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

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Jun 2013 11:17:56 +0000

Ok folks,

Below is some Offerer text for BUNDLE. I've also included some examples.

As we have discussed, Bundle Sync Offer may not be good terminology, but again I'd like to focus more on the technical content, and the "understandability" of the text, for now :)

Also note that the text currently assumes that a port zero m= line CANNOT be inside a BUNDLE group. That may change (depending on how we move forward with the plans etc), but
should not have a huge impact on the text, apart from the section talking about disabling an "m=" line in a BUNDLE group.

Also, the definition of "bundle address" WILL be defined, but it's more or less the IP port, address and ICE information associated with the transport plane.

Happy reading!

Regards,

Christer

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

6.2.  SDP Offerer Procedures

6.2.1.  General

   This section describes how an Offerer creates an SDP Offer which
   includes a BUNDLE group.

   An SDP Offer that includes a BUNDLE group can be categorized either
   as a Bundle Restart Offer (BRO) Section 6.2.2.1 or as a Bundle Sync
   Offer (BSO) Section 6.2.2.2.

6.2.2.  SDP Offer Types

6.2.2.1.  Bundle Restart Offer (BRO)

   A Bundle Restart Offer (BRO) is used to negotiate (or re-negotiate)
   the usage of the BUNDLE mechanism, and/or the bundle address used by
   the "m=" lines in a BUNDLE group.

   In a BRO, the Offerer assigns a unique address to at least one "m="
   line in a BUNDLE group.  Such "m=" lines can be removed from the
   BUNDLE group by the Answerer (see [xxx]), as the unique address can
   be used outside the BUNDLE group.

   In a BRO, the Offerer assigns, for each "m=" line in the BUNDLE
   group, either a unique address, or a previously negotiated bundle
   address, as long as a unique address is assigned to at least one "m="
   line in the BUNDLE group (if the bundle address is assigned to each
   "m=" line in the BUNDLE group, the SDP Offer is by definition a
   Bundle Sync Offer (BSO) Section 6.2.2.2.

   When a session is initiated, if the Offerer does not know whether the
   Answerer supports the BUNDLE mechanism, the Offerer MUST initiate a
   BRO, and the Offerer MUST assign a unique address to each "m=" line
   in the BUNDLE group.

   If, in the SDP Answer associated with the BRO, the offered BUNDLE
   group is accepted [ref-to-be-added], the Offerer MUST, for each "m="
   line in the BUNDLE group, start to use its local bundle address, and
   the remote bundle address, both selected by the Answerer [ref-to-be-
   added].  In addition, the Offerer MUST send a Bundle Sync Offer (BSO)
   Section 6.2.2.2, in which the bundle address is assigned to each "m="
   line in the BUNDLE group.

   NOTE: The Offerer needs to send the BSO as soon as possible, in order
   to make sure intermediaries are aware that the bundle address will be
   used for each "m=" line in the BUNDLE group.  However, the exact
   moment for sending the BSO might depend on other features and
   extensions (e.g. ICE) also used by the Offerer, that also require the
   sending of subsequent SDP Offers.

   Example: The example shows a BRO, 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
   bundle address, by placing the mid value associated with the "m="
   line first in the SDP group:BUNDLE attribute mid list.

   SDP Offer (Bundle Restart 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.2.  Bundle Sync Offer (BSO)

   A Bundle Sync Offer (BSO) is used when the Offerer does not want to
   re-negotiate the usage of the BUNDLE mechanism, and/or the bundle
   address.  The Offerer can, using a BSO, re-negotiate other parameters
   associated with the BUNDLE group, however.

   In a BSO, the Offerer MUST assign the bundle address to each "m="
   line in a BUNDLE group.  Such "m=" lines can not be removed from the
   BUNDLE group by the Answerer [ref-to-be-added], as the bundle address
   can not be used outside the BUNDLE group.

   Example: The example shows a BSO, where the bundle address is
   assigned to each "m=" line in the BUNDLE group.

   SDP Offer (Bundle Sync 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

6.2.3.  Use Cases

6.2.3.1.  Offerer Bundle Address Request

   In order to negotiate (or re-negotiate) the bundle address, the
   Offerer MUST send a BRO.  In the BRO, as the Offerer assigns a unique
   address to some (or all) "m=" lines in the BUNDLE group, the Offerer
   needs to indicate to the Answerer which address, associated with one
   of the "m=" lines in the BUNDLE group, it wishes to use as its local
   bundle address.  The first mid value in the SDP group:BUNDLE
   attribute mid value list represents the "m=" line address with the
   highest preference.

   The Answerer will select the local bundle address for the Offerer, as
   described in Section 6.3.3.  The Offerer MUST use the bundle address
   selected by the Answerer.  If the Offerer is not able to use that
   bundle address, it MUST either terminate the session, or send a new
   BRO.

   Example: The example shows a BRO, 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
   bundle address, by placing the mid value associated with the "m="
   line first in the SDP group:BUNDLE attribute mid list.

   SDP Offer (Bundle Restart 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.3.2.  Adding a media description to a BUNDLE group

   When adding an "m=" line to a BUNDLE group, the Offerer generates
   either a BRO or BSO.  In case of a BSO, the Offerer assigns the
   bundle address to each "m=" line (including the new one) in the
   BUNDLE group.  In case of a BRO, the Offerer assigns, for each "m="
   line (including the new one), either a unique address, or the bundle
   address (only the bundle address can be assigned to more than one
   "m=" line in the BUNDLE group).

   Example: The example shows a BRO, where a new "m=" line, identified
   by the "zen" mid value, is added to a BUNDLE group.  The bundle
   address is assigned to each of the current "m=" lines in the BUNDLE
   group, while a unique address is assigned to the new "m=" line.  The
   Offerer requests that the bundle address is not changed, by placing
   the mid value associated with the audio "m=" line, for which the
   previously negotiated bundle address is assigned, first in the SDP
   group:BUNDLE attribute mid list.

   SDP Offer (Bundle Restart 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

   Example: The example shows a BSO, where a new "m=" line, identified
   by the "zen" mid value, is added to a BUNDLE group.  The previously
   negotiated bundle address assigned to each "m=" line (the current
   ones and the new one) in the BUNDLE group.

   SDP Offer (Bundle Sync 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 10000 RTP/AVP 60
       a=mid:zen
       b=AS:1000
       a=rtpmap:60 H261/90000

6.2.3.3.  Removing A Media Description From A BUNDLE Group

   In order to remove an "m=" line from a BUNDLE group, the Offerer
   generates either a BRO or BSO.  The Offerer MUST remove the "m="
   line, and its associated mid value, from the BUNDLE group, and the
   Offerer MUST assign a unique address to the removed "m=" line.

   Example: The example shows a BSO, 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.

   SDP Offer (Bundle Sync 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.3.4.  Disabling A Media Description In A BUNDLE Group

   In order to disable an "m=" line in a BUNDLE group, the Offerer
   generates either a BRO or BSO.  The Offerer MUST remove the disabled
   "m=" line, and its associated mid value, from the BUNDLE group.  In
   addition, the Offerer assigns a zero port value to the "m=" line,
   according to the procedures in RFC 3264.

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

   SDP Offer (Bundle Sync 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

   OPEN ISSUE: It is FFS whether it is allowed to include a port zero
   media descriptions in a BUNDLE group.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Jun 2013 09:42:20 -0700

Nice work.  I had too many comments to do an email reply properly, so
I've done the whole nasty Word doc thing.

The only big item is that I think that you need to more tightly
control the conditions for a BSO - in most cases, you could label
those BSO as BRO without causing any problems.  Given that limitation,
you could probably eliminate the BRO/BSO labels, which might help with
readability a little.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Jun 2013 12:45:28 -0400

Hi Christer,

I'm still finding problems when I read this, in spite of all the 
discussions. It feels to me like the problem is that the distinction 
between BRO and BSO isn't quite right, and it isn't just the names. 
Clearly there are a couple of different kinds of things. While reading 
and writing this I've been trying to figure out exactly what the problem 
is and how to fix it.

First, I'll comment inline where I see issues.
Then at the end I'll suggest something that might help.

On 6/6/13 7:17 AM, Christer Holmberg wrote:
> Ok folks,
>
> Below is some Offerer text for BUNDLE. I’ve also included some examples.
>
> As we have discussed, Bundle Sync Offer may not be good terminology, but
> again I’d like to focus more on the technical content, and the
> “understandability” of the text, for now :)
>
> Also note that the text currently assumes that a port zero m= line
> CANNOT be inside a BUNDLE group. That may change (depending on how we
> move forward with the plans etc), but
>
> should not have a huge impact on the text, apart from the section
> talking about disabling an “m=” line in a BUNDLE group.
>
> Also, the definition of “bundle address” WILL be defined, but it’s more
> or less the IP port, address and ICE information associated with the
> transport plane.
>
> Happy reading!
>
> Regards,
>
> Christer
>

The above excludes the possibility of both proposing to change the 
previously negotiated bundle address and add a new m-line with a unique 
address.

>     BRO, and the Offerer MUST assign a unique address to each "m=" line

The MUST above bothers me. I could go with SHOULD.
IOW, even if the offerer doesn't know whether the answerer supports 
bundle, it could take a chance, on the assumption that the odds are good 
that it will be successful. Then it can deal with the consequences if 
the answer indicates that bundle wasn't supported.

>     line in the BUNDLE group.

In some cases things could be done with one O/A rather than two, and 
whether a 2nd one is needed may depend on what was in the answer. What 
is proposed seems to *require* two O/As when bundling is used.

[snip]

>     associated with the BUNDLE group, however.

If all I want to do is change the bundle address, I should be able to 
send an offer that does that. And after the answer all is done. I 
shouldn't be required to offer unique addresses for each (or any) m-line 
in the bundle to do this.

>     can not be used outside the BUNDLE group.

Some of the m-lines in the bundle can be rejected (port zero), and then 
be removed from the bundle. And if there is then only one m-line left in 
the bundle, then I guess it can either be left in the bundle or else the 
bundle can be removed.

[snip]

>     attribute mid value list represents the "m=" line address with the

Again, you say a BRO MUST be used to to change the bundle address.
But the key defining feature of a BRO over a BSO is that it has at least 
one m-line with a unique address. This doesn't suit the case well.

But I can't use a BSO for this, because, by your definition it must have 
the previously negotiated bundle address.

[snip]

ISTM that all bundle offers must meet some constraints:
- some of the m-lines may have *unique* addresses
- all the rest, if any, must have a single *common* address.
- if any share a common address, then the first mid in the
   bundle group must identify one of them

All answers to a bundle offer must also meet some constraints:
- all the standard grouping constraints on answers
- all m-lines in the bundle in the answer must have a single
   common address.
- m-lines bundled in the offer but unbundled in the answer
   must have either a zero port or a unique address in the answer.
   (Unique from each other and from the common address of the
   lines bundled in the answer.)
- An m-line that had a common address in the offer may only
   be removed from the bundle in the answer if:
   - it is given a zero port in the answer
   - all the other m-lines that had the same common address
     in the offer have been given a zero port in the answer

Then, a bundle offer where *all* the addresses are common is "stable". 
(It doesn't need to be "fixed up".) Maybe we can call that a BSO. :-)

That distinction is independent of whether it is used to initially 
establish a bundle, to change the address of a bundle, add or remove 
m-lines, etc.

A bundle offer that meets the general constraints but isn't a BSO is an 
"unstable" bundle offer, in that it will (probably) need to be followed 
up with another, stable, bundle offer.

One open issue I have here is that I think some answers might eliminate 
the need for an unstable bundle offer to be followed up by a stable 
offer. (IOW, the answer may stabilize an unstable offer.) Some examples 
where I think this may be so:

- if the bundling is entirely rejected, (no bundle group in answer),
   then no stable bundle offer is required

- if the offer would be stable if it only contained the m-lines in
   the answer bundle group, then a stable bundle offer *may* not be
   required. (IOW the answer removed everything from the bundle that
   made it unstable.) This needs further discussion.

So the bottom line is that you can do whatever you want (add, remove, 
reject m-lines, move them out of bundles, change addresses, etc.) in an 
offer or answer if and only if you meet the stated constraints for an 
offer or answer.

So the focus becomes one of making certain the constraints are specified 
precisely and clearly.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Jun 2013 13:23:49 -0400

Hi Martin,

I see we had some of the same issues, but I think we have formed 
different ideas of how the proposal was intended to work and how to 
improve it.

My conclusion is that trying to characterize full offers into different 
types and impose rules on them breaks down, and that it is better to 
impose constraints that must apply.

I sketched out some proposed constraints in my reply. But if that 
approach seems acceptable then those need some refinement. For instance, 
in general the constraints don't apply to an entire offer or answer, but 
instead apply to a set of m-lines in a bundle group. (If there is more 
than one bundle group then each can be considered separately.) But some 
of the constraints are global - e.g. uniqueness.

	Thanks,
	Paul

On 6/6/13 12:42 PM, Martin Thomson wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Jun 2013 11:17:05 -0700

On 6 June 2013 10:23, Paul Kyzivat <[email-masked]> wrote:
> I see we had some of the same issues, but I think we have formed different
> ideas of how the proposal was intended to work and how to improve it.

I'm not sure that we differ in conclusions, just in our approach :)
Your constraints look good and are (to my eye) exactly what I sketched
out.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Jun 2013 05:40:20 +0000

Hi Martin & Paul,

Thank You very much for your detailed review! I will go through your comments, and suggestions, reply and try to come up with modified text.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: 6. kesäkuuta 2013 21:17
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th)

On 6 June 2013 10:23, Paul Kyzivat <[email-masked]> wrote:
> different ideas of how the proposal was intended to work and how to improve it.

I'm not sure that we differ in conclusions, just in our approach :) Your constraints look good and are (to my eye) exactly what I sketched out.
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Jun 2013 12:19:45 +0000

Hi,

After reading Paul's and Martin's comments, I am suggesting a change to the separation between BSO and BRO. 

Again, the names will be changed, but I'll leave that for now - but I DO like the Bundle Negotiation Offer (BNO) suggestion made by Martin :)

In the current text, I separate between BSO and BRO pretty much based on the type address information in the "m=" lines of the SDP Offer. I have realized that it doesn't work very well.

So, a new suggestion is that the separation is done based on the PURPOSE of the SDP Offer, NOT the type of address information in the "m=" lines (of course, in many cases they go hand-in-hand).

A BSO would be used ONLY for synchronization purpose, or making the SDP "stable".

A BRO would be used to negotiate the usage of BUNDLE, to add/remove/modify "m=" lines and/or the bundle address. So, even an with the same address information in each "m=" line could be an BRO, if the purpose is to modify the SDP in one way or another.

So, please keep the assumptions above in mind when reading my reply to the individual comments below :)

>>    A Bundle Restart Offer (BRO) is used to negotiate (or 
>>    re-negotiate)  the usage of the BUNDLE mechanism, and/or the bundle address used 
>>    by  the "m=" lines in a BUNDLE group.
>>

> The above excludes the possibility of both proposing to change the previously negotiated bundle address and add a new m-line with a unique address.

Correct. But, with the suggested change in the beginning of the mail it should now be possible.

> the answer indicates that bundle wasn't supported.

Ok.

> is proposed seems to *require* two O/As when bundling is used.

I will make it more clear that the 2nd O/A (BSO) is required ONLY when a BRO was sent, AND each "m=" line did NOT have the same address information.

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

> send an offer that does that.
> And after the answer all is done. I shouldn't be required to offer unique addresses for each (or any) m-line 

The new BRO definition will allow you to do that, as you can now assign the same address (i.e. your suggested new bundle address) to each "m=" line.

> be removed from the bundle.

I thought I had some text clarifying that, but if it's not there I will add it.

> And if there is then only one m-line left in the bundle, then I guess it can either 
> be left in the bundle or else the bundle can be removed.

I did have some text about BUNDLE groups with only one "m=" line, but it seems it got lost somewhere.

Personally I don't think we would need to forbid BUNDLE groups with only one "m=" line (unless it goes against RFC 5888), but it doesn't really give you anything.

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

> the previously negotiated bundle address.

Correct. My suggestion in the beginning of the reply would change that.

You would still use a BRO for this, but you can assign the same 
address (previously negotiated bundle address OR suggested new bundle address)
to each "m=" line if you want.

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

You had some more comments, but I'll leave them for now, because I *THINK* my new suggestion would solve most of them.

But, I'll go through them when I put together a proposal for new text.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Jun 2013 09:12:39 -0700

Great stuff Christer.  I think that we have reached some sort of agreement.

Only one thing to comment on:

>> the answer indicates that bundle wasn't supported.

So I don't have a problem with going with SHOULD here rather than
MUST.  If the Offerer wants to take that chance, then that is OK with
me.  It might still work even if the Answerer didn't support BUNDLE.
The only thing that would make me reluctant to do so is that you then
need to follow the SHOULD with some additional information.  Guidance
on what could go wrong if the SHOULD is ignored.

Were it me, I'd want to dredge through the archives to uncover all
those nasty corner cases we discussed in order to get the right text,
so my natural laziness would lead to choosing MUST :)

--Martin

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jun 2013 13:23:12 -0400

Christer,

> So, a new suggestion is that the separation is done based on the PURPOSE of the SDP Offer, NOT the type of address information in the "m=" lines (of course, in many cases they go hand-in-hand).

Note that offers and answers may contain more than just one set of 
bundled m-lines. They may contain unbundled m-lines, and multiple 
bundles. So the purpose of a particular offer may be complex, trying to 
satisfy different needs for various parts of the SDP. That complicates 
making such a distinction.

> A BSO would be used ONLY for synchronization purpose, or making the SDP "stable".

So this is just intended to describe the case where both ends have 
reached agreement on what they want to do, and don't want to change 
that, but the agreed pair of SDPs doesn't describe that agreement in the 
standard way? This additional O/A is used *solely* to put things into 
the standardized representation?

And if things end up in the standardized form without a BSO then one is 
not sent?

If so, then the receiver of the offer can tell that it is a BSO by 
analyzing it in the context of what the prior O/A had been. But there is 
no particular reason to do so, because it doesn't affect the behavior of 
the answerer.

The value of the term must be simply to facilitate the description of 
offerer behavior. Following an O/A exchange that has left things in a 
non-canonical form, the offerer in that exchange is required to send a BSO.

And I think the need for a BSO can indeed only be determined after 
receiving the answer. It is largly driven by the structure of the offer, 
but even so, certain answers may eliminate the need for the BSO.

> A BRO would be used to negotiate the usage of BUNDLE, to add/remove/modify "m=" lines and/or the bundle address. So, even an with the same address information in each "m=" line could be an BRO, if…

So an offer that *changes* *anything* is a BRO, while one that changes 
nothing but puts things in the correct form is called a BSO.

That definition might work from the point of view of the offer.
But note that even with a BSO the answer might change something.
E.g. the answerer could change its bundle address, or it could reject 
some m-lines. (But I don't think it is possible for the answer to do 
anything valid that will prevent the intent of the BSO from being achieved.)

> So, please keep the assumptions above in mind when reading my reply to the individual comments below :)

I don't have any further comments on what follows.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Jun 2013 18:55:40 +0000

Hi,

> making such a distinction.

I guess it should be more clear that the definition is per bundle group within an SDP Offer, not necessairly the whole SDP body. 

> the standardized representation?

Correct.

> And if things end up in the standardized form without a BSO then one is

Correct.

> but even so, certain answers may eliminate the need for the BSO.

The reason for sending the BSO is not the Answerer - it is because of intermediaries that don't understand BUNDLE.

>> A BRO would be used to negotiate the usage of BUNDLE, to add/remove/modify "m=" lines and/or the bundle address. So, even an with 
>> the same address information in each "m=" line could be an BRO, if the purpose is to modify the SDP in one way or another.
>

Correct.

> anything valid that will prevent the intent of the BSO from being achieved.)

I think that's ok.

Because, even without BUNDLE, if an Offerer sends a SIP re-INVITE/UPDATE with an unmodified SDP Offer (e.g. because of session-timer usage), the SDP Answer may still change.

One question, though, is whether the SDP o= line version number should be incremented when sending a BSO (assuming everything, including the non-BUNDLE stuff, in the SDP body is unmodified). From a pure SDP perspective, the address information for certain "m=" lines may have changed, eventhough from a BUNDLE perspective it is just about synchronization.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Jun 2013 12:06:07 -0700

On 7 June 2013 10:23, Paul Kyzivat <[email-masked]> wrote:
> Note that offers and answers may contain more than just one set of bundled
> m-lines. They may contain unbundled m-lines, and multiple bundles. So the
> purpose of a particular offer may be complex, trying to satisfy different
> needs for various parts of the SDP. That complicates making such a
> distinction.

I thought about this, but forgot to followup.  I think that it could
be possible for a single request to be a BSO for one group, which a
BRO for another.  The labels are a convenience only, and provide a way
to provide guidance about how to handle offer/answer creation...scoped
only to the affected m-lines.  I think that the complication is only a
complication insofar as it requires some text that highlights this.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Jun 2013 19:16:27 +0000

Hi,

> complication insofar as it requires some text that highlights this.

I agree. The scope of a BRO or BSO is only per individual BUNDLE group within an SDP Offer - not the whole SDP Offer.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jun 2013 15:22:58 -0400

> I guess it should be more clear that the definition is per bundle group within an SDP Offer, not necessairly the whole SDP body.

I think the BSO must be determined over the entire O/A, not on a 
per-bundle basis. Otherwise the new offer is being sent with the intent 
to change *something* in it.

> The reason for sending the BSO is not the Answerer - it is because of intermediaries that don't understand BUNDLE.

I realize that the BSO is not being sent for the benefit of the 
answerer. My point was that the need to send the BSO is determined by 
the offerer, but cannot be determined until the answer has been received.

> One question, though, is whether the SDP o= line version number should be incremented when sending a BSO (assuming everything, including the non-BUNDLE stuff, in the SDP body is unmodified). From a…

I've always had a problem with o-lines.
AFAICT the only value they bring (at least in the context of O/A) is as 
an optimization: if the new one says via the o-line that it is identical 
to the prior one then perhaps you can simply not process it.

But I think an implementation would be insane to trust this. There is 
too much of a chance that there will be a changed SDP with an unchanged 
o-line. So I think a reasonable implementation will at least do a 
comparison of the whole body before optimizing for an unchanged one. (Or 
else it will do any optimization on an element by element basis.)

BUT, on the off chance that anybody does use the o-line that way, then I 
think it must be marked as changed. It isn't identical, and the reason 
its not, and is being sent, is because of the changes it contains. Those 
changes may have different significance to intermediaries than to the 
UAS, but its important that the difference be recognized.

If *nothing* is changed, then there is no reason to send the BSO.

Of course the *answer* to the BSO most likely will be unchanged from the 
prior answer, so the o-line for that ought to reflect that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 9 Jun 2013 18:13:37 +0000

Hi,

> to change *something* in it.

Sure, but you could change things which are non-BUNDLE related.

For example, if you use ICE, you could combine the BUNDLE BSO with the ICE Offer which informs the other endpoint of the selected candidates (sorry, I don't remember all ICE terminology at the moment :)

Correct.

>> One question, though, is whether the SDP o= line version number should be incremented when sending a BSO (assuming everything, including the non-BUNDLE 
>> stuff, in the SDP body is unmodified). From a pure SDP perspective, the address information for certain "m=" lines may have changed, eventhough from a BUNDLE perspective it is just about synchronization.
>

Actually, I have seen entities that do NOT perform any check if the o-line value is unchanged :)

> UAS, but its important that the difference be recognized.

I agree.

Correct.

Correct.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Jun 2013 12:47:55 +0000

Hi Paul,

A comment on some of the stuff you sent earlier.

What is the reason for the third bullet?

For example, assume I am adding a new "m=" line, with a unique address, and I would like that address to become the new bundle address.

In the existing "m=" lines, I couldn't keep the previously negotiated bundle address, because based on the third bullet the first mid would have to identity one of those. So, I would have to either:

1) Assign a unique address to each of the existing "m=" lines, which would then allow me to request the address of the new "m=" line to become the new bundle address; or

2) I would have to assign the suggested new bundle address to ALL "m=" lines (the existing ones and the new one).

Note that both 1) and 2) are allowed today.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Jun 2013 12:50:42 -0400

> Note that both 1) and 2) are allowed today.

OK, I didn't think of that case.
So I guess that constraint should be removed.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Jun 2013 10:07:28 -0700

Christer wrote:
> For example, assume I am adding a new "m=" line, with a unique address, and
> I would like that address to become the new bundle address.

That's two things:

1. Add a new m-line, but allow it to be accepted and unbundled.
2. Change the transport parameters of the existing bundle, but permit
the change to be rejected.

I would be perfectly happy to require that this take two rounds of
offer/answer to perform.

I understand how that might be useful in theory, but I don't think
that you can make this change without accepting a lot of additional
complexity in the rest of the solution.  I liked the constraint
because it simplifies the rules around creation and acceptance
significantly.  Remove that constraint and I don't know where we are
any more.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Jun 2013 09:15:18 +0000

Hi,

>> For example, assume I am adding a new "m=" line, with a unique 
>> address, and I would like that address to become the new bundle address.
>
>That's two things:
>
>2. Change the transport parameters of the existing bundle, but permit the change to be rejected.
>
>I would be perfectly happy to require that this take two rounds of offer/answer to perform.
>
>I understand how that might be useful in theory, but I don't think that you can make this change without accepting a lot of additional 
>complexity in the rest of the solution.  I liked the constraint because it simplifies the rules around creation and acceptance significantly.  
>Remove that constraint and I don't know where we are any more.

Personally, I think the case where the Offerer wants to re-negotiate the bundle address will be very rare. In practice, I think it will only happen if the Offerer uses a re-INVITE to perform a transfer.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Jun 2013 11:09:35 -0700

> Personally, I think the case where the Offerer wants to re-negotiate the bundle address will be very rare. In practice, I think it will only happen if the Offerer uses a re-INVITE to perform a tran…

I can see this happening on ICE restart.  I can't see that happening
at the same O/A exchange as a stream addition.