Re: [AVTCORE] SSRC multiplexing of RTP

Cullen

I agree. I have also got negative feedback on SSRC multiplexing.

I had it described in the draft for multi-party handling of real-time 
text in draft-hellstrom-text-conference-02.txt
in order to easily separate the streams from different sources and 
display them in a way that the receiver decides.

But the feedback was that many RTP implementations would just regard it 
to be an error if a new SSRC appeared in the session and it would cause 
problems.

SSRC multiplexing also has some trickiness in that when a new SSRC 
appears in the session, it can either be an old stream that changed SSRC 
or a new multiplexed stream. RFC 3550 mentions ways to handle that but 
there is a risk for losing initial packets before it is sorted out. 
Losing initial packets in e.g. a video stream can be fatal for the 
possibility to start proper decoding rapidly.

Taking the consequences of this, I am just about to submit a modified 
draft for the real-time text case using one stream and marking the 
source by CSRC per packet.
It will survive through most existing RTP implementations.

/Gunnar

Cullen Jennings skrev 2011-03-09 00:34:
> I've been geeing a lot of questions lately about ways to multiplex RTP onto one UDP port. This would be for an environment using point to point media flows set up with SIP between endpoints or between an endpoint and centralized conferring unit. There is no multicast involved in these use cases. For example the SSRC based approach in
>
> http://www.jdrosen.net/papers/draft-peterson-rosenberg-avt-rtp-ssrc-demux-00.txt
>
> Now, I do recall that people felt there were problems with this type of approach but I forget what they were. Can someone help remind me what the issues are with this.
>
> Thanks, Cullen
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt