Re: [rtcweb] No Plan
Christer Holmberg <christer.holmberg@ericsson.com> Sat, 01 June 2013 11:05 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 47F2F21F8808 for <rtcweb@ietfa.amsl.com>; Sat, 1 Jun 2013 04:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.204
X-Spam-Level:
X-Spam-Status: No, score=-5.204 tagged_above=-999 required=5 tests=[AWL=0.445, 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 DDfhdXMV5eHa for <rtcweb@ietfa.amsl.com>; Sat, 1 Jun 2013 04:05:42 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1274E21F8746 for <rtcweb@ietf.org>; Sat, 1 Jun 2013 04:05:41 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d6d000003d54-67-51a9d58419fc
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 98.DC.15700.485D9A15; Sat, 1 Jun 2013 13:05:40 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Sat, 1 Jun 2013 13:05:39 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: [rtcweb] No Plan
Thread-Index: AQHOXJ6w4pPZWNQxOUWhx5DufiT5nZkdWAeQgAMGtQCAAFWpzg==
Date: Sat, 01 Jun 2013 11:05:39 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C380AA2@ESESSMB209.ericsson.se>
References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D144@ESESSMB209.ericsson.se>, <51A9A7E2.7000907@jitsi.org>
In-Reply-To: <51A9A7E2.7000907@jitsi.org>
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+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvrW7L1ZWBBh2T1S3W7JzAYrH2Xzu7 A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgyrh8/iFjQZdcxZ19zawNjE/Euxg5OSQETCQW z+lghLDFJC7cW8/WxcjFISRwmFHiw8+djBDOYkaJ+YseAjkcHGwCFhLd/7RBGkQE5CW62xYx gdjMAuoSdxafYwexhQVkJbZMnsEEUSMncf3nPjYI20ni7+RvYDUsAioSF++8ZAMZySvgK9H/ IhliVSejxNLZJ8FWcQpoSmz+FgZSzgh02/dTa6BWiUvcejKfCeJmAYkle84zQ9iiEi8f/2MF aZUQUJRY3i8HUa4jsWD3JzYIW1ti2cLXYOW8AoISJ2c+YZnAKDYLydRZSFpmIWmZhaRlASPL Kkb23MTMnPRyw02MwOg4uOW37g7GU+dEDjFKc7AoifPq8S4OFBJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cDI8stv0mLbVxl/LunZxMmvlexNXemy6tH3b1cWXJGdff1G05RbtjnMPUfWPZuo dCRu+snvJXndSnH86vyr3nHXu12Pkm9w5c2f+9hvR5/R/c9L1uqnf9WesWkG/zmrcOZVfc+D nZTMLyStTFBK+BPcemPW5iLeM1cK587z4io1K5x/PWnS1a9MSizFGYmGWsxFxYkARSKhb1wC AAA=
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: Sat, 01 Jun 2013 11:05:49 -0000
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
- 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