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

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 03 June 2015 12:37 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 960E91A8777 for <rtcweb@ietfa.amsl.com>; Wed, 3 Jun 2015 05:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id pZ3XHzuhpSDV for <rtcweb@ietfa.amsl.com>; Wed, 3 Jun 2015 05:37:30 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35041A8775 for <rtcweb@ietf.org>; Wed, 3 Jun 2015 05:37:29 -0700 (PDT)
X-AuditID: c1b4fb3a-f79ec6d000006dc0-9c-556ef5079b22
Received: from ESESSHC021.ericsson.se (Unknown_Domain []) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 44.3E.28096.705FE655; Wed, 3 Jun 2015 14:37:27 +0200 (CEST)
Received: from [] ( by smtp.internal.ericsson.com ( with Microsoft SMTP Server id; Wed, 3 Jun 2015 14:37:13 +0200
Message-ID: <556EF4F9.1060700@ericsson.com>
Date: Wed, 03 Jun 2015 14:37:13 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCJMWRmVeSWpSXmKPExsUyM+JvrS7717xQg4/3ZSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqnOi6wFeyUqpu69wtjAuFi4i5GTQ0LARGLN5LksELaYxIV7 69m6GLk4hASOMkr039zNBJIQEljGKPHssyGIzSugLXH5xgH2LkYODhYBFYnp/RkgYTYBC4mb PxrZQGxRgSiJqY/XsUCUC0qcnPkEzBYRUJe4/PACO4gtLOAgMWv9BhaQMcwC9hIPtpaBhJkF 5CWat85mhtiqLdHQ1ME6gZFvFpJJsxA6ZiHpWMDIvIpRtDi1uDg33chIL7UoM7m4OD9PLy+1 ZBMjMJgObvlttYPx4HPHQ4wCHIxKPLwL4/NChVgTy4orcw8xSnOwKInzztgMFBJITyxJzU5N LUgtii8qzUktPsTIxMEp1cDI1PprRsiqe0capr96sr976YcP+ju/pTxnM7QISK2Yxu1056QB w7To94u2HdxxX/xXJ5ecPufr3JdCxbsj3zDf03yfHe3KPyEiaL2KIOOjSSe0pBNW6Tx0rmTR sS5v/yj1qD7GJjtHzZjBNepUSEVR1Ksj3x7NCXA4/uVPrTT/0fN+XdPCutKUWIozEg21mIuK EwGhnUmYBwIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/oOT7uAQrrj9YSJmrS1kNiXKNODg>
Subject: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 12:37:31 -0000


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 

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.

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.


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: magnus.westerlund@ericsson.com