3

RFC 3550（RTP）のJava実装を行っていますが、小さな問題が発生しました。

第11章の第2段落では、次のように述べています。

（...）参加者は、着信RTPまたはRTCPパケットの送信元ポートが発信RTPまたはRTCPパケットの宛先ポートとして使用できると想定してはなりません（MUSTNOT）。RTPデータパケットが双方向に送信される場合、各参加者のRTCP SRパケットは、他の参加者がRTCPの受信用に指定したポートに送信する必要があります。（...）

RTPには、これらのアドレスとポート（SDPまたはその他のセットアッププロトコルまで）を通知するメカニズムがないため、この段落を「不明なソースからデータを受信して​​いる場合は、破棄するだけ」と理解できます。 。

ただし、セクション6.3.3では、基本的に、RTPまたは非BYE RTCPパケットが不明なSSRCで受信された場合、新しい参加者をテーブルに追加する必要があると述べています。

要約すると：

  1. 不明なSSRCを受信した場合は、新しい参加者を追加する必要があります。
  2. パケットの送信元IP/ポートをその参加者のパケットの宛先として使用することはできません。
  3. SDPは、各RTP参加者が使用するSSRCを定義していません。
  4. RTP参加者を手動で追加できます（他の方法で検出されます）が、SSRCがどうなるかはわかりません。

つまり、百万ドルの問題は、予期しないSSRCをどのように処理するのかということです。

4

2 に答える 2

2
  1. 不明なSSRCを受信した場合は、新しい参加者を追加する必要があります->セクション6.2.1に従って確認した後のみ
  2. パケットの送信元IP/ポートをその参加者のパケットの宛先として使用することはできません->エンドポイントAのRTP/RTCPペアがエンドポイントBのペアと同じであるとは期待できないと言っています（ただし、指定されていない限り）。（セクション11では、RFCはIPアドレスについて話していません。）
  3. SDPは、各RTP参加者が使用するSSRCを定義していません-> SSRCはオンザフライで変更できるため、はい。
  4. RTP参加者を手動で追加できます（他の方法で検出されます）が、SSRCがどうなるかはわかりません。???

したがって、百万ドルの質問はまだ百万ドルの価値があります。あなたを調査して更新します。それまでの間、回答が見つかった場合は、私たちも更新してください。

于 2010-09-15T10:04:31.160 に答える
0

RFCの私の解釈から、あなたの質問への回答はセクション6.3.3にあります：

6.3.3RTPまたは非BYERTCPパケットの受信

SSRCがメンバーテーブルにない参加者からRTPまたはRTCPパケットを受信すると、SSRCがテーブルに追加され、セクション6.2.1で説明されているように、参加者が検証されるとメンバーの値が更新されます。

どのエントリが有効であると見なされるべきかについて：

（...）新しいSSRCを伝送する複数のパケットが受信されるまで（付録A.1を参照）、またはそのSSRCのCNAMEを含むSDES RTCPパケットが受信されるまで、新しいエントリは無効と見なされる場合があります。 ）。

何かが足りなくてもいいですか？;）

于 2010-09-14T08:23:58.087 に答える