Insecure=invite for pjsip


In sip.conf we could configure an entity with insecure=invite for a sip peer.

How can i implement that when migrating to pjsip based endpoint from sip based sip peer?


PJSIP uses a separate configuration entry to do IP based matching. It’s configured using the “type=identify” section and is documented on the wiki[1]. You can also find an example[2].


Hi thanks for the quick reply.

To be accurate here is what i want to do —

I have one asterisk configured as the sip server where i have configured two endpoints A and B.

I have another asterisk that acts as a sip client. It registers from client asterisk as both A and B to server asterisk.

I want to make calls from client asterisk to the server asterisk as a regular sip client.

Is there any documents that tells me how to configure that for asterisk 13?

Sorry for the inconveniences.

You would use the same configuration in the examples basically for PJSIP connecting to an ITSP and for PJSIP connecting to clients. The most important option being “from_user” on the endpoint, so that when placing calls to the other Asterisk it can match the endpoint correctly.

Can i have two endpoints such as ‘endpoint_a’ and ‘endpoint_b’ in ‘server asterisk’ such that when the client registers for them they are authenticated using 401. But when client makes a call through ‘INVITE’ server asterisk does not challenge with 401?

PJSIP does not currently have the functionality to match based on registered IP address, you would need to know the IP address ahead of time or do username/password matching.

That;s not the problem that insecure=invite tries to solve; that is just broken.

insecure=invite handles the case of your registering with an ITSP. Typically ITSPs do not authenticate themselves to you. insecure=invite stops your insisting on such authentication.

Whilst I haven’t used pjsip, I’m concerned that you are misunderstanding what insecure=invite does; it is not about matching.

I’m also concerned that you are saying that it will not match based on an IP address obtained from a registration. I guess it can still use the IP address for the UAC role, but it sounds broken to me that it won’t use a learned IP address for the UAS role.

I always get that option confused as it is poorly named along with the values.

As for being broken - the act of matching a SIP request to an endpoint in PJSIP is pluggable so we could add it, but over the past 3+ years it has come up maybe 4 times. People just don’t seem to need that behavior for dynamic registrations.

Static IP addresses can of course be configured and matched though.

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

The system i am working on has a long history. Currently it is using asterisk 1.8 for both the ‘server asterisk’ and ‘client asterisk’. I needed one asterisk (client*) to behave like a normal sip client (e.g a sip phone) which can register as multiple sip peer and receive calls and make calls. kindof like this
caller — ‘server*’ ---- ‘client*’ ---- ‘server*’ — callee

Depending on which sip peer is called by the ‘caller’ the ‘client*’ needs to answer as that peer and make a call as that peer to the callee and bridge them. In the ‘client*’ i used ‘register’ command from sip.conf. It registered just fine but failed to authenticate during INVITE. So i configured those sip peers as insecure=invite.

Now i need to upgrade the ‘server*’ asterisk to 13. But for some business constraint have to keep the ‘client*’ in asterisk 1.8.

In the ‘server*’ i have used pjsip. I need the ‘server*’ to behave just like before.

I tried the pjsip identify object. Because of lack of my knowledge in that so far i failed. I added one entry for each endpoint in the identify object like this —
‘endpoint_a’ — match:
’endpoint_b’ — match:
I face an issue in the registration itself. Only one endpoint registers successfully. So i could not test or configure further.

Question is — Can i achieve that? if yes how. if no, i need to know that it cant be done. So that we can move on.

Sorry for the trouble. All your responses are much appreciated.


We’d need to see the actual full configuration for everything and the logs to go deeper into this. I will say for the match - you can’t have two match with the same IP address going to different endpoints. It won’t work.

1 Like