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

[Christer Holmberg <[e-mail]>]

Hi,

>>> 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 didn't mean that I have all the details in my head :)

What I meant was that it is clear WHAT we need to do, and we should do that as a community.

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

You still need to specify how the media level parameters will "interact" in a bundle - no matter whether you use CapNeg or not to negotiate the bundle.

In my opinion, the usage of CapNeg is "overkill" for this, as we're only talking about the port. And, as you said, we would still need to define new parameters for the bundle semantics. 

And, does the base CapNeg spec support providing alternative port numbers?

And, even if the answerer doesn't support bundle, maybe the offerer still wants to use the same local port.

Regards,

Christer