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