Don't terminate PeerConnection after moving to the failed state #202
+114
−26
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have been terminating PeerConnection after it moved to the failed state. While this approach was easy to implement, it had two drawbacks:
get_stats
as the process was no longer aliveThis PR keeps peer connection alive even when it moves to the failed state. This is pretty big breaking change as a lot of our examples and demo apps relies on linking to the PeerConnection process and waiting until it crashes.
Things to note:
addTrack
,addTransceiver
orcreateOffer
even though the connection might not be able to restart (that's the case when DTLS fails, or at least we don't support DTLS restart).send_rtp
and others, and moving to the failed state so such a log could appear pretty oftenRelevant specs: