Background
VoIPBin is a CPaaS (Communication Platform as a Service) that provides real-time call services built on top of Asterisk.
When an Asterisk instance unexpectedly crashes during an ongoing call, all SIP sessions on that instance disappear immediately. From the client’s perspective, the session is terminated without a BYE, causing issues such as:
- Interrupted TTS playback
- Unexpected conference exit
- Media channel failure
To address this, I implemented SIP session recovery, making it appear to the client as if the session is still active — even after the Asterisk process handling it has crashed.
Overview of the Recovery Process
After an Asterisk crash, VoIPBin performs a SIP session recovery using the following steps:

- Crash detection
VoIPBin’ssentinel-manager
detects that an Asterisk instance has crashed. - Session lookup from DB
We query our internal database for all call sessions that were being handled by the failed instance. - Collect recoverable SIP fields via HOMER
Using the HOMER API, we retrieve SIP header fields for each session:- From/To URI and Display
- Tags (From/To Tag), Call-ID, CSeq
- Route and Record-Route headers
- Request URI
- Create new SIP channel on another Asterisk
We select a healthy Asterisk instance and create new SIP channels to recover the affected sessions. - Set recovery-related channel variables
The following channel variables are set to ensure that the INVITE message reuses the original session’s identity: goCopyEditchannelVariableRecoveryFromDisplay = "PJSIP_RECOVERY_FROM_DISPLAY" channelVariableRecoveryFromURI = "PJSIP_RECOVERY_FROM_URI" channelVariableRecoveryFromTag = "PJSIP_RECOVERY_FROM_TAG" channelVariableRecoveryToDisplay = "PJSIP_RECOVERY_TO_DISPLAY" channelVariableRecoveryToURI = "PJSIP_RECOVERY_TO_URI" channelVariableRecoveryToTag = "PJSIP_RECOVERY_TO_TAG" channelVariableRecoveryCallID = "PJSIP_RECOVERY_CALL-ID" channelVariableRecoveryCSeq = "PJSIP_RECOVERY_CSEQ" channelVariableRecoveryRoutes = "PJSIP_RECOVERY_ROUTES" channelVariableRecoveryRecordRoutes = "PJSIP_RECOVERY_RECORD-ROUTES" channelVariableRecoveryRequestURI = "PJSIP_RECOVERY_REQUEST_URI"
- Send INVITE → client treats it as session continuation
Because the INVITE reuses the original Call-ID, tags, and headers, the client interprets it as a re-INVITE and resumes the session. - RTP and SIP session fully restored
Media flow and signaling are successfully re-established. The client resumes communication as if nothing happened. - Resume Flow execution
Once recovered, the call resumes its Flow execution from just before the crash.
For example, if the user was in a conference, they are reconnected to the same conference bridge; if TTS was being played, it resumes based on the Flow definition.

Asterisk Patch for Recovery
To support this functionality, I patched Asterisk’s PJSIP stack to allow overriding SIP header fields based on channel variables:
cCopyEditval_from_display_c_str = pbx_builtin_getvar_helper(session->channel, "PJSIP_RECOVERY_FROM_DISPLAY");
val_from_uri_c_str = pbx_builtin_getvar_helper(session->channel, "PJSIP_RECOVERY_FROM_URI");
val_from_tag_c_str = pbx_builtin_getvar_helper(session->channel, "PJSIP_RECOVERY_FROM_TAG");
val_to_display_c_str = pbx_builtin_getvar_helper(session->channel, "PJSIP_RECOVERY_TO_DISPLAY");
val_to_uri_c_str = pbx_builtin_getvar_helper(session->channel, "PJSIP_RECOVERY_TO_URI");
val_to_tag_c_str = pbx_builtin_getvar_helper(session->channel, "PJSIP_RECOVERY_TO_TAG");
// Call-ID, CSeq, Routes, and others are handled similarly
With this patch, a newly created SIP channel can impersonate the original one — making the recovery INVITE look like a legitimate continuation of the previous session.
Final Thoughts
SIP session recovery is a critical capability for handling unexpected Asterisk failures in production.
By combining fast crash detection with smart session restoration logic, VoIPBin ensures that users experience minimal service disruption.
I’m planning to expand this functionality to include:
- Broader support for mid-call state recovery
If you’re building real-time telephony platforms or CPaaS services, I hope this gives insight into how deep SIP session recovery can be handled — even in the face of infrastructure-level crashes.