Josh7,
Well, it looks as though your systems have not been receiving a good response from their registration attempts.
A144 Ext <eeeee> SIP Registration Failure (5000 Only)
FIELDS: eeeee The extension number of the SIP peer for which registration failed.
CAUSE: SIP registrations for the specified device have failed beyond provisioned failure threshold. This alarm is raised after registration is retried for the provisioned maximum number of times and registration is still not successful. This would stop further registration retries towards SIP peer.
ACTION: Correct any provisioning error for the SIP peer, or resolve any network or other issue that is causing the SIP Registrations to fail. In order to restart the registration process, an administrator can either change the operating state (INS -> OOS-Maint -> INS) or change any of the registration affecting database fields for this SIP peer. That would result in resetting the
registration process. However, the administrator would have to clear this alarm explicitly.
NOTE This is not an auto clearing alarm
So, have you verified that the SIP Trunks are down; I assume they are trunks due to the extension you provided 82003. If the trunks are up and working and the alarms is just there telling you that the system is having an problem getting registration then you have a few things to look at. Typically, in my experience, the issue is with the Firewall or the SIP Provider blocking or not accepting the traffic for one reason or another.
Are all of the sites connected to the same SIP Provider or using the same Firewall?
You can try to set the Registration attempts to a higher number for a quick band-aid, but that won't solve your problem. We had one SIP Provider that didn't like the Registration Interval that is used by default, but they didn't send any UPDATES with the interval they wanted; they just expected us to know this hidden piece of information. Once we made that change the problem just disappeared.
If it were me I would try to find the common denominator and figure out what is going on, but that takes time and effort on your part to do so. The only way that I can think of is to start a capture of the SIP logs and go over those to see what is going on. You may even have to go so far as to put a device out there to do a packet capture if you don't have an MBG in the mix already.
Thanks,
TE
