How to disable SIP authentication on a trunk level entirely?

Hi all,

I have two Asterisk nodes:

  • [A] ( is paired with FreePBX and works in production

  • [B] ( is a test node and does not have any GUI. Its version: Asterisk 13.1-cert2

I need a simple thing: set up a PJSIP-trunk between [A] and [B} without any registration or authentication. However, inbound authentication on [B] persists even though it is not enabled.

Trunk configuration for [A]:

Trunk configuration for [B]:

[oleg@LAB-03 ~]$ more /etc/asterisk/pjsip.conf


;============== SIP TRUNK TO =======




As you can see, no inbound or outbound auth is configured.
However, it is not actually disabled - node [B] is still trying to authenticate [A].
It replies with “401 Unathorized” to all OPTIONS and INVITE requests coming from [A]:

Am I missing / confusing anything in the configuration or it is a known bug?

Thank you in advance.

in order to be able to receive calls with no authentication you need to use on chan sip the option insecure=invite I suggest you send no authenticated calls to an special context

insecure=invite is related to chan_sip driver. Which options should I use for PJSIP driver?

As for not requiring username/password, if there is no inbound_auth configured then pjsip won’t challenge for auth.

Just dont use the type=auth

Thank you. However, as you can see from the provided excerpt of pjsip.conf, I do not refer to any auth object in my trunk configuration. What else am I doing wrong?

I dont use pjsip in production yet, but would be good to enable the type=identify it will allow you to indentify the inbound traffic per IP or by pulling the user from the “From:” SIP header in the packet, if you dont have enable it will do it by the from header, but I think you should one to be indentify by IP instead

Your traffic isn’t being associated with an endpoint. For security reasons we fake an authentication, so that anyone trying to find accounts receives the same response for accounts that both require authentication and don’t exist. You need an identify section to associate the incoming traffic to the endpoint. On the calling side having the from user set to “10-33-3-44” would also allow it to match.

Initially, identify section was not commented out, but the issue persisted.
I commented it out during troubleshooting activities. Will try again.

Is it enough to specify these instructions in identify or smth. else is needed?

That should be enough. You can use “pjsip set logger on” to see the incoming traffic including where it is coming from, and there are CLI commands that allow you to inspect and see what is configured to ensure the section is there.

Although not related to pjsip, it is sufficient to omit secret. If you need to authenticate the other way, use remotesecret. insecure=invite doesn’t fully disable authentication, even when Asterisk is UAS.

I uncommented identify, restarted asterisk, but this does not resolve the issue.
Information in console logs enabled by ‘pjsip set logger on’ repeats what I see in the packet traces:

<— Received SIP request (429 bytes) from UDP: —>
OPTIONS sip: SIP/2.0
Via: SIP/2.0/UDP;rport;branch=z9hG4bKPj493a5a94-727d-4dec-bc40-db80e0f28168
From: sip:;tag=28df4c36-12c5-450e-b467-0cb934e8365e
To: sip:
Contact: sip:
Call-ID: a70bf395-a52d-45c9-8b3a-a7a80fc53a2c
CSeq: 9521 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-
Content-Length: 0

<— Transmitting SIP response (534 bytes) to UDP: —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP;rport=5060;received=;branch=z9hG4bKPj493a5a94-727d-4dec-bc40-db80e0f28168
Call-ID: a70bf395-a52d-45c9-8b3a-a7a80fc53a2c
From: sip:;tag=28df4c36-12c5-450e-b467-0cb934e8365e
To: sip:;tag=z9hG4bKPj493a5a94-727d-4dec-bc40-db80e0f28168
CSeq: 9521 OPTIONS
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1501377143/14b09b99f1d30de442fd7c5d9c9e48ce”,opaque=“7b438d4417b458a4”,algorithm=md5,qop=“auth”
Content-Length: 0

No errors / warnings, although the verbosity level is high. Any other ideas?

P.S. For clarity, please find attached full pjsip.conf file with public IPs and secrets obfuscated.
pjsip.txt (1.0 KB)

Did you use the CLI commands to determine that the identify section was properly read? It would be “pjsip show identify 10-33-3-44”.

Yes - everything looks correct there.
SIPS*CLI> pjsip show identify 10-33-3-44

Identify: <Identify/Endpoint…>
Match: <ip/cidr…>

Identify: 10-33-3-44/10-33-3-44

ParameterName : ParameterValue

endpoint : 10-33-3-44
match :

What else can I check?

Nothing else immediately comes to mind, but it’s definitely something in your configuration. If you enable debug in logger.conf to console, do “core set debug 5”, and then attempt a call or see an OPTIONS coming in do you see any messages about an endpoint being used? (provide the output if possible)

Yes, it’s interesting!
Look at the last line (in bold). For some strange reason, it refers to From field… Why?

Module ‘logger’ reloaded successfully.
== Parsing ‘/etc/asterisk/logger.conf’: Found
Asterisk Queue Logger restarted
[Jul 29 22:29:23] DEBUG[2555]: pjsip:0 <?>: sip_endpoint.c Processing incomi ng message: Request msg OPTIONS/cseq=11691 (rdata0x7f017c001878)
<— Received SIP request (430 bytes) from UDP: —>
OPTIONS sip: SIP/2.0
[… truncated …]

[Jul 29 22:29:23] DEBUG[2555]: netsock2.c:172 ast_sockaddr_split_hostport: Split ting ‘’ into…
[Jul 29 22:29:23] DEBUG[2555]: netsock2.c:226 ast_sockaddr_split_hostport: …ho st ‘’ and port ‘’.
[Jul 29 22:29:23] DEBUG[2621]: pjsip:0 <?>: sip_endpoint.c Distributing rdat a to modules: Request msg OPTIONS/cseq=11691 (rdata0x7f017c006918)
[Jul 29 22:29:23] DEBUG[2621]: netsock2.c:172 ast_sockaddr_split_hostport: Split ting ‘’ into…
[Jul 29 22:29:23] DEBUG[2621]: netsock2.c:226 ast_sockaddr_split_hostport: …ho st ‘’ and port ‘’.
[Jul 29 22:29:23] DEBUG[2621]: res_pjsip_endpoint_identifier_ip.c:108 ip_identif y_match_check: Source address matches identify ‘10-33-3-44’
[Jul 29 22:29:23] DEBUG[2621]: res_pjsip_endpoint_identifier_user.c:106 username _identify: Could not identify endpoint by username ‘’

That’s expected. It looks like the identify did work, but the endpoint wasn’t returned. Looking back at it - your endpoint is invalid. “qualify” is not a valid option there. This would have produced a message at load time stating that the option was invalid and the endpoint wasn’t loaded.

[Please disregard this message]

The option has to be removed. It doesn’t exist in an endpoint.

1 Like

Thank you a lot!
Removing qualify resolved the issue.

<— Transmitting SIP request (417 bytes) to UDP: —>
OPTIONS sip: SIP/2.0
Via: SIP/2.0/UDP;rport;branch=z9hG4bKPj40599b30-4a1d-42c8-87b9-864ac5ca9e21
From: sip:;tag=c0d2366a-3a51-4260-9e6e-a38c880b9e07
To: sip:

<— Received SIP response (858 bytes) from UDP: —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP;rport=5060;received=;branch=z9hG4bKPj40599b30-4a1d-42c8-87b9-864ac5ca9e21
Call-ID: 40b21e2d-243a-4402-af82-8c0f943e8f3f
From: sip:;tag=c0d2366a-3a51-4260-9e6e-a38c880b9e07

For INVITEs it also works now.