Re: [rtcweb] No Plan

Christer Holmberg <> Sat, 01 June 2013 11:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47F2F21F8808 for <>; Sat, 1 Jun 2013 04:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.204
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DDfhdXMV5eHa for <>; Sat, 1 Jun 2013 04:05:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1274E21F8746 for <>; Sat, 1 Jun 2013 04:05:41 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d6d000003d54-67-51a9d58419fc
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 98.DC.15700.485D9A15; Sat, 1 Jun 2013 13:05:40 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Sat, 1 Jun 2013 13:05:39 +0200
From: Christer Holmberg <>
To: Emil Ivov <>
Thread-Topic: [rtcweb] No Plan
Thread-Index: AQHOXJ6w4pPZWNQxOUWhx5DufiT5nZkdWAeQgAMGtQCAAFWpzg==
Date: Sat, 1 Jun 2013 11:05:39 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
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: "" <>
Subject: Re: [rtcweb] No Plan
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 01 Jun 2013 11:05:49 -0000


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




> 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: [] On Behalf Of Emil Ivov
> Sent: 29. toukokuuta 2013 22:00
> To:
> 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:
> 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
> --
> _______________________________________________
> rtcweb mailing list
> .