Avaya 1120E SIP Firmware not honoring configuration parameter.

[owen16]

I have 40 1120E phones here with the latest SIP firmware loaded. The manual documents the Device Configuration parameter 'REG_REFRESH_INTERVAL' that should cause the phone to re-register with the proxy after the configured time.

This parameter does indeed cause the suggested expire time in the REGISTER request to be the configured value, but it does not cause the phone to attempt to re-register at the configured time, even though the RFC3261-required expires parameter to the Contact: header is present with the REG_REFRESH_INTERVAL value.

I have packet traces showing a 200 Ok packet in reply to the 1120E's REGISTER request with an expires parameter in the Contact: header of 360 seconds, as configured in REG_REFRESH_INTERVAL, but the 1120E does not attempt to re-register at 360 seconds, as configured.

Also, if I ssh in to pdt and type prtcfg, the parameter name is changed, but the value is correct. The prtcfg pdt command lists this parameter as REG_REFRESH_TIMER instead of REG_REFRESH_INTERVAL. FWIW.

The SIP proxy I'm attempting to use is 3CX. 3CX is returning the RFC3261-compliant expires parameter in the Contact: header, but it is not returning an Expires: header in the 200 Ok response (which doesn't appear to be mandated by the RFC anyway, although Asterisk (at least the Asterisk 11 in the current FreePBX distribution) returns both the Expires: header and the expires parameter to the Contact: header). 3CX by default uses 1800 seconds as the maximum expires, but the 1120E's don't re-register within that 1800 seconds, even if I set REG_REFRESH_INTERVAL to 1800 seconds (or less, down to 300 seconds, which is the minimum allowed value for that parameter). The 1120E's do re-register after 20+ hours, honoring an 'expires' time of 86400 seconds (the REG_REFRESH_INTERVAL default) [UPDATE: note below, as I've found that this doesn't actually work]

Any advice on working around this issue, or advice on how to file a bug report with Avaya (as I consider this a bug, since 3CX works fine with lots of other phones, and it is sending back a strictly RFC3261-compliant response) is welcomed.

[owen16]

Update:

Even trying to work around the issue by setting the MAXEXPIRES parameter in 3CX doesn't help; the 1120E phones simply aren't re-registering at all, even after 86400 seconds, with 3CX. Now, I'll have to see if they attempt to re-register after a few hours; time will tell.

[owen16]

Update for SIP 4.4 firmware:

I have been testing the 4.4 firmware for this issue; while the initial registration times out, after a few hours of being online, the phone successfully re-registers and then stays registered properly. When I say a few hours, that can be 10 to 20 hours later, but never more than 24 hours.

Am looking at it more closely. Time to pull out the packet sniffer again....

[owen16]

Ok, some results, and some strange results at that. I set up a wireshark sniffer on a SPAN port on the Cisco 7609 to which the phone and the 3CX proxy are both connected. REG_REFRESH_INTERVAL is set to 28800 in users.dat. The 3CX proxy has a security feature to blacklist IP's that attempt to contact the proxy without first registering. I have not configured a backup/failover SIP proxy; only the 3CX box is configured. Following is a copy of what I posted to the 3CX forum:

Ok, a bit more info.

All seconds listed are relative to the bootup of the phone.

I see the 1120E doing the initial registration, with Expires set to 28800, and the 200 OK comes back with Expires=28800. I see SIP_PINGs going out every 60 seconds, with a 407 Proxy Auth Required returned back. REG_REFRESH_INTERVAL is set to 28,800 seconds. After 16,000 seconds, I see a TFTP refresh of the configuration (I don't see a DHCP exchange at that time). I do not see a REGISTER after 28,800 seconds, but SIP_PINGS are continuing, with the 407 reply.

After 60,150 seconds, the 3CX box replies to the SIP_PINGS a 403; after this, the SIP_PINGS go unanswered until 60,300 seconds, at which point the phone tries to connect to the second proxy (which doesn't exist, and it actually is attempting, through SRV DNS requests, to find sip:domain.tld, but in my case this points to our e-mail server, which causes the phone to fail back, as there are no SIP services on the e-mail server. It tries to REGISTER with the second server for about a minute and a half, at which point it REGISTERS with the 3CX box again (but can't, because it's still blacklisted). It fails over to the domain.tld server again, which still can't register, and repeats this process another twelve times, finally reconnecting to the 3CX box at 61,950 seconds. At this point it re-registers, again with an Expires of 28800.

At 86400 seconds, it does the DHCP refresh and ACK.

At 90,770 seconds, the 1120E does indeed attempt a REGISTER, 30 seconds shy of the expiry of REG_REFRESH_INTERVAL, and it is successful.

At 111,450 or so the 3CX box again either blacklists the 1120E or the 3CX proxy has rebooted (I have it set to pull updates and restart early Sunday morning, and this would be the time in the capture, and I don't see a 403 Forbidden like I do the first time). It tries the failover again to the mail server, but only once, as on the second attempt to contact the 3CX box, it registers successfully, at 111,669 seconds, again with a 28800 Expires.

At 129,619 the DHCP request/ack handshake occurs again.

At 140,438 the 1120E again REGISTERs successfully with 3CX (again, about 30 seconds before the 28800 second Expires).

At 169,208 the 1120E again REGISTERs successfully with 3CX (28769 seconds after the previous).

DHCP is refreshed at 172,800, just as expected.

TFTP is refreshed at 188,958 seconds, the first time since 16,000.

And, finally, at 197,977 seconds (28769 seconds after doing so before) the 1120E REGISTERs once again to the 3CX proxy.

If I had set the REG_REFRESH_INTERVAL to 1800 seconds I think it would then reregister after 1770 seconds, after the first time of getting blacklisted and attempting to failover. I haven't tested that, but I do plan to perhaps this coming weekend.

I'll also look at the blacklist parameters in 3CX and see if tuning on those might trigger the failover sooner.

So, in a nutshell:
1.) The 1120E does the initial REGISTER with an Expires set to REG_REFRESH_INTERVAL
2.) After REG_REFRESH_INTERVAL seconds, the phone does not re-REGISTER but continues to SIP_PING
3.) After the 3CX blacklist time is triggered by the SIP_PINGS after the phone goes unregistered in 3CX, the phone attempts a failover.
4.) After the 3CX blacklist times out (I assume) the phone will re-REGISTER with 3CX, again with an Expires set to REG_REFRESH_INTERVAL.
5.) The phone now properly refreshes the REGISTER every (REG_REFRESH_INTERVAL-30) seconds, give or take a second.

Whew.

[owen16]

Update:

In the 3CX System/Security/Anti-hacking setup:
1.) "Failed Challenge Requests (407)" is set to 28. (times)
2.) "Blacklist time interval" is set to 180. (seconds)
Everything else is default.

In the 1120E config:
REG_REFRESH_INTERVAL 1500
REGISTER_RETRY_TIME 30
REGISTER_RETRY_MAXTIME 1800
SIP_PING YES

These settings bring the amount of time the phone is unregistered down to seven minutes, 25 minutes after initial bootup. After 32 minutes, the phone re-registers and then works as it should.