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

Magnus Westerlund <> Mon, 08 June 2015 14:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4667B1A8AE9 for <>; Mon, 8 Jun 2015 07:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GyLvlQlo758Q for <>; Mon, 8 Jun 2015 07:43:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AF7F1A8AE3 for <>; Mon, 8 Jun 2015 07:43:08 -0700 (PDT)
X-AuditID: c1b4fb30-f799f6d000000faf-7a-5575a9fb696e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id FE.EC.04015.BF9A5755; Mon, 8 Jun 2015 16:43:07 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 8 Jun 2015 16:43:06 +0200
Message-ID: <>
Date: Mon, 08 Jun 2015 16:43:05 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Simon Perreault <>, Harald Alvestrand <>, Roman Shpount <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvre7vlaWhBg93SFkc6+tis5hxYSqz xdp/7ewW16+EOrB4XJlwhdVjyZKfTB7/5jxl9rg1pSCAJYrLJiU1J7MstUjfLoErY/XHH6wF P8Qrfqzbx9TA+FGoi5GTQ0LAROLTzK2MELaYxIV769m6GLk4hASOMkrM3HiDHcJZxijRMO89 E0gVr4C2xIrLO1lBbBYBFYnlO76C2WwCFhI3fzSygdiiAlESUx+vY4GoF5Q4OfMJmC0iUCFx c00bM4jNLKAucWfxOXYQW1jAV+L1os2sEMv6mCROLTgHtIyDg1NAQ6J7kwWIySxgL/FgaxlE q7xE89bZYGOEgM5paOpgncAoOAvJtlkIHbOQdCxgZF7FKFqcWpyUm25kpJdalJlcXJyfp5eX WrKJERjQB7f8NtjB+PK54yFGAQ5GJR7eB/tKQoVYE8uKK3MPMUpzsCiJ887YnBcqJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgbH8eNdP8e3lTvLbI3rqWl2FrzK+33O3j5V/8rTmaYsMP81V OMpSbtqjzPw5aN688lA2w+3+zZtrTix7qb+zq3Pl/NnnNr3Wua9xtdWWy/DTTEbOrzzFHOXv nc7yStfWWThfLzL9e+NxkGde4CqHWemlcvfDVv7JWzth9ureshzJlded44uKTyqxFGckGmox FxUnAgDEE2p0SQIAAA==
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 14:43:11 -0000

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


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: