Inbound from-sip-external

I have a system where all inbound calls from the provider are coming in through from-sip-external instead of matching the trunk I have. I’ve needed to enable Anonymous Inbound SIP calls in order for the calls to complete. Logs here - Automatic Pastebin from Sangoma OS 7 - FreePBX Pastebin

PROVIDER_IP = The signaling IP of the provider where the call is coming from
RTP_IP = The IP of the media for the call
CALLERID_NUM = Caller ID of the inbound caller
DID_NUM = DID that the caller called

I also have Match (Permit) set to the signaling IP as well, though I have iptables whitelisting other subnets of the provider.

Who is the provider?

If you enable Anonymous Inbound SIP Calls, which some think is a security risk (but I don’t), then be sure to create a catchall inbound route (with no DID and no CID) that routes to Terminate Calls:Hangup, so that SIP probes won’t get a useful response from your system.


I have Anonymous Inbound SIP calls enabled on this server, but these calls shouldn’t require that setting since I can see that the call is coming from the IP and port I’m expecting and have configured in the trunk.

I don’t have any experience with Vitelity. If I did, I’d probably know the answer here.

Any idea why your logs show this as a chan_sip connection when your screenshot shows a pjsip trunk?

Do you have a chan_sip trunk that might match here?

Have you tried using a chan_sip trunk with Vitelity to see if you get a different result?

NOTE: I’m apparently required to warn you that chan_sip is deprecated and that it won’t be around for much longer.

I tried a chan_sip trunk and the result is the same.

@AdHominem nailed it. You’ve created a pjsip trunk, but configured the provider to send INVITEs to the chan_sip port. Without registration, you must ensure that settings are correct at the provider end for both host and port. You will prob want to disable inbound authentication for the trunk as well.

While I love the idea of being right, he did say (later) that he tried with a chan_sip trunk and it still didn’t work. So, I’m not convinced that I was right. :slight_smile:

Callcentric used to have this problem, but it was because CC uses SRV lookup and chan_sip’s support for that was very limited. Pjsip has better support for SRV lookup and so that problem shouldn’t be what you are experiencing with Vitelity.

I think we need your complete configuration settings for Vitelity, both on the pjsip and chan_sip side and on the Vitelity side (if you’re not using registration). Obviously you should omit sensitive information like your username and password.

I use IP auth only for them.

I recreated a chan_sip trunk for them and it works, so I must have overlooked some config in the other. Vitelity Inbound IP auth only allows 5060 so I will need to change the PJSIP bind port in order to get that to work. Thanks @AdHominem for catching that dumb mistake.

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