Re: [MMUSIC] [rtcweb] No Plan

[Emil Ivov <[e-mail]>]

Hey Paul,

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

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?

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?

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