Subject: Re: [AVT] RTP collision resolution

From: Colin Perkins <[email-masked]>
Date: Fri, 9 May 2003 16:58:50 -0400

Hi,

--> Aaron Colwell <[email-masked]> writes:
> 
> I've been reading through the RFC 1889 and draft-ietf-avt-rtp-new-12.txt
> and I still can't quite figure out a few things about the SSRC collision
> resolution algorithm.
> 
> I will first start with the simple case where there is one sender in the
> RTP session. In this case there is only one sending SSRC and the "send a
> BYE for the old SSRC and pick a new SSRC" is pretty clear and easy for
> the client to figure out what is happening. Does the sender keep the same
> sequence number and timestamp offset across this switch? My current
> assumption is that it does, but I could not find that explicitly stated
> anywhere. Is that assumption correct? I hope so since it might cause all
> sorts of problems for certain payload types like interleaved AMR.

I'd expect a sender to pick new random offsets for the sequence number and
timestamp when a collision occurs, as if it had just joined the session. A
collision should be a very rare event, so I'm not worried that this might
cause a glitch in the playout.

> The second case that I am confused about is when there are more than one
> sender in an RTP session. For this example I'll use the case where we are
> doing SSRC multiplexing of a stream and a retransmission stream. In this
> case both SSRCs are associated with the same CNAME. In the highly
> unlikely chance that both SSRCs conflict with existing SSRCs in the
> session, how will the client resolve the proper transition of both of
> these SSRCs to new SSRCs? The only way that I can think of to resolve
> this would be to use the payload type. Is that how the resolution should
> happen?

Yes, I think so.  
 
> My third case is similar to my second case. I have seen examples in the
> archives where people talk about using SSRC multiplexing for a lecture
> type environment where there is a SSRC assigned to a lecturer, and a
> SSRC assigned to a question microphone. In this scenario, the two SSRCs
> likely have the same payload type so the resolution mechanism from case 2
> would not work. How is the client supposed to resolve the transitions in
> this case? Do all of these sources have the same CNAME? If not, then the
> resolution can be done based on the CNAME. I was under the impression
> that the CNAME would be the same for all the SSRCs in this scenario
> though.

I'd be tempted to give these separate CNAMEs, since they're really two
different sources.

> One final question about SSRC multiplexing in general. Is it assumed that
> all SSRCs associated with the same CNAME should be mixed together on the
> client side?

Depends on what payload formats are used.  The traditional model was that
SSRC multiplexing represented multiple cameras or microphones for a single
source, so it made sense to mix audio streams. If payload formats like the
retransmision format, SSRC multiplexing is now used for other purposes, so
you need to determine what is being multiplexed before you decide what to
do with it.

This is one of the reasons why there was pushback about the use of SSRC
multiplexing with retransmission.

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