How Do I Pass Information Between Steps of a FreeSWITCH Call?
Use channel variables, custom variables, exported values and SIP headers to carry customer, routing and CRM context through a FreeSWITCH call flow.
FreeSWITCH learning series · Part 17 of 30
Use channel variables, custom variables, exported values and SIP headers to carry customer, routing and CRM context through a FreeSWITCH call flow.
What this question really means in a working FreeSWITCH system
Channel variables are the glue between call stages, but scope matters. Some values belong only to the current leg, some need to be exported to a B-leg, and SIP headers may represent network input rather than trusted application state. For CRM integration, define which identifiers are authoritative—call UUID, customer ID, campaign ID—and avoid letting arbitrary inbound headers become business permissions.
Start with the mental model
A channel variable is the call’s working memory. It can carry caller identity, normalized destination, customer ID, routing choices, recording paths and provider metadata across actions and into a newly created B-leg when exported correctly.
| Value | Why carry it | Safety note |
|---|---|---|
| Normalized destination | Consistent routing/reporting | Log sanitized form |
| CRM customer ID | Join call to business record | Avoid unnecessary personal data |
| Campaign ID | Attribution and controls | Validate campaign state elsewhere |
| Provider route | Selected outbound path | Do not let untrusted header choose it |
| Recording path | Locate media artifact | Protect access/retention |
Work through it from zero
Some variables come from FreeSWITCH/Sofia, some from the dialplan, some from API/ESL and some from SIP headers.
Prefer namespaced/custom variable names that do not collide with built-in variables.
A variable set on one channel does not automatically exist on another; export or leg-specific syntax intentionally.
Inbound headers are external input. Validate before using them as authorization or routing truth.
A CRM customer ID is useful correlation; credentials and raw personal data do not belong in casual logs.
What beginners usually confuse
- Assuming every variable propagates to the B-leg.
- Trusting caller-supplied SIP headers as internal metadata.
- Logging full customer payloads for convenience.
How to know you are actually finished
- Document the few variables that form your application contract.
- Use consistent naming and data types.
- Correlate call UUIDs with application IDs for observability.
How to use this in a real implementation
For this FreeSWITCH task, use a bounded test built around this objective: use channel variables, custom variables, exported values and sip headers to carry customer, routing and crm cont…. Observe one state change at a time, save the evidence, and only then move to the next layer.
- Capture the exact runtime evidence related to Know where the value originates before changing the next layer.
- Keep a known-good test number/endpoint and repeat the same call after each configuration change.
- Record SIP response codes, context/destination decisions and media observations separately; they answer different questions.
- If you cannot explain which file/module owns the behavior, stop and locate that ownership before editing more configuration.
Continue from here
After this article: use the next link that matches the unresolved part of use channel variables, custom variables, exported values and sip headers to carry customer, routing and crm cont…. Start the FreeSWITCH learning series · Use the SIP → dialplan → RTP troubleshooting ladder · Continue into real-time AI media streaming
Questions a careful reader usually asks next
Should I change several FreeSWITCH files at once?
Not while learning or troubleshooting. Prove know where the value originates first, then change one layer and repeat the same test so you know what caused the new behavior.
Is a successful CLI command enough proof?
No. For use channel variables, custom variables, exported values and sip headers to carry customer, routing and crm cont…, confirm the live SIP, dialplan or media behavior that the command was intended to affect. A parser or CLI success only proves the command was accepted, not that the call path now behaves correctly.
Where should business logic live?
For use channel variables, custom variables, exported values and sip headers to carry customer, routing and crm cont…, keep low-level signaling/media truth in FreeSWITCH, while customer, campaign and business state stays in the application layer unless the telephony engine genuinely needs it for call execution.
References and further reading
Protocol and configuration facts for How Do I Pass Information Between Steps Of A FreeSWITCH Call are grounded in the current FreeSWITCH Users Manual and, where Asterisk is compared, Asterisk's official documentation. Community tutorials are included only as credited learning aids.
- FreeSWITCH Users Manual — authoritative project documentation for the FreeSWITCH behavior/configuration referenced above.
- FreeSWITCH Getting Started — authoritative project documentation for the FreeSWITCH behavior/configuration referenced above.
- FreeSWITCH — CLI and API command reference — additional primary/official reference for context and verification.
Want to see API-driven CRM + Telecom workflows in action? Try the WhatsApp bot or explore the demos.
Comments (0)
Be the first to comment.