IceTransport.stop() affect on RtpSender/Receiver #186

Closed
aboba opened this Issue Apr 8, 2015 · 8 comments

Projects

None yet

2 participants

@aboba
Contributor
aboba commented Apr 8, 2015

From Robin Raymond:
http://lists.w3.org/Archives/Public/public-ortc/2015Mar/0014.html

What happens to RtpSender/Receiver associated to an IceTransport() if IceTransport.stop() is called? For example, the RTCP was non-mux and the DtlsTransport for RTCP is .stop()’ed. This case would mean RTP would continue to flow but RTCP would stop. Or the RTP transport could be closed without RTCP being close. Or both could be closed.

Currently things “silently” fail (with perhaps some statistics going ‘wrong’). There’s no error or event on the RtpSender/Receiver to inform of the bad condition.

@aboba aboba added the 1.1 label Apr 8, 2015
@aboba
Contributor
aboba commented Apr 8, 2015

When receiver.receive(parameters) or sender.send(parameters) is called, and parameters.rtcp.mux is set to false, then there needs to be an RTCP DtlsTransport and IceTransport, set (and not stop'd) or else an exception (InvalidParameters) will be thrown.

Once IceTransport.stop(), is called, calling DtlsTransport.start() on a DtlsTransport constructed from that IceTransport should probably throw an exception.
Also, wouldn't a stop'd IceTransport be considered invalid for constructing DtlsTransport objects, and wouldn't a DtlsTransport object with a stop'd IceTransport be considered invalid for use in constructing RtpSender/Receiver objects?

If IceTransport.stop() is called after DtlsTransport.start() is called, should the DtlsTransport.onerror handler be called?

Is there ever a valid reason to call DtlsTransport.stop() on an RTP or RTCP DtlsTransport attached to an active RtpReceiver or RtpSender?

@aboba
Contributor
aboba commented Apr 21, 2015

Here are some questions relating to this issue:

Section 2.3.1: RTCDtlsTransport.onerror

Should calling transport.stop() cause this error handler to be fired?

Section 2.3.2: RTCDtlsTransport.start()

Should we throw an InvalidStateError exception if stop() or transport.stop() has been called?

Section 3.3.2 RTCIceTransport.createAssociatedTransport()

Should we throw an InvalidStateError exception if stop() has been called? What about if gatherer.close() has been called?

Section 3.3.2 RTCIceTransport.start()

Should we throw an InvalidStateError exception if stop() or gatherer.close() has been called?

Section 4.3.1 RTCIceTransportController.addTransport()

Should we throw an InvalidStateError exception if transport.stop() had been called? What about transport.gatherer.close()?

Section 6.3.1

onerror: Is this event handler fired if transport.stop(), rtcpTransport.stop(), transport.transport.stop() or rtcpTransport.transport.stop() is called?

Section 6.3.2

send: Is an InvalidStateError exception fired if transport.stop(), rtcpTransport.stop(), transport.transport.stop() or rtcpTransport.transport.stop() has been called?

setTransport: Is an InvalidStateError exception fired if transport.stop(), rtcpTransport.stop(), transport.transport.stop() or rtcpTransport.transport.stop() has been called?

Section 7.3.1

onerror: Is this event handler fired if transport.stop(), rtcpTransport.stop(), transport.transport.stop() or rtcpTransport.transport.stop() is called?

Section 7.3.2

receive: Is an InvalidStateError exception fired if transport.stop(), rtcpTransport.stop(), transport.transport.stop() or rtcpTransport.transport.stop() has been called?

setTransport: Is an InvalidStateError exception fired if transport.stop(), rtcpTransport.stop(), transport.transport.stop() or rtcpTransport.transport.stop() has been called?

@robin-raymond
Contributor

If RTCIceTransport.stop() is called and a RTCDtlsTransport is associated, the RTCDtlsTransport should go to the closed state because it's transport is effectively dead. Calling RTCDtlsTransport.stop() will also go to the closed state and calling RTCDtlsTransport.stop() when in the closed state is a noop.

If RTCIceTransport is in the closed state prior to association of an RTCDtlsTransport and the RTCDtlsTransport is constructed with that closed RTCIceTransport then an exception should be thrown upon construction of the RTCDtlsTransport.

@robin-raymond
Contributor

change some text here:
RTCIceTransport.createAssociatedTransport()

Create an associated RTCIceTransport for RTCP. If called more than once for the same component, or if the RTCIceTransport is in the closed state, throw an InvalidStateError exception. If called when component is "RTCP", throw an InvalidStateError exception.

@robin-raymond
Contributor

RTCIceTransport.addRemoteCandidate() and RTCIceTransport.setRemoteCandidates() must throw an InvalidStateError exception if the RTCIceTransport is in the closed state.

@robin-raymond
Contributor

RTCIceTransportController.addTransport() must throw an InvalidStateError exception if the RTCIceTransport passed in is in the closed state. FYI - The associated RTCIceGatherer's state is not relevant.

@robin-raymond
Contributor

RTCIceGatherer.createAssociatedGatherer() must throw an InvalidStateError exception if the RTCIceGatherer is in the closed state.

@robin-raymond
Contributor

I don't think we should be firing errors or throwing exceptions on the RTCRtpSender or RTCRtpReceiver constructor or setTransport() method is the RTCRtpDtlsTransport is in the closed state (or any of the dependency transport objects below). The reason is because those lower layer objects already indicate their own failure states and having an error thrown by the sender/receivers would cause a programmer to be unclear if this is a new problem that needs fixing vs an existing problem they already resolve by virtue of fixing the error condition from the lower layer transports.

@robin-raymond robin-raymond pushed a commit that referenced this issue May 7, 2015
Robin Raymond - sender.setTrack() updated to return a Promise, as noted in:
#148

- Clarified handling of incoming connectivity checks prior to calling iceTransport.start(), as noted in:
#170

- Clarified handling of incoming DTLS packets, as noted in:
#173

- Added RTCIceGatherer as an optional argument to the RTCIceTransport constructor, as noted in:
#174

- Clarified handling of contradictory RTP/RTCP multiplexing settings, as noted in:
#185

- Clarified error handling relating to RTCIceTransport, RTCDtlsTransport and RTCIceGatherer objects in the "closed" state, as noted in:
#186

- Added component method and createAssociatedGatherer() method to the RTCIceGatherer object, as noted in:
#188

- Added close() method to the RTCIceGatherer object as noted in:
#189

- Clarified behavior of TCP candidate types, as noted in:
#190

- Clarified behavior of iceGatherer.onlocalcandidate, as noted in:
#191

- Updated terminology in Section 1.1 as noted in:
#193

- Updated RTCDtlsTransportState definitions, as noted in:
#194

- Updated RTCIceTransportState definitions, as noted in:
#197
c006197
@aboba aboba closed this May 13, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment