Subject: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses.

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Sep 2013 16:45:12 -0400

On 8/30/13 4:27 PM, Hadriel Kaplan wrote:
>
> On Aug 30, 2013, at 9:39 AM, Christer Holmberg <[email-masked]> wrote:
>
>> Hi,
>>
>>>> We also need to decide whether that change also applies to when new media descriptions (m- line) are added to a previously negotiated BUNDLE group.
>>>> Currently the text says that, when an m- line is added, it must contain either a unique address, or a previously negotiated BUNDLE address.
>>>> But, since we now allow to assign a new, yet not confirmed, BUNDLE address to multiple m- lines, I guess that applies also to a new m- line.
>>>
>>> But then if the far-end answered with accepting it for the same bundle, then you'd have to send another offer with the m-line using the correct port of the bundle group, right?
>>
>> The change is that an Offerer is now allowed to assign the same address (the requested BUNDLE address) to all m- lines in the BUNDLE group BEFORE the Answerer has "confirmed" the address
>> to become the Offerer's BUNDLE address.
>>
>> So, if the requested BUNDLE address was assigned to all m- lines in the BUNDLE group, and the Answerer accepts it, there is obviously no need to send a second offer.
>>
>> But, if any of the m- lines in the offer did NOT contain the selected BUNDLE address, a second Offer is still required :)
>
> Actually, on reflection it doesn't need to send a new offer even if the far-end didn't want bundle.
> As the offerer, if you want to add an m-line with bundle, simply use the the same port numbers as the existing bundle.  If the answerer responds with its same port number for its side of the bundle, you're done.  If the answerer decides it didn't want that new m-line to be bundled, it will simply pick a new port number in its answer.  You're still done.  Because it's not the same 5-tuple. (it happens to be the same local source port number on the offerer, but not the same dest port)
> If the offerer now wants a new local port number for some reason (like it can't handle distinguishing full 5-tuples) it can send another offer to use a new port number for that m-line.

When I first read this I thought it was very clever, and seemed to work.

On reflection, I still think its clever, but I think it presents a 
complication:

Suppose this procedure was carried out between X and Y. So for some 
"bundled " m-line X has its bundle port, while Y has a unique port.
Then Y has need to send an offer to X, but has no desire to change 
anything about this bundle of m-lines. What does it put into the offer? 
It will presumably need to offer its unique port.

Then what are the rules for X to put in the answer? The existing rules 
would have it put its bundle address/port in. Then Y is expected to send 
another offer to put all the bundled m-lines onto the bundle port. But 
to achieve its goal of keeping that m-line unbundled (to it) Y won't 
want to do that.

The rules can be changed to make this valid. But if so, I think that is 
a significant change. For middle boxes, when getting the first answer it 
is ambiguous whether media will be flowing on the bundle port even 
though the SDP says otherwise, or if the media will be flowing on these 
'half different" 5-tuples.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Sep 2013 16:47:11 -0400

On 8/30/13 8:43 AM, Christer Holmberg wrote:
> If so, we can make the text in Section 6.4.3, because it more or less uses the procedures defined in Section 6.4.1.

Yes. I think we can just say that when an m-line is added, it muust 
contain either a unique address or the (existing or new) bundle address.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> ------------------------------------------
>
>
> OLD TEXT (-04):
> ---------------------
>
>
> 6.4.3.  Adding a media description to a BUNDLE group
>
>     When an Offerer adds an "m=" line to a BUNDLE group, the Offerer MUST
>     assign either a unique address, or the BUNDLE address associated with
>     the BUNDLE group, to the added "m=" line.  In addition, the Offerer
>     MUST assign a mid value to the "m=" line, and place the mid in the
>     SDP group:BUNDLE attribute mid list associated with the BUNDLE group,
>     in order to group the "m=" line to the BUNDLE group.
>
>     NOTE: If the Offerer assigns a unique address to the added "m=" line,
>     it allows the Answerer to move the "m=" line out of the BUNDLE group
>     without having to reject the "m=" line ([ref-to-be-added]).
>
>     To the previously added "m=" lines in the BUNDLE group, the Offerer
>     assigns either unique addresses or the BUNDLE address associated with
>     the BUNDLE group, according to the procedures in Section 6.4.1.
>
>     Section 10.3 shows an example of an SDP Offer used to add an "m="
>     line to a BUNDLE group.
>
>
> NEW SUGGESTED TEXT (-04):
> --------------------------------------
>
>
> 6.4.3.  Adding a media description to a BUNDLE group
>
>     When an Offerer adds a new "m=" line to a previously negotiated BUNDLE group, the
>     Offerer assigns an address to the new "m=" line according to the procedures in Section
>     6.4.1. If the Offerer assigns a BUNDLE address (previously negotiated, or a suggested
>     new Address) to the previously negotiated "m=" lines in the BUNDLE group, the Offerer
>     can assign the same address to the new "m=" line. Alternatively, the Offerer can assign
>     a unique address to the new "m=" line.
>
>     NOTE: If the Offerer assigns a unique address to the added "m=" line,
>     it allows the Answerer to move the "m=" line out of the BUNDLE group
>     without having to reject the "m=" line ([ref-to-be-added]).
>
>     Section 10.3 shows an example of an SDP Offer used to add an "m="
>     line to a BUNDLE group.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 27. elokuuta 2013 16:43
> To: [email-masked]
> Subject: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses.
>
> This seems reasonable to me.
>
> 	Thanks,
> 	Paul
>
> On 8/23/13 6:39 AM, Christer Holmberg wrote:
>> Hi,
>>
>> One of the open issues related to BUNDLE presented in Berlin (Q5 in my
>> slides) was whether, once a BUNDLE address is re-negotiated (i.e. the
>> usage of BUNDLE etc has already been negotiated), it is allowed to
>> assign the new suggested BUNDLE address to all "m=" lines immediately,
>> instead of doing the 2-step Offer/Answer procedure. The outcome was
>> that it shall be allowed.
>>
>> So, based on that, I am suggesting the change below to section 6.1.4
>> of BUNDLE.
>>
>> NOTE that this only applies to the case where a BUNDLE address is
>> RE-negotiated (e.g. in a re-INVITE). There is still a discussion about
>> the initial Offer, and that outcome of that (and the outcome of the UP
>> discussions) may obviously also impact the text. But, let's keep that
>> separate for now, and only focus on the case when a BUNDLE address is
>> RE-negotiated :)
>>
>> Regards,
>>
>> Christer
>>
>> -------------------------------------------
>>
>> OLD TEXT (BUNDLE-04):
>>
>> ====================
>>
>> 6.4.1.  SDP Offerer Bundle Address Request and Usage
>>
>>      An Offerer can assign a BUNDLE address to multiple "m=" lines in a
>>
>>      BUNDLE group, once the Answerer has selected the BUNDLE address
>> for
>>
>>      the Offerer.  An Offerer MUST NOT assign a BUNDLE address to
>> multiple
>>
>>      "m=" lines until the Answerer has selected the BUNDLE address.
>>
>>      OPEN ISSUE: Should it be allowed to assign a new BUNDLE address to
>>
>>      multiple "m=" lines in a BUNDLE group, before the Answerer has
>>
>>      selected the BUNDLE address?
>>
>>      In order to negotiate (or, to re-negotiate) the BUNDLE address
>>
>>      associated with a BUNDLE group, the Offerer, in the SDP Offer,
>>
>>      assigns a unique address to each "m=" line in the BUNDLE group.
>> In
>>
>>      addition, the Offerer indicates which unique address it wishes the
>>
>>      Answerer to select as the Offerer's BUNDLE address.  The Offerer
>>
>>      places the mid, associated with the unique address requested to be
>>
>>      selected as the BUNDLE address, first in the SDP group:BUNDLE
>>
>>      attribute mid list.  The Answerer will then select the BUNDLE
>> address
>>
>>      for the Offerer ([ref-to-be-added]).
>>
>>      If the Offerer, in a subsequent SDP Offer, wants to re-negotiate
>> the
>>
>>      BUNDLE address associated with a BUNDLE group, it MAY assign the
>>
>>      previously negotiated BUNDLE address as a unique address to one of
>>
>>      the "m=" lines in the BUNDLE group.
>>
>>      If the Offerer assigns the previously selected BUNDLE address to
>> more
>>
>>      than one "m=" line in a BUNDLE group, the first mid in the SDP
>>
>>      group:BUNDLE attribute mid list MUST represent an "m=" line to
>> which
>>
>>      the BUNDLE address is assigned.  Hence, in order to re-negotiate
>> the
>>
>>      BUNDLE address, the Offerer needs to assign a unique address to
>> each
>>
>>      "m=" line in the BUNDLE group, as described above.
>>
>>      An Offerer MUST NOT assign a BUNDLE address to an "m=" line that
>> is
>>
>>      not associated with a BUNDLE group.  An Offerer MUST NOT assign a
>>
>>      BUNDLE address, that has been negotiated for a BUNDLE group, to an
>>
>>      "m=" line that is associated with another BUNDLE group.
>>
>>      Section 10.1 shows an example of a Bundle Address Request.
>>
>> SUGGESTED NEW TEXT:
>>
>> ===================
>>
>> 6.4.1.  SDP Offerer Bundle Address Request and Usage
>>
>>
>>
>>      An Offerer can assign a BUNDLE address to multiple "m=" lines in a
>>
>>      BUNDLE group, once the Answerer has selected the BUNDLE address
>> for
>>
>>      the Offerer.  An Offerer MUST NOT assign a BUNDLE address to
>> multiple
>>
>>      "m=" lines until the Answerer has selected the BUNDLE address.
>>
>>
>>
>>      Before the Answerer has selected a BUNDLE address for the Offerer,
>>
>>      in order to negotiate the BUNDLE address associated with a BUNDLE
>>
>>      group, the Offerer, in the SDP Offer, assigns a unique address to
>>
>>      each "m=" line in the BUNDLE group. In addition, the Offerer
>> indicates
>>
>>      which unique address it wishes the Answerer to select as the
>>
>>      Offerer's BUNDLE address. The Offerer places the mid, associated
>>
>>      with the unique address requested to be selected as the BUNDLE
>> address,
>>
>>      first in the SDP group:BUNDLE attribute mid list.  The Answerer
>> will
>>
>>      then select the BUNDLE address for the Offerer ([ref-to-be-added]).
>>
>>
>>
>>      If an Offerer, in a subsequent SDP Offer, wants to re-negotiate
>> the
>>
>>      BUNDLE address associated with a BUNDLE group, it can either:
>>
>>
>>
>> -     Assign the requested new BUNDLE address to all "m=" lines in the
>>
>> BUNDLE group; or
>>
>> -     In the same way as described in the procedures above, assign a
>>
>> unique address to each "m=" line in the BUNDLE group (the previously
>>
>> negotiated BUNDLE address can also be assigned as a unique address
>>
>> to one of the "m=" lines in the BUNDLE group).
>>
>>
>>
>>      In both cases, the Offerer places the mid, associated with the
>> unique
>>
>>      address requested to be selected as the BUNDLE address, first in
>> the
>>
>>      SDP group:BUNDLE attribute mid list (if the requested new BUNDLE
>> address
>>
>>      is assigned to all "m=" lines in the BUNDLE group, all mids in the
>> SDP
>>
>>      group:BUNDLE attribute mid list will represent that same address).
>>
>>
>>
>>      An Offerer MUST NOT assign a BUNDLE address to an "m=" line that
>> is
>>
>>      not associated with a BUNDLE group.  An Offerer MUST NOT assign a
>>
>>      BUNDLE address, that has been negotiated for a BUNDLE group, to an
>>
>>      "m=" line that is associated with another BUNDLE group.
>>
>>
>>
>>      Section 10.1 shows an example of a Bundle Address Request.
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Sep 2013 11:30:33 +0000

Hi,

Currently, when one reads BUNDLE, one might get the impression that, in an Offer:

1) Each m- line in a BUNDLE group must have a unique address; or
2) Each m- line in a BUNDLE group must have a BUNDLE address

But, I guess there is no reason why there can't be a "mix". It for sure might be the case when an m- line is added (e.g. the new m- line may have a unique address, while the other m- lines have a previously negotiated BUNDLE address), but maybe there are also other cases (depending in the outcome of bundle-only, that may be a case where the bundle-only m- lines have a common address, while other m- lines have a unique address).

At the end of the day, it comes down to the fact that: the Offer indicates which address it wants to become the BUNDLE address, the Answerer selects it, and the Offerer needs to decide whether a 2nd Offer is needed.

There might be a need to make it more clear in the draft.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Paul Kyzivat [mailto:[email-masked]] 
Lähetetty: 2. syyskuuta 2013 23:47
Vastaanottaja: Christer Holmberg
Kopio: [email-masked]
Aihe: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses.

> If so, we can make the text in Section 6.4.3, because it more or less uses the procedures defined in Section 6.4.1.

Yes. I think we can just say that when an m-line is added, it muust contain either a unique address or the (existing or new) bundle address.

	Thanks,
	Paul

>> assign the new suggested BUNDLE address to all "m=" lines 
>> immediately, instead of doing the 2-step Offer/Answer procedure. The 
>> outcome was that it shall be allowed.
>>
>> RE-negotiated (e.g. in a re-INVITE). There is still a discussion 
>> about the initial Offer, and that outcome of that (and the outcome of 
>> the UP
>>      is assigned to all "m=" lines in the BUNDLE group, all mids in 
>> the SDP
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Sep 2013 09:42:24 -0400

> There might be a need to make it more clear in the draft.

I think we are in agreement.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 3 Sep 2013 09:07:46 -0500

On Tue, Sep 3, 2013 at 6:30 AM, Christer Holmberg <
[email-masked]> wrote:

> But, I guess there is no reason why there can't be a "mix". It for sure
> might be the case when an m- line is added (e.g. the new m- line may have a
> unique address, while the other m- lines have a previously negotiated
> BUNDLE address), but maybe there are also other cases (depending in the
> outcome of bundle-only, that may be a case where the bundle-only m- lines
> have a common address, while other m- lines have a unique address).
>
> At the end of the day, it comes down to the fact that: the Offer indicates
> which address it wants to become the BUNDLE address, the Answerer selects
> it, and the Offerer needs to decide whether a 2nd Offer is needed.
>
[MB] Yeah - given the complexity and the details around this, it might be
really helpful to include some indented paragraphs that capture the essence
as in your "At the end of the day..." paragraph.  This was done in another
RFC (I can't remember which one) and I thought it really helped to
clarify/summarize some of the key concepts. [/MB]

> Aihe: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is
> RE-negotiated, the Offerer can assign the requsted new address to all m-
> lines immediately, without first offering unique addresses.
>
> > We also need to decide whether that change also applies to when new
> media descriptions (m- line) are added to a previously negotiated BUNDLE
> group.
> >
> > Currently the text says that, when an m- line is added, it must contain
> either a unique address, or a previously negotiated BUNDLE address.
> >
> > But, since we now allow to assign a new, yet not confirmed, BUNDLE
> address to multiple m- lines, I guess that applies also to a new m- line.
> >
> > If so, we can make the text in Section 6.4.3, because it more or less
> uses the procedures defined in Section 6.4.1.
>
> > Subject: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is
> RE-negotiated, the Offerer can assign the requsted new address to all m-
> lines immediately, without first offering unique addresses.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Sep 2013 10:37:14 +0000

Hi,

>>> The change is that an Offerer is now allowed to assign the same 
>>> address (the requested BUNDLE address) to all m- lines in the BUNDLE group BEFORE the Answerer has "confirmed" the address to become the Offerer's BUNDLE address.
>>>
>>> But, if any of the m- lines in the offer did NOT contain the selected 
>>> BUNDLE address, a second Offer is still required :)
>>
>> As the offerer, if you want to add an m-line with bundle, simply use 
>> the the same port numbers as the existing bundle.  If the answerer responds with its same port number for its side of the bundle, you're 
>> done.  If the answerer decides it didn't want that new m-line to be bundled, it will simply pick a new port number in its answer.  You're 
>> still done.  Because it's not the same 5-tuple. (it happens to be the same local source port number on the offerer, but not the same dest 
>> port) If the offerer now wants a new local port number for some reason (like it can't handle distinguishing full 5-tuples) it can send another 
>> offer to use a new port number for that m-line.
>
> On reflection, I still think its clever, but I think it presents a complication:
>
> Suppose this procedure was carried out between X and Y. So for some "bundled " m-line X has its bundle port, while Y has a unique port.
> Then Y has need to send an offer to X, but has no desire to change anything about this bundle of m-lines. What does it put into the offer? 
> Then what are the rules for X to put in the answer? The existing rules would have it put its bundle address/port in. Then Y is expected to send 
> another offer to put all the bundled m-lines onto the bundle port. But to achieve its goal of keeping that m-line unbundled (to it) Y won't want 
> to do that.
>
> The rules can be changed to make this valid. But if so, I think that is a significant change. For middle boxes, when getting the first answer it is 
> ambiguous whether media will be flowing on the bundle port even though the SDP says otherwise, or if the media will be flowing on these 

I'm sure we could make it work. But, I thought we had a decision to NOT allow a given address to act as both a BUNDLE address (maybe even for more than one BUNDLE group...) and unique address at the same time. Instead, any given address acts as EITHER:

1)	A unique address; OR
2)	A BUNDLE address for ONE BUNDLE group

Unless something goes wrong, I would not like to reverse that decision.

So, in case the Offerer adds a new m- line to a BUNDLE group, but assigns a unique address, and the Answerer accepts the m- line into the BUNDLE group, the Offerer MUST send a second Offer, where it assigns its BUNDLE address to the new m- line. That is consistent with the general rules. 

And, if the Offerer wants to avoid having to send a second Offer, it can assign the BUNDLE address to the new m- line already in the first Offer. Of course, if the Answerer doesn't accept the new m- line into the BUNDLE group, it will have to reject it (THEN, the Offerer can of course choose to send a 2nd Offer, where the m- line isn't even part of the BUNDLE group to begin with. But, that is normal 3264 procedure, outside the scope of BUNDLE).

Regards,

Christer