Skip to content
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

DTLS should be restarted when the remote DTLS fingerprint has been changed or the tls-id has changed during applying an answer #1636

Open
mission-liao opened this issue Jan 14, 2021 · 0 comments · May be fixed by #1846
Assignees

Comments

@mission-liao
Copy link
Contributor

Your environment.

  • Version: v3.0.3

What did you do?

  • Make a pair of PeerConnections, one is at server side, and another one is at App side.
  • The App is crashed or is swipe out from foreground.
  • When the App is back, I would need to create a fresh PeerConnection and pair it with the one at server side.
  • The pairing is not working, ICE is connected but not the DTLS part
    • The connection-state of PeerConnection at server side shows "connected".
    • The connection-state of PeerConnection at App side turns to "failed".

What did you expect?

  • the connection between them should be able to establish

What happened?

  • The PeerConnection at server side didn't restart its DTLS handshaking. Per JSEP spec 5.11, PeerConnection should restart DTLS when corresponding parameters changed in remote session-description as offer.
      If the remote DTLS fingerprint has been changed or the tls-id has
      changed, tear down the DTLS connection.  This includes the case
      when the PeerConnection state is "have-remote-pranswer".  If a
      DTLS connection needs to be torn down but the answer does not
      indicate an ICE restart or, in the case of "have-remote-pranswer",
      new ICE credentials, an error MUST be generated.  If an ICE
      restart is performed without a change in tls-id or fingerprint,
      then the same DTLS connection is continued over the new ICE
      channel.  Note that although JSEP requires that answerers change
      the tls-id value if and only if the offerer does, non-JSEP
      answerers are permitted to change the tls-id as long as the offer
      contained an ICE restart.  Thus, JSEP implementations which
      process DTLS data prior to receiving an answer MUST be prepared to
      receive either a ClientHello or data from the previous DTLS
      connection.

We can consider to implement this part in our PeerConnection.SetRemoteDescription.

@mission-liao mission-liao self-assigned this Jan 14, 2021
@Antonito Antonito self-assigned this Jun 26, 2021
Antonito added a commit to pion/srtp that referenced this issue Jun 26, 2021
This is needed for DTLS restart, as mentioned in pion/webrtc#1636.
Antonito added a commit that referenced this issue Jun 26, 2021
@Antonito Antonito linked a pull request Jun 26, 2021 that will close this issue
Antonito added a commit to pion/srtp that referenced this issue Jun 26, 2021
This is needed for DTLS restart, as mentioned in pion/webrtc#1636.
Antonito added a commit to pion/srtp that referenced this issue Jun 27, 2021
This is needed for DTLS restart, as mentioned in pion/webrtc#1636.
Antonito added a commit that referenced this issue Jun 29, 2021
Antonito added a commit that referenced this issue Jun 29, 2021
Antonito added a commit that referenced this issue Jun 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants