Good afternoon guys. I’m facing an issue about inbound calls and is more than one week I’m looking for a solution but still I didn’t get it . I’m a newbie and I already setup a working installation of FreePBX, Extensions (sip), Trunk (sip), Outbound routes. Extensions are able to call each other and also the outbound traffic is working great. The only thing doesn’t work is the inbound calls to VOIP numbers (extensions) : asterisk is reached but there is something misconfigured I guess. Here below the messages I got:
[2023-11-01 16:44:00] NOTICE[19919] res_pjsip/pjsip_distributor.c: Request 'INVITE' from '"393382742364" <sip:393382742364@93.41.239.11>' failed for '93.41.239.11:5060' (callid: 1651399221@192.168.1.57) - No matching endpoint found
[2023-11-01 16:44:00] NOTICE[19919] res_pjsip/pjsip_distributor.c: Request 'INVITE' from '"393382742364" <sip:393382742364@93.41.239.11>' failed for '93.41.239.11:5060' (callid: 1651399221@192.168.1.57) - Failed to authenticate
Definitely you want the FreePBX people, as Incoming Route has no meaning in Asterisk. In any case the error messages indicate that that the call didn’t get that far.
When you go to the FreePBX people please provide a log of an incoming call request transaction, not an outgoing connectivity test one. The SIP you have logged has no relation to the failed call.
Note that I’d normally assume inbound to mean from a provider, but the reverse lookup on the address and the use of a non-routeable IP address in the call ID don’t look right for that.
Thanks david551 for your reply! I confirm log submitted is not related with my issue, my fault. Considering registration on FreePBX forum denied (tested more times but always some issues arose), what asterisks file I could share to get helped by you?
Assuming FreePBX doesn’t use Asterisk Realtime Architecture, and uses the default directories, the transitive closure of /etc/asterisk/pjsip.conf and everything related by inclusion, together with the protocol logging for a real call.
When I call from my own mobile the sim laid into the GSM Gateway, I get the busy signal and don’t have asterisk’s log. It seems GSM Gateway doesn’t arrive to Asterisk. When you said “transitive closure of /etc/asterisk/pjsip.conf and everything related by inclusion” you mean a zip including all pjsip* files ?
chan_sip is not longer supported, and has been removed from the source code of the latest version.
This is gibberish. very was deprecated a very long time ago, and has been completely removed in supported versions of Asterisk. Neither “&”, nor “.|” are valid delimiters. This could cause failed to authenticate, except that it hasn’t got that far.
Also, if you need this, you are matching the OUTGOING section for incoming calls, so don’t need an INCOMING one.
This is a FreePBX concept. What is the actual context name? (The INCOMING/OUTGOING hack shouldn’t be needed for simple mobile air interface gateway box, and isn’t needed, on the supported channel driver.)
This doesn’t do anything when you have an explicit host.
You are looking for 1111, but they are sending 393382742364.
The INCOMING context is incomplete.
None of this being used, as the message indicates that chan_pjsip is the one that is listening on port 5060.
Thanks david551 for your kindly replies. I removed the INCOMING settings and updated the “insecure” param like you suggested (insecure=port.invite). Outgoing calls keeps on working fine but incoming call still busy. Errors are still the same:
[2023-11-06 10:24:54] NOTICE[10935] res_pjsip/pjsip_distributor.c: Request ‘INVITE’ from ‘“393382742364” sip:393382742364@128.140.66.20’ failed for ‘93.41.239.11:5060’ (callid: 236768969@192.168.1.57) - No matching endpoint found
[2023-11-06 10:24:54] NOTICE[10935] res_pjsip/pjsip_distributor.c: Request ‘INVITE’ from ‘“393382742364” sip:393382742364@128.140.66.20’ failed for ‘93.41.239.11:5060’ (callid: 236768969@192.168.1.57) - Failed to authenticate
The number 393382742364 is the one calling the sim locatend into the GoIP and it’s forwarded to asterisk (Setting on GoIP is “Use CID as SIP Caller ID”… Other options are “Disable” and “Use Remote Party ID”).
For both “Use Remote Party ID” and “Disable” the error messages are the following:
There is no indication that you need insecure=port, and I think insecure=invite may be dangerous, in this case, but it depends on how the gateway is configured.
You are still using sip.conf, when port 5060 is being handle by chan_pjsip, so nothing in sip.conf is relevant to your calls, which are arriving on 5060. You can’t have both bound to the same port, and, rumour has it that FreePBX prefers chan_pjsip for 5060 and uses a different default number for chan_sip, if both are enabled.
For security, you should enable outbound authentication
You haven’t provided your pjsip.conf information yet.
DTMF inband seem questionable for a “GSM” gateway. Also note that GSM only supports DTMF outbound. Inbound DTMF will be garbled, as the codec will not support inband over the air interface and the air interface only supports out of band in the expected direction from phone to network.
Some of the options are not self explanatory. They may well not even be adequately documented, so you might have to try them to understand what they really do, unless someone familiar with the device comes along.
There’s no type=identify for the IP address, nor is there a type=endpoint for 1111 set to match on authorisation user name. There is no type=auth for username=1111.
Basically you are sending the call to chan_pjsip without having told chan_pjsip about the gateway.
My preference would be to use type=identify on the IP address.
For security reasons, I’d also suggest using outbound-auth, as well as, or instead of auth, and to make the corresponding changes on the gateway, as it is outbound calls which will provide the payback for toll fraud and you don’t want an attacker to be making them by directly accessing the gateway.
That’s an incomplete configuration for chan_sip. As chan_pjsip is listening on port 5060, chan_sip cannot do the same. I believe FreePBX sets it to listen on a different port number, although if it didn’t the first one to claim 5060 would win, and the other would fail.