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

Taylor Brandstetter <> Thu, 27 July 2017 00:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30940131F0D for <>; Wed, 26 Jul 2017 17:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RqH93E3BddDP for <>; Wed, 26 Jul 2017 17:23:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0756B131F0A for <>; Wed, 26 Jul 2017 17:23:17 -0700 (PDT)
Received: by with SMTP id p3so53243895qtg.2 for <>; Wed, 26 Jul 2017 17:23:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7NEgK1ZmaIBNVknTHdFHHE/4RN/mJQWmJmC4PsJXBi4=; b=OV8zm06ZykgecuFc4Or7fP16hD0JV8JkGxOcMRD81bqkj72XMWw7MVvaeCgGWrpSYN FaAHV+2V0VnS9FXGK0xyBPa8hhUkydpY07aIQek19qv6h7nvLk1QJYtajVrRMMTf+uuJ +ZVWTx1awn+gb41a2On6T4ekcr0O9ngWf4vsve2hsGFLSV81IgSpsZIiRYL20F+AE7Tu U31ICeqJ+kYxTl808uDietaR0cu/1Yl1Figvfpiu3y4+ZduphXkge3EtNEC4+9NVVDTi 61DWn/PeXhuCwQEmVEFX7eIn1lMX1sOArG4NW0lTn8B6m7c7Y2NBqW1E7h/RIweRiHkA fyag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7NEgK1ZmaIBNVknTHdFHHE/4RN/mJQWmJmC4PsJXBi4=; b=iz/OJln1F+ndIhKgi1AUGcbqvs0QmJ64Osv6OJLdWy2t2o3pk8iu/ubol/risVofrK Qj6S5TMk55tY0BVaUr6bruqQCguYLfOjo+W0ODxcC8FB1wG/X8IMiF2huEBQEfQPZhmY GwnkaFc26qmIv3f3vTbCLMUCv/ZVincykp7OTXalO6g/t8Z2xqKAe0iTAH6h+XY3hWEo pkzDeuPs5Ru5XKG/vp0rTzq3QVzEtWCt/QZ9KS5G94ut4hOlouRJA8Wsvz/lr1cTqpDZ 5W9DtzUe1MFNUwBpKrk6v97aZl1hRssjYs7LYHYEWajtNfuHNbCdJS802g8INqMPxcGX MBPA==
X-Gm-Message-State: AIVw112gfZIFLolo8qtbvaNdjJoZD99MXYOhmN0G64MVnfbZM92h57ZR j4hVI6mZVdnFGUekRCPPMKyfXdI6KOUcLvw=
X-Received: by with SMTP id v33mr3930669qtb.67.1501114995933; Wed, 26 Jul 2017 17:23:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 26 Jul 2017 17:23:15 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Taylor Brandstetter <>
Date: Wed, 26 Jul 2017 17:23:15 -0700
Message-ID: <>
To: mmusic WG <>
Content-Type: multipart/alternative; boundary="001a1143b9281a0afc055541924c"
Archived-At: <>
Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Jul 2017 00:23:19 -0000

Ping. Harald (the author of this document) is on sabbatical, so I'd
appreciate some guidance from someone else familiar with IETF processes.
It's already in the RFC editor queue, which seems like a problem.

On Thu, Jul 20, 2017 at 6:41 PM, Taylor Brandstetter <>

> 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.
> This is all related to the "early media" functionality, and is explained
> further in a blog post by Jan-Ivar; see the "Correlate by transceiver.mid"
> section:
> So, the question became "why signal track IDs at all?" This was brought up
> in a May virtual interim (
> webrtc/wiki/May_2_2017), and we decided to investigate removing them. To
> my knowledge this topic hasn't been brought up on this mailing list yet.
> Is this something still worth considering, or is it too late? "a=msid"
> would switch to only containing the stream ID, not the track ID.
> Implementers would presumably have a transitional period where they support
> parsing both forms of "a=msid", after which they start generating the new
> format, as we've done for other things.
> The benefits are that the SDP would be slightly smaller, and the
> complexity of the standards could be slightly reduced. The downside is that
> more applications that rely on track IDs would need to be updated (though
> many will need to be updated anyway).
> Regardless of the outcome of this decision, "mmusic-msid" really ought to
> be updated before publication. It's been out of sync with WebRTC 1.0 for
> about a year; here's the first editor's draft that broke the track ID
> symmetry: