Extensions_additional.conf | Where are the include elements located?


(Sip Sepp) #21

Thank you Tom for your input.

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:

Diversion: <tel:+49899876123>;reason=no-answer;screen=no;privacy=off

Conclusion:

  1. The failing call forwarding configured by the Grandstream telephone seems to be an issue between the telephone and the FreePBX.
  2. 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:

  1. I hear the dial tone
  2. The call is being forwarded
  3. If the participant on the forwarded mobile device takes the call, he cannot hear anything
  4. 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.

(Tom Ray) #22

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.


(Sip Sepp) #23

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?


(Sip Sepp) #24

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:

  1. Is it an expected restriction, that Users sync’ed from LDAP cannot be edited in the User Management?

  2. 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?


(Sip Sepp) #25

Found this one regarding the sound issue: SOLVED: No sound when do followme on ext call to ext number

Enabled the FAX detection, but it didn’t help.


(Sip Sepp) #26

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

In my opinion it should work.


(Dave Burgess) #27

This should not be disabled (see below).

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.


(Lorne Gaetz) #28

@cynjut you’re confusing firewalld with iptables. On an SNG7 distro system firewalld should be disabled.


(Avayax) #29

If you are losing audio then you need to do a packet capture and see where RTP is being sent, blocked, etc.


(Sip Sepp) #30

deleted


(Sip Sepp) #31

I did it and the capture result indicates that traffic is being sent from the FreePBX to the Vodafone SIP Gateway but it does not return.


(Sip Sepp) #32

I’ll keep firewalld disabled.


(Sip Sepp) #33

Hmm, where can I check if SIP-ALG is enabled? Slide 9 of this one https://www.slideshare.net/NetgateUSA/firewall-best-practices-for-voip-on-pfsense-pfsense-hangout-october-2017 says:

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.


(Sip Sepp) #34

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?


(Tom Ray) #35

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?


(Sip Sepp) #36

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?


(Sip Sepp) #37

Reconfigured the pfSense from NAT 1:1 to Port Forwarding & Outbound Rules.
Same behaviour: SIP TOP, RTP Flop!


(Itzik) #38

Do you forward 10k-20k to the PBX?


(Sip Sepp) #39

Treid it with 10000-20000, with 10000-50000, 1024-65535 and any variation I found on different howtos.
Always the same issue: no audio.


(Itzik) #40

Can you post a call log?