Bye from peer not getting to fusionpbx

jeremiec73

New Member
Mar 23, 2026
1
0
1
51
Hello,



We are experiencing an issue with calls not clearing properly on FusionPBX (FreeSWITCH) when the upstream SBC (Sipwise MR14) fails to correctly handle or forward a BYE.





Environment​





  • FusionPBX (FreeSWITCH backend)
  • External SIP trunk to Sipwise NGCP MR14
  • Calls bridged via:

    sofia/internal → sofia/gateway → external carrier






Observed Behavior​





In certain cases, the upstream carrier sends a BYE to Sipwise, but:



  1. Sipwise does NOT respond with 200 OK to the BYE
  2. Sipwise does NOT forward the BYE to FreeSWITCH
  3. FreeSWITCH never receives a BYE on the B-leg
  4. The call remains ACTIVE indefinitely on FusionPBX




Later:



  • Sipwise sends a delayed BYE
  • FreeSWITCH responds with 481 Unknown Dialog
  • Call state becomes inconsistent or remains stuck






Packet Flow Summary​





  • Carrier → Sipwise: BYE (multiple retransmits)
  • Sipwise → Carrier: 408 Request Timeout (instead of 200 OK)
  • Sipwise → FusionPBX: delayed BYE
  • FusionPBX → Sipwise: 481 Unknown Dialog






Result​





  • Call remains active on FreeSWITCH even though the far end has hung up
  • RTP may still be flowing, so RTP timeout does not trigger
  • Session timers do not reliably clean up the call






What We Have Tried​





  • rtp_timeout_sec
  • sip_require_timer=false
  • Exporting variables to B-leg (nolocal)
  • Manual hangup logic in dialplan




These do not consistently resolve the issue because:



  • RTP may still be present
  • FreeSWITCH never receives proper signaling to terminate the call






Question / Request​





Is there a recommended way in FreeSWITCH / FusionPBX to:



  1. Detect a missing or failed BYE transaction on the B-leg
  2. Force call teardown when:


    • BYE is not acknowledged upstream
    • Dialog state becomes inconsistent
  3. Automatically clear channels when receiving a late BYE that results in 481 Unknown Dialog




Specifically:



  • Is there a Sofia profile setting, timer, or watchdog mechanism to prevent channels from remaining active indefinitely in this scenario?
  • Is there a way to enforce dialog cleanup when upstream B2BUA behavior is non-compliant?






Goal​





We are looking for a robust way to ensure calls are always torn down cleanly on FreeSWITCH, even when upstream SIP entities mishandle BYE transactions.



Any guidance or recommended configuration would be greatly appreciated.



Thank you.

:::
 
A very blunt tool for outbound calls would be to add something like this to the dialplan, this would hang the call up after an hour, apart from this I cannot think of a way if rtp timeout is not working for you:

Code:
execute_on_answer=sched_hangup +3600