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

[Magnus Westerlund <[e-mail]>]

Simon Perreault skrev den 2015-06-08 16:15:
> Le 2015-06-08 03:36, Magnus Westerlund a écrit :
>> 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.
>
> Can you please explain, for those of us with short memories? :)

I went and checked this. This formulation has been present since the 
first versions, and no one has questioned this RFC 2119 worded 
statement. Therefore I consider there to be consensus behind it and 
being intentional.

The motivation I see for this statement is the following. First of all I 
think people have been against considering having stand bye SSRCs that 
are really likely to never be used. I think DTMF is one of these 
exceptions. Having stand by SSRC also have an overhead cost, primarily 
in the result of the number of SSRCs present in the session and their 
consumption of their share of the RTCP bandwidth resources. We also have 
the issue of correctly associating the SSRC to a media source, now that 
there are more than one.

Based on that, (with the assumption that you do PT switching rarely) the 
lower cost is to drop the SSRC after its usage. From that follows that 
one stop using it, and therefore sends BYE, then you really should not 
revive a dead SSRC. Thus, need to create a new one. Simply codifying 
this expectation in the RFC.


>
>>> Are there legacy gateways that will NOT fall over on a clock rate + SSRC
>>> switch?
>>
>> Good Question!
>
> Depends what you mean by "legacy". My gateway will not fall over.
>

I think this is an import aspect. The gateway is not legacy, as it is an 
WebRTC gateway. It is the endpoint on the other side of the gateway that 
is "legacy".

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