Re: [MMUSIC] [rtcweb] No Plan

Paul Kyzivat <> Mon, 03 June 2013 21:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AF2711E810D for <>; Mon, 3 Jun 2013 14:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.287
X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WxpByWjFSu1Q for <>; Mon, 3 Jun 2013 14:39:57 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:56]) by (Postfix) with ESMTP id AC7B011E810A for <>; Mon, 3 Jun 2013 14:36:21 -0700 (PDT)
Received: from ([]) by with comcast id jn0g1l0050SCNGk56xcMbC; Mon, 03 Jun 2013 21:36:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id jxcL1l00d3ZTu2S3VxcLfe; Mon, 03 Jun 2013 21:36:21 +0000
Message-ID: <>
Date: Mon, 03 Jun 2013 17:36:19 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Emil Ivov <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1370295381; bh=mNLSg+33yMYcHHRC4F01N2JzTHm2a/TDVgHXD8qyGLw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GVUw8VNoOjMqxOhDIWttfLUmAE1ITrhAwXzjdLSBladysuxO0WvGsqZyxGUjj2F4s 3I4yhRvRuaYzYx8W3JYahMtcQzqCoKp7HdBgvfxTbTnQpql5vB13GMVNqNa4IPaEwL aG91y9zZj5bHOjgoEjH2aoRahkGtidJ+V4aUQotug82NKM09zbUJdhtzfXmWY0OsAz RpDg97n/9FuZ++9D7wkOEwjwMeDVfGkv7SVNDoDu9wf281KAQNjBNUeTLee7RNycmT 9UdzOf2Hgy852AtWeTirjmQywX+QJDvvsr/4dJT/yyOVnFfO9yslgFsV0b/3dHYDWq H0Q+Kox0DJaXg==
Subject: Re: [MMUSIC] [rtcweb] No Plan
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: Mon, 03 Jun 2013 21:40:12 -0000

On 6/3/13 5:09 PM, Emil Ivov wrote:
> Hey Paul,
> On 03.06.13, 23:37, Paul Kyzivat wrote:
>> On 6/1/13 1:40 AM, Emil Ivov wrote:
>>> On 31.05.13, 22:11, Paul Kyzivat wrote:
>>>> On 5/31/13 6:51 AM, Emil Ivov wrote:
>>>>> Hey Paul,
>>>>> On 29.05.13, 22:57, Paul Kyzivat wrote:
>>>>>> Emil,
>>>>>> I'm going to reserve judgment on this pending further discussion.
>>>>>> I think this *might* work for CLUE, but I want to be certain.
>>>>> Sure!
>>>>>> I'm concerned with decomposed endpoints that can't manage all the
>>>>>> streams on the same address/port. They will need multiple independent
>>>>>> m-lines and/or bundle groups.
>>>>> This is obviously open for debate but the general idea of No Plan is
>>>>> that: Offer/Answer is used for configuring media and RTP stacks and
>>>>> additional signalling is not the browser's concern.
>>>>> Having extra m= lines, particularly when using BUNDLE, is in many ways
>>>>> just extra signalling.
>>>> You may be able to argue that adding extra m-lines into an existing
>>>> bundle is "just extra signaling". But introducing an additional 5-tuple
>>>> is more substantial. It requires configuring a new RTP stack and media.
>>> Indeed, this would require BUNDLE to work.
>> I don't understand what that means - what point you are trying to make.
> Sorry about this. What I was trying to say was: yes, you are right,
> introducing a new 5-tuple is more substantial. Therefore adding a new m=
> line to an SDP is a lot simpler if it didn't also imply adding a new
> 5-tuple. This would only be possible when m= lines are bundled.

No. The problem arises without bundle. It gets more complex in 
combination with bundle.

> This is
> why I said: "Indeed, this would require BUNDLE to work."
> Is this clearer?

Maybe not. Still some disconnect here.

>> You seem to have some criterion for what requires sdp and what does not.
>> And AFAIK you are already assuming bundle works - you are simply using
>> it less.
> No, not really. The assumption is only necessary when trying to talk to
> Plan A devices and you want to have new m= lines added en route.

I thought you were assuming bundle what there to combine audio and video 
on a single 5-tuple. I don't think this need have anything to do with 
Plan A.

> No such assumption is necessary, for example, when talking to legacy SIP
> phones that will only show one video and one audio stream.

Of course, in such a degenerate case where there is only one m-line for 
each media type, and only one stream per m-line.

>> As best I can tell, you acknowledge that you need SDP to:
>> - negotiate a 5-tuple over which media will flow
>> - specify which types of media can be carried and the codec info
>>     they may use.
> Yes.
>> I'm just pointing out that for decomposed endpoints one 5-tuple may not
>> be enough. And the need for this might not be known a priori. One side
>> may be ready to add another stream for some purpose, and be willing/able
>> to use private signaling to negotiate that. But the other side may not
>> be able to handle that stream on the same 5-tuple. That in turn may
>> result in a need to negotiate SDP changes to establish an additional
>> 5-tuple that can then be used for that new stream.
> I think I see ... but not completely. Could you please post an SDP offer
> with BUNDLE and the corresponding answer?

The issue can be discussed without bundle, and without detailing the O/A.

Assume we have had an O/A already between X and Y, with a single (video) 
m-line, resulting in a single 5-tuple. Over this we have a single audio 
RTP stream and mediaStreamtrack.

The user of X interacts with the app, indicating a desire to receive 
another video stream from Y. This causes the app to trigger the JS in Y 
to set up another mediaStreamTrack. But the camera on Y has a separate 
IP address. So it is necessary to first set up another video m-line with 
the new address on Y's end. (X's end can use its single IP address.)

Once that is done the new mediaStreamTrack can be established on the new 

How does this fit into No Plan?

> (This might be a good point to move this to mmusic)



> Thanks,
> Emil
>>>>      Thanks,
>>>>      Paul
>>>>> If you'd like for that signalling to be in SDP, I
>>>>> don't see any problem with it. However it would be best for this extra
>>>>> layer of SDP signalling to appear at either the application layer
>>>>> or in
>>>>> a signalling gateway (that is going to be there anyway).
>>>>> Does this make sense?
>>>>> Emil
>>>>>> Further questions:
>>>>>> I presume that you expect bandwidth in the SDP to be an aggregate
>>>>>> per-m-line, with application specific signaling for bandwidth at the
>>>>>> per-RTP-stream level?
>>>>>>       Thanks,
>>>>>>       Paul
>>>>>> On 5/29/13 2:59 PM, Emil Ivov wrote:
>>>>>>> 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
>>>>>> .
>>>> .