問題タブ [ice-protocol]

Cで小さなwebrtcアプリケーションを開発しています.sipシグナリングを使用してwebrtc呼び出しを行っています。スタン/ターン/アイスの使用に関して以下の質問があります。

通話を開始するときに、オファー (SDP) を含む INVITE を送信します。SDP では、ICE 候補を配置する必要があります。

考えられるケースは 2 つあります。それを説明するために、例を挙げます。2 つのエンドポイントがAとBであるとします。Pと言う一口プロキシサーバーがあります。また、私はターンサーバー（スタンとターンの両方をサポートしています）を持っています。それはTです。

ケース 1
すべてのエンティティA、B、P、およびTが同じプライベート ネットワーク内にあります。ここで STUN 解決が必要ですか? はいの場合、対処する必要があるすべてのスタン要求/応答は何ですか?

ケース 2
ここで、 Aはプライベート ネットワーク内にあります。他のエンティティB、P、およびTはパブリック ネットワークにあります。この場合、STUN/TURN 解決を行う必要があることを願っています。STUN から始めて、ホストと再帰候補を得たとしましょう。いくつかの例では、Permission、Channel Bindリクエストも使用されています。STUN のみ (TURN なし) を使用している場合、ホストとリフレクティブ候補を取得した後、何か特別なことをする必要がありますか?

これ以外に、gnutls (openssl なし) を使用する C のスタン/ターン クライアントに利用できる優れたオープン ソースはありますか?

関連する WebRTC、ICE プロトコルは、どのペアのアドレスがペア間の直接メディア転送で機能するかを示します。

A と B を 2 つの端点とする

1. A と B 間の直接通信に使用するアドレスを選択するために、人物 A はまず候補を収集し、候補属性をエンコードし、SDP オファー メッセージをエンコードして、それを別のエンドポイントに送信します。

2. B が A からオファー メッセージを受け取ると、B は候補を収集し、SDP 応答メッセージを独自の候補リストでエンコードして、A に送信します。

3. このプロセスの最後に、各エージェントはローカル候補とリモート候補の完全なリストを取得します。それらをペアにして、CANDIDATE PAIRS を生成します。どのペアが機能するかを確認するために、各エージェントは STUN req/resp を使用して接続チェックを実行します。

有効な候補ペアを指名するために、何回の接続性チェックが実行されますか?

webRTC 呼び出しに関して実行される残りの ICE 接続チェックは何ですか?

webRTC 呼び出し用の ICE モジュールを開発するには、RFC5245 の各ステップに従う必要がありますか?

Webrtc 通話では、メディア パラメータのネゴシエーションに sip シグナリングと sdp を使用しています。

通話開始前に、スタンバインド トランザクションを実行し、再帰候補を取得します。ベース候補とホスト候補に加えて、これらの再帰候補をsdpに入れました。

Invite の 200 OK を取得したら、すぐにメディアを開始する必要があります。メディアを開始するには、どの候補ペアを使用する必要があるかを知る必要があります。

どの候補ペアを使用する必要があるかを判断したいと考えています。接続チェックを行う必要があります。接続チェックの方法がわかりません (送信するメッセージなど)。

誰かがこれを理解するのを手伝ってくれませんか。

また、ice/stun/turn をサポートするオープン ソース (c、Linux ベース) もあります。

私は WebRTC アプリケーションを作成していますが、LAN 内ではすべて正常に動作します。ただし、ICE Failedピアが異なるネットワーク上にあるとエラーが発生します。

私の STUN サーバーはパブリック IP の候補を返すので、正しく設定されていると思います。問題は、候補 IP が「正しくペアリング」されていないことです。ブラウザーは常に 1 つのパブリック IP と 1 つのプライベート IP を接続しようとするため、接続は失敗します (候補ペアを参照してください)。

ここで何が問題になる可能性がありますか？シグナリングサーバーまたはrtcpeerconnection構成？

メディア メッセージを他のデバイスに送信するとき、または初めて使用するときに、毎回STUN サーバーを使用する必要がありますか?

最初のメッセージを送信した後、パブリック IP アドレスを知っているからです。

つまり、(パブリック IP アドレスを取得するために) 初めてSTUN サーバーが必要な場合は、メッセージの転送中にSTUN サーバーがダウンしても何も気にしません。

だから、私はwebrtc video chatを使用してWebアプリを構築しようとしていpeer.jsます. これまでのところ、すべてがうまくいっているようです。プライベート サーバーでアプリを実行すると、問題が発生します。

応答または電話をかけようとするたびに、ビデオが数秒間再生され始めますが、黒い画面が表示され、ICE Failedエラーが発生して切断されます。

これは、2 人のユーザーが同じ IP アドレスを共有している場合には発生しません。ユーザーが同じ IP を共有している場合、ビデオ チャットは正常に機能し、まったく問題はありません。

ここで何が問題になる可能性がありますか？

アップデート

私はstunを追加し、サーバーをピアに向けましたが、同じエラーが再び発生しました

これは、ICE ネゴシエーションによる webrtc コール セットアップの遅延に関するものです。音声通話を試してから、ビデオを有効にしています。新しいビデオ ストリームが既存のピア接続に追加され、オーディオ トラックとビデオ トラックの両方の ICE 候補が収集されます。再交渉開始。RE-INVITE の SDP には、オーディオおよびビデオ トラックの新しい ICE 候補があります。

最初の音声通話中に既に存在していた音声トラックの ICE 候補を使用できないのはなぜですか? なぜ再びICE候補を集めるのですか？