Issue 1858: the astonishing behavior of transceiver.stop

As noted in Issue 1858, calling transceiver.stop() when using bundled "m=" sections can have unexpected side effects. For example, BUNDLE Section 7.3.3 suggests that an Answerer cannot reject an offerer tagged "m=" section on its own, but instead must reject other "m=" sections.  This implies that if transceiver.stop() does not throw, it will have the side effect of "stopping" all transceivers in the BUNDLE group.

Currently the WebRTC 1.0 API provides no mechanism allowing the application to designate which transceiver corresponds to the tagged "m=" section, nor to determine which "m=" section has been tagged (aside from parsing the SDP).  Therefore, the application cannot easily anticipate either potential behavior - throwing or stopping all transceivers in the BUNDLE group.

What are the potential alternatives?


  1.  Document the issue but do not fix it. This approach would effectively relegate use of transceiver.stop() to scenarios where stopping all transceivers in the BUNDLE group is a desired outcome.  If that is not the desired outcome, then causing transceiver.direction to transition to "inactive" might be better choice, since that causes transceiver.receiver and transceiver.sender to stop sending while not affecting the operation of other transceivers.
  2.  Add a mechanism by which the application can determine which transceiver is offerer-tagged, but cannot set this attribute.
  3.  Add mechanisms by which an application can set which transceiver is offerer-tagged.

Discuss.

The BUNDLE specification states:

7.2.1<https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-52#section-7.2.1>.  Suggesting the Offerer tagged 'm=' section


   In the initial BUNDLE 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<https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-52#section-7.3.1>].  In addition, if the answerer selects the "m="
   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.

   It is RECOMMENDED that the suggested offerer tagged "m=" section is a
   bundled "m=" section that the offerer believes it is unlikely that
   the answerer will reject, or move out of the BUNDLE group.  How such
   assumption is made is outside the scope of this document.

7.3.3<https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-52#section-7.3.3>.  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 criterion:

   o  In the corresponding offer, the "m=" section is the offerer tagged
      "m=" section.

   If the criterium above is fulfilled the answerer can not reject the
   "m=" section in the answer.  The answerer can either reject the whole
   offer, reject each bundled "m=" section within the BUNDLE group, or
   keep the "m=" section within the BUNDLE group in the answer and later
   create an offer where the "m=" section is disabled within the BUNDLE
   group [Section 7.5.3<https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-52#section-7.5.3>].

   When an answerer generates an answer, in which it rejects a bundled
   "m=" section, the answerer:

   o  MUST assign a zero port value to the "m=" section, according to
      the procedures in [RFC3264<https://tools.ietf.org/html/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

   o  MUST NOT include an SDP 'bundle-only' attribute in the "m="
      section.




Reference: https://github.com/w3c/webrtc-pc/issues/1858
[https://avatars0.githubusercontent.com/u/14118599?s=400&v=4]<https://github.com/w3c/webrtc-pc/issues/1858>

What happens when an answerer stops a transceiver that ...<https://github.com/w3c/webrtc-pc/issues/1858>
github.com
The BUNDLE spec says: When an answerer wants to reject a bundled "m=" section in an answer, it MUST first check the following criterium: -In the corresponding offer, an offerer BUNDLE address:port (previously selected [Section 8.3.1] or ...