Re: [MMUSIC] Another bundling proposal - Christer's comments

[Christer Holmberg <[e-mail]>]

Hi,

>>>> Second, you use the non-bundle m- lines for codec negotiation etc. 
>>>> But, previously, when MMT was discussed, I believe that people 
>>>> indicated that they do not want to "refer" to other m- lines from 
>>>> the MMT m- line. Instead,  the information should be explicitly 
>>>> provided in the MMT m- line (which is the reason why the SDP size 
>>>> gets pretty big with MMT, as most information is duplicated).
>>>
>>> I've heard that mentioned before, but I've never seen the argument 
>>> in favor of it.  Can someone tell me what it is, or provide a 
>>> pointer?
>> 
>>It was indicated in a meeting (at the moment I can't remember which 
>>meeting, though), but I never checked whether it was added to the 
>>minutes. I guess it will be on audio recording.
>> 
>>But, as far as I remember, there were never much discussion about it. 
>>It was an open issue on one of my slides, and people simply indicated 
>>support for adding explicit information, rather the referencing.
>>
>If this desire exists, I'd like to hear technical reasons why it is desired.  

As far as I remember, there were no real technical reasons - it was mostly "cosmetic".

But, one issue is if there is an intermediary (e.g. transcoder) that modifies the payload type/codec information in the non-BUNDLE m- lines, but leaves the BUNDLE m- line untouched and passes the "kumquat" payload transparently. The offerer and answerer would not have different payload type/codec information.

(Of course, if you assume that such intermediary would always remove the KUMQUAT grouping attribute value, the case won't occur.)

>Adding payload types to the bundle media description makes it more difficult to ensure that a non-supporting answerer rejects the bundle media description.

It depends on how it's done. You could still only indicate "kumquat" on the m- line, but then provide the encapsulated payload type information using SDP attributes.

Regards,

Christer