Conversation
A battery camera has to be woken before it joins its signaling channel, and the channel buffers nothing, so the single offer we sent was simply gone by the time the camera was listening. The live view stayed black and nothing in the log said why. Wake DEVICEMGMT models first, then resend the offer and candidates every 4 seconds until one comes back answered. Cameras still take 5 to 20 seconds to start streaming. That is the wakeup itself, not this loop.
The session config was fetched once during platform setup and never retried, so any camera asleep at that moment kept a null config for the lifetime of the integration and raised "WebRTC session configuration not available yet" on every attempt. For battery cameras that is most of them, most of the time. It could not recover on its own either: the frontend asks for the config before it asks for an offer, and the offer handler was the only place the wakeup ran. Fall back to public STUN so the sync hook can answer, and refresh the real config out of band. wake_and_fetch_config polls get_stream_info six times over 20 seconds, because a battery camera keeps reporting iot-state 0 for the first few seconds after it wakes.
|
|
|
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
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
2 participants
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.
Second of three related WebRTC fixes. Depends on #904, and since I cannot push a base branch to this repo the diff here shows #904's commit as well. Mine is the second commit,
fix: recover WebRTC session config for cameras asleep at setup.The session config was fetched once during platform setup and never retried, so any camera asleep at that moment kept a null config for the life of the integration and raised "WebRTC session configuration not available yet" on every attempt. For battery cameras that is most of them, most of the time.
It could not recover on its own either: the frontend asks for the config before it asks for an offer, and the offer handler was the only place the wakeup ran.
Falls back to public STUN so the sync hook can answer, and refreshes the real config out of band.
wake_and_fetch_configpollsget_stream_infosix times over 20 seconds, because a battery camera keeps reportingiot-state 0for the first few seconds after it wakes.