External phones not callable

(Theta Coder) #1

Forgive me for being an idiot about this.
We are running FreePBX 14 (up to date)
The server is a dedicated unit, with dual NICs. SIP trunk provided by Spectrum. All internal phones are on a dedicated 172.16.x.x network, and the server has a second nic on our business side so we can access the Dashboard.
We have a remote employee starting. They are running Zoiper 5 until thier new physical phone arrives.
We created a new extension with no presently applied template (Her real phone will be a Yealink)
It presently is the most basic of setups, no VM, call forwarding, no follow-me or anything. Just a single extension and assigned to her user.
We made rules in the firewall for SIP on our ports, and the RTP UDP range, and created a rule that allows the remote employees computer to talk on said ports to the phone server through the business side.

The Zoiper software shows it is connected to the server. When she tries to dial a number, it will ring my extension, and when I pick up, there is dead air, no audio at all.

Have I missed something, or is this up the road of call Sangoma and get more support credits.

(Communication Technologies) #2

IF you can ring, the signaling is intact. No audio seems to point to the RTP packets. I know you said you did, but making sure the RTP port range on your FreePBX match what’s allowed on the firewalls.


You might need to trace the packets on your network to see where the RTP packets are dropping. Could also be a NAT issue.

(Theta Coder) #3

Just verified in the firewall. The SIP ports match and the RTP ports match the settings in the Asterisk SIP settings from the dashboard. Still looking into the possible NAT


From the asterisk cli

rtp set debug on

(Theta Coder) #5

Verified SIP transforms is OFF (SonicWall firewall) and Consistent NAT is enabled
Sent that CLI command, and tried dialing the extension. Phone display said it was OK, but got no connection, and an service unavailable.


That doesn’t jive with

…The Zoiper software shows it is connected to the server. When she tries to dial a number, it will ring my extension, and when I pick up, there is dead air, no audio at all…

Did something change?

(Theta Coder) #7

Mine rang hers, my guess is the SIP signaling is ok, but the RTP UDP stream is getting wonked. But not sure.


Thats what the rtp debug will show after a call is connected (answered).

(Theta Coder) #9

Should that be run from the Dashboard, or from a SSH session? In the dashboard there was nothing, there was a return of the turning on and another when I cycled it off

(Luke C) #10

I have had good luck and bad luck with Sonicwalls, do yourself a favor and throw that thing in the garbage. People will say if you have the correct NAT settings they work fine, which is true most of the time.

Id compare it to dialing in a chevy 350 engine with a carburetor. Why mess with it tho, Id rather just LS Swap it and have the 5.3 or 6.0 engine with fuel injection.

(Theta Coder) #11

Sadly, my company is a Sonic Wall reseller. I would love to have a Cisco or PaloAlto up on my rack, but that is not in the cards for this.


Preferable from a shell login (ssh or local tty)

  1. Look at the logs.
  2. What happens when you call your remote employee? Audio, or no?
  3. Are you using pjsip or chan_sip for your extension?
  4. Regardless of which one you’re using, try the other and see what happens.
  5. I agree with other’s observations about SonicWall. If you can, at least try with another router. If you cannot, ensure that you’ve DISABLED any features on the SonicWall that purport to help with SIP (especially ALG).
  6. Reboot the router. Yes, seriously - this has solved one-way audio problems for me in the past.


Oh, and one more thing: Consider having your employee connect to your network via a VPN. if your employee is in a local subnet via a VPN, presumably all of these problems go away.

(Theta Coder) #14

We are using Chan_Sip.
After fiddling with how to view the logs, for some reason, the dashboard indicates she is connected (based on the silly graph, shows no users offline, and all users online), but there is a line in the full log that says she is not fully registered, so I am working on tracing that down.
We are trying to avoid a VPN if possible, given the rather large hit in bandwidth it incurs.
And yes, we did go and check with a different Tech, SIP Transforms (ALG) are disabled and consistent NAT is enabled.

(Dave Burgess) #15

There is a long, explanatory thread on here about “Success With SonicWall” from maybe a year ago. I recommend you start with that instead of reinventing the wheel and trying to guess on a bunch of stuff.

[mod edit: Happiness With Sonicwalls - It can happen!]

(Theta Coder) #16

Checked the link provided. Set the settings, re-verified my NAT rules, NAT, SIP transforms and the like. Tried PJSIP, wouldn’t even register.

It honestly seems like the UDP packets are all getting dumped and either are never getting out or are trying to be sent down the wrong network.



Thats what the rtp debug will show after a call is connected (answered).

Did you try that yet?

(Theta Coder) #18

Ok. I putty’ed into the server, did a ‘tail -f full’ in the var\log\asterisk
I then placed a call from my internal extension (105) to the test external connection (205)
105 is on the internal dedicated phone network (172.16.x.x)
205 is on an external WAN, connecting through our business side system.
It showed registered, and did ring. But when picks up, nothing. I hung up after about 10 seconds.
The log of the putty session is here https://pastebin.com/QQZCSayi


But how about looking for media traffic ? (it won’t be in the log file until you enable it !)

(Theta Coder) #20

so enable the rtp debug in the cli, then cap a putty session?