Open
Description
Your environment.
- Version: v3.0.3
What did you do?
- Make a pair of
PeerConnection
s, 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".
- The connection-state of
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
.
Metadata
Metadata
Assignees
Labels
No labels