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

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

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.

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

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

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

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.

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

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.

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

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

>     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

The term "BRO" is no longer defined.

>     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

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.

>     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

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

>     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
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>