1100-series with 3CX

[lowen]

Ok, I've been reading through lots of forums, and I thank those here for all the good stuff on converting 1100-series to SIP, etc.

But I'm running into a really stubborn issue with using some 1120SA (1120E with some interesting modifications, but runs 1120E firmware) phones with 3CX.  Now, back in https://forums.networkinfrastructure.info/nortel-ip-telephony/some-1140e-(sip-version)-questions/  mention was made of re-registering every 30 minutes; but no resolution was posted, so not sure if that poster ever got it working or not.

I've upgraded to the latest SIP 4.3 service pack firmware, and have the recommended settings in 1120eSIP.cfg and users.dat as included from 1120eSIP.cfg.  I've also set up automatic login with the SIP[MAC].cfg file with the correct MAC address, and I don't see the 'evaluation license' issue since I'm using the posted users.dat file section that's been posted on here several times.

After 30 minutes, the 1120's are unregistering themselves from 3CX.  Further, 3CX is logging, after several hours, that an IP is being blacklisted because of too many authentication failures; that IP invariably turns out to be an 1120 phone.

I've set up the 3CX box's firewall to allow pings, thinking that maybe SIP_PING failure was at fault, but that didn't help.  I then disabled SIP_PING, and that didn't help.

I can make the unregister happen sooner by setting REG_REFRESH_INTERVAL to something less than 1800 seconds, but setting it to 86400 seconds (the default) doesn't make it take 24 hours to unregister, it still happens after 30 minutes.  (oddly enough, a prtcfg shows that parameter as REG_REFRESH_TIMER instead of REG_REFRESH_INTERVAL.....).  It does re-register after several hours (probably the DHCP lease renewal time), but then unregisters again after 30 minutes.

I haven't yet hooked up a wireshark to see what's transpiring on the wire, and that is on my list of things to do to work on this.  But the 3CX activity log indicates that the phone is actively unregistering itself.

I was hoping the OP of https://forums.networkinfrastructure.info/nortel-ip-telephony/some-1140e-(sip-version)-questions/  could report back as to the resolution, but that's been quite a while back and they may not monitor this forum.....

Any ideas would be good, including firmware downgrade, which is also one of the items on my list of things to try.

Thanks in advance.

UPDATES

Downgrading to SIP FW 2.2 didn't help.  Downgrading to 3.2 doesn't help, either.

Now, I temporaried a FreePBX install; the 1120SA's with SIP FW 4.3.18 seem to work just fine with FreePBX.  For what it's worth, they now show the date and time with FreePBX, whereas they didn't with 3CX.

Also, the OP of the thread I referenced above, leejor, is corresponding with me on this issue on the 3CX forums.  If and when we come up with a solution I'll post here for the sake of the archives......

[lowen]

Ok, I have an update on this, after performing multiple long-term packet traces.

In essence, the 1120E SIP firmware is not honoring REG_REFRESH_INTERVAL, nor is it honoring a 200 Ok response that has the RFC3261-mandated expires parameter to the Contact: header but does not have a separate Expires: header.

3CX is returning 200 Ok to the authenticated REGISTER request without the Expires: header but with the expires parameter of the Contact: header.  The expires parameter to the Contact: header is required by the RFC, but the Expires: header is not, even though it's used in the registration example in the RFC text.

FreePBX (Asterisk 11 under the hood, but the FreePBX distribution is what I tested with) is returning a 200 Ok with both the expires parameter to the Contact: header and the separate Expires: header, and the 1120E SIP firmware is honoring that expires value and is properly re-registering at that interval (FreePBX sends back 3600 seconds).

REG_REFRESH_INTERVAL does cause the 1120E SIP firmware to set the expiry in the REGISTER requests, but it does not cause the phone to re-register after that amount of time; in my testing with 3CX, I have a packet trace of over 73000 seconds where the phone, set with REG_REFRESH_INTERVAL to 360 seconds, does not send any more REGISTER requests after the initial registration(although it should do so prior to 86400 seconds, it did not do so within 73000 seconds). 

3CX correctly expires the registration after the configured time, or 3CX's MAXEXPIRES time, whichever is less.  MAXEXPIRES is 1800 seconds by default.  A kludgey workaround is to set MAXEXPIRES to over 86400 seconds; this seems to work in initial testing, but if the 3CX box needs to be restarted it could be up to 24 hours before all phones re-register to it.  (Although setting SIP_PING to YES might cause that to not be the case; I haven't tried that yet; it takes a long time to do multiple sets of tests when the tests are 86400 seconds in duration!).  Oh, and our Cisco 7960's are just fine with the 3CX registration response lacking the Expires: header.

Anyway, this is what I've found thus far.

 In my opinion, both 3CX and Avaya should make some changes: 3CX by adding the Expires: header with the correct value (even though it's not strictly required by the SIP standards, it is used in the example registration handshake in said standards), and Avaya by both honoring the expires parameter to the Contact: header even in the absence of a separate Expires: header, since that is the strict reading of RFC3261, and by honoring the specifically set REG_REFRESH_INTERVAL, actually doing the re-register when told to do so by the explicit configuration setting. 

[Michael McNamara]

Welcome to the forums @lowen and thanks for sharing your findings!

[lowen]

You're quite welcome.

An update for 4.4 SIP firmware.

With the 4.4 firmware, the phone will initially register, and then won't try again after REG_REFRESH_INTERVAL seconds.  However, after a few hours (I've seen 10 to 20 hours at this point) the phone does re-register, and then it successfully stays registered.  I have not had opportunity to put the sniffer on one with 4.4 as yet, but plan on doing so.  This is with the 3CX configuration parameter for maximum registration length set to 86400 seconds, incidentally.

[Michael McNamara]

I'm guessing you'll see the problem in the packet trace with a SIP decode... it's always fun reading those traces - NOT!

[lowen]

Yes, you are correct.  I've posted a more detailed analysis in the 3CX forums.

(I'd post it as an external link, but I haven't hit 10 posts yet...... just go to the 3CX forums and search for "Avaya (Nortel) 1100-series SIP phone unregister issue.")

It's fairly long, but the end result is, if I set:
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

I get the following timing, as related by the server activity log:
11-Jan-2014 15:08:45.089   [CM504001]: Endpoint Extn:851: new contact is registered. Contact(s): [sip:851@192.168.1.117:5061 / 851]
11-Jan-2014 15:06:06.852   [IPBL] Packet from banned IP/range: ip = 192.168.1.117; Comment: PBX: blocked for too many failed authentications
11-Jan-2014 15:05:06.753   Blacklisted (Too many failed auth)
IP = 192.168.1.117; Failed auth: 0; unauth: 0; auth: 0; 407: 28
11-Jan-2014 15:01:21.053   [CM504002]: Endpoint Extn:851: a contact is unregistered. Contact(s): []
11-Jan-2014 14:36:03.820   [CM504001]: Endpoint Extn:851: new contact is registered. Contact(s): [sip:851@192.168.1.117:5060 / 851]

And this produces a period of seven minutes or so, starting 1500 seconds after the initial registration, where the phone is unregistered.  After the phone successfully re-registers, it then properly honors REG_REFRESH_INTERVAL and re-registers at 1500 second intervals, as verified by a pair of 24-hour packet traces. 

I'll say this; I've learned a lot in the last while debugging this, and I hope by sharing with the  group here that others can begin using these solid phones with 3CX.