Phone regsitration failures

I'm having a few problems with phones failing to register after a certain amount of time.

All of the phones are on remote networks behind NAT talking to a server on a public IP.

The phones in question are Aastra's and Linksys SPA92's.

They register fine on bootup, but after time, sometimes several hours, registration fails. No attempts are logged at the server end when this happens. It seems to be broadband provider specific, in that these phones happen to be using BT broadband. That said, a cisco 79xx phone seems fine. I should add that the phones are located in multiple locations, in that I'm not simply talking about 1 specific broadband connection.

Anyone any clues?

regards

Had this on a Aastra 480. A restore and reinstall of the firmware seems to have stopped it

Hi
What is the register interval of the sets set to in the aastra.cfg and is qualify set? if so what to.
Are the aastras running the latest firmware ?

Ian

I have the same issue with 1 particular Linksys phone.
(SPA942). It registers and works ok and all of a sudden its
line buttons go orange.
The funny thing is that the server does not receive any
data from the phone so its either the provider playing
games with 5060 port traffic or the phone.....

I'll try a firmware upgrade and see what happens...
Reading the following from the Linksys page firmware
release notes gives a hint..

Quote:

Worked around this problem: some server will change the Contact header's address in their response to the SPA's SIP REGISTER request, so that the SPA cannot find the corresponding Contact in the response and therefore may not be able to extract the proper expires value inserted by the server. This is a problem if the expires value inserted by the server in the response is smaller than the value in the original SIP REGISTER request. The work around is to use the first entry in the Contact header if an exactly matching address is not found.

ianplain :

Hi What is the register interval of the sets set to in the aastra.cfg and is qualify set? if so what to. Are the aastras running the latest firmware ? Ian

The asterisk server forces the phones to register every 120 seconds,regardless of what they're set to. I've even gone down to 10 seconds, and while they last slightly longer, it's not great. Qualify=yes, and I've tried No, same results. All phones have lastest firmware. I've also done factory resets in case there were some bit's of conflicting configs. Still no joy.

The Linksys phones report that the registration failed. But when that happens I don't see any traffic at the server end, so it's really hard to debug. It's almost as if it's an MTU issue.

When the same phones are on a local network, they behave.

regards

Lambros :

I have the same issue with 1 particular Linksys phone. (SPA942). It registers and works ok and all of a sudden its line buttons go orange. The funny thing is that the server does not receive any data from the phone so its either the provider playing games with 5060 port traffic or the phone..... I'll try a firmware upgrade and see what happens... Reading the following from the Linksys page firmware release notes gives a hint.. Quote: Worked around this problem: some server will change the Contact header's address in their response to the SPA's SIP REGISTER request, so that the SPA cannot find the corresponding Contact in the response and therefore may not be able to extract the proper expires value inserted by the server. This is a problem if the expires value inserted by the server in the response is smaller than the value in the original SIP REGISTER request. The work around is to use the first entry in the Contact header if an exactly matching address is not found.

I've also tried this, I'm running the latest version of software, but I'm wondering if it's due to packet fragmentation.

The phone will very often go 'orange' the second a call terminates. Very strange.

regards

for the linksys phones, I did find this setup info

Quote:

STUN Support SIP > NAT Support Parameters Handle VIA received: yes Handle VIA rport: yes Insert VIA received: yes Insert VIA rport: yes Substitute VIA Addr: yes Send Resp To Src Port: yes STUN Enable: yes STUN Test Enable: yes STUN Server: any public STUN server NAT Keep Alive Intvl: 15 (can be increased after you are confident everything is configured properly) Line 1 > NAT Settings NAT Mapping Enable: yes NAT Keep Alive Enable: yes NAT Keep Alive Msg: $PING NAT Keep Alive Dest: $PROXY

Of note is the change from the default Keep Alive Msg from $Notify, to $PING


Still have an issue with the Aastra's of course. Going to try a factory reset to see if that helps

regards

Did that particular linksys setup improve things
at all ?

I don't have the Via or the Stun params set to yes
as i am doing static port forwarding. However,
all my NOTIFY messages arriving at the server fail as
they seem to originate from the internal ip.

If i do tick the Via it stops working completely.

The funny thing is that on another setup, with SPA941
phones remotely,
no Via, no Stun, (just the NAT Mapping and NAT
keepalive set to yes - using $NOTIFY, $PROXY), no static
port forwarding, yet no problems...

Puzzled.

Lambros :

Did that particular linksys setup improve things at all ? I don't have the Via or the Stun params set to yes as i am doing static port forwarding. However, all my NOTIFY messages arriving at the server fail as they seem to originate from the internal ip. If i do tick the Via it stops working completely. The funny thing is that on another setup, with SPA941 phones remotely, no Via, no Stun, (just the NAT Mapping and NAT keepalive set to yes - using $NOTIFY, $PROXY), no static port forwarding, yet no problems... Puzzled.

Don't know yet. I'm going to take it on-site Monday. Seems stable enough here though, but then again it always has.

regards

Update,

Well so far so good. A factory reset of the Aastra seemed to sort that phone out. My guess there were some old values from previous versions in there somewhere.

In addition, the Linksys phone now seems stable as well. Not sure which option did the trick, but heck it works that's the main thing

regards

middletn :

I'm having a few problems with phones failing to register after a certain amount of time. .... It seems to be broadband provider specific, in that these phones happen to be using BT broadband. .... I should add that the phones are located in multiple locations, in that I'm not simply talking about 1 specific broadband connection.

Did you have any long term joy with this? I have had one customer with this problem for a few days now, and looks like another one has just joined in. Both are long term customers who's phones have worked fine for months now.

The fragile common factor appears to be that they are both on BT Broadband and both have the same sort of router BT Voyager.

I have lots of other customers who dont have any problems with identical configuration to the same server.

Server is based on Asterisk 1.4.11 and Phones are Grandstream GXP2000.

Any suggestions for solving the problem would be appreciated.

These phones have been stable for the last 3 days. Long answer is don't use BT, but the modem/BB combo is definately a problem. I can't believe no one has picked on on this issue, that said, getting BT to do something about it would probably be a waste of time. Still now that this link is documented, you can steer customers away. My guess is that there's been an automatic update of the router software which has broken something.

regards

I am still experiencing the same issues with the
Linksys phones.
I have noted that whatever the registration interval,
(tried 60/180/300) the second registration always fails.

The phones have a short and long failed re-register attempt
interval. The short-timed attempt fails and the long ones
are a hit and miss.

I don't think its a provider issue. If i powercycle the phone
it registers straight away.

Some more info regarding the issue just in case anyone
is willing to take a look:
Using the same Linksys IP phone, i register one after
the other to 2 different servers running Asterisk 1.4.11.

With one server the re-register problem does not occur,
with the other it does. Register period: 60 secs

The reply from the server is a 401 unauthorised.

<--- Transmitting (NAT) to CLIENT_IP:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.104:5060;branch=z9hG4bK-11ffe214;received=CLIENT_IP
From: "username" <sip:8@SERVER_NAME>;tag=f447eae4f1a1a668o0
To: "username" <sip:8@SERVER_NAME>;tag=as7295f2dc
Call-ID: 9224c620-34aa24ca [!at] 192.168.0.104 (replace the [!at] with a @)
CSeq: 17975 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="0b4b3381", stale=true
Content-Length: 0

From looking at forums etc the key seems to be the
stale=true phrase. (it is also shown in the log as:

chan_sip.c: Correct auth, but based on stale nonce received from '"Nicosia" <sip:8@SERVER_IP>'
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="205c158f", stale=true

Also note that the * server sends some NOTIFY packets
which are answered after the 2nd attempt.

An obviously nasty hack, is to reduce the long
re-register interval in the phone to 1 second.
In that case the phone is not registered
for about 2 secs every 60.......
Alternatively, if i reduce the 60secs registration
period to 30secs things seem ok but i guess that
is also a nasty hack(?)

The routers at the asterisk sites
are different. SIP Ports are forwarded to the * machines
but there is no forwarding at the client site.

Any ideas anyone ?

TIA