Authentication behavior on incoming calls

Flac · August 12, 2024, 1:45pm

Hello !

I’m building a voip system with asterisk as a “provider” in lab and I have trouble concerning authentication on incoming call. Sometimes asterisk sent a 401 (good), but sometimes (more often) it doesn’t send a 401.

Below, pjsip.conf :

[global]
default_realm=provider.net

[udp-transport]
type=transport
protocol=udp
bind=192.168.0.132:5060

[33908070605]
type=endpoint
context=external
disallow=all
allow=ulaw
auth=auth33908070605
aors=33908070605
direct_media=no

[auth33908070605]
type=auth
auth_type=userpass
password=33908070605
username=33908070605
realm=provider.net

[33908070605]
type=aor
max_contacts=1
qualify_frequency=60

[33908070605]
type=identify
endpoint=33908070605
match=192.168.0.130

SIP trace on a successful call :

INVITE sip:+33134775457@192.168.0.132:5060 SIP/2.0
Via:  SIP/2.0/UDP 192.168.0.130:5060;branch=z9hG4bKaca6.81be8255.0
Route:  <sip:172.21.0.130:5060;lr>
From:  <sip:33908070605@192.168.0.132>;tag=E801C41B_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_6407
To:  <sip:+33134775457@192.168.0.132:5060>
Call-ID: 0201FFFF17FE3BE4
CSeq:  1 INVITE
Contact:  <sip:192.168.0.130;did=39a.219f7707>
Allow:  INVITE, ACK, CANCEL, OPTIONS, BYE
Authorization:  Digest username="33908070605", realm="provider.net", nonce="1723467344/2ef6b13d746c85973afff4f35d4381d5", uri="sip:+33134775457@192.168.0.132:5060", response="e37819763a04c8159988e600c2a3a50c", algorithm=MD5, cnonce="c41b8b01d0fc6f24d61ae4768c611fe61509a252", opaque="3a9326b379f65eac", qop=auth, nc=00000009
Supported:  100rel
Max-Forwards:  68
Privacy:  none
P-Asserted-Identity:  <sip:33908070605@192.168.0.132>
User-Agent:  A5000 R8.0  /AC00 FRA
Content-Type:  application/sdp
Content-Length:  408

v=0
o=- 1723467381 1723467381 IN IP4 192.168.0.132
s=-
c=IN IP4 172.21.0.131
t=0 0
m=audio 22010 RTP/AVP 9 8 0 18 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=mptime:30 
a=mptime:20 
a=mptime:30 
a=mptime:20 
a=mptime:30 
a=mptime:40 
a=sendrecv
a=rtcp:22011
a=ptime:20

SIP/2.0 401 Unauthorized
Via:  SIP/2.0/UDP 192.168.0.130:5060;rport=5060;received=192.168.0.130;branch=z9hG4bKaca6.81be8255.0
Call-ID: 0201FFFF17FE3BE4
From:  <sip:33908070605@192.168.0.132>;tag=E801C41B_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_6407
To:  <sip:+33134775457@192.168.0.132>;tag=z9hG4bKaca6.81be8255.0
CSeq:  1 INVITE
WWW-Authenticate:  Digest realm="provider.net",nonce="1723467380/3040dec3834b9e8635a8ed418875b969",opaque="37c206a51d7201a7",stale=true,algorithm=MD5,qop="auth"
Server:  Asterisk PBX 20.9.2
Content-Length:   0

INVITE sip:+33134775457@192.168.0.132 SIP/2.0
Via:  SIP/2.0/UDP 192.168.0.130:5060;branch=z9hG4bK7ca6.f008d565.0
Route:  <sip:172.21.0.130:5060;lr>
From:  <sip:33908070605@192.168.0.132>;tag=E801C41B_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_6407
To:  <sip:+33134775457@192.168.0.132>
Call-ID: 0201FFFF17FE3BE4
CSeq:  2 INVITE
Contact:  <sip:192.168.0.130;did=39a.319f7707>
Allow:  INVITE, ACK, CANCEL, OPTIONS, BYE
Authorization:  Digest username="33908070605", realm="provider.net", nonce="1723467380/3040dec3834b9e8635a8ed418875b969", uri="sip:+33134775457@192.168.0.132", response="2eee82ea6d4b757701bd5dc8c3983b21", algorithm=MD5, cnonce="c51b8b01e9e62d0d00db442ea1e5d6febd86d9ba", opaque="37c206a51d7201a7", qop=auth, nc=00000001
Supported:  100rel
Max-Forwards:  68
Privacy:  none
P-Asserted-Identity:  <sip:33908070605@192.168.0.132>
User-Agent:  A5000 R8.0  /AC00 FRA
Content-Type:  application/sdp
Content-Length:  405

v=0
o=- 1723467381 1723467382 IN IP4 172.21.0.7
s=-
c=IN IP4 172.21.0.131
t=0 0
m=audio 22010 RTP/AVP 9 8 0 18 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=mptime:30 
a=mptime:20 
a=mptime:30 
a=mptime:20 
a=mptime:30 
a=mptime:40 
a=sendrecv
a=rtcp:22011
a=ptime:20

CANCEL sip:+33134775457@192.168.0.132 SIP/2.0
Via:  SIP/2.0/UDP 192.168.0.130:5060;branch=z9hG4bK7ca6.f008d565.0
From:  <sip:33908070605@192.168.0.132>;tag=E801C41B_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_6407
Call-ID: 0201FFFF17FE3BE4
To:  <sip:+33134775457@192.168.0.132>
CSeq:  2 CANCEL
Max-Forwards:  70
Route:  <sip:172.21.0.130:5060;lr>
Reason:  SIP ;cause=200 ;text="Call completed"
User-Agent:  OpenSIPS (3.4.6 (x86_64/linux))
Content-Length:  0

SIP/2.0 200 OK
Via:  SIP/2.0/UDP 192.168.0.130:5060;rport=5060;received=192.168.0.130;branch=z9hG4bK7ca6.f008d565.0
Call-ID: 0201FFFF17FE3BE4
From:  <sip:33908070605@192.168.0.132>;tag=E801C41B_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_6407
To:  <sip:+33134775457@192.168.0.132>;tag=e5e14bd2-6814-4d2c-8cd9-beb0f39bf572
CSeq:  2 CANCEL
Server:  Asterisk PBX 20.9.2
Content-Length:   0

SIP/2.0 487 Request Terminated
Via:  SIP/2.0/UDP 192.168.0.130:5060;rport=5060;received=192.168.0.130;branch=z9hG4bK7ca6.f008d565.0
Call-ID: 0201FFFF17FE3BE4
From:  <sip:33908070605@192.168.0.132>;tag=E801C41B_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_6407
To:  <sip:+33134775457@192.168.0.132>;tag=e5e14bd2-6814-4d2c-8cd9-beb0f39bf572
CSeq:  2 INVITE
Server:  Asterisk PBX 20.9.2
Allow:  OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Content-Length:   0

SIP trace on an unsuccessful call :

INVITE sip:+33134775457@192.168.0.132:5060 SIP/2.0
Via:  SIP/2.0/UDP 192.168.0.130:5060;branch=z9hG4bK1b06.5bcef5a1.0
Route:  <sip:172.21.0.130:5060;lr>
From:  <sip:33908070605@192.168.0.132>;tag=0502FD9A_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_64A6
To:  <sip:+33134775457@192.168.0.132:5060>
Call-ID: 0201FFFFFAFD0265
CSeq:  1 INVITE
Contact:  <sip:192.168.0.130;did=a7.6e072ef3>
Allow:  INVITE, ACK, CANCEL, OPTIONS, BYE
Authorization:  Digest username="33908070605", realm="provider.net", nonce="1723467694/03f5077c6aa45a10b1691c1967541d83", uri="sip:+33134775457@192.168.0.132:5060", response="15776d787f3ccbb66629a14a011ae143", algorithm=MD5, cnonce="fd9a8b01af02cc3edca90b5f29f1dee9a6f2bc22", opaque="3e40cb4639b955c5", qop=auth, nc=00000005
Supported:  100rel
Max-Forwards:  68
Privacy:  none
P-Asserted-Identity:  <sip:33908070605@192.168.0.132>
User-Agent:  A5000 R8.0  /AC00 FRA
Content-Type:  application/sdp
Content-Length:  408

v=0
o=- 1723467707 1723467707 IN IP4 192.168.0.132
s=-
c=IN IP4 172.21.0.131
t=0 0
m=audio 25992 RTP/AVP 9 8 0 18 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=mptime:30 
a=mptime:20 
a=mptime:30 
a=mptime:20 
a=mptime:30 
a=mptime:40 
a=sendrecv
a=rtcp:25993
a=ptime:20

SIP/2.0 180 Ringing
Via:  SIP/2.0/UDP 192.168.0.130:5060;rport=5060;received=192.168.0.130;branch=z9hG4bK1b06.5bcef5a1.0
Call-ID: 0201FFFFFAFD0265
From:  <sip:33908070605@192.168.0.132>;tag=0502FD9A_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_64A6
To:  <sip:+33134775457@192.168.0.132>;tag=ff6416e2-daa5-475d-995b-e4082a4e81f9
CSeq:  1 INVITE
Server:  Asterisk PBX 20.9.2
Contact:  <sip:192.168.0.132:5060>
Allow:  OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Content-Length:   0

CANCEL sip:+33134775457@192.168.0.132 SIP/2.0
Via:  SIP/2.0/UDP 192.168.0.130:5060;branch=z9hG4bK1b06.6bcef5a1.0
Route:  <sip:172.21.0.130:5060;lr>
From:  <sip:33908070605@192.168.0.132>;tag=0502FD9A_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_64A6
To:  <sip:+33134775457@192.168.0.132>
Call-ID: 0201FFFFFAFD0265
CSeq:  1 CANCEL
Reason:  Q.850 ;cause=16 ;text="Terminated"
Max-Forwards:  68
User-Agent:  A5000 R8.0  /AC00 FRA
Content-Length:  0

SIP/2.0 481 Call/Transaction Does Not Exist
Via:  SIP/2.0/UDP 192.168.0.130:5060;received=192.168.0.130;branch=z9hG4bK1b06.6bcef5a1.0
Call-ID: 0201FFFFFAFD0265
From:  <sip:33908070605@192.168.0.132>;tag=0502FD9A_nab_FFFF_isp_FFFF_cco_FFFF_igo_FFFF_mgt_64A6
To:  <sip:+33134775457@192.168.0.132>;tag=z9hG4bK1b06.6bcef5a1.0
CSeq:  1 CANCEL
Server:  Asterisk PBX 20.9.2
Content-Length:   0

In debug mode, we can see this when the call is ok :

[Aug 12 14:56:20] DEBUG[76471] res_pjsip_authenticator_digest.c: Realm: provider.net  Username: 33908070605  Result: STALE
[Aug 12 14:56:21] DEBUG[76471] res_pjsip_authenticator_digest.c: Calculated nonce 1723467380/3040dec3834b9e8635a8ed418875b969. Actual nonce is 1723467380/3040dec3834b9e8635a8ed418875b969
[Aug 12 14:56:21] DEBUG[76471] res_pjsip_authenticator_digest.c: Realm: provider.net  Username: 33908070605  Result: SUCCESS

Here is when the call is ko :

[Aug 12 15:01:46] DEBUG[76471] res_pjsip_authenticator_digest.c: Calculated nonce 1723467694/03f5077c6aa45a10b1691c1967541d83. Actual nonce is 1723467694/03f5077c6aa45a10b1691c1967541d83
[Aug 12 15:01:46] DEBUG[76471] res_pjsip_authenticator_digest.c: Realm: provider.net  Username: 33908070605  Result: SUCCESS

It seems that asterisk doesn’t need to authenticate client because he already has what he needs. I don’t understand this part…

The problem that client needs this authentication otherwise he loses the dialog and send a request with a other branch.

Please help !

Thank you

F.

jcolp · August 12, 2024, 1:49pm

I don’t think there’s really helping this because Asterisk is behaving as expected, and perfectly valid within SIP. At the time the INVITE was received the Authorization was valid. It sounds like the remote side is broken and I’m not sure there’s anything you can do Asterisk side to work around that - well, not authenticating might.

Flac · August 12, 2024, 2:01pm

Thank you for replying!

There is no way to force asterisk to challenge each call and not calling his cache ? cr*p.
It seems that further, it used to ?

The client side is a Mitel A5000, and I don’t think it’s possible to deal with it

jcolp · August 12, 2024, 2:02pm

The chan_sip module behaved differently.

Flac · August 12, 2024, 2:04pm

Ok, I think this is certainly for performance gain.
I will search an other way to fix it.

Thank again !

TheNextDay · August 12, 2024, 3:18pm

This is interesting. Of course I am not watching SIP debugs the whole day but I think I never saw behaviour like this.
If you say authorization was valid at time of call, which authorization could this have been? From previous REGISTER?

jcolp · August 12, 2024, 3:20pm

Something prior, yes. It’s valid for a short period of time. I’ve never seen an implementation reuse auth as such, but it can be done.

TheNextDay · August 12, 2024, 3:44pm

My fault, I overlooked the Authorization header in the second example and thought asterisk accepted the call without auth just because of some prior successful auth.

I agree, I guess it’s valid like this as long as the nonce hasn’t expired.

Edit: maybe setting nonce_lifetime (default 32) in auth section to a much more lower value could help here. Worth a try.

david551 · August 12, 2024, 7:31pm

32 will be based on the maximum delay as the result of retransmissions.

system · September 11, 2024, 7:32pm

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

Topic		Replies	Views
Outgoing Call PJSIP - 401 Asterisk SIP	8	358	May 13, 2022
Asterisk returns 401 for correctly authenticated extensions when calling Asterisk SIP	7	999	October 24, 2018
401 Unauthorized when receiving calls from providers Asterisk SIP	10	1465	October 23, 2021
Incoming calls - authentication error Asterisk Support	2	235	June 25, 2012
Asterisk will not accept incoming calls Asterisk Support	5	30	September 6, 2024

Authentication behavior on incoming calls

Related topics