My FreePBX 2.11.0.43 machine has two SIP trunks. One comes in from my SIP provider, and another connects to another Asterisk based PBX not under my control.
When a call arrives from the inbound SIP trunk (originally, from PSTN) the CallerID works correctly if we take the call into a queue or answer it at an extension.
When the call is sent to the next PBX via SIP trunk, the CallerID information is overwritten with my main DID. I suspect this is a configuration error that I’ve made in setting up the trunk.
Any suggestions as to what I might have done wrong, to cause the CallerID to be overwritten? I’ve left the “Outbound CallerID” of this particular trunk blank, and CID Options are “Allow Any CID”
… and if @dicko 's suggestion doesn’t do it all, try looking at “Set Caller ID” and see if that addition helps. I suspect setting the Intra-company route will be enough.
I would consider that, yes; but what implication does that have on the configuration? Is “intra-company” a valid context? The documentation doesn’t have a list of what’s valid or not.
It doesn’t seem to be a valid context because “intra-company” doesn’t appear in any files within /etc/asterisk.
Please clarify your statements as to exactly what configuration changes you’re suggesting.
It’s there complete with pop up help on the route you used’s page.
It’s also explained in the wiki, it’s always a good idea to read that through a couple of times .
It’s there complete with pop up help on the route you used’s page.
It’s also explained in the wiki, it’s always a good idea to read that through a couple of times
I’m sorry, could you provide some links? Because I have no clue what you are talking about. I was NOT able to find the information after quite a bit of searching.
I’m looking on the trunk configuration page, and finding nothing of the sort. Am I looking in the wrong place? What is the exact name of the parameter?
I think you’re making some assumptions that aren’t correct; please explain your answer more thoroughly. For example you may think I’m looking at some screen or configuration item, when I’m looking at something completely different (and wrong).
Moral of the story: Don’t expect somebody to know how to use a clutch if you’re teaching them how to use a manual transmission!
To clarify:
There is an IVR, with a destination type TRUNK which is my SIP TRUNK.
When I call in to the system, then dial this IVR option my call is successfully connected to the other end of the trunk, but the CallerID is that of my main number; not the CallerID of the inbound call.
For an IVR, one way might be to construct a custom-destination/custom-context to dial something that was recognized and passed by an outbound route that set ${INTRACOMPANYROUTE}
A different Moral Of The Story:
A guy is floating along in a balloon one foggy day. He floats down and asks a passer-by
“Where am I?”
The passer-by says “In a balloon.”
The guy in the balloon gets angry at the guy on the ground.
“That’s a horrible answer. Why did you expect that to be helpful?”
The guy on the ground looks up and says “It’s a perfectly correct answer. The fact that it doesn’t help you isn’t my fault.”
Your first post said you were receiving the call on a queue, and now you say that you’re connecting via an IVR. Which is it, because the answers make a difference.
Another Moral of the Story: Don’t tell people you want to learn how to drive a car with an automatic if you have a standard transmission.
Once your first PBX has answered the call and processed it, it is no longer an incoming call - it’s a call from your IVR. Using the trunk as an IVR destination is not one of the myriad ways that I would have set this up - I’m not actually sure that it should ever work. I agree with @dicko on this one - if you want to do this the way you are describing, I recommend writing a custom context to set up the call and route it through the trunk that way.
My statement was IF it goes to a queue, CallerID works correctly - a diagnostic step to indicate that CallerID is being received correctly from the SIP provider.
The OP then goes on to state:
Yes, I should have specified how the call was being “sent”. My test case is an IVR entry in which I’ve selected “Trunk” as the destination, then selected the SIP trunk to the other PBX.
Thank you, that’s very helpful. I had not thought of it in that context.
It works in the sense that the call arrives where I want it to, but it’s not having the desired effect; and certainly may not be the “correct” way of accomplishing the task. I’m certainly open to doing it differently - hence my original statement of “I think I’ve configured something the wrong way”.
I’ll see if I can figure out how to do that.
What would @cynjut or @dicko recommend as the best solution to this problem?
The goal I’m trying to accomplish is that if all of my queue agents are busy or unavailable, the call is sent to another call center via this trunk, maintaining the original callers’ CallerID helps the receiving agent at the next call center know who the caller is.
One solution might be to create a custom-extension, perhaps 888,that dials
local/888${EXTEN}@outbound-allroutes
and an outbound intra-company route that matches 888nxxnxxxxx (or whatever), strips off the prefix 888 and sends it to your tie-line trunk. the queue failover when all agents are busy would go to that extension.
the choice of 888 in both contexts is arbitrary , jut for consistency between prefix and the extension that prefixes.
I’ve created a custom extension 950. Should ${EXTEN} actually go in the dial rule for the custom extension, or should I be substituting something?
Is outbound-allroutes a specific keyword in this context, or should I be specifying the name of an existing outbound route?
I’m not sure that I understand correctly.
Inferring from context, I think that local/888${EXTEN}@outbound-allroutes should have “outbound-allroutes” replaced with the name of an actual route that exists.
So I’ve created a custom extension 950, set it to dial local/950${EXTEN}@outbound-tietrunk
I’ve created a new outbound route, named outbound-tietrunk. The trunk sequence for Matched Routes is set to my tie trunk, and checkmarked “Intra-Company”.
In the dial patterns, I’ve set “950” in the “prefix” field, and “NXXNXXXXXX” in the match pattern (I have no clue if this is correct - you said “or whatever” above, but I don’t know what the “or whatever” means).
However, when I try to dial it; I get a fast busy/congestion and the log entry is:
[2016-03-24 12:52:41] VERBOSE[13627][C-0007a327] pbx.c: – Executing [s@macro-dial-one:43] Dial(“SIP/sip-inbound-00015131”, “local/950${EXTEN}@outbound-tieline,Ttr”) in new stack
[2016-03-24 12:52:41] NOTICE[13627][C-0007a327] chan_local.c: No such extension/context 950${EXTEN}@outbound-tielinewhile calling Local channel
[2016-03-24 12:52:41] VERBOSE[13627][C-0007a327] app_dial.c: – Couldn’t call local/950${EXTEN}@outbound-tieline
Clearly, I haven’t understood correctly; and have not configured this correctly. Suggestions?
As I said I hadn’t tried it, but you should yourself read my post “more thoroughly”, the outbound-allroutes will filter the call through your outbound routes, including the from-internal tie line, your assumption as to why , not so much. The rest is just logic to restore the original caller over that trunk, and no the custom extension won’t replace the ${EXTEN} you will need a custom-context to add that variable appropriately, I kinda blew that
Thank you for helping through my ignorance on the subject, which of course I freely admit. I worked with a consultant to build a configuration that works:
In /etc/asterisk/extensions_custom.conf
exten => 1001,1,Dial(SIP/TrunkName/1000,30,o)
Where SIP/TrunkName/1000 is the trunk name as configured in Applications/Trunks in the FreePBX GUI. The /1000 is because they asked us to send calls to extension 1000 on the trunk, so that’s application specific. For most implementations, I assume simply SIP/TrunkName would be sufficient. The magic sauce is the “o” on the options, which ends up shuttling the callers’ CallerID to the other end.
The next step was in Applications/Misc Destinations to add a destination which a “Dial” value of “1001” (the extension number in the custom configuration above). Then that destination can be used from any GUI menu by selecting that specific “Misc Destination”.
This configuration has been tested to work in our environment, YMMV.
.