Hi all,
We have been running fine for a very long time with a system using Centos 5, Asterisk 1.6 and FreePBX 2 … and then the disk on the machine quite literally reached end of life. At that point I decided it would probably be in our best interest to move to the latest version rather than trying to resurrect the old system.
So now we are running Centos 6.4, Asterisk 11 and FreePBX 2.11. This seems to be running mostly OK but some of the phones don’t seem to register. Our phones are a hodge podge primarily of old Linksys phones, some Cisco 7940’s and a single Digium D40. I have recovered the phone config files from the old disk and restored them to the TFTP server directory on the new machine and set up FTP just for the D40. They are all fetching their configs ok but the 7940’s don’t want to register. The phones don’t report any errors in parsing the config files and I have checked the passwords in the config and in FreePBX and all is good. I have even tried manually modifying the SIP config on a couple of the phones to enter the password but it is still no-go (the phone shows the disconnected ‘x’ for the extensions and a Wireshark trace shows an authentication failure).
How can I diagnose what the issue is? Do the Cisco 7940’s require some different configuration somehow? I am using a standard SIP extension in FreePBX with 30 character passwords (I think the Cisco’s are limited to 31 chars) and I have tried them with simple 8 character passwords as well to no avail.
Any wisdom would be gratefully accepted !
M
For starters you need to start debugging on SIP side. Do a “sip set debug on” in Asterisk CLI and try to register a Cisco phone. Copy/paste the output of the command here.
Hi,
I tried setting debug on for SIP in the Asterisk console and it does produce output (lots of it). The net is that for each extension that is not registering I see something like the following. I have checked that the extension and password are correct in the phone config and in Asterisk (via FreePBX). Is it possible to tell from the SIP messages the reason why it is seeing the Unauthorized response?
Many thanks, M
[code]<------------->
— (10 headers 0 lines) —
Really destroying SIP dialog ‘651f15f75b0c230870b93c8e596616b3@192.168.1.21:5060’ Method: OPTIONS
<— SIP read from UDP:192.168.1.252:53246 —>
REGISTER sip:192.168.1.21 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.252:5060;branch=z9hG4bK061fe14f
From: sip:3304@192.168.1.21;tag=000dbc4cca0755387d8606bd-6f9b2fe8
To: sip:3304@192.168.1.21
Call-ID: 000dbc4c-ca070003-76c34deb-3999ad32@192.168.1.252
Max-Forwards: 70
Date: Thu, 18 Apr 2013 14:40:02 GMT
CSeq: 11007 REGISTER
User-Agent: Cisco-CP7940G/8.0
Contact: sip:3304@192.168.1.252:5060;transport=udp;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000 dbc4cca07>";+u.sip!model.ccm.cisco.com="8"
Content-Length: 0
Expires: 3600
<------------->
— (12 headers 0 lines) —
Sending to 192.168.1.252:53246 (NAT)
<— Transmitting (NAT) to 192.168.1.252:53246 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.252:5060;branch=z9hG4bK061fe14f;received=192.168.1.252;rport=53246
From: sip:3304@192.168.1.21;tag=000dbc4cca0755387d8606bd-6f9b2fe8
To: sip:3304@192.168.1.21;tag=as65f84c28
Call-ID: 000dbc4c-ca070003-76c34deb-3999ad32@192.168.1.252
CSeq: 11007 REGISTER
Server: FPBX2.11.0beta1(11.3.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="502203c6"
Content-Length: 0[/code]
There is no Authorization header. This is normal. The phone should repeat with such a header. If it doesn’t, it suggests that it has no idea which password to use.
The standard sequence is:
Register, without authorisation.
401 saying how to authorise.
Register, with authorisation.
OK.
Well, quite by accident, I seem to have resolved this problem. And let me admit that I don’t really understand the implication of the change. In FreePBX there is a NAT setting that, by default, is was set to “Yes”. We are not large enough as to need more so the whole building is on the same subnet. In my tinkering to try and resolve this problem I changed the NAT setting to “No - RFC3581” as I reasoned that it was not necessary. Almost as soon as I had hit apply the phone I was testing with connected. The same change to the extension settings for the other 7940 allowed them to register as well. Now life is now grand again! Well, at least folks are not whinging at me any more about that problem 
Thank you david55 and dejanst for your help - your comments show me that I really need to spend some time and learn the underlying technology better and not rely on FreePBX so heavily.
M
Can you please re-do the debug with “NAT=no”? It would be interesting to see the change in SIP signalling.
Hi dejanst,
I have tried to gather this a couple of times for you but it seems that restarting one of the 7940’s just results in Asterisk reconnecting and carrying on. I’d probably have to restart Asterisk then reconnect the phone to get a complete sign-on trace and that would not go over well with the users now that they have their phones back
M.