Asterisk answer "Unauthorized" for each endpoint's OPTIONS request

Asterisk Asterisk SIP
1

Hello team!
I see a lot of pjsip logs where endpoints send to Asterisk OPTIONS request with frequency like it doing a ping of server, but Aasterisk each time answering “401 Unauthorized”.

Is it wrong configuration of endpoints where they don’t include authorization headers in OPTIONS request? Or it’s wrong configuration of Asterisk where he cannot authorize them?

Below is a pjsip log of Asterisk:

<--- Received SIP request (402 bytes) from UDP:146.11.9.12:20091 --->
OPTIONS sip:sip.example.com SIP/2.0
Call-ID: ef9c2c838a6c42aaf7ec4fc10117cb08@10.24.22.75
CSeq: 2115 OPTIONS
From: "user1" <sip:user1@sip.example.com>;tag=3966865735
To: "user1" <sip:user1@sip.example.com>
Via: SIP/2.0/UDP 146.11.9.12:20091;branch=z9hG4bKe6e52700c0a07156497bd74c8589e3ff323638;rport
Max-Forwards: 70
User-Agent: SIPAUA/0.1.001
Content-Length: 0


<--- Transmitting SIP response (601 bytes) to UDP:146.11.9.12:20091 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 146.11.9.12:20091;rport=20091;received=146.11.9.12;branch=z9hG4bKe6e52700c0a07156497bd74c8589e3ff323638
Call-ID: ef9c2c838a6c42aaf7ec4fc10117cb08@10.24.22.75
From: "user1" <sip:user1@sip.example.com>;tag=3966865735
To: "user1" <sip:user1@sip.example.com>;tag=z9hG4bKe6e52700c0a07156497bd74c8589e3ff323638
CSeq: 2115 OPTIONS
WWW-Authenticate: Digest realm="asterisk",nonce="1581497789/791892342f148ee0810420627a4d93bd",opaque="6ca095747ad7fdcd",algorithm=md5,qop="auth"
Server: Asterisk PBX 16.7.0
Content-Length:  0

That entries are thousands in the log, once in 1-2 sec. Looks like UAC very want to be Authorized)

2

Neither. If the are only doing it as a ping (as is the case when Asterisk does it), a 401 response is as good as any other.

3

Not sure, that they are doing a ping, at least I didn’t setup that. Is this ok that ping doing through “OPTIONS” request?

Is it adjustable time for these requests?

Also, seems for each “OPTIONS” there are records in security Asterisk log:

[2020-02-12 09:50:11] SECURITY[27115] res_security_log.c: SecurityEvent="ChallengeSent",EventTV="2020-02-12T09:50:11.523+0000",Severity="Informational",Service="PJSIP",EventVersion="1",AccountID="user1",SessionID="268142b327966a6ea9f81816cc956108@10.63.206.137",LocalAddress="IPV4/UDP/10.128.0.7/5060",RemoteAddress="IPV4/UDP/146.11.9.12/35449",Challenge=""

Is it ok? Every second, with sometimes pause for 10 seconds.

4

Whether it would be adjustable is up to the remote endpoint. It is the one sending the OPTIONS request. As for the security log it’s stating that it challenged for authentication, which it did.

5

Hm, I thought it can be adjusted by “qualify” options in pjsip. But ok, thank you for explanation!

6

The qualify option in Asterisk configures the frequency at which Asterisk itself will send OPTIONS requests.

7

Got it.

My concern here - should I try to get these “OPTIONS - UNAUTHORIZED” dialogs have “OPTIONS - AUTHORIZED” in somehow way?

Are they so frequently, not because UAC every time receive “Unauthorized”, and in case if he will be Authorized he will send, for example “OPTIONS” once in a 10 minutes?

8

That would be dependent on the behavior of the remote side. I can’t answer that with certainty as I do not know. Generally OPTIONS is frequently sent as a keep alive/ping, so even with auth that may not change things.

9

Thank you for explanation!

And my last question. Am I right that though UAC itself registered, because I see it in ‘pjsip show endpoints’ output, Asterisk send “Unauthorized” because “Options” request itself don’t has authorization header, but not because it’s a bug and Asterisk should consider all registered endpoints in “pjsip list endpoints” as trusted and don’t ask send Uac to Asterisk Authorization token?

10

All requests from an endpoint are challenged for authentication. Endpoints aren’t “trusted” if they register. That merely tells Asterisk where to send calls destined for them.

2 Likes
11

Got it! Thanks a lot for explanation!

12

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