Re: [MMUSIC] Unified Plan for SDP Handling
Adam Roach <adam@nostrum.com> Wed, 17 July 2013 20:23 UTC
Return-Path: <adam@nostrum.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 85E4A21F99F1 for <mmusic@ietfa.amsl.com>; Wed, 17 Jul 2013 13:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.396
X-Spam-Level:
X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, 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 j0gu7viYJceC for <mmusic@ietfa.amsl.com>; Wed, 17 Jul 2013 13:23:55 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 45C5D21F99FC for <mmusic@ietf.org>; Wed, 17 Jul 2013 13:23:51 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6HKNiU5069468 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 15:23:45 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51E6FD4B.3030200@nostrum.com>
Date: Wed, 17 Jul 2013 15:23:39 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
References: <51E447C8.1000701@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3182B8@ESESSMB209.ericsson.se>
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C3182B8@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Unified Plan for SDP Handling
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: Wed, 17 Jul 2013 20:23:55 -0000
On 7/17/13 09:08, Stefan Håkansson LK wrote: > I have a couple of specific questions/comments, coming from a very > WebRTC centric (sorry for that) perspective: > > * Simulcast: In the current API model, MediaStreamTrack is about the > lowest you can get to. And the same source (camera, microphone) can > source several MediaStreamTrack - and each of those can use individual > constraints for width, height, framerate, etc. So in a WebRTC context, > there seem to me we would not need the simulcast solution you have > included. The different resolutions can be sent as different > MediaStreamTrack's - meaning they would be separate m-lines. That's what we meant to convey with this (section 2, bullet 1): "This does not preclude 'application level' simulcasting; i.e., the creation of multiple media stream tracks from a single source." It's true that we don't broach the issue of how to indicate the need for simulcast via a WebRTC javascript API. I think this is something that would be future work, probably in the W3C. I'm going to leave any further explanation to Justin, as most of the simulcast ideas in the document came from him. > * Direction attribute: The current WebRTC API is "sender" oriented: the > application can select MediaStream(Track)'s to send. Would it for WebRTC > make sense to have all m-lines being unidirectional (send/recvonly)? I understand how this makes things cleaner in general. The issue I have is that it interacts poorly with legacy uses. > (If > they should be sendrecv we also need to specify when a return track > should reuse an existing m-line, and when a new m-line should be created.) > I agree that this could stand to be spelled out more clearly. I do not think that doing so will prove particularly controversial. /a
- Re: [MMUSIC] Unified Plan for SDP Handling Jonathan Lennox
- [MMUSIC] Unified Plan for SDP Handling Adam Roach
- Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handli… Roman Shpount
- Re: [MMUSIC] Unified Plan for SDP Handling Roni Even
- Re: [MMUSIC] Unified Plan for SDP Handling Adam Roach
- Re: [MMUSIC] Unified Plan for SDP Handling Bernard Aboba
- Re: [MMUSIC] Unified Plan for SDP Handling Emil Ivov
- Re: [MMUSIC] Unified Plan for SDP Handling Bernard Aboba
- Re: [MMUSIC] Unified Plan for SDP Handling Roni Even
- Re: [MMUSIC] Unified Plan for SDP Handling Stefan Håkansson LK
- Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handli… Paul Kyzivat
- Re: [MMUSIC] Unified Plan for SDP Handling Jonathan Lennox
- Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handli… Adam Roach
- Re: [MMUSIC] Unified Plan for SDP Handling Adam Roach
- Re: [MMUSIC] Unified Plan for SDP Handling - msid… Belling, Thomas (NSN - DE/Munich)
- Re: [MMUSIC] Unified Plan for SDP Handling - msid… Harald Alvestrand
- Re: [MMUSIC] Unified Plan for SDP Handling - msid… Belling, Thomas (NSN - DE/Munich)
- Re: [MMUSIC] Unified Plan for SDP Handling - msid… Harald Alvestrand
- Re: [MMUSIC] Unified Plan for SDP Handling - msid… Belling, Thomas (NSN - DE/Munich)
- Re: [MMUSIC] Unified Plan for SDP Handling Bernard Aboba
- Re: [MMUSIC] Unified Plan for SDP Handling Justin Uberti
- Re: [MMUSIC] Unified Plan for SDP Handling Cullen Jennings
- Re: [MMUSIC] Unified Plan for SDP Handling Cullen Jennings
- Re: [MMUSIC] Unified Plan for SDP Handling Jonathan Lennox
- Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handli… Matt Fredrickson
- Re: [MMUSIC] Unified Plan for SDP Handling Stefan Håkansson LK