0

RFC 3550から:

受信者が他の 2 つのソースが衝突していることを発見した場合、一方からのパケットを保持し、これが異なるソース トランスポート アドレスまたは CNAME によって検出できる場合、他方からのパケットを破棄することができます。 状況が続かないように、2 つのソースが衝突を解決することが期待されます。

レシーバーとのみ通信する 1 つのレシーバーと 2 つのセンダーを含むユニキャスト構成では、SSRC 衝突がセンダーによってどのように検出される可能性がありますか?

1 つの推測では、受信者はすべての既知の CNAME をすべての既知の参加者 (送信者) に定期的に送信する必要があります。本当ですか？しかし、この場合、送信者は受信した CNAME をトランスポート アドレスにどのように関連付けるのでしょうか?

アップデート：

以下で回答されているように、別々の SSRC スペースを持つ 2 つの別々の RTP セッションがあるため、衝突検出は必要ありません。

RTP セッションの際立った特徴は、それぞれが完全な個別の SSRC 識別子のスペースを維持することです。

と：

1 つの RTP セッションに含まれる参加者のセットは、参加者のいずれかによって送信された SSRC 識別子をSSRC または CSRC (以下で定義) として RTP または RTCP で受信できるもので構成されます。

そして、私が説明した状況の例さえあります:

たとえば、各参加者が別のポート ペアで他の 2 人から受信する、ユニキャスト UDP を使用して実装された 3 者会議を考えてみましょう。各参加者が、他の 1 人の参加者から受信したデータに関する RTCP フィードバックをその参加者にのみ送信する場合、会議は 3 つの個別のポイントツーポイント RTP セッションで構成されます。

4

2 に答える 2

1

さようならは、理由を適切な値に設定して送信できます。

http://www.ietf.org/rfc/rfc3550.txt @ 6.6 BYE: Goodbye RTCP Packetを参照してください。

伝統的に、SSRCが変化していることを示すために使用される値「ssrc」を見てきました。

さらに、RTCP パケットが新しい SSRC で受信された場合、RTP パケットの ssrc もおそらく変更される必要があるため、ssrc が変更されてもシーケンス番号がまだ有効な場合は、シーケンス番号を検証するときに処理され、新しい ssrc が使用されます。 .

于 2014-06-07T20:51:40.700 に答える
1

私が理解している限り、このルールはパケットのマルチキャストおよび/またはループにのみ適用されます。あなたが説明した設定 (2 つの送信者が 1 つの受信者にユニキャストしている) では、お互いを認識しておらず、衝突を検出する手段がありません。この問題に対処するのが受信側のタスクです。受信者がメディア プロセッサである場合、エンド パーティとして機能し、ストリームを再フォーマットし、独自の SSRC で必要なコンテンツを再送信する可能性があります。

于 2014-01-07T19:00:20.830 に答える