Intermittent Failure of Outgoing SIP Calls
Hi,
M270 Firebox, 12.5.4 fw
I'm wondering if anyone can shed any light on an issue I am having.
I am reconfiguring my Avaya PBX to use SIP for external calls, so far, incoming calls appear to be working without a problem but I am seeing an intermittent issue with external calls.
When calling a mobile, 99% of the time the call completes as expected. When calling a landlane, 99% of the time I have no ringing and no voice when the call connects however the recipient of the call can hear me fine.
I have used traffic monitor and I can see the call connection packets, in the instances when I get no audio, nothing in the logs indicate an issue or data being being blocked.
I have an open support case but I thought I would also ask here incase anyone has experienced a similar issue and managed to resolve it.
Thanks
Comments
You are going to need to create a packet filter for the voice traffic. This filter in general will also need to be to the SPECIFIC address' if the internal devices (if you are using handsets such as Polycom, Yealink....
What I typically do in a smaller environment is group the handsets with DHCP reservations, create a alias to cover that range of IP's and have your ports and outside info there....for instance:
This example is for Nextiva, RingCentral and of course, Avaya would have different destinations and possibly some different ports.
Hi @IanW82
The first thing you need to do is upgrade your firewall to the lastest version of Fireware. The version you are running is potentially susceptible to malware known as Cyclops Blink. See: https://detection.watchguard.com/
Any firewall
With regards to the phones:
-By default, the Outgoing policy on the firebox will do what @TestingTester is showing -- allow the traffic out via a packet filter. Unless you've made a proxy policy with SIP-ALG, that is not enabled. Lots of VoIP providers will blindly provide troubleshooting steps asking to open huge swaths of ports or demanding you turn features on or off without even detailing what they believe the issue is. If nothing has changed on the firewall and this issue randomly popped up, it's very unlikely that the problem lies there.
If you're able to intermittently get calls out, the probability that these ports are closed are very low.
The VoIP provider should be able to see the call control data via the SIP protocol (SIP is mostly plain text and can be easily read in a tool like wireshark.)
If you're getting one way audio, it's likely that the RTP stream (the actual audio data) isn't being sent back to you properly.
-If you look in traffic monitor, do you see any Deny traffic coming from the SIP provider's IP ranges. If so, this suggests the phone(s) or PBX may not be keeping connections open as they should?
-DO you see any logs stating "TCP SYN CHECKING" or "INVALID TCP CONNECTION STATE" -- if so, the phones or service may be trying to recycle very old connections or ones that have reset -- these should be holding their connections open via their registration interval (usually something like 900 seconds.) You can turn off TCP Syn check/connection state verification in global settings if you're seeing this and it may help. Adjusting the connection timeout on your phone policies may help too.
If you can reply with the case number, I can make sure your case is with the correct team to assist.
-James Carson
WatchGuard Customer Support
@james.carson
Being as his firmware is older, one might assume it is out of support...but, a packet filter does not need any of the UTM or licensed features.
You are right that in theory, the traffic 'could' or even 'should' go out the device for voice (without the SIP-ALG I have never known any place who would need it). The fact is, without a proper packet filter I have never, not once ever seen a reliable connection for SIP devices (web clients would, of course, be different). This is why years ago myself and some folks on your Support Team came up with some default packet filter setups for RingCentral, Vonage, Phonality, 3CX and some others (they are all close for most ports...obviously their IPs are not the same. One would think that an 'any' policy would work...it does not.
Frequently there will be nothing but green traffic on the WG and there will be connectivity issues for IPTelephones, create the policy and they work 100% of the time.
Many are painting wide strokes for the ports they want open on the transport side (UDP 10,000-50,000) for instance. But, oddly, seems that on occasion they will touch every side of that spectrum if we try to tighten it down (seen with QoS or call connection issues).
Heck, any more you can not get email from Comcast on a MacBook Pro with out a custom packet filter for the traffic...should not -need- it, but you do.
@TestingTester
They said in their initial post that they had a case open, hence why I asked.
The only devices I've ever found that explicitly need SIP-ALG are some very old doorbell intercom phones that have to be set up with dip switches. Since the things are stuck to the sides of buildings, they quite often aren't changed out when hardware refreshes happen inside the building(s).
Most SIP devices nowadays use STUN to do NAT traversal -- the SIP-ALG will break that, so you end up with the two things fighting and a phone that can't get out.
-James Carson
WatchGuard Customer Support
@james.carson
@TestingTester
Thank you both for your replies, from the information you provided I am confident that it now works reliably. I'm not entirely sure why my initial rules didn't work as intended but I now have two new rules that I have based on the traffic monitor logs, since I implemented the rules, all calls have been successful.
Rule 1: Allows data to pass through and connect the call on port 5060, for both incoming and outgoing calls.
From: 3rd party supplied VOIP I.P addresses, PBX IP
To: "external I.P 1 --> PBX I.P", "external I.P 2 --> I.P 2", Any-External
Port: UDP:5060
Rule 2:
From: 3rd party supplied VOIP I.P addresses
To: "external I.P 1 --> PBX I.P", "external I.P 2 --> I.P 2" udp:10000, 11030
Since I implemented the rules, all of my test call have all completed successfully.
Nice. I have found that for HOSTED IP I have not needed inbound rules. For onsite (Like Avaya) I have needed them. No matter what, even with an 'any' rule, I have always needed rules for SIP.
Also, you may want to add a range (maybe). Many of the systems are going for 5061 and some randomly from 5060-9. We have had a number of Polycom handsets auto-configure to things in that range other than 5060.
If you get packet drop one way or the other (indicated by you can hear them but they can not hear you)...I have diagnosed that with a custom packet filter for the handsets and watched what ports the traffic is really going out on...as oppose to what it is suppose to go out on. Fun times.