PONG timeouts or How to gracefully reconnect with MCSubscriber

[patrickcusack]

I am encounterig the following Pong time outs across several devices (iPad, iOS, simulator) running the latest SDK. I didn't experience this when using the 2.x SDK. Can you explain what is 1) Going on here? Are these solely web socket timeouts? Can we increase the number of failed timeouts or change the web socket behavior? 2) How do I recover from this? I don't see this behavior on the web SDK or in the player. Basically I have to restart my connection every few minutes. I added a subscriber for web socket states. I never see failed. How do I work around this? These connections are on varied connections, wired and wifi - different networks.

2025/11/20 20:33:29.924721 [SDK|WARNING] [[websocket_task_queue_impl.cc:314](http://websocket_task_queue_impl.cc:314/)] 	Pong timeout
2025/11/20 20:33:32.296473 [SDK|DEBUG] [[state_machine.cc:45](http://state_machine.cc:45/)] 	ConnectionSM requesting state reconnecting
2025/11/20 20:33:32.296677 [SDK|DEBUG] [[state_machine.cc:238](http://state_machine.cc:238/)] 	ConnectionSM initiating transition from connected to reconnecting
2025/11/20 20:33:32.297457 [SDK|DEBUG] [[state_machine.cc:45](http://state_machine.cc:45/)] 	ConnectionSM requesting state connected
2025/11/20 20:33:32.297590 [SDK|INFO] [[state_machine.cc:287](http://state_machine.cc:287/)] 	ConnectionSM reached state reconnecting
2025/11/20 20:33:32.297688 [SDK|DEBUG] [[state_machine.cc:238](http://state_machine.cc:238/)] 	ConnectionSM initiating transition from reconnecting to disconnecting
WebSocket connected
WebSocket disconnecting
2025/11/20 20:33:32.798813 [SDK|DEBUG] [[state_machine.cc:287](http://state_machine.cc:287/)] 	ConnectionSM reached state disconnecting
2025/11/20 20:33:32.798998 [SDK|DEBUG] [[state_machine.cc:238](http://state_machine.cc:238/)] 	ConnectionSM initiating transition from disconnecting to idle
2025/11/20 20:33:32.799133 [SDK|DEBUG] [[state_machine.cc:45](http://state_machine.cc:45/)] 	ProjectionSM requesting state IDLE
2025/11/20 20:33:32.799213 [SDK|DEBUG] [[state_machine.cc:238](http://state_machine.cc:238/)] 	ProjectionSM initiating transition from PROJECTED to IDLE
2025/11/20 20:33:32.799282 [SDK|INFO] [[state_machine.cc:287](http://state_machine.cc:287/)] 	ProjectionSM reached state IDLE
2025/11/20 20:33:32.799364 [SDK|INFO] [[projection_state.cc:1213](http://projection_state.cc:1213/)] 	Enabling projection tracks masking for seamless migration after reconnection
2025/11/20 20:33:32.799454 [SDK|DEBUG] [[state_machine.cc:45](http://state_machine.cc:45/)] 	ProjectionSM requesting state IDLE
2025/11/20 20:33:32.799524 [SDK|DEBUG] [[state_machine.cc:401](http://state_machine.cc:401/)] 	ProjectionSM requested transition to IDLE completed
2025/11/20 20:33:32.799676 [SDK|DEBUG] [[projection_state.cc:488](http://projection_state.cc:488/)] 	Resetting peerconnection, invalidating all tracks projections
2025/11/20 20:33:32.828823 [SDK|INFO] TvosAudioDeviceModule::UpdateProcessing()
2025/11/20 20:33:32.830103 [SDK|WARNING] [[websocket_manager.cc:103](http://websocket_manager.cc:103/)] 	Websocket currently closed, dropping message!
2025/11/20 20:33:32.830188 [SDK|WARNING] [[transaction_manager.cc:44](http://transaction_manager.cc:44/)] 	Failed transaction 3, Operation cancelled: operation's solver abandoned before producing the result
2025/11/20 20:33:32.830276 [SDK|DEBUG] [[websocket_manager.cc:41](http://websocket_manager.cc:41/)] 	websocket manager preparing destruction!
2025/11/20 20:33:32.830336 [SDK|DEBUG] [[websocket_manager.cc:47](http://websocket_manager.cc:47/)] 	Websocket has been shutdown!
2025/11/20 20:33:32.830396 [SDK|DEBUG] [[projection_state.cc:506](http://projection_state.cc:506/)] 	Resetting RTS connection, invalidating all tracks activity states
2025/11/20 20:33:32.830457 [SDK|DEBUG] [[state_machine.cc:287](http://state_machine.cc:287/)] 	ConnectionSM reached state idle
2025/11/20 20:33:32.830540 [SDK|DEBUG] [[state_machine.cc:238](http://state_machine.cc:238/)] 	ConnectionSM initiating transition from idle to connecting
2025/11/20 20:33:32.830634 [SDK|DEBUG] [[state_machine.cc:287](http://state_machine.cc:287/)] 	ConnectionSM reached state connecting
2025/11/20 20:33:32.830694 [SDK|DEBUG] [[state_machine.cc:238](http://state_machine.cc:238/)] 	ConnectionSM initiating transition from connecting to connected
WebSocket idle
WebSocket connecting...
nw_endpoint_flow_add_one_protocol [C3.1.1.1 18.164.174.63:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en7)] Failed to create protocol handler: quic-connection
nw_endpoint_flow_failed_with_error [C3.1.1.1 18.164.174.63:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en7)] already failing, returning
nw_endpoint_flow_add_one_protocol [C3.1.1.2 18.164.174.129:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en7)] Failed to create protocol handler: quic-connection
nw_endpoint_flow_failed_with_error [C3.1.1.2 18.164.174.129:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en7)] already failing, returning
nw_endpoint_flow_add_one_protocol [C3.1.1.3 18.164.174.14:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en7)] Failed to create protocol handler: quic-connection
nw_endpoint_flow_failed_with_error [C3.1.1.3 18.164.174.14:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en7)] already failing, returning
nw_endpoint_flow_add_one_protocol [C3.1.1.4 18.164.174.20:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en7)] Failed to create protocol handler: quic-connection
nw_endpoint_flow_failed_with_error [C3.1.1.4 18.164.174.20:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en7)] already failing, returning
2025/11/20 20:33:33.059337 [SDK|ERROR] [millicast_client.cpp:590] 	Unauthorized(401): Http Error: Unauthorized(401)
2025/11/20 20:33:33.059489 [SDK|INFO] [millicast_client.cpp:591] 	[Sub][Fail] Connection failed, trying to reconnect if allowed in config...
2025/11/20 20:33:33.059559 [SDK|DEBUG] [millicast_client.cpp:538] 	Reconnects disabled, disconnecting on error
2025/11/20 20:33:33.059623 [SDK|DEBUG] [[state_machine.cc:45](http://state_machine.cc:45/)] 	ConnectionSM requesting state idle
2025/11/20 20:33:33.059731 [SDK|WARNING] [[state_machine.cc:312](http://state_machine.cc:312/)] 	ConnectionSM failed to reach state connected. The state stays in connecting and the transition to connected is aborted: Unauthorized(401): Http Error: Unauthorized(401): Error: REST API error response
2025/11/20 20:33:33.059845 [SDK|DEBUG] [[state_machine.cc:238](http://state_machine.cc:238/)] 	ConnectionSM initiating transition from connecting to disconnecting
2025/11/20 20:33:33.059997 [SDK|DEBUG] [[state_machine.cc:287](http://state_machine.cc:287/)] 	ConnectionSM reached state disconnecting
2025/11/20 20:33:33.060075 [SDK|DEBUG] [[state_machine.cc:238](http://state_machine.cc:238/)] 	ConnectionSM initiating transition from disconnecting to idle
2025/11/20 20:33:33.060176 [SDK|INFO] [[state_machine.cc:287](http://state_machine.cc:287/)] 	ConnectionSM reached state idle
WebSocket idle

[FabienLavocat]

Hi @patrickcusack,

From this log you share I can see that you are not being authorized to connect to the stream you're trying to connect to.

2025/11/20 20:33:33.059337 [SDK|ERROR] [millicast_client.cpp:590] 	Unauthorized(401): Http Error: Unauthorized(401)
[...]
2025/11/20 20:33:33.059731 [SDK|WARNING] [[state_machine.cc:312](http://state_machine.cc:312/)] 	ConnectionSM failed to reach state connected. The state stays in connecting and the transition to connected is aborted: Unauthorized(401): Http Error: Unauthorized(401): Error: REST API error response

[patrickcusack]

Correct. What happens is that I grab a token from the backend that exists for 10 seconds. After I successfully connect, I can view content for 5-10 minutes before I see the web socket PONG timeouts.

2025/11/20 20:33:29.924721 [SDK|WARNING] [[websocket_task_queue_impl.cc:314](http://websocket_task_queue_impl.cc:314/)] Pong timeout

This begins the eventual failure of the connection. I didn't encounter this previously with 2.X. 1) Are these timeouts normal 2) how do I gracefully reconnect? Specifically what signal do I look for to begin the reconnection process. These timeouts do not see normal.

[patrickcusack]

I created a 12 hour token, connected with that and maintained connectivity through the PONG timeout. See below. In this particular case, I can create a long lived token, but I would like to understand what is going on with the web socket tearing down.

2025/11/20 23:36:46.096783 [SDK|WARNING] [websocket_task_queue_impl.cc:314] Pong timeout
2025/11/20 23:36:46.340029 [SDK|DEBUG] [state_machine.cc:45] ConnectionSM requesting state reconnecting
2025/11/20 23:36:46.340083 [SDK|DEBUG] [state_machine.cc:238] ConnectionSM initiating transition from connected to reconnecting
2025/11/20 23:36:46.340396 [SDK|DEBUG] [state_machine.cc:45] ConnectionSM requesting state connected
2025/11/20 23:36:46.340422 [SDK|INFO] [state_machine.cc:287] ConnectionSM reached state reconnecting
2025/11/20 23:36:46.340459 [SDK|DEBUG] [state_machine.cc:238] ConnectionSM initiating transition from reconnecting to disconnecting
WebSocket connected
WebSocket disconnecting
2025/11/20 23:36:46.841593 [SDK|DEBUG] [state_machine.cc:287] ConnectionSM reached state disconnecting
2025/11/20 23:36:46.841671 [SDK|DEBUG] [state_machine.cc:238] ConnectionSM initiating transition from disconnecting to idle
2025/11/20 23:36:46.841775 [SDK|DEBUG] [state_machine.cc:45] ProjectionSM requesting state IDLE
2025/11/20 23:36:46.841816 [SDK|DEBUG] [state_machine.cc:238] ProjectionSM initiating transition from PROJECTED to IDLE
2025/11/20 23:36:46.841849 [SDK|INFO] [state_machine.cc:287] ProjectionSM reached state IDLE
2025/11/20 23:36:46.841940 [SDK|INFO] [projection_state.cc:1213] Enabling projection tracks masking for seamless migration after reconnection
2025/11/20 23:36:46.842000 [SDK|DEBUG] [state_machine.cc:45] ProjectionSM requesting state IDLE
2025/11/20 23:36:46.842050 [SDK|DEBUG] [state_machine.cc:401] ProjectionSM requested transition to IDLE completed
2025/11/20 23:36:46.842089 [SDK|DEBUG] [projection_state.cc:488] Resetting peerconnection, invalidating all tracks projections
2025/11/20 23:36:46.868300 [SDK|INFO] TvosAudioDeviceModule::UpdateProcessing()
2025/11/20 23:36:46.870352 [SDK|WARNING] [websocket_manager.cc:103] Websocket currently closed, dropping message!
2025/11/20 23:36:46.870408 [SDK|WARNING] [transaction_manager.cc:44] Failed transaction 3, Operation cancelled: operation's solver abandoned before producing the result
2025/11/20 23:36:46.870454 [SDK|DEBUG] [websocket_manager.cc:41] websocket manager preparing destruction!
2025/11/20 23:36:46.870481 [SDK|DEBUG] [websocket_manager.cc:47] Websocket has been shutdown!
2025/11/20 23:36:46.870522 [SDK|DEBUG] [projection_state.cc:506] Resetting RTS connection, invalidating all tracks activity states
2025/11/20 23:36:46.870552 [SDK|DEBUG] [state_machine.cc:287] ConnectionSM reached state idle
2025/11/20 23:36:46.870580 [SDK|DEBUG] [state_machine.cc:238] ConnectionSM initiating transition from idle to connecting
2025/11/20 23:36:46.870657 [SDK|DEBUG] [state_machine.cc:287] ConnectionSM reached state connecting
2025/11/20 23:36:46.870687 [SDK|DEBUG] [state_machine.cc:238] ConnectionSM initiating transition from connecting to connected
WebSocket idle
WebSocket connecting...
2025/11/20 23:36:47.164957 [SDK|INFO] [millicast_client.cpp:484] Adding stun/turn server
2025/11/20 23:36:47.165013 [SDK|INFO] [millicast_client.cpp:484] Adding stun/turn server
2025/11/20 23:36:47.165036 [SDK|INFO] [millicast_client.cpp:484] Adding stun/turn server
2025/11/20 23:36:47.165597 [SDK|DEBUG] [websocket_task_queue_impl.cc:280] Connecting to wss://live-phx-1.millicast.com/ws/v2/sub/b8fb2bf6f8c24c409e0bb9a010dd65e7?token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
2025/11/20 23:36:47.350074 [SDK|INFO] [millicast_client.cpp:899] [WS][Opened] WebSocket opened
2025/11/20 23:36:47.350197 [SDK|INFO] [state_machine.cc:287] ConnectionSM reached state connected
WebSocket connected
2025/11/20 23:36:47.351597 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: H264, parameters: { level-asymmetry-allowed=1 packetization-mode=1 profile-level-id=640c34 }
2025/11/20 23:36:47.351693 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: H264, parameters: { level-asymmetry-allowed=1 packetization-mode=1 profile-level-id=42e034 }
2025/11/20 23:36:47.351761 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: VP8, parameters: { }
2025/11/20 23:36:47.351828 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: VP9, parameters: { }
2025/11/20 23:36:47.351900 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: AV1, parameters: { }
2025/11/20 23:36:47.351971 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: H265, parameters: { }
2025/11/20 23:36:47.354457 [SDK|INFO] [peerconnection.cpp:101] [renegociation] pc.createOffer() | Success
2025/11/20 23:36:47.356219 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: H264, parameters: { level-asymmetry-allowed=1 packetization-mode=1 profile-level-id=640c34 }
2025/11/20 23:36:47.356272 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: H264, parameters: { level-asymmetry-allowed=1 packetization-mode=1 profile-level-id=42e034 }
2025/11/20 23:36:47.356301 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: VP8, parameters: { }
2025/11/20 23:36:47.356331 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: VP9, parameters: { }
2025/11/20 23:36:47.356358 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: AV1, parameters: { }
2025/11/20 23:36:47.356387 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: H265, parameters: { }
2025/11/20 23:36:47.356556 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: H264, parameters: { level-asymmetry-allowed=1 packetization-mode=1 profile-level-id=640c34 }
2025/11/20 23:36:47.356590 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: H264, parameters: { level-asymmetry-allowed=1 packetization-mode=1 profile-level-id=42e034 }
2025/11/20 23:36:47.356631 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: VP8, parameters: { }
2025/11/20 23:36:47.356660 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: VP9, parameters: { }
2025/11/20 23:36:47.356690 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: AV1, parameters: { }
2025/11/20 23:36:47.356720 [SDK|DEBUG] [video_decoder_factory.cc:24] SupportedFormat: Codec name: H265, parameters: { }
2025/11/20 23:36:47.357632 [SDK|INFO] [peerconnection.cpp:116] [renegociation] pc.setLocalDescription() | sucess
2025/11/20 23:36:47.357872 [SDK|INFO] [viewer_impl.cpp:50] Sending viewer SDP:
v=0

[Yousif-CS]

Hey @patrickcusack, so it seems like you are using self signed subscriber tokens when communicating with the director. I see two things here:

1. The PONG timeout happening in the Websocket could be to a multitude of reasons, could be related to network and it is hard to tell without more context. Maybe there is a proxy/vpn issue going on? You mentioned "it maintained connectivity" through the PONG timeout, could you clarify what that means? Does it mean the SDK did not tear down the connection and attempt to reconnect again? Was the media playback working fine while this happened?

2. The SDK flow when the pong timeout did occur, when auto reconnection is enabled, is to retry the director subscribe call from the beginning, and at that point the SDK internally used the token you provided in the beginning, which at the point of network dropout already expired, and thus indicates why you see the 401 error occur. Here, since the SDK received a 401, will not re-attempt to connect again. Here, the app should have a listener for the http connection errors that occur, that invokes the subscriber connect method again after setting new credentials with a newly generated subscriber token.

[patrickcusack]

"it maintained connectivity" refers to the fact that the web socket does properly reconnects with a long lived valid token.
Previously with the 1.3.1 SDK, I never encountered issues with a web socket timeout. I used very small timed tokens. I could run my tvOS app for days and not see any issues. Did the web socket behavior change? I guess we can close this as I can use a long-lived token (and reconnect logic will work as well). But last question is this: does a PONG timeout necessarily imply that the UDP data is not properly flowing to the client?

[Yousif-CS]

Hey @patrickcusack thanks for the quick reply. So yes then my understanding is correct. The reason why the long lived tokens worked is because the when the automatic reconnection occured in the SDK after the pong timeout, the director call succeeded and we managed to re-establish the connection correctly.

Why the pong times out is the more interesting question here. A lot of things have changed between the 1.3.1 SDK and 2.5 SDK, including a refactor of the websocket connection establishment. As far as I remember, there was no ping/pong logic there, and it was introduced to be able to detect network dropouts. Before, the network could dropout completely, and only after 30 seconds we would get the connection teardown callback from the socket. However, now the timeout is 4 seconds, so if we don't receive a pong in that period, the connection is considered out, and a reconnect is kicked off.

Is there any more details you can provide that could help narrow this down? For example, is media playback fine around the time you get a pong timeout? Are you running behind a proxy? how stable is the network connection you are running from?

As far as using long lived tokens/short lived tokens, shouldn't affect it, and you can infact just implement the token regeneration to occur in

      let task =  Task { 
            for await error in subscriber.httpError() {
               if error.code == 401 { 
                  // regenerate token and kick off new subscriber connection
               }
            }
      }

[patrickcusack]

I will run a session tomorrow and provide further feedback. I encountered this PONG timeout on a two different networks, a network we manage and another that is managed by another group, both with a combination of wired and wifi connections.