- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Fri, 1 May 2015 17:18:30 +0000
- To: "public-ortc@w3.org" <public-ortc@w3.org>
- CC: Robin Raymond <robin@hookflash.com>
I've done a review of the potential errors that can result from calling iceTransport.stop() and iceGatherer.close(). Here are some of the issues and proposed fixes: RTCDtlsTransport Attempting to construct an RTCDtlsTransport from an RTCIceTransport in the "closed" state should generate an exception. So should calling dtlsTransport.start() on a DTLS object in the "closed" state. If IceTransport.stop() is called, this should cause the associated RTCDtlsTransport to go into the "closed" state. Proposed additional text: Section 2.2 If an attempt is made to construct a RTCDtlsTransport instance from an RTCIceTransport in the "closed" state, an InvalidStateError exception is thrown. Section 2.3.2 start If remoteParameters is invalid, throw an InvalidParameters exception. If start() is called after a previous start() call, or if state is "closed", throw an InvalidStateError exception. stop Stops and closes the DTLS transport object. Calling stop() when state is "closed" has no effect. Section 2.7 enum RTCDtlsTransportState closed The DTLS connection has been closed intentionally via a call to stop() or as the result of an error (such as a failure to validate the remote fingerprint). Calling transport.stop() will also result in a transition to the "closed" state. RTCIceTransport If an IceTransport object is in the "closed" state, then calling iceTransport.start() should throw an exception, as should a call to createAssociatedTransport(), addRemoteCandidate() or setRemoteCandidates(). If the IceGatherer is in the "closed" state, then attempting to use the closed object to construct other objects or in iceTransport.start() should raise an exception. Proposed text additions: Section 3.2 If gatherer.state is "closed" or gatherer.component is "RTCP", then throw an InvalidStateError exception. Section 3.3.2: 3.3.2 Methods addRemoteCandidate If state is "closed", throw an InvalidStateError exception. createAssociatedTransport If called more than once for the same component, or if state is "closed", throw an InvalidStateError exception. If called when component is "RTCP", throw an InvalidStateError exception. setRemoteCandidates If state is "closed", throw an InvalidStateError exception. start If start() is called with invalid parameters, throw an InvalidParameters exception. For example, if gatherer.component has a value different from iceTransport.component, throw an InvalidParameters exception. If state or gatherer.state is "closed", throw an InvalidStateError exception. stop Stops and closes the current object. Also removes the object from the RTCIceTransportController. Calling stop() when state is "closed" has no effect. Section 4: IceTransportController Attempting to add an IceTransport in the "closed" state should throw an exception. Additional text: 4.3.1 Methods addTransport If transport.state is "closed", throw an InvalidStateError exception. If transport has already been added to another RTCIceTransportController object, or if transport.component is "RTCP", throw an InvalidStateError exception. Section 5: IceGatherer Calling close() on an IceGatherer that is already in the "closed" state has no effect. Once "close" is called, you cannot call createAssociatedGatherer. Proposed additional text: close Prunes all local candidates. Associated RTCIceTransport objects transition to the "disconnected" state. Calling close() when state is "closed" has no effect. createAssociatedGatherer If state is "closed", throw an InvalidStateError exception. If called more than once for the same component or if component is "RTCP", throw an InvalidStateError exception. -----Original Message----- From: Bernard Aboba Sent: Tuesday, April 7, 2015 9:26 PM To: public-ortc@w3.org Subject: Re: Issue 186: IceTransport.stop() affect on RtpSender/Receiver [BA] 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? Robin Raymond said: 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. -Robin
Received on Friday, 1 May 2015 17:18:58 UTC