Re: [rtcweb] No Plan

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 03 June 2013 21:50 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B5821F90A5 for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.063
X-Spam-Level:
X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1]
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 eqMjNdyFSj+Z for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:50:28 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 19D4A11E8126 for <rtcweb@ietf.org>; Mon, 3 Jun 2013 14:48:09 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id jnS91l0021c6gX858xo9qc; Mon, 03 Jun 2013 21:48:09 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id jxo91l0053ZTu2S3jxo97G; Mon, 03 Jun 2013 21:48:09 +0000
Message-ID: <51AD0F18.5020202@alum.mit.edu>
Date: Mon, 03 Jun 2013 17:48:08 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Emil Ivov <emcho@jitsi.org>
References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, <51A9A7E2.7000907@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se> <51ACFF31.9090607@alum.mit.edu> <51AD0D98.2080302@jitsi.org>
In-Reply-To: <51AD0D98.2080302@jitsi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370296089; bh=qrrgppz4EW9M2ZTnu5Dw+N3a6wYAYD/vZSZ9b490qe8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DET+jqKyd3YnTO048hMnQTNku02ZxnLCmvH7k0R9p4wigoC46zzycAmrQdEJImbs1 0boE9zxc69mce5yAa853KPO2MeLlpos8pc1gAAuHKuW5JDE02LnU9wYLNCN2Dsl2Xr xz7N/SGaRtRL6lauGaxlFDknY7WtvwdCPwxXHq3bsFPXMFFGe35BXUi+SGdBmz9zT5 uOMhe04AwsfvfnfxRwDmLV1rk/03N50OguBC+p7KORPf+u4aRPn5kh2L/ev8JU9uku EIjir6EKnHQkxMdrt2o/CNz4Qbw0VCcozAO63sheS0q3UGQ2wMQCQwPOEPE/JAaKM5 DuIg0RI4ErPSg==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No Plan
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2013 21:50:51 -0000

On 6/3/13 5:41 PM, Emil Ivov wrote:
>
>
> On 03.06.13, 23:40, Paul Kyzivat wrote:
>> +1
>>
>> The more we dig into this the more it looks like Plan B.
>
> I am not sure exactly what you mean by this. I did try to make it clear
> that "No Plan" has a lot in common with "Plan B". The main differences
> are that there is no expectation for SSRCs to be pre-announced and there
> are requirements for WebRTC APIs to provide the tools necessary for apps
> to control individual streams themselves.

I now think that it is enough like plan B that the two should be 
collapsed together. Make the signaling of the explicit SSRCs optional 
when there is some other mechanism to agree upon them.

	Thanks,
	Paul

> Emil
>
>>
>>     Thanks,
>>     Paul
>>
>> On 6/1/13 7:05 AM, Christer Holmberg wrote:
>>>
>>> Hi,
>>>
>>>>> The draft says:
>>>>>
>>>>>         "For the sake of interoperability this specification
>>>>> strongly advises
>>>>>         against the use of multiple m= lines for a single media type."
>>>>
>>>> This should probably be clarified. The above referred mostly to a
>>>> browser's expectations and default offers. Multiple m= lines can
>>>> confuse
>>>> a number of existing legacy endpoints which is why they should be
>>>> avoided when initiating a session that could reach a similar device
>>>> (and
>>>> by default this should be assumed for any session).
>>>>
>>>> If applications *know* that they need to have multiple m= lines of a
>>>> given type they can request this the same way they could do it with
>>>> Plan B:
>>>>
>>>>      If the application wishes, it can request that a given
>>>>      media source be placed onto a separate m= line, by setting a new
>>>>      .content property on the desired MediaStreamTrack; the values
>>>> for the
>>>>      .content property are those defined for the a=content attribute in
>>>>      [RFC4796].
>>>>
>>>> I'll make sure this is part of the next version.
>>>>
>>>> Does this make sense?
>>>
>>> I have nothing against a general recommendation to, for a given media
>>> type, have as few m- lines as possible.
>>>
>>> But, I do think the draft need to point out that it is not always
>>> possible, e.g. because:
>>>
>>> 1) m- lines have different characteristics (normally indicated using
>>> SDP attributes) that does not "fit" all content for the given media
>>> type;
>>> 2) different protocols are used for different m- lines, even if the
>>> media type is the same; or
>>> 3) the remote endpoint only supports a single (or, another given
>>> number) of sources per m- line.
>>>
>>> Etc.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>>> My understanding is that the usage of multiple m= lines for a single
>>>> media type would not affect the mechanism as such, but I just want
>>>> to verify that :)
>>>>
>>>> Also, there ARE "legacy" implementations that use multiple m= lines
>>>> for a single media type (e.g. video enabled devices using two video
>>>> m= lines: one for camera content, and one for slides).
>>>>
>>>> So, while I definitely think that legacy interoperability shall be
>>>> taken into consideration, I would not like to make such strong
>>>> statements. In my opinion (the draft also talks about it), the usage
>>>> of multiple simultaneous SSRCs per m- line is a much bigger issue
>>>> when it comes to legacy interoperability.
>>>>
>>>> Also, in CLUE we have been working on signaling scenarios with
>>>> multiple m= lines per media type.
>>>    >
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>>>> Behalf Of Emil Ivov
>>>> Sent: 29. toukokuuta 2013 22:00
>>>> To: rtcweb@ietf.org
>>>> Subject: [rtcweb] No Plan
>>>>
>>>> Hey all,
>>>>
>>>> Based on many of the discussions that we've had here, as well as
>>>> many others that we've had offlist, it seemed like a good idea to
>>>> investigate a negotiation alternative that relies on SDP and
>>>> Offer/Answer just a little bit less.
>>>>
>>>> The following "no plan" draft attempts to present one such approach:
>>>>
>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
>>>>
>>>> The draft relies on conventional use of SDP O/A but leaves the
>>>> intricacies of multi-source scenarios to application-specific
>>>> signalling, with potentially a little help from RTP.
>>>>
>>>> Hopefully, proponents of Plans A and B would find that the
>>>> interoperability requirements that concerned them can still be met
>>>> with "no plan". Of course they would have to be addressed by
>>>> application-specific signalling and/or signalling gateways.
>>>>
>>>> Comments are welcome!
>>>>
>>>> Cheers,
>>>> Emil
>>>>
>>>> --
>>>> https://jitsi.org
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>> .
>>>>
>>>
>>> --
>>> https://jitsi.org
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>