Milestone 2025 R2 Webrtc Stream Encrypted Alert

When connecting to a milestone camera via WebRtc the stream will cut out after a few minutes. When looking at a network capture we noticed that the milestone endpoint was sending an Encrypted Alert before the stream was cut off.

Searching encrypted alerts I saw:

What It Means

  • Encrypted Payload: Packet analyzers like Wireshark show “Encrypted Alert” because the content is protected by symmetric encryption keys established during the handshake; the analyzer cannot read the plaintext without the session keys.

  • Structure: The alert contains two bytes—one showing the severity (warning or fatal) and another identifying the specific condition. [1, 2, 3]

Common Causes

  • Session Closure: Most frequently, it is a normal close_notify message indicating that one side is shutting down the session cleanly.

Please advise how we can move forward determining the reason why Milestone VMS is ending the webrtc stream.

Thanks for reporting this.

A few questions that may help narrow it down:

  • Does the stream stop consistently or only occasionally?
  • Have you seen this in multiple installations or only one?
  • Does it affect multiple cameras?
  • Does the behavior change with another browser or another PC?
  • Could you describe the use case and steps to reproduce?
  • Do the API Gateway logs show any warnings or errors when the stream disconnects?

If nothing stands out, please enable Debug logging for the API Gateway, reproduce the issue, and share the log entries around the time of the disconnect.

Instructions for enabling Debug logging are described here: Webrtc integration

Please let us know what you find.

This will happen consistently on our streams (I haven’t seen an exact pattern of “Stream for minutes”)

It’s across multiple deployments/cameras.

The reproduction steps are pretty straightforward, create a WebRtc stream with a camera and let it sit streaming.

I enabled debug logs, there isn’t too much to go off of :slightly_smiling_face:

2026-08-31 08:14:08.268-05:00 [ 38] DEBUG - Initiating session for deviceId: 09ae0c62-c559-461a-892e-0057f3bdd4ec
2026-08-31 08:14:10.017-05:00 [ 39] DEBUG - GatheringState sessionId: 8d08e9d4-5d00-4c9a-b42e-2f413448aa7a, gathering
2026-08-31 08:14:10.025-05:00 [ 39] DEBUG - OnServerIceCandidate sessionId: 8d08e9d4-5d00-4c9a-b42e-2f413448aa7a, 2522306478 1 udp 2113937663 192.168.6.228 63100 typ host generation 0
2026-08-31 08:14:10.221-05:00 [ 38] DEBUG - Session initiated for deviceId: 09ae0c62-c559-461a-892e-0057f3bdd4ec sessionId: 8d08e9d4-5d00-4c9a-b42e-2f413448aa7a streamId: (null)
2026-08-31 08:14:10.708-05:00 [ 38] DEBUG - Updating session for sessionId: 8d08e9d4-5d00-4c9a-b42e-2f413448aa7a - answerSDP: {“type”:“answer”,“sdp”:“v=0\no= 24986 0 IN IP4 0.0.0.0\ns=-\nt=0 0\na=group:BUNDLE 0 1\nm=video 9 UDP/TLS/RTP/SAVPF 101 102 103\nc=IN IP4 0.0.0.0\na=ice-ufrag:/2aijUZgubGrePblXf+p8Kt8XeYBATPn\na=ice-pwd:mZjFkxKFw7LRAuLs3pQElLVT1bMeUXrn\na=mid:0\na=rtcp-mux\na=setup:active\na=rtpmap:101 H264/90000\na=rtcp-fb:101 transport-cc\na=fmtp:101 packetization-mode=1;profile-level-id=42e01f;level-asymmetry-allowed=1\na=rtpmap:102 H264/90000\na=rtcp-fb:102 transport-cc\na=fmtp:102 packetization-mode=1;profile-level-id=42e034;level-asymmetry-allowed=1\na=rtpmap:103 H264/90000\na=rtcp-fb:103 transport-cc\na=fmtp:103 profile-level-id=42e01f\na=recvonly\na=fingerprint:sha-256 6F:DB:8A:C1:56:9F:CC:DF:D0:96:A4:3A:5D:D6:69:43:26:E5:75:4E:62:E1:6D:19:8F:7D:15:39:A7:F4:41:21\na=candidate:3 1 UDP 505413887 20937 typ relay raddr rport 21232\na=candidate:4 1 UDP 337658111 34979 typ relay raddr rport 9\na=end-of-candidates\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\nc=IN IP4 0.0.0.0\na=ice-ufrag:/2aijUZgubGrePblXf+p8Kt8XeYBATPn\na=ice-pwd:mZjFkxKFw7LRAuLs3pQElLVT1bMeUXrn\na=mid:1\na=setup:active\na=sctp-port:5000\na=fingerprint:sha-256 6F:DB:8A:C1:56:9F:CC:DF:D0:96:A4:3A:5D:D6:69:43:26:E5:75:4E:62:E1:6D:19:8F:7D:15:39:A7:F4:41:21\n”}, token supplied: False
2026-08-31 08:14:10.726-05:00 [ 38] DEBUG - IceConnectionStateChanged sessionId: 8d08e9d4-5d00-4c9a-b42e-2f413448aa7a, checking
2026-08-31 08:14:10.838-05:00 [ 39] DEBUG - IceConnectionStateChanged sessionId: 8d08e9d4-5d00-4c9a-b42e-2f413448aa7a, connected
2026-08-31 08:14:10.838-05:00 [ 39] DEBUG - ConnectionStateChange sessionId: 8d08e9d4-5d00-4c9a-b42e-2f413448aa7a, connecting
2026-08-31 08:14:10.954-05:00 [ 38] DEBUG - ConnectionStateChange sessionId: 8d08e9d4-5d00-4c9a-b42e-2f413448aa7a, connected
2026-08-31 08:52:47.040-05:00 [ 46] DEBUG - ConnectionStateChange sessionId: 8d08e9d4-5d00-4c9a-b42e-2f413448aa7a, closed
2026-08-31 08:52:47.040-05:00 [ 46] DEBUG - Video source stopped
2026-08-31 08:52:47.040-05:00 [ 46] DEBUG - Closing session: 8d08e9d4-5d00-4c9a-b42e-2f413448aa7a
2026-08-31 08:52:47.063-05:00 [ 46] DEBUG - Removed session: 8d08e9d4-5d00-4c9a-b42e-2f413448aa7a

If you test with the WebRTC - JavaScript client sample do you see the same issue?

At this point, the issue may be related to the network path between the WebRTC server and the client. Could you provide some information about the network topology?

  • Is there any NAT device between the server and the client?
  • Are there any firewalls, reverse proxies, load balancers, or VPNs involved?
  • Is the problem reproducible only from external networks, or also when the client is on the same LAN as the server?
  • Have you configured and tested a TURN server, or are you relying only on STUN/direct connectivity?
  • Do browser developer tools show any ICE connection failures or WebRTC-related errors in the console?

WebRTC is sensitive to NAT traversal and firewall restrictions, so understanding the network setup will help determine whether the encrypted stream warning is related to connectivity rather than the video stream itself.