This past week I’ve upgraded a client from version 1.2.1 to 1.4.20 (from source on a 9x version of SuSE) I’ve got Humpty Dumpty glued back together except for a strange flavor of the the “Failed to authenticate user” error. I’ve scoured about every reference to the error that I can find on both the UG’s and Google to no avail. There are quit a few references to the error, but nothing that matches all the data points of my problem…
Topology: Asterisk (“pbx”) is on a public IP. It has ~40 line assignments spread across ~12 physical clients. The client devices range from Polycom 500’s to Grandstream ATA’s and base units, as well as some soft phones for Road Warrior-ing. The majority of the phones are on a “typical” intranet behind an exposed router.
This may sound strange at first, but bear with me: I’ve “looped back” a connection from the Intranet (LAN) into a secondary NIC on the PBX server. It has the requisite routing table entries and works like a charm. As far as Asterisk is concerned the LAN resources are not NAT’d. “Reinvite” is not allowed on any of the devices, so Asterisk is unknowingly working as a bridge. (Before this raises any red flags, be aware that I’ve run/tested the server both WITH and WITHOUT the “LoopBack cable” and get identical Errors in both cases – even after making the expected nat-related parameter changes in the config files.)
So, here we are:
incoming calls DO work
outgoing calls DO work
extension-to-extension calls work SOMETIMES:
1) origination from a soft phone (SJ for example) WORKS
2) originated by dialing the ext followed by send WORKS
3) originated by picking up the handset and then dialing DOES NOT work
***A couple of threads claim this latter is a Polycom issue. it might be, however the same thing also happens when using the Grandstreams. The ATA devices and Softphones have only one dialing “mode” so I can’t really draw too many conclusions on their role.
attended transfers DO NOT work
blind transfers DO work
(my personal favorite) calls can transferred into and out of the Parking Lot without any problems
All failures listed above produce a FAST-BUSY after triggering an error of the same type:
[Jun 2 12:26:01] NOTICE: chan_sip.c:13969 handle_request_invite:
Failed to authenticate user "Air Works Sales"
±------LAN IP assignment for the “LoopBack” cable
If I disconnect my LoopBack cable and make the appropriate NAT changes in sip.cfg, the IP designated above changes to reflect the public IP assigned to the LAN router.
limitonpeer = yes
register => << vonage credentials >>
callerid="The Air Works"
<< clipped road warrior/soft phone devices >>
for what it’s worth, here’s a sample from the dialplan:
exten => 101,1,Dial(SIP/101) ;Extension
exten => 201,1,Dial(SIP/201) ;Sales
exten => 301,1,Dial(SIP/301) ;Service
exten => 102,1,Dial(SIP/102) ;Extension
exten => 202,1,Dial(SIP/202) ;Sales
exten => 302,1,Dial(SIP/302) ;Service
exten => 103,1,Dial(SIP/103) ;Extension
exten => 203,1,Dial(SIP/203) ;Sales
exten => 303,1,Dial(SIP/303) ;Service
exten => 104,1,Dial(SIP/104) ;Extension
exten => 204,1,Dial(SIP/204) ;Sales
exten => 304,1,Dial(SIP/304) ;Service
each physical phone unit has three lines registered as a bundle:
x01 = primary line
x02 = sales line
x03 = service service
This strategy benefits the station+queue algorithms, but unless I’m missing something, I can’t see that it has any impact on producing the errors I’ve indicated.
In case it makes any different, I’m running the exact same configuration now as under 1.2.1 – and anything worked fine then. (taking into consideration the modifications due to deprecated features/settings between the two versions)
Anyone got any insights? Thanks in advance.