Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0

Cullen Jennings <fluffy@iii.ca> Tue, 12 September 2017 13:52 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE8B13305E for <mmusic@ietfa.amsl.com>; Tue, 12 Sep 2017 06:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level:
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CYRl7H5WkTK7 for <mmusic@ietfa.amsl.com>; Tue, 12 Sep 2017 06:52:57 -0700 (PDT)
Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED0713305D for <mmusic@ietf.org>; Tue, 12 Sep 2017 06:52:57 -0700 (PDT)
Received: from smtp29.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp29.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EC04424F06; Tue, 12 Sep 2017 09:52:53 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp29.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 86FB224E33; Tue, 12 Sep 2017 09:52:53 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 12 Sep 2017 09:52:53 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCADFB5@ESESSMB109.ericsson.se>
Date: Tue, 12 Sep 2017 07:52:52 -0600
Cc: Taylor Brandstetter <deadbeef@google.com>, mmusic WG <mmusic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F7765CFE-01FA-4788-B06F-EBB93C14BE2D@iii.ca>
References: <CAK35n0ZYsjMTGGajpHuzg2_ARvG_V=PMbAPVgWZ9gHu_SMU7BA@mail.gmail.com> <CAK35n0bjyvcBOJBxec2oCkEXRRuGrY-FwhLf4cYXas2HfqB9Hw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4CCADFB5@ESESSMB109.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/J2HQVcTyJsjkk0ViYhGad196U5A>
Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 13:52:58 -0000

> 
> In the current state of WebRTC 1.0, track IDs are not guaranteed to be symmetrical between the sending and receiving PeerConnection. This is because "addTrack" not only creates an RtpSender, but a whole RtpTransceiver, which has an RtpReceiver, which has a MediaStreamTrack with a generated ID. So if "addTrack" is called, and a remote description is set later, it's the MID that correlates the "m=" section with the track, not the track ID, and the track ID in SDP is effectively ignored.

I'm not following the problem here ... yes, webrtc ends up with the track from A to B and B to A having different track IDs but the msid draft clearly allows the offer and answer to have different app data in the MSID line. What's the issue on this?


PS - As side note, I've argued since before 2013 that we did not need to signal track ID in SDP but I think that train left the station long ago and I'd rather not change it at this point. The mostly compelling argument I recall on why we need this was hangouts uses it.