I corrected the escape character (the backslash) in the dial plan, but it didn’t make any difference.
Of course it must be the way you stated. The original [sub-diversion-header] context also is featured with the escape character prior to the semi-colon.
Till today I always initiated the Call Forwarding function by hitting the following keys on my deskphone (it is a Grandstream GXP 1630 model): *720171987654321#
Where 0171987654321 is the mobile number where the ingoing call shall be forwarded to.
It never worked due to the diversion header issue we’re talking about in this thread.
Now I made an interesting experience playing around with the FreePBX’s “FollowMe” feature that is part of every extension’s confugration options within the Web GUI.
First I created a “Misc Destination” including the mobile number where to redirect to, then I set it on my extension’s “Find Me / Follow Me” tab at “Destinations” (bottom of the configuration page).
Having disabled the call forwarding on the telephone (i.e. *73# ) I performed a test call from external to my extension.
The result:
The call will be forwarded to the mobile number I configured as “Misc Destination”!
Investigating the diversion header in the SIP trace, it shows what Vodafone support told me how it should look like:
The failing call forwarding configured by the Grandstream telephone seems to be an issue between the telephone and the FreePBX.
Vodafone support didn’t lie to me (at least this time)
This would be an acceptable workaround to make call forwardings possible at all, if there wouldn’t be another issue now:
Having perfomed three or four test calls where all of them succeeded, now I cannot hear anything anymore.
Call is being forwarded like before to the mobile device, but you cannot hear a dialing tone and when the participant on the forwarded device takes the call, both ofthem cannot hear each other.
Some time later: I rebooted the deskphone and the FreePBX server, I deleted and recreated both the extension and its inbound route used for the call forwarding test and now there is again a different behaviour:
I hear the dial tone
The call is being forwarded
If the participant on the forwarded mobile device takes the call, he cannot hear anything
On the caller’s mobile phone you still can hear the dialing tone. It seems that the caller’s device didn’t get knowledge that someone took the call.
And that’s why I wanted to know the call flow. When the CF is at the phone level then the transaction is happening at the phone, so the PBX thinks it’s an outbound call from the phone and that’s why it was using the extension’s callerID in your calls at first.
You should be doing this via the feature codes or UCP to enable CFU on the extension, then the PBX would honor all the inbound call settings including the ${FROM_DID} variable and then it would go through the outbound routes and the PBX would see it as a truly forwarded call.
Right now the PBX just sees this as a new call from the phone. Doing this at the PBX level would make this a lot easier I believe.
Well, the feature code for CF is *72 . This is what is defined for “Call Forward All Activate” at Web GUI > Admin > Feature Codes > Callforward.
I don’t think that the Grandstream phone has to be configured additionaly. It “undestands” that a call forwarding has been configured by *720171987654321# . At least it shows the “Call Forwarding Icon” on its display.
Regarding the UCP I must admit that we never used it for our users. I just tried to entitle my user for UCP login, but at User Managment > MyUserName > Edit Icon (Stylus) I cannot save settings having changed them: There’s no SAVE button.
On the top of the page there’s a notification:
The directory for this user is currently locked while updates are being run
The “currently” here means ALWAYS. It’s the same for all of the user accounts.
We import the users from the OpenLDAP server. Could that be the reason, why we cannot change the user settings?
Just to check the UCP I created a new user within the PBX Internal Directory, a new extension and linked it to the new user.
I was able to entitle this user for UCP login and configure further settings, because the SUBMIT button is available here.
Having logged in with the new user to the UCP, I configured the unconditional call forwarding and made a test call.
Result: The call was forwarded as expected! The SIP trace shows the correct Diversion header! Not so good: The caller and the callee couldn’t hear each other.
Questions:
Is it an expected restriction, that Users sync’ed from LDAP cannot be edited in the User Management?
What could be the cause that the participants cannot hear each other? Do the SIP trace or the full log help to understand the issue?
Apparently in 99% of the cases wrong port filter settings are responsible for this behaviour, if the FreePBX is located behind a NAT firewall - this is the case in my setup.
Let’s check the rules:
The FreePBX system firewall firewalld is disabled
The company firewall (pfSense 2.4.4p1) has the WAN and the LAN NIC
The FreePBX is located in the LAN
A static public IP is mapped by NAT 1:1 to the FreePBX’ local IP
On the pfSense’s WAN interface there’s a rule to allow traffic on any IPv4 UDP ports to pass from the Vodafone SIP-Gateway’s IP to the FreePBX’ IP.
On the pfSense’s LAN interface there’s a rule to allow traffic on any IPv4 UDP ports to pass from the FreePBX’ IP to the Vodafone SIP-Gateway IP.
The FreePBX is configured to use the RTP ports from 10000 to 20000
There are several specific and special settings for pfSense routers - making sure SIP-ALG is off is the first one.
This is why you should have the firewall on the server turned on. You are allowing a lot of potentially bad traffic when you do this. Also, you shouldn’t use 1:1 NAT with Asterisk. You should set it up with specific ports forwarded from pfSense to the internal network of the phone server.
In my opinion, until you make these changes, you aren’t going to get it working.
pfSense does not include a SIP Application Layer Gateway (ALG) to modify the contents of SIP packets - The contents of SIP packets is always passed as-is.
Well, the FreePBX is in the LAN and inbound connections are restricted to the Vodafone SIP Gateway.
Regarding the 1:1 NAT configuration almost all of the guides and howtos I found include an 1:1 NAT + Firewall Rules scenario and alternatively the Port Forwarding + Outbound NAT Rule scenario.
Short poll: Do experienced FreePBX admins generally advise against the NAT 1:1 scenario?
Only if they don’t mind disregarding the fact they have a firewall to protect the machine and then they just let it all through with this method. Why do you need to let everything through?
I do not. Inbound traffic is only allowed from the Vodafone SIP Gateway (they call it also SBC = Session Border Controller). The “all UDP ports allowed from SBC to FreePBX” rule is only temporary as long as audio doesn’t work).
OK, apart from the firewall question there’s no further reason not to use the 1:1 NAT scenario - especially regarding the lacking audio?