Subject: [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: Fri, 23 Aug 2013 10:39:34 +0000

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Aug 2013 09:42:44 -0400

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.
>
> 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
>
> -     Assign the requested new BUNDLE address to all “m=” lines in the
>
> BUNDLE group; or
>
> unique address to each “m=” line in the BUNDLE group (the previously
>
> to one of the “m=” lines in the BUNDLE group).
>
>
>
>     is assigned to all “m=” lines in the BUNDLE group, all mids in the SDP
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Aug 2013 12:43:56 +0000

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.

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.

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.

	Thanks,
	Paul

On 8/23/13 6:39 AM, Christer Holmberg wrote:
> 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.
>
> discussions) may obviously also impact the text. But, let's keep that

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Aug 2013 09:10:26 -0400

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

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Aug 2013 13:39:02 +0000

Hi,

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

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Aug 2013 16:27:44 -0400

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

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 31 Aug 2013 06:55:21 +0000

Hi,

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

That is a separate topic, more related to the Answerer procedures, and is not alligned with the current BUNDLE text. Currently, if an m- line (no matter whether it is a new m- line, or a previously added one) in an Offer contains a BUNDLE address, and the Answerer doesn't want it to be bundled, it MUST be rejected with port zero.

We have been discussing, and it is what my original bundle proposal described, the usage of a single address on the Offerer side even if the Answerer uses separate ports, and I thought we decided not to go that way...

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 31 Aug 2013 07:52:15 -0400

On Aug 31, 2013, at 2:55 AM, Christer Holmberg <[email-masked]> wrote:

> We have been discussing, and it is what my original bundle proposal described, the usage of a single address on the Offerer side even if the Answerer uses separate ports, and I thought we decided not to go that way…

No the issue with the Offer using the same ports is an issue for the *initial* offer, before the offerer knows the far-end supports bundle.  In the above I was talking about the subsequent offers/answers, once the offerer knows the far-end supports bundle.

Regardless, I suppose we really do need to have the 'bundle-only' attribute anyway, just to enable the offerer to say "I am only offering these m-lines using the same bundle transport, and if you don't want to do that then I want them to not be used at all".

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 31 Aug 2013 15:36:06 +0000

Hi,

>> That is a separate topic, more related to the Answerer procedures, and is not alligned with the current BUNDLE text. Currently, if an 
>> m- line (no matter whether it is a new m- line, or a previously added one) in an Offer contains a BUNDLE address, and the Answerer 
>> doesn't want it to be bundled, it MUST be rejected with port zero.
>>

Fair enough. But, it's still not specific to 'bundle-only' m- lines.

> Regardless, I suppose we really do need to have the 'bundle-only' attribute anyway, just to enable the offerer to say "I am only offering these m-lines using the same bundle transport, and if you d…

With the CURRENT rules you do that by assigning the BUNDLE address to those m- lines, because the Answerer must reject them in case they are removed from the BUNDLE group.

But, IF we want to change that (for mid-call O/As), there might be a need for an explicit attribute.

In any case, we can work on the text for now, and then later throw it away if we find out it's not needed :)

Regards,

Christer