Re: [MMUSIC] Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)

[Eric Rescorla <[e-mail]>]

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.

   o  Initial offer: The first offer, within an SDP session (e.g. a SIP
      dialog when the Session Initiation Protocol (SIP) [RFC3261] is

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.

   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?

   o  In the initial offerer, the offerer MUST NOT include IDENTICAL and
      TRANSPORT multiplexing category SDP attributes (BUNDLE attributes)

initial offer

      TRANSPORT multiplexing category SDP attributes (BUNDLE attributes)
      in bundle-only "m=" sections.  The offerer MUST included such
      attributes in all other bundled "m=" sections.  In the initial

MUST include

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

   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

   add a bundled "m=" section to a previously negotiated BUNDLE group,
   the offerer follows the procedures in [Section 7.5].  The offerer
   either picks the added "m=" section, or an "m=" section previously

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

On Sat, May 19, 2018 at 1:32 PM, Eric Rescorla <[e-mail]> wrote:

> Tools failure here failed to get my new review. Expect something correct
> soon.
>
> On Sat, May 19, 2018 at 1:18 PM, Eric Rescorla <[e-mail]> wrote:
>
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-mmusic-sdp-bundle-negotiation-51: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundl
>> e-negotiation/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> 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.
>>
>>
>>
>