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

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 May 2013 10:28:35 +0000

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 (if they already are in a bundle group, a separate offer is needed to remove them).

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 :)

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 May 2013 10:36:15 -0400

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*.
>
> NOTE: “port” = port:address combination – we are working on coming up
> with better terminology J
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 May 2013 11:14:52 -0700

On 24 May 2013 07:36, Paul Kyzivat <[email-masked]> wrote:
> 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.

Yes.  That addresses most concerns.

It gets even better when you consider that there is an expectation
that any bundled m-line is "fixed up" to include the same transport
parameters, thus "sealing the deal".

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 24 May 2013 15:12:01 -0700

Hey Christer

   This looks good ( including Paul's clarification and Martin's statement
about Expectation of the following fixup to make intermediaries happy).

Also few comments inline.

On Fri, May 24, 2013 at 3:28 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,****
> ** **
> identical ports* (usage of port zero within a bundle is a separate topic)
> for all m- lines within an bundle group. ****
>
> **
>
**
> MUST NOT include those m- lines in a bundle group (if they already are in a
> bundle group, a separate offer is needed to remove them).
>

[Suhas] If the answerer wants to use different ports for "ALL" the m-lines
then it is implicitly assumed that there was a Successful O/A exchange +
Fixup and this Offer is a subsequent one.
On the other hand, changing some ports in the Answer can even happen in the
first ever BUNDLE O/A as well.
Just wanted to clarify with the wordings.

****
> ** **
> 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****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 May 2013 10:04:50 +0000

Hi,

The text suggested by Paul is good.

Regards,

Christer

From: Suhas Nandakumar [mailto:[email-masked]]
Sent: 25. toukokuuta 2013 1:12
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between

Hey Christer

   This looks good ( including Paul's clarification and Martin's statement about Expectation of the following fixup to make intermediaries happy).

Also few comments inline.
On Fri, May 24, 2013 at 3:28 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

[Suhas] If the answerer wants to use different ports for "ALL" the m-lines then it is implicitly assumed that there was a Successful O/A exchange + Fixup and this Offer is a subsequent one.
On the other hand, changing some ports in the Answer can even happen in the first ever BUNDLE O/A as well.
Just wanted to clarify with the wordings.

Regards,

Christer

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 27 May 2013 13:37:33 +0000

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

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 ?

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

> 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.
> 
> 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
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 May 2013 14:33:39 +0000

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…

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

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 27 May 2013 16:10:25 +0000

> 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.

+1