RTP：SSRC碰撞檢測單播會話

Question

從RFC 3550：

如果接收器發現其他兩個 源碰撞，它可以從一個保持數據包，當這一點可以從其他丟棄 包由不同的 源傳輸地址或CNAME檢測到。 這兩個來源預計 來解決衝突，使情況不會持續。

在具有一個接收器和兩個只與接收器通信的發送器的單播配置中，發送器如何檢測SSRC衝突？

一個猜測是接收方應定期向所有已知的參與者（發件人）發送所有已知的CNAME。這是真的嗎？但在這種情況下，發件人如何將收到的CNAME與傳輸地址相關聯？

更新：

如下回答，也有獨立SSRC空間兩個單獨的RTP會話，所以不需要碰撞檢測。

RTP會話的顯着特徵是，每個 保持SSRC標識符

和一個完整的，獨立的空間：

參與者集合包含在一個RTP會話 包括那些可以接收任何一個參與者傳輸 SSRC標識符的人可以在RTP中作爲SSRC或CSRC （也在下面定義）或RTCP。

而且甚至還有爲我所描述的狀況的一個例子：

例如，請考慮使用單播UDP每個 參與者從不同的其他兩個接收三 方會議實現端口對。 如果每個參與者發送有關從 一個其他參與者收到的數據RTCP反饋只返回給該參與者，然後 會議由三個單獨的點對點RTP 會話組成。

Answer 1

據我所知，這個規則只適用於數據包的多播和/或環路。用你所描述的設置（兩個發送者單播給一個接收者），他們彼此不認識，也沒有檢測到碰撞的措施。解決這個問題是接收方的任務。如果接收器是媒體處理器，它可能會作爲一個終端方，重新格式化流並重新發送其自己的SSRC下的所需內容。

Answer 2

甲再見可以設置爲適當的值的原因被髮送..

參見http://www.ietf.org/rfc/rfc3550.txt @ 6。6 BYE：再見RTCP數據包

按照傳統，我已經看到用於指示SSRC正在改變的值「ssrc」。

此外，如果一個RTCP數據包被一個新的SSRC接收到，RTP數據包ssrc可能也應該改變，因此將在驗證序列號時處理，如果ssrc改變但序列號仍然有效，那麼新ssrc將被使用。