Hi,
After upgrading asterisk (13 -> 16.0.1) no incoming calls get through. Asterisk complains: “No matching peer for +358… from aaa.bbb.ccc.dddd:ppppp” and sends SIP/2.0 401 Unauthorized. The calls come via a SIP trunk provider (Twilio).
All ip addresses used by the trunk provider are listed in sip.conf and show up with ‘sip show peers’, yet no match is ever found. Each host is defined as
type=peer
context=incoming
allowguest=yes
insecure=invite,port
dtmfmode=rfc2833
canreinvite=no
disallow=all
allow=ulaw
host=one ip here
If I understand it correctly, port number (typically high, changes every time) should be ignored and matching should use ip address only (insecure=port). Yet a match is never found (and hence a 401 challenge?). If I set allowguest=yes in the [general] section, everything works in that context.
There is no NAT, TLS is used. There are no users (sip show users => empty).
Any ideas why matching peers fails? Or how to debug the issue further?
Try this. Into your peer configuration add
fromdomain = aaa.bbb.ccc.dddd
Thanks for the suggestion! Tried it, but the problem is still there.
Are you disable chan_pjsip ? Because you still want using chan_sip, right?
I’ve disabled chan_pjsip (by adding a number of noload instructions to modules.conf) and still the same result. Furthermore, pjsip.conf contains no uncommented (nonempty) lines, if that makes any difference. The problem is still there.
place here again but full warning comment if you want just censor IP/PSTN/DOMAIN
Please find the details of an unsuccessful call below:
<--- SIP read from TLS:54.171.127.192:38605 --->
INVITE sips:my-number@my-ip-address SIP/2.0
Record-Route: <sip:54.171.127.192:5061;transport=tls;r2=on;lr;ftag=94299385_6772d868_a21da9de-177c-4cae-bb94-3063251229ab>
Record-Route: <sip:54.171.127.192:5060;r2=on;lr;ftag=94299385_6772d868_a21da9de-177c-4cae-bb94-3063251229ab>
From: <sip:call-from@my-pstn-domain:5060>;tag=94299385_6772d868_a21da9de-177c-4cae-bb94-3063251229ab
To: <sips:my-number@my-ip-address>
CSeq: 1 INVITE
Max-Forwards: 19
P-Asserted-Identity: <sip:call-from@sipgw5061.com;user=phone>
Diversion: <sip:my-number@public-vip.ie1.twilio.com>;reason=unconditional
Call-ID: da4e301538be73ba2d737b99750657c0@0.0.0.0
Via: SIP/2.0/TLS 54.171.127.192:5061;branch=z9hG4bK8823.07092166.0
Via: SIP/2.0/UDP 172.18.205.231:5060;rport=5060;received=172.18.205.231;branch=z9hG4bKa21da9de-177c-4cae-bb94-3063251229ab_6772d868_110-10765760433449593165
Contact: <sip:call-from@172.18.205.231:5060;transport=udp>
Allow: INVITE,CANCEL,BYE,ACK,REFER,OPTIONS,NOTIFY
User-Agent: Twilio Gateway
X-Twilio-AccountSid: AC2fbaabfec992c03eb1390f3615bf31d5
Content-Type: application/sdp
X-Twilio-CallSid: CA06bce37e675df123a0f7bda03ac2f43d
Content-Length: 238
v=0
o=root 586834192 586834192 IN IP4 52.215.127.189
s=Twilio Media Gateway
c=IN IP4 52.215.127.189
t=0 0
m=audio 17856 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
<------------->
--- (19 headers 11 lines) ---
Sending to 54.171.127.192:5061 (no NAT)
Sending to 54.171.127.192:5061 (no NAT)
Using INVITE request as basis request - da4e301538be73ba2d737b99750657c0@0.0.0.0
No matching peer for 'call-from' from '54.171.127.192:38605'
<--- Reliably Transmitting (no NAT) to 54.171.127.192:5061 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 54.171.127.192:5061;branch=z9hG4bK8823.07092166.0;received=54.171.127.192
Via: SIP/2.0/UDP 172.18.205.231:5060;rport=5060;received=172.18.205.231;branch=z9hG4bKa21da9de-177c-4cae-bb94-3063251229ab_6772d868_110-10765760433449593165
From: <sip:call-from@my-pstn-domain:5060>;tag=94299385_6772d868_a21da9de-177c-4cae-bb94-3063251229ab
To: <sips:my-number@my-ip-address>;tag=as1acb9e66
Call-ID: da4e301538be73ba2d737b99750657c0@0.0.0.0
CSeq: 1 INVITE
Server: Asterisk PBX 16.0.1~dfsg-0~ppa1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="my-domain", nonce="61bb7123"
Content-Length: 0
<------------>
Scheduling destruction of SIP dialog 'da4e301538be73ba2d737b99750657c0@0.0.0.0' in 32000 ms (Method: INVITE)
<--- SIP read from TLS:54.171.127.192:38605 --->
ACK sips:my-number@my-ip-address SIP/2.0
Via: SIP/2.0/TLS 54.171.127.192:5061;branch=z9hG4bK8823.07092166.0
From: <sip:call-from@my-pstn-domain:5060>;tag=94299385_6772d868_a21da9de-177c-4cae-bb94-3063251229ab
Call-ID: da4e301538be73ba2d737b99750657c0@0.0.0.0
To: <sips:my-number@my-ip-address>;tag=as1acb9e66
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: Twilio Gateway
Content-Length: 0
<------------->
--- (9 headers 0 lines) ---
Really destroying SIP dialog 'da4e301538be73ba2d737b99750657c0@0.0.0.0' Method: ACK
allowguest=yes it has to be defined on general
canreinvite=no it is deprecated use direct media
also it is 54.171.127.19 found on your sip configuration ?
Make sure also Asterisk it is not challenging authentication due to a local device who match the from header with the incoming INVITE
I haven’t changed the configuration on upgrade apart from adding a couple of more hosts. Removed canreinvite now altogether. I’ve had allowguest=no in [general] and it has worked that way previously. It cannot be overridden anymore? Changed allowguest=yes in [general] and now I get slightly different errors:
No matching peer for 'call-from' from '35.156.191.128:58203'
[Dec 11 16:24:39] ERROR[11527][C-00000006]: rtp_engine.c:474 ast_rtp_instance_new: No RTP engine was found. Do you have one loaded?
[Dec 11 16:24:39] NOTICE[11527][C-00000006]: chan_sip.c:26578 handle_request_invite: Failed to authenticate device <sip:call-from@my-pstn-domain:5060>;tag=03355906_6772d868_b5e8e938-03c9-411a-898a-b9345758ecc0
That results in SIP/2.0 403 Forbidden
And yes, 54.171.127.192 (and 35.156.191.128) are defined as peers and can be listed with sip list peers. 54.171.127.19 was a typo, right?
Still no matching peer is found, but a 403 is sent instead of 401.
Apart from two firewalls, which seem to be working as expected, there are no extra devices at my end.
Having pjsip disabled seems to have caused the error (rtp_engine.c). By enabling pjsip again (fully commented pjsip.conf) all incoming calls are routed to the default context. Yet I have no way of defining context per peer, since the “No matching peer for … from …” problem is still there.
The persisting problem is that a matching peer is never found. Defined peers show up with sip show peers, ip addresses match and I have insecure=port,invite. There are no ACLs. “SIP Domain support not enabled”.
Any ideas how to fix or debug this?
Hi Liuhanen,
I am facing the same problem using Asterisk Certified 13.21, but when I upgraded to 16.3.0 the problem seemed to resolve… That’s not really a comfort to me thought because I have NO IDEA what the change was! Did you ever get to the bottom of this? I’d be curious where the experience took you if you still remember.
First of all, thanks for reaching out. Unfortunately, we were never able
to figure this out. Asterisk plays only a minor role for us and it was
easier to ignore it altogether than to pour in more resources into
debugging this kind of behaviour. In the end, we had no idea either.
I’ll have to try whether 16.3.0 has solved the problem, but as you so
nicely put it, it is hard to gain confidence back having no idea why an
upgrade broke pretty much everything.
Digging at the changelog, I found an entry tagged 46442aa9e5 that had some discussion of a fix that may have been the culprit. The only thing left to make me wonder now is, I could swear it was working before I updated… But we have been doing a lot of stuff on the IMS, so maybe it was incorrectly matching for other reasons. Anyway, there does appear to have been some work done on peer matching for TCP connections that would have caused that issue. Some confidence restored? Figured I’d mention I found something that looks suspiciously like a smoking gun.