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

Harald Alvestrand <> Mon, 08 June 2015 15:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6CC161B2E8D for <>; Mon, 8 Jun 2015 08:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1YhEmdZ1U4q9 for <>; Mon, 8 Jun 2015 08:13:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 07E9C1B2EC3 for <>; Mon, 8 Jun 2015 08:09:13 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D55077C0A46; Mon, 8 Jun 2015 17:09:11 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iGp4mF8b82pC; Mon, 8 Jun 2015 17:09:10 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:f4ab:e7e9:ac4b:ad3e] (unknown [IPv6:2001:470:de0a:27:f4ab:e7e9:ac4b:ad3e]) by (Postfix) with ESMTPSA id 6D12C7C0A45; Mon, 8 Jun 2015 17:09:10 +0200 (CEST)
Message-ID: <>
Date: Mon, 08 Jun 2015 17:09:07 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Magnus Westerlund <>, Simon Perreault <>, Roman Shpount <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: "" <>
Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jun 2015 15:13:03 -0000

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