Re: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00

[Flemming Andreasen <[e-mail]>]

On 11/17/11 3:34 AM, Christer Holmberg wrote:
> Hi,
>
>    
>>>>> We do however have a number of SDP parameters (in RFC 4566 and extensions) that are specified on a per media stream
>>>>> basis and we need some general rules around how to deal with those. Section 7.2 begins to look at it, but we need a
>>>>> lot more here, especially if we need to support backwards compatibility at the same time in a single O/A exchange.
>>>>> Some media description parameters will have to be cumulative among the multiple "m=" lines (rtpmap for example), others
>>>>> will have to pick a single one (e.g. SRTP keying parameters), and yet others will need to be combined (bandwidth for
>>>>> example as noted in the draft).
>>>>>
>>>>>            
>>>> I agree, and that for sure is something we will have to work with before the spec is published as RFC. Section 6.4 (and 7.2) is intended to
>>>> cover such text (there is already some text about the b= parameter, but more will be needed).
>>>>          
>>> However, I hope that not having all those details ready available at this point is a show stopper for starting the work.
>>>        
>> Agreed, however it may affect the nature of the solution and hence it
>> would be good to understand more details around this before deciding
>> which way to go. Taking capability negotiation as an alternative for
>> example, you there have an explicit negotiation framework that could
>> make it very explicit as to what you actually want to do depending on
>> whether you end up doing the bundle or not in a given negotiation.
>> The approach outlined here seems less clear (for the moment at least) and will
>> require a bunch of new rules that may or may not generalize well
>> among existing and future SDP extensions.
>>      
> In my personal opinion (but, the WG of course decides :) I think it is quite clear and straight forward, and I don't see any major issues - eventhough I do agree that there are a number of things we need to specify.
>    
Ok - if it's clear and straight forward then it should be easy to write 
them up in the next version of the draft so we can see that.

> I do realize that there might be cases where an answerer, that does not support BUNDLE, will not accept an offer with identical port numbers. But, I have never seen such entity, and nobody has informed about such entities. That of course doesn't mean they don't exist, but my view is that it's not a big real-life problem.
>
> Also, could you explain to me how all this would look using CapNeg, and how you would avoid the issues you've raised with BUNDLE?
>    
The backwards compatibility issue would be addressed by having the 
standard (non-bundle) configuration provided as the actual configuration 
(i.e. standard SDP) whereas the bundle configuration would be provided 
as a set of capabilities with a potential configuration for them. You 
may need to supplement that with one or more new attributes to specify 
bundle semantics, but those attributes could simply be provided as 
attribute capabilities that would be part of the potential (bundle) 
configuration.

As for rules around how to deal with various media-level parameters that 
you may or may not want depending on whether you end up doing the bundle 
or not, the potential configuration allows you to specify the exact set 
you want used for each configuration. It gets verbose quickly, but it's 
unambigious and well-defined at least.

Thanks

-- Flemming


> Regards,
>
> Christer
>