FOOD FOR THOUGHT Using CallCentric with PIAF

[Trimline2]

Here is my tested solution.

Problem Abstract:

Callcentric Asterisk users don't have a clear and concise instruction set to follow when using a PIAF setup. Calls do not reach their intended target PBX or are rejected as Callcentric uses multiple IP Peers. This currently is limited to Callcentric, but may in the future, involve other VoIP providers.

Fix, Adjustment:

The "from-sip-external" on Asterisk acts as a funnel for calls that do not have a defined Peer. This module's purpose is to determine if the system permits Anonymous connections, if it does, or if you allow this on your system, no changes are required on your part (setting not recommended). However, if you do not allow anonymous SIP connections, review the below code and adjust accordingly.

See Ward's post #12 above. Prior to changing your config.

;-------------------------------------------------------------------------------
[from-sip-external]
; from-sip-external  Add to extensions_override_freepbx.conf
;
; This context is the default SIP context unless otherwise changed in the SIP
; Settings module or other sip configuration locations. This context is hit by
; either anonymous SIP calls or mis-configured SIP trunks when the incoming call
; can not be matched with a SIP section.
;
; 05-Jan-2014 WardMundy : Added override line below s1
; 08-Jan-2014 Trimeline : Added line to log Peer IP and Source IP
; 08-Jan-2014 Trimeline : s1 moved and altered stmt for inbound Callcentric (or any other provider) check.  You may add as
;                        many CC (provider) DIDs as needed by duplicating the 1777 line as exampled below.
;
[from-sip-external]
exten => _.,1,NoOp(Received incoming SIP connection from unknown peer to ${EXTEN})
exten => _.,n,Set(DID=${IF($["${EXTEN:1:2}"=""]?s:${EXTEN})})
exten => _.,n,NoOp(Peer IP: ${SIPCHANINFO(peerip)} Source IP: ${SIPCHANINFO(recvip)})
exten => _.,n,Goto(s,1)
exten => s,1,GotoIf($[${DID}=17775551212]?from-trunk,${DID},1)
exten => s,n,GotoIf($[${DID}=17775551212101]?from-trunk,${DID},1)
exten => s,n,GotoIf($["${ALLOW_SIP_ANON}"="yes"]?checklang:noanonymous)
exten => s,n(checklang),GotoIf($["${SIPLANG}"!=""]?setlanguage:from-trunk,${DID},1)
exten => s,n(setlanguage),Set(CHANNEL(language)=${SIPLANG})
exten => s,n,Goto(from-trunk,${DID},1)
exten => s,n(noanonymous),Set(TIMEOUT(absolute)=15)
exten => s,n,Log(WARNING,"Rejecting unknown SIP connection from ${CHANNEL(recvip)}")
exten => s,n,Answer
exten => s,n,Wait(2)
exten => s,n,Playback(ss-noservice)
exten => s,n,Playtones(congestion)
exten => s,n,Congestion(5)
exten => h,1,Hangup
exten => i,1,Hangup
exten => t,1,Hangup
;-------------------------------------------------------------------------------

Testing

Asterisk 11.6
FreePBX 2.11.x

Testing was completed by using a Callcentric DID, assigned as a 1777XXX1234 DID and a 1777XXX1234EXT. All calls with the aforementioned inbound route completed succesfully. The trunk definition used was as follows during testing:

trunk name: callcentric

context=from-trunk
fromdomain=callcentric.com
fromuser=1777XXXXXXX
host=callcentric.com
insecure=port,invite
secret=YOUR PASSWORD
type=peer
defaultuser=1777XXXXXXX
disallow=all
allow=g722,ulaw <===USE WHAT YOU SEEM FIT.

Registration:
1777XXXXXXX:[email protected]/1777XXXXXXX

Installation:

If you are using the above PIAF, simply copy/paste your changes to extensions_override_freepbx.conf via Config Edit, then press update, and then Re-Read Configs option.




.

 

[Trimline2]

Why that's as generic as Walmart. I like it! Doesn't get any better.

 

[Hyksos]

So you have
Allow SIP Guests: Yes
Allow Anonymous Inbound SIP Calls: No
?

I see you don't use the from-pstn-toheader context or SIP_HEADER(TO) in the dialplan, which would indicate those configurations would not allow DID based routing. Of course this would be needed only when multiple DID are delivered by callcentric via one trunk. One method would lead to having 1777XXXXXXX as the DID in your inbound route and the toheader usage would mean you would route with the real incoming DID, as received from callcentric via the header.

So I guess depending on the services your consuming different configurations would work but more configurations are needed to route on DID?

About NAT, if you're behind it with no port forwarding? I think this nuance counts too. Or if you're using direct exposure with a whitelist of source IPs(providers and remote ext, if applicable)?
Because if you can receive incoming call from different IP addresses you might not be currently "chatting" with, it will mean that the incoming call will not be NATed toward the PBX by the router.
Simple NAT situation, but if that happens, you won't get the call.

Forwarding everything to the PBX would work but you won't be forwarding just callcentric.
Configurations have been suggested where all callcentric incoming IPs be listed in the configuration as peers. Right now you handle that "not a peer" issue in [from-sip-external].
But adding all the peers was also used to enforce a qualify=yes against all the possible incoming peers to hopefully solve the NAT issue for potential incoming calls.
Of course if calls almost always come from the SBC/peer your currently chatting with, this NAT issue could be rare. But still bad.

About that, Callcentric support said to a customer that he could receive callcentric calls from "66.193.176.35 which does not resolve to callcentric.com".
So even adding all those peers and maintaining NAT pinholes for all of them would not suffice to receive calls from this IP, you would need to know all the potential IPs in advance and make sure they can reach you.
If not, you would have to accept all SIP traffic to go the PBX(whatever the source IP) and manage it inside the dialplan, like you guys are doing here by routing ONLY callcentric calls to the from-trunk context and actively denying everything else. Not for the novice I guess...

Others have said that callcentric-asterisk works from behind NAT, this is where I stop understanding, if callcentric network can send you calls from different sources, how can you truly be behind NAT?
That would have to mean that you _always_ receive calls from the peer your chatting with, but even callcentric seem to say you shouldn't count on that.

I could also be 100% wrong about ALL of it but if I have all those questions I'm probably not alone. I still want to callcentric!
And I know I HAVE to be wrong about something because most people make it work 100% and I don't understand how you can do that from behind NAT without knowing all the potential source IPs in advance to maintain pinholes for them.

 

[Hyksos]

Just so we're clear on my tone, means "to master" or "mastering" callcentric, it's like Rambo.

 

[wardmundy]

Hyksos: Correct. This would not peel off individual DIDs. If somebody has a free DID and a free iNum from CC, both will come in on the same path without more.

I was more interested in getting a generic solution that works for all systems. My thought is that if people have a bunch of DIDs, they're smart enough to do most of this themselves. I'm worried about the other 99%. And, yes, it won't catch all of Callcentric's fancy IP failover addresses, but I'm thinking iptables-restart should get anybody back in business that loses their Callcentric connectivity. In fact, I thought about adding that to the trunk monitoring script just to cover this. Wouldn't the Callcentric FQDN also change to the new IP adddress when they jump over to another IP address?? Don't really know because there's no way to test this much less discuss it with Callcentric folks.

One thing is for sure. Callcentric supporters and staff have some striking similarities to Apple FanBoys. Makes it really difficult to have a technical discussion because they are always hurling insults and complaining that you're bashing Callcentric for being so brilliant and ahead of their time.

p.s. This is more of a challenge than something we really want to do. Callcentric charges about double the rate for terminations and about 80-100% more for DIDs. Vitelity supports our project so my enthusiasm for fixing Callcentric's mess is MINIMAL especially after the bashing in "The Genius Forum."

 

[Mango]

Others have said that callcentric-asterisk works from behind NAT, this is where I stop understanding, if callcentric network can send you calls from different sources, how can you truly be behind NAT?
That would have to mean that you _always_ receive calls from the peer your chatting with

In my experience, I have indeed always received calls from the SBC I'm registered to. You're correct; any other way it wouldn't work behind NAT.

Wouldn't the Callcentric FQDN also change to the new IP adddress when they jump over to another IP address??

You're aware that they currently list eight IP addresses, correct? Yes, they would change their DNS if they wished to divert traffic to some other SBC. Is that answer along the lines of what you were looking for?

 

[wardmundy]

Yep. Thanks. So that means that, by monitoring your trunks with trunkcheck.sh, when a trunk failed we could issue iptables-restart to bring Callcentric back on line if it was their IP address that was no longer reachable. I'll add it to the script.

 

[Mango]

I haven't yet read the script - but the other way to do that is by enabling dnsmgr in dnsmgr.conf. That would refresh DNS lookups every refreshinterval seconds.

 

[wardmundy]

After further discussions with the FreePBX folks, it turns out this is a bad idea. Using _1777. would basically let anybody spoof the DID with a number beginning with 1777 and give them free access to your dialplan just as if you had turned on Allow Anonymous SIP. A suggestion was made that a single line entry could be made to extensions_custom.conf to handle an individual account, BUT...

The other issue involves opening up Allow Guest at all on your server without an IPtables WhiteList. Here is the FreePBX explanation for the difference in Allow Guest vs. Allow Guest + Allow Anonymous SIP:

Just enabling Allow Guest would protect your dialplan; however, it opens up SIP access to Asterisk from outside. The risk there is all of the denial of service and other attacks that might compromise your Asterisk server if there are remaining bugs in the SIP module of Asterisk. I think there were about a half dozen at different times during 2013.

A better and safer alternative would be to create a trunk for each of Callcentric's servers. You can get the list of servers with:

dig SRV _sip._udp.callcentric.com

This is a pain in the ass basically because Callcentric has chosen not to create a FreePBX module for their unique architecture. But that's kinda where we are.
Special thanks to Tony and Philippe for the excellent explanation.

 

[grimloch]

CallCentric resources below. Haven't tried them. The method documented above works for sure.

DID-based Routing for CallCentric with PIAF

Trunk Configuration for CallCentric with PIAF

You may also want to review the CallCentric position on the reason for the mess (see Iscream comments below) as well as some of the other posts in this thread.

Using the settings Ward posted about worked for me, specifically the instructions from Callcentric's site "Trunk Configuration for CallCentric with PIAF" and "DID-based Routing for CallCentric with PIAF"

My SIP settings are "No" for Allow Anonymous Inbound SIP Calls and "Yes" for Allow SIP Guests. It sounds like Allowing SIP Guests may be a security thread, though, so I should turn this off?

 

[Trimline2]

I did test this a while back on Ward's recommendation after adding all of the 20 Callcentric servers; listed by:

dig SRV _sip._callcentric.com

Although this was a data entry exercise, I had no issue with having both parameters set to "No".

 

[briankelly63]

Using a provider should not be this complicated. Simplicity will always trump technical cleverness. What is also concerning is the "99%" who are low to medium technical builders are going to be using configurations that properly process their calls part of the time. Unless they get a lot of calls or complaints they may not even know they are missing calls.

In the non-voip, traditional engineering world organizations like the IEEE take control of confusion like this and lay out standards that the providers must comply with to be considered "compliant". The compliance requirement gets written into project and bid requirements. If they don't adhere to the standards they end up out in the cold.

New to VoIP users that inadvertently select a provider that is less then plug and play are unfortunately given the impression that getting a working configuration is some sort of black art. 50 Posts later they get it "working" (or so they think) and they're not even 100% sure why.

Whats surprising is that the companies that manufacture the hardware for providers haven't enforced a more standardized approach.

 

[voipRookie]

I agree using a provider should not be this complicated and it does seem Callcentric goes out of its way to make it this way. However, at least to my untrained ear, the audio quality on Callcentric is superior to all the other providers that I currently use (Flowroute, VoIP.ms, Vitelity, IPComms, Vestalink, Anveo).

 

[briankelly63]

Haven't found that to be true. Other than codec or network related issues they should be about the same.

RTP proxy can be a factor: http://pbxinaflash.com/community/in...ovider-proxy-rtp-build-list.13646/#post-87207

 

[voipRookie]

I agree there shouldn't be much of a difference and there isn't one between all the other providers I use (don't get me wrong, they're all good). But for some reason Callcentric sounds the best. However, since Callcentric is the most expensive I don't use them as often as I use the other providers.

 

[Mango]

In the non-voip, traditional engineering world organizations like the IEEE take control of confusion like this and lay out standards that the providers must comply with

Let's say you're the IEEE. What would you have Callcentric do?

 

[wardmundy]

Manage support for multiple IPs on the provider side instead of with end-users. Imagine if Ma Bell had set up phones this way to connect to different countries.

 

[Mango]

Can you tell me more about managing multiple IPs on the provider side? I'm curious about this.

 

[grimloch]

I got a beaglebone black to replace my RPi. I started going through this headache again and ended up grabbing a free ipcomms DID instead. MUCH easier set up. I'm using GV and the python callback method so the DID number isn't important at this point. We'll see what happens next Thursday..

 

[tycho]

^^^ Same boat here, using a Dockstar and twinclouds' set-up. But tinkering with the detail from this thread re: CC on my PC-based PIAF box...