Feature add close signaling - #807
Conversation
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
The trickle section's closing note discusses terminating the WebSocket session and states the only reason to keep the connection is to extend. With the new close command, there is a second reason: to actively release device resources (ICE candidates, TURN connections) before teardown. Point readers to section_close. Co-Authored-By: Claude <noreply@anthropic.com>
|
Typically web browser clients can be closed at any moment, it's normal for a human to just close a browser tab, and then the client just stops, it isn't able to send any "close" command. So a camera must be able to deal with this, with timeouts and such, and detect that a client has disappeared, and then free local resources. It's not reliable to only free resources when a "close" is received. And with such automatic freeing implemented, is there any need for a "close" command? |
| signaling server shall return a successful response rather than 404, so a client | ||
| can retry safely after a network interruption. The 404 fault applies only when the | ||
| session ID was never valid.</para> | ||
| </section> |
There was a problem hiding this comment.
It would also be helpful to clarify the expected behavior if a trickle or extend command is received for an already closed session—specifically, whether the signaling server should return a 404 Not Found fault or silently drop/ignore the message.
There was a problem hiding this comment.
trickle: Returns success but does not forward (avoids flooding the client with errors, consistent with idempotent design).
extend: Returns 404 (clearly signals the session has ended, preventing "ghost sessions").
…iptions for trickle and extend commands
|
@jcadev Automatic reclamation is the mandatory foundation; close is an optimization for prompt, graceful termination and explicit intent. They are complementary, not interchangeable.The spec (section_close in specs/doc/WebRTC.xml) now states this explicitly: close is an optimization, and devices and signaling servers shall still implement timeout- and disconnection-based cleanup as a fallback, since a client may disappear without sending close. |
The ONVIF WebRTC specification lacks an explicit stream close signaling mechanism, leading to resource waste, difficult state management, state inconsistency, and degraded user experience. It is recommended to add this mechanism so clients can actively notify devices to stop streaming, release resources promptly, enable platforms to accurately track session lifecycles, and improve system performance and user experience.