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

"Roni Even" <> Tue, 07 May 2013 12:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8ABA21F8FEB; Tue, 7 May 2013 05:52:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.82
X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NCcCF7CwMapr; Tue, 7 May 2013 05:52:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22c]) by (Postfix) with ESMTP id 5252921F86CB; Tue, 7 May 2013 05:52:32 -0700 (PDT)
Received: by with SMTP id z12so546555wgg.23 for <multiple recipients>; Tue, 07 May 2013 05:52:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=2RWu8vEvaNNxgdOEgSPUq0KFcKvUdFCXvtl2aqaWnIY=; b=Zj1IE1eHWA7ZQMRF7jD/qyb8LwoyxQMxNoOIiwn4qxh3/Vqw0JQeEB/Txc71N/Fwxn zAjiQUHWJQ+RDHbOGRBw07mrceD4AK0E2s+gqdT0lsiaaTUyFuRp55sAlP+EY8GbaEuV qU29U8red0FprDT1EOEl2EQbUndBenOCaQ2xNjPF1fbK3uQPR4GV/Qn7U9OiOHac5QQF 6XJo90V9LO8z1dPdiuROEBLfjFqQ70S6ToXbz9F+26p5+cyfEZO+3Sup0k5ALKX0fZ0S AMMCS8NR7bAT3JdaqFVNIeygapOAG9HgPNJW/+IrcwOPATjSCvMxhLOQaF6xZFg2B0rk 9ErQ==
X-Received: by with SMTP id ng3mr3138032wic.22.1367931150438; Tue, 07 May 2013 05:52:30 -0700 (PDT)
Received: from RoniE ( []) by with ESMTPSA id q18sm2618430wiw.8.2013. for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 05:52:29 -0700 (PDT)
From: "Roni Even" <>
To: "'Justin Uberti'" <>, <>, <>
References: <> <> <>
In-Reply-To: <>
Date: Tue, 7 May 2013 15:51:40 +0300
Message-ID: <008701ce4b21$a0997aa0$e1cc6fe0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01CE4B3A.C5E88760"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIfv5wx4y9wP/O/FJv66Nx2OU8XsQM3rT1TAYHWzfiYMNuJkA==
Content-Language: en-us
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:52:45 -0000


I think that plan B is the right direction. I am wondering if this should be discussed in RTCWEB or MMUSIC


I like the proposed solution for multicast support but there is also an individual draft in MMUSIC see . I think that it will be good to have a separate document on simulcast support


Some comments


1.       In section 3.1 when talking about using more than one m-line for a media type I think that there are other cases when this may be required . for example, if an attribute is not specified at SSRC level or if the SDP will be simpler when using multiple m-line  )describing different codec combinations

2.       In section 3.2 the document says that collision will not happen if the answerer sees the SDP from the Offer. I am not sure it will work when joining a multipoint conference since the offer is joining an existing session and do not know what SSRC have been used. I think that the issue is handled in RFC5576 so you can point at it.

3.       The draft, as far as I can tell, is discussing point to point calls and full meshed conferences. I think we need to look at other topologies including a centralized MCU doing video switch, for example.

4.       In section 4.1 you suggest using the MSID as an indication for supporting plan B. I think that this may be RTCWEB specific and other usages like CLUE may use a different way to associate an SSRC to a Media Capture. My proposal is to use maxssrc. I think that it will be needed since an offer may include more options than can be really sent by the offerer and the maxssrc can tell the answerer how many it can select. It can also tell the answerer how many simultaneous RTP streams the offerer can receive. Otherwise it may be better to have a specific identifier that will tell that multiple RTP streams in an m-line are supported.

5.       I have a question about the last paragraph of section 4.2. Currently the answerer can start sending media immediately when getting the offer in parallel to sending the SDP answer since the offer includes receive capabilities and receive transport address. Are you suggesting that media will flow only after the 3 way handshake?

6.       Small nit on section 5.1.4, according to section 8 of the Lennox source selection draft, the third offer must have sending:on for the streams that are being sent so probably need a=ssrc:1 msid:left-mic sending:on



Roni Even






From: [] On Behalf Of Justin Uberti
Sent: 03 May, 2013 9:09 AM
Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt


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