Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-49: (with COMMENT)

[Christer Holmberg <[e-mail]>]

Hi Benjamin,

Thank You for the review! Please see inline.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

> Should the NOTE in Section 8.5.2 explicitly reaffirm that only one m= section within the BUNDLE group 
> can have the offerer BUNDLE address:port, regardless of whether it is a new or preexisting address:port?  
> That is, that you cannot use an existing BUNDLE address:port and offer a new one in the same BUNDLE group.

I can add a sentence to the end of the Note:

   "NOTE: If the offerer also wants to suggest a new offerer BUNDLE
   address:port to the BUNDLE group, the offerer can assign the newly
   suggested offerer BUNDLE address:port either to the added "m="
   section, or to some other "m=" section within the BUNDLE group
   [Section 8.5.1]. To every other "m=" section within the BUNDLE group
   the offerer will assign a zero port value and an SDP 'bundle-only' attribute
   [Section 8.5.1]."
      
---

> When we talk about how the offerer must move a section out of one BUNDLE group and then generate a second offer
> where that section is added to the other BUNDLE group (this occurs in several places, IIRC), do we need to say anything
> about the offer that moves the section out of the first BUNDLE group must be accepted before the second offer is offered?

It is a basic 3264 rule that whatever changes are done in an offer only become valid once they have been accepted by the answerer.

---

> In Section 10.2, page 23, I appreciate the description of the payload type/m= mapping used by legacy
> implementations, but I worry that there may not be sufficient description of when an SDP participant should 
> take the care to ensure the uniqueness of the mapping (versus when the legacy considerations can be ignored).

Section 10 was "outsourced", so I will ask the folks who provided the text to reply :)

Magnus, Colin?

----

> Does the first paragraph of Section 10.3.1.2 imply that an implementation of BUNDLE must also implement rtcp-mux-only?

Yes. I could add a sentence to the following paragraph in section 10.2.:

   "Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP
   multiplexing [RFC5761] for the RTP-based media specified by the
   BUNDLE group. In addition, the offerer and answerer MUST support the
   SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive]."

----

> Should the RTP SDES header extension URI be mentioned somewhere other than the IANA considerations?

It is mentioned in Section 10.1:

      "o  The RTP MID header extension MUST be enabled, by including an SDP
      'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp-
      hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section
      in every offer and answer."

---

>In Section 17:
>
>   The security considerations of "RTP Header Extension for the RTP
>   Control Protocol (RTCP) Source Description Items" [RFC7941] requires
>   that when RTCP is confidentiality protected, and that any SDES RTP
>   header extension carrying an SDES item, such as the MID RTP header
>   extension, is also protected using commensurate strength algorithms.
>
> "that when [...], and that" seems the wrong construction here; I think that just "that when [...]," is the intended meaning.

Correct. I suggest:

   "The security considerations of "RTP Header Extension for the RTP
   Control Protocol (RTCP) Source Description Items" [RFC7941] requires
   that when RTCP is confidentiality protected, then any SDES RTP
   header extension carrying an SDES item,..."

---

Regards,

Christer