Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-54

Thank you for writing this.

The Abstract says "This specification updates RFC 3264, ...", but it doesn't say how it updates RFC7941. I think it would be helpful if it did...

8.1.  Multiplex Category Considerations

   When a BUNDLE group is initially negotiated, and a unique
   address:port is assigned to each bundled "m=" section (excluding any
   bundle-only "m=" section) in the initial offer [Section 8.2], any
   IDENTICAL and TRANSPORT mux category SDP attributes included in the
   BUNDLE group MUST explicitly be included in each bundled
   "m=a€œ section (excluding any bundle-only "m=" sections).

HTML encoding is not really readable in plain text.

Please add a reference on first mention of UTF-8.

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.


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?


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


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


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


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.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3382

This is really vastly better. Thanks for making the changes. I have
made a few notes of things that I still think are problematic, but I
am clearing my DISCUSS.


IMPORTANT
S 7.3.5.
>      a zero port value to, the video "m=" section.
>   
>      SDP Answer
>   
>        v=0
>        o=bob 2808844564 2808844564 IN IP6 2001:db8::1

This doesn't sound right. You can't use the existing address:port,
because if the peer rejects BUNDLE but accepts the m= section then
it's broken.


S 9.3.1.2.
>   
>   9.3.1.2.  Generating the SDP Answer
>   
>      When an answerer generates an answer, if the answerer supports RTP-
>      based media, and if a bundled "m=" section in the corresponding offer
>      contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage

This does not define how to interact with trickle ICE.

COMMENTS

>   
>    Negotiating Media Multiplexing Using the Session Description Protocol
>                                    (SDP)
>               draft-ietf-mmusic-sdp-bundle-negotiation-51.txt
>   
>   Abstract

This document is quite a bit improved from when I read it before, but
it's still very confusing. The primary problem here is the repeated
use of "address;port" as synechdoche for the m= section which is the
"head" of the BUNDLE group (i.e., that which is indicated by the
BUNDLE-tag). That's not what's going on and it's misplaced
concreteness. I would invent some new term ("head" is actually not
bad) and then use it throughout for this concept.


S 1.2.
>      transport) for sending and receiving media (bundled media) described
>      by multiple SDP media descriptions ("m=" sections).  The address:port
>      combination used by an endpoint for sending and receiving bundled
>      media is referred to as the BUNDLE address:port.  The set of SDP
>      attributes that are applied to each "m=" section within a BUNDLE
>      group is referred to as BUNDLE attributes.  The same BUNDLE transport

Nit: "pair"?


S 1.2.
>      group is referred to as BUNDLE attributes.  The same BUNDLE transport
>      is used for sending and receiving bundled media, which means that the
>      symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is
>      always used for RTP-based bundled media.
>   
>      This specification defines a new SDP Grouping Framework [RFC5888]

Why is one of these called "address" and the other "address:port"?


S 1.2.
>      Interactive Connectivity Establishment (ICE)
>      [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group.
>   
>      A given BUNDLE address:port MUST only be associated with a single
>      BUNDLE group.  If an SDP offer or answer contains multiple BUNDLE
>      groups, the procedures in this specification apply to each group

1. Bundle lets you have multiple SDP m= sections on a single 5-tuple
2. The underling mechanism here is that you put those m= sections in
the same BUNDLE group
3. In order to facilitate demuxing, we define a new RTP extension for
MID.
4. It is sometimes desirable to say that an m= section should only be
negotiated if it can be bundled. This is done with port=0 and a
=bundle-only.



S 1.2.
>      Interactive Connectivity Establishment (ICE)
>      [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group.
>   
>      A given BUNDLE address:port MUST only be associated with a single
>      BUNDLE group.  If an SDP offer or answer contains multiple BUNDLE
>      groups, the procedures in this specification apply to each group

This section is kind of a laundry list. I think it would be helpful to
break it out conceptually. Specifically.

1.
2.
3.



S 1.3.
>         SDES header extension that can be used to associate RTP streams
>         with "m=" sections.
>   
>      o  The specification updates [RFC7941], by adding an exception, for
>         the MID RTP header extension, to the requirement regarding
>         protection of an SDES RTP header extension carrying an SDES item

Was this intended to be a bullet?


S 2.
>   
>      o  BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category
>         SDP attributes.  Once a BUNDLE group has been created, the
>         attribute values apply to each bundled "m=" section within the
>         BUNDLE group.
>   

This is a very idiosyncratic definition, because it's *not* the first
offer in the session, but the one where the BUNDLE group is
introduced. Given that 3264 has a different meaning for this same
term, and the difference is critical, I would strongly urge you to
pick a different term.


S 2.
>      o  Bundle-only "m=" section: A bundled "m=" section that contains an
>         SDP 'bundle-only' attribute.
>   
>      o  Bundled media: All media associated with a given BUNDLE group.
>   
>      o  Initial offer: The first offer, within an SDP session (e.g. a SIP

This appears still not to be resolved. Here is the 3264 definition "
Protocol operation begins when one agent sends an initial offer to
another agent.  An offer is initial if it is outside of any context
that may have already been established through the higher layer
protocol." I'm not making this part of my DISCUSS, but I think it's
very confusing and I would strongly urge the AD to address it.




S 2.
>         BUNDLE group is created once the answerer sends the initial
>         answer.
>   
>      o  Subsequent offer: An offer which contains a BUNDLE group that has
>         been created as part of a previous offer/answer exchange.
>   

How about "is part of" instead of "associated with"


S 2.
>         been created as part of a previous offer/answer exchange.
>   
>      o  Subsequent answer: An answer to a subsequent offer.
>   
>      o  Identification-tag: A unique token value that is used to identify
>         an "m=" section.  The SDP 'mid' attribute [RFC5888] in an "m="

Again "part of"


S 5.
>      a semantics value [RFC5888] of "BUNDLE".  An identification-tag is
>      assigned to each bundled "m=" section, and each identification-tag is
>      listed in the SDP 'group:BUNDLE' attribute identification-tag list.
>      Each "m=" section whose identification-tag is listed in the
>      identification-tag list is associated with a given BUNDLE group.
>   

I would put some of this text up before the attribute definition to
explain why the attribute exists.


S 7.
>      rejected by the answerer, the previously negotiated addresses:ports,
>      SDP parameters and characteristics (including those associated with a
>      BUNDLE group) apply.  Hence, if an offerer generates an offer in
>      order to negotiate a BUNDLE group, and the answerer rejects the
>      offer, the BUNDLE group is not created.
>   

Multiplexing?


S 7.
>      "m=" line proto value assigned to a bundled "m=" section.  Section 9
>      defines additional considerations for RTP based media.  Section 6
>      defines additional considerations for the usage of the SDP 'bundle-
>      only' attribute.  Section 10 defines additional considerations for
>      the usage of Interactive Connectivity Establishment (ICE)
>      [I-D.ietf-ice-rfc5245bis] mechanism.

Something bad happened here with your editor.


S 7.
>      the usage of Interactive Connectivity Establishment (ICE)
>      [I-D.ietf-ice-rfc5245bis] mechanism.
>   
>      Offers and answers can contain multiple BUNDLE groups.  The
>      procedures in this section apply independently to a given BUNDLE
>      group.

This is pretty opaque. It's not that the address:port pair have been
selected but rather that BUNDLE has been negotiated for that m=
section (though of course the address:port being selected is a side
effect of this).




S 7.1.1.
>      attribute values have been assigned to each bundled "m=" section.
>   
>   7.1.1.  Connection Data (c=)
>   
>      The "c=" line nettype value [RFC4566] associated with a bundled "m="
>      section MUST be 'IN'.

It seems like you should define bundled "m=" section. I believe it's
one that appears in a bundle tag?


S 7.1.1.
>   
>   7.1.1.  Connection Data (c=)
>   
>      The "c=" line nettype value [RFC4566] associated with a bundled "m="
>      section MUST be 'IN'.
>   

Huh? This is section 8.1.

This whole paragraph is a mess. I would say

"One consequence of these rules is that because SDP attributes which
are appropriate only to some other m= section may appear in the m=
section indicated by the BUNDLE-tag. For instance, the BUNDLE-tag may
indicate a data channel but contain the 'rtcp-mux' attribute because
that applies to an RTP m= section that is part of the BUNDLE group"




S 7.1.2.
>      with each "m=" section.
>   
>      NOTE: Extensions to this specification can specify usage of the
>      BUNDLE mechanism for other nettype and addrtype values than the ones
>      listed above.
>   

This sentence is ungrammatical. "In order to negotiate a BUNDLE group
in an initial offer, the offerer MUST"


S 7.1.3.
>   
>      An offerer and answerer MUST include SDP attributes in every bundled
>      "m=" section where applicable, following the normal offer/answer
>      procedures for each attribute, with the following exceptions:
>   
>      o  In the initial offerer, the offerer MUST NOT include IDENTICAL and

initial offer


S 7.1.3.
>      "m=" section where applicable, following the normal offer/answer
>      procedures for each attribute, with the following exceptions:
>   
>      o  In the initial offerer, the offerer MUST NOT include IDENTICAL and
>         TRANSPORT multiplexing category SDP attributes (BUNDLE attributes)
>         in bundle-only "m=" sections.  The offerer MUST included such

MUST include


S 7.1.3.
>         attributes in all other bundled "m=" sections.  In the initial
>         offer each bundled "m=" line can contain a different set of BUNDLE
>         attributes, and attribute values.  Once the offerer tagged "m="
>         section has been selected, the BUNDLE attributes contained in the
>         offerer tagged "m=" section will apply to each bundled "m="
>         section within the BUNDLE group.

I would reorder these, because the zero port is the main semantic.


S 7.1.3.
>         tagged "m=" section).  The offerer and answerer MUST NOT include
>         such attributes in any other bundled "m=" section.  The BUNDLE
>         attributes contained in the tagged "m=" section will apply to each
>         bundled "m=" section within the BUNDLE group.
>   
>      o  In an offer (initial or subsequent), or in an answer (initial or

Why is this an "If"? There are only two choices: "unique" and "zero".
Just put this graf up before the discussion of bundle-only and you can
remove the conditional


S 7.2.
>      within the BUNDLE group does describe RTP-based media).
>   
>   7.2.  Generating the Initial SDP Offer
>   
>      When an offerer generates an initial offer, in order to negotiate a
>      BUNDLE group, it MUST:

I would say "believes" rather than "assumes"


S 7.2.
>      within the negotiated BUNDLE group, the offerer MUST:
>   
>      o  Include an SDP 'bundle-only' attribute [Section 7.2.1] in the "m="
>         section; and
>   
>      o  Assign a zero port value to the "m=" section.

Line breaks between the m= sections would help here.


S 7.2.
>      section, but does not include an SDP 'bundle-only' attribute in the
>      "m=" section, it is an indication that the offerer wants to disable
>      the "m=" section [Section 7.5.3].
>   
>      [Section 7.2.2] and [Section 17.1] show an example of an initial
>      offer.

Comma not needed here. Also, this negative phrasing is hard to follow.
I would say "MUST only ... if" here and below


S 7.2.1.
>      In the initial offer, the bundled "m=" section indicated by the
>      offerer BUNDLE-tag is the suggested offerer tagged "m=" section.  The
>      address:port combination associated with the "m=" section will be
>      used by the offerer for sending and receiving bundled media if the
>      answerer selects the "m=" section as the offerer tagged "m=" section
>      [Section 7.3.1].  In addition, if the answerer selects the "m="

This bullet is unnecessary as it immediately follows from the
preoceeding bukllet.


S 7.2.1.
>      section as the offerer tagged "m=" section, the BUNDLE attributes
>      included in the "m=" section will be applied to each "m=" section
>      within the negotiated BUNDLE group.
>   
>      The offerer MUST NOT suggest a bundle-only "m=" section as the
>      offerer tagged "m=" section.

This isn't right, because each BUNDLE group has its own address:port,
so instead "For each BUNDLE group" contained in the offer.

More importantly, it's not the address:port that the answerer chooses,
but rather the m= section. I.e.,

o Determine the first m= section in the BUNDLE group which will be
BUNDLEd in the answer
o Select an answerer BUNDLE address:port


S 7.3.
>        a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
>   
>   7.3.  Generating the SDP Answer
>   
>      When an answerer generates an answer (initial or subsequent) that
>      contains a BUNDLE group the following general SDP grouping framework

Again, this isn't selecting the address:port but rather the m=section


S 7.3.
>         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; and
>   
>      o  Select the answerer tagged "m=" section [Section 7.3.2]; and

This repeats text in S 8.3.


S 7.3.
>   
>      o  Include SDP attributes in the bundled "m=" sections following the
>         rules in [Section 7.1.3]; and
>   
>      o  Include an SDP 'group:BUNDLE' attribute in the answer; and
>   

This text is baffling. As far as I can see, the first condition is
"don't pick it as the head m= section if you intend to move it out".
The second is some entirely different case. Can you rewrite it so it
makes sense.


S 7.3.
>      group, it MUST:
>   
>      o  Move the "m=" section out of the BUNDLE group [Section 7.3.3]; or
>   
>      o  Reject the "m=" section [Section 7.3.4].
>   

No comma


S 7.3.1.
>      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.  Answerer Selection of Offerer tagged 'm=' section
>   

This is the third time you have said this. If you want to say it here,
say "Because ..., if"


S 7.3.1.
>      o  The answerer will not reject the "m=" section [Section 7.3.4]; and
>   
>      o  The "m=" section does not contain a zero port value.
>   
>      If all of the criteria above are fulfilled, the answerer MUST select
>      the "m=" section as the offerer tagged "m=" section.

Same comment here as above. These are entirely different conditions.


S 7.3.1.
>      o  The "m=" section does not contain a zero port value.
>   
>      If all of the criteria above are fulfilled, the answerer MUST select
>      the "m=" section as the offerer tagged "m=" section.
>   
>      If one or more of the criteria are not fulfilled, the answerer MUST

"criteria... are"


S 7.3.1.
>      indicated by that identification-tag.  If there are no more
>      identification-tags in the identification-tag list, the answerer MUST
>      NOT create the BUNDLE group.  Unless the answerer rejects the whole
>      offer, the answerer MUST apply the answerer procedures for moving an
>      "m=" section out of a BUNDLE group [Section 7.3.3] or rejecting an
>      "m=" section within a BUNDLE group [Section 7.3.4] to every bundled

No comma


S 7.3.2.
>   7.3.2.  Answerer Selection of Answerer tagged 'm=' section
>   
>      The answerer MUST select the "m=" section in that corresponds to the
>      selected offerer tagged "m=" section in the corresponding offer
>      [Section 7.3.1] as the answerer tagged "m=" section.  In the answer
>      the answerer BUNDLE-tag indicates the answerer tagged "m=" section.

I'm having trouble reading this paragraph. How do you select an m=
section that correspond to the selected m= section.


S 7.3.3.
>      has been negotiated, a bundled "m=" section can not be moved out of
>      the BUNDLE group in an answer.  Instead an offer is needed.
>   
>      When the answerer generates an answer, in which it moves a bundled
>      "m=" section out of a BUNDLE group, the answerer:
>   

Please put line breaks in between m= sections here too


S 7.3.3.
>   
>      o  MUST include any applicable SDP attribute in the "m=" section,
>         using the normal offer/answer procedures for the each Attributes;
>         and
>   
>      o  MUST NOT place the identification-tag associated with the "m="

address:port, again. It's the m=section that's relevant.


S 7.3.3.
>         list associated with the BUNDLE group.
>   
>      o  MUST NOT include an SDP 'bundle-only' attribute to the "m="
>         section; and
>   
>      Because an answerer is not allowed to move an "m=" section from one

"each" -> "an given"


S 7.3.4.
>      another BUNDLE group [Section 7.5.1].
>   
>   7.3.4.  Rejecting a Media Description in a BUNDLE Group
>   
>      When an answerer wants to reject a bundled "m=" section in an answer,
>      it MUST first check the following criterium:

criterion would be more standard English. criterium generally refers
to a bike race


S 7.3.4.
>         the procedures in [RFC3264]; and
>   
>      o  MUST NOT place the identification-tag associated with the "m="
>         section in the SDP 'group:BUNDLE' attribute identification-tag
>         list associated with the BUNDLE group; and
>   

Again it would make more sense to describe this as suggesting a new m=
section.


S 7.5.
>   
>      o  Pick one bundled "m=" section as the offerer tagged "m=" section.
>         The offerer can either pick the "m=" section that was previously
>         selected by the answerer as the offerer tagged "m=" section, or
>         pick another bundled "m=" section within the BUNDLE group; and
>   

Are you sure disable -> port 0, as opposed to "inactive"


S 7.5.1.
>   
>   7.5.1.  Adding a Media Description to a BUNDLE group
>   
>      When an offerer generates a subsequent offer, in which it wants to
>      add a bundled "m=" section to a previously negotiated BUNDLE group,
>      the offerer follows the procedures in [Section 7.5].  The offerer

You should make clear that it's not possible to have an added m=
section that the peer can take as bundled or not.


S 8.1.
>      correct protocols.
>   
>   8.1.  STUN, DTLS, SRTP
>   
>      Section 5.1.2 of [RFC5764] describes a mechanism to identify the
>      protocol of a received packet among the STUN, DTLS and SRTP protocols

Nit "the correct"


S 9.2.
>         If the RTCP packet is a feedback request that includes target
>         SSRC(s), for each target SSRC that is found in the outgoing SSRC
>         table, deliver a copy of the RTCP packet to the "m=" section
>         associated with that SSRC.  PSFB and RTPFB types that are handled
>         in this way include:
>   

associates -> includes


S 9.3.1.2.
>      section, following the procedures for BUNDLE attributes
>      [Section 7.1.3].  In addition, if the "m=" section that is selected
>      as the offerer tagged "m=" section contained an SDP "rtcp-mux-only"
>      attribute, the answerer MUST include an SDP "rtcp-mux-only" attribute
>      in the answerer tagged "m=" section.
>   

You should rewrite this graf and the one below to be about BUNDLED-
ness not port assignment. I.e., if you are definitely bundled, willing
to bundle, or not bundled.


S 9.3.1.2.
>   
>      If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
>      negotiated in a previous offer/answer exchange, the answerer MUST
>      include an SDP 'rtcp-mux' attribute in the answerer tagged "m="
>      section .  It is not possible to disable RTP/RTCP multiplexing within
>      a BUNDLE group.

Same point here as above. Talking about address:port isn't helpful.

Maybe also briefly say in the abstract how/why RFC7941 is updated.