Reconnection Failure ([calling][0] fails)

R

random_nerd

New Member
Sep 30, 2025
9
0
1
48
Hey all, dealing with a pesky issue where agents lose connection for a brief moment (less than a second), we reestablish the connection, the call continues, but then drops around a minute later. I see numerous posts about calls ending after 32 seconds exactly, that's what this USED to be but now it seems to be around a minute and 10.

# Call established successfully
22:06:31.567937 [DEBUG] sofia.c:7493 Channel sofia/internal/1418a4d8-b021-70ee-47c6-edcacf5c5df7@fdis0kf10m29.invalid entering state [ready][200]
22:06:31.567937 [NOTICE] sofia.c:8681 Channel [sofia/internal/1418a4d8-b021-70ee-47c6-edcacf5c5df7@fdis0kf10m29.invalid] has been answered
22:06:31.567937 [DEBUG] switch_channel.c:3912 Callstate Change RINGING -> ACTIVE

# Agent re-registers after transport reconnect (this works)
22:06:35.627937 [WARNING] sofia_reg.c:1842 SIP auth challenge (REGISTER) on sofia profile 'internal' for [1418a4d8-b021-70ee-47c6-edcacf5c5df7@xxx] from ip x.x.x.x

# ~1 minute later, channel goes back to [calling] state - THIS IS THE PROBLEM
22:07:34.310192 [DEBUG] sofia.c:7493 Channel sofia/internal/1418a4d8-b021-70ee-47c6-edcacf5c5df7@fdis0kf10m29.invalid entering state [calling][0]

# 32 seconds later, call drops
22:08:06.308200 [DEBUG] sofia.c:7493 Channel sofia/internal/1418a4d8-b021-70ee-47c6-edcacf5c5df7@fdis0kf10m29.invalid entering state [terminating][408]
22:08:06.308200 [NOTICE] sofia.c:8736 Hangup sofia/internal/1418a4d8-b021-70ee-47c6-edcacf5c5df7@fdis0kf10m29.invalid [CS_EXCHANGE_MEDIA] [RECOVERY_ON_TIMER_EXPIRE]
22:08:06.347980 [DEBUG] mod_sofia.c:469 Channel sofia/internal/1418a4d8-b021-70ee-47c6-edcacf5c5df7@fdis0kf10m29.invalid hanging up, cause: RECOVERY_ON_TIMER_EXPIRE

Client side:
userAgent.transport.onDisconnect = async (error) => {
await userAgent.reconnect();
await registerer.register();
};


How can we properly maintain an active SIP dialog/session across a WebSocket transport reconnect in SIP.js? Or is there a FreeSWITCH-side configuration that can help with this scenario?

Thanks everyone!
 
You may be trying to fix the symptom instead of the Illness. I would be more concerned about why the agents lose the connection in the first place.
 
@Adrian Fretwell usually because their connection isn't perfectly stable. We run a virtual contact center so they are on home wifi rather than an in-office setting with dedicated lines. All connecting via sipjs.
 
OK, it is an interesting one, I will give it some more thought. One thing I am curious about is, as it is WebSocket transport, which I believe is a "sub protocol" of TCP, why are you seeing these brief disconnections, normally TCP would protect you from such transient errors. But as you point out, unknown WiFi is involved so maybe something a little more catastrophic is going on with the client.
It may be worth also asking the question in the Signalwire Freeswitch forum.
 
The 32 second thing is usually an indication that the SIP ACK was not getting correctly routed, using a tool like sngrep you will usually see repeated sending of the 200OK before the call drops. The ACK should be being sent to the address in the contact field of the 200OK, look and see if that is correct.
 
You must log in or register to reply here.
Top Bottom