Registration always have an "Unauthorized" attempt, then success, then a "Not Found" response to OPTIONS

Asterisk Asterisk SIP
1

I am in the process of upgrading a very old Asterisk system to 18.3. Part of this process is moving to pjsip. I’m using pjsip_wizard.conf for configuration, and I’m at the point where it looks “Registered”:

asterisk*CLI> pjsip show registration vitelity-reg-0

 <Registration/ServerURI..............................>  <Auth..........>  <Status.......>
==========================================================================================
 vitelity-reg-0/sip:inbound5.vitelity.net                vitelity-oauth    Registered

 ParameterName            : ParameterValue
 ==============================================================
 @pjsip_wizard            : vitelity
 auth_rejection_permanent : true
 client_uri               : sip:vitel_subacct@inbound5.vitelity.net
 contact_header_params    :
 contact_user             :
 endpoint                 :
 expiration               : 3600
 fatal_retry_interval     : 0
 forbidden_retry_interval : 0
 line                     : false
 max_retries              : 10
 outbound_auth            : vitelity-oauth
 outbound_proxy           :
 retry_interval           : 60
 server_uri               : sip:inbound5.vitelity.net
 support_outbound         : no
 support_path             : false
 transport                : transport-udp-nat

One problem I’ve noticed is that when I do pjsip set logger on, every 60 seconds I’m seeing this exchange:

Tx > REGISTER sip:inbound5.vitelity.net SIP/2.0
Rx < SIP/2.0 100 Trying
Rx < SIP/2.0 401 Unauthorized
Tx > REGISTER sip:inbound5.vitelity.net SIP/2.0
Rx < SIP/2.0 100 Trying
Rx < SIP/2.0 200 OK
Tx > OPTIONS sip:inbound5.vitelity.net SIP/2.0
Rx < SIP/2.0 404 Not Found

The first 6 exchange above all have a From:/To: lines that I would expect:

From: <sip:vitel_subacct@inbound5.vitelity.net>;tag=0ac443a5-43e2-4cfb-9563-41b7726856fa
To: <sip:vitel_subacct@inbound5.vitelity.net>

but the last two messages above are using the internal IP address of the Asterisk server and have a different To line:

From: <sip:vitel_subacct@192.168.1.10>;tag=282e737c-7158-45ee-94c7-0bba2d458381
To: <sip:inbound5.vitelity.net>

So I have three questions:

  1. Does my pjsip show registration output seem “correct” for an ITSP SIP trunk?

  2. Can I prevent the repeated “Unauthorized” REGISTER attempt every 60s?

  3. What is causing the OPTIONS message and the resulting “Not Found” reply?

Thanks for any insight!

2
  1. If it works for you, it’s ok.
  2. No. It’s defined by the provider. See screenshot.
    register
    register1731×213 51.5 KB
  3. Maybe not supported by the ISP? Set qualify_frequency=0

Regarding wrong IP-address in options request: There should be the external IP address, too. Maybe a wrong NAT configuration?

Btw.: Don’t use UDP - use TCP or better TLS!

3

Thanks for taking the time to reply, micha.

  1. I was wondering if it looked like I missed anything. (This is my first foray into using pjsip.) I realize it may be “working”, but I’d prefer for it to be “optimal”.

  2. I understand that my provider sets the registration interval. I want to know how to avoid the useless SIP exchange (REGISTER / Trying / Unauthorized) that is happening every 60s before the successful REGISTER exchange.

  3. I have local_net, external_media_address and external_signaling_address configured in the transport-udp-nat stanza in pjsip.conf. I’m trying to understand why the OPTIONS message is being sent with the server’s internal IP address in the From: header. Are there some other settings I’m missing?

(As for using TCP/TLS, unless things have changed, last time I checked Vitelity is UDP-only. And that’s another bridge to cross later… right now I’d just like to get the old config working under 18.3.)

4

It’s not useless. It provides the random challenge (nonce) for the authentication. Nonces only have a short lifetime, so even trying with the same one as last time won’t normally help.

1 Like
5

Ah, thanks david551! The piece about the nonce in the first registration attempt is what I was missing, and makes sense. So that explains that, at least!

6

If anybody has any ideas :bulb: about the OPTIONS message (sent after the REGISTER exchange is completed) returning 404 Not Found, I’d be happy to try out some suggestions… :wink:

7

Not found isn’t a problem. Anything except no response at all indicates the peer is still there.

8

Hmm. :thinking: I thought it might be related to REGISTER using:

From: <sip:vitel_subacct@inbound5.vitelity.net>;tag=0ac443a5-43e2-4cfb-9563-41b7726856fa
To: <sip:vitel_subacct@inbound5.vitelity.net>

but OPTION sending this:

From: <sip:vitel_subacct@192.168.1.10>;tag=282e737c-7158-45ee-94c7-0bba2d458381
To: <sip:outbound.vitelity.net>

I was thinking the “Not Found” reply could be related to the lack of an account name in the To: header… but not sure what I’d need to adjust in pjsip_wizard.conf to try forcing a username to be included in that To:.

9

That probably is the reason, but it doesn’t need fixing, as the peer replied.

10

Thanks for taking the time to reply, david551. :+1: Much appreciated!

Seems silly to me to send a SIP OPTIONS message if it’s not doing anything useful… if for no other reason than it’s extra noise when I’m watching SIP debug logs.

  1. Assuming it serves no purpose, is there a setting to disable sending the OPTIONS message after each REGISTER?

  2. Alternatively, is there a way to add a username to the OPTIONS message’s To: header to see if that makes the peer reply back with an OK so it doesn’t seem like an error?

11

They serve the purpose of detecting whether there is something at the other end, so that you don’t have to wait for a timeout to know the call will fail, and also to calibrate the size of the timeout used, so you don’t resend prematurely.

For chan_sip, they are controlled by qualify and qualifyfreq(ency)

1 Like
12

Ah, that’s a good piece of info and an association that I was missing.

In pjsip_wizard.conf, I went ahead and set aor/qualify_frequency = 0 on my inbound trunk since it requires registration… and it stopped the OPTIONS message that generated the “Not Found” reply from being sent.

But it was unexpected that a successful REGISTER exchange doesn’t count as a successful “qualification”. Since my provider sets a 60s registration timeout, I’m already exchanging messages as frequently as setting aor/qualify_frequency = 60 would. But when it’s set to 0, it just shows up as NonQual. I was hoping to only need to send qualifications for the outbound endpoint. (My provider has separate hosts for inbound registration and outbound calls.)

In any case, thanks again for the insight, david551. I like to understand the reason for the traffic coming to/from my network and devices, and now it makes a bit more sense.

13

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