Cisco 7960/7940 SIP fails to register (401/403)

Hi all, hoping for a pointer here as I have been looking at this for a few days and there is clearly something I either don’t know that is simple or something weird going on. Unless otherwise mentioned, everything is at defaults.

Basically, FreePBX 2.7.0, Asterisk 1.6.2.9 on Centos (5.5 I think - latest release with relevant updates.). Cisco 7960 and 7940 phones (a fair few of).

Basic setup, no NAT, no trunks or anything fancy, just playing really to get some knoweldge together and see how practical an open source call manager type solution actually is.

Problem - Cannot place calls, SIP registration fails with a 401 Unauthorised followed by a 403 Rejected. Any calls initiated appear to hit “from-external”.

TFTP is fine, image loads fine, configs load down fine just that SIP registration failing. Seemed to me to point to a cock up on my part with usernames/passwords but am on my fourth phone now and fourth extension and they are all behaving the same. Using latest firmware for the phones (8.12).

Assumed user stupidity so tried to remove myself from the setup by using the endpoint administrator module and the results are exactly the same. Examples below show one extension (1001) setup with a passwrod of bo11ocks (with 1s not ls, otherwise it would be rude).

Any assistance or pointers to the button that needs clicking or file that needs poking would be greatly appreciated.

Used an analyser to dig deeper into what was happening and I see:

SIP request from phone to Asterisk on port 5060 Request Register SIP
(Data sip:[email protected] (seems correct)
Server responds:
Status Trying
401 Unauthorised
SIP request from phone to Asterisk on port 5060 Request Register SIP
(Data sip:[email protected] (seems correct)
Server responds:
Status Trying
403 Forbidden (Bad auth)

Files (although I am doing everything via FreePBX)

SIPDefault.conf
image_version: “P0S3-8-12-00”

proxy1_address: “10.10.1.10”

proxy2_address: “xxx.xxx.xxx.xxx

proxy3_address: “xxx.xxx.xxx.xxx

proxy4_address: “xxx.xxx.xxx.xxx

Proxy Server Port

proxy1_port:“5060”

proxy2_port:“5060”

proxy3_port:“5060”

proxy4_port:“5060”

proxy_emergency: ""
proxy_emergency_port: "5060"
proxy_backup: ""
proxy_backup_port: "5060"
outbound_proxy: ""
outbound_proxy_port: “5060”

nat_enable: "0"
nat_address: ""
voip_control_port: "5060"
start_media_port: "16348"
end_media_port: "20134"
nat_received_processing: "1"
dyn_dns_addr_1: ""
dyn_dns_addr_2: ""
dyn_tftp_addr: "10.10.1.10"
tftp_cfg_dir: “./”

proxy_register: "1"
timer_register_expires: "120"
preferred_codec: "none"
tos_media: "5"
enable_vad: "0"
dial_template: "dialplan"
network_media_type: "auto"
autocomplete: "1"
telnet_level: “2”

cnf_join_enable: "1"
semi_attended_transfer: "0"
call_waiting: "1"
anonymous_call_block: "0"
callerid_blocking: "0"
dnd_control: “0”

dtmf_inband: "1"
dtmf_outofband: "avt"
dtmf_db_level: "3"
dtmf_avt_payload: "101"
timer_t1: "500"
timer_t2: "4000"
sip_retx: "10"
sip_invite_retx: "6"
timer_invite_expires: “180”

sntp_mode: "directedbroadcast"
sntp_server: "10.10.1.10"
time_zone: "CST"
time_format_24hr: "1"
dst_offset: "1"
dst_start_month: "April"
dst_start_day: ""
dst_start_day_of_week: "Sun"
dst_start_week_of_month: "1"
dst_start_time: "2"
dst_stop_month: "Nov"
dst_stop_day: "1"
dst_stop_day_of_week: "Sunday"
dst_stop_week_of_month: ""
dst_stop_time: "2"
dst_auto_adjust: “1”

messages_uri: “*97”

http_proxy_addr: ""
http_proxy_port: 80


SIP-mac-address-here-.conf (sorry saving my finger typing/cutpasting)

proxy1_address: “10.10.1.10”

line1_name: "1001"
line1_shortname: "Eldon 1001"
line1_displayname: "Eldon 1001"
line1_authname: "1001"
line1_password: “bo11ocks”

line2_name: ""
line2_shortname: ""
line2_displayname: ""
line2_authname: "UNPROVISIONED"
line2_password: “UNPROVISIONED”

proxy_emergency: ""
proxy_emergency_port: "5060"
proxy_backup: ""
proxy_backup_port: "5060"
outbound_proxy: ""
outbound_proxy_port: “5060”

nat_enable: "0"
nat_address: ""
voip_control_port: "5060"
start_media_port: "16348"
end_media_port: "20134"
nat_received_processing: “0”

phone_label: "Eldon 1001’s Phone "
time_zone: PST
services_url: ""
directory_url: ""
logo_url: “”

telnet_level: "2"
phone_prompt: "Cisco7960"
phone_password: ""
enable_vad: "0"
network_media_type: "auto"
user_info: phone

Ok, well got angry and reinstalled and we are different but not happy. Asterisk log enclosed. Note the calls seen as coming from-sip-external. no SIP registrations or anything when looking on console.

-- Executing [[email protected]:1] NoOp("SIP/10.10.1.10-00000006", "Received incoming SIP connection from unknown peer to 7777") in new stack
-- Executing [[email protected]:2] Set("SIP/10.10.1.10-00000006", "DID=7777") in new stack
-- Executing [[email protected]:3] Goto("SIP/10.10.1.10-00000006", "s,1") in new stack
-- Goto (from-sip-external,s,1)
-- Executing [[email protected]:1] GotoIf("SIP/10.10.1.10-00000006", "0?checklang:noanonymous") in new stack
-- Goto (from-sip-external,s,5)
-- Executing [[email protected]:5] Set("SIP/10.10.1.10-00000006", "TIMEOUT(absolute)=15") in new stack

Channel will hangup at 2010-07-02 14:57:45.125 BST.
– Executing [[email protected]:6] Answer(“SIP/10.10.1.10-00000006”, “”) in new stack
– Executing [[email protected]:7] Wait(“SIP/10.10.1.10-00000006”, “2”) in new stack
– Executing [[email protected]:8] Playback(“SIP/10.10.1.10-00000006”, “ss-noservice”) in new stack
– <SIP/10.10.1.10-00000006> Playing ‘ss-noservice.gsm’ (language ‘en’)
– Executing [[email protected]:9] PlayTones(“SIP/10.10.1.10-00000006”, “congestion”) in new stack
– Executing [[email protected]:10] Congestion(“SIP/10.10.1.10-00000006”, “5”) in new stack
== Spawn extension (from-sip-external, s, 10) exited non-zero on ‘SIP/10.10.1.10-00000006’
– Executing [[email protected]:1] Hangup(“SIP/10.10.1.10-00000006”, “”) in new stack
== Spawn extension (from-sip-external, h, 1) exited non-zero on ‘SIP/10.10.1.10-00000006’

The phones are not registering, do you have NAT in the extension set to never and qualify set to yes?

with cisco phones I have found NAT=no does not work. You have to use NAT=never. Don’t ask me why but I have blood on the floor on this issue.

NAT is set to “no” - I have changed to “never” and restarted with no effect.

Qualify - This was set to no but I have changed to “yes”, restarted and rebooted phones but to no effect (trace still shows as from SIP External). I am assuming this correlates to the proxy_register setting that is in the SIPDefault.cnf (set to 1)?

From a packet analyser I see the SIP registration attempt #1 returned with a 401 Unauthorized followed by a second attempt then a 403 Forbidden (Bad auth).

That seems to suggest password/username wrong but I have redone that so many times I’m pretty confident they are not. Username here is 4002 (ext. no) and password is simple enough. I’m assuming that the format of “4002” is fine. Checking the phone(s) they have received this config and are trying to auth (with 4002 or 4001 as appropriate) but failing (403).

The other bit I am not sure about is:
In the extension there is a deny/permit line. I have left these as defaults (both set to 0.0.0.0/0.0.0.0 so I am assuming that permit any network/subnet is the default.

Any pointers would be wicked - doing my head in as it is so close yet so far…

I will confirm that NAT=no does work (I have all my Cisco phones set with nat=no and qualify=no, and they range from a 7960 to a 7945 and Communicator).

If you haven’t already been and checked it out, i put together a very lengthly document on setting up these phones with asterisk. http://minded.ca/2009-12-16/configure-cisco-ip-phones-with-asterisk/

on another note, I seem to remember trying Asterisk 1.6 a few months back and ditched it as it was a pain to make everything work properly. I have my suspicions that something that Cisco adds to its packet headers are the cause. Things are stable and work well in 1.4 so I haven’t had the need to find out either. It sounds like you’ve done everything properly and checked what should be checked so far. It might be worth it to try them on an asterisk 1.4 server if its an option, just to verify.

hope some of that helps.

Have you reset the phone to factory defaults and see if it loads everything OK?

Ok people, thanks for all your advice. 99% of it didn’t have any effect at all but the one little glimmer of hope that shone through and made it all suddenly work was:

Deinstall FreePBX (yum remove freepbx)
Deinstall asterisk16 (yum remove asterisk16)
Deinstall asterisk16-core (yum remove asterisk16-core)
Install asterisk 1.4 (yum install astersik14)
Install freepbx (yum install frepbx)

all phones then sprung into life immediately with no changes. So it’s something in Asterisk 1.6 that stops Cisco phones working. Doesn’t matter to me - I’m just playing but worth noting to others…

Thanks again.

That sucks, I have the exact same issue and I only upgraded to be able to use Google voice. I guess I will have to do without it and move on back :slight_smile:

Followed the above information and my build is back and working… Thanks for the advice.

Sorry I was late in responding to this.

For Asterisk 1.6 and 1.8 support on the 7940 and 7960 add the following to SIPDefault.cnf:

Default is 0.

Any of the XML based phones line the 7941 and 61 work in the later versions without issue.

Hi, I been working on this issue for a cupple days and was asked for the versions and more information, think im ready now
after upgrading Asterisk 1.6.2.11 to Asterisk 1.6.2.18 cisco 7940 phones (Firmware P0S3-08-9-00) are unable to register with error SIP/2.0 401 Unauthorized, raw logs ( http://pastebin.com/Z9iw9QRy )
the config files remain the same, phone config remains the same, only think that was changed was upgrading asterisk —> ( http://pastebin.com/67YM31eM )
my sample sip_additional.conf ( http://pastebin.com/ah4c87Bu ) i have tried uninstalling asterisk and installing asterisk 1.4 but the problem remained, a fresh install of asterisknow/freepbx has worked until the system yum updates
i guess my question is , is there any changes to sip or the registration from these too versions? are there any workarounds or patches? Any help is greatly appreciated
http://www.cyfordtechnologies.com/

I had this issue occur about 5 weeks ago, where the Cisco 7940 stopped registering, but other brands would work OK. Tried everything (even built another server on a diff network, no luck). The 1.4.2 updates I got notice of today seems to have cured the issue (I hope I did not jinx myself).

Best of luck

So, I know this is an ooooold thread, but since it’s the first one that comes up when I google it, I want to post for others what helped me. I was getting red hot about my 7940G not working, it just stopped talking to asterisk. So after hours of frustration I tried something on a whim. I stopped fail2ban and instantly my 7940 sprang back to life. This is on asterisk 1.8. Hope this helps someone like me!

Was the phone on a different network as the server? Fail2ban should not listen on attached networks.

Hi,

I know this is an old thread, but I had the very same issue a couple of days ago
(updating Asterisk on my ubuntu home server).

The only way for me to solve the problem was to put siproxd (a SIP proxy software)
between my Cisco 7940 and Asterisk (version 1.8.10.1~dfsg-1ubuntu1).

Here are my changes to the default contents of /etc/siproxd.conf:

#####################################
# the proxy is running on the same host as the "outbound" asterisk
if_outbound = lo
host_outbound = 127.0.0.1
# this is my internal subnet (Asterisk and the Cisco 7940 live there)
hosts_allow_reg = 192.168.88.0/24
# we cannot use the default port, it is already taken by Asterisk
sip_listen_port = 5061
# this password must be supplied by the Cisco phone
# it is also set as password in Asterisk's /etc/asterisk/sip.conf
proxy_auth_passwd = verysecretpassword
# forward everything to the Asterisk instance
outbound_proxy_host = myasteriskserverhostname (maybe even "localhost" works)
outbound_proxy_port = 5060
#####################################

Then, I changed the configuration of the Cisco 7940 to connect to
port 5061 instead of 5060 and everything worked.

Hope that helped,

J. Uhrmann