Call parking and retrieving, SIP ALG, ports 5060 and 7000, and different protocols

[Guest DanH]

Subject: issues with retrieving parked calls; support ticket. 

Support received complaint about parked calls not being able to be retrieved, "odd behavior". Observation from reporting environment: 

Devices consistently using port 7000. Support agent noted their testing environment was consistently using port 5060.  Through testing with SIP both enabled and disabled, as well as different ports being specified (7000 vs 5060), and specifying different proxy servers for registration, it was determined that none of 2600Hz's zones were experiencing any issues with parking, and that SIP ALG was the suspected problem. 

Setting protocol to TLS, specifying port 7000, and disabling SIP ALG altogether were identified as workarounds for this issue that was concluded to be local network derived. 

[Skunkbeard]

So I know SIP ALG is the firewall setting. But when you specify TLS and Port 7000 are you referring to sip server settings on the device? Transport is set to TLS and Port default is 5060/0 changed to 7000? 

 

Edited June 24, 2022 by Skunkbeard (see edit history)

[mc_]

Firewalls with SIP ALG typically target UDP (and maybe TCP) packets destined for port 5060 on the remote side.

When ALG can't be turned off at the client site, moving traffic to port 7000 (a typical alternative SIP port) makes the packets pass through the firewall unmolested.

Adding TLS obviously encrypts the packets to keep them from being mangled as well - not required to move to 7000 to do this. Not sure if there's a standard or convention, but I think TLS-enabled connectivity targets ports 5061 and 7001 on KAZOO: https://github.com/2600hz/kazoo-configs-kamailio/blob/69840f0c5a11237b1b216072e411d3d98df006eb/kamailio/listener-defs.cfg#L9

[Rick]

So, to expand upon this a bit more, there's a few steps I'll personally take if I suspect LAN issues.

 

First, I'll check to make sure that port 7000 is being used or not. If not, I'll switch the phone to using port 7000 as 5060 is very commonly caught by router's SIP ALG and as we all know, SIP ALG is universally TERRIBLE.

If it persists after that, I'll enable TCP transport instead of UDP. There's some overhead that comes along with this, but it's not too terrible and it can resolve issues like UDP fragmentation.

If it STILL persists after this, I'll try TLS. It's rare, but it is still possible for routers to determine that traffic on port 7000 is SIP traffic using deep packet analysis. TLS necessarily means TCP is being used. So it's sort of the nuclear option to make sure that there aren't any network config issue.

If there's STILL a problem, I'll break out a network monitoring tool like PingPlotter to monitor the connection for packet loss/jitter. There are a few other tools that'll do this well too like Solarwinds NPM, MTR and a cool secret tool we are testing right now. (stay tuned on that one)

There has been only ONE time that this procedure hasn't resolved the clients' issue without there being some major issue that was affecting large swaths of clients on a cluster. And that was a ticket from @Karl Stallknecht. I honestly can't remember what came of it though. Maybe he'll share? Think maybe it was an edge case in the code?

[Karl Stallknecht]

8 hours ago, Rick said:

There has been only ONE time that this procedure hasn't resolved the clients' issue without there being some major issue that was affecting large swaths of clients on a cluster. And that was a ticket from @Karl Stallknecht. I honestly can't remember what came of it though. Maybe he'll share? Think maybe it was an edge case in the code?

My memory is a little fuzzy here, but I think the issue ended up being the client's POS (point of sale) terminals wrecking havoc on the network. Maybe I'm recalling something completely different though...? lol

Also, I did see another ticket where there was an issue with default config issued by provisioner. Random phones were ringing, but it turned out to be an issue where phones with BLF keys monitoring other phones were ringing even though the call was not being directed towards them. @Rick Guytonthought it was an issue with NAT (assuming the phones actually HAD been receiving calls) and thus asked us to switch to TLS, when it was actually just an issue with the appearance/sound of the phones ringing, triggered by other phones.

 

@Rick Guyton are BLF and custom ring tones still broken with TLS?

[Rick]

Oh! Yea! The Poly had a weird config option on it where it played a ring tone when the BLF lit. So we thought the phone was ringing when it wasn't supposed to, but really it was just playing a ringtone when the BLF lit. And TLS fixed the issue, but only because it broke BLF. That was crazy! Made it seem for sure like LAN issues, but defiantly wasn't. It's in an old T(w)IL actually lol. I thought your BLF with TLS thing got resolved, can't find the old ticket though. That still a thing for you? I can go dig it out if so.