特定のファイアウォールや VPN を介した接続環境下でのみ、以下のような現象を観測した場合、SDK の Client#connect の引数の option.iceServersProtocol オプションで解決できる可能性があります。
通常、RICOH Live Streaming で使用している WebRTC のトランスポートプロトコルは UDP、TCP、TLS の中からクライアントが自ネットワークで使用可能なプロトコルを自動で選択します。また、WebSDK や AndroidSDK では TLS や TCP が選択されると CONNECT プロキシを通ることができます。 (AndroidSDK は OS のプロキシ設定は反映されず option.proxy.url の指定が必要です)
しかし特定のファイアウォール、VPN、プロキシではクライアントのトランスポートプロトコル自動判定が正常に機能しません。例えば環境によっては、UDP 通信は最初の数秒のみ疎通してすぐに遮断されるが、TLS 通信は CONNECT プロキシ経由で正常に接続できることがあり得ます。この場合、SDK は最初の疎通している間に UDP 通信が可能と判定しますが、その後遮断されてしまって通信に失敗します。
このようなトランスポートプロトコル自動判定が正常に機能しない環境では、SDK の Client#connect の引数の option.iceServersProtocol に使用するプロトコルを与えて強制させることで接続できるようになります。
demo.js の例だと 181 行目のコメントアウトを解除する とトランスポートプロトコルが TLS に強制されます。
ただし、常に TLS を強制することがベストとは限りません。大雑把に言うとトランスポートプロトコルの違いで以下のようなトレードオフがあります。
商用アプリケーションでこの機能を使う場合の実装としては、設定画面に「接続に利用するプロトコルを TLS (TCP ポート 443) に強制する」のチェックボックスを用意して、チェックされていたら iceServersProtocol を tls 、そうでなければ all に設定するなどが現実的かと思います。
また、同じ環境で正常に通信できている端末も存在するなど、ファイアウォールや VPN に問題があるとは言えない場合で SDK が 53719 ConnectionCreateTimeout のエラーを発生させたり、映像も音声も流れなかったりする場合は、ネットワーク帯域や CPU のスペック不足など他の問題の可能性が非常に高いです。
ここまで WebRTC の専門用語を使わずに説明しましたが、トランスポートプロトコルを自動判定するプロトコルは ICE (Interactive Connectivity Establishment)、WebRTC の通信を各種トランスポートプロトコルにトンネリングさせるプロトコルは TURN (Traversal Using Relays around NAT)、というプロトコルです。これらのプロトコルの詳細は MDN などウェブ上に解説記事が複数ありますのでそちらを参照してください。
この情報は役に立ちましたか？