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

Magnus Westerlund <> Mon, 08 June 2015 08:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D21331B2D94 for <>; Mon, 8 Jun 2015 01:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 rm31uf76HMyX for <>; Mon, 8 Jun 2015 01:48:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E16251B2CAA for <>; Mon, 8 Jun 2015 01:48:48 -0700 (PDT)
X-AuditID: c1b4fb3a-f79ec6d000006dc0-f6-557556ee6534
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 47.27.28096.EE655755; Mon, 8 Jun 2015 10:48:47 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 8 Jun 2015 10:48:46 +0200
Message-ID: <>
Date: Mon, 08 Jun 2015 10:48:45 +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: Roman Shpount <>, Harald Alvestrand <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+Jvre77sNJQgz0XuC2O9XWxWcy4MJXZ Yu2/dnYHZo8rE66weixZ8pPJ49aUggDmKC6blNSczLLUIn27BK6MXzP3sBbsla3Y9fgkawNj v3gXIyeHhICJROOVT8wQtpjEhXvr2boYuTiEBI4ySsz8+ogZwlnGKNEwcx6Qw8HBK6Atcf+1 L0gDi4CKxILdDSwgNpuAhcTNH41sILaoQJTE1MfrwOK8AoISJ2c+AbNFBAIlnh+ewApiMwuo S9xZfI4dxBYW8JV4vWgzK8SuiYwSvzqfgl3ECdTQNmsmI8heZgF7iQdbyyB65SWat84GKxEC OqehqYN1AqPgLCTrZiF0zELSsYCReRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYPge3PLb agfjweeOhxgFOBiVeHgf7CsJFWJNLCuuzD3EKM3BoiTOO2NzXqiQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGxvitTnbBHO1RCh1WHxkO2u53fC/dM98o4PIRYd8JV27t6ntRqvXRn2dtuPyy C7Uym73WK7Upr57076P9l4g8xTe6scl35092Zo1V37WjQ0Jkg47l3bPx2zf2+D6XbN8fm/HK y/yr0TzddNsDmeyH/s951W1gcEZp7fV1pmI1VZbW167dXO7coMRSnJFoqMVcVJwIAJNql7hA AgAA
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 08:48:51 -0000

Roman Shpount skrev den 2015-06-04 23:02:
> On Wed, Jun 3, 2015 at 4:06 PM, Harald Alvestrand <
> <>> 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.

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.

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 

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.


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: