Allowed quantity of "401 Unauthorized" as an answer to SIPINVITE before Asterisk considers do not accept any ... ? (+)

Asterisk Asterisk SIP
1

There is Asterisk 20.6.0 and multi channel GSM gateway set up via PJSIP on the same LAN.
During incoming call to the one of gateway’s channel from cellular phone, gateway sends SIP INVITE with credentials to the PBX in hoping to route/place this call to the PBX.
But these credentials are mismatched with ones set up at PBX.
As following the PBX answers with “401 Unauthorized”.

The gateway make 3 attempting to send SIP INVITE which are ended up with “401 Unauthorized”.

Can somebody tell is there RFCs or rules or any … where is speified what quantity of SIP INVITE - 401 Unauthorized dialog are allowed before such call/channel/gateway will be considered as Non-authorized and PBX will send nothing as well as “401 Unauthorized” to the gateway in context of this call even if the gateway contibue to try to established the call - send it to the PBX ?

2

Sending nothing is not an option, for a server or registrar, that would be given by any RFC. If a system starts ignoring a caller that fails to respond to 401 with an attempt to authenticate, it will be because of third party, firewall manipulating, software, such as fail2ban.

See How can I limit a count of reregistrations in Asterisk PJSIP? - Stack Overflow (but note that the chan_sip parameters are when acting as registrant).

Whilst I’m pretty sure that Asterisk has no limit when acting as a server or registrar, chan_pjsip has an optional limit of 1, when acting as registrant. I don’t think there is a limit as client.

Also, mismatched credentials should produce 403, not 401. The only time I’d expect multiple 401s is if the client/registrant did not offer authentication, or the nonce was stale by the time it authenticated.

Why is the gateway authenticating to the PABX? The toll fraud risk direction is normally the other way.

3

Nevertheless Asterisk answers as “401 Unauthoried”:
Each time “Authorization” field is added.
It is 3rd time - 3 lines with “Authorization”.

INVITE sip:sk8gp00@192.168.0.99:5062 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.242:50604;branch=z9hG4bK7b3f9;rport
From: "cell_number" <sip:cell_number@192.168.0.99:5062>;userid=usk8gp4;tag=a9ccacc5-48
To: <sip:sk8gp00@192.168.0.99:5062>
Contact: <sip:cell_number@192.168.0.242:50604>
Call-ID: 23ab47cb1837a00885b54e65d2f8d547@192.168.0.242
CSeq: 10004 INVITE
Authorization: Digest username="usk8gp4", realm="MySuperPuperPbx", nonce="1718194294/78e62c77102a0dcc057897c61c233811", uri="sip:sk8gp00@192.168.0.99:5062", algorithm=MD5, cnonce="234abcc436e2667097e7fe6eia53e8dd", opaque="46ce6f127f38ee2f", qop=auth, nc=00000001, response="f6252932f59ecaf9453b27a85339ea2a"
Authorization: Digest username="usk8gp4", realm="MySuperPuperPbx", nonce="1718194294/78e62c77102a0dcc057897c61c233811", uri="sip:sk8gp00@192.168.0.99:5062", algorithm=MD5, cnonce="234abcc436e2667097e7fe6eia53e8dd", opaque="5ec552b07d37affa", qop=auth, nc=00000001, response="f6252932f59ecaf9453b27a85339ea2a"
Authorization: Digest username="usk8gp4", realm="MySuperPuperPbx", nonce="1718194294/78e62c77102a0dcc057897c61c233811", uri="sip:sk8gp00@192.168.0.99:5062", algorithm=MD5, cnonce="234abcc436e2667097e7fe6eia53e8dd", opaque="51ff1d9b492713e0", qop=auth, nc=00000001, response="f6252932f59ecaf9453b27a85339ea2a"
Max-Forwards: 70
Supported: timer
User-Agent: My Gateway
Expires: 120
Allow: INVITE, ACK, INFO, CANCEL, BYE, OPTIONS, UPDATE, MESSAGE
Content-Type: application/sdp
Content-Length:   354

v=0
o=cell_number 3927183094 3927183094 IN IP4 192.168.0.242
s=SIP CALL
c=IN IP4 192.168.0.242
t=0 0
m=audio 10000 RTP/AVP 18 4 9 2 8 0 101
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:9 G722/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.242:50604;rport=50604;received=192.168.0.242;branch=z9hG4bK7b3f9
Call-ID: 23ab47cb1837a00885b54e65d2f8d547@192.168.0.242
From: "cell_number" <sip:cell_number@192.168.0.99>;tag=a9ccacc5-48;userid=usk8gp4
To: <sip:sk8gp00@192.168.0.99>;tag=z9hG4bK7b3f9
CSeq: 10004 INVITE
WWW-Authenticate: Digest realm="MySuperPuperPbx",nonce="1718194294/78e62c77102a0dcc057897c61c233811",opaque="3d6613d559e4fdb7",algorithm=MD5,qop="auth"
Server: Microsoft Lync 2020
Content-Length:  0

After such 3rd attemoting the gateway doesn’ t send SIP INVITE anymore and the gateway core make ATA command for exact channel modem, not ATH.
But call routing from the gateway cannot be accepted by PBX.

The gateway firmware R&D doesn’ t want t fix it.

I need to find arguents to convince they to fix it.

4

Asterisk has an identity crisis. It thinks it is really a Microsoft product.

You would get 401 if none of the opaque’s matched, but the log doesn’t show the previous 401.

Also, I’m pretty sure that there should only be one authentication for a given realm, but the rules are heavy reading.

I may not have understood the original question, if the three was referring to the number of headers.

5

Looks like PBX not allowing to authorize
Give please more details in PBX pjsip section
I think there is some missmatch in IP address in “permit” or “deny” instruction in PBX trunk

6

The original question is after how many “401 Unathorized” answers to SIP INVITE, some device, for example gsm gateway will understand that PBX is not authorized it and will not send any more SIP INVITE.

7

The situation was initiated by myself - I set up some wrong credentials at PBX side.
I made it to look at how gateway will handle the situation.
In my oppinion after unsuccessfull authorization gateway core has to hang up the modem - sends ATH to the modem, but it pick up the call - sends ATA.
In the case this incoming call can not be routed further to PBX but connection between modem and smartphone is established.
I see here security issue as well as minutes counts and some fee is appeared for this “semi call”.

8

That’s a local management policy, although getting 401 is not what you should see if you are actually not authorised. 401 is the result of providing no, no validly formed, authorisation. Providing an authorisation with the wrong credentials will provide a 403.

With the roles reversed, Asterisk has the choice of stopping after the first 403, stopping after the first 403 or 401, or delaying for a specified time after a 403.

9

But Asterisk sends 401, not 403.

How is set authorization by sip invite limit at Asterisk, at pjsip ?

10

Sending 401 to reject would be a bug, and I think it would have been reported long ago. I think the real problem is that the authorisation responses are malformed. I think sending three of them, with different opaque values, in response to a single challenge, counts as malformed.

11

As I saw the Asterisk console and rememer:
fo the first attempt is:

Authorization: Digest username="usk8gp4", realm="MySuperPuperPbx", nonce="1718194294/78e62c77102a0dcc057897c61c233811", uri="sip:sk8gp00@192.168.0.99:5062", algorithm=MD5, cnonce="234abcc436e2667097e7fe6eia53e8dd", opaque="46ce6f127f38ee2f", qop=auth, nc=00000001, response="f6252932f59ecaf9453b27a85339ea2a"

for second attempt:

Authorization: Digest username="usk8gp4", realm="MySuperPuperPbx", nonce="1718194294/78e62c77102a0dcc057897c61c233811", uri="sip:sk8gp00@192.168.0.99:5062", algorithm=MD5, cnonce="234abcc436e2667097e7fe6eia53e8dd", opaque="46ce6f127f38ee2f", qop=auth, nc=00000001, response="f6252932f59ecaf9453b27a85339ea2a"
Authorization: Digest username="usk8gp4", realm="MySuperPuperPbx", nonce="1718194294/78e62c77102a0dcc057897c61c233811", uri="sip:sk8gp00@192.168.0.99:5062", algorithm=MD5, cnonce="234abcc436e2667097e7fe6eia53e8dd", opaque="5ec552b07d37affa", qop=auth, nc=00000001, response="f6252932f59ecaf9453b27a85339ea2a"

and for third attempt I posted at my initial question:

Authorization: Digest username="usk8gp4", realm="MySuperPuperPbx", nonce="1718194294/78e62c77102a0dcc057897c61c233811", uri="sip:sk8gp00@192.168.0.99:5062", algorithm=MD5, cnonce="234abcc436e2667097e7fe6eia53e8dd", opaque="46ce6f127f38ee2f", qop=auth, nc=00000001, response="f6252932f59ecaf9453b27a85339ea2a"
Authorization: Digest username="usk8gp4", realm="MySuperPuperPbx", nonce="1718194294/78e62c77102a0dcc057897c61c233811", uri="sip:sk8gp00@192.168.0.99:5062", algorithm=MD5, cnonce="234abcc436e2667097e7fe6eia53e8dd", opaque="5ec552b07d37affa", qop=auth, nc=00000001, response="f6252932f59ecaf9453b27a85339ea2a"
Authorization: Digest username="usk8gp4", realm="MySuperPuperPbx", nonce="1718194294/78e62c77102a0dcc057897c61c233811", uri="sip:sk8gp00@192.168.0.99:5062", algorithm=MD5, cnonce="234abcc436e2667097e7fe6eia53e8dd", opaque="51ff1d9b492713e0", qop=auth, nc=00000001, response="f6252932f59ecaf9453b27a85339ea2a"

If somebody wants to see such log I can do it.

12

There is no ability to change or configure such a thing in Asterisk. I still don’t understand what the real problem is here. Is the real problem that it should be authenticating and the call work, but it doesn’t?

13

The real ptoblem is thatt after some time of unauthorization the gateway corec has to hamg up appropriae modem, not pick up the call.

I would like to know if there are some rfc or rules define authorization attemps after which the device is considered as denied.

Looks like after 3 failed password attempts Lonux or Windows or some mail service either blocks such user for some minutes or forvever.

14

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