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

[Harald Alvestrand <[e-mail]>]

Den 08. juni 2015 10:48, skrev Magnus Westerlund:
> Roman Shpount skrev den 2015-06-04 23:02:
>> On Wed, Jun 3, 2015 at 4:06 PM, Harald Alvestrand <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>
>>     If we want to have a mechanism that:
>>
>>     a) allows PT switching
>>     b) uses different clock rates (and therefore different SSRCs)
>>     c) doesn't need renegotiation on SSRC change
>>
>>     I would think that the initial SDP would have to contain a=ssrc
>>     fields for *all* the possible SSRCs - that is, one "a=ssrc:<nnnn>
>>     cname:<cname>" line per payload type.
>>
>>     Section 5.2.1 already specifies that there will be multiple a=ssrc
>>     lines (and a=ssrc-group lines) in the case of RTX data. So it's not
>>     exactly a novel solution.
>>
>>
>> I agree with one small correction -- it is not a separate SSRC per
>> payload type, but separate SSRC per clock rate. For instance, if you
>> have G.711 audio, RFC 4733 tones and CN at 8KHz, there is going to be a
>> payload type for each of them, but all this media should use the same
>> SSRC. Opus, RFC 4733 tones and CN at 48Khz (and you will need to specify
>> to different payloads for tones and CN for different clock rates), will
>> use second SSRC.
>>
>> The reason for separate SSRCs is to have RTCP reports to work correctly,
>> which requires to use the same time units for all the media under
>> particular SSRC. Multiple payloads running with the same clock rate can
>> re-use the same SSRC without any issues. It actually is beneficial to
>> use the same SSRC since they can be synchronized based on the RTP time
>> stamps which would be more precise then ntp time.
> 
> 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?

> 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.

> 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?

> 
> 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?
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]
> ----------------------------------------------------------------------
>