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

[Christer Holmberg <[e-mail]>]

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