Asterisk to 3CX SIP Trunk: Routing Caller Lookup Results
Yes, you can run the caller lookup in Asterisk and pass each call to 3CX over an Asterisk to 3CX SIP trunk. The simplest design uses one 3CX destination per outcome, such as a queue DID or extension. Passing a value in a SIP header is possible, but check that 3CX can route on it.
Can you use an Asterisk to 3CX SIP trunk for caller lookup?
Yes. With an Asterisk to 3CX SIP trunk, Asterisk can receive the inbound call, run the AGI, then dial the 3CX system. This is a common way to keep existing routing logic while evaluating a new platform.
The trunk is configured on both sides: Asterisk sees 3CX as a peer, and 3CX sees Asterisk as a SIP trunk or provider-style connection. Check the 3CX documentation for the supported trunk types and how it matches inbound calls from a trunk.
The main design choice is how Asterisk tells 3CX where the call should go. There are two approaches: one distinct destination per lookup result, or a single entry point with a value that 3CX uses for routing.
Option 1: How do I send each lookup result to its own 3CX destination?
The AGI returns a result such as known customer in group A, known customer in group B, or unknown. The dialplan maps each result to a different dialled number, and Asterisk sends the call to 3CX using that number. In 3CX, the number is routed to the matching queue or to the receptionist.
This is the lowest-risk choice. It uses only standard call routing, with no dependence on custom headers. It is easy to test by dialling each destination by hand.
The downside is that adding a new queue means changing both systems, and the number of destinations grows with the number of routes.
Confirm in the 3CX documentation how inbound calls from a trunk are matched to a destination. Matching is typically based on the dialled number, so check the exact field it uses.
Option 2: Can 3CX route on a value passed from Asterisk?
Asterisk can add a custom SIP header or alter the dialled number or caller ID fields. Whether 3CX can read a custom header and use it in routing rules is something to verify in its documentation or with the vendor.
Do not assume it can. If it cannot, the header is ignored and every call lands in the same place.
Reusing the caller ID or dialled number field to carry a code is fragile. It can break call displays, reports, and any rule that depends on the real caller number.
If the original ANI must be preserved for screen pops or call logs, keep it intact and carry the routing decision in the dialled number instead.
For a small office, Option 1 is usually enough. Consider Option 2 only if the number of destinations becomes unmanageable and the vendor confirms header-based routing.
Where should the lookup run, and what usually goes wrong?
While evaluating, leave the lookup in Asterisk. It already works, and moving it would defeat the purpose of the trial.
Later options include 3CX's own routing or integration features, or a lookup service that 3CX calls. Check the documentation for what the chosen version supports before committing.
Likely problem areas on the trunk, roughly in order of probability:
- Trunk authentication or IP matching fails, so 3CX rejects the call. Check the SIP logs on both sides.
- The dialled number sent by Asterisk does not match any 3CX route. Compare the exact digits and any prefix or format differences.
- Codec or media mismatch causes one-way or no audio. Align the codecs and check NAT and RTP settings.
- The caller ID is rewritten or dropped, so 3CX shows the wrong number. Check the From and identity headers.
- The AGI is slow or fails, and the call stalls. Add a timeout and a default route to the receptionist so an error never drops the call.
- Call loops or double routing happen when 3CX sends calls back to Asterisk. Keep the call direction clear.
How should I test, and when should I get help?
Test each outcome over the Asterisk to 3CX SIP trunk with a test number before moving real traffic: a known customer, an unknown caller, a database failure, and a busy queue. Keep a fallback that sends all calls straight to the receptionist.
Get a telephony professional or the vendor involved if you need header-based routing, if carrier-facing SIP is changing, or if emergency calling is affected by the new path.
Confirm emergency call handling in particular before any production cutover.
Common questions
Should I pass the customer lookup result to 3CX as a SIP header?
Only if the 3CX documentation or vendor confirms it can route on that header. Otherwise, use a separate dialled destination for each result.
What happens if the database is down?
The AGI should time out and the dialplan should send the call to a default destination, usually the receptionist. Test this case deliberately.
Will the original caller number reach 3CX?
It can, if Asterisk passes the caller ID through unchanged. Verify it in the SIP trace and in 3CX call logs.
Where should the caller lookup run while I evaluate 3CX?
Leave it in Asterisk, since it already works and moving it would defeat the purpose of the trial. Check the documentation before moving it to 3CX routing, an integration, or a lookup service.