Freeswitch 481 Response to BYE

Freeswitch 481 Response to BYE

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.

StepInitiatorRequest/ResponseRecipientObservation / Issue
1Zoom SBC
BYE
FreeswitchFreeswitch responds with 481 (Call/Transaction Not Found). The call is now hanging.
2FreeswitchBYEZoom SBCAfter session timeout, Freeswitch attempts to terminate the session.
3Zoom SBC481FreeswichZoom 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.

Request for Insight​

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!