Re: [AVTCORE] SSRC multiplexing of RTP

[Harald Alvestrand <[e-mail]>]

On 03/09/11 16:40, Magnus Westerlund wrote:
> Hi Gunnar,
>
> Gunnar Hellström skrev 2011-03-09 16:11:
>> 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.
> Well, this is how you are supposed to use cases when you have multiple
> sources. And text chat is case when implementations can't really say
> that they don't have the rendering capabilities for it. But I do
> understand that most implementations sucks at handling multiple SSRCs
> which is very bad.
>
> My hope is that we will see a bit of signalling support for handling
> multiple SSRCs as part of the CLUE work. But, we do need to push that
> support for multiple SSRCs, it needs to be in the stacks.
Seems to me that since this isn't clear from current specs, there needs 
to be a specification of what a new SSRC appearing in a session means, 
possibly agreed to at call setup time, and if both renumbering and 
multiple streams are to be supported:

- if it is a new stream, how to tell that it's a new stream
- if it is an old stream, renumbered, how to tell what the old stream was

This will certainly be an RTCWEB discussion item, so I'm happy to see 
AVTCORE pick it up to be worked on.
>> 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.
> I guess clarifications should be in place here. And your strategy for
> handling it will depend a lot of what application it is and which media
> one talks about.
>
>> 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.
>>
> So your going with a mixer design, despite that for text it isn't really
> needed. I think it is unfortunate, but I guess pragmatic due to poor
> implementation support.
>
> A question to implementors:
>
> Have you tried running the tests documented in RTP testing strategies?
> http://www.rfc-editor.org/rfc/rfc3158.txt
>
> These are excellent tests to check that ones implementation handles what
> it needs to.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>