Re: [rtcweb] No Plan

[Paul Kyzivat <[e-mail]>]

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.

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