IETF Logo Mail Archive

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 14:21 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 3CBA921E8101 for <mmusic@ietfa.amsl.com>; Thu, 18 Jul 2013 07:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 2g3XbxFuZbV8 for <mmusic@ietfa.amsl.com>; Thu, 18 Jul 2013 07:21:19 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 04FCA11E80E3 for <mmusic@ietf.org>; Thu, 18 Jul 2013 07:21:17 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6IELDhf011497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Jul 2013 16:21:14 +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 r6IELDG7026666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 16:21:13 +0200
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 18 Jul 2013 16:21:13 +0200
Received: from DEMUMBX001.nsn-intra.net ([169.254.1.212]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 16:21:13 +0200
From: "Belling, Thomas (NSN - DE/Munich)" <thomas.belling@nsn.com>
To: ext Harald Alvestrand <harald@alvestrand.no>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track
Thread-Index: AQHOg7eYiqJibBkYeUq8/d0kMSi315lqT9QAgAAmLvA=
Date: Thu, 18 Jul 2013 14:21:13 +0000
Message-ID: <BDBE1A97E84675488F72A48C23811F351179DE@DEMUMBX001.nsn-intra.net>
References: <51E447C8.1000701@nostrum.com> <BDBE1A97E84675488F72A48C23811F351179A4@DEMUMBX001.nsn-intra.net> <51E7F05A.6070401@alvestrand.no>
In-Reply-To: <51E7F05A.6070401@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_BDBE1A97E84675488F72A48C23811F351179DEDEMUMBX001nsnintr_"
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: 9434
X-purgate-ID: 151667::1374157274-000017BA-0BAC7E10/0-0/0-0
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:21:37 -0000

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).

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.

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

v2.23.0 | Report a Bug | By Email