401 UnAuthorized despite configuration was working

Hi there,

Since Today I am experiencing a 401 UnAuthorized from my local Asterisk. I have two devices configured at SIP.conf and one Trunk SIP at PJSIP.

The configuration was working until yesterday, but I noticed in the past from time to time I got same issue of 401 and I took for granted it was related to WIFI issue and I simply execute SIP reload to refresh ..that work in the past now I got consistently 401.

The only configuration change I did yesterday and it was working is the following at PJSIP.conf, I reverted the original I was using and restart all ..and so far not ok.

auth_type=userpass —> auth_type=digest —> auth_type=userpass.

Enabling SIP debug at CLI was working ok Yesterday, Today I see no traffic at all, I have to go for ngrep to retrieve SIP messages where I found the 401.

I am struggling I was using this box to testing my integration with a SIP Bridge component for an AI Project and now I am stuck, not so sure what the issue is.

Asterisk is located at 192.168.0.64

Devices at 192.168.0.21 y 39

Digging at AMI I can see service rejecting Auth seems to be PJSIP ..how come ?? I have config for devices at SIP. See last trace with event please

Kind regards,

Juan Antonio

sip.conf

; Configuration added by eeijcea 30/10/2025

bindport=5060

bindaddr=192.168.0.64

externip=

localnet=192.168.1.0/255.255.255.0 ; Ajusta a tu red interna real

authfailureevents=yes

;nat=force_rport,comedia

;srvlookup=yes

; Added by eeijcea 22/10/2025

[eeijcea]

type=friend

secret=mysecret

host=dynamic

context=interno

callerid=“eeijcea” <1500>

[edjurevicb]

type=friend

secret=mysecret2

host=dynamic

context=interno

callerid=“edjurevicb” <1501>

pjsip.conf

; Added by eeijcea 31/10

[system-local-udp]

type=transport

protocol=udp

bind=192.168.0.64

[system-local-tcp]

type=transport

protocol=tcp

bind=192.168.0.64

[livekit_trunk_auth] ; Aunque no uses auth, esta sección puede mantenerse vacía o omitirse

type=auth

;auth_type=digest

auth_type=userpass

username=gambito

password=SecretOUT

[livekit_trunk_aor]

type=aor

max_contacts=1

contact=sip:192.168.0.39:5060

;remove_existing=true

[livekit_trunk_endpoint]

type=endpoint

context=from-livekit

disallow=all

allow=ulaw,alaw

transport=system-local-udp

aors=livekit_trunk_aor

auth=livekit_trunk_auth ; Opcional, si no hay auth se puede omitir

;identify=livekit-trunk-identify

;direct_media=no

;force_rport=yes

;rewrite_contact=yes

[livekit_trunk_identify]

type=identify

endpoint=livekit_trunk_endpoint

match=192.168.0.39

REGISTER SIP Traces

#

U 192.168.0.39:57214 → 192.168.0.64:5060 #1

REGISTER sip:192.168.0.64 SIP/2.0..Via: SIP/2.0/UDP 192.168.0.39:57214;rport;branch=z9hG4bKPjg7Em8OwxShGXToPzeMiTSKeStuTrJGat..Max-Forwards: 70..From: “eeijcea” <sip:eeijcea@192.168.0.64>;tag=K

LvGFOfRNVbg7o5C57OYzWDJ1TjCpqCO..To: “eeijcea” <sip:eeijcea@192.168.0.64>..Call-ID: MDZHZeng7hBnT6cNHWuVyM4eOknBtgo3..CSeq: 6365 REGISTER..User-Agent: Telephone 1.6..Contact: “eeijcea” <sip:eei

jcea@192.168.0.39:57214;ob>..Expires: 300..Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS..Content-Length: 0…

#

U 192.168.0.64:5060 → 192.168.0.39:57214 #2

SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP 192.168.0.39:57214;rport=57214;received=192.168.0.39;branch=z9hG4bKPjg7Em8OwxShGXToPzeMiTSKeStuTrJGat..Call-ID: MDZHZeng7hBnT6cNHWuVyM4eOknBtgo3..From

: “eeijcea” <sip:eeijcea@192.168.0.64>;tag=KLvGFOfRNVbg7o5C57OYzWDJ1TjCpqCO..To: “eeijcea” <sip:eeijcea@192.168.0.64>;tag=z9hG4bKPjg7Em8OwxShGXToPzeMiTSKeStuTrJGat..CSeq: 6365 REGISTER..WWW-Aut

henticate: Digest realm=“asterisk”,nonce=“1762172624/98c3208179ddd8aa56213381979824e7”,opaque=“0a5260187a6bf69d”,algorithm=md5,qop=“auth”..Server: Asterisk PBX 13.18.3~dfsg-1ubuntu4..Content-L

ength: 0…

#

U 192.168.0.39:57214 → 192.168.0.64:5060 #3

REGISTER sip:192.168.0.64 SIP/2.0..Via: SIP/2.0/UDP 192.168.0.39:57214;rport;branch=z9hG4bKPj.a.-6cWBOEXgHs62HgaFHct9HtqMh8qh..Max-Forwards: 70..From: “eeijcea” <sip:eeijcea@192.168.0.64>;tag=KLvGFOfRNVbg7o5C57OYzWDJ1TjCpqCO..To: “eeijcea” <sip:eeijcea@192.168.0.64>..Call-ID: MDZHZeng7hBnT6cNHWuVyM4eOknBtgo3..CSeq: 6366 REGISTER..User-Agent: Telephone 1.6..Contact: “eeijcea” <sip:eei

jcea@192.168.0.39:57214;ob>..Expires: 300..Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS..Authorization: Digest username=“eeijcea”, realm=“asterisk”, nonce=“1762172624/98c3208179ddd8aa56213381979824e7”, uri=“sip:192.168.0.64”, response=“78b5ac967eea3e7d61bdf58962fd0819”, algorithm=md5, cnonce=“c6cWuYviMOf.3PiNz0vpXrHjiaaRCIO”, opaque

=“0a5260187a6bf69d”, qop=auth, nc=00000001..Content-Length: 0…

#

U 192.168.0.64:5060 → 192.168.0.39:57214 #4

SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP 192.168.0.39:57214;rport=57214;received=192.168.0.39;branch=z9hG4bKPj.a.-6cWBOEXgHs62HgaFHct9HtqMh8qh..Call-ID: MDZHZeng7hBnT6cNHWuVyM4eOknBtgo3..From

: “eeijcea” <sip:eeijcea@192.168.0.64>;tag=KLvGFOfRNVbg7o5C57OYzWDJ1TjCpqCO..To: “eeijcea” <sip:eeijcea@192.168.0.64>;tag=z9hG4bKPj.a.-6cWBOEXgHs62HgaFHct9HtqMh8qh..CSeq: 6366 REGISTER..WWW-Aut

henticate: Digest realm=“asterisk”,nonce=“1762172624/98c3208179ddd8aa56213381979824e7”,opaque=“754b2fa90a65b8ba”,algorithm=md5,qop=“auth”..Server: Asterisk PBX 13.18.3~dfsg-1ubuntu4..Content-L

ength: 0….

AMI AUTH Events traces.

Event: ChallengeSent

Privilege: security,all

EventTV: 2025-11-03T15:15:51.980+0100

Severity: Informational

Service: PJSIP

EventVersion: 1

AccountID: livekit_trunk_endpoint

SessionID: Jf7qiY7DOY9Sn9.OEBmhpOI1-fNmPxvi

LocalAddress: IPV4/UDP/192.168.0.64/5060

RemoteAddress: IPV4/UDP/192.168.0.39/57214

Challenge:

Event: ChallengeResponseFailed

Privilege: security,all

EventTV: 2025-11-03T15:15:51.990+0100

Severity: Error

Service: PJSIP

EventVersion: 1

AccountID: livekit_trunk_endpoint

SessionID: Jf7qiY7DOY9Sn9.OEBmhpOI1-fNmPxvi

LocalAddress: IPV4/UDP/192.168.0.64/5060

RemoteAddress: IPV4/UDP/192.168.0.39/57214

Challenge: 1762179351/b9400aebbedda862ebe0980e131d8618

Response: 0200a6512c4e056fe66164a87319f984

ExpectedResponse:

You can’t have two different services on the same port number. If you try to do that in FreePBX, chan_pjsip gets the standard port number.

Also, if livekit represents a service provider, note that service providers generally will not authenticate themselves, so, if that applies, the “auth=livekikt_trunk_auth”, will cause a 401 to be sent, but the other end wll not have the credentials to allow it to respond.

Actually this isn’t FreePBX, in which case there will be no automatic resolution of the the conflict, and only one of the two channel drivers will successfully claim port 5060, presumably the first one that is attempted, which might depend on the physical order of files in a directory.