Subject: [AVT] RTP Multicast conferencing & SSRC

From: "Cesc Santa" <[email-masked]>
Date: Wed, 20 Jun 2007 12:11:22 +0200

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Jun 2007 11:28:06 +0100

Hi,

On 20 Jun 2007, at 11:11, Cesc Santa wrote:
> If this is not the appropriate forum, please let me know where  
> shall I send this query to.

This list is the correct place.

> I am testing two RTP multicast conferencing implementations and I  
> came across a problem.
>
> Lets say I have:
> - 1 units of MCU-type-A
> - 3 units of MCU-type-B
> Each of these units runs on a separate PC, all connected by a  
> multicast network (a hub? :D ).
>
> Now, they are statically configured to dump audio in a multicast  
> channel.
>
> The problem is that the 3 units of MCU-type-B they all choose the  
> same SSRC for their RTP streams (they are mixers, mixing the audio  
> from unicast SIP phones) for that conference/mcast channel.
>
> What happens is that the one unit of MCU-type-A gets severely  
> confused: it uses only the SSRC to "mix" the received multicast  
> streams (of course, each "multicast channel"/conference has a  
> separate SSRC-list). The 3 received streams have the same SSRC (and  
> codec), but different sequence numbers, so the mixer thinks that is  
> receiving ONE stream with huuuuge jitter and also old packets and  
> dropping most of the packets.
>
> My question is: is the behavior of the MCU-type-B (same SSRC) correct?

No - see RFC 3550 section 5.1 (the description of the SSRC).

> * if yes, this means that the mixer on MCU-type-A should take into  
> consideration the source transport address when mixing multicast  
> streams. This seems a lot of extra work (processing power) on the  
> mixer.
> * if no, I agree with you :)
>
> I read the RFC but it was not clear to me if such a setup would  
> fall into the definition of ONE "RTP Session" (and thus SSRC  
> uniqueness needs to be enforced) or we'd be talking about 3 rtp  
> sessions. It would seem to me that only destination transport  
> (pair) address is considered, and this being a multicast session,  
> it is the same for all participants and thus it is to be considered  
> ONE rtp session and thus SSRC uniqueness MUST be enforced.

Correct. It's a single RTP session, so the SSRC values must be unique.

> I don't know if it is important, but RTCP is not supported by  
> neither of the MCU types ...

It hinders the SSRC collision resolution mechanism, and makes it  
impossible to know which original sources are being mixed, amongst  
other problems.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Cesc Santa" <[email-masked]>
Date: Wed, 20 Jun 2007 13:08:18 +0200

Thanks!
I will notify the vendor.

Cesc