Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between

[Christer Holmberg <[e-mail]>]

Hi,

>I think a agree with Paul's text but I read it as almost the opposite of what you wrote.

We meant the same thing: the bundle port is the first mid value in the SDP group:BUNDLE attribute, and the first mid value in the SDP group:BUNDLE attribute must not represent a zero port m- line.

Paul talked about "the first mid representing a non-zero m- line", while I talk about having a rule saying that "the first mid must not represent a zero m- line to begin with"

> I think some examples would help

There will be lots of them :)

> So if the offer has 3 m-lines with A,B, C in a bundle with ports 1,2,3. It is fine for the answer to put m-lines A and B in a bundle both using port 1 but then have C outside the bundle using port 3. Do have this right? Would a detail example help ?

Yes, as long as the offer contains DIFFERENT ports, it is allowed to leave C outside.

But, if the offer contains IDENTICAL ports, it is not allowed to leave C outside, because there would be no "fallback" port for C. That is what rule #4, which you are pretty sure you disagree with, says :)

Regards,

Christer




On May 24, 2013, at 8:36 AM, Paul Kyzivat <[e-mail]> wrote:

> I agree with the sense of what you state below.
> I have some nits with the words you use.
>
> On 5/24/13 6:28 AM, Christer Holmberg wrote:
>> Hi,
>>
>> At the interim yesterday, we agreed that an answerer MUST always include
>> identical ports* (usage of port zero within a bundle is a separate
>> topic) for all m- lines within an bundle group.
>>
>> If the answerer wants to use different ports* for some/all m- lines, it
>> MUST NOT include those m- lines in a bundle group
>
> OK so far. But:
>
>> (if they already are
>> in a bundle group, a separate offer is needed to remove them).
>
> This depends on what you mean by "already in a bundle group".
> Certainly they are already in a bundle group in the offer, so presumably that is not what you mean.
>
> I presume you mean that they were already in a bundle group in the prior O/A.
>
> I think this can be stated more clearly. How about:
>
> The answer to an offer containing a bundle group may remove an m-line from the bundle group if (and only if) the address/port of the m-line in the offer is distinct from the address/port of all the other m-lines in the offered bundle group. When doing so it must supply a unique address/port for that m-line in the answer.
>
>       Thanks,
>       Paul
>
>> WHAT IT MEANS: There is no way for an answerer to tell that the offerer,
>> for certain m- lines, can use the same port*, eventhough the answer will
>> use separate ports*.
>>
>> I will work on some actual text proposal later, but please indicate if
>> you OBJECT to this approach in general.
>>
>> Regards,
>>
>> Christer
>>
>> NOTE: “port” = port:address combination – we are working on coming up
>> with better terminology J
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic