Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Jun 2013 14:12:25 +0000

Hi,

I've gone through the comments received, and made some conclusions.

First, defining Offer "types" was probably not a good idea. It caused confusion, and it was unclear whether it refers to the whole SDP body, or only individual BUNDLE groups within it. So, I've removed the BSO and BRO. I HAVE defined a procedure called  'Bundle Address Synchronization (BAS)', which is basically what the BSO was previously used for. But, it is not a new Offer type, it is simply a procedure that an Offerer does (using an SDP Offer, though).

Also, we probably DO need more text on when a BAS is needed, but I hope you understand what the intention of it is :)

Second, there were different opinions on how flexible the mechanism should be when it comes to re-negotiating the bundle address, and whether it should be allowed to do it in the same Offer used to e.g. adding an m= line. I tried to come up with a compromise:

What Paul wanted, but didn't get:

-          Paul wanted to be able to assign a new bundle address to multiple m- line, even if the bundle address hasn't been negotiated yet.

What Paul got:

-          In order to negotiate/re-negotiate a bundle address, the Offerer MUST assign unique addresses to each m- line. There Offerer CANNOT simply add a new bundle address to multiple m- lines, until it has been negotiated.

What Martin wanted, but didn't get:

-          Martin wanted to use separate O/A transactions for negotiating the bundle address, and for adding m- lines to a BUNDLE group.

What Martin got:

-          It IS allowed to add an m- line, and re-negotiate the bundle address, in the same SDP Offer. However, as described above, in that case the Offerer needs to assign unique addresses to each m- line.

I am not saying we can't change what you got, and didn't get, but just keep the assumptions above in mind when you read the text :)

Third, I removed "Use Cases" section naming. The procedures contains lots of normative text, while Use Cases are normally informative, and used to provide background information.

Fourth, I know the especially Martin suggested some terminology changes. I didn't forget those, but as many of those are no more valid, I thought it's better to work based on the new text.

Fifth, in section 6.1, please do not spend too much time on the numbered list at this point. It is still something we need to discuss, but I believe we need to make some progress on the Plan A vs B stuff first.

At least I personally think the text is more clear, and easier to understand, now :)

Regards,

Christer

-----------------------------------------------

6.  SDP Offer/Answer Procedures

6.1.  General

   This section describes the usage of the SDP Offer/Answer mechanism
   [RFC3264] to negotiate the usage of the BUNDLE mechanism, to
   negotiate the bundle address, and to add, remove and reject SDP Media
   Descriptions ("m=" lines) associated with a BUNDLE group.

   The generic rules and procedures defined in [RFC3264] and [RFC5888]
   apply when the SDP Offer/Answer mechanism is used for BUNDLE.  For
   example, if an SDP Offer is rejected, the previously negotiated SDP
   parameters and characteristics (including those associated with
   BUNDLE groups) apply.

   When an endpoint generates an SDP Offer, or an SDP Answer, which
   contains a BUNDLE group, the endpoint MUST assign SDP media-level mid
   value for each "m=" line in the BUNDLE group.  In addition, the
   endpoint MUST insert an SDP session-level group:BUNDLE attribute, and
   place each mid value associated with the BUNDLE group in the
   attribute mid value list.

   Until the Offerer knows whether the Answerer supports the BUNDLE
   mechanism, the Offerer MUST, for each "m=" line in a BUNDLE group:

   o  1.  Insert a unique address.

   o  2.  Insert different SDP 'rtcp' attribute value, when used.

   o  3.  Insert an SDP 'rtpc-mux' attribute.

   o  4.  Insert identical DTLS-SRTP fingerprint attribute, when used

   o  5.  Insert different SDES crypto attribute, when used

   Once it is known that both endpoints support the BUNDLE grouping
   extension, the SDP Offerer and Answerer MUST, for each "m=" line
   associated with a BUNDLE group:

   o  1.  Insert either a unique address, or the bundle address
      associated with the BUNDLE group (see sections below for details).

   o  2.  Insert identical SDP 'rtcp' attribute value, when used.

   o  3.  Insert an SDP 'rtpc-mux' attribute.

   o  4.  Insert identical DTLS-SRTP fingerprint attribute, when used

   o  5.  Insert different SDES crypto attribute, when used

   READER'S HELP: The detailed definition of the 'Unique Address' and
   'Bundle Address' terminology will be elsewhere in the document, but
   is basically contains the IP address, IP port and ICE candidates.
   Perhaps also media security parameters?

6.2.  SDP Offerer Procedures

6.2.1.  SDP Offerer Bundle Address Request and Usage

   An Offerer can assign an address to multiple "m=" lines in a BUNDLE
   group, once the address has been selected as the Offerer's local
   bundle address.  An Offerer MUST NOT assign an address to multiple
   "m=" lines until the address has been selected as a bundle address
   for that BUNDLE group.

   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 to use
   as its local bundle address.  There Offerer places the mid value,
   associated with the "m=" line that contains the preferred address
   first in the SDP group:BUNDLE attribute mid list.  The Answerer then
   selects the local 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 bundle address to more than one "m=" line
   in a BUNDLE group, the first mid value in the SDP group:BUNDLE
   attribute mid value 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.

   Example: The example shows an SDP Offer, where a unique address is
   assigned to each "m=" line in the BUNDLE group.  The Offerer requests
   the address associated with the audio "m=" line to be selected as its
   local bundle address, by placing the mid value associated with the
   "m=" line first in the SDP group:BUNDLE attribute mid value list.

   SDP Offer

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo bar
       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       m=video 20000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000

6.2.2.  Bundle Address Synchronization (BAS)

   When an Offerer has sent an SDP Offer, a bundle address has been
   selected by the Answerer, and the bundle address was in the SDP Offer
   not assigned to each "m=" line in the BUNDLE group, the Offerer MUST
   send a new SDP Offer, in which it assigns the negotiated bundle
   address to each "m=" line in the BUNDLE group.  This procedure is
   referred to as Bundle Address Synchronization (BAS).

   The Offerer MUST NOT modify any parameters associated with the BUNDLE
   group when it performs a BAS.

   NOTE: Eventhough the Offerer is not allowed to modify parameters
   associated with a BUNDLE group when it performs a BAS, the Answerer
   might modify parameters in the associated SDP Answer.  For example,
   the Answerer can in the SDP Answer reject an "m=" line, by removing
   the rejected "m=" line from the BUNDLE group and assigning a zero
   port value to the rejected "m=" line ([ref-to-be-added]).

   Example: The example shows an SDP Offer, where the Offerer assigns
   the bundle address to each "m=" line in the BUNDLE group, in order to
   perform a Bundle Address Synchronization.

   SDP Offer (BAS)

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo bar
       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       m=video 10000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000

6.2.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 "m=" line that is added.  In addition, the
   Offerer MUST assign a mid value for the "m=" line, and place it in
   the SDP group:BUNDLE attribute mid value list associated with the
   BUNDLE group.

   NOTE: If the Offerer assigns a unique address to the "m=" line that
   is added to the BUNDLE group, it allows the Answerer to remove the
   "m=" line from the BUNDLE group without having to reject the "m="
   line ([ref-to-be-added]).

   To the other "m=" lines (that previously have been added to the
   BUNDLE group), the Offerer assigns addresses according to the
   procedures in Section 6.2.1.

   Example: The example shows an SDP Offer, where a new "m=" line,
   identified by the "zen" mid value, is added to a BUNDLE group.  The
   Offerer assigns a unique address to the "m=" line, and the bundle
   address to each of the other "m=" lines in the BUNDLE group.

   SDP Offer

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo bar zen
       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       m=video 10000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000
       m=video 30000 RTP/AVP 60
       a=mid:zen
       b=AS:1000
       a=rtpmap:60 H261/90000

6.2.4.  Removing A Media Description From A BUNDLE Group

   When an Offerer removes an "m=" line from a BUNDLE group, the Offerer
   MUST assign a unique address to the "m=" line that is removed.  In
   addition, the Offerer MUST NOT place the mid value that was
   previously defined for the "m=" line in the SDP group:BUNDLE
   attribute mid value list associated with the BUNDLE group.

   To the other "m=" lines (that previously have been added to the
   BUNDLE group), the Offerer assigns addresses according to the
   procedures in Section 6.2.1.

   Example: The example shows a BRO, where an "m=" line is removed from
   a BUNDLE group.  The Offerer removes the mid ("zen") associated with
   the "m=" line from the SDP group:BUNDLE attribute mid value list, and
   assigns a unique address to the removed "m=" line.

   Example: The example shows an SDP Offer, where an "video" "m=" line
   (previously identified by the "zen" mid value), is removed from a
   BUNDLE group.  The Offerer assigns a unique address to the "m=" line,
   and the bundle address to each of the remaining "m=" lines in the
   BUNDLE group.

   SDP Offer

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo bar
       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       m=video 10000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000
       m=video 40000 RTP/AVP 60
       b=AS:1000
       a=rtpmap:60 H261/90000

6.2.5.  Rejecting A Media Description In A BUNDLE Group

   When an Offerer rejects an "m=" line in a BUNDLE group, the Offerer
   MUST assign a unique address, with a zero port value [RFC3264], to
   the "m=" line that is rejected.  In addition, the Offerer MUST NOT
   place the mid value that was previously defined for the "m=" line in
   the SDP group:BUNDLE attribute mid value list associated with the
   BUNDLE group.

   To the other "m=" lines (that previously have been added to the
   BUNDLE group), the Offerer assigns addresses according to the
   procedures in Section 6.2.1.

   Example: The example shows an SDP Offer, where an "video" "m=" line
   (previously identified by the "zen" mid value), is rejected, and
   removed from a BUNDLE group.  The Offerer assigns a unique address,
   with a zero port value, to the "m=" line, and the bundle address to
   each of the remaining "m=" lines in the BUNDLE group.

   SDP Offer

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo bar
       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       m=video 10000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000
       m=video 0 RTP/AVP 60
       a=rtpmap:60 H261/90000

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 12 Jun 2013 16:32:54 +0000

Dear Christer,

only some comments on the terminology:

"When an Offerer rejects an "m=" line in a BUNDLE group ..."
I am used to terminology where an answerer "rejects" something that is being offered, but is unclear what this means for an offerer.
I assume what you are after is "disabling" an m-line. Perhaps this terminology would be clearer?

You also speak about "Removing A Media Description From A BUNDLE Group".
I see a certain risk that people misunderstand this to also mean "disabling" an m-line.
I assume what you are after is rather "Moving A Media Description out of a BUNDLE Group". Perhaps this terminology would be clearer?

Regards, Thomas

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Christer Holmberg
Sent: Wednesday, June 12, 2013 4:12 PM
To: [email-masked]
Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)

   SDP Offer

       v=0

   SDP Offer

       v=0

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Jun 2013 17:28:38 +0000

Hi Thomas,

I used to have 'disable' for the Offerer, but there was a comment suggesting to use 'reject'. We can discuss it.

I am ok to use 'move out of' terminology, as you suggest.

Thanks!

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Belling, Thomas (NSN - DE/Munich) [[email-masked]]
To: Christer Holmberg [[email-masked]]; [email-masked] [[email-masked]]
Subject: RE: BUNDLE TEXT: Offerer procedures (June 12th)
Dear Christer,

“When an Offerer rejects an "m=" line in a BUNDLE group …”
I am used to terminology where an answerer “rejects” something that is being offered, but is unclear what this means for an offerer.
I assume what you are after is “disabling” an m-line. Perhaps this terminology would be clearer?

You also speak about “Removing A Media Description From A BUNDLE Group”.
I see a certain risk that people misunderstand this to also mean “disabling” an m-line.
I assume what you are after is rather ”Moving A Media Description out of a BUNDLE Group”. Perhaps this terminology would be clearer?

Regards, Thomas

   SDP Offer

       v=0

   SDP Offer

       v=0

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 13 Jun 2013 08:41:55 +0000

Thanks Christer,

I would clearly prefer "disable", as "reject" in my view only fits for something that is being offered.
What was the reasoning brought forward to use "reject"?

Thomas

From: ext Christer Holmberg [mailto:[email-masked]]
Sent: Wednesday, June 12, 2013 7:29 PM
To: Belling, Thomas (NSN - DE/Munich); mmusic_ietf.org
Subject: RE: BUNDLE TEXT: Offerer procedures (June 12th)

Hi Thomas,

Thanks!

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com<http://www.nitrodesk.com>)

-----Original Message-----
From: Belling, Thomas (NSN - DE/Munich) [[email-masked]]
To: Christer Holmberg [[email-masked]]; [email-masked]<mailto:[email-masked]> [[email-masked]]
Subject: RE: BUNDLE TEXT: Offerer procedures (June 12th)
Dear Christer,

Regards, Thomas

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Christer Holmberg
Sent: Wednesday, June 12, 2013 4:12 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)

   SDP Offer

       v=0

   SDP Offer

       v=0

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jun 2013 14:00:48 -0400

Christer,

We seem to be getting there.
I have more comments inline.

	Thanks,
	Paul

BTW: sorry that Thunderbird has double spaced all the included draft 
text. (Presumably because lines end with <CR><LF> and it treats each of 
those as a <NL>.)

On 6/12/13 10:12 AM, Christer Holmberg wrote:
> Hi,
>
> I’ve gone through the comments received, and made some conclusions.
>
> *First*, defining Offer “types” was probably not a good idea. It caused
> confusion, and it was unclear whether it refers to the whole SDP body,
> or only individual BUNDLE groups within it. So, I’ve removed the BSO and
> BRO. I HAVE defined a procedure called  ‘Bundle Address Synchronization
> (BAS)’, which is basically what the BSO was previously used for. But, it
> is not a new Offer type, it is simply a procedure that an Offerer does
> (using an SDP Offer, though).
>
> Also, we probably DO need more text on when a BAS is needed, but I hope
> you understand what the intention of it is :)
>
> *Second*, there were different opinions on how flexible the mechanism
> should be when it comes to re-negotiating the bundle address, and
> whether it should be allowed to do it in the same Offer used to e.g.
> adding an m= line. I tried to come up with a compromise:
>
> What Paul wanted, but didn’t get:
>
> -Paul wanted to be able to assign a new bundle address to multiple m-
> line, even if the bundle address hasn’t been negotiated yet.
>
> What Paul got:
>
> -In order to negotiate/re-negotiate a bundle address, the Offerer MUST
> assign unique addresses to each m- line. There Offerer CANNOT simply add
> a new bundle address to multiple m- lines, until it has been negotiated.

I still disagree with this. More on it inline below.

> What Martin wanted, but didn’t get:
>
> -Martin wanted to use separate O/A transactions for negotiating the
> bundle address, and for adding m- lines to a BUNDLE group.
>
> What Martin got:
>
> -It IS allowed to add an m- line, and re-negotiate the bundle address,
> in the same SDP Offer. However, as described above, in that case the
> Offerer needs to assign unique addresses to each m- line.
>
> I am not saying we can’t change what you got, and didn’t get, but just
> keep the assumptions above in mind when you read the text :)
>
> *Third*, I removed “Use Cases” section naming. The procedures contains
> lots of normative text, while Use Cases are normally informative, and
> used to provide background information.
>
> *Fourth*, I know the especially Martin suggested some terminology
> changes. I didn’t forget those, but as many of those are no more valid,
> I thought it’s better to work based on the new text.
>
> *Fifth*, in section 6.1, please do not spend too much time on the
> numbered list at this point. It is still something we need to discuss,
> but I believe we need to make some progress on the Plan A vs B stuff first.
>

Under what circumstances may the offerer presume to *know* whether the 
answerer supports BUNDLE?

The minimal answer is that if an offer included a bundle group, and the 
answer also contains a corresponding bundle group, then the answerer 
supported *that* bundle at the time of *that* answer, and continues to 
do so at least until there is another offer.

But we want to assume more - at least that if *a* bundle was supported 
by both sides in one O/A exchange, then both sides can be presumed to 
*understand* bundle, including the use of the same address info for 
multiple m-lines in a bundle offer, in future offers within the same 
signaling session.

Is, or should there be, a way to go back on that presumption - to stop 
supporting bundle? I guess if an end wanted to stop supporting bundle 
while a bundle was in effect it would need to send an offer that didn't 
include any bundles. But it might want to send such an offer just 
because it doesn't currently need a bundle though it still supports them.

Perhaps we should say that an offerer or answerer who supports bundle 
should *always* include an a=group:bundle in its offers and answers. If 
it doesn't currently want a bundle it can simply include 
"a=group:bundle" without any mid values.

>     selects the local bundle address for the Offerer ([ref-to-be-added]).

I don't understand what the last sentence above is trying to tell me.

>     "m=" line in the BUNDLE group, as described above.

I still object to this. It is a significant cost, and I don't understand 
how it adds any value over simply assigning a new address to all the 
bundled m-lines.

>     group when it performs a BAS.

I still don't understand the point of this restriction.
What value does it add?

Suppose that a need to make another change arises after the offer that 
proposed the bundle, but before the answer has been received. Then, when 
the answer is received it will be necessary to send a BAS before sending 
another offer to make the new change. Why wait?

ISTM that it would be better to say that after receiving an answer, if 
there is at that moment no need to send another offer, if the 
corresponding offer had bundled m-lines with different addresses, then a 
BAS must be sent.

>     attribute mid value list associated with the BUNDLE group.

nit: I don't think this should say anything about the mid value that was 
previously defined for the m-line. That implies that mid values must be 
preserved from one o/a to another. While they probably will in most 
cases I don't think that should be required. If I want, I should be able 
to "relabel" the m-lines with new mid values. This reduces the amount of 
state that is required to be preserved from one o/a to the next.

The statement "remove an m-line from a bundle group" already implies 
that the group does not contain a mid-value identifying that m-line (in 
*this* offer or answer).

>     Example: The example shows a BRO, where an "m=" line is removed from

The term "BRO" is no longer defined.

> 6.2.5.  Rejecting A Media Description In A BUNDLE Group

I agree with prior comment that using "Rejecting" here is weird and 
confusing. I agree that "disabling" is probably more appropriate.
But then "disabling a media description in a bundle group" is still a 
little confusing, because it is then no longer "in" the bundle group.

It might be clearer to just incorporate this into the prior section on 
removing a media description from a bundle group. E.g., in 6.2.4:

    When an Offerer removes an "m=" line from a BUNDLE group, the Offerer
    MUST assign either a unique address *or a zero port* to the "m=" line
    that is removed.

>     MUST assign a unique address, with a zero port value [RFC3264], to

as long as the port is zero the address need not be otherwise unique.

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Jun 2013 11:35:58 +0000

Hi,

>>     negotiate the bundle address, and to add, remove and reject SDP 
>>     Media Descriptions ("m=" lines) associated with a BUNDLE group.
>>
>>     The generic rules and procedures defined in [RFC3264] and 
>>     [RFC5888]apply when the SDP Offer/Answer mechanism is used for BUNDLE.  For
>>     parameters and characteristics (including those associated with BUNDLE groups) apply.
>>
>>     contains a BUNDLE group, the endpoint MUST assign SDP media-level 
>>     mid value for each "m=" line in the BUNDLE group.  In addition, the
>>     endpoint MUST insert an SDP session-level group:BUNDLE attribute, 
>>     and place each mid value associated with the BUNDLE group in the
> Under what circumstances may the offerer presume to *know* whether the answerer supports BUNDLE?
>
> The minimal answer is that if an offer included a bundle group, and the answer also contains a corresponding bundle group, then the answerer 
> supported *that* bundle at the time of *that* answer, and continues to do so at least until there is another offer.

Yes.

I was actually thinking about removing the "until the Offerer knows" text, and simply generally say that the bundle address is negotiated by assigning a unique address to each "m=" line.

But, as you want to be able to assign a bundle address to multiple "m=" lines before it has been negotiated, it would not work.

> But we want to assume more - at least that if *a* bundle was supported by both sides in one O/A exchange, then both sides can be presumed to
> *understand* bundle, including the use of the same address info for multiple m-lines in a bundle offer, in future offers within the same signaling session.

I would rather say SDP session, to keep it independent from the signaling protocol. That is the same as for any other parameter you negotiate using SDP O/A - it's valid until re-negotiated.

> Is, or should there be, a way to go back on that presumption - to stop supporting bundle? I guess if an end wanted to stop supporting bundle 
> while a bundle was in effect it would need to send an offer that didn't include any bundles. But it might want to send such an offer just because
> it doesn't currently need a bundle though it still supports them.

Sure, but if anyone then wants to start using BUNDLE again, it will send an Offer and suggest the usage.

> Perhaps we should say that an offerer or answerer who supports bundle should *always* include an a=group:bundle in its offers and 
> answers. If it doesn't currently want a bundle it can simply include "a=group:bundle" without any mid  values.

Or, we could leave it up to the signaling protocol. For SIP, one could define a media feature tag. That would also allow SIP entities to request that INVITEs are sent to entities to support BUNDLE (and have indicated so during registration).

--------------------------------------

>>     An Offerer can assign an address to multiple "m=" lines in a 
>>     BUNDLE group, once the address has been selected as the Offerer's local
>>     assigns a unique address to each "m=" line in the BUNDLE group.  
>>     In addition, the Offerer indicates which unique address it wishes to 
>>     use as its local bundle address.  There Offerer places the mid value,
>>     first in the SDP group:BUNDLE attribute mid list.  The Answerer 
>>     then selects the local bundle address for the Offerer ([ref-to-be-added]).
>

The intention is to say that the Answerer selects the Offerer's bundle address.

--------------------------------------

>>     If the Offerer, in a subsequent SDP Offer, wants to re-negotiate 
>>     the bundle address associated with a BUNDLE group, it MAY assign the
>>     If the Offerer assigns the bundle address to more than one "m=" 
>>     line in a BUNDLE group, the first mid value in the SDP group:BUNDLE
>>     bundle address, the Offerer needs to assign a unique address to 
>>     each "m=" line in the BUNDLE group, as described above.
>
> I still object to this. It is a significant cost, and I don't understand how it adds any value over simply assigning a new address to all the bundled m-lines.

The problem is not assigning a new address to all m- lines.

>From a specification perspective, it becomes a little more tricky when you add a new bundle address to some m- lines, and unique addresses to others. 

Also, the Answerer will have check and figure out that the suggested new BUNDLE address has been assigned to multiple "m=" lines, and that it therefore cannot move it out of the BUNDLE group without rejecting it, etc.

I guess one alternative could be to say that a suggested new BUNDLE address would have to be assigned to each "m=" line in the BUNDLE group. I.e. the Offerer would not be allowed to assign both a new BUNDLE address and unique addresses (e.g. for "m=" lines being added to the BUNDLE group).

--------------------------------------

>>     selected by the Answerer, and the bundle address was in the SDP 
>>     Offer not assigned to each "m=" line in the BUNDLE group, the Offerer 
>>     MUST send a new SDP Offer, in which it assigns the negotiated bundle
>>     The Offerer MUST NOT modify any parameters associated with the 
>>     BUNDLE group when it performs a BAS.
>
> Suppose that a need to make another change arises after the offer that proposed the bundle, but before the answer has been 
> received. Then, when the answer is received it will be necessary to send a BAS before sending another offer to make the new change. Why wait?
>
> ISTM that it would be better to say that after receiving an answer, if there is at that moment no need to send another offer, if the corresponding 
> offer had bundled m-lines with different addresses, then a BAS must be sent.

The main reason for not allowing any parameter modifications in the BAS was to decrease the likelihood that the Answerer would reject the BAS (because it doesn't accept the suggested parameter changes).

So, we can for sure allow parameter modifications in a BAS, but I think we need some text saying that an Offerer must perform a BAS until it is accepted.

--------------------------------------

>>     When an Offerer removes an "m=" line from a BUNDLE group, the 
>>     Offerer MUST assign a unique address to the "m=" line that is removed.  In
> nit: I don't think this should say anything about the mid value that was previously defined for the m-line. That implies that mid 
> values must be preserved from one o/a to another. While they probably will in most cases I don't think that should be required. 
> If I want, I should be able to "relabel" the m-lines with new mid values. This reduces the amount of state that is required to be 
> preserved from one o/a to the next.
>
> The statement "remove an m-line from a bundle group" already implies that the group does not contain a mid-value identifying that m-line (in
> *this* offer or answer).

Maybe I could say that the mid value that was previously defined is no more valid, and must not be present in any Offer or Answer.

--------------------------------------

>> I agree with prior comment that using "Rejecting" here is weird and confusing. I agree that "disabling" is probably more appropriate.
>> But then "disabling a media description in a bundle group" is still a little confusing, because it is then no longer "in" the bundle group.
>>
>> It might be clearer to just incorporate this into the prior section on removing a media description from a bundle group. E.g., in 6.2.4:
>>

I at least intend to put back "disabling". I was also thinking about combining the sections, as you suggest, as the only difference is that
the port value is set to zero in the reject/disable case.

>>     When an Offerer rejects an "m=" line in a BUNDLE group, the 
>>     Offerer MUST assign a unique address, with a zero port value [RFC3264], to
>

True. I guess your suggested text above ("unique address or a zero port") will fix that.

As a side note, I intend to replace "unique address" and "bundle address" with "unique transport parameters" and "bundle transport parameters", as suggested by Martin.

...except in cases where the text actually talks about the IP address, that is :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Jun 2013 13:30:05 +0000

Hi Paul,

I will try to submit a new version of the BUNDLE draft today, or at latest during the weekend.

I have done quite much re-structuring/re-wording, and I also try to implement most of your suggestions.

Allowing the Offerer to assign a new BUNDLE address to multiple "m=" lines will require some editorial work, though, so I would like to have some more discussions about it before I change the text. Just to make sure you don't think that I don't care about your opinion :)

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 14. kesäkuuta 2013 14:36
To: Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)

Hi,

> The minimal answer is that if an offer included a bundle group, and 
> the answer also contains a corresponding bundle group, then the answerer supported *that* bundle at the time of *that* answer, and continues to do so at least until there is another offer.

Yes.

> while a bundle was in effect it would need to send an offer that didn't include any bundles. But it might want to send such an offer just because it doesn't currently need a bundle though it still supports them.

> should *always* include an a=group:bundle in its offers and answers. If it doesn't currently want a bundle it can simply include "a=group:bundle" without any mid  values.

> proposed the bundle, but before the answer has been received. Then, when the answer is received it will be necessary to send a BAS before sending another offer to make the new change. Why wait?
>
> there is at that moment no need to send another offer, if the corresponding offer had bundled m-lines with different addresses, then a BAS must be sent.

> nit: I don't think this should say anything about the mid value that 
> was previously defined for the m-line. That implies that mid values must be preserved from one o/a to another. While they probably will in most cases I don't think that should be required.
> If I want, I should be able to "relabel" the m-lines with new mid 
> values. This reduces the amount of state that is required to be preserved from one o/a to the next.
>

>>    MUST assign either a unique address *or a zero port* to the "m=" line

I at least intend to put back "disabling". I was also thinking about combining the sections, as you suggest, as the only difference is that the port value is set to zero in the reject/disable case.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Jun 2013 14:34:23 -0400

Hi Christer,

More discussion inline.

> I would rather say SDP session, to keep it independent from the signaling protocol. That is the same as for any other parameter you negotiate using SDP O/A - it's valid until re-negotiated.

Sure, I think "SDP session" will work.

> Sure, but if anyone then wants to start using BUNDLE again, it will send an Offer and suggest the usage.

My point was that if support for bundle can be presumed, then it no 
longer is necessary to offer unique address info for each m-line when 
adding to bundles or proposing new bundles.

In particular, this becomes significant for the bundle splitting case:

1) X sends offer to Y proposing a bundle, uses unique address info
2) Y sends answer to x accepting the bundle,
    but rejecting some of the m-lines in it
3) X sends a BAS to Y to finalize the initial bundle.
4) Y sends answer to X accepting the BAS
5) Y sends offer to X keeping the existing bundle,
    and proposing a new bundle for the previously rejected
    m-lines. Because it knows X supports bundle, and it knows
    that X was willing to have the m-lines in question bundled,
    this offer is in the form of a BAS, with all the m-lines
    in the new bundle having common address info.
6) X sends answer to Y, presumably accepting both bundles.

In this case it is quite wasteful if Y has to provide separate address 
info for each of the m-lines in the new bundle, and then yet another BAS 
has to be exchanged to fix that up.

Of course being able to presume support also is useful in cases where no 
bundle splitting is needed. E.g., Y was able to accept the initial 
bundle from X in full. Then later it wanted to offer an additional 
separate bundle. And it could also cover the case where an initial O/A 
is done when no bundle is yet needed, but *support* for bundle is 
negotiated. Then later, when a bundle is needed, it may be offered in 
BAS form, so only a single O/A is required.

The above also points out another issue: (3) & (4) are quite a waste. It 
would be nice to be able to avoid them in this case. One way to achieve 
that would be to put the burden on the answerer that accepts a bundle 
where the address info is not all the same to send the BAS. In this case 
that would mean that (5) would also serve as a substitute for (3), and 
(6) would then substitute for (4).

> Or, we could leave it up to the signaling protocol. For SIP, one could define a media feature tag. That would also allow SIP entities to request that INVITEs are sent to entities to support BUNDLE…

Yes, we could. I don't have a strong preference one way or the other.

I'm still having trouble making sense of this. Let me break out some 
things to try and understand. (I'm trying to state what I think you 
mean, not as it ought to be written in a draft, just for maximal clarity.)

It is the *answer* that selects the m-line that defines the bundle 
addresses for both offerer and answerer. Until then it isn't known.

Only after the bundle addresses are known may an offer be sent that has 
a common address for multiple m-lines in the bundle, and if so it must 
be the one that was previously defined as the bundle address.

As a consequence, on the initial offer that proposes a bundle, every 
m-line must have unique address info.

When sending an subsequent offer, after a bundle has previously been 
defined, (so the bundle addresses are known), multiple m-lines in that 
bundle *may* be offered with the same address info, but that address 
info must be the previously agreed bundle address.

As a consequence, to *change* a previously agreed bundle address, an 
offer must be sent where every m-line in the bundle has unique address info.

Does that accurately restate what you meant above?

(If so, you know that I don't agree - I find it much more prescriptive 
than it needs to be, with negative consequences. But lets be certain we 
agree what you are intending to say first.)

Then what is the problem?

> Also, the Answerer will have check and figure out that the suggested new BUNDLE address has been assigned to multiple "m=" lines, and that it therefore cannot move it out of the BUNDLE group withou…

Yes. That doesn't seem to be any great burden.

> I guess one alternative could be to say that a suggested new BUNDLE address would have to be assigned to each "m=" line in the BUNDLE group. I.e. the Offerer would not be allowed to assign both a n…

Even that seems over prescriptive.

ISTM that the problem is being driven by what is easy to describe, 
rather than what is useful to do, even though the actual implementation 
effort would probably be the same or even less difficult.

While I do agree that clarity of explanation is important, that tells me 
we need to continue to work to find a clear way to express constraints 
without being over restrictive.

I previously tried - offering a set of constraints on offers and answers 
that I thought covered the cases. I still think that could work.

You mean in the sense that the entire offer would be rejected at the 
signaling level - e.g., a sip 488?

The trouble is that this also disallows reasonable and non-risky 
changes, such as dropping an m-line, or reducing the set of codecs 
offered to a subset of what had been agreed.

> So, we can for sure allow parameter modifications in a BAS, but I think we need some text saying that an Offerer must perform a BAS until it is accepted.

Sure, that would be ok. And there could be a note that the offerer 
should try to construct the BAS to minimize the possibility that it will 
be rejected.

The mid values from the previous o/a have *no* relevance to the new o/a.
It is *possible* (though not likely) that some of the same values may be 
used in the new offer to identify *different* m-lines. So saying that a 
value from a previous o/a must not be present is also not correct.

I don't think you need to say anything about this. Possibly you could 
say that the bundle group identifies the m-lines that are to be in the 
bundle, and so must not mention m-lines that are no longer in the 
bundle. But this is so obvious that stating it is likely to confuse 
people more than not stating it.

WFM.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Jun 2013 14:35:11 -0400

Sure, this is all good.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Jun 2013 20:45:28 +0000

Hi,

>>> But we want to assume more - at least that if *a* bundle was 
>>> supported by both sides in one O/A exchange, then both sides can be 
>>> presumed to
>>> Is, or should there be, a way to go back on that presumption - to 
>>> stop supporting bundle? I guess if an end wanted to stop supporting 
>>> bundle while a bundle was in effect it would need to send an offer that didn't include any bundles. But it might want to send such an offer just because it doesn't currently need a bundle though it still supports them.
>>
> My point was that if support for bundle can be presumed, then it no longer is necessary to offer unique address info for each m-line when adding to bundles or proposing new bundles.

Ok, I hear you. Yes, IF we allow that it is important that it is clear when one can assume that the Answerer supports BUNDLE.

> In this case it is quite wasteful if Y has to provide separate address info for each of the m-lines in the new bundle, and then yet another BAS has to be exchanged to fix that up.
>
> Of course being able to presume support also is useful in cases where no bundle splitting is needed. E.g., Y was able to accept the initial bundle from X in full. Then later 
> it wanted to offer an additional separate bundle. And it could also cover the case where an initial O/A is done when no bundle is yet needed, but *support* for bundle is 
> negotiated. Then later, when a bundle is needed, it may be offered in BAS form, so only a single O/A is required.
>
> The above also points out another issue: (3) & (4) are quite a waste. It would be nice to be able to avoid them in this case. One way to achieve that would be to put the burden
> on the answerer that accepts a bundle where the address info is not all the same to send the BAS. In this case that would mean that (5) would also serve as a substitute for (3), and

I understand what you're saying, and I'll dig more into it once I get -04 submitted :) 

I have added it as an Open Issue in -04, though.

> I'm still having trouble making sense of this. Let me break out some things to try and understand. (I'm trying to state what I think you mean, not as it ought to be written in a draft, just for maximal clarity.)
>
> It is the *answer* that selects the m-line that defines the bundle addresses for both offerer and answerer. Until then it isn't known.

Correct. 

> Only after the bundle addresses are known may an offer be sent that has a common address for multiple m-lines in the bundle, and if so it must be the one that was previously defined as the bundle address.

Correct.

> As a consequence, on the initial offer that proposes a bundle, every m-line must have unique address info.

Correct.

> When sending an subsequent offer, after a bundle has previously been defined, (so the bundle addresses are known), multiple m-lines in that bundle *may* be offered with the same address info, but that address info must be the previously agreed bundle address.

Correct.

> As a consequence, to *change* a previously agreed bundle address, an offer must be sent where every m-line in the bundle has unique address info.

Correct. 

Yes.

> (If so, you know that I don't agree - I find it much more prescriptive than it needs to be, with negative consequences. But lets be certain we agree what you are intending to say first.)

It seems we have a common understanding of what is currently specified :)

And, even with your suggestion, the answerer would still select the bundle addresses for both the offerer and the answerer. But, there might of course
 not be too many addresses to choose from in the offer (e.g. if each m- line in the offer has the suggested new bundle address).

Also, even with your suggestion I guess that at least the initial offer would need to have unique addresses for each m- line, as it is yet not known
 whether BUNDLE is supported within that particular SDP session.

>> Also, the Answerer will have check and figure out that the suggested new BUNDLE address has been assigned to multiple "m=" lines, and that it
>> therefore cannot move it out of the BUNDLE group without rejecting it, etc.
>
>
>> I guess one alternative could be to say that a suggested new BUNDLE address would have to be assigned to each "m=" line in the BUNDLE group. I.e. the Offerer
>> would not be allowed to assign both a new BUNDLE address and unique addresses (e.g. for "m=" lines being added to the BUNDLE group).
>>
> ISTM that the problem is being driven by what is easy to describe, rather than what is useful to do, even though the actual implementation effort would probably be the same or even less difficult.
>
> While I do agree that clarity of explanation is important, that tells me we need to continue to work to find a clear way to express constraints without being over restrictive.
>
> I previously tried - offering a set of constraints on offers and answers that I thought covered the cases. I still think that could work.

Ok, once I've submitted -04, I'll continue to work on text for that, while allowing people to review the rest of the procedures.

>>> Suppose that a need to make another change arises after the offer 
>>> that proposed the bundle, but before the answer has been received. Then, when the answer is received it will be necessary to send a BAS before sending another offer to make the new change. Why wait?
>>>
>>> ISTM that it would be better to say that after receiving an answer, 
>>> if there is at that moment no need to send another offer, if the corresponding offer had bundled m-lines with different addresses, then a BAS must be sent.
>>
> You mean in the sense that the entire offer would be rejected at the signaling level - e.g., a sip 488?

Yes.

> The trouble is that this also disallows reasonable and non-risky changes, such as dropping an m-line, or reducing the set of codecs offered to a subset of what had been agreed.

True.

> Sure, that would be ok. And there could be a note that the offerer should try to construct the BAS to minimize the possibility that it will be rejected.

In the draft that I intend to submit soon I have removed the restriction, but I'll try to add a note before submitting.

> It is *possible* (though not likely) that some of the same values may be used in the new offer to identify *different* m-lines. So saying that a value from a previous o/a must not be present is also not correct.
>
> I don't think you need to say anything about this. Possibly you could say that the bundle group identifies the m-lines that are to be in the bundle, and so must 
> not mention m-lines that are no longer in the bundle. But this is so obvious that stating it is likely to confuse people more than not stating it.

The to-be-submitted text basically only says that the mid must no longer be used to associate the removed/rejected/disabled m- line with the BUNDLE group.

>> I at least intend to put back "disabling". I was also thinking about 
>> combining the sections, as you suggest, as the only difference is that the port value is set to zero in the reject/disable case.
>>

It wasn't as easy to change as I first thought, so for now I keep "unique address" and "bundle address". But, I have added a definition, saying that it refers to the IP address and port.

In a separate chapter I talk about ICE candidates, and other parameters, that have to be identical in bundled m- lines.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Jun 2013 18:53:30 -0400

(The quoting here is getting rather unmanageable.
I'm trimming, but maybe we need to start over fresh.)

> Ok, I hear you. Yes, IF we allow that it is important that it is clear when one can assume that the Answerer supports BUNDLE.

In prior reply I sketched out my thoughts about what constitute 
reasonable evidence.

But IMO an offerer MAY presume support without any explicit evidence in 
the signaling if it wishes. This may be because it knows the relevant 
deployment environment guarantees it, or because it has some other 
signaling mechanism to learn it. Or it may simply want to play the odds.

I don't think we should forbid guessing. It is a judgement call, and in 
such a case the offerer must be prepared to cope with the consequences 
if the guess turns out to be wrong.

> I understand what you're saying, and I'll dig more into it once I get -04 submitted :)

Sure!

> I have added it as an Open Issue in -04, though.

Thanks.

> It seems we have a common understanding of what is currently specified :)

Good. That is a start!

Yes.

>   whether BUNDLE is supported within that particular SDP session.

Not necessarily. I discussed this above.

> Ok, once I've submitted -04, I'll continue to work on text for that, while allowing people to review the rest of the procedures.

OK.

> The to-be-submitted text basically only says that the mid must no longer be used to associate the removed/rejected/disabled m- line with the BUNDLE group.

OK.

> In a separate chapter I talk about ICE candidates, and other parameters, that have to be identical in bundled m- lines.

Sounds reasonable.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 15 Jun 2013 08:55:16 +0000

Hi,

> I'm trimming, but maybe we need to start over fresh.)

I think the only technical issue is whether it's allowed to:

1) Assign an address to multiple m- line before it has been selected as a bundle address; and

2) Whether it's allowed to assign an address to multiple m- line before the Answerer has indicated *in the SDP Answer* whether it supports BUNDLE.

The two are of course related, because in order to allow 2) we also need to allow 1) :)

I personally don't have any problems with you suggestion (it will require some editorial work, but technically there should be no issues). 

However, it does sound very much like my original BUNDLE proposal (where the Offerer ALWAYS assigned the bundle address to all m- lines), so I'd like to hear what others - especially Cullen - thinks about it.

Regards,

Christer