Re: Issue 1858: the astonishing behavior of transceiver.stop

On 2018-07-10 22:19, Bernard Aboba wrote:
> 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.

I guess that to some extent this depends on the intended use cases for 
transceiver.stop(). What use of it do we envision?

Another question that pops to mind: would the use cases for trx.stop() 
be compatible with the "max-compat" bundle policy? If so that could be a 
way to handle this. If not we probably need to look into 2. or 3. above.

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

Received on Thursday, 12 July 2018 08:25:26 UTC