Asterisk server asks peer on other server to Authenticate

I am trying to have an SIP peer on one asterisk server call an SIP peer on another asterisk server. I have SRTP enabled between the two servers not the SIP clients. When I initiate the call, i.e SIP1 on server1 calls SIP2 on server2, server2 tries to authenticate SIP1 and fails. I don’t want SIP TLS to be enabled, if that is causing the problem, and I don’t believe I have it enabled. Why is one server trying to authenticate a device on another server, don’t the severs just authenticate each other, via username/password? Everything is on the same WLAN, no NAT. Since it just says failed to authenticate SIP device, that doesn’t give me much information on what type of authentication failed.

I have tried different ways to try to fix this before posting here, but the receiving server just keeps saying that it has failed to authenticate the peer on the calling server.

I don’t know if this related but when I have an SIP client on dynamic, and I register it with the server, the server trys to look for the peer via my router’s public ip for some reason.

Here is my configuration for serverA or server1(similar config on serverB):

[general]
udpbindaddr=0.0.0.0
videosupport=no
allowguest=no
dtmfmode=rfc2833
context=default
disallow=all
allow=alaw
rtcachefriends=yes
limitonpeers=yes
callcounter=yes
canreinvite=no
srtpcapable=yes
call-limit=50
t38pt_udptl=no
qualify=yes
transfer=yes
allowtransfer=yes
encryption=yes

[asterisksrtpB]
disallow=all
allow=alaw
host=192.168.1.207
deny=0.0.0.0/0.0.0.0
permit=192.168.1.0/255.255.255.255
defaultuser=asterisksrtpA
secret=apassword
type=peer
context=incoming-internal
canreinvite=no
qualify=yes
nat=no
insecure=invite,port
srtpcapable=yes
encryption=yes

[201]
disallow=all
allow=alaw
host=dynamic
deny=0.0.0.0/0.0.0.0
permit=192.168.0.0/255.255.0.0
defaultuser=201
secret=somepassword
type=friend
context=incoming-internal
canreinvite=no
qualify=yes
nat=no
srtpcapable=no
encryption=no

Thank you

This is a discussion forum, not one for obtaining support.

There is no mention of SSL in you configuration, so any authentication failure will be due to simple password checking.

You have disabled password checking of B by A, so if there is a similar configuration on B, the secrets on the tie trunk are not being used. That suggests that B is not matching its section in A’s sip.conf.

As a minimum, you need to include a verbose log of the failure.

canreinvite is deprecated and may have been removed. You should check the rest of your configuration against the current documentation.

Sorry about that, won’t happen again.

Here is a verbose log of the error:

serverA says:

-- Executing [455@incoming-internal:1] NoOp("SIP/201-00000010", "Call from "" <201> to 455") in new stack -- Executing [455@incoming-internal:2] Dial("SIP/201-00000010", "SIP/asterisksrtp/202") in new stack == Using SIP RTP CoS mark 5 -- Called SIP/asterisksrtp/202 [Jun 21 12:45:13] WARNING[2099]: chan_sip.c:21111 handle_response_invite: Received response: "Forbidden" from '"201" <sip:asterisksrtp@192.168.1.180>;tag=as2f601b30' == Everyone is busy/congested at this time (1:0/0/1) -- Executing [455@incoming-internal:3] Hangup("SIP/201-00000010", "") in new stack == Spawn extension (incoming-internal, 455, 3) exited non-zero on 'SIP/201-00000010'

ServerB says:

chan_sip.c:23540: handle request invite: Failed to authenticate device "201" <sip:server1@server1ip>tag...

Thank you

Change type=friend to type=peer. The former is rarely needed and causes this problem if both sides have device names in common and use the device name as the caller ID. Alternatively follow the best practice security advice and do not use extension numbers as device names.

Note, when you fix this, the insecure=invite will mean you have no authentication between the two servers, so appassword will have no useful purpose. insecure=port is almost always an unnecessary insecurity.

I changed it to type=peer on both server’s configs. Now the message that serverA gave before is gone. When SIP <201> on serverA goes to call SIP <202> on serverB just like before, now no error message or any verbose appears on B. But now A says “the failed to authenticate message” as above that B said before but says it for 201@serverAip