Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track

Harald Alvestrand <harald@alvestrand.no> Thu, 18 July 2013 14:51 UTC

Return-Path: <harald@alvestrand.no>
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 5FEAE21E810B for <mmusic@ietfa.amsl.com>; Thu, 18 Jul 2013 07:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.486
X-Spam-Level:
X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7gS5-H76UNS for <mmusic@ietfa.amsl.com>; Thu, 18 Jul 2013 07:51:23 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B4E8E21F94DC for <mmusic@ietf.org>; Thu, 18 Jul 2013 07:51:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DD1939E1C9; Thu, 18 Jul 2013 16:51:05 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UGCpNasL-Qn; Thu, 18 Jul 2013 16:51:03 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A488B39E0FA; Thu, 18 Jul 2013 16:51:03 +0200 (CEST)
Message-ID: <51E800D7.3080207@alvestrand.no>
Date: Thu, 18 Jul 2013 16:51:03 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Belling, Thomas (NSN - DE/Munich)" <thomas.belling@nsn.com>
References: <51E447C8.1000701@nostrum.com> <BDBE1A97E84675488F72A48C23811F351179A4@DEMUMBX001.nsn-intra.net> <51E7F05A.6070401@alvestrand.no> <BDBE1A97E84675488F72A48C23811F351179DE@DEMUMBX001.nsn-intra.net>
In-Reply-To: <BDBE1A97E84675488F72A48C23811F351179DE@DEMUMBX001.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------050403040100090507060703"
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jul 2013 14:51:33 -0000

On 07/18/2013 04:21 PM, Belling, Thomas (NSN - DE/Munich) wrote:
>
> Thanks Harald,
>
> I understand the Media Stream ID and Media Stream Track ID appear in 
> the W3C API.
>
> However, this does not necessarily mean they need to be signaled 
> end-to-end (rather than being only of local significance for the 
> interactions between the JavaScript application and the API, and being 
> mapped to/from some other SDP properties such as the ordinal number of 
> the SDP m-line).
>

Well... if we want to have the same ID attached to the same 
MediaStreamTrack at both ends, the ID has to be carried somehow.

If there's no need for the ID to be the same, we don't need it. But so 
far, I think the consensus in the W3C WG is that it needs to be the same.

> If something important was missing in SDP up to now, we certainly need 
> to add it. But we should not duplicate information. This is what I try 
> to find out. And obviously, requiring mandatory SDP extensions does 
> not simplify interoperability with existing SDP peers.
>

That's why the MSID spec has a section on what to do when you get tracks 
without MSIDs.

> Thomas
>
> *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On 
> Behalf Of *ext Harald Alvestrand
> *Sent:* Thursday, July 18, 2013 3:41 PM
> *To:* mmusic@ietf.org
> *Subject:* Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute 
> and media stream track
>
> On 07/18/2013 03:06 PM, Belling, Thomas (NSN - DE/Munich) wrote:
>
> ...
>
>   
> And do we require an extra identifier for it, in addition of the position (that could also be expressed by an ordinal number in some separate protocol or for cross-referencing within SDP) of the m-line in the SDP?
> I suspect the need for a new identifier of the m-line/media stream track has something to do with partial SDP offers? But could the identifier not still be the ordinal number with respect to the "full" SDP (or the next free number if an m-line is added), and be restricted to partial offers?
>   
>   
> The msid attribute also assings a "media stream ID", but your draft does not describe at all what that ID would be used for.
>
>
> The ID of a WEBRTC MediaStream is defined in 
> http://dev.w3.org/2011/webrtc/editor/getusermedia.html#attributes
>
>   
>   
>