Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching
Harald Alvestrand <harald@alvestrand.no> Wed, 03 June 2015 20:06 UTC
Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0561A7028 for <rtcweb@ietfa.amsl.com>; Wed, 3 Jun 2015 13:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l920UxJV92nR for <rtcweb@ietfa.amsl.com>; Wed, 3 Jun 2015 13:06:56 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 789761A0282 for <rtcweb@ietf.org>; Wed, 3 Jun 2015 13:06:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8A1CD7C0951 for <rtcweb@ietf.org>; Wed, 3 Jun 2015 22:06:55 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6h58Z4pg7B8 for <rtcweb@ietf.org>; Wed, 3 Jun 2015 22:06:53 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:e536:c983:6fc4:1d46]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3E4577C0950 for <rtcweb@ietf.org>; Wed, 3 Jun 2015 22:06:53 +0200 (CEST)
Message-ID: <556F5E5C.5080600@alvestrand.no>
Date: Wed, 03 Jun 2015 22:06:52 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <556EF4F9.1060700@ericsson.com>
In-Reply-To: <556EF4F9.1060700@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/yiIOmeDroHMkA_jDAHCP5daxXc4>
Subject: Re: [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 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: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] JSEP: Issues with a=ssrc and RTP payload… Magnus Westerlund
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Bernard Aboba
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Harald Alvestrand
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Roman Shpount
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Magnus Westerlund
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Harald Alvestrand
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Magnus Westerlund
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Simon Perreault
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Magnus Westerlund
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Simon Perreault
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Harald Alvestrand
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Simon Perreault
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Harald Alvestrand
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Magnus Westerlund
- Re: [rtcweb] JSEP: Issues with a=ssrc and RTP pay… Christer Holmberg