I have an Asterisk 11.2 cert 2 system, when I forward calls, the outbound callerid is going out as the number that calls have been forwarded to. I have tried setting the callerid in the dialplan for this and I am not having any luck. I’m guessing the my VoIP provider is ONLY expecting to see our DIDs and only allows those to establish outbound calls. Which is what their engineer said was happening based on a trace we did. My sales guys are having a fit because they can’t forward their calls. Please help with any ideas.
Most responsible ITSP will not forward caller ID unless you have proved to them that it is a number that you control.
No responsible ITSP will do so unless they tag it as “failed screen” (or for less responsible ones, unscreened), which may cause downstream systems to suppress it.
It should never be able to get “passed screen” status on your customers, as you will not be a able to prove you control the number, as you do not.
(To get network provided status, a responsible network operator will require that you are another network operator.)
I would suggest either finding a dodgy ITSP or announcing the number, in band, when the call is answered.
Finding a “dodgy ITSP” is definitely NOT what I’m looking to do. I have a good provider in Verizon Business. What I’m looking to do is figure out how to set the callerid to one of my DIDs. We use Cisco phones and utilize the CFwdAll button on those phones for forwarding. I’ve tried multiple ways of setting the caller id to one of my DIDs and just cant’s seem to get it to work. Any thoughts?
As suggested, send it in band once the call has been answered.
Okay. I’m fairly new to Asterisk, so how is this accomplished?
Nothing you can do on Asterisk will get round a refusal to pass unscreened numbers.
Whether you can set caller ID on transfers depends on exactly how the transfer is initiated, e.g. true SIP attended transfers are done as an enquiry that is indistinguishable from an independent call on a second line, although you could set global variables and use dialplan logic to infer that it was really the start of an attended transfer.
Other variations are features.conf transfers, real SIP blind transfers, and SIP blind transfers implemented as attended ones.
The odd thing is when our service was using a PRI and not voip this wasn’t an issue, but I’m assuming that’s the nature of voip.
The screening categories come from PRI signalling. Maybe your PRI operator was more lax, or maybe they were actually setting “failed screen” and the downstream systems didn’t care.
VoIP is particularly vulnerable to faked CLID, which is one reason junk phone callers like it. As a result, maybe good operators check it properly. It is also possible that your operator doesn’t want the hassle of screening your numbers, so simply overwrites them with a “network provided” one.