ENG-4952 - Player fails to start media stream when Chat/Captions enabled and Data Channels disabled server-side - #99
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When Data Channels are disabled for the application in WSEM, enabling Chat or Captions on the player left media dead and both pages flooding the engine with re-offers. The SCTP section is now treated as optional in the offer/answer: media plays either way, and the refusal is reported through the existing error banner on both the play and publish pages.
Changes made
negotiationneededon every return tostableonce a data channel exists whose m-line the server refused, and all four handlers answered it unconditionally, renegotiating forever so ICE never settled. A one-shotWeakSetof peer connections owing a re-offer now gates them; it lives at module level so both the automatic recovery path and the manual Restart ICE buttons arm it without needing the recovery handle.src/utils/IceRestartUtils.js:17,19,27,49,109,src/webrtc/startPlay.js:162,394,src/webrtc/startPublish.js:195,400dataChannelsAcceptedInAnswertreats a missingm=applicationsection or a port of0as a rejection, andensureApplicationSectionInAnswerappends a rejected stand-in when the server drops the section outright, sosetRemoteDescriptionno longer fails on an m-line mismatch and take audio/video down with it. Colocated withcreateSctpBootstrap, mirroring howSIMULCAST_REJECTED_MESSAGEsits besidesimulcastAcceptedInAnswer.src/webrtc/attachDataChannel.js:41,46,52,62onDataChannelsUnavailablecallback without touching media state. Replaces the publisher's previous reliance on an incidental, browser-dependentchannel.onerror.src/webrtc/startPlay.js:19,33,233,242,455,467,src/webrtc/startPublish.js:24,42,274,292,477,498,src/components/play/Player.js:92,src/components/publish/Publisher.js:9,64-66startCaptionBroadcastreturned astop()that only cleared the timer, leaving the channel open when the publisher gives up on data. It now closes the channel too, with the timer-only path kept internal for theonclosehandler.src/webrtc/captions.js:36,47,54,56connectedso a session stuck mid-negotiation could not be stopped at all.stopPlaynow detaches handlers before closing (matchingtearDownConnectionon the publish side),onErrorroutes through it, and WHEP hands over the peer connection immediately so a partial failure is still closable.src/webrtc/stopPlay.js:11,src/components/play/Player.js:19,32,57,105,src/webrtc/startPlay.js:362**How it looks**