IceTransport.stop() affect on RtpSender/Receiver

[aboba]

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]

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]

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]

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]

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]

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

[robin-raymond]

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]

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

[robin-raymond]

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.