Re: [rtcweb] No Plan

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 04 June 2013 14:11 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 4C10A21F9AC9 for <rtcweb@ietfa.amsl.com>; Tue, 4 Jun 2013 07:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.575
X-Spam-Level:
X-Spam-Status: No, score=-5.575 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_17=0.6, 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 x33-sdScD+96 for <rtcweb@ietfa.amsl.com>; Tue, 4 Jun 2013 07:10:51 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2D40321F9CEE for <rtcweb@ietf.org>; Tue, 4 Jun 2013 05:35:13 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d6d000003d54-b5-51addeffb41b
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D5.AA.15700.FFEDDA15; Tue, 4 Jun 2013 14:35:11 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Tue, 4 Jun 2013 14:35:11 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Emil Ivov <emcho@jitsi.org>
Thread-Topic: [rtcweb] No Plan
Thread-Index: AQHOXJ6w4pPZWNQxOUWhx5DufiT5nZkdWAeQgAMGtQCAAFWpzoADpfOAgAARKwCAAAHKAIABGQng
Date: Tue, 04 Jun 2013 12:35:10 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38275A@ESESSMB209.ericsson.se>
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> <51AD0F18.5020202@alum.mit.edu>
In-Reply-To: <51AD0F18.5020202@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvre7/e2sDDX6eNbdYs3MCi8WKDQdY Ldb+a2d3YPb4+/4Dk8eSJT+ZPP6/CQxgjuKySUnNySxLLdK3S+DK+PJzN2PBFJ2Kvn3NrA2M t5W7GDk5JARMJC4f7GODsMUkLtxbD2RzcQgJHGaUmL5uLTtIQkhgMaPEgQnaXYwcHGwCFhLd /8BMEQFXiXnPFEEqmAXUJe4sPgdWLSwgK7Fl8gwmEFtEQE7i+s99bBB2lMSHFSfAbBYBFYlp z78zg9i8Ar4SmyZcZIFYu5FJ4l73G0aQBKeAjsS8HXfBbEag276fWsMEsUxc4taT+UwQNwtI LNlznhnCFpV4+fgfK8htEgKKEsv75SDKdSQW7P7EBmFrSyxb+Bpqr6DEyZlPWCYwis1CMnUW kpZZSFpmIWlZwMiyipE9NzEzJ73ccBMjMGIObvmtu4Px1DmRQ4zSHCxK4rx6vIsDhQTSE0tS s1NTC1KL4otKc1KLDzEycXBKNTCqL489cHmK48Ov3RI/OecvZmSXWXg7/2bP0anC9fqmfh3L 0zaqtbExL/5Xrbo9Qpyvk8nmYfWRlXcWngmWq38i/HO24yulj1fv+hTqHt/Gzl5+flV3xOIJ Tf9cT397E9msob+1JfoU78pHK1WM29eteX7pwNwPFecUPoeULP+74ay1ZemPPxv8lViKMxIN tZiLihMBP0kQpWYCAAA=
Cc: "rtcweb@ietf.org" <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: Tue, 04 Jun 2013 14:11:06 -0000

Hi,

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

When you say "signaling", do you refer to what is sent on the wire?

As others have said, we still need API support to control things - no matter whether it's done using SDP or some other mechanism.

Regards,

Christer


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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb