Freeswitch 481 Response to BYE

[mrb11]

We are experiencing a common, yet problematic, SIP dialog flow between our Freeswitch (v1.10.10) and the Zoom SBC, which frequently results in hanging calls. We are seeking insights into why Freeswitch fails to terminate the session properly on the first attempt.

The Problematic Call Flow Scenario​

This is a scenario where we initiate the call (INVITE). The issue occurs during the session termination sequence initiated by Zoom.

Step	Initiator	Request/Response	Recipient	Observation / Issue
1	Zoom SBC	BYE	Freeswitch	Freeswitch responds with 481 (Call/Transaction Not Found). The call is now hanging.
2	Freeswitch	BYE	Zoom SBC	After session timeout, Freeswitch attempts to terminate the session.
3	Zoom SBC	481	Freeswich	Zoom responds with 481 (Call/Transaction Not Found) because they terminated teh session during the intial BYE.

Crucial Point: Freeswitch eventually sends its own BYE (Step 2), which implies it does still have the session in memory. We're confused about why it sends the 481 in Step 1 if the call record exists.

Debugging Observations​

• We have verified the Call-ID, From Tag, and To Tag on Zoom's initial BYE request (Step 1). They appear to be set up correctly and match the established dialog, suggesting Freeswitch should be able to locate the session.
• The only anomaly we've noted is that Zoom's initial BYE request (Step 1) arrives from an ephemeral port. We know, according to the SIP RFC, that this should not interfere with Freeswitch's dialog lookup process (which uses Call-ID, From/To Tags, and CSeq). wondering if this is related to any known Freeswitch/SBC-specific behavior or security/NAT logic.

Has anyone encountered this specific BYE -> 481 -> Timeout BYE -> 481 loop on Freeswitch?

Any information or ideas on why Freeswitch would send a 481 (Call/Transaction Not Found) when the dialog appears to be valid (and is later acted upon via the second BYE) would be greatly appreciated.

Thank you!

 

[Adrian Fretwell]

I have seen this happen where a SIP ALG or helper in the router/firewall corrupts the Call-ID. Some endpoints use their IP address as part of the Call-ID, if this IP address is an RFC1918 address many ALGs and "helpers" will try to fix it by replacing it with what it believes is the correct external IP address.

 

[mrb11]

Hi @Adrian Fretwell ,

Thanks for your response, the Call-ID for this leg does not have an IP as part of the Call-ID (for example 323807214_129097034@43.211.56.179). It is a standard UUID Call-ID.

We also do not use SIP ALG as our freeswitch routes traffic out of the AWS Internet Gateway and it receives traffic directly to it's network interface from external traffic. We have security groups enabled but I do not believe that has SIP ALG on it.

Can you think of anything else that can cause this issue?

Thanks

 

[Adrian Fretwell]

I was going to suggest raising this with the Singalwire Freeswitch Forum, but I see you have already done that.
https://support.signalwire.com/portal/en/community/topic/freeswitch-481-response-to-bye

I can't think of anything else to help right now, but I will post if I do have any ideas. If you resolve this please take the time to post your findings back here, it is an interesting issue.

 

[mrb11]

Will do @Adrian Fretwell, thank you for the feedback!