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

[Christer Holmberg <[e-mail]>]

Hi,

>>> 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.
>
> To specify two types of audio flows with very different characteristics I would normally have separate media lines with separate codec lists and attributes.  One may require DTMF and the other silence suppression in addition to the selected (but different) 
> codecs.  We need to keep this characteristic.  We also need a way of specifying bandwidth per (old) media line, which is already supported using separate media lines but requires that something new be defined for m=bundle.  What about RTCP 
> characteristics?  We certainly want to specify them per (old) media line.
>
> I understand that this can be done with m=bundle, but it requires new syntax.  Why bother if we have something that can work?

I am not sure it requires new syntax, if you e.g. can use the ssrc attribute in order to map attributes to specific flows.

>> 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.
>
> It would seem to be attractive to support negotiation of bundle with the first offer/answer transaction else it will be delayed. 
> And some networks may not need a 2nd offer/answer if the first one successfully negotiates one of the options.

Only if you can assume that there are not intermediaries in those network - AND that there won't be additional offer/answers for other reasons (you earlier said that there in many cases WILL be additional offer/answers...).

I still think it would be wrong to reject the m=bundle proposal based on badly implemented endpoints. In that case one could claim that endpoints will "choke" if they receive SDPs with RTCWEB datachannels, CLUE channels, whatever channels...

Regards,

Christer