RTCDtlsTransport.start needs to return a promise #194

robin-raymond opened this Issue Apr 21, 2015 · 6 comments


None yet

2 participants


RTCDtlsTransport.start() needs to return a promise so the programmer is aware when either the remote fingerprints become verified or it fails to verify (to avoid busy polling).

@robin-raymond robin-raymond added the 1.1 label Apr 21, 2015

Alternative to a promise: We add a validated state to the RTCDtlsTransport state table. If start remote fingerprints validate, it goes to this state (after connected of course). If it fails fingerprint validation, object could go to closed state. Question: does this cause 1.0 compatibility concern?


NOTE: We already have to monitor the closed state on a RTCDtlsTransport, so if we did a promise we would have to monitor both the rejection of the promise and the closed state. So for that reason I'd prefer to not use a promise and use a validated state so the error is already monitored via closed state and we can monitor validated state to know the remote party is truly whom they claim to be.

aboba commented Apr 26, 2015

Would we still need an additional RTCDtlsTransportState if we we defined "connected" and "closed" as follows?

DTLS has completed negotiation of a secure connection (including DTLS-SRTP and remote fingerprint verification).

The DTLS connection has been closed intentionally or as the result of an error (such as a failure to validate the remote fingerprint).


It's not even this simple. The RTCDtlsTransport.getLocalParamters() returns certificate fingerprints and those certs can take a while to generate. So that method either needs to be made a promise or we need to create a cert management API as suggested in bug #195 . If we mandate that a certificate is required then both sides would therefor need to have generated and exchanged their certs before calling RTCDtlsTransport.start() or media will not be allowed to flow. The question I have is do we want to allow any media or data to flow prior to validating the fingerprint. If no, then connected state can be the same as validated since we will never send media without validation the fingerprint anyway and we'd never go into the connected state unless the fingerprints have been validated.

Keep in mind that we cannot send or receive DTLS packets properly until we have both sides generated their respective certs but they need not be signalled yet for media to flow (if you don't mind being in a potential man-in-the-middle attack state). If you don't mind temporary man-in-the-middle then there is a reason to have validated separated from connected.


Suggested solution: For RTCDtlsTransport connected should imply that start has been called and is validated. However, incoming media can flow through prior to the connected state but outgoing media will not start sending until in the connected state.

Reasoning: the remote party might have validate you already and determined the fingerprints are correct and thus starts sending media immediately but you have not yet validated your side so you won't send media until you do the same.

aboba commented Apr 29, 2015

Here is a potential update to DtlsTransportState:

  The RTCDtlsTransport object has been created and has not started negotiating yet.

  DTLS is in the process of negotiating a secure connection.  Once a secure connection is negotiated and DTLS-SRTP has derived keys (but prior to verification of the remote fingerprint, enabled by calling start(), incoming media can flow through.

  DTLS has completed negotiation of a secure connection (including DTLS-SRTP and remote fingerprint verification). Outgoing media can now flow through.

  The DTLS connection has been closed intentionally or as the result of an error (such as a failure to validate the remote fingerprint).
@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:

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

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

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

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

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

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

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

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

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

- Updated terminology in Section 1.1 as noted in:

- Updated RTCDtlsTransportState definitions, as noted in:

- Updated RTCIceTransportState definitions, as noted in:
@aboba aboba closed this May 21, 2015
@aboba aboba reopened this Jun 16, 2015
@aboba aboba closed this Jun 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment