Audio works with inbound calls from the DID of one VoIP provider but working with another (SIPSTATION)

FreePBX Providers
2

Please confirm that in your pfSense, you have forwarded UDP ports 10000-20000 to the LAN address of the PBX.

If for some reason you cannot do this, turn off source port rewriting; see
https://docs.netgate.com/pfsense/en/latest/nat/static-port.html
This is not as robust as forwarding the ports. For example, it won’t work if a DID gets forwarded to an external mobile number.

Audio is working now with VoIP.ms, because they detect the port (rewritten by pfSense and unknown to Asterisk) from which your audio is coming, and send their audio back to the same port.

1 Like
3

@Stewart1 is on the right track. Media for voip.ms is proxied through their signalling servers, so you can expect audio to work without router forwarding rules. SIPStation does not do this, so the full RTP range must be forwarded to the PBX at the router.

4

@Stewart1 Thanks for your reply. As I indicated in my initial post, the first thing I did when audio wasn’t working with the SIPSTATION DID was to forward UDP ports 10000-20000 to the LAN IP address of the FreePBX server. The reason that I’m quite sure this is working is that before I did this, the SIPSTATION External Connectivity–>Check Connectivity failed to pass the SIPSTATION Firewall Status test. However, after opening up UDP ports 10000-20000, the Firewall Status test showed “Pass”.

5

Please confirm that your pfSense has a public IP address on its WAN interface. If not, please explain (your ISP-supplied modem is configured as a router, your ISP does NAT, etc.)

Also, it’s possible the port forwarding setup is sufficient to satisfy the firewall test but is still translating port numbers. Please see
https://docs.netgate.com/pfsense/en/latest/nat/configuring-nat-for-a-voip-pbx.html

On the failing calls, is there audio in either direction?

6

@Stewar1 Again, thanks for your reply and that of lgaetz. Yes, the WAN interface on pfSense is a public IP, 64.x.x.x. On the failing calls, there is no audio period.

Also I followed the instructions to turn off source port rewriting above (at least as far as I could understand it), but there was no change in the audio.

I will next check the netgate pfSense docs on configuring NAT for a VoIP box and will let you know.

7

To be clear, you need to forward 10k-20k from all source IPs, not just the signalling hosts.

8

@ Stewart1 As suggested, I went to the pfSense docs on Configuring NAT for a VoIP PBX:

https://docs.netgate.com/pfsense/en/latest/nat/configuring-nat-for-a-voip-pbx.html#

+++++++++++++

For VoIP there are typically a few components to get right for proper inbound and outbound audio from a local PBX.

  1. Port forward entries with firewall rules (Or 1:1 NAT with Firewall Rules)
  2. Manual Outbound NAT with a rule at the top set to perform static port NAT on traffic from the PBX (Or 1:1 NAT)
  3. On the PBX, ensure it is set properly for NAT with the correct external IP and local subnets defined.

+++++++++++++
For step 3 above, I went to Settings–>SIP Settings–>NAT Settings and confirmed the External Address: 64.x.x.x. and my Local Network: 172.16.0.0/24. RTP Port Ranges–>10000-20000. In Chan_SIP the Bind Port is 5060 and TLS Bind Port is also 5060.

Note that TCP has been enabled (for Avaya IP phones to work).

+++++++++++++

Port Forwards

For the port forward ( Firewall–>NAT , Port Forwards tab), it can be set as follows:

  • Interface : WAN
  • Protocol : UDP (or TCP/UDP if needed)
  • Source : Type Single Host or Alias : SIP_Trunks – or a Any for the type if the SIP trunk IP addresses are not known.
  • Source Port : any/any
  • Destination : WAN address or external VIP for the PBX
  • Destination Port : PBX_Ports
  • Redirect target IP : PBX
  • Redirect target port : PBX_Ports

Manual Outbound NAT

For Manual Outbound NAT , navigate to Firewall > NAT , Outbound tab, switch from Automatic Outbound NAT to Manual Outbound NAT and press Save . Then at the top of the list, create a rule that looks like so:

  • Interface : WAN
  • Protocol : UDP
  • Source : Network , PBX
  • Source Port : [blank]
  • Destination : Network , SIP_Trunks – Or Any for the type if the SIP trunk IP addresses are not known
  • Destination Port : PBX_Ports (or leave blank)
  • Translation : Interface address if using the WAN IP address, or the external VIP for the PBX
  • Port : [blank]
  • Static Port : CHECKED

Reset States

After making the changes to NAT rules, the states for the PBX must be reset.

  • Navigate to Diagnostics > States
  • Enter the IP address of the PBX and click Filter
  • Click Kill

Once the PBX re-registers it test inbound and outbound calls and confirm inbound and outbound audio works as expected.
+++++++++++++
I followed instructions for Port Forwarding and Manual Outbound NAT carefully and am confident that the configuration I have is correct. I did “Kill” all the states, and waited for the SIP trunks to re-register.

But again, altho’ my local IP phone rings on ext. 1001, there is no audio on either end when I call the SIPSTATION DID.

9

@lgaetz Also to answer your last reply “To be clear, you need to forward 10k-20k from all source IPs, not just the signalling hosts”, the port forwarding rule in pfSense in this regard is:

Interface:WAN
Protocol:UDP
Source Address:*
Ports:*
Address:WAN address
Dest. Ports:10000-20000
NAT IP:17.16.0.175 (i.e., my FreePBX server)
NAT Ports:10000-20000

10

Looking through the logs for a call where the audio fails, can someone explain if “ERROR … This function requires a PJSIP channel” is relevant:

[2020-03-27 06:31:19] VERBOSE[13421][C-00000006] pbx.c: Executing [[email protected]:9] ExecIf(“SIP/fpbx-1-Yksxxxxxx-0000000b”, “0?MacroExit()”) in new stack
110 [2020-03-27 06:31:19] VERBOSE[13421][C-00000006] pbx.c: Executing [[email protected]:10] ExecIf(“SIP/fpbx-1-Yksxxxxxx-0000000b”, “0?ChanSpy(SIP/7525,q)”) in new stack
111 [2020-03-27 06:31:19] VERBOSE[13421][C-00000006] pbx.c: Executing [[email protected]:11] ExecIf(“SIP/fpbx-1-Yksxxxxxx-0000000b”, “0?MacroExit()”) in new stack
112 [2020-03-27 06:31:19] ERROR[13421][C-00000006] res_pjsip_header_funcs.c: This function requires a PJSIP channel.
113 [2020-03-27 06:31:19] VERBOSE[13421][C-00000006] pbx.c: Executing [[email protected]:12] ExecIf(“SIP/fpbx-1-Yksxxxxxx-0000000b”, “0?Macro(vm,7525,DIRECTDIAL,)”) in new stack
114 [2020-03-27 06:31:19] ERROR[13421][C-00000006] res_pjsip_header_funcs.c: This function requires a PJSIP channel.
115 [2020-03-27 06:31:19] ERROR[13421][C-00000006] res_pjsip_header_funcs.c: This function requires a PJSIP channel.
116 [2020-03-27 06:31:19] VERBOSE[13421][C-00000006] pbx.c: Executing [[email protected]:13] ExecIf(“SIP/fpbx-1-Yksxxxxxx-0000000b”, “0?MacroExit()”) in new stack
117 [2020-03-27 06:31:19] ERROR[13421][C-00000006] res_pjsip_header_funcs.c: This function requires a PJSIP channel.
118 [2020-03-27 06:31:19] ERROR[13421][C-00000006] res_pjsip_header_funcs.c: This function requires a PJSIP channel.
119 [2020-03-27 06:31:19] VERBOSE[13421][C-00000006] pbx.c: Executing [[email protected]:14] ExecIf(“SIP/fpbx-1-Yksxxxxxx-0000000b”, “0?Gosub(ext-intercom,*807525,1())”) in new stack
120 [2020-03-27 06:31:19] ERROR[13421][C-00000006] res_pjsip_header_funcs.c: This function requires a PJSIP channel.
121 [2020-03-27 06:31:19] ERROR[13421][C-00000006] res_pjsip_header_funcs.c: This function requires a PJSIP channel.
122 [2020-03-27 06:31:19] VERBOSE[13421][C-00000006] pbx.c: Executing [[email protected]:15] ExecIf(“SIP/fpbx-1-Yksxxxxxx-0000000b”, “0?MacroExit()”) in new stack
123 [2020-03-27 06:31:19] ERROR[13421][C-00000006] res_pjsip_header_funcs.c: This function requires a PJSIP channel.
124 [2020-03-27 06:31:19] ERROR[13421][C-00000006] res_pjsip_header_funcs.c: This function requires a PJSIP channel.
125 [2020-03-27 06:31:19] VERBOSE[13421][C-00000006] pbx.c: Executing [[email protected]:16] ExecIf(“SIP/fpbx-1-Yksxxxxxx-0000000b”, “0?ChanSpy(SIP/7525,q)”) in new stack
126 [2020-03-27 06:31:19] ERROR[13421][C-00000006] res_pjsip_header_funcs.c: This function requires a PJSIP channel.
127 [2020-03-27 06:31:19] ERROR[13421][C-00000006] res_pjsip_header_funcs.c: This function requires a PJSIP channel.
128 [2020-03-27 06:31:19] VERBOSE[13421][C-00000006] pbx.c: Executing [[email protected]:17] ExecIf(“SIP/fpbx-1-Yksxxxxxx-0000000b”, “0?MacroExit()”) in new stack
129 [2020-03-27 06:31:19] ERROR[13421][C-00000006] res_pjsip_header_funcs.c: This function requires a PJSIP channel.

11

not relevant

12

I suppose I have to ask the obvious question from what I have learned here, and I mean this respectfully, because I have seen there are some awesome people from Sangoma, whom I have high regard for, constantly monitoring and assisting the FreePBX community channel.

My question is this: FreePBX is a fabulous system by any standard, and because–as I understand it–Sangoma owns Asterisk and FreePBX, FreePBX is or should be, tightly coupled with SIPSTATION. Why is it that it is so much easier, not to mention significantly less expensive, for a non-FreePBX VoIP provider to have phones working through a pfSense (or another vendor’s) firewall with exactly zero configuration with their SIP trunks when–it appears–this can’t be accomplished without significant effort on the part of someone using SIPSTATION trunks. Yes I realize that SIPSTATION clearly points out in their documentation that having a third party firewall in front of FreePBX means that things probably won’t work. If another VoIP provider can do it, why can’t Sangoma and SIPSTATION?

Why should I stay with more expensive SIPSTATION trunking when I am finding out they are much more complicated to configure, when I could go with a competitor where things just work? What am I missing?

13

Better timing for this question, frankly. As Inspector Clouseau said, “Now is not the time, Cato.”

14

@FreerPBXer OK, agreed.

15

Read this post: SIP Port Forwarding

Do the channel originate test noted therein using your working trunk. I will bet that the test fails for you. You have configured your router for a specific SIP use case, one that works for the majority of calls using one provider but not another. With only two data points and success with one but not the other, your mistake is in assuming there is something at fault with the non-working provider. If you went out and chose 20 more providers at random, you would see similar problems with about half of them. It is not the service that’s at fault here, it’s your router configuration. There is almost nothing that can be done at the PBX to compensate for router/firewall misconfig.

Not sure which docs you refer to here, but this is just not true. I would guess the majority of SIPStation customers are behind NAT, and unless they are using a Sangoma SBC, they are by definition behind a third party router/firewall. The service works fine if the firewall is configured correctly.

16

@lgaetz Thanks for your reply again. I do want to say that I am listening to you and the others who respond on this channel and I truly appreciate the expertise and dedication you bring to FreePBX, especially in this VERY difficult time. I might be mis-informed but my questions are honest appeals for assistance. (I may be relatively new to FreePBX, but I’m not new to computer support.)

Firstly, to my statement that “having a third party firewall in front of FreePBX means that things probably won’t work” I refer to the statement (in red ink) when enabling the Sangoma Smart Firewall in FreePBX that says:

“To receive the full benefits of the Sangoma Smart Firewall, you should ensure that no other firewall is intercepting traffic to this machine. This is normally accomplished by configuring your internet connection to place this machine in the ‘DMZ’ of your gateway. If you are unable to do this, it is unlikely that Responsive Firewall will work correctly, if at all.”

Apologies if I mis-interpreted what the statement above says, but I have a hard time understanding that putting FreePBX behind a pfSense firewall is not a good idea. Anyway, enough on that.

However I completely agree with you and admit that I am wrong to make assumptions about things not working when relying on only two data points. You’re the one with the years of support expertise and if you say it’s likely that half of providers would have similar issues, and that nothing can be done at the PBX to compensate for router/firewall misconfig, I totally believe that. 'Nuff said.

Another comment. You say: “You have configured your router for a specific SIP use case, one that works for the majority of calls using one provider but not another.” In this particular case, with VoIP.ms, using VoIP trunks and a VoIP.ms DID, the fact is I have NOT configured pfSense at all, period. Nothing, no SIP or UDP ports forwarded, etc. In this case, I got lucky and everything just worked.

Now on to the link to SIP Port Forwarding provided above. Your post from Nov. '17 is clear and well-written and you clear up a mis-conception I had that port forwarding is unnecessary with FreePBX. I’m no firewall expert, but configuring port forwarding in pfSense isn’t terribly complicated and I believe I had forwarded UDP ports 10k-20K correctly in pfSense. That was reinforced when, in the Connectivity Test in SIPSTATION, the test would fail when port forwarding of ports 10k-20k in pfSense was toggled off, and pass when port forwarding was toggled on. If the connectivity test produces false positives, I expect this to be explained somewhere.

One thing you mention in your Nov '17 post is the test you do from the Asterisk CLI:

channel originate local/[email protected] application echo

When I perform the channel originate command to the VoIP.ms DID with the working VoIP.ms trunks, both with and without UDP ports 10k-20k forwarded on pfSense, there is no echo as you predicted.

Can you point me to additional logs, or debug flags, etc., so I can further troubleshoot this issue?

1 Like
17

The test proves what we already know, inbound media is either being blocked or misdirected by the router. Given that something changed when you added the forwarding rule, it seems likely that media is being misdirected by inconsistent RTP port rewrites. I know very little specifically about pfsense, but it’s a common router and I expect there are numerous resources to assist with configuring for SIP. Indeed there are three FreePBX wiki pages that mention pfsense:

https://wiki.freepbx.org/display/ST/Troubleshooting+SIPStation#TroubleshootingSIPStation-IamhavingtroubleusingSIPStationbehindaPFSensefirewall.

https://wiki.freepbx.org/display/FPG/NAT+Configuration+FreePBX+12?focusedCommentId=89817603#comment-89817603

https://wiki.freepbx.org/display/FDT/[How-to]+Setup+VPN+between+pfsense+and+FreePBX

18

@lgaetz Thanks for your reply.

I worked with Sangoma SIPStation support yesterday and today and was able to get outbound and incoming calls working with SIPStation by making changes to the NAT rules in pfSense. Support referred me to the following document:

Following instructions here:
https://docs.netgate.com/pfsense/en/latest/nat/configuring-nat-for-voip-phones.html

Setting Static Port using Hybrid Outbound NAT

To disable source port rewriting, the Static Port option must be used on outbound NAT rules. When crafting these rules, be as specific as possible with the source, destination, and destination port to avoid problems with other traffic

  • Navigate to Firewall > NAT on the Outbound tab - Done
  • Select Hybrid Outbound NA - Done
  • Click Save - Done
  • Click Add with the up arrow to add a rule to the top of the list - Done
  • Set Interface to WAN - Done
  • Set the Protocol to match the desired traffic (e.g. UDP) - Done
  • Set the Source to match the local source of traffic, such as LAN Net or a specific device such as a game console IP address, or an alias containing multiple such devices - Source: 172.16.0.175 - Done
  • Leave the Source Port box empty, which indicates any - udp/ - Done*
  • Set the Destination to match the traffic, if known, otherwise leave set to ‘any’ - * - Done
  • Set the Destination Port to a specific port or port alias, if it is known, otherwise leave the box blank for any udp/ - Done*
  • Set the Translation Address to Interface Address or an appropriate VIP if needed - - Done
  • Check Static Port to indicate that traffic matching this rule will retain the original source port - - Done
  • Click Save - Done
  • Click Apply Changes - Done
  • Navigate to Diagnostics > States - Done
  • Enter the IP address of the device in the Filter box if a specific source was used in the rule
  • Click Filter - Done
  • Click Kill - Done

The pfSense firewall was rebooted. When I run the External Connectivity / Check Connectivity Test in the SIPStation module in FreePBX, firewall status again shows FAIL.

An outgoing call to the PSTN (my mobile) works. Audio works in both directions.
An incoming call from my mobile works. Audio in both directions.

I think we can close this issue. However, can someone please explain why the SIPStation External Connectivity / Check Connectivity test shows a false positive. I have spent hours pulling my hair out on on this.

Sangoma SIPStation Support replied to my last question as follows:

Unfortunately regarding the Connectivity test it is not the best. It does need to be either improved or removed because it does sometimes give a result that is not truly indicative of quality of setup.

19

Just to close this off, I would like to document the pfSense settings to get both SIPStation and VoIP.ms working for me:

Host dnsmgr Username Refresh State Reg.Time
trunk1.freepbx.com:5060 Y YksXXXXXXXX 105 Registered Wed, 01 Apr 2020 02:25:37
vancouver1.voip.ms:5060 Y 12345_user 105 Registered Wed, 01 Apr 2020 02:25:37
vancouver2.voip.ms:5060 Y 12345_user 105 Registered Wed, 01 Apr 2020 02:25:37
trunk2.freepbx.com:5060 Y YksXXXXXXXX 105 Registered Wed, 01 Apr 2020 02:25:37
4 SIP registrations.

Create pfSense aliases in Firewall–>Aliases:

IP Aliases

PBX: 172.16.0.175
SIPSTATION_trunks: trunk1.freepbx.com, trunk2.freepbx.com
VoIPms_trunks: vancouver1.voip.ms, vancouver2.voip.ms
Trunks: trunk1.freepbx.com, trunk2.freepbx.com, vancouver1.voip.ms, vancouver2.voip.ms

Port Aliases

PBX_RTP_Ports: 10000:20000
SIP_Port: 5060

In Firewall–>NAT–>Port Forward, create rules as follows:

Interface: WAN
Protocol: UDP
Source Address: Trunks
Source Ports: *
Dest. Address: WAN address
Dest. Ports: PBX_RTP_Ports
NAT IP: PBX
NAT Ports: PBX_RTP_Ports

Interface: WAN
Protocol: TCP/UDP (note: TCP is required for some Avaya IP phones in my setup)
Source Address: Trunks
Source Ports: *
Dest. Address: WAN address
Dest. Ports: SIP_Port
NAT IP: PBX
NAT Ports: SIP_Port

It may be necessary to kill the states associated with FreePBX.
As above, navigate to Diagnostics–>States
Enter the PBX server IP (i.e., 172.16.0.175) in the Filter box.
Click Filter
Click Done

20

An additional point that Sangoma SIPStation support clarified regarding the IP Configuration setting in SIP Settings–>Chan SIP Settings:

The setting should be “Static IP”. “Public IP” would mean that there is a public IP directly on the PBX which I doubt is the case here. It is not the recommended setup.

1 Like
21

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.