Re: [MMUSIC] [rtcweb] No Plan

[Paul Kyzivat <[e-mail]>]

Hi Emil - more inline.

On 6/5/13 12:30 PM, Emil Ivov wrote:
> 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?

Consider it to be a web server coupled to a sip GW. So in the webrtc 
"triangle" view, X is a browser, Y is a SIP device, and the GW is the 
web server driving the broswer. For the moment lets assume that Y 
supports ICE, and bundle, and DTLS/SRTP, so that the GW need only be a 
signaling gw, not a media gw.

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

(1) doesn't fit what I'm concerned with.

> 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

This is more what I had in mind.
So at least you are ok with two separate video m-lines on different 
5-tuples in this case, where it is initiated from the sip device.
It wasn't evident to me if this fit into your model.

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

Lets consider a more complex variant of this scenario:

- the initial o/a is just for audio. That gets set up in obvious way.
   There is only an audio m-line. (Maybe in a degenerate bundle,
   maybe not.) I guess there is no data channel, because the gw doesn't
   expect sip devices to support one.

- then X (or the app in the gw driving X) decides to add video.
   So it creates second offer, including a video m-line bundled with
   the audio m-line.

- that offer goes to Y. But Y can't handle the audio and video as
   a bundle. In this case it can simply refuse the bundle while
   accepting the video unbundled.

If that is ok with No Plan then I think I am ok with it.

	Thanks,
	Paul

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