Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc8843bis-00: Including 8843 example (Paul K)

[Christer Holmberg <[e-mail]>]

Hi,

...

>* Notes at the end of sections 7.3 and 7.4 discuss interoperation if implementions of the bis with those of RFC8843. It would be good to include an example of this. 
>(For the benefit of those who implement from the examples!)

I was thinking about this could be implemented. Since the current examples are in separate sub-sections, what about putting the note, and the examples you request, in dedicated subsections.

Something like this:

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

7.3.  Generating the SDP Answer

   When an answerer generates an answer (initial BUNDLE answer or
   subsequent) that contains a BUNDLE group, the following general SDP
   Grouping Framework restrictions, defined in [RFC5888], also apply to
   the BUNDLE group:

   *  The answerer is only allowed to include a BUNDLE group in an
      initial BUNDLE answer if the offerer requested the BUNDLE group to
      be created in the corresponding initial BUNDLE offer;

   *  The answerer is only allowed to include a BUNDLE group in a
      subsequent answer if the corresponding subsequent offer contains a
      previously negotiated BUNDLE group;

   *  The answerer is only allowed to include a bundled "m=" section in
      an answer if the "m=" section was indicated as bundled in the
      corresponding offer; and

   *  The answerer is only allowed to include a bundled "m=" section in
      the same BUNDLE group as the bundled "m=" line in the
      corresponding offer.

   In addition, when an answerer generates an answer (initial BUNDLE
   answer or subsequent) that contains a BUNDLE group, the answerer
   MUST:

   *  In case of an initial BUNDLE answer, select the offerer-tagged
      "m=" section using the procedures in Section 7.3.1.  In case of a
      subsequent answer, the offerer-tagged "m=" section is indicated in
      the corresponding subsequent offer and MUST NOT be changed by the
      answerer;

   *  Select the answerer-tagged "m=" section (Section 7.3.1);

   *  Assign the answerer BUNDLE address:port to the answerer-tagged
      "m=" section, and to every other bundled "m=" section within the
      BUNDLE group;

   *  Include SDP attributes in the bundled "m=" sections following the
      rules in Section 7.1.3;

   *  Include an SDP 'group:BUNDLE' attribute in the answer; and

   *  Place the identification-tag of each bundled "m=" section in the
      SDP 'group:BUNDLE' attribute identification-tag list.  The
      answerer BUNDLE-tag indicates the answerer-tagged "m=" section
      (Section 7.3.1).

   If the answerer does not want to keep an "m=" section within a BUNDLE
   group, it MUST:

   *  Move the "m=" section out of the BUNDLE group (Section 7.3.2); or

   *  Reject the "m=" section (Section 7.3.3).

   The answerer can modify the answerer BUNDLE address:port, add and
   remove SDP attributes, or modify SDP attribute values in a subsequent
   answer.  Changes to the answerer BUNDLE address:port and the answerer
   BUNDLE attributes will be applied to each bundled "m=" section within
   the BUNDLE group.

   NOTE: If a bundled "m=" section in an offer contains a zero port
   value, but the "m=" section does not contain an SDP 'bundle-only'
   attribute, it is an indication that the offerer wants to disable the
   "m=" section (Section 7.5.3).

7.3.1 <No changes>
7.3.2 <No changes>
7.3.3 <No changes>
7.3.4 <No changes>

7.3.5  RFC 8843 Considerations

   In RFC 8843, instead of assigning the offerer BUNDLE
   address:port to each "m=" section within the BUNDLE group when
   modifying the session (Section 7.5), the offerer only assigned the
   offerer BUNDLE address:port to the offerer-tagged "m=" section.  For
   every other "m=" section within the BUNDLE group, the offerer
   included an SDP 'bundle-only' attribute in, and assigned a zero port
   value to, the "m=" section.  In order to be backward compatible with
   offerers that implement that version of the specification, an
   answerer SHOULD accept such offers. The example below shows such
   offer:

    SDP Offer

       v=0
       o=alice 2890844526 2890844526 IN IP6 2001:db8::3
       s=
       c=IN IP6 2001:db8::3
       t=0 0
       a=group:BUNDLE foo bar

       m=audio 10000 RTP/AVP 0 8 97
       b=AS:200
       a=mid:foo
       a=rtcp-mux
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

       m=video 10000 RTP/AVP 31 32
       b=AS:1000
       a=mid:bar
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000
       a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid


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


7.4.  Offerer Processing of the SDP Answer

   When an offerer receives an answer, if the answer contains a BUNDLE
   group, the offerer MUST check that any bundled "m=" section in the
   answer was indicated as bundled in the corresponding offer.  If there
   is no mismatch, the offerer MUST apply the properties (BUNDLE
   address:port, BUNDLE attributes, etc.) of the offerer-tagged "m="
   section (selected by the answerer; see Section 7.3.1) to each bundled
   "m=" section within the BUNDLE group.

   NOTE: As the answerer might reject one or more bundled "m=" sections
   in an initial BUNDLE offer, or move a bundled "m=" section out of a
   BUNDLE group, a given bundled "m=" section in the offer might not be
   indicated as bundled in the corresponding answer.

   If the answer does not contain a BUNDLE group, the offerer MUST
   process the answer as a normal answer.

7.4.1  RFC 8843 Considerations

   In RFC 8843, instead of assigning the answerer BUNDLE
   address:port to each "m=" section within the BUNDLE group when
   generating the answer (Section 7.3), the answerer only assigned the
   answerer BUNDLE address:port to the answerer-tagged "m=" section.
   For every other "m=" section within the BUNDLE group, the answerer
   included an SDP 'bundle-only' attribute in, and assigned a zero port
   value to, the "m=" section.  In order to be backward compatible with
   answerers that implement that version of the specification, an
   offerer SHOULD accept such answers. The example below shows such
   answer:

   SDP Answer

     v=0
     o=bob 2808844564 2808844564 IN IP6 2001:db8::1
     s=
     c=IN IP6 2001:db8::1
     t=0 0
     a=group:BUNDLE foo bar

     m=audio 20000 RTP/AVP 0
     b=AS:200
     a=mid:foo
     a=rtcp-mux
     a=rtpmap:0 PCMU/8000
     a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

     m=video 0 RTP/AVP 32
     b=AS:1000
     a=mid:bar
     a=bundle-only
     a=rtpmap:32 MPV/90000
     a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

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

Regards,

Christer