Handle_response_invite: Failed to authenticate on INVITE to

I am facing the issue bellow and I have no clues to fix it.
I am trying to call the number 15998444557 from SIP 1532386920. Please, what is wrong on my configuration files?

MFC/R2 call offered on chan 2. ANI = 1532, DNIS = 02115998444557, Category = National Subscriber
[Jan 1 05:38:55] DEBUG[695]: chan_dahdi.c:4042 dahdi_r2_accept_call: Accepting MFC/R2 call with charge on chan 2

MFC/R2 call has been accepted on backward channel 2
– Executing [02115998444557@from-e1:1] NoOp(“DAHDI/2-1”, “”) in new stack
– Executing [02115998444557@from-e1:2] Dial(“DAHDI/2-1”, “SIP/02115998444557@User1”) in new stack
– Called SIP/02115998444557@User1

[Jan 1 05:38:56] NOTICE[692]: chan_sip.c:21095 handle_response_invite: Failed to authenticate on INVITE to ‘“1532” sip:1532@100.71.223.5:5080;tag=as086be738’
– SIP/User1-00000030 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
– Auto fallthrough, channel ‘DAHDI/2-1’ status is ‘CONGESTION’

[Jan 1 05:39:01] DEBUG[2300]: chan_dahdi.c:8325 dahdi_handle_event: bits changed in chan 2
MFC/R2 call disconnected on channel 2
[Jan 1 05:39:01] DEBUG[2300]: chan_dahdi.c:6632 dahdi_hangup: disconnecting MFC/R2 call on chan 2
[Jan 1 05:39:01] DEBUG[2300]: chan_dahdi.c:6284 dahdi_ast_cause_to_r2_cause: ast cause 16 resulted in openr2 cause 6/Normal Clearing
MFC/R2 call end on channel 2

-sh-4.0# cat extensions.conf
[general]
static=yes
writeprotect=no
autofallthrough=yes
clearglobalvars=no
priorityjumping=no

[globals]

[from-e1]
exten => _X.,1,Noop()
exten => _X.,n,Dial(SIP/${EXTEN}@User1)

[from-sip]
exten => _X.,1,Noop()
exten => _X.,n,Dial(DAHDI/r0/${EXTEN})

-sh-4.0# cat sip.conf
[general]
context=from-sip
disallow=all
allowguest=no
srvlookup=yes
bindaddr=0.0.0.0
engine=comcerto
t38pt_udptl=yes,redundancy
useragent=Aligera AG561
bindport=5080
tos_sip=0
defaultexpiry=90
jbenable=yes
jbmaxsize=200
jbimpl=fixed
t1min=100
timert1=500
timerb=32000
rtptimeout=60
rtpholdtimeout=300
rtpkeepalive=60
session-timers=originate
session-refresher=uas
autoframing=no
use183as180=no
directrtpsetup=no

[User1]
#include sip_account_custom-1.conf
type=friend
host=177.53.130.66
port=5060
dtmfmode=rfc2833
nat=no
qualify=no
insecure=port,invite
transport=udp
setvar=FAXOPT(gateway)=yes
disallow=all
allow=ulaw:20
allow=alaw:20

You haven’t presented the complete SIP configuration. You are missing the contents of sip_account_custom-1.conf. That will make a difference to the detailed reasons.

The general reason for this is likely to be that: the peer requires a password and you haven’t provided one, or have provided the wrong one; the peer doesn’t recognize the account name; or the peer recognizes the account name, but you are not someone that it wants to talk to.

Without the included file, your configuration contains nothing to specify the account name, although the incoming caller ID might get used for that, and nothing to specify the password.

Also please double check type=friend, nat=no, and insecure=port,invite. There are circumstances where these are the right thing to use, but they mainly result from copying and pasting bad examples. For ITSP connections, the most common best options are: type=peer, nat left unset, and insecure=invite (although remotesecret is a better way of addressing that issue).

Since, it I use a trusted IP, I don´t need an account name and password, do I? Also, I haven’t send the sip_account_custom-1.conf because it is empty.

If you don’t have a password, why do you have insecure=invite?! (It does nothing if you have no secret set.) We can’t tell you have nothing in the included file.

How is the peer supposed to recognize you? Hint. One of the reasons that I say type=friend is usually wrong is that it matches first by user name, so if you have another Asterisk at the other end and it has type=friend, one of the reasons for this failure would be that your caller ID mimics a local account that does need a password.

So far you have only eliminated wrong password from my list.

If you are relying on a trusted IP to authenticate the other end, to you, type=friend breaks that, and you need a system high network. Anyone knowing or guessing that User1 is the section name can initiate calls, as though they were the legitimate other end of that “connection”.

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