Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session

[Christer Holmberg <[e-mail]>]

Hi,

>> And how is the m=bundle mechanism not going to be handled correctly by
>> endpoints? An endpoint that doesn't support it would reject it, and an
>> endpoint that supports it can accept it.
>
> This is true, although Cullen has the not unreasonable concern that some endpoints may choke on something this far removed from normal syntax.

I am not sure what "normal syntax" means. The receiver sees an m- line media type that it doesn't support, so I am not sure whether it's even going to look deeper into it.

But, IF the endpoint "chokes", the offerer can send a new offer, without bundle. I don't see why we should specify our mechanism based on how badly implemented endpoints will act...

> m=bundle requires significant extensions to the syntax and also a near doubling in the size of the SDP.  It is harder to specify allowed 
> combinations of codecs and other options that are normally associated with a single m line. 

Please give an example.

> I think we should avoid having duplicate syntax to express all these things that can already be represented in SDP.

We DID have a discussion about whether it should be possible, inside the m=bundle line, to "reference" information existing in the audio/video/etc m- lines, in order to avoid duplication.

> The only issue identified with the original approach is that some endpoints may choke on using the same port for multiple media lines.  Why don't we focus on the simplest fix for that one identified problem?

You have said that we need a second offer/answer, with the same port numbers, in order to handle intermediaries. I don't understand why the first offer could not be without bundle, and the second offer (once you know that the remove endpoint supports bundle) according to the current mechanism, with the same port numbers.

Regards,

Christer