Failed to authenticate on INVITE

I have a SIP provider who I am working with that I am struggling to get working. I have two other SIP providers added with trunks that work just fine. The specific error in the full log is:
NOTICE[2359][C-00002424] chan_sip.c: Failed to authenticate on INVITE to '<sip:303XXXXXXX@xyzdotorg>;tag=as76f6743e'

My truck PEER settings are:

username=303XXXXXXX
type=peer
trunkstyle=voip
secret=xxxsecretxxx
registersip=yes
registeriax=no
realm=xyzdotorg
qualify=yes
outboundproxy=*
insecure=port,invite
host=xyzdotorg
hassip=yes
hasiax=no
hasexten=no
fromuser=303XXXXXXX
fromdomain=xyzdotorg
disallow=all
authuser=303XXXXXXX
authname=303XXXXXXX
allow=ulaw,alaw,gsm,g726

with a registration string of:

303XXXXXXX:xxxsecretxxx@xyzdotorg

A sip show peers shows the trunk as reachable. A sip show registry shows the truck registered. I have one outbound route with a simple dial plan to catch and route calls to this trunk and this trunk alone. However all calls fail with the above error.

Any advice would be greatly appreciated.
Thank you.
FB

Basically this peer has a bunch of invalid/bad settings and outdated settings that have been changed over the years. You’re also missing a context= option that will tell inbound calls where to go.

You should clean up this peer, have a proper context and try again.

Follow up edit:

PEERs do not REGISTER they auth/validate based on IPs. So you having a REGISTER string is pointless, it doesn’t use it or care about it. You need type=friend if you’re going to register.

1 Like

Thanks for the reply.

I have cleaned up the PEER details as noted (the outboundproxy does have an IP - I forgot to change it while I was obfuscating the details.) However, even after the clean up its still the same error. It is now configured as:

defaultuser=303XXXXXXX
type=peer
secret=xxsecretxxx
qualify=yes
outboundproxy=IPADDY
insecure=port,invite
host=xyzdotorg
fromuser=303XXXXXXX
fromdomain=xyzdotorg
disallow=all
authuser=303XXXXXXX
allow=ulaw,alaw,gsm,g726
context=from-trunk

I should have mentioned that the PEER details I was using came from an old configuration with the same provider we had setup back in 2013. I did however try configuring the trunk with minimal settings similar to our other provider and still had the same issue which was very similar to what is configured now (above).

I added a context=from-trunk and still the same error. However, we are only setting this trunk up for outbound calls so would that actually affect the ability to call out? Or receive the Failed to authenticate on INVITE error?

Without the REGISTER string, regardless of type=peer or type=friend, a sip show registry does not show as registered, but with the REGISTER string it shows as registered with either type. Also, I still receive the same error "Failed to authenticate on INVITE’ when attempting an outbound call regardless of combination.

How about from the provider’s side, what could be causing this? I have them working with me and they are aware of this thread, but they claim to be stumped as well. Any suggestions for them?

Try allowing only ulaw as a codec, it’s possible that ones provider doesn’t support cause them to reject.

At the Asterisk console, type
sip set debug on
and make an outbound call attempt. There may be clues in the request or response SIP headers that show what’s wrong. Post the result here (after partially masking numbers, etc.)

My suspicion is that the provider is fussy about the format of caller ID or destination number and is rejecting the call, but instead of returning the proper error code they are sending 401 UnAuthorized or 403 Forbidden.

How was this setup with the provider? Do they require a Registration? Because Registration tells the provider where to send calls to i.e. your PBX. So are they expecting you to make outbound calls and auth by IP or do they want a username and password for outbound calls?

The following is a snippet while sip set debug on was turned on from the area most likely responsible for the issue. The server is in a production environment with 80+ extensions so catching sip debug info is pretty difficult.

[2019-01-18 14:35:55] VERBOSE[22081][C-0000361b] chan_sip.c: Reliably Transmitting (NAT) to 64.X.X.X:5060:
INVITE sip:3XXXXXXXX7@xyzdotorg SIP/2.0
Via: SIP/2.0/UDP 63.X.X.X:5060;branch=z9hG4bK78ebd811;rport
Max-Forwards: 70
From: <sip:303XXXXXXX@xyzdotorg>;tag=as4c966f3e
To: <sip:3XXXXXXXX7@xyzdotorg>
Contact: <sip:[email protected]:5060>
Call-ID: 2f80765b1exxxf40000e86c90d07b219@xyzdotorg
CSeq: 105 INVITE
User-Agent: FPBX-14.0.5.25(13.22.0)
Date: Fri, 18 Jan 2019 21:35:55 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 256
v=0
o=root 1522980495 1522980495 IN IP4 63.X.X.X
s=Asterisk PBX 13.22.0
c=IN IP4 63.X.X.X
t=0 0
m=audio 10196 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

[2019-01-18 14:35:55] VERBOSE[22081][C-0000361b] app_dial.c: Called SIP/CNCSIP/3XXXXXXXX7
[2019-01-18 14:35:55] VERBOSE[2359] chan_sip.c:
<— SIP read from UDP:64.X.X.X:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 63.X.X.X:5060;received=63.X.X.X;branch=z9hG4bK78ebd811;rport=35217
From: <sip:303XXXXXXX@xyzdotorg>;tag=as4c966f3e
To: <sip:3XXXXXXXX7@xyzdotorg>
Call-ID: 2f80765b1exxxf40000e86c90d07b219@xyzdotorg
CSeq: 105 INVITE
<------------->
[2019-01-18 14:35:55] VERBOSE[2359] chan_sip.c: — (6 headers 0 lines) —
[2019-01-18 14:35:55] VERBOSE[2359] chan_sip.c:
<— SIP read from UDP:64.X.X.X:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 63.X.X.X:5060;received=63.X.X.X;branch=z9hG4bK78ebd811;rport=35217
From: <sip:303XXXXXXX@xyzdotorg>;tag=as4c966f3e
To: <sip:3XXXXXXXX7@xyzdotorg>;tag=172.25.238.2+1+735735+636083d3
Call-ID: 2f80765b1exxxf40000e86c90d07b219@xyzdotorg
CSeq: 105 INVITE
WWW-Authenticate: Digest realm=“172.25.238.2”,nonce=“678a6244cdd0”,stale=false,algorithm=MD5,qop=“auth”
Server: DC-SIP/2.0
Supported: resource-priority, siprec, 100rel
Content-Length: 0
<------------->
[2019-01-18 14:35:55] VERBOSE[2359] chan_sip.c: — (10 headers 0 lines) —
[2019-01-18 14:35:55] VERBOSE[2359][C-0000361b] chan_sip.c: Transmitting (NAT) to 64.X.X.X:5060:
ACK sip:3XXXXXXXX7@xyzdotorg SIP/2.0
Via: SIP/2.0/UDP 63.X.X.X:5060;branch=z9hG4bK78ebd811;rport
Max-Forwards: 70
From: <sip:303XXXXXXX@xyzdotorg>;tag=as4c966f3e
To: <sip:3XXXXXXXX7@xyzdotorg>;tag=172.25.238.2+1+735735+636083d3
Contact: <sip:[email protected]:5060>
Call-ID: 2f80765b1exxxf40000e86c90d07b219@xyzdotorg
CSeq: 105 ACK
User-Agent: FPBX-14.0.5.25(13.22.0)
Content-Length: 0

[2019-01-18 14:35:55] NOTICE[2359][C-0000361b] chan_sip.c: Failed to authenticate on INVITE to ‘<sip:303XXXXXXX@xyzdotorg>;tag=as4c966f3e’
[2019-01-18 14:35:55] VERBOSE[22081][C-0000361b] app_dial.c: SIP/CNCSIP-000040ab is circuit-busy
[2019-01-18 14:35:55] VERBOSE[22081][C-0000361b] app_dial.c: Everyone is busy/congested at this time (1:0/1/0)
[2019-01-18 14:35:55] VERBOSE[22081][C-0000361b] pbx.c: Executing [s@macro-dialout-trunk:24] NoOp(“SIP/420-000040aa”, “Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 21”) in new stack
[2019-01-18 14:35:55] VERBOSE[22081][C-0000361b] pbx.c: Executing [s@macro-dialout-trunk:25] GotoIf(“SIP/420-000040aa”, “1?continue,1:s-CONGESTION,1”) in new stack
[2019-01-18 14:35:55] VERBOSE[22081][C-0000361b] pbx_builtins.c: Goto (macro-dialout-trunk,continue,1)
[2019-01-18 14:35:55] VERBOSE[22081][C-0000361b] pbx.c: Executing [continue@macro-dialout-trunk:1] NoOp(“SIP/420-000040aa”, “TRUNK Dial failed due to CONGESTION HANGUPCAUSE: 21 - failing through to other trunks”) in new stack

I also have allow=ulaw as the only codec.

@BlazeStudios
How was this setup with the provider? Do they require a Registration? Because Registration tells the provider where to send calls to i.e. your PBX. So are they expecting you to make outbound calls and auth by IP or do they want a username and password for outbound calls?

I am not sure about this … I will contact them and see if I can get an answer to this.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.