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

Harald Alvestrand <> Wed, 03 June 2015 20:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0B0561A7028 for <>; Wed, 3 Jun 2015 13:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l920UxJV92nR for <>; Wed, 3 Jun 2015 13:06:56 -0700 (PDT)
Received: from ( [IPv6:2001:700:1:2::117]) by (Postfix) with ESMTP id 789761A0282 for <>; Wed, 3 Jun 2015 13:06:56 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A1CD7C0951 for <>; Wed, 3 Jun 2015 22:06:55 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X6h58Z4pg7B8 for <>; Wed, 3 Jun 2015 22:06:53 +0200 (CEST)
Received: from (unknown [IPv6:2620:0:1043:1:e536:c983:6fc4:1d46]) by (Postfix) with ESMTPSA id 3E4577C0950 for <>; Wed, 3 Jun 2015 22:06:53 +0200 (CEST)
Message-ID: <>
Date: Wed, 03 Jun 2015 22:06:52 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
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: Wed, 03 Jun 2015 20:06:59 -0000

On 06/03/2015 02:37 PM, Magnus Westerlund wrote:
> Hi,
> I want raise for discussion the fact that I think JSEP does not handle 
> RTP payload type switching as currently specified.
> So lets walk through a case of RTP payload type switching and what it 
> means according to the specifications we do have.
> So we have an established PeerConnection with one audio track for 
> which we have negotiated the possibility to send both PCM and OPUS. If 
> the sender decides to switch RTP payload type, lets say from OPUS to 
> PCM. The reason is actually not important, but lets say due to a 
> "replace track" API call as currently being discussed on W3C WebRTC 
> group.
> When that RTP payload type switch from OPUS to PCM we also have an RTP 
> timestamp rate change, from 48 kHz to 8 kHz. As specified in RTP usage 
> (Section 4.3):
>    If performing changes between two RTP payload types that use
>    different RTP clock rates, an RTP sender MUST follow the
>    recommendations in Section 4.1 of [RFC7160].
> So lets look at what RFC 7160 says:
> 4.1.  RTP Sender (with RTCP)
>    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.
> Thus, this Payload type change forces the use of a new SSRC.
> This in itself should not be a significant issue. The binding to the 
> right media block in the SDP is done using MID. Which, will be sent in 
> an RTP header extension to ensure that stream upon reception is 
> correctly associated. The RTP synchronization information will arrive 
> in RTCP or even in the RTP header extension if the peers both supports 
> RFC 6051. Thus minimal media impacts is to be expected.
> But, discussing what happens in this case with Stefan Håkansson we did 
> look into JSEP. And here we clearly have some short commings in the 
> specification.
> A. First of all there is an assumption that the value of a=ssrc will 
> not change. For example Section 5.2.2 (Subsequent Offers):
>   o  For MediaStreamTracks that are still present, the "a=msid",
>       "a=ssrc", and "a=ssrc-group" lines MUST stay the same.
> If an RTP payload type switching has occured that forces a SSRC change 
> then I expect that the actually used SSRCs are included in the offer. 
> Thus, both a=ssrc and a=ssrc-group can change in subsequent offers.

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.

> B. The next question is if a RTP payload type change actually requires 
> the node that performs the change to actually initiate an Offer/answer 
> exchange to update their a=ssrc values?
> Clearly JSEP needs to be updated to address these issues.
> Cheers
> 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:
> ----------------------------------------------------------------------
> _______________________________________________
> rtcweb mailing list