Draft: draft-ietf-rtcweb-jsep

Commentary: and 
 To resolve WGLC comments : it was agreed to incorporate a reference to this text in 8843bis : That text ended up in s7.6 . 
 When draft-8843bis is given an RFC number , this draft should reference the new RFC .
Mailing list commentary: Hi , Eventhough I would not like to make more changes than necessary , I am fine with " 3PCC Considerations " . However , your suggested text is very difficult to understand in some places , so let me give it a try . ( The first paragraph is generic , the second SIP specific , and the third BUNDLE specific . )
Not seeing any objections for a month then once -02 is submitted we will progress this towards our AD . spt
Paragraph (version A):
When RFC8829 was published, inconsistencies regarding BUNDLE RFC8843
operation were identified with regard to both the specification text
as well as implementation behavior.  The former concern was addressed
via an update to RFC8843.  For the latter concern, it was observed
that some implementations implemented the "max-bundle" bundle policy
defined in RFC8829 by assuming that bundling had already been
negotiated, rather than marking "m=" sections as bundle-only as
indicated by the specification.  In order to prevent unexpected
changes to applications relying on the pre-standard behavior, the
decision was made to deprecate "max-bundle" and instead introduce an
identically defined "must-bundle" policy that, when selected,
provides the behavior originally specified by RFC8829.
Paragraph (version B):
When RFC8829 was published, inconsistencies regarding BUNDLE I-
D.ietf-mmusic-rfc8843-bis operation were identified with regard to
both the specification text as well as implementation behavior.  The
former concern was addressed via an update to I-D.ietf-mmusic-
rfc8843-bis.  For the latter concern, it was observed that some
implementations implemented the "max-bundle" bundle policy defined in
RFC8829 by assuming that bundling had already been negotiated, rather
than marking "m=" sections as bundle-only as indicated by the
specification.  In order to prevent unexpected changes to
applications relying on the pre-standard behavior, the decision was
made to deprecate "max-bundle" and instead introduce an identically
defined "must-bundle" policy that, when selected, provides the
behavior originally specified by RFC8829.
Paragraph (version A):
Note that gathering phases only gather the candidates needed by
new/recycled/restarting "m=" sections; other "m=" sections continue
to use their existing candidates.  Also, if an "m=" section is
bundled (either by a successful bundle negotiation or by being marked
as bundle-only), then candidates will be gathered and exchanged for
that "m=" section if and only if its MID item is a BUNDLE-tag, as
described in RFC8843.
Paragraph (version B):
Note that gathering phases only gather the candidates needed by
new/recycled/restarting "m=" sections; other "m=" sections continue
to use their existing candidates.  Also, if an "m=" section is
bundled (either by a successful bundle negotiation or by being marked
as bundle-only), then candidates will be gathered and exchanged for
that "m=" section if and only if its MID item is a BUNDLE-tag, as
described in I-D.ietf-mmusic-rfc8843-bis.
Paragraph (version A):
The application can specify its preferred policy regarding the use of
BUNDLE, the multiplexing mechanism defined in RFC8843.  Regardless of
policy, the application will always try to negotiate bundle onto a
single transport and will offer a single bundle group across all "m="
sections; use of this single transport is contingent upon the
answerer accepting bundle.  However, by specifying a policy from the
list below, the application can control exactly how aggressively it
will try to bundle media streams together, which affects how it will
interoperate with a non-bundle-aware endpoint.  When negotiating with
a non-bundle-aware endpoint, only the streams not marked as bundle-
only streams will be established.
Paragraph (version B):
The application can specify its preferred policy regarding the use of
BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic-
rfc8843-bis.  Regardless of policy, the application will always try
to negotiate bundle onto a single transport and will offer a single
bundle group across all "m=" sections; use of this single transport
is contingent upon the answerer accepting bundle.  However, by
specifying a policy from the list below, the application can control
exactly how aggressively it will try to bundle media streams
together, which affects how it will interoperate with a non-bundle-
aware endpoint.  When negotiating with a non-bundle-aware endpoint,
only the streams not marked as bundle-only streams will be
established.
Paragraph (version A):
RFC8859 groups SDP attributes into different categories.  To avoid
unnecessary duplication when bundling, attributes of category
IDENTICAL or TRANSPORT MUST NOT be repeated in bundled "m=" sections,
repeating the guidance from RFC8843.  This includes "m=" sections for
which bundling has been negotiated and is still desired, as well as
"m=" sections marked as bundle-only.
Paragraph (version B):
RFC8859 groups SDP attributes into different categories.  To avoid
unnecessary duplication when bundling, attributes of category
IDENTICAL or TRANSPORT MUST NOT be repeated in bundled "m=" sections,
repeating the guidance from I-D.ietf-mmusic-rfc8843-bis.  This
includes "m=" sections for which bundling has been negotiated and is
still desired, as well as "m=" sections marked as bundle-only.
Paragraph (version A):
Note that if bundling has been negotiated, unbundling is no longer
possible, and media sections will not be marked as bundle-only.  This
is by design, but could cause issues in the rare case of sending a
subsequent offer as an initial offer to a non-bundle-aware endpoint
via Third Party Call Control (3PCC).
Paragraph (version B):
Note that if bundling has been negotiated, unbundling is no longer
possible, and media sections will not be marked as bundle-only.  This
is by design, but could cause issues in the rare case of sending a
subsequent offer as an initial offer to a non-bundle-aware endpoint
via Third Party Call Control (3PCC), as discussed in I-D.ietf-mmusic-
rfc8843-bis.
Paragraph (version A):
If the answer contains valid bundle groups, discard any ICE
components for the "m=" sections that will be bundled onto the
primary ICE components in each bundle, and begin muxing these "m="
sections accordingly, as described in RFC8843.
Paragraph (version B):
If the answer contains valid bundle groups, discard any ICE
components for the "m=" sections that will be bundled onto the
primary ICE components in each bundle, and begin muxing these "m="
sections accordingly, as described in I-D.ietf-mmusic-rfc8843-bis.
Paragraph (version A):
When bundling, associating incoming RTP/RTCP with the proper "m="
section is defined in RFC8843.  When not bundling, the proper "m="
section is clear from the ICE component over which the RTP/RTCP is
received.
Paragraph (version B):
When bundling, associating incoming RTP/RTCP with the proper "m="
section is defined in I-D.ietf-mmusic-rfc8843-bis.  When not
bundling, the proper "m=" section is clear from the ICE component
over which the RTP/RTCP is received.