Solved ATA sp112 behind Sonicwall to Skyetel
-
@jasgot What model ATA?
I will agree the issue is likely the SonicWall. But to prove it, we need packet captures from the ATA to start.
-
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.
-
@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
-
@pete-s said in ATA sp112 behind Sonicwall to Skyetel:
I believe tcp is the newer standard so old devices might not support it.
Not newer. Always a standard, but never very popular. UDP has always been the de facto standard, but TCP has always been an actual standard.
-
@jasgot said in ATA sp112 behind Sonicwall to Skyetel:
The ATA's outgoing port is something in the 13k+ range and it goes to port 5060 at Skyetel. It appears Skyetel answers back to the ATA on 5060, even though it sees the traffic coming in on the high port. Of course, there's no path back to the ATA on 5060, it's on the higher port.
Since Skyetel only answers on 5060, I think I need to force my ATA to send the registration request out on 5060, but I can see how to do that.The outbound port and the inbound port are not related to one another. Only the listening port is known. The response port is always a random port.
-
@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.
