We have SoundPoint IP 330 phones for quite a few years and we have migrated from an internal SIP-PBX to an external SIP-PBX from a provider. The connection to the SIP server now goes via a NAT firewall. We are using TCPOnly as the SIP transport and we have enabled NAT keepalive so tha the TCP connection remains open. We also use a short registration expiration time (180 seconds) so that recovery from network problems is not that long.
Calls work fine but whenever the TCP connection goes "dead" it takes about 10 minutes for the phone to drop the dead TCP connection and open a new one and re-register.
The phones are running firmware 3.3.5 (latest available for that model).
What I mean by "dead" TCP connection is when the packets sent by the phone receive no response at all. I have captured the network packets and analyzed them with Wireshark and when the phone attempts to re-register it reuses the existing TCP connection to the SIP server. When it receives no response (at the TCP level, no ACK) it resends the TCP data for about 10 minutes within which it does 12 TCP retransmissions. After this it closes the TCP connection (sends a last packet with the RST flag) and a few seconds later it initiates a new TCP connection and re-registers fine. Although the phone recovers the 10 minutes it takes for it to recover is rather long.
The "dead" TCP connections may occur when the NAT firewall restarts or when it does failover from one ISP to another.
Is there any setting that can be tweaked for the TCP connection to be dropped more quickly?
I have tried with the retryTimeOut, retryMaxCount, tcpFastFailover, reRegisterOn, failRegistrationOn and onlySignalWithRegistered settings but they do not seem to change anything. Note that we have a single SIP server.
welcome to the Polycom Community.
The IP330 was no longer sold after 12/31/2009 and the support for the IP 330 ended back in 12/31/2014
Newer phones support the tcpIpApp.keepalive.tcp.noResponseTransmitInterval parameter but your old SPIP 330 does not.
Maybe time to invest in some currently supported phones as these phones are at least 8 or more years old.
Polycom Global Services
Many thanks for your reply. Looking at the Administrator's guide for 3.3.0 the tcpIpApp.keepalive.tcp.idleTransmitInterval and tcpIpApp.keepalive.tcp.noResponseTransmitInterval settings are there, but apparently they only apply to the TLS transport and not pure TCP (controlled by the tcpIpApp.keepalive.tcp.sip.tls.enable setting).
Why is that this is only available for TLS? Any way it can be enabled for pure TCP?
I must say that the 330s works for our needs (except for this issue) and that if we had to renew our equipement we would probably not purchase phones from Polycom as they are not truly supported by our VoIP provider and they do not provide an easy way to provision Polycom.
like I said your phones are well out of warranty (by multiple years) and you are out of support and there is no further development on this end of life phones.
Polycom Global Services
My suggestion would be to switch to UDP instead of TCP.
TCP support was not very mature when these phones were in their heyday, and has been improved a lot since then, even though people using TCP as their primary transport for SIP is still only a small percentage.
Another option is to implement a firewall that allows you to tune the connection tracking, eg pfSense, which you could set to the "aggressive" NAT mode:
aggressive – this expires idle connections more quickly. It makes more efficient use of CPU and memory but can drop legitimate connections. This is best used with low-latency connections.
This may cause the connections to be forcefully reset by the pfSense firewall, which the phones may react to by receiving the RST packet, and restart their communications more quickly.
Thanks for the suggestion, but we switched from UDP to TCP to avoid worse problems in the case of ISP failover, so that is not really an option.
Luckily ISP failover or firewall restart is a rare event, so even if it takes 10 minutes (or a manual phone restart) to recover phone service it is not that bad.
I will check with the firewall manufacturer to see if it can be configured to send back RST packets when it receives packets for unknown connections (e.g., after a restart).