FOOD FOR THOUGHT Using CallCentric with PIAF

[chwebb1]

Hello All,
I can't seem to figure out how to get my CallCentric service working on PIAF. Neither inbound or outbound calls will ring my phone. CallCentric shows the PBX as registered. I have confirmed that inbound and outbound calling work with Future9 and Vitelity. I tried to follow the directions here: http://www.callcentric.com/support/device/asterisk/1_8 but I still couldn't figure out how to get it to work. I am using an extension so that I can keep my current PBX working until I am certain that I'll keep PIAF (I am pretty sure I will if I can get CallCentric working). I've assigned PIAF extension 101 on CallCentric. The config I have is:
PEER Details:
username=1777XXXXXXX101
type=peer
secret=XXXXXXXXX
insecure=port,invite
host=callcentric.com
fromuser=1777XXXXXXX101
fromdomain=callcentric.com
disallow=all
context=from-pstn
allow=g729&ulaw&alaw

USER DETAILS:
Blank

Register string:
1777XXXXXXX101:[email protected]

Does anyone have any ideas?
Thanks!

 

[rossiv]

I have Callcentric outbound working. I don't use them for inbound.
One issue I had at first when switching my Callcentric trunk from one PBX to the other was the public IP change. I had to update Callcentric's whitelist with the new IP before anything would work. Also, check your outbound CID settings too. They're really picky about what CID you send.

Trunk Name: callcentric
 
Peer Details:
context=from-trunk
fromdomain=callcentric.com
fromuser=1777XXXXXXX
host=callcentric.com
insecure=port,invite
secret=SuperSecret
type=peer
defaultuser=1777XXXXXXX
disallowed_methods=UPDATE
directmedia=no
videosupport=no
disallow=all
allow=ulaw
 
Register String: 1777XXXXXXX:[email protected]/1777XXXXXXX

That's straight copy/paste from their website that I am using on my PBX.

Edit: Also, any particular reason you are using PIAF Yellow? Are you using Digium phones?

 

[chwebb1]

Hello rossiv
I'm still getting the "All circuits are busy now" when dialing out, and ringing in doesn't work either. I've used your configuration from above (of course modifying the fromuser, default user and secret, as well as the register string user and pass). I have copied my logfile from here:

[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@sub-flp-2:1629] Return("SIP/0001-00000004", "") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk:13] Set("SIP/0001-00000004", "OUTNUM=XXXXXXXXXX") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk:14] Set("SIP/0001-00000004", "custom=SIP/CallCentric") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk:15] ExecIf("SIP/0001-00000004", "0?Set(DIAL_TRUNK_OPTIONS=M(setmusic^default)Tt)") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk:16] ExecIf("SIP/0001-00000004", "0?Set(DIAL_TRUNK_OPTIONS=TtM(confirm))") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk:17] Macro("SIP/0001-00000004", "dialout-trunk-predial-hook,") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk-predial-hook:1] MacroExit("SIP/0001-00000004", "") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk:18] GotoIf("SIP/0001-00000004", "0?bypass,1") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk:19] ExecIf("SIP/0001-00000004", "1?Set(CONNECTEDLINE(num,i)=XXXXXXXXXX)") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk:20] ExecIf("SIP/0001-00000004", "1?Set(CONNECTEDLINE(name,i)=CID:XXXXXXXXXX)") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk:21] GotoIf("SIP/0001-00000004", "0?customtrunk") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk:22] Dial("SIP/0001-00000004", "SIP/CallCentric/XXXXXXXXXX,300,Tt") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] netsock2.c: == Using SIP RTP TOS bits 184
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] netsock2.c: == Using SIP RTP CoS mark 5
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] app_dial.c: -- Called SIP/CallCentric/XXXXXXXXXX
[2014-01-03 22:01:29] NOTICE[2307][C-00000002] chan_sip.c: Failed to authenticate on INVITE to '"MY NAME" <sip:[email protected]>;tag=as72cf3f37'
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] app_dial.c: -- SIP/CallCentric-00000005 is circuit-busy
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] app_dial.c: == Everyone is busy/congested at this time (1:0/1/0)
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk:23] NoOp("SIP/0001-00000004", "Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 21") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-dialout-trunk:24] GotoIf("SIP/0001-00000004", "0?continue,1:s-CONGESTION,1") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Goto (macro-dialout-trunk,s-CONGESTION,1)
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s-CONGESTION@macro-dialout-trunk:1] Set("SIP/0001-00000004", "RC=21") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s-CONGESTION@macro-dialout-trunk:2] Goto("SIP/0001-00000004", "21,1") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Goto (macro-dialout-trunk,21,1)
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [21@macro-dialout-trunk:1] Goto("SIP/0001-00000004", "continue,1") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Goto (macro-dialout-trunk,continue,1)
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [continue@macro-dialout-trunk:1] NoOp("SIP/0001-00000004", "TRUNK Dial failed due to CONGESTION HANGUPCAUSE: 21 - failing through to other trunks") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [continue@macro-dialout-trunk:2] Set("SIP/0001-00000004", "CALLERID(number)=0001") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [XXXXXXXXXX@from-internal:6] Macro("SIP/0001-00000004", "outisbusy,") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-outisbusy:1] Progress("SIP/0001-00000004", "") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-outisbusy:2] GotoIf("SIP/0001-00000004", "0?emergency,1") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-outisbusy:3] GotoIf("SIP/0001-00000004", "0?intracompany,1") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] pbx.c: -- Executing [s@macro-outisbusy:4] Playback("SIP/0001-00000004", "all-circuits-busy-now&pls-try-call-later, noanswer") in new stack
[2014-01-03 22:01:29] VERBOSE[2782][C-00000002] file.c: -- <SIP/0001-00000004> Playing 'all-circuits-busy-now.gsm' (language 'en')
[2014-01-03 22:01:31] VERBOSE[2782][C-00000002] app_macro.c: == Spawn extension (macro-outisbusy, s, 4) exited non-zero on 'SIP/0001-00000004' in macro 'outisbusy'
[2014-01-03 22:01:31] VERBOSE[2782][C-00000002] pbx.c: == Spawn extension (from-internal, XXXXXXXXXX, 6) exited non-zero on 'SIP/0001-00000004'
[2014-01-03 22:01:31] VERBOSE[2782][C-00000002] pbx.c: -- Executing [h@from-internal:1] Hangup("SIP/0001-00000004", "") in new stack
[2014-01-03 22:01:31] VERBOSE[2782][C-00000002] pbx.c: == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/0001-00000004'

That to me looks like for some reason it is having authentication issues, and I'm not 100% sure why. I'm using the SIP number and password that I set with CallCentric. I also don't see my name anywhere in the configuration, so I'm not sure why it's showing my name in the authentication failure. Any ideas?

I am using Yellow because I assumed that it was the latest supported version (I didn't want to start on an old version), and I didn't want to use the beta version. I see on the home page, I likely should have chosen the version above that, If I'm remembering correctly, it's called Green. I'm not using Digium phones, I have a no-name SIP Wi-Fi phone, but I'm currently testing with a SIP Avaya 1165e. I also have a Nortel/Avaya 1230 and Polycom SoundPoint IP 330 I'll be using after I get everything set up.

 

[rossiv]

Honestly, Yellow really shouldn't make that much of a difference in the scheme of things. Was just curious.

Back to the issue at hand, I think that is almost the exact same issue that I saw this morning when I was migrating my CallCentric trunk from an old PBX to a new PBX but didn't change the IP in CallCentric's portal. Did you check that by chance? If not, please do.
Another guess is the CID like I mentioned earlier. Is the CID that you are sending them for an outbound call verified in their portal?

 

[chwebb1]

Honestly, Yellow really shouldn't make that much of a difference in the scheme of things. Was just curious.

Back to the issue at hand, I think that is almost the exact same issue that I saw this morning when I was migrating my CallCentric trunk from an old PBX to a new PBX but didn't change the IP in CallCentric's portal. Did you check that by chance? If not, please do.
Another guess is the CID like I mentioned earlier. Is the CID that you are sending them for an outbound call verified in their portal?

I checked CallCentric's portal, and it looked like I had that feature disabled:

Allow device registration only from specified IP Addresses:    No   
IP Addresses white list:    The list is empty

The outbound caller ID is set to the same caller ID calls from my old PBX displayed (I emailed them and asked them to force all of my caller IDs to my phone number). I'm using that same phone number. That should be all I need to do, right? Or is there another verification I need to do?

 

[rossiv]

Interesting. I thought they made me do that. Maybe I chose that. Doesn't matter in this case now.
Same for the CID, if they are forcing it, it shouldn't matter. Now I'm stumped. Hmm....

 

[rossiv]

Wait...when you say 'MYNAME' is that chwebb1 like your forum username or something else? That seems like something extra got copy-pasted when I posted my config from earlier.

Edit: Second thought. Found another thread with the same issue. http://pbxinaflash.com/community/index.php?threads/callcentric-setup.9866/
Try adding this to your peer details:

username=1777XXXXXXX

 

[chwebb1]

Wait...when you say 'MYNAME' is that chwebb1 like your forum username or something else? That seems like something extra got copy-pasted when I posted my config from earlier.

No, I mean my full name that I go by. Like "First Name Last Name"

 

[rossiv]

No, I mean my full name that I go by. Like "First Name Last Name"

Oh. That's stranger. Is that mentioned in your Outbound Routes? I really don't have a clue where that would come from. See my edit to my last post, just above yours. See if that helps.

 

[chwebb1]

That fixed outbound with them (Yay!), but I'm still having issues receiving calls. What do I need to do to get my Inbound working with them? I even tested using the SIP number and doing a "Click to Call" in addition to calling one of my phone numbers with them.

 

[chwebb1]

OK, I found this in the log:

[2014-01-03 22:54:08] VERBOSE[4051][C-00000011] func_timeout.c: -- Channel will hangup at 2014-01-03 22:54:23.175 EST.
[2014-01-03 22:54:08] VERBOSE[4051][C-00000011] pbx.c: -- Executing [s@from-sip-external:6] Log("SIP/callcentric.com-0000001e", "WARNING,"Rejecting unknown SIP connection from 204.11.192.161"") in new stack
[2014-01-03 22:54:08] WARNING[4051][C-00000011] Ext. s: "Rejecting unknown SIP connection from 204.11.192.161"

I think this might be why I'm not receiving calls. Do you have any ideas why the PBX is rejecting this call?

 

[wardmundy]

Try this CallCentric solution first!

This gets complicated so, if you don't know what you're doing, SWITCH PROVIDERS! We don't use CallCentric regularly so I can't speak to whether you have misconfigured your trunk or whether this is a problem at the CallCentric end that either they or you have misconfigured for Asterisk access. Some providers simply don't configure their SIP trunks properly which causes FreePBX to treat the calls as anonymous SIP calls. We had this problem with CallCentric inbound calls as well, but try the solution above before proceeding.

WARNING: You do NOT want to set Allow Anonymous Calls to YES in FreePBX, or all the bad guys on the planet will be trying to hack into your system.

The solution is to add an anonymous call exception for just your DID. Here's how.

1. Find the [from-sip-external] context in /etc/asterisk/extensions.conf and make a copy of it. It looks like this in FreePBX 2.11:

; from-sip-external
;
; 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.
;
[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,Goto(s,1)
exten => s,1,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
;-------------------------------------------------------------------------------

2. Copy the [from-sip-external] context from Step #1 into the bottom of /etc/asterisk/extensions_override_freepbx.conf.

3. While still editing extensions_override_freepbx.conf, find the line in your newly pasted context that looks something like this:

exten => s,1,GotoIf($["${ALLOW_SIP_ANON}"="yes"]?checklang:noanonymous)

4. Just below that line, INSERT a new line with your Callcentric DID:

exten => _17771234567,1,Goto(from-trunk,${DID},1)

5. Reload your dialplan: asterisk -rx "dialplan reload"

6. Add an Inbound Route in FreePBX for your new DID using your complete Callcentric account number, e.g. 17771234567.

7. If you're using Travelin' Man 3 or some other IPtables WhiteList setup, make sure you add the provider's IP address to the WhiteList and iptables-restart.

8. Make a test call to the DID to verify that things are working.

Good luck!

 

[chwebb1]

Thanks for the suggestion. I ended up buying a DID from Vitelity so I'll see how they work for me.

 

[Hyksos]

Dont feel bad for giving up, the only reason I think I should get one of their account is to help people here and understand how it's possible that they are making it soooo complicated on a FreePBX platform to configure one of their trunks.

They are obviously doing it with a little twist on the required configurations... And answering support ticket saying you should allow anonymous sip calls.

I'm not saying they are a bad provider, plenty of people here use them, I just never did. There is a forest of providers and you have to like many trees. At least two.

Search http://pbxinaflash.com/community on google for "callcentric" and start reading finish with the most recent ones.
Then try to make it work and if you succeed you'll be in the upper percentiles of VOIP user...
When you're a callcentric customer you hack your dialplan.

 

[wardmundy]

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.

My point was that the person who _configures_ Asterisk MUST know what s/he is doing in clear details - that includes routing, firewalling and NAT'ing in addition to be able to configure Asterisk itself. I wrote also that I'm aware of huge number of installations (because I have access to internal reports - I know the number of tickets in our system as well as a number of each type of UAs registered and used on our network) being able to utilize our services in full.

Therefore, as it's been said above by somebody, in this "cutthroat" competition - if something would not be operational on Callcentric side - those [huge number of] customers would simply be using someone else's service.

Callcentric simply cannot hold [as a customer] some one who is not absolutely happy with our services - because of no long term contracts; the service is based on account's available balance and monthly paid DIDs. Most [all] standard/basic services are provided for free.

To "AllThumbs" - PBX in a Flash is just another Asterisk distribution which utilizes the same common Asterisk code thus requiring someone to possess certain knowledge _before_ that one is capable to use all functionality provided by Asterisk. B/w - Callcentric has a number of PIAF installed on premises - in order to provide an adequate support to those customers who are able to get it.

To date - you're the only one who "officially" claims something about Asterisk while not even being a part of Asterisk (Digium) development team. On Callcentric side - Callcentric is being in touch with Asterisk during long 10 years. Digium is always cooperative, but it takes long time to fix or modify anything within the system behavior - all due to a huge number of installed and supported servers all "belonging" to different distribution versions and packages.

Unfortunately, the Registration logic is something where Asterisk code is not completely RFC compliant. That's right - Asterisk perfectly works when there is one or two Registrars, preferably - not DNS SRV based. But when there are multiple SBCs - this is where Asterisk's logic leads to troubles. "AllThumbs" - you may speak of hundreds service providers (who are [b/w] all Asterisk based) or millions marching "not in step" (love this term - this is something I escaped many years ago), but if a UA registers 6 times (for example sake) with different SBCs while it also _maintains_ its registration - it MUST also obey REGISTRATION related parts of RFCs including timer/timeout parts.

This is why I wrote about ability to use Wireshark (or former Ethereal) - it's very easy to see the picture then.

Therefore, if an UA is registered to 6 Registrars (SBCs) - it MUST _expect_ an incoming call from ANY of those 6 Registrars. When it rejects a call based on its own internal logic - then it leads to customers' problem not being able to receive calls until one of those two above mentioned solutions (or their variants) have been properly configured.

As Mango wrote above - it's NOT Callcentric problem when Callcentric MUST use a large number of SBCs - due to having an absolutely open network supporting ANY devices and in order to use a sufficient processing power to protect itself from different Distributed Denial of Service attacks. Those SBCs are announced via standard DNS "A" and "SRV" records. And it's Asterisk whose code decides on which records to consider [at this very moment] to be registered with and which to consider to reject calls from. For a customer the above means - two ways to resolve the problem: either by allowing not restricted access (by also utilizing side protection measures like Firewall/NAT/etc.) or by listing all possible sources (IP addresses and names) of incoming calls (which is inherently not reliable and thus denies the whole notion of using multiple SBCs).

As Mango also wrote - Asterisk should behave the same way as most SIP RFC compliant UAs behave - choose certain records and then stick to them until a failure discovered while allowing incoming calls from those IPs it currently sticks to. Or it would be nice to be able to declare provider's DN reverse resolution name - any requests coming then from provider's domain would be accepted - that would allow the most flexible and the most secure solution.

The last - I've explained the theory and background of operation. It's not something which is even remotely possible to be "fixed" by Callcentric... nor it's even more discussable.

 

[Mango]

In case anyone is curious about an Asterisk admin's explanation why it works the way it does:

Asterisk does separate DNS queries for the IP address that is used for the peer and the IP address used for registration. Since Callcentric currently uses 20 IPs, these two queries will return different results 19 out of 20 times.

When an incoming call arrives from the switch that you registered to most recently, Asterisk compares the IP of this switch with the IP of its peers. 19 out of 20 times there will not be a match, and the call will be treated as anonymous. In other words, Asterisk is registering to a specific switch, but refusing calls from it.

This behaviour will occur with any service provider that has multiple IPs behind a single DNS name, if you have not created peers for each IP.

 

[Trimline2]

Someone correct my memory, but when I was using Vitelity, they too had a number of IP peers. The difference between Callcentric and Vitelity is they assigned you an incoming host name via their portal, such as host=inbound24.vitelity.net, host=inbound28.vitelity.net, etc.. making it very easy to administer and monitor your trunk status. Assignments were determined by the type of device that was connecting to their service, Asterisk, 3Cx, an ATA, etc..

A separate outbound route was required as well when using a PBX, but it was fairly generic.

Callcentric should consider this type of IP maneuver for their Asterisk customers.

 

[Mango]

You can certainly hard-code IP addresses or hostnames (alphaXX.callcentric.com) if you wish. But that would be less reliable than if you used DNS for load balancing and failover.

 

[wardmundy]

See this thread on DSL Reports for an exhaustive look at "The Callcentric Problem with Asterisk" or "The Asterisk Problem with Callcentric" depending upon your perspective.

If you need Callcentric, the documented fix is posted above.

 

[Trimline2]

Out of sheer frustration with CC, I am testing an easier fix to make Asterisk work, and I'm not even a regular customer. This just irritates the heck out of me, especially when some says it works and it doesn't. I should have something by tomorrow, as it needs a bit more shining.

The DSLForum is steaming hot and my thumbs are frozen... LOL