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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FDB921F85BF; Tue, 7 May 2013 03:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.159
X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ge-w-QSuBd9L; Tue, 7 May 2013 03:11:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 51D2421F8574; Tue, 7 May 2013 03:11:57 -0700 (PDT)
X-AuditID: c1b4fb25-b7f396d000007d06-a6-5188d36ccc50
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A6.2E.32006.C63D8815; Tue, 7 May 2013 12:11:56 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Tue, 7 May 2013 12:11:55 +0200
From: Christer Holmberg <>
To: Harald Alvestrand <>, Justin Uberti <>
Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt
Thread-Index: AQHOR8S71uamUT1UgU2fGg1LHYFLV5j4GHYAgAE/1LA=
Date: Tue, 7 May 2013 10:11:55 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C36C8EBESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+JvrW7O5Y5Ag2XzJS2O9XWxWWydKmQx dfljFou1/9rZHVg8rky4wuqxYFOpx5IlP5kCmKO4bFJSczLLUov07RK4Mm7d+Mdc0NjDWDH3 w1e2BsZF1V2MnBwSAiYS617uZoOwxSQu3FsPZHNxCAkcZpQ4fL+JHcJZzCix/VAfUIaDg03A QqL7nzZIg4hAkMTcjxvAmpkFfCQenZnOBGILC0RKvFo9nxGiJkri9/fb7BC2lcSR5u2sIDaL gIrE6WtNYL28Ar4Sq9bsZYTY9ZFRYt79drBmTgFdiYVNJ5hBbEag676fWsMEsUxc4taT+UwQ VwtILNlznhnCFpV4+fgfK4StKHF1+nKo+nyJxnPnGCGWCUqcnPmEZQKj6Cwko2YhKZuFpAwi riOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYmTPTczMSS832sQIjLiDW36r7mC8c07kEKM0 B4uSOG8yV2OgkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYmoZtFD9mn51l3dlw56Hl98u3N VtviGTaf/LJ1cX2QJIdtkejW2PL8e48XHA1eVeE3K7xs6bP6E0f5LvEZbOWV6sm0exnbtPBd d9OJyrr1wu/4Lnzfy8NVzNz84J7A1g/MK1V0q6+9WcuzfMObUq+srgjJ2P5FERN9Iw79/v1y cvgtwYWP32gqsRRnJBpqMRcVJwIA0x9NxYYCAAA=
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 10:12:03 -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.


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



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