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

Taylor Brandstetter <deadbeef@google.com> Fri, 21 July 2017 01:42 UTC

Return-Path: <deadbeef@google.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D91AC131C03 for <mmusic@ietfa.amsl.com>; Thu, 20 Jul 2017 18:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ru1sqe_bCUD7 for <mmusic@ietfa.amsl.com>; Thu, 20 Jul 2017 18:42:00 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A627126D73 for <mmusic@ietf.org>; Thu, 20 Jul 2017 18:42:00 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id r14so564709qte.4 for <mmusic@ietf.org>; Thu, 20 Jul 2017 18:42:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rIRQzhJqqRkr11aIFMYn9M1ML+fgv/0rpJ4HB5yoeMw=; b=jH+MupyTSu9SHcRGGDhdI3grC+2TmLoEJPZJtVPBWIVuunZaIukHJ33/Yef9+uIWtz YvGUmNaiIh/2g7g6DH7bNGetpvzJn8wqwR4dPl5Y/D6sAfk6OxUvEHIJmcV11W4U/crC eEYNMWeaHYqgpLXIlOi95ucWzBMSBQZABt/YF5lJ2JvneL5bBi2fd4DmKA95CZ1SdNQe Dnxa510QDwUd4al7+6cvr+c1ZkChg0Lc8TQQaLr4y7qvrBOlAaA+DZCyJzd0J7O+Jmdg xxMKMfLqbWvJyNWFLYfPvYTA3y175OEVaBJkFGK/wSHq6mHSWml5WCqaPFxPKgi0dUsh Cfsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rIRQzhJqqRkr11aIFMYn9M1ML+fgv/0rpJ4HB5yoeMw=; b=HKTnmapPBYFtMSs6G4qH/Tor1FPsBMdNWbv/O+50tibDJHK/fOD9HuEDTwNp/JgR+h bIDGuuolURAlNP1zEMqb4N/xUVf0A/tcT9bFSUa0imo0HQK+WxYe2FagxfLYSaoRxWgS QgSRB63f/i4lcIHcz5AslCrVWHmuji99Q6LZ+BomuMzPhVkVa1jqc8qCCvjj4i7nkglD 0awh3fKRgtfPmlNGAKRe8WNzN9niiol9Ji8Oc3bKAtqcZ9JJn9pTaWHK/BR4lyF1nGwG mnWZWfMfV+p3cl54DoQrvOZRtjr20pSpcEkGSH1RPocW9Tml5qGwFjSnZsnsjFRbpjXA J+zA==
X-Gm-Message-State: AIVw1132o46mYoIrr/cPNrbOot+DsSE23RG9020AhcheN5obu03ORXvv 4dkvu0ZorxIvUHHyoHlpYlyDfJAmahw+siF8dQ==
X-Received: by with SMTP id x32mr1151017qtx.223.1500601319182; Thu, 20 Jul 2017 18:41:59 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 20 Jul 2017 18:41:58 -0700 (PDT)
From: Taylor Brandstetter <deadbeef@google.com>
Date: Thu, 20 Jul 2017 18:41:58 -0700
Message-ID: <CAK35n0ZYsjMTGGajpHuzg2_ARvG_V=PMbAPVgWZ9gHu_SMU7BA@mail.gmail.com>
To: mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="001a113ad8ec94c7fb0554c9f84a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/TSVtuizf99OXiKgi9k2x17STnK0>
Subject: [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: Fri, 21 Jul 2017 01:42:02 -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.

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: https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/

So, the question became "why signal track IDs at all?" This was brought up
in a May virtual interim (https://www.w3.org/2011/04/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: https://w3c.github.io/webrtc-pc/archives/20160722/webrtc.html