BUG in Asterisk 13.Х chan_sip - Forbidden 403

I found a problem with call processing using SIP protocol.
For example:
I’m trying to make a call from a station at an Asterisk (PBX-1, assigned numbers: 11ХХ) directly to a station at another Asterisk (PBX-2, assigned numbers: 10ХХ-11ХХ). The original CID is passed during the call. It may happen so that PBX-2 determines the incoming CID as existing in its own configuration. in this case PBX-2 returns “Forbidden 403” as if an authentication error occured.
For example, I’m trying to make a call from number 1107 on PBX-1 (this number exists in the configuration of both PBXs), to number 1000 (PBX-2)

Using INVITE request as basis request - 195851bb4abc4fdc17ba8da524330781@172.16.15.196:5060
Found peer '1107' for '1107' from 172.16.15.196:5060
[Mar 17 01:02:55] WARNING[901][C-00000049]: chan_sip.c:16702 check_auth: username mismatch, have <1107>, digest has <s>
[Mar 17 01:02:55] NOTICE[901][C-00000049]: chan_sip.c:25603 handle_request_invite: Failed to authenticate device "Astashov A." <sip:1107@172.16.15.196>;tag=as5ce36944

Both PBXs are configured according to the documentation.

However, if I remove the station number (1107) from the PBX-2 configuration, the error does not occur, the call proceeds normally.

The error is occurring with Asterisk version 13, it does not occur on Asterisk version 11 when using the same configuration.
Also, the error does not occur when using the IAX2 protocol even on version 13.
So, the problem is only with Asterisk 13 when using SIP.

This issue is preventing me from using FMC (Fixed Mobile Convergence) provided by our mobile carrier.

My configuration is as follows:
#cat sip.conf (PBX-1)
[general]
context=public
udpbindaddr=0.0.0.0
allowoverlap=no
bindaddr=0.0.0.0
bindport=5060
register => Astashov-EDU-15-196:MyEDU-8.117!@172.16.15.196/Astashov-EDU-15-196

[1100]
type=friend
context=phones
host=dynamic
secret=MyEDU!!
dial=SIP/1100

[1107]
type=friend
context=phones
host=dynamic
secret=MyEDU!!
dial=SIP/1107

[Astashov-EDU-8-117]
type=friend
secret=MyEDU-8.117!
contex=8-117-incoming
host=dynamic
disallow=all
allow=alaw
insecure=invite

#cat extension.conf (PBX-1)
[globals]

[general]
autofallthrough=yes

[outgoing_calls]
exten => _10XX,1,NoOp()
exten => _10XX,n,Dial(SIP/172.16.8.117/${EXTEN})

[internal]
exten => 1107,1,Verbose(1|Extension 1107)
exten => 1107,n,Dial(SIP/1107,30)
exten => 1107,n, Hangup()

[public]
exten => _11XX,1,NoOp()
exten => _11XX,n,Dial(SIP/${EXTEN},30)
exten => _11XX,n,Hangup()

[phones]
include => internal
include => outgoing_calls

[8-117-incoming]
include => internal

#cat sip.conf (PBX-2)
[general]
context=public
udpbindaddr=0.0.0.0
allowoverlap=no
bindaddr=0.0.0.0
bindport=5060
register => Astashov-EDU-8-117:MyEDU-8.117!@172.16.15.196/Astashov-EDU-8-117

[1000]
type=friend
context=phones
host=dynamic
secret=MyEDU!!
dial=SIP/1000

[1107]
type=friend
context=phones
host=dynamic
secret=MyEDU!!
dial=SIP/1107

[Astashov-EDU-15-196]
type=friend
secret=MyEDU-8.117!
contex=15-196-incoming
host=dynamic
disallow=all
allow=alaw
insecure=invite

#cat extension.conf (PBX-2)
[globals]

[general]
autofallthrough=yes

[outgoing_calls]
exten => _11XX,1,NoOp()
exten => _11XX,n,Dial(SIP/172.16.15.196/${EXTEN})

[internal]
exten => 1000,1,Verbose(1|Extension 1000)
exten => 1000,n,Dial(SIP/1000,30)
exten => 1000,n, Hangup()

[public]
exten => _10XX,1,NoOp()
exten => _10XX,n,Dial(SIP/${EXTEN},30)
exten => _10XX,n,Hangup()

[phones]
include => internal
include => outgoing_calls

[15-196-incoming]
include => internal

Sounds like you have been following flawed cookbook articles. Based on reading the first few lines of your report, I think you have a configuration error in that you have used type=friend, when you should have used type=peer. Whilst most cookbook solutions use type=friend, it is very rare that it is actually appropriate.

This is not a bug. It is expected behaviour if you use type=friend.

(Also note that making device names guessable, like using their primary extension number, is not best security practice. Combined with the use of friend, it allows an attack without upsetting existing registrations.)

Does not make difference whether it’s peer or friend, the error persists.

This my configuration - is the simplest test for a particular error. I did it in order to exclude any influence.

Everything should be a peer.

Indeed, if I use “peer” everywhere, it works. But the manual (Asterisk, The Definitive Guide, 4th Edition) advises to use “friend” where possible, including SIP stations…

And in the book Asterisk The Future of Telephony (Second Edition) (My main book :slight_smile:) is written:

Since we want to be able to both send calls to the softphone and allow the client to
place calls, we have defined the type as friend. The other two types are user and
peer. From the viewpoint of Asterisk, a user is configured to enter the dialplan, and a
peer is created for calls leaving the dialplan (via the Dial() application). A friend is
simply a shortcut that defines both a user and a peer. If in doubt, define the type as
friend.

I still think that this is a bug. Prior to version 11, all worked well.

I don’t believe there have been any changes in 13 to impact this, chan_sip has certainly not received much, and I’d be surprised if it was different in 11. Matching has always happened based on the From username. Since it’s 1107 it’s grabbing 1107. There is an option which can be set in the general section:

match_auth_username=yes

That attempts to use the authentication username instead. It’s an experimental feature and may work. I still don’t believe this is a bug though. Have you actually used the exact same configuration in 11 and confirmed the regression?

In version 11, I set to SIP-phones type=friend
On the trunk set type=peer, everything works.

on version 13 does not work.

It is not the setting on the peer, it is the settings on local devices.

The only bug is in the book, which seems to be suffering from copy and pasting from earlier poor sources.

When Asterisk gets a call (and this applies to 1.6.1.0, as well as to the later ones you are using), it first tries to match the name in the From header with the section names of type=user entries. If that fails, it tries to match based on the last known IP address of any peers. friends are simultaneously users and peers. peers will match on name, but only for REGISTER, not for calls.

Therefore, when you get a call on the trunk with the user part of its From header matching an “extension”, the user match on that “extension” takes precedence over the peer match on the “trunk”. (Note that Asterisk uses neither “extension” nor “trunk” with their meanings in this posting.