I’m not very familiar with Asterisk coding and most things we use for our PBX is simply done via the GUI.
We have now come across an issue where a cellular provider no longer allows diverted calls if the diversion header is not in the correct format.
The diversion header that is being sent from my PBX is as follows (sign changed to > for posting)
The provider blocks these calls as they require the header to be in international format, so the 0 at the start of the number needs to be +27
I have seen posts on how to modify the header, etc. but I can’t figure out how to change that number to show +27 instead of the 0, as I can’t just add the +27.
Why is your PBX sending Diversion headers back to your ITSP? Why isn’t the PBX answering the calls and dealing with them? How does a cell provider get involved in rejecting Diversion headers that were between your PBX and your provider?
Perhaps the OP should confirm this before we waste time on a solution, but my understanding is:
An incoming call is routed to a PBX extension, which is not answered. Using Follow Me or Unavailable Forward, the call is forwarded to the user’s mobile, sending the number of the original caller as caller ID. The provider handling the outbound leg routes the call onward to the user’s cell carrier. To reduce the number of spam/scam calls with spoofed caller ID, the cell carrier rejects calls from an unexpected source, unless the forwarding number (DID called) is properly presented in a Diversion header.
Yes, that’s exactly what happens.
The inbound caller ID will always change, so when the call is diverted to the cellular number of the recipient, the diversion header sends the original number that was dialled along but it’s in the incorrect format. This specific cellular provider has simply stated that unless the call is in the correct format, the call will be dropped.
For this reason, I need to change the diversion header to drop the 0 on the number and replace it with +27
Sigh. Not a single part of that process requires a Diversion Header. In fact the only way FreePBX will even send Diversion Headers is if the feature is explicitly turn on, which by default it is not.
Also why does the destination carrier care?! It doesn’t, stop referring to the “cell carrier” unless that “cell carrier” is somehow the ITSP as well. The only party that is going to care about the Diversion Headers is going to the the ITSP that the call is going out of. The destination carrier has nothing to do with this, nor will it care about Diversion Headers because PSTN.
When the PBX “forwards” is opens a new channel and to the PBX that is just a regular ole call that is going to be sent out the proper trunk. Adding the Diversion Headers to that call is to mimic what proxies do, actual divert the call, as opposed to what B2BUA’s do. Which is answer the call and create new calls/channels for the second (or more) legs. Not new branches of the same call.
@Stewart1 the trunk is chan_sip
I have tried creating a custom extension, which works when I dial the custom extension from another extension, but not when I divert an inbound call to the custom extension.
I have also tried FollowMe, but so far I’m not getting it to work.
@Tom Ray - that’s exactly the fight we are having with the cellular carrier (the destination) as they shouldn’t care, but for some weird reason, they are the ones insisting on the Diversion Header.
We place direct calls to them without any issue as the trunk manipulates the number correctly and changes it to the international format, but on a diverted call, they are blocking it because the diversion header is not in the correct format for them to accept the call.
So your provider, the one that provides you the SIP Trunk to the PSTN, they have no issues with your call? Because you understand at that point the call is going to between your provider and the destination carrier.
You in no way deliver calls directly to the cell provider unless you have some direct peering agreement with them. Are you peering with this cell provider directly or do all your calls go through your SIP provider?
Do they reject the call if you don’t send a Diversion header at all, but supply the number of the original caller in the correct international format? Can you post your trunk settings (except of course for username, secret, etc.)?
Do a test where you temporarily set Outbound CID for your extension to a number that is not yours. From that extension, dial your mobile directly. Does the call complete and does the number you set show on the mobile?
Yes, my provider as no issues with my call, but the destination carrier insists on a diversion header, and then proceeds to block it as it’s in the incorrect format. We do not connect to or have any agreements with the cell provider, they are just being ridiculous.
They reject the call if there is no diversion header
I did a test with an extension set to use a number that is not with us, and it went through to my cell, which is with a different provider without any issue, displaying the “wrong” CLID
I then dialled a cell that is with that specific carrier, and the number they display is the first number on the list of numbers that belong to us.
Well that doesn’t make any sense. The call is going to go from your PBX to your carrier. Once your carrier has the call, they decide what to do with it. They could end up routing directly to the cell carrier if they have a peering agreement with them or they will route it to a partner peer that can send the call to the destination carrier.
So clearly someone has something completely messed up or your provider is just really crappy.
I now get:
Executing [[email protected]:2] Gosub(“SIP/ECNTRUNK-00000008”, “func-set-sipheader,s,1(Diversion,<tel:+27422933723>;reason=no-answer;screen=no;privacy=off)”) in new stack
[2018-12-15 11:23:40] ERROR[C-00000006] app_stack.c: Attempt to reach a non-existent destination for Gosub: (Context:func-set-sipheader, Extension:s, Priority:1)
The call simply cuts off now when it starts diverting
I’m very puzzled. Possibly the code is different in the version you are running. Take a look at the sub-diversion-header subroutine in your /etc/asterisk/extensions_additional.conf . My intent was that the replacement code be identical except for inserting a modified value of FROM_DID.
If you can’t easily spot the trouble, report whether a truly identical replacement also causes the error.
That is on the specific route linked to the provider in question.
Can that be modified to change the diversion header on that route only?
Apologies, I am very unfamiliar with Asterisk, so learning as I’m going