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
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Richard Barnes
- Re: [rtcweb] No Plan Cullen Jennings
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Martin Thomson
- [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Mary Barnes
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan - PT based MUX Cullen Jennings
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- Re: [rtcweb] No Plan Mark Rejhon
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- [rtcweb] RTT (was Re: No Plan) Matthew Kaufman
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Matthew Kaufman
- Re: [rtcweb] RTT (was Re: No Plan) Paul Kyzivat
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was Re: No Plan) Gunnar Hellstrom
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Barry Dingle
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- [rtcweb] Translating Plan A into No Plan (Was: No… Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Eric Rescorla
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] Translating Plan A into No Plan (Was… Martin Thomson
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] RTT (was :No Plan ) Paul Kyzivat
- Re: [rtcweb] No Plan - but what's the proposal Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Jonathan Lennox
- Re: [rtcweb] No Plan Jim Barnett
- Re: [rtcweb] Translating Plan A into No Plan (Was… Roni Even
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- [rtcweb] Repair Flows and No Plan (Was: No Plan) Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was :No Plan ) BeckW
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] Repair Flows and No Plan (Was: No Pl… Sergio Garcia Murillo
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Silvia Pfeiffer
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- [rtcweb] Plan xyz discussions; MMUSIC <> RTCweb R… Flemming Andreasen
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Peter Thatcher