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

"Belling, Thomas (NSN - DE/Munich)" <thomas.belling@nsn.com> Thu, 18 July 2013 15:18 UTC

Return-Path: <thomas.belling@nsn.com>
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 32FA621E8108 for <mmusic@ietfa.amsl.com>; Thu, 18 Jul 2013 08:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.448
X-Spam-Level:
X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 iRGRfT1Te0zn for <mmusic@ietfa.amsl.com>; Thu, 18 Jul 2013 08:18:31 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1B921E80F5 for <mmusic@ietf.org>; Thu, 18 Jul 2013 08:18:30 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6IFIPGK024936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Jul 2013 17:18:25 +0200
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6IFIP0l027215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 17:18:25 +0200
Received: from DEMUHTC015.nsn-intra.net (10.159.42.46) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 18 Jul 2013 17:18:24 +0200
Received: from DEMUMBX001.nsn-intra.net ([169.254.1.212]) by DEMUHTC015.nsn-intra.net ([10.159.42.46]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 17:18:24 +0200
From: "Belling, Thomas (NSN - DE/Munich)" <thomas.belling@nsn.com>
To: ext Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track
Thread-Index: AQHOg7eYiqJibBkYeUq8/d0kMSi315lqhQeDgAACXAA=
Date: Thu, 18 Jul 2013 15:18:24 +0000
Message-ID: <BDBE1A97E84675488F72A48C23811F35117A17@DEMUMBX001.nsn-intra.net>
References: <51E447C8.1000701@nostrum.com> <BDBE1A97E84675488F72A48C23811F351179A4@DEMUMBX001.nsn-intra.net> <51E7F05A.6070401@alvestrand.no> <BDBE1A97E84675488F72A48C23811F351179DE@DEMUMBX001.nsn-intra.net> <51E800D7.3080207@alvestrand.no>
In-Reply-To: <51E800D7.3080207@alvestrand.no>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.97]
Content-Type: multipart/alternative; boundary="_000_BDBE1A97E84675488F72A48C23811F35117A17DEMUMBX001nsnintr_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 16942
X-purgate-ID: 151667::1374160705-00002EAE-2BB55662/0-0/0-0
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 15:18:36 -0000

That is where my confusion starts:
The MSID draft, and also your related backward compatibility procedures, assumes that multiple tracks can be described by one m-line.
This is no longer true.

For the MediaStreamTrack ID, I still suspect that a standardized mapping to m-line ordinal numbers could now be sufficient to have the same IDs at both sides


For the MediaStream, the API description says:
Each MediaStream<http://dev.w3.org/2011/webrtc/editor/getusermedia.html#idl-def-MediaStream> object can contain zero or more tracks, in particular audio and video tracks. All tracks in a MediaStream are intended to be synchronized when rendered. Different MediaStreams do not need to be synchronized.

This sounds like a lipsynch group in SDP.
The group name can then serve as MediaStrem ID.  Each m-line outside such a group would probably have a separate MediaStream,  and the m-line ordinal number could then serve as MediaStream ID.



From: ext Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, July 18, 2013 4:51 PM
To: Belling, Thomas (NSN - DE/Munich)
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track

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> [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Harald Alvestrand
Sent: Thursday, July 18, 2013 3:41 PM
To: mmusic@ietf.org<mailto: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