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

[Harald Alvestrand <[e-mail]>]

On 06/08/2015 04:43 PM, Magnus Westerlund wrote:
> 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.

This has another implication:

When doing PT switching for comfort noise, you MUST have a CN with the
same clock rate as your normal audio codec.

CN is exactly the type of PT-switching that, if it occurs at all, occurs
very frequently.