asterisk users - Mar 2005 - Broadvoice latest changes and still not working- An Additional Server

I have been going crazy with this also since Sat.

Our server was working perfectly with BV but will now not place calls 
to BV.

Incoming from BV works fine.

I felt sad rebooting it today, it had been running for almost 200 days!

Here is my error message from the console...

Notice I am running today's CVS

Connected to Asterisk CVS-03/08/05-14:32:39 currently running on com 
(pid = 1624)
     -- Executing Dial("SIP/6050-5bc9", 
"SIP/18475098263@sip.broadvoice.com|30") in new stack
     -- Called 18475098263@sip.broadvoice.com
Mar  8 23:11:55 NOTICE[15376]: chan_sip.c:5047 handle_response: Failed 
to authenticate on INVITE to '"6050" 
<sip:8475100139@sip.broadvoice.com>;tag=as20911f6e'

I have tried many versions of sip.conf, here is the current...

[sip.broadvoice.com]
type=peer
user=phone
host=sip.broadvoice.com
fromdomain=sip.broadvoice.com
fromuser=8475100139
secret=blah
username=8475100139
insecure=very
context=default
authname=8475100139
dtmfmode=inband
dtmf=inband
;Disable canreinvite if you are behind a NAT
canreinvite=no

I have tried the different proxies proxy.dca.broadvoice.com, lax, mia, 
and was originally using chi when the system worked.

BV told me Mon that chi is considered a test server that should not be 
used for production, it is expected to go up and down.

My hosts file points to one of the working ones.

I verified my account through a softphone. It works fine to BV.

There is something wrong with the authentication.

Here is the SIP debug...

     -- Executing Dial("SIP/6050-019c", 
"SIP/18475098263@sip.broadvoice.com|30") in new stack
We're at xxx.xxx.xxx.xxx port 16776
Answering with capability 2
Answering with capability 4
Answering with capability 8
12 headers, 10 lines
Reliably Transmitting:
INVITE sip:18475098263@sip.broadvoice.com SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK5364668c
From: "6050" <sip:8475100139@sip.broadvoice.com>;tag=as292b9469
To: <sip:18475098263@sip.broadvoice.com>
Contact: <sip:8475100139@xxx.xxx.xxx.xxx>
Call-ID: 5e81fefe69a768f969fd50f6000d4a39@xxx.xxx.xxx.xxx
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Wed, 09 Mar 2005 05:35:15 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 205

v=0
o=root 3501 3501 IN IP4 xxx.xxx.xxx.xxx
s=session
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio 16776 RTP/AVP 3 0 8
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
  (no NAT) to 147.135.8.128:5060
     -- Called 18475098263@sip.broadvoice.com
com*CLI>

Sip read:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK5364668c
From: "6050" <sip:8475100139@sip.broadvoice.com>;tag=as292b9469
To: <sip:18475098263@sip.broadvoice.com>
Call-ID: 5e81fefe69a768f969fd50f6000d4a39@xxx.xxx.xxx.xxx
CSeq: 102 INVITE


6 headers, 0 lines
com*CLI>

Sip read:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK5364668c
From: "6050" <sip:8475100139@sip.broadvoice.com>;tag=as292b9469
To: <sip:18475098263@sip.broadvoice.com>;tag=SD38ad399-
Call-ID: 5e81fefe69a768f969fd50f6000d4a39@xxx.xxx.xxx.xxx
CSeq: 102 INVITE
WWW-Authenticate: DIGEST 
realm="BroadWorks",algorithm=MD5,nonce="1110346372627"
Content-Length: 0


8 headers, 0 lines
Transmitting:
ACK sip:18475098263@sip.broadvoice.com SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK5364668c
From: "6050" <sip:8475100139@sip.broadvoice.com>;tag=as292b9469
To: <sip:18475098263@sip.broadvoice.com>;tag=SD38ad399-
Contact: <sip:8475100139@xxx.xxx.xxx.xxx>
Call-ID: 5e81fefe69a768f969fd50f6000d4a39@xxx.xxx.xxx.xxx
CSeq: 102 ACK
User-Agent: Asterisk PBX
Content-Length: 0

  (no NAT) to 147.135.8.128:5060
Mar  8 23:35:15 NOTICE[15376]: chan_sip.c:5047 handle_response: Failed 
to authenticate on INVITE to '"6050" 
<sip:8475100139@sip.broadvoice.com>;tag=as292b9469'


TIA

Chris

Chris,

first of all, if your server has been up for 200 days, I suggest you
update the kernel -- you don't say if it's Linux, but chances are that
yes... and there have been some security bugs patched recently.

That aside. I'm not sure, but it's possible that since you are using a
valid host name ('sip.broadvoice.com') in your dial statement, perhaps
* tried to talk to it directly and does not consider the section in
sip.conf. Just a guess. You will notice from the the sip debug output
that * does not even try to authenticate, as if it didn't know about
the user/secret.

I use the BV number as the section name, so the dial statement
essentially looks like: Dial(${EXTEN}@${BV_LINE})

Try changing yours to say "broadvoice" and then the corresponding
section in sip.conf. I'm using the DCA server, and didn't have an
issue at all when they introduced INVITE authentication on the
weekend. This is how my section looks like:

[360350XXXX]
type=peer
dtmfmode=inband
username=360350XXXX
fromuser=360350XXXX
secret=XXXXXXXXXX
host=sip.broadvoice.com
fromdomain=sip.broadvoice.com
canreinvite=no
nat=no
insecure=very
context=incoming
outgoinglimit=2

In /etc/hosts I have:
147.135.0.128           sip.broadvoice.com

It's the proxy.dca.broadvoice.com server. Hope this helps...

--Luki