Re: [MMUSIC] [rtcweb] No Plan

Paul Kyzivat <> Tue, 04 June 2013 17:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F28F421F9C89 for <>; Tue, 4 Jun 2013 10:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.229
X-Spam-Status: No, score=-0.229 tagged_above=-999 required=5 tests=[AWL=0.208, 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 1wxzp0ct8Bhl for <>; Tue, 4 Jun 2013 10:35:34 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:17]) by (Postfix) with ESMTP id CBDBE21F9622 for <>; Tue, 4 Jun 2013 09:07:31 -0700 (PDT)
Received: from ([]) by with comcast id kG3Q1l0071vXlb85AG7XPm; Tue, 04 Jun 2013 16:07:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id kG7X1l0023ZTu2S3dG7XFl; Tue, 04 Jun 2013 16:07:31 +0000
Message-ID: <>
Date: Tue, 04 Jun 2013 12:07:30 -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="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1370362051; bh=/bhvWQxUg6osN/yspy69zHQJWEgT9A4Kw9kV0wHDLTw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sQGW9OsxyBO/mkla3P9TiMXQcoO76HB6yx2x1LBNymS/WwHM1Z1d1ExDMvLpWMt6E oeDWK0JGrH+oCSWh+m6nfVLwL61tcyerfr3rC65CIfS1JxRoh4b71hor/msylj5d/n HmM+kRrzi+VCkCEJU3v2Rpk9f5T8zC5dA+Clv8T5Wgl8i7Z9b+hmElumjmkdHynuPM KsS0C5i/1EawZ3Vdr03WS5Mb4fNd/k80kkRIXDDwTPqTh5j5fm4NDLcrKEuTd15lDN IZRPFZUHq82S2Q94Y5Fx7yuufheFHbVm3BmRfNSSTPis7466ju9o3EQX/DfvQcxVLn sc6Gd+qZSey0g==
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: Tue, 04 Jun 2013 17:35:39 -0000

On 6/3/13 6:17 PM, Emil Ivov wrote:

>>>> 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.
> We can certainly try. I am not sure if I am following though. Let's see:
>> 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.)
> This is the part that I can't quite picture. How can Y's camera be on a
> separate IP, but still appear as a regular device to Y's javascript and
> still generate a regular stream track? All this with a generic browser?

I'm not a browser guy, so maybe I am imagining things that are out of 
scope for webrtc, but maybe not.

At the very least you can have an app that gateways between a browser 
and some non-browser device. So assume that X is a browser and Y is not. 
What does the app tell the browser to do so that the new stream is on a 
different 5-tuple?

> Wouldn't it be much more likely that such a separate camera will be
> controlled by a proprietary interface that is not directly related to
> WebRTC?

Can somebody who knows more about these things comment if this is 
entirely impossible for two devices accessible to the browser to be 
accessible only via distinct IP address/port, or if it might occur for a 
sufficiently sophisticated device?


> If so, then the additional signalling for this camera would obviously
> need to be generated by Y's javascript (i.e. not the browser). That
> additional signalling can then be merged into the one from Y's browser
> by Y's JS or a gateway.
> X would indeed need to handle an offer with two video m= lines at that
> point, but that's because they would negotiate different 5-tuples. So
> this is fine.
> Another option would be to handle the new camera with an independent
> Offer/Answer that would yield a new PeerConnection. I don't know if that
> works for your case but I thought I'd mention it. In this case any
> additional information required for the synchronization of the two peer
> connections would be exchanged in an app-specific way.
> Cheers,
> Emil
>> Once that is done the new mediaStreamTrack can be established on the new
>> m-line.
>> How does this fit into No Plan?
>>> (This might be a good point to move this to mmusic)
>> Done.
> Thanks,
> Emil
>>     Thanks,
>>     Paul
>>> 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
>>>>>>>> .
>>>>>> .