We have a Adtran Total Access 908, ADSL2+ (2nd Gen) Part Number: 4212908L4 configured with Verizon DSL line. We have the SIP trunk properly configured with SIP username and password, and the unit has been online the whole time.
When I look at the voice trunk registration page I see the following:
What I don't understand I why would I have some many failed and challenged registrations? We haven't changed the username/password or any other configuration data since the unit has been powered on, so I wonder what would cause a failed or challenged registration? I assume when it is failed that the voice would not work during that period? I believe the internet has been up the entire time as well.
In a client scenario the registration expiration time is set by the server by default. You can manipulate this in the trunk configuration by requesting a shorter expiration time. You don't want to get too aggressive with chatty traffic on a DSL link, nor do you want to overburden the SIP server with frequent requests.
In a proxy scenario with SIP phones on the inside you can do registration pacing on the TA900.
ip sip proxy register rate-adaption server-expires 3600
ip sip proxy register rate-adaption user-expires 60
ip sip proxy register rate-adaption threshold percentage 50
would cause the phones to register to the TA900 with an expiration of 60 seconds. The TA900 would register to the SIP server with an expiration of an hour. At half of this time the device would re-register.
On start-up or reboot nothing is registered. The phones, however, are tickling the inside of the TA900 every 30 seconds. When a phone registers for the first time the TA900 passes this through to the outside server, gets the challenge with nonce, passes it to the phone and passes the response to the server. The phone is now authenticated and registered, relatively quickly.
For the next half hour, the phone registers to the TA900 every 30 seconds. The TA900 just responds 200 OK locally without querying the server. After 30 minutes (50% of 3600 seconds) the TA900 passes the registration through and re-authenticates. Then it just locally OKs the phone for the next server expire time. The local register messages on the 100 Mbps LAN aren't an issue and the server doesn't get hammered with REGISTER messages. Good compromise between a quick up-time on reboot and not clobbering the server or WAN link with a lot of chatter.
Without rate pacing, if the phones are set to re-register every half hour and the TA900 reboots but the phones don't, then it can take a while for everything to get back in sync. The phones "think" they're registered, the server "thinks" they're registered, but the TA900 doesn't have state on the registrations.
Just wondering if you found the answer to this question, having similar issues
Fiberman,
Thanks for posting! The failed registrations indicate the unit did not receive a response to registrations or it was otherwise rejected. By default, our unit will attempt to re-register five minutes prior to expiration. Since our unit has enough time to attempt to register several times before the expiration, a few missed registration attempts is unlikely to cause any disruption in service.
If you would like to check for a problem, or just see exactly what is occurring, you can capture the output of "debug sip stack messages". This should show you the exact response the unit gets from the SIP registrar.
Thanks!
David
I think you are correct as I no longer have any more failed registrations.
Now I have another question. You say the unit will attempt to re-register five minutes prior to expiration, but how do you make the unit attempt to register on startup? For example I reboot the unit, the unit doesn't have internet access yet, so of course the registration to a internet sip register fails if it tries before the internet connection is established. Once the unit has internet the only way I know how to make them register is to go to voice, reports, and trunk registrations, check the box to select all, and the click Force-Register selected users.
I think the unit automatically does do this after a while, but is at least 5 minutes. Is there a setting you can change?
In a client scenario the registration expiration time is set by the server by default. You can manipulate this in the trunk configuration by requesting a shorter expiration time. You don't want to get too aggressive with chatty traffic on a DSL link, nor do you want to overburden the SIP server with frequent requests.
In a proxy scenario with SIP phones on the inside you can do registration pacing on the TA900.
ip sip proxy register rate-adaption server-expires 3600
ip sip proxy register rate-adaption user-expires 60
ip sip proxy register rate-adaption threshold percentage 50
would cause the phones to register to the TA900 with an expiration of 60 seconds. The TA900 would register to the SIP server with an expiration of an hour. At half of this time the device would re-register.
On start-up or reboot nothing is registered. The phones, however, are tickling the inside of the TA900 every 30 seconds. When a phone registers for the first time the TA900 passes this through to the outside server, gets the challenge with nonce, passes it to the phone and passes the response to the server. The phone is now authenticated and registered, relatively quickly.
For the next half hour, the phone registers to the TA900 every 30 seconds. The TA900 just responds 200 OK locally without querying the server. After 30 minutes (50% of 3600 seconds) the TA900 passes the registration through and re-authenticates. Then it just locally OKs the phone for the next server expire time. The local register messages on the 100 Mbps LAN aren't an issue and the server doesn't get hammered with REGISTER messages. Good compromise between a quick up-time on reboot and not clobbering the server or WAN link with a lot of chatter.
Without rate pacing, if the phones are set to re-register every half hour and the TA900 reboots but the phones don't, then it can take a while for everything to get back in sync. The phones "think" they're registered, the server "thinks" they're registered, but the TA900 doesn't have state on the registrations.