Questions Regarding WebRTC Multi-Session Support and Maximum Bitrate Limit #1384
|
Environment We would like to better understand the expected behavior and limitations of the WebRTC remote viewer.
Is Breeze WebRTC designed to support multiple concurrent remote sessions from the same technician workstation? In our testing, we can successfully connect to a device using Breeze Viewer. However, when opening an additional remote session to another device while the first session is already active, the Breeze Viewer becomes unresponsive and shows a "Not Responding" state. We are not yet certain whether this is: An expected limitation
Could you clarify: Is multiple concurrent device viewing officially supported?
We noticed that the WebRTC stream appears to be capped at approximately 15 Mbps. Could you confirm:
For environments with high-speed connections and modern endpoints, a higher bitrate could significantly improve image quality, responsiveness, and the overall remote support experience. Any guidance would be appreciated. |
Replies: 1 comment
|
Thanks for the detailed write-up — both observations are accurate. Here's where things stand, and I've opened tracking issues for each. 1. Multiple concurrent remote sessions This should work — viewing several different devices at once is a core technician workflow — but today the viewer can't, and what you hit (a second session making the viewer unresponsive) is a real limitation, not your environment. The agent side is fine: each device is its own agent, and the per-agent "one active desktop session" guard only prevents duplicate captures on the same device, not viewing two different ones. The blocker is the viewer being built single-session: it holds one peer connection + one video surface, so opening a second device replaces/clobbers the first instead of running alongside it. Tracking the fix here: #1409 — goal is multiple simultaneous sessions to different devices (each with its own connection, video, clipboard/cursor/input channels). In the meantime, the reliable workaround is one device per viewer instance. 2. WebRTC bitrate Yes — there's a fixed ceiling: 8 Mbps at ≤1080p and 15 Mbps above 1080p, hardcoded in the agent encoder. The stream adapts downward to network conditions but never exceeds that cap, and it isn't currently configurable. On a high-res endpoint over a fast LAN, 15 Mbps is the limiting factor for sharpness well before your network is. You're right that this deserves headroom. Tracking it here: #1410 — make the max bitrate configurable (a quality slider / preset, ideally per-session and as an org/policy default) and raise the ceiling so 1440p/4K are genuinely usable. The plan keeps a configurable cap rather than a blind hardcode bump, so low-bandwidth/WAN remote stays protected while LAN/fiber can push much higher. (For sizing: even at a generous ~80 Mbps per 4K stream, a handful of concurrent sessions is a fraction of a 1 Gbps link — bandwidth isn't the constraint at normal concurrency, the conservative cap is.) |
Thanks for the detailed write-up — both observations are accurate. Here's where things stand, and I've opened tracking issues for each.
1. Multiple concurrent remote sessions
This should work — viewing several different devices at once is a core technician workflow — but today the viewer can't, and what you hit (a second session making the viewer unresponsive) is a real limitation, not your environment. The agent side is fine: each device is its own agent, and the per-agent "one active desktop session" guard only prevents duplicate captures on the same device, not viewing two different ones. The blocker is the viewer being built single-session: it holds one peer connection + one video sur…