Re: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT

[Christer Holmberg <[e-mail]>]

Hi,

>>>>>> At the interim yesterday, we agreed to use the SDP BUNDLE group
>>>>>> attribute to indicate on which port bundled media will be sent. In an
>>>>>> SDP offer, the order of the attribute mid values can be used by the
>>>>>> offerer to indicate a "wish", but the first attribute mid value in the
>>>>>> answer indicates where the answerer will eventually send bundled media.
>>>>>
>>>>> This could be interpreted to mean the first a=mid value in the SDP.
>>>>> I'm sure you mean "the first mid value in the a=group:bundle" line.
>>>>
>>>> Yes.
>>>>
>>>>> Or perhaps "the first mid value in the bundle group" - assuming there is a definition that "bundle group" means an a=group:bundle line.
>>>>
>>>> In the draft "bundle group" means (or, at least is supposed to mean :) the bundle grouped m- lines, and in general I think it is better to explicitly mention the line/attribute.
>>>>
>>>>> This can be "future proofed" by saying that the first mid value in the bundle group in the answer that references an m-line with non-zero
>>>>> port value. I realize this adds nothing unless 5888 is revised to permit m-lines with zero port in a bundle group. But at least it will be ready for that, and harms nothing.
>>>>
>>>> I agree, but suggest a little different wording: by saying the first mid value in the group attribute MUST NOT represent a port zero m- line.
>>>
>>> I just want to be sure we're clear here.
>>>
>>> Are you saying that even if we relax 5888 so that we may have m-lines
>>> with port zero in a bundle group, that the *first* mid in the bundle
>>> group can't designate a zero port???
>>
>> Yes, for BUNDLE. It doesn't have to be a generic 5888 rule.
>>
>>> I guess that should always be possible as long as there is at least one
>>> with a non-zero port.
>>>
>>> Do we have a possibility, with ICE, that all the m-lines in the bundle
>>> will have zero port? (Because we are waiting for ICE to figure out the
>>> actual port.) Or are we going to use something else for that purpose?
>>>
>>> As long as there is no possibility of having a bundle where all the
>>> ports are zero then I'm ok with what you propose.
>>
>> I hear what you're saying.
>>
>> But, in that case saying "first non-zero mid" does not work either, does it? :)
>
> Yep, you're right!
>
>> Another option is to also allow mids for zero-port m- lines to be first. A first mid for a port zero m- line would mean that there is no port for bundled media. Maybe there could be a use-case for that.
>
> That sounds like a bad choice if one of the other m-lines in the bundle has a non-zero port.

I agree, but it would allow us to have a generic rule, which would be applicable also in the case where all m- lines have zero port values (assuming we'll allow such m- lines in a bundle group to begin with, that is).

> So maybe your rule is best, if it works: first mid in bundle must
> identify an m-line in the bundle with non-zero port if there is one. If
> there are non with non-zero port then it can refer to one that is zero.
>
> But we can't take this too far without deciding if we want to allow
> rejected m-lines in bundles, and if so, what that means.

I don't think it means anything else than that the media associated with the m- line is disabled. As you have said earlier, having a port-zero-m-line in a bundle could be used as a "hint that it may be used within a bundle later", but I can't think of any new technical semantics. Plan A uses port-zero-m-lines, but the plan doesn't define new semantics for the port value itself.

Regards,

Christer