Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

Christer Holmberg <> Tue, 07 May 2013 12:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EF3721F8EFC; Tue, 7 May 2013 05:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.874
X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 O6kQj6wDNPVb; Tue, 7 May 2013 05:08:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D1B6821F8F3C; Tue, 7 May 2013 05:08:21 -0700 (PDT)
X-AuditID: c1b4fb25-b7f396d000007d06-16-5188eeb4bdb8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C5.D1.32006.4BEE8815; Tue, 7 May 2013 14:08:21 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Tue, 7 May 2013 14:08:20 +0200
From: Christer Holmberg <>
To: Harald Alvestrand <>
Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt
Thread-Index: AQHOSw8clsjra9RECEqdCjXAKrt6wpj5iT9g
Date: Tue, 7 May 2013 12:08:19 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre7Wdx2BBn+WMVkc6+tis9g6Vchi 6vLHLBZr/7WzO7B4XJlwhdVjwaZSjyVLfjIFMEdx2aSk5mSWpRbp2yVwZSy5+JSl4KZ+xeNP H1gbGJeodTFyckgImEi8+7CcFcIWk7hwbz1bFyMXh5DAYUaJG2f+sEI4ixklfsz4xtTFyMHB JmAh0f1PG6RBREBH4uH+BiYQm1mgSOL82weMILawQKTE1GtfGSFqoiQuHT3HBGEbSTzc+JER ZAyLgIrEjjX6ICavgK/E5uuOIBVCAjeYJL4f0gKxOQV0JRa+3Q7WyQh02vdTa6A2iUvcejKf CeJkAYkle84zQ9iiEi8f/4N6RVHi6vTlUPV6EjemTmGDsLUlli18DVbPKyAocXLmE5YJjGKz kIydhaRlFpKWWUhaFjCyrGJkz03MzEkvN9rECIycg1t+q+5gvHNO5BCjNAeLkjhvMldjoJBA emJJanZqakFqUXxRaU5q8SFGJg5OqQbGWR/nTnP/U2t3wnDDKS7vAjH2hQfOXHy6z+sB96T2 lrVO3UZxXPu2XNq1/oZZoqfDHgNV1zdy9+3cTbJVGsRt46KWC7P43s474CyXxaom6j+tx+Lc niXzF10O+FhfYb/fyshhy7SUWKuqqc+aw+MdVYPeBx+oZGS9L/1DRbI5fY0lL3ex+iYlluKM REMt5qLiRABxn+cZagIAAA==
Cc: "" <>, "" <>
Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 May 2013 12:08:27 -0000

>> A few questions on the draft:
>> The examples only show one PT per m- line, and the draft seem to assume that all PTs (ie codecs and/or codec configurations) apply to all SSRCs 
>> within an m- line. I think that is very important to point out, because at least in my opinion it is an important factor that we need to discuss.
> Example: I think Cullen often talks about using a camera with built in codec X. But, Plan B does not allow to (or, at least does not describe how to) 
> explicitly offer codec X for the track/ssrc associated with the camera. Codec X is offered for ALL tracks/ssrcs associated with the m- line.
> My read: This is a very special use case. The sender always chooses the codec from the available codecs that the recipient can understand - and it's then free to choose the built in codec X if supported by the recipient.
> If, for some reason, the application is dependent on segregating the codecs, it can use the "a=content" mechanism to segregate the streams onto different M-lines.

- Assume I have two cameras, one which can handle codec X, and one which can handle codec Y. 

- I send you an offer with a video m- line, offering X, Y and a ssrc for each camera

- You only want one of my camera streams, AND you only support codec X. Now, how do you know which ssrc to choose? You don't know which uses codec X.

Now, maybe this is a theoretical problem, but I think the draft needs to describe that codecs, and codec configurations, apply to all ssrcs associated with an m- line.

And, IF there is a need to apply codecs to a specific ssrc only, you need to use a separate m- line for that ssrc.

>> Q2_1_LEGACY:
>> The text says that things must work with legacy devices, and that an endpoint can choose a single source when communicating with a 
>> legacy device. But, there is really no text about how the legacy device will know which source to use, etc.
> The application that drives the API will have to decide that it can send only one source. The browser cannot (in my opinion) sensibly make that choice on behalf of the application.

Fair enough, but that needs to be clearly described.

>> Q2_2_LEGACY:
>> The example in section 5.2 (and sub sections) confuses me a little. You indicate that the m- line itself represents "main", while ssrc 
>> attributes are used to describe the left/center/right mic sources. Why is there no ssrc attribute for the main flow?
> The MSID identifier is, by definition, meaningless. The association between the MSID and the function of the stream is not carried in 
> the MSID attribute. The example is a bit unfortunate in that it uses MSIDs that look as if they're human-readable strings that carry semantics.

I wasn't referring to the MSID identifier, but more to the fact that you don't indicate the ssrc value for the "main" flow. I thought we were going to mandate the indication of the ssrc value for each flow, but maybe I remember wrong.

>> The draft does not explicitly forbid the usage of multiple m- lines for a given media type (e.g. audio). It would probably be good to point that out also.
> In fact the a=content mechanism (see section 3.1) depends on the ability to use multiple m- lines for a given media type, so it would be really hard to interpret the draft as forbidding this.

Fair enough. My mistake.



There's an issue with representing the semantics of an incoming call that uses multiple m- lines for a given media type and doesn't give differing a=content attributes for those media types.
I don't know if such a scenario ever occurs in practice.

From: [] On Behalf Of Harald Alvestrand
Sent: 6. toukokuuta 2013 17:20
To: Justin Uberti
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt
Note - I regard the Plan A / Plan B conflict as the "long end of the pole" with regards to resolving issues regarding SDP signalling in RTCWEB - and as such, I regard it as very important to get it resolved.

The silence on this issue is disquieting.


On 05/03/2013 08:08 AM, Justin Uberti wrote:
Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each. 
Hopefully this will make discussion of this topic easier.
---------- Forwarded message ----------
From: <>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <>

A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename:        draft-uberti-rtcweb-plan
Revision:        00
Title:           Plan B: a proposal for signaling multiple media sources in WebRTC.
Creation date:   2013-05-03
Group:           Individual Submission
Number of pages: 15

   This document explains how multiple media sources can be signaled in
   WebRTC using SDP, in a fashion that avoids many common problems and
   provides a simple control surface to the receiver.

The IETF Secretariat

rtcweb mailing list