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