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

Den 12. juli 2018 10:24, skrev Stefan Håkansson LK:
> 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.

My impression of how we ended up with transceiver.stop() was:

- "SDP has special semantics for port=0 on an M-line"
- "We've got to figure out how to set that! Since m-lines are
transceivers, transceiver.<something>. BTW, what does it mean?"
- "It means that the m-line isn't used any more - people use it to stop
things"
- "OK, let's call it transceiver.stop() then".

My take: It's a way to set the port to zero, thereby telling the other
end (which may or may not be webrtc) not to use that media section any
more. We should take the consequences of that, and just follow the rules
for setting a port to zero - including the BUNDLE "yes, this will break"
rule.

It is most useful for dealing with non-WebRTC endpoints, and in those
cases, it's also likely that "max-compat" will be useful.

I don't have any objection to knowing which transceiver is
offerer-tagged. I just don't think the number of scenarios where I care
will be large.

Received on Thursday, 12 July 2018 11:37:10 UTC