I have a situation:
The endpoint is registered in asterisk.
The endpoint send a call to asterisk
Asterisk response 401
The endpoint send a new invite with authorization
Asterisk response 401
I trie put identity_by=username
identity_by=auth_username
but the result is the same
The field from its different of aor
Without logging and configurations, it is difficult to say. One reason for this would be that the client isn’t being recognized, and the 401 is actually being sent to avoid letting an attacker know they weren’t recognized.
2022/04/12 12:50:57.759475 186.193.226.201:7080 → 131.196.224.6:7080
INVITE sip:42327699@131.196.224.6:7080 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.150:7080;rport;branch=z9hG4bKPjKojggRt0CvfZ1Lf0mRj1DOvE12J0pnXe
Max-Forwards: 70
From: “0994” sip:250@131.196.224.6:7080;tag=TDDPyE3GXSKMxBJcA7cspcWCCXgy-LXl
To: sip:42327699@131.196.224.6:7080
Contact: “0994” sip:250@192.168.0.150:7080
Call-ID: lPm18LxlEYFp4LIvk6Sznj.6iAqV-4u0
CSeq: 4040 INVITE
Allow: INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, OPTIONS, SUBSCRIBE, NOTIFY
Supported: 100rel, 100rel
User-Agent: Rev42
Content-Type: application/sdp
Content-Length: 309
v=0
o=icip3858648528 3858648528 IN IP4 192.168.0.150
s=int
c=IN IP4 192.168.0.150
t=0 0
m=audio 10014 RTP/AVP 18 8 0 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
2022/04/12 12:50:57.760031 131.196.224.6:7080 → 186.193.226.201:7080
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.150:7080;rport=7080;received=186.193.226.201;branch=z9hG4bKPjKojggRt0CvfZ1Lf0mRj1DOvE12J0pnXe
Call-ID: lPm18LxlEYFp4LIvk6Sznj.6iAqV-4u0
From: “0994” sip:250@131.196.224.6;tag=TDDPyE3GXSKMxBJcA7cspcWCCXgy-LXl
To: sip:42327699@131.196.224.6;tag=z9hG4bKPjKojggRt0CvfZ1Lf0mRj1DOvE12J0pnXe
CSeq: 4040 INVITE
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1649778657/7dbcd00b0b2695d8a84e7fc7812367a4”,opaque=“2db001d849f31b74”,algorithm=md5,qop=“auth”
Server: asterisk
Content-Length: 0
2022/04/12 12:50:57.766216 186.193.226.201:7080 → 131.196.224.6:7080
ACK sip:42327699@131.196.224.6:7080 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.150:7080;rport;branch=z9hG4bKPjKojggRt0CvfZ1Lf0mRj1DOvE12J0pnXe
Max-Forwards: 70
From: “0994” sip:250@131.196.224.6:7080;tag=TDDPyE3GXSKMxBJcA7cspcWCCXgy-LXl
To: sip:42327699@131.196.224.6:7080;tag=z9hG4bKPjKojggRt0CvfZ1Lf0mRj1DOvE12J0pnXe
Call-ID: lPm18LxlEYFp4LIvk6Sznj.6iAqV-4u0
CSeq: 4040 ACK
Content-Length: 0
2022/04/12 12:50:57.767746 186.193.226.201:7080 → 131.196.224.6:7080
INVITE sip:42327699@131.196.224.6:7080 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.150:7080;rport;branch=z9hG4bKPjhttc1iSwHgy10.OkdE5TGxvm8cpJtZpU
Max-Forwards: 70
From: “0994” sip:250@131.196.224.6:7080;tag=TDDPyE3GXSKMxBJcA7cspcWCCXgy-LXl
To: sip:42327699@131.196.224.6:7080
Contact: “0994” sip:250@192.168.0.150:7080
Call-ID: lPm18LxlEYFp4LIvk6Sznj.6iAqV-4u0
CSeq: 4041 INVITE
Allow: INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, OPTIONS, SUBSCRIBE, NOTIFY
Supported: 100rel, 100rel
User-Agent: Rev42
Authorization: Digest username=“0994”, realm=“asterisk”, nonce=“1649778657/7dbcd00b0b2695d8a84e7fc7812367a4”, uri=“sip:42327699@131.196.224.6:7080”, response=“f911877092248e174fc59fdf0
7cd27”, algorithm=md5, cnonce=“bXY-.CtSTqnXGY.ZEYpzk0dQ8bDOccrE”, opaque=“2db001d849f31b74”, qop=auth, nc=00000001
Content-Type: application/sdp
Content-Length: 309
v=0
o=icip 3858648528 3858648528 IN IP4 192.168.0.150
s=int
c=IN IP4 192.168.0.150
t=0 0
m=audio 10014 RTP/AVP 18 8 0 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
2022/04/12 12:50:57.768275 131.196.224.6:7080 → 186.193.226.201:7080
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.150:7080;rport=7080;received=186.193.226.201;branch=z9hG4bKPjhttc1iSwHgy10.OkdE5TGxvm8cpJtZpU
Call-ID: lPm18LxlEYFp4LIvk6Sznj.6iAqV-4u0
From: “0994” sip:250@131.196.224.6;tag=TDDPyE3GXSKMxBJcA7cspcWCCXgy-LXl
To: sip:42327699@131.196.224.6;tag=z9hG4bKPjhttc1iSwHgy10.OkdE5TGxvm8cpJtZpU
CSeq: 4041 INVITE
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1649778657/93aad26f2a301be9302a4230a23a5a64”,opaque=“2226c070092783ef”,algorithm=md5,qop=“auth”
Server: asterisk
Content-Length: 0
debug asterisk:
Endpoint found for ‘0994’ but ‘auth_username’ method not supported’
Request ‘INVITE’ from ‘“0994” sip:250@131.196.224.6’ failed for ‘186.193.226.201:7080’ (callid: l3ABsw-8pvqp3byOGGuexg3ZjOxuNwFJ) - Failed to authenticate
The issue here is that you aren’t using the right settings. identify_by tells the endpoint which auth method to use. You want username, which doesn’t require you touching that setting.
You need to set auth=[auth-section] and then make an auth section that has the username, password and the method. See the wiki and samples files for what to do.
Asterisk 18 Configuration_res_pjsip - Asterisk Project - Asterisk Project Wiki
This my configuration:
[0994]
type=aor
max_contacts=1
remove_existing=yes
[0994]
type = auth
realm=asterisk
username = 0994
password = ******
[0994]
type = endpoint
context=geral
moh_suggest=default
contact_user=0994
callerid=0994
;;;;;redirect_method=uri_pjsip
disallow=all
allow=alaw
allow=ulaw
language=pt_BR
allow_subscribe=yes
auth=0994
outbound_auth=0994
aors=0994
direct_media=no
inband_progress=yes
voicemail_extension=6240
rtp_timeout=300
dtmf_mode=rfc4733
100rel=no
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
identify_by=auth_username
You shouldn’t have both of these! Typically if you use outbound auth, you are talking to a service provider and I’ve never heard of a service provider that support inbound auth at the PABX end, which will means that enabling it with auth= is likely to result in the provider giving up, as they will not know what password to use.
I can’t think of a valid reason for using this, as the initial INVITE will not have one, so I’d expect the INVITE always to fail.
After many tests
with debug I discovered:
the “default_realm” needs have the same value of realm of auth section from endpoint.
The asterisk search first with IP, second with from and when I put identify_by=auth_username he search by Authorization field and finally find with username in autorization;
The question is: the “default_realm” in globals sections needs have the same value realm in endpoint, because the invite of origin send autorization with this value in second invite
This works for me.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.