Re: [MMUSIC] [rtcweb] No Plan

[Emil Ivov <[e-mail]>]

Hey Paul,

On 04.06.13, 18:07, Paul Kyzivat wrote:
> 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.

Well I suppose a browser could always support a decoupled device if it 
were made available as local through some driver. Something like a 
virtual local device. In that case however, this driver would still have 
to bring the media to the local host so that it can be placed within a 
track, a stream and a peer connection. At this point it wouldn't matter 
to WebRTC that the device is actually decoupled, would it?

There is still the other option where this device is controlled by 
proprietary JS and for this you'd need to have your own signalling and 
your own control interfaces.

> At the very least you can have an app that gateways between a browser
> and some non-browser device.

Let me make sure I understand this. This gateway app, is it running on 
X, is it on a box between X and Y, or is it a controlling entity of the 
decoupled Y?

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

Without knowing the specifics of your scenario I'd say that you have the 
following options:

1) Y relays RTP from its decoupled camera toward X. In this case X is 
getting everything on the same 5-tuple, so no extra m= lines are 
necessary. (You'd have a similar situation in the case above where the 
camera is somehow presented as a virtual local device on Y)

2) Y just wants to handle signalling and it would like that video from 
the decoupled camera reaches X directly from there. Y also wants to have 
everything handled within the same Offer/Answer dialog. In this case:
2.1) When Y calls X, it would add a second video m= line in a second 
bundle (or with no bundle at all) when sending its offer to X
2.2) When X calls Y with a single lined offer, Y would also answer with 
a single m= line and would then re-Offer with two lines.

In both 2.1 and 2.2 the browser on X would see two independent, 
unbundled streams and handle them appropriately.

Is any of the above close to what you have in mind? Or is it completely off?

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

-- 
https://jitsi.org