External phones not callable

From the asterisk cli

rtp set debug on

1 Like

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?

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).

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

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.

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.

https://www.sonicwall.com/support/knowledge-base/how-to-disable-sip-alg/210615065648977/

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.

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.

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!]

2 Likes

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.

Agian

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

Did you try that yet?

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 !)

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

enable the rtp debug and you will be able to look at it later in /var/log/asterisk/full by any means you feel comfortable with, but generally a real time view in the Asterisk CLI ( or using tail in a shell) will clue you up quickly

In my experience, the CLI output goes by too quickly to do anything more than an cursory exam. Run the test and check it out “at your leisure” in the /var/log/asterisk/full log.

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