Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching

[Magnus Westerlund <[e-mail]>]

Harald Alvestrand skrev den 2015-06-08 11:19:
> Den 08. juni 2015 10:48, skrev Magnus Westerlund:

>> However, this can't work as RFC 7160 says in Section 4.1:
>>
>>    An RTP Sender with RTCP turned on MUST use a different SSRC for each
>>     different clock rate.  An RTCP BYE MUST be sent and a new SSRC MUST
>>     be used if the clock rate switches back to a value already seen in
>>     the RTP stream.
>>
>> Note the second sentence. One would still have to do a new round of
>> signalling to prime a new SSRC for the previous rate after having
>> switched to be able to switch back to that Payload Type.
>
> Hm. I missed that when reviewing the clock-rate doc.
> So that means one uses up an SSRC for every clock rate switch. That
> seems silly; is it possible that this should be considered an erratum
> for RFC 7160?

No, it is highly intentional as I remember the discussion.

>
>> I would to some degree argue that renegotiation is not needed here. My
>> preference would be for a solution that rather use header extensions to
>> indicate what "purpose" the new RTP stream has so that one understands
>> that this is the replacement for an earlier RTP stream.
>
> That would of course be incompatible with anything that came before.

All that has used multiple streams per endpoint before has had some 
implicit rules to handle different situations. What is forcing the issue 
here is the realization about RFC 7160 forcing SSRC changes. If there is 
single encoding per endpoint, then using CNAME and PT is sufficient to 
associate when one switches. If one have multiple streams then the fun 
starts. IETF has never had any specifications for solving this, so from 
that perspective we are laying down a solution where different 
interpretations has been used based on what is specific for that 
application.

>
>> For the cases where a source is encoded into a single encoded stream and
>> put in one RTP stream I think all the necessary indications are there.
>> MID for which m line it belongs. The PT will indicate if it a source RTP
>> stream or an Redundancy RTP stream (FEC or RTX).
>>
>> It is when one comes to scalability layers sent in multiple RTP streams
>> it becomes problematic to determine on RTP level which is which, without
>> looking into payload header info to determine which layer the payload
>> contains.
>
> But I just can't imagine switching clock rates for different layers of a
> scalability-encoded stream. Should we just not solve the problem of
> behaving bizarrely for this case?

That was not what I meant. If one switches to or from a scalable encoder 
or between different encoders, the one might be in a situation where one 
needs to identify that one set of SSRCs are now replaced with a 
different set of SSRCs.

What I was unclear on was that multiple RTP streams for a single media 
source due to scalable encoding anyway has this issue with 
identification. I think the solution to that is likely a combination of 
MID and something like the header marking header extension being 
proposed in AVTEXT:

https://datatracker.ietf.org/doc/draft-berger-avtext-framemarking/

That way the identification information is available to the receiver 
directly before having to look into payload. Something that will be 
impossible in a PERC scenario anyway.

>
>>
>> Having said that I do wonder if this will be a problem, especially in
>> gateways to legacy. Where this behaviour will make the legacy peer fall
>> over. Thus requiring a gateway that remap back to a single stable SSRC,
>> possibly with loss of synch information. Please remember that there are
>> reasons why the SSRC change was made as the required behaviour.
>
> Are there legacy gateways that will NOT fall over on a clock rate + SSRC
> switch?

Good Question!

> If so - what do these legacy gateways do when switching back to the
> original PT? New SSRC, or back to a previously used SSRC?
>


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------