Solved ATA sp112 behind Sonicwall to Skyetel
-
@jaredbusch said in ATA sp112 behind Sonicwall to Skyetel:
@pete-s said in ATA sp112 behind Sonicwall to Skyetel:
One difference between different providers can be if they're using tcp or udp. I believe tcp is the newer standard so old devices might not support it.
WTF
Just because you don’t know what you’re talking about does not mean you should talk out of your ass. TCP was part of the original RFC
I don't know how to talk with my buttocks. I'm not into deviant behavior but to each his own.
-
@jasgot using TCP can fix your issue from the it does not work perspective. But it will not resolve the actual configuration problem you have with UDP traffic.
If you can get a pack of capture of the registration packet and response that would be useful to troubleshoot
-
@pete-s said in ATA sp112 behind Sonicwall to Skyetel:
One difference between different providers can be if they're using tcp or udp. I believe tcp is the newer standard so old devices might not support it.
A quick search seems to indicate that Skyetel is udp by default but can be switched to tcp.
TCP should be better for the firewall because it tracks tcp sessions but not udp. So it knows where to send a reply inside a tcp session.
I would give it a try. Switch Skyetel to tcp.
FWIW - if you are using SIP Registration, we do not support TCP, only UDP.
TCP + SIP Registration = Very Insecure + Much More Vulnerable to DDOS.
-
[takes thumb out of ass for a moment, speaking begins]
Isn't there an option in the Sonicwalls that has to be turned off (or maybe on)? I don't deal with them, so I'm not sure what that option is called any more.
[puts thumb back where it belongs]
-
@dafyre said in ATA sp112 behind Sonicwall to Skyetel:
[takes thumb out of ass for a moment, speaking begins]
Isn't there an option in the Sonicwalls that has to be turned off (or maybe on)? I don't deal with them, so I'm not sure what that option is called any more.
[puts thumb back where it belongs]
SIP-ALG - yep.. that should be killed with fire!
-
Turning SIP Transformations on in the Sonicwall made it so the SPA122 would register with Skyetel, however it killed the phones that register with VitalPBX.
The solution turned out to be using a Firewall Rule to turn on SIP Transformations for ONLY the ATA. All is good now.
Here is the SIP Transformation turned on and set for Rule Based
And here is the Rule:
-
I never had an issue with Cisco ATAs connected to a cloud service behind Sonicwall devices. I don't recall setting anything up, but I am curious enough to review my setup notes to confirm.
-
FWIW - Hate SonicWall (I think most people don't know how to configure them properly) - and Hate SIP ALG - most routers don't implement it properly and it does nothing but fuck things up.
-
@jclambert said in ATA sp112 behind Sonicwall to Skyetel:
I never had an issue with Cisco ATAs connected to a cloud service behind Sonicwall devices. I don't recall setting anything up, but I am curious enough to review my setup notes to confirm.
We have not either. We have many Cisco SPA ATAs in service. All of them behind Sonicwalls. This is the only one connected to Skyetel.
-
@jasgot said in ATA sp112 behind Sonicwall to Skyetel:
@jclambert said in ATA sp112 behind Sonicwall to Skyetel:
I never had an issue with Cisco ATAs connected to a cloud service behind Sonicwall devices. I don't recall setting anything up, but I am curious enough to review my setup notes to confirm.
We have not either. We have many Cisco SPA ATAs in service. All of them behind Sonicwalls. This is the only one connected to Skyetel.
Would need to see the packet as I mentioned above to try and give you any kind of answer on why.
