Register, but no dynamic contact, and inbound call auth failure

Good evening. Just playing around with the various config options as I get ready to deep dive into Asterisk after having not touched it in quite a few years… And, for context, this is not FPBX, this is a fresh Asterisk compile and install.

So, I’ve got PJSIP configured. Initially, I had it set to register as an extension off my company PBX. Had some issues with that but eventually got it working with some static config. I guess I had expected that when Asterisk registered, it would then auto update the AOR and CONTACT info. It did not, so although I had it registered, I coudln’t actually call into it. I ended up building an identity block and identifying the SIP server to associate the contact, and that worked fine until I then needed my second registration. Now, everything coming in was matching to the first registration.

So, I’ve been messing with it all night trying to decouple the server IP from the identity of the particular endpoint. I don’t know if there’s a parameter I need to set in a config file somewhere that tells PJSIP that it’s ok to trust a sender that you’ve registered with, but it’s definitely having trust issues. I’ve tried telling it to identify by username and auth_username, it still doesn’t marry up inbound calls to the registered channel (I even tried telling it to match the TO header, and even with a dead match, it’s not finding the match to that either.

What’s even stranger (to me), is that although it’s registered (via TCP, so NAT isn’t going to be an issue), the endpoints are listed as unavailable.

Here’s what should be the relevant parts of the config:

[nightring_01](nightring)
type=endpoint
aors=nightring_01
allow=ulaw,alaw
direct_media=no
rewrite_contact=yes
identify_by=auth_username,username
100rel=no
trust_id_inbound=yes
rtp_symmetric=yes
inband_progress=yes
media_use_received_transport=yes

[nightring_01]
type=aor
max_contacts=1
remove_existing=yes
qualify_frequency=60
qualify_timeout=3.0
contact=sip:6999@UE-Lab <----Really hoped this would be dynamic with the registration (or that I could tell it to do so)

[nightring_01](auth-nightring)
username=6999@UE-Lab
password=<REDACTED>

[auth-nightring](!)
type=auth
auth_type=userpass

[nightring_01](tcpv4)
type=registration
outbound_auth=nightring_01
client_uri=sip:6999@UE-Lab
contact_user=6999
endpoint=nightring_01

[tcpv4](!)
transport=transport-tcpv4
server_uri=sip:<REDACTED>:5060
outbound_proxy=sip:<REDACTED>:5060
retry_interval=60
line=yes

[transport-tcpv4]
type=transport
protocol=tcp
bind=0.0.0.0:5060
tcp_keepalive_enable=yes
tcp_keepalive_idle_time=60
tcp_keepalive_interval_time=60
tcp_keepalive_probe_count=5

Inbound call attempts flood the console with this:

[Mar  4 03:22:03] NOTICE[1641]: res_pjsip/pjsip_distributor.c:688 log_failed_request: Request 'INVITE' from '"Desk Phone" <sip:1002@UE-Lab>' failed for '<REDACTED>:5060' (callid: 20250304032203011128-b23b1709ac279b1a99e7bfbff6dce780) - No matching endpoint found
[Mar  4 03:22:03] NOTICE[1641]: res_pjsip/pjsip_distributor.c:688 log_failed_request: Request 'INVITE' from '"Desk Phone" <sip:1002@UE-Lab>' failed for '<REDACTED>:5060' (callid: 20250304032203011128-b23b1709ac279b1a99e7bfbff6dce780) - Failed to authenticate

Why? You need to know this information locally in order to be able to register in the first place. More generally, a SIP registrant doesn’t have to be the entity the contact address, so the contacted entity may not see the registration response.

These:

are not really compatible with:

you should only have the latter.

If supported by the company PBX (really should be as it just requires correct implementation of a SIP registrar), the line option of type=register should handle this. If not, you need to use contact user and resolve the endpoints in the dialplan.

I think I need protocol logs for this, but I think you may be making assumptions about the purposes for which the TCP connection can be used.

Your configuration and logs are not marked up correctly, for the forum.

type=endpoint
aors=nightring_01
allow=ulaw,alaw
direct_media=no
rewrite_contact=yes
identify_by=auth_username,username
100rel=no
trust_id_inbound=yes
rtp_symmetric=yes
inband_progress=yes
media_use_received_transport=yes

[nightring_01]
type=aor
max_contacts=1
remove_existing=yes
qualify_frequency=60
qualify_timeout=3.0
contact=sip:6999@UE-Lab. <----Really hoped this would be dynamic with the registration so I wouldn't have to set it.

[nightring_01](auth-nightring)
username=6999@UE-Lab
password=<REDACTED>

[auth-nightring](!)
type=auth
auth_type=userpass

[nightring_01](tcpv4)
type=registration
outbound_auth=nightring_01
client_uri=sip:6999@UE-Lab
contact_user=6999
endpoint=nightring_01

[tcpv4](!)
transport=transport-tcpv4
server_uri=sip:<REDACTED>:5060
outbound_proxy=sip:<REDACTED>:5060
retry_interval=60
line=yes

[transport-tcpv4]
type=transport
protocol=tcp
bind=0.0.0.0:5060
tcp_keepalive_enable=yes
tcp_keepalive_idle_time=60
tcp_keepalive_interval_time=60
tcp_keepalive_probe_count=5

Inbound call attempts flood the console with this:
[Mar  4 03:22:03] NOTICE[1641]: res_pjsip/pjsip_distributor.c:688 log_failed_request: Request 'INVITE' from '"Desk Phone" <sip:1002@UE-Lab>' failed for '<REDACTED>:5060' (callid: 20250304032203011128-b23b1709ac279b1a99e7bfbff6dce780) - **No matching endpoint found**
[Mar  4 03:22:03] NOTICE[1641]: res_pjsip/pjsip_distributor.c:688 log_failed_request: Request 'INVITE' from '"Desk Phone" <sip:1002@UE-Lab>' failed for '<REDACTED>:5060' (callid: 20250304032203011128-b23b1709ac279b1a99e7bfbff6dce780) - **Failed to authenticate**

I see you do have a line parameter. Maybe it does go on the transport, but the you haven’t referenced the transport from the type=register, so you will get the default transport.

Actually, it is in the type=register. The bad markup confused me.

However, I think that templates cannot be forward referenced.

I went back and marked them up as code blocks (sorry, it was late last night) :slight_smile:

contact=” was only added as (hopefully) a temporary measure because the registration itself didn’t seem to update the contact in “show contacts”. I take it by your comment about “type=register should handle this” that my belief was correct (prior to the addition of contact, it would register and have no contact).

I don’t believe “line=yes” goes on the transport because when I remove it from the endpoint, it gets mad (“endpoint specified without enabling line support”). I did just test it to confirm though.

I know the cascading templates may look a little wonky, but they do work and do have a logical flow for what we’re doing. The purpose for them is to extend just a “registrations” file to an editable location allowing the editing of the SIP credentials, without exposing the items we want to be static (like the server - that’s why I was bummed when it seemed like I needed “contact=”, as those parts are currently in the “protected” section - granted, I could take care of that with scripting).

Previously I also had an “identify” block, but in my digging, it seemed like the very existence of that block negated dynamic updates (as I was essentially saying “This is how you can identify this device, so ignore what you’d normally derive from registration”.

So it sounds like, indeed, it should be updating the contact with registration, suggesting my registration may be malformed somehow.

AsteriskServer*CLI> pjsip send register  nightring_01
<--- Transmitting SIP request (518 bytes) to TCP:<REDACTED-SERVER-PUBLIC-IP>:5060 --->
REGISTER sip:<REDACTED-SERVER-DNS>:5060 SIP/2.0
Via: SIP/2.0/TCP <REDACTED-ASTERISK-PRIVATE-IP>:5060;rport;branch=z9hG4bKPj1d119b49-6213-43e2-9ee9-acdfa824b876;alias
From: <sip:6999@UE-Lab>;tag=13839d06-6cf6-443f-b8e9-2b7ac3e83094
To: <sip:6999@UE-Lab>
Call-ID: d4814263-ed0f-40a5-97a8-eec33e3c5caa
CSeq: 41154 REGISTER
Contact: <sip:6999@<REDACTED-ASTERISK-PRIVATE-IP>:5060;transport=TCP;line=lidsrzk>
Expires: 0
Route: <sip:<REDACTED-SERVER-DNS>:5060>
Max-Forwards: 70
User-Agent: Asterisk PBX 22.2.0
Content-Length:  0

<--- Received SIP response (502 bytes) from TCP:<REDACTED-SERVER-PUBLIC-IP>:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/TCP <REDACTED-ASTERISK-PRIVATE-IP>:5060;branch=z9hG4bKPj1d119b49-6213-43e2-9ee9-acdfa824b876;alias;received=<REDACTED-ASTERISK-PUBLIC-IP>;rport=38691
To: <sip:6999@UE-Lab>
From: <sip:6999@UE-Lab>;tag=13839d06-6cf6-443f-b8e9-2b7ac3e83094
Call-ID: d4814263-ed0f-40a5-97a8-eec33e3c5caa
CSeq: 41154 REGISTER
Contact: <sip:6999@<REDACTED-ASTERISK-PRIVATE-IP>:5060;transport=TCP;line=lidsrzk>
Expires: 0
Server: SiPBx v44-2-1
Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,UPDATE,REFER,SUBSCRIBE
Content-Length: 0

<--- Transmitting SIP request (623 bytes) to TCP:<REDACTED-SERVER-PUBLIC-IP>:5060 --->
REGISTER sip:<REDACTED-SERVER-DNS>:5060 SIP/2.0
Via: SIP/2.0/TCP <REDACTED-ASTERISK-PRIVATE-IP>:5060;rport;branch=z9hG4bKPj55407874-ea50-4f22-ac33-39680ef4ac37;alias
From: <sip:6999@UE-Lab>;tag=2854a388-7ad1-4957-906d-e512b8d5a75f
To: <sip:6999@UE-Lab>
Call-ID: d4814263-ed0f-40a5-97a8-eec33e3c5caa
CSeq: 41155 REGISTER
Contact: <sip:6999@<REDACTED-ASTERISK-PRIVATE-IP>:5060;transport=TCP;line=lidsrzk>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Route: <sip:<REDACTED-SERVER-DNS>:5060>
Max-Forwards: 70
User-Agent: Asterisk PBX 22.2.0
Content-Length:  0

<--- Received SIP response (436 bytes) from TCP:<REDACTED-SERVER-PUBLIC-IP>:5060 --->
SIP/2.0 407 Proxy Authentication Required
Proxy-Authenticate: Digest realm="UE-Lab", nonce="<REDACTED>"
Via: SIP/2.0/TCP <REDACTED-ASTERISK-PRIVATE-IP>:5060;branch=z9hG4bKPj55407874-ea50-4f22-ac33-39680ef4ac37;alias;received=<REDACTED-ASTERISK-PUBLIC-IP>;rport=38691
To: <sip:6999@UE-Lab>
From: <sip:6999@UE-Lab>;tag=2854a388-7ad1-4957-906d-e512b8d5a75f
Call-ID: d4814263-ed0f-40a5-97a8-eec33e3c5caa
CSeq: 41155 REGISTER
Content-Length: 0

<--- Transmitting SIP request (825 bytes) to TCP:<REDACTED-SERVER-PUBLIC-IP>:5060 --->
REGISTER sip:<REDACTED-SERVER-DNS>:5060 SIP/2.0
Via: SIP/2.0/TCP <REDACTED-ASTERISK-PRIVATE-IP>:5060;rport;branch=z9hG4bKPj18d2f67b-a8ad-4a24-9882-34190ee36357;alias
From: <sip:6999@UE-Lab>;tag=2854a388-7ad1-4957-906d-e512b8d5a75f
To: <sip:6999@UE-Lab>
Call-ID: d4814263-ed0f-40a5-97a8-eec33e3c5caa
CSeq: 41156 REGISTER
Contact: <sip:6999@<REDACTED-ASTERISK-PRIVATE-IP>:5060;transport=TCP;line=lidsrzk>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Max-Forwards: 70
User-Agent: Asterisk PBX 22.2.0
Proxy-Authorization: Digest username="6999@UE-Lab", realm="UE-Lab", nonce="<REDACTED>", uri="sip:<REDACTED-SERVER-DNS>:5060", response="<REDACTED>"
Route: <sip:<REDACTED-SERVER-DNS>:5060>
Content-Length:  0

<--- Received SIP response (513 bytes) from TCP:<REDACTED-SERVER-PUBLIC-IP>:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/TCP <REDACTED-ASTERISK-PRIVATE-IP>:5060;branch=z9hG4bKPj18d2f67b-a8ad-4a24-9882-34190ee36357;alias;received=<REDACTED-ASTERISK-PUBLIC-IP>;rport=38691
To: <sip:6999@UE-Lab>
From: <sip:6999@UE-Lab>;tag=2854a388-7ad1-4957-906d-e512b8d5a75f
Call-ID: d4814263-ed0f-40a5-97a8-eec33e3c5caa
CSeq: 41156 REGISTER
Contact: <sip:6999@<REDACTED-ASTERISK-PRIVATE-IP>:5060;transport=TCP;line=lidsrzk>
Expires: 3600
Server: SiPBx v44-2-1
Allow: INVITE, ACK, CANCEL, BYE, INFO, OPTIONS, UPDATE, REFER, SUBSCRIBE
Content-Length: 0

AsteriskServer*CLI> pjsip show registrations

 <Registration/ServerURI..............................>  <Auth....................>  <Status.......>
==========================================================================================
 nightring_01/sip:<REDACTED-SERVER-DNS>:5060    nightring_01                Registered        (exp. 3582s)

An outbound registration has no impact on LOCAL contacts or AORs. It’s up to you to configure it with how to reach the remote side. An outbound registration merely tells the REMOTE side how to reach you. The line support CAN be used with some remote servers to identify traffic FROM them, but it requires them to adhere to the RFC and some don’t. Otherwise you have to use “identify” and match based on source IP address/network, or based on some header.

No. I’m saying that line should be in the type=register section. My first point was that the contact should be explicit in the type=aor section, with the added explanation that the type=register, in theory, might not even be on the same machine (although it would have to be for line to work).

I was reacting to the bad markup, and saying I might have been wrong about the type=register section.

If it is objecting to endpoint, when you remove line=, maybe it is allowing forward references to templates, but I would always put the template before the reference. If it is accepting line parameter, it suggests the endpoint is not returning the full contact URI. You should get protocol logs to confirm that it is being sent in the REGISTER Contact, but not returned in the request URI. In that case, you will have to use contact user, and use the dialplan to separate the the endpoints.

Actually, you don’t seem to have a From User set on the endpoint, which may confuse the endpoint, although it should really be using the client URI to determine who is registering.

That all makes sense to me. What was bothering me was, I was trying to match on:

match_header=To: <sip:6999@UE-Lab>

which was a direct cut/paste out of an invite, but it never seemed to match. That seems like a perfectly workable solution for the match, but for some reason it just didn’t seem to find the match.

Here’s an attempted invite as well (since trying to match on header)…

Also, “max_contacts=x” was meant to only permit x simultaneous calls - I realize that was in error and not the correct parameter for that need.

PJSIP Logging enabled
<--- Received SIP request (1079 bytes) from TCP:<REDACTED-SERVER-PUBLIC-IP>:5060 --->
INVITE sip:6999@<REDACTED-ASTERISK-PRIVATE-IP>:5060 SIP/2.0
Via: SIP/2.0/TCP <REDACTED-SERVER-PUBLIC-IP>:5060;branch=z9hG4bKjFhNbIL8DawjA9eV0111A0
Call-ID: 20250304150501042860-b23b1709ac279b1a99e7bfbff6dce780
Contact: <sip:<REDACTED-SERVER-PUBLIC-IP>:5060;transport=tcp>
CSeq: 201 INVITE
From: "Desk Phone" <sip:1002@UE-Lab>;tag=8OgPPzCgmvtpxMOK01119F
Max-Forwards: 20
To: <sip:6999@UE-Lab>
Date: Tue, 04 Mar 2025 15:05:01 GMT
Server: SiPBx v44-2-1
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Supported: timer
Min-SE: 90
Session-Expires: 180;refresher=uac
Content-Type: application/sdp
Content-Length: 445

v=0
o=NetSapiens_Nms 8000 8000 IN IP4 <REDACTED-SERVER-PUBLIC-IP>
s=SIP Call
c=IN IP4 <REDACTED-SERVER-PUBLIC-IP>
t=0 0
m=audio 26140 RTP/AVP 9 13 0 8 123 2 4 18 97 101
a=sendrecv
a=rtpmap:9 G722/8000
a=ptime:20
a=rtpmap:13 CN/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:123 opus/48000/2
a=rtpmap:2 G726-32/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

[Mar  4 15:05:01] NOTICE[2712]: res_pjsip/pjsip_distributor.c:688 log_failed_request: Request 'INVITE' from '"Desk Phone" <sip:1002@UE-Lab>' failed for '<REDACTED-SERVER-PUBLIC-IP>:5060' (callid: 20250304150501042860-b23b1709ac279b1a99e7bfbff6dce780) - No matching endpoint found
<--- Transmitting SIP response (533 bytes) to TCP:<REDACTED-SERVER-PUBLIC-IP>:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP <REDACTED-SERVER-PUBLIC-IP>:5060;rport=5060;received=<REDACTED-SERVER-PUBLIC-IP>;branch=z9hG4bKjFhNbIL8DawjA9eV0111A0
Call-ID: 20250304150501042860-b23b1709ac279b1a99e7bfbff6dce780
From: "Desk Phone" <sip:1002@UE-Lab>;tag=8OgPPzCgmvtpxMOK01119F
To: <sip:6999@UE-Lab>;tag=z9hG4bKjFhNbIL8DawjA9eV0111A0
CSeq: 201 INVITE
WWW-Authenticate: Digest realm="asterisk",nonce="<REDACTED>",opaque="<REDACTED>",algorithm=MD5,qop="auth"
Server: Asterisk PBX 22.2.0
Content-Length:  0

There is no line parameter information, in the request. You haven’t provided the register, to see if it was actually set on the Contact header.

I’ve never heard of matching on To. People generally use the dialplan, based on the request URI, or, in cases which don’t apply here, parse the user from the To header, and use it as a GoTo target, also using dialplan code.

1 Like

I had the register earlier in the this thread. Not only is it providing the LINE info, the host server responds back confirming the LINE info. I’ve got a ticket open with the manufacturer, since they clearly are confirming they accept the LINE parameter and aren’t using it moving forward.

Thanks for pointing me in the right direction. Admittedly, I didn’t even know about what the LINE option did, and how that maifested in the contact. :slight_smile:

A parameter, like that, should be returned as a header, of the same name. They won’t actually know what it means.

I agree. But if the system acknowledges it as part of the contact during registration (which it did), then they should be including it with all subsequent contact requests. Regardless of what it may or may not mean to them, in general it means “this is how you reach me”, and as of this moment (from what I can tell) their system is making an active decision to strip crucial elements of the endpoint’s contact, crippling the ability to contact it.

I ended up solving this issue with this:

[channel_01-identify]
type=identify
endpoint=channel_01
match_request_uri=/^sip:6666@/

After some digging, it turns out MATCH HEADER and MATCH REQUEST URI can be regex, which allowed a wildcard of just matching the registered extension. :slight_smile: