401 Unauthorized with multiple PJSIP registrations

Asterisk Asterisk SIP
1

Hello. I have an Asterisk 16 installation that I’m converting from chan_sip to pjsip. It has two Vitelity subaccount registrations, which both appear to be registering correctly, both on port 5060.

vitelity-1234-reg/sip:xxxx_1234@inbound23.vitelity.net vitelity-1234-auth-outbound Registered
vitelity-5678-reg/sip:xxxx_5678@inbound23.vitelity.net vitelity-5678-auth-outbound Registered

I can send a call to 5678 but 1234 will fail with “401 Unauthorized”. If I comment out 5678 and reload pjsip, calls will go through to 1234 just fine, so that tells me that both accounts can receive calls. It appears that the last one that registers is the one that works. This didn’t happen with chan_sip() so I’m assuming I just have something wrong in my configs.

Looking at the SIP logs for the failed call, the correct username, xxxx_1234, is being sent in the authorization but then is rejected:

[2021-10-08 16:55:54] NOTICE[1022520]: res_pjsip/pjsip_distributor.c:672 log_failed_request: Request ‘INVITE’ from ‘"[V] 1112223333" sip:1112223333@66.241.96.96’ failed for ‘66.241.96.96:5060’ (callid: 3209ba4d26ddf7df675f0301311882c4@66.241.96.96) - Failed to authenticate
SIP/2.0 401 Unauthorized

I can post anything relevant that might be needed. Just let me know. If this rings a bell with anyone, just point me in the right direction. Thank you!

2

401 is not a failure! We would need to see the configuration to understand why Asterisk didn’t know how to authenticate in response to this challenge.

3

I realize the first 401 is part of the protocol but this one happens further down in the SIP conversation.
Tried posting my config but the forum considers me a new user, although I’ve had an inactive account for years. It won’t let me post my config or upload a file. It complains about too many links in my content. Maybe the SIP URIs are confusing it. Oh well. Not sure how to proceed.

4 
; This is used by all connections
[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0

[vitelity-5678-auth]
type=auth
auth_type=userpass
username=xxxx_5678
password=my_secret

[vitelity-5678-auth-outbound]
type=auth
auth_type=userpass
username=xxxx_5678
password=my_secret

[vitelity-1234-auth]
type=auth
auth_type=userpass
username=xxxx_1234
password=my_secret

[vitelity-1234-auth-outbound]
type=auth
auth_type=userpass
username=xxxx_1234
password=my_secret


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Now the registration profiles for both subaccounts
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

[vitelity-5678-reg]
type=registration
outbound_auth=vitelity-5678-auth-outbound
client_uri = sip:xxxx_5678@inbound23.vitelity.net:5060
server_uri = sip:xxxx_5678@inbound23.vitelity.net:5060
contact_user = xxxx_5678
forbidden_retry_interval=60
fatal_retry_interval=60
auth_rejection_permanent=no


[vitelity-1234-reg]
type=registration
outbound_auth=vitelity-1234-auth-outbound
client_uri = sip:xxxx_1234@inbound23.vitelity.net:5060
server_uri = sip:xxxx_1234@inbound23.vitelity.net:5060
contact_user = xxxx_1234
forbidden_retry_interval=60
fatal_retry_interval=60
auth_rejection_permanent=no


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Inbound for 5678
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

[vitelity-5678-inbound]
type=aor
contact=sip:inbound23.vitelity.net

[vitelity-5678-inbound]
type=identify
endpoint=vitelity-5678-inbound
match=inbound23.vitelity.net

[vitelity-5678-inbound]
type=endpoint
context=from-vitel
disallow=all
allow=ulaw
auth=vitelity-5678-auth
aors=vitelity-5678-inbound
dtmf_mode=auto
direct_media=no ; canreinvite

; Behind nat
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Inbound for 1234
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

[vitelity-1234-inbound]
type=aor
contact=sip:inbound23.vitelity.net

[vitelity-1234-inbound]
type=identify
endpoint=vitelity-1234-inbound
match=inbound23.vitelity.net

[vitelity-1234-inbound]
type=endpoint
context=from-vitel
disallow=all
allow=ulaw
auth=vitelity-1234-auth
aors=vitelity-1234-inbound
dtmf_mode=auto
direct_media=no ; canreinvite

; Behind nat
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Outbound for 5678
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

[vitelity-5678-outbound]
type=aor
contact=sip:outbound.vitelity.net

[vitelity-5678-outbound]
type=identify
endpoint=vitelity-5678-outbound
match=outbound.vitelity.net

[vitelity-5678-outbound]
type=endpoint
disallow=all
allow=ulaw
auth=vitelity-5678-auth
outbound_auth=vitelity-5678-auth-outbound
aors=vitelity-5678-outbound
dtmf_mode=auto
from_user=xxxx_5678
send_rpid=yes

direct_media=no
trust_id_inbound=yes

; Behind nat
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Outbound for 1234
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

[vitelity-1234-outbound]
type=aor
contact=sip:outbound.vitelity.net

[vitelity-1234-outbound]
type=identify
endpoint=vitelity-1234-outbound
match=outbound.vitelity.net

[vitelity-1234-outbound]
type=endpoint
disallow=all
allow=ulaw
auth=vitelity-1234-auth
outbound_auth=vitelity-1234-auth-outbound
aors=vitelity-1234-outbound
dtmf_mode=auto
from_user=xxxx_1234
send_rpid=yes

direct_media=no
trust_id_inbound=yes

; Behind nat
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
5

Why is vitelity behind NAT? That is strange for an ITSP. Normally it is the customer that is behind NAT, which is handled by signalling and media addresses in your transport (where you do not have anything to cope with NAT).

Why do you have inbound and outbound endpoints. They are rarely needed for chan_sip and even less so for chan_pjsip.

Why do you have identify for something only used for outbound?

It is indeterminate how two type=identifies with exactly the same match conditions, will work. Generally trying to simulate a DID trunk with multiple accounts is not a good idea. A business provider will provide a single account, multiple DID trunk. A domestic/home office supplier won’t expect you to have a PABX or multiple numbers.

Typical ITSPs won’t authenticate themselves to the customer, but you have specified two way authentication.

6

Obviously, I have issues with this config. I’m a bit new to pjsip. Thanks. I’ll drop back and start over.

7

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