New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
2 participants
@aboba
Copy link
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

This comment has been minimized.

Copy link
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

This comment has been minimized.

Copy link
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

This comment has been minimized.

Copy link
Contributor

robin-raymond commented Apr 21, 2015

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

This comment has been minimized.

Copy link
Contributor

robin-raymond commented Apr 21, 2015

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

This comment has been minimized.

Copy link
Contributor

robin-raymond commented Apr 21, 2015

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

@robin-raymond

This comment has been minimized.

Copy link
Contributor

robin-raymond commented Apr 21, 2015

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

This comment has been minimized.

Copy link
Contributor

robin-raymond commented Apr 21, 2015

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

@robin-raymond

This comment has been minimized.

Copy link
Contributor

robin-raymond commented Apr 21, 2015

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

@aboba aboba added the PR exists label May 7, 2015

@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