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

[Christer Holmberg <[e-mail]>]

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. 

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?

Regards,

Christer