[MMUSIC] MSID and mapping to tracks and streams

Martin Thomson <martin.thomson@gmail.com> Thu, 11 December 2014 18:51 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BD01A6F01 for <mmusic@ietfa.amsl.com>; Thu, 11 Dec 2014 10:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level:
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 iwG4KtpX7UIp for <mmusic@ietfa.amsl.com>; Thu, 11 Dec 2014 10:51:06 -0800 (PST)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFC01A701C for <mmusic@ietf.org>; Thu, 11 Dec 2014 10:50:55 -0800 (PST)
Received: by mail-oi0-f54.google.com with SMTP id u20so4097208oif.41 for <mmusic@ietf.org>; Thu, 11 Dec 2014 10:50:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SPAga5r5qEI33Rh80Z+ecj6Yixg2ZvrwU0ZuU8qAJGw=; b=B/9bulgXLRw8m3X5PcdOeWveJL67nWBeSxJdCx6xqGGyEqxljDFeRda2mlUz/2nZD1 LYzxoEFCnoViXPo2iT3zDC608u3GzCST3rnLdhSR2o9/gtvMqTY2uT0ZvHivcYi+wdOp ijSBZvHJMP1KzkiSZnlVATwGiK2hfTzyjZdy9G8FwVrgdAtzJGTEUEiT1iSDqH/LaucN K++qqYYoBUr4NYXNf2GOVNgkOAoDVXISrAiyMEfn9g+eTV+kh9Il8CHwd9iRFp9BEf5N ChMnErD5PXRX7NejgumwGUN+9yAeLZXi5Hujj/SXZTZaChDBcD1JCMxRbjaZQHaEu4mw f+vg==
MIME-Version: 1.0
X-Received: by 10.182.97.66 with SMTP id dy2mr7393041obb.30.1418323854920; Thu, 11 Dec 2014 10:50:54 -0800 (PST)
Received: by 10.202.107.19 with HTTP; Thu, 11 Dec 2014 10:50:54 -0800 (PST)
Date: Thu, 11 Dec 2014 10:50:54 -0800
Message-ID: <CABkgnnWsHWuc=bnVWkYj0W1Lkpkn88sOaDESDBvEjoGF7wruqg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8ruynsuWc8UZA2bC3WijlRE6vfo
Subject: [MMUSIC] MSID and mapping to tracks and streams
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 11 Dec 2014 18:51:08 -0000

   The value of the "identifier" field in the msid consists of the "id"
   attribute of a MediaStream, as defined in its WebIDL specification.

   The value of the "appdata" field in the msid consists of the "id"
   attribute of a MediaStreamTrack, as defined in its WebIDL
   specification.

I think that this is backwards. The media section (m=) corresponds to
a track, not a stream.  The MediaStream is the secondary identifier.

I'd have thought that this was merely personal bias, until I read this:

   The identifier is a string of ASCII characters that are legal in a
   "token", consisting of between 1 and 64 characters.  It MUST be
   unique among the identifier values used in the same SDP session.  It
   is RECOMMENDED that it is generated using a random-number generator.

This rule, as specified and in combination with the aforementioned,
would absolutely prevent the use of multiple tracks from the same
stream (i.e., the most common case in existence).

Also, this is mightly confusing to me:

   [...]  Once negotiation has completed on a
   session, there is no memory apart from the currently valid SDP
   descriptions; an msid "identifier" value that appears in a later
   negotiation will be taken to refer to a new MediaStream.

I have no idea what this might be saying.  I can imagine a whole lot
of things that might be said here: "a track (not stream) that is bound
to a given media section is unaffected by changes in the msid values
in that media section during renegotiation" or "a track on the sending
side that is bound to a media section, then subsequently swapped out
(see replaceTrack) for another, MAY cause the msid values to change in
subsequent renegotiations, but this does not result in action from the
receiving side".