Re: [MMUSIC] [rtcweb] No Plan

[Paul Kyzivat <[e-mail]>]

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

[snip]
>>>> 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?

	Thanks,
	Paul

> 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:
>>>>>>>>>
>>>>>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>>> .
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> .
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>