Whitelist intercept of INBOUND SIP/TRUNK

FreePBX 2.5.1.5
Asterisk 1.4.25.1

We’d like to check inbound calls (SIP/VSP-TRUNK) against NPA-NAA DBGET/DB_EXISTS and then pass them on or not – whitelisting. A little custom dialplan fragment DB() stuff, but …

Where in the freePBX dailplan framework is the correct/appropriate place to “hook” into the incoming sip/trunk callflow as well as the appropriate return-to point?

We’ve looked at from-trunk and watched asterisk -r, but it really isn’t clear to us. Other then hijacking the [app-blacklist-check] context. :slight_smile:

Any guidance (or dialplan examples) would be appreciated.

Our VSP is voicenetwork.ca and per their configuration examples their TRUNK PEER DETAILS is as follows. It’s their guidance for a “trixbox” trunk config and works for non-trix freePBX installs. The “from-trunk” context is first cited here.

Where TRUNK NAME is VNCA-OUT (outbound “friend”)
------TRUNK PEER DETAILS----
nat=yes
disallow=all
host=sipgw.voicenetwork.ca
context=from-trunk
allow=ulaw
type=friend
username=<our_account>
fromuser=<our_account>
sendrpid=yes
qualify=yes
canreinvite=no
insecure=port,invite
secret=<63-bytes of secret>

TRUNK NAME VNCA-IN (inbound “peer”)
-----TRUNK USER DETAILS-----
type=peer
host=sipgw.voicenetwork.ca
qualify=yes
canreinvite=no
disallow=all
context=from-trunk
allow=ulaw

Thanks,

First you need to determine if those inbound details are really being used - most of the time, in the case of a commercial provider, they’re not. So blank out the trunk user name and details, and leave in only the peer name and details and see if the trunk still works. The reason you need to know is because the statement “context=from-trunk” appears in both, and you need to find out which one is really being used on inbound calls.

Anyway, once you’ve figured out which one is valid, you can look at How to change incoming CallerID for an example of how to insert a bit of custom dialplan in the inbound call flow.

The top of the CLI log follows (numbers changed to protect the innocent).

We’re seeing the CID info we need to see.

And, I guess curiously, it’s reporting the inbound call on the “-OUT” outgoing settings/trunk PEER and not the incoming setting/trunk USER which would have read “VNCA-IN.”

Perhaps I should mention that this is a working system – twelve DID’s and four trunks with the VSP, an ACD queue (888-NXX-XXXX), parking lot and followme. It’s a great systems.

That said, given your questioning, should our trunk’s be better/diff wrt the SIP PEER and USER fields? If so, may we ask how so.

The VSP has a self-serve portal. When you buy DIDs and config a PEER, you select the end-system type – asterisk, trixbox (2.6), SIP. The trixbox selection yields a cut-and-paste of your params for the TRUNK>ADD SIP screen. This is what we’ve used. The only “extras” --by us-- are the codecs stuff – disallow, and allow.

If it should be or could be better for native freePBX site, please so advise. We’ll do the config changes. And, as appropriate, feed forward to the VSP for the benefit of their other customers too – credit given where due :slight_smile:

Thanks,

-----asterisk -r -----
Connected to Asterisk 1.4.25.1 currently running on trixbox1 (pid = 5617)
Verbosity is at least 12
– Executing [[email protected]:1] Set(“SIP/VNCA-OUT-b7e1”, “__FROM_DID=4160000000”) in new stack
– Executing [[email protected]:2] Gosub(“SIP/VNCA-OUT-b7e1”, “app-blacklist-check|s|1”) in new stack
– Executing [[email protected]:1] LookupBlacklist(“SIP/VNCA-OUT-b7e1”, “”) in new stack
– Executing [[email protected]:2] GotoIf(“SIP/VNCA-OUT-b7e1”, “0?blacklisted”) in new stack
– Executing [[email protected]:3] Return(“SIP/VNCA-OUT-b7e1”, “”) in new stack
– Executing [[email protected]:3] ExecIf(“SIP/VNCA-OUT-b7e1”, “0 |Set|CALLERID(name)=4169999999”) in new stack
– Executing [[email protected]k:4] Ringing(“SIP/VNCA-OUT-b7e1”, “”) in new stack
– Executing [[email protected]:5] Wait(“SIP/VNCA-OUT-b7e1”, “5”) in new stack
----- snip end ------

If more log or other stuff needed, please just let me know what (and how – I.T. guru but an asterisk/freepbx tadpole).

Thanks,

Thanks!

Just trialed the hook to and return from, as per your suggested example, and it looks really good. The NoOp and Verbose statements are showing all the needed info and we’re “returning” to the freePBX call flow

Again, thank you.

/S