web-dev-qa-db-ja.com

RTPのCSRCとSSRC

私はRTPに非常に慣れていませんが、CSRCとSSRC全般について誰かが説明できますか？

http://www.rfc-editor.org/rfc/rfc3550.txt から、次のようになります。SSRCフィールドは同期ソースを識別します。それは、ネットワーク内でRTP（マルチキャストネットワーク）に貢献し、パケットがどのソースから来ているかを識別するために多くの送信者がいる可能性があるということですか？

CSRC：コントリビューティングソース（CSRC）：RTPミキサー（以下を参照）によって生成された結合ストリームにコントリビューションしたRTPパケットのストリームのソース） 。 わからなかった。

誰かが例を挙げて説明してもらえますか？ありがとう

siprtsprtprtcp
10
badri.coder

リンク： から取得

[〜＃〜] ssrc [〜＃〜]同期ソースを識別します。値はランダムに選択され、同じRTPセッション内の2つの同期ソースが同じSSRCを持つことはありません。複数のソースが同じ識別子を選択する可能性は低いですが、衝突を検出して解決するために、すべてのRTP実装を準備する必要があります。ソースがソーストランスポートアドレスを変更した場合、ループされたソースとして解釈されないように、新しいSSRCも選択する必要があります。

[〜＃〜] csrc [〜＃〜]このパケットに含まれるペイロードの寄与元を識別する0から15のCSRC要素の配列。識別子の数はCCフィールドで指定されます。 15を超える貢献元がある場合、15のみを識別できます。 CSRC識別子は、寄稿元のSSRC識別子を使用してミキサーによって挿入されます。たとえば、オーディオパケットの場合、パケットを作成するために混合されたすべてのソースのSSRC IDが一覧表示され、受信者での正しい話者表示が可能になります。

正直なところ、SSRCやCSRCを実際に意味のある方法で使用している人を見たことがありません。私が扱ったすべてのコードでは、SSRCで乱数を生成するだけで、CSRCに入力する必要はありません。

SSRCは、ループしているオーディオパスのトレースや検出に役立つと思います。

CSRCは、上記の引用で示唆されているように、複数のオーディオソースが混在している会議サーバーからオーディオを受信するSIPエンドポイントに役立つ可能性があると思います。私が言ったように、私が扱った会議サーバーのコードでは、私たちは気にしません。

13
Shane Powell

あなたの質問について「それは、ネットワークでは、RTP（マルチキャストネットワーク）に貢献し、パケットがどのソースから来ているかを識別するために多くの送信者がいる可能性があるということですか??」

多くのソースがある場合、ビデオ/オーディオはRTPミキサーで混合され、この場合のSSRCはRTPミキサーSSRCであるため、特に当てはまりません。はRTPパケット送信者のソースではありません。ソースを知るために、一意のSSRCによって識別されるこれらのソースを持つCSRC配列を調べる必要があります。配列のサイズは、次の式でも与えられます。ヘッダーフィールドCC：CSRCをカウントします。

オーディオ/ビデオが結合されていない（ユニキャスト）場合、SSRCはこのビデオ/オーディオの送信者のものであり、CSRCは入力されていません。

役立つプレゼンテーション： http://voip.netlab.uky.edu/~fei/teaching/cs671/slides/rtp.pdf

2
Nizarazo
  1. SSRC：

同期ソース識別子（32ビット）は、データストリームのソースを明確に区別します。同じRTPセッション内の同期ソースは一意になります。

2.CSRC：

コントリビューションソースID（各32ビット）は、複数のソースから生成されたストリームへのコントリビューションソースを合計します。

https://en.wikipedia.org/wiki/Real-time_Transport_Protocol

0
Charles