Phone forced to register to PJSIP with every call

I have Grandstream DP750 base with DP720 handset configured with aterisk PJSIP.
In wireshark I see that with every phone call asterisk forces the phone to register to SIP server before making a call.

From what I understand, the DP750 base after powering up, makes an initial register to the server and keeps a session.
pjsip show endpoints:

 Endpoint:  121/121                                              Not in use    0 of inf
     InAuth:  auth121/121
        Aor:  121                                                1
      Contact:  121/sip:121@10.100.0.3:23599               8865771ce9 NonQual         nan
  Transport:  udp-transport             udp      0      0  0.0.0.0:5060

Here’s how it looks like. I make a call to extension 777. The DP750 base has an IP 10.100.0.3.

So I don’t understand why asterisk sends 401 Unauthorized message with every phone call and asks for authentication.

Asterisk does NOT force to re-register.
Your phone registers once and refreshes it every few minutes with a REGISTER message.
Thus, the phone is able to receive inbound calls.

When your phone places an outbound call it needs to authenticate, for every single call.
This is by standard and therefore expected behaviour.
The 401 message is needed for the phone to receive a digest nonce from the server (see Challenge Response Authentication for details).

What you see is not an error, it’s normal behaviour :wink:

Asterisk request Authorization for the INVITE (call), not REGISTER.

If such additional authorization is a problem for GrandStream ( I think its not), you can disable additional authorization by adding:

insecure=invite

Or, if you use custom SIP port( different from default ), you can also allow it with appending ‘port’ option:

insecure=port,invite

after reload config, asterisk will ‘TRUST’ to INVITE requests from your grandstream, will still ask for pssword for REGISTER request

As I understand it, insecure=port is only needed if the port changes dynamically.

Also, I believe that insecure only applies to chan_sip.

Hi Devid,

Port dynamically, or statically set - does not matter, it helps for all
cases where non-default peer remote PORT number is used ( but this not the
question in this discussion )

PJSIP do not have ‘insecure’ ? I did not know.
according to thread :

→ if there is no inbound_auth configured then we won’t challenge for
auth.

This applies to REGISTER as well.

The normal case for insecure=invite was with ITSP’s who never register and never authenticate themselves. However, I think that remotesecret better describes that case, except that everyone copies samples without thinking about them.

The code that is controlled by insecure=port is:

ast_sockaddr_port(&peer->addr) == ast_sockaddr_port(&peer2->addr) ?
			(CMP_MATCH | CMP_STOP) : 0;

That doesn’t care whether the port is standard or not, only whether it is that currently recorded against the peer.

My issue here is that the option is called insecure for a reason, but people simply copy it from samples without considering whether it is actually necessary. ITSPs will tend to give insecure options, because the call is less likely to fail.

As for me, If I trust to remote server peer IP (its mine voip GSM gateway,
or it well known device), I would better set insecure=invite, then fighting
with remote server and forcing it correctly answer on SIP 401 authentication
request on INVITE.

 What I ment about the port:   If server uses any port(for example 5656), 

which is different from default ( 5060 ) would require setting either
insecure=port, either explicitly set port=5656 on the remote peer conf
Yes - it could be dynamic as well.

As long as you configure the port in the peer entry, or the peer registers from that port, I don’t think it matters whether it is 5060 or not, as long as it is the one configured, or the one used in the registration.

The only time I’ve needed to use it is for TCP, where a random source port is typically used.

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