Skip to content

ENG-4952 - Player fails to start media stream when Chat/Captions enabled and Data Channels disabled server-side - #99

Open
rafaelAlonso-wowza wants to merge 2 commits into
feature/ENG-3870_WebRTC_modernization_phase_1from
bug/ENG-4952_player_fails_to_start_media_when_data_channel_enabled_but_disabled_in_engine
Open

ENG-4952 - Player fails to start media stream when Chat/Captions enabled and Data Channels disabled server-side#99
rafaelAlonso-wowza wants to merge 2 commits into
feature/ENG-3870_WebRTC_modernization_phase_1from
bug/ENG-4952_player_fails_to_start_media_when_data_channel_enabled_but_disabled_in_engine

Conversation

@rafaelAlonso-wowza

Copy link
Copy Markdown
Collaborator

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

  • Only re-offer for an ICE restart we actually asked for — the browser re-raises negotiationneeded on every return to stable once 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-shot WeakSet of 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,400
  • Detect the refusal on the wiredataChannelsAcceptedInAnswer treats a missing m=application section or a port of 0 as a rejection, and ensureApplicationSectionInAnswer appends a rejected stand-in when the server drops the section outright, so setRemoteDescription no longer fails on an m-line mismatch and take audio/video down with it. Colocated with createSctpBootstrap, mirroring how SIMULCAST_REJECTED_MESSAGE sits beside simulcastAcceptedInAnswer. src/webrtc/attachDataChannel.js:41,46,52,62
  • Degrade instead of failing, identically on both pages — the data-channel setup helpers now return a close handle, and on refusal the channels are shut down and reported via a new onDataChannelsUnavailable callback without touching media state. Replaces the publisher's previous reliance on an incidental, browser-dependent channel.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-66
  • Release the captions channel on stopstartCaptionBroadcast returned a stop() 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 the onclose handler. src/webrtc/captions.js:36,47,54,56
  • Make a stalled play session recoverable — a failed start left the peer connection and websocket alive with their handlers attached, and Stop was gated on connected so a session stuck mid-negotiation could not be stopped at all. stopPlay now detaches handlers before closing (matching tearDownConnection on the publish side), onError routes 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**

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant