Assume all FreePBX 14. I have a queue on FreePBX-01. I have extensions registered on FreePBX-02. I have been trying to work out how to have extensions registered to FreePBX-02 as queue members in the FreePBX-01 queue. I was looking for a way to login “1001@FreePBX-02” without creating a trunk or custom extensions on FreePBX-01.
Is there a way to do this?
My short answer: when I tried the answer was “no”. I ended up creating local custom extensions with the dial string of the extension and server in them.
This is possible, my approach isn’t perfect, and not ideal for large contact centers, there are better solutions for those situations.
This approach you can easily test and requires no custom dialplan and really should work for smaller centers that probably don’t care about metrics as much. You can do it with FreePBX settings right out of the box.
EXAMPLE
PBX01 has Queue#9000 and local extensions 1000-1999 and an IP of 10.1.1.10
PBX02 is the remote PBX with extensions 2000-2999 and an IP of 10.2.2.10
We want to have extension 2501 on PBX02 register to the queue 9000 on PBX01
We’ll start at PBX02 and move forward to PBX01.
STEP 1
Deactivate call waiting on the extension(s) on PBX02 that are going to be part of the queue.
PBX01 can deliver the queue call to PBX02, but it doesn’t know the offical state of that extension for subsequent queue calls. This means that if PBX02 extensions are on queue calls already, they are still a target for subsequent queue calls.
With call waiting active, they will keep getting beeps in their handsets for calls over and over. Would be annoying.
Increase the time for calls to go to voicemail on PBX02 (if applicable) by a couple of seconds more than the agent timeout value in the queue. If the queue agent time out (the duration of time the agent has to answer a call) is the same as voicemail, the vm MIGHT answer the queue call. So if agent timeout is 15 seconds, make voicemail 17 seconds. (or just disable voicemail on the extension completely).
(Or better, create a separate line on the phone just for queue calls if possible)
STEP 2
ON PBX02 FREEPBX-> FEATURE CODES, disable QUEUES *45, *46 and *47. (de-select ENABLE).
We want to use those built in feature codes on PBX01, and not have PBX02 respond to them.
Assumption is that PBX02 has no queues on it. (If it does, we can do some other work around)
STEP 3
You have 3 general ways you can logon to the queue (built in with FreePBX).
ON PBX02 create an OUTBOUND route for PBX02 to PBX01 (assuming trunk exists already) and use these 3 dialpattern matches
*45XXXX*XXXX
*45XXXX
*45
(Login explanation)
*45 will take log you into any/all queue(s) that you are a dynamic agent of based on a CID match of your phone with the number programmed in DYNAMIC AGENTS in the queue.
*45XXXX, where the XXXX is the queue number will log you into a specific queue. So if you are a member of 4 different queues, you can log into the ones you want specifically. Again CID match is performed
*45XXXX*XXXX will let you logon any extension to to any queue. *45extension*queuenumber
This method will force the extension you dial into the queue you want without requiring a CID check.
So if you dial *452501*9000 this would send the exact sequence to PBX01 and log extension 2501 into queue 9000.
STEP 4
If you are going to have PBX02 agents use the *45XXXX*XXXX sequence then you just need to do step
"A" ,
however if you plan or think they’ll use *45XXXX or *45 then follow step “B”.
Both can be programmed in to cover all bases if you desire.
A>
ON PBX01 create a SIP extension that matches the extension on PBX02 in the manner they are logging in. Yes. So 2501 would be on PBX01 and PBX02.
B>
ON PBX01 create a SIP extension that matches the CID extension on PBX02 in the manner they are logging in. So if it the CID is 707-555-2501, then put in an extension with that full 10 digit number in PBX01
STEP 5
On this 2501 extension you created in PBX01, (and the CID option B based one too) under the ADVANCED TAB, change the HOST entry from DYNAMIC and replace it with any valid IP.
In my example I’ll replace it with PBX02’s ip of 10.2.2.10.
Doesn’t matter to much what the IP is, just as long as it is (for arguments sake) an IP that PBX01 can ping.
This will trick PBX01 thinking that 2501 has a valid IP that it could deliver calls to (but we aren’t going to use that iP for that delivery) and more importantly allow it to be a legit target for the queue.
6> Under the advanced tab of 2501 (AND the CID length version too!). Replace the DIAL entry (will have something like SIP/XXXX in it) and replace it with the sequence to dial PBX02 via the trunk between the two systems.
For example, if you have an IAX trunk in FreePBX between these two PBX’s named "PBX01-PBX02 , the sequence would look liek this: iax/pbx01-pbx02/2501
So now if the queue (or even an extension native to PBX01) calls 2501, PBX01 will see its a local extensions, but when it goes to dial it, will just push the call right to PBX02 across the trunk as it normal would.
Save your changes and test! It really should work!
From PBX02 dial *45, and provided that your CID (AMPUSER in livelog) matches the number in the DYNAMIC AGENTS in the queue, you should hear “Agent logged in”
Place a test call, should get the queue call delivered!
Conveniently, the backout form this is just delete the extension from PBX01.
We did this with a customer not long ago as a stop gap and they didn’t report any problems. Maybe it will work for you! Or at the very least you learn some tricks to solve other problems in the future.
If having problems i’ll try and help, post some logs of fails and i’ll see if i can help.
Post questions and i’ll try and clarify where i can!
Thanks, dickson! I really appreciate your detailed instructions. This IS for a large call center with hundreds of agents and frequent changes. What “better solutions” were you thinking of for large contact centers?
Probably not that solution…I mean, sure you could run a huge center doing that deployment, but that method the queue doesn’t know if the remote agent is on a call or not, so it will keep targeting them for a call. I feel that it could cause some potential reporting problems (calls offered to agent = 100, answered =4 because agent was on the phone for the other 96 attempts). Or if you have autopause in a queue, it could put the agent into a ‘not ready’ state.
I’m spooling up some VMs, I’ll see if i can sort that registration issue out or not.
I’ve been wanting to try the FreePBX Cotnact Center solution but i’ve been met with rolling tumble weeds when I’ve asked for a demo or test licence to really try it.
An approach like the one pictured here (doesn’t have to be their software) would probably scale best.
http://www.indosoft.com/acd-for-asterisk.htm
Ok, so here is what we do for our own organization today.
I didn’t talk about it at first, because you mentioned you weren’t interested in setting up a bunch of trunks, and I assumed you only had a few extensions (10-20) vs 100-200 or more like us.
But the method I currently use requires a little bit of configuration but might be the best bang for your buck.
And requires -NO- custom dialplan. Completely doable through FreePBX GUI.
So the problem we needed to solve:
How do I connected different extensions belonging to different geographical PBX’s, (some asterisk, Mitel and Avaya) into a single unified queue regardless of brand or numeric requirements? We have a mix of SIP, IAX and PSTN PRI connectivity. This is challenging in itself, but absolutely critical is reporting.
Call center reporting is crucial to businesses running large centers.
Well how do we do this?
The KEY for me to solve this problem was creating a separate FreePBX instance that I refer to as the “ContactCenter Gateway” (C.C.G.) Its sole purpose is to act as an intermediary device between the asterisk queue pbx and the SIP and PSTN trunks to the different centers.
First and foremost, it poses as a SIP registration point to the QUEUE through individually created SIP trunks.
So the asterisk queue sees every extension that belongs to a queue properly registered with a user/password and valid IP (being the IP of the CCG) just like a soft or hardset would register.
Secondly the CCG has VoIP and PSTN connectivity to all the pbx we have around the world that would need to be part of the queue.
Operation:
1>
Any user in any office picks up their desk set and dials *45, that call hits the queue PBX, the CID confirms a match to their extension. They will hear “Agent Logged In”.
2>
When a caller enters a queue, and the queue targets extension 2501 (for example), the queue PBX sees that extension registered in its SIP table (sip show peers) with an IP (CCG IP)
3>
That call is sent to the CCG, the CCG has an inbound route to match each extension, in the example of 2501, the inbound route is did=2501 and its destination point is the trunk to PBX02,
4>
Call arrives on PBX02, and is sent to the extension. The extension answers. The beauty is the messaging comes back to the queue on PBX01, and call shows INUSE in the queue.
5>
Proper metrics in the call center reporting. No calls target that extension until the agent hangsup.
For our India users, the same thing happens, however on the trunk to the PSTN gateway(Vega200s) I tag on the 011 in front of the number and call goes to india, call goes PSTN to our office there, rings the user, agent picks up, message comes back and now queue reports as INUSE.
Here’s a picture…might help?
Wait…what? you register each extension as a trunk? This works??
YES. and YESSSS! Heres the details:
So on the asterisk PBX01 queue box, I create an extension that matches the CID of the extension of the remote users will login from as it appears in the logs when they dial *45
In the case of 2500 range on PBX02, they just show up as “CID=25XX”. So there is an extension created to match these.
Same with India, those numbers show up as 91775555XXXX when they logon (registration happens across an IAX trunk, but full CID is displayed). So there are extensions in the asterisk PBX01 that are 12 digits long. no big deal.
When a user dials *45, the call comes to the queue, and if the CID=Number in the Dynamic Agents box in the queue. They get logged in.
The CCG
In that box every single extension that is in the PBX01 system gets its own SIP trunk. I use the user/password information for the extension as configured in PBX01 in the SIP trunk info in PBX02.
In the CCG I create a SIP trunk. Each individual trunk name reflects the 4 digit number
the outgoing/incoming context I leave blank.
On the the incoming section at the bottom there is a registration string. The syntax i put in here as follows:
extension:password@PBX01_ip_ADDRESS/extension
ie:
2501:[email protected]/2501
With that method, repeated for each extensions, you will now have the call control you desire.
Yes, there are some tweaks i’m probably forgetting, but we did this ALL in dialplan
@dickson That is a pretty impressive setup. So now this isn’t in any way me dumping on this solution but it is a mix of IAX, Dahdi and Chan_SIP. My concern is over the latter.
Chan_SIP has been deprecated since Aug. 2014. It only receives bug fixes/updates by Asterisk community members. It is not officially supported by Digium (and thus Sangoma) and hasn’t been the focus on any new development in Asterisk for over 4 years.
Chan_SIP is also marked to start going no-load in upcoming release which means you actively will need to config/enable Chan_SIP for it to be an option to use. Within the next 1-2 LTS releases I would expect it to be gone. So let’s say in the next 5 years.
What is the plan for a setup like this that is going to be losing one of the channel drivers it depends on? I’m hoping it’s not going to be a “We’ll just never update and stay where we are” type plan. That’s a bad plan.
You, for your setup, are probably looking at months or even a year or so of testing and validating your setup on the new SIP driver (PJSIP) to make sure everything is working properly. So while your setup is impressive and kudos on it, it is probably not a setup that should be shared with new people looking to do something like this because they will be in the same boat down the road. The need to update their stuff to Chan_PJSIP.
The last thing you need is a FreePBX version update that goes “Oh we are going to migrate all your Chan_SIP peers to Chan_PJSIP because Chan_SIP is longer available” which can then completely screw up your setup.
No worries! No you aren’t dumping, those are valid questions.
I’m moving into my 30th year in IT. And in my career, I’ve learned 2 things.
First IT reality
Whatever IT project I build now, no matter how how cool, feature rich or cost beneficial it is, just won’t mean jack to anyone, in 5 years. It’ll all be different then, so whatever needs updating at the 5 year mark, will be ripped out and replaced with whatever is cool, feature rich and cost beneficial at that time.
Second IT reality is
Nobody -ever- wants their phone system touched. EVER.
Whats my plans for this solution? I am not going to do anything to it at all but keep it fed and cooled, and MAYBE patched for anything critical. Its working now, it will work 5 years from now. If I have the OS and the source, it’ll work a decade from now.
This project came to me, not because of the quarter of a million dollar price tag the customer was presented for a full solution end to end solution. They wanted to know if they could avoid forcing their employees all over the world to needlessly re-learn a new system that, to the end user, did the same thing as the old one, only in annoying different ways for different people.
That being said, as for upgrades, I’ve not put a lot of thought into that project to make it bleeding edge. Its not like i’m going to wake up tomorrow and all the Chan_SIP drivers all over the world disappeared. I’ve worked with asterisk steady since Asterisk@Home was the new thing, we all just keep evolving with the product. I’m sure I can make this type of deployment work even better and easier as new features unfold, and I’ll use that in new deployments. Maybe this one will get updated with new feature realizations, but honestly, I doubt much will need to be done.
That would mean that at a certain point you would be running a PBX that runs a version of Asterisk that would be considered EOL and no longer supported. It would also leave you on an OS that will eventually be EOL and no longer supported. Look at Distro 6 (v13) as soon as SNG7 was released the previous distro OS was soon moved to EOL/SFO.
For a quarter of a million price tag and even the “never touch my PBX” mentality. Finding out they are up schitt’s creek with no paddle because everything they are running is out of date and unsupported isn’t going to play well, at all.
It’s never going to be an issue of “I can’t find a version of Asterisk with Chan_SIP” it’s going to be an issue of having current and properly supported versions of Asterisk/FreePBX for everything else that will need support. Pigeonholing yourself over the SIP driver is risky.
Thanks, Dave. Custom extension was my fallback if the simplicity of "1001@FreePBX-02’ was not available. I’ve done that with Verizon OneTalk phones but the extension state was not tracked correctly. Do you have that issue?
Not that I’ve noticed. As with other “foreign” connections, be sure to turn off anything that would give the calling PBX the impression you are going to get to the call.
Valid Points!
Absolutely have old asterisk/centos 5&6 deployments in full use. Still running.
Those users needs are being met, I dont need to touch it. Barring a catastrophic hardware failure, the OS will run forever. Being out of EOL just means I can’t call a 800 number for support, something I’ve never done for asterisk or linux
My point is, if the end customer understands the risk and signs off on it and the support group understands the technology, then how big a risk is it really if you know what to do to fix a problem should it arise?
I’m sure everyone here reading this use stuff in critical situations that is not under support. Its just a fact of business.
No, it also means things like Apache, MySQL, etc are going to stop being updated. System level stuff that is going to not be updated. Apache finds an issue and needs a patch or says “you need to update to avoid this hole” you won’t get that. PHP is already behind, etc. There is more that needs to be consider then calling Sangoma support for module help. FreePBX is just a piece there is an entire system OS there.
I get that not everything maybe not under support by a company but FreePBX has a lot of other things in it, as I mentioned above. However, to never review you setup on a regular basis, like yearly, to understand where you are at and if any new risks have come up that need to be reviewed and mitigated is not the best course either.
Because there is also that whole future planning part of it as well. At some point someone will say “Hey it would be really cool if we did this” and have to be told “Yeah, it would be but we can’t because we don’t have anything current that can support it”. So it really comes down to have a long term plan and proper risk management/mitigation in place.
@dickson Kudos on your system and thanks for the help! You have definitely given me some ideas. One advantage I can see in your trunk=extension system is easy trunk failover since we don’t have HA on 14. We have 250 - 750 agents in 5 locations depending on time of year, elections, etc. At first glance it seems this would be somewhat cumbersome to setup and maintain in the GUI, but I guess we could automate an update of extensions_custom.conf. I will experiment and let you know.
I absolutely agree, but I think “Long term” these days means about a year. Who can really see beyond that? Hardware has 100% failure rate, so redundancy the only solution. CentOS 5 is still reliable if you have a warm spare. We build the standby systems with up-to-date (but not bleeding edge) modules and migrate to them when the original becomes “long of tooth.” By that time, the up-to-date spare is nearing EOL so we make a warm spare with up-to-date modules … and on it goes.
Longest Term Plan: Virtualize everything possible to keep application support and hardware independent. Software lasts forever. I still have a couple Windows 2000 Server VMs that are still reliably doing the intranet job they’ve done for for the last 2 decades. They now live in their 4th VM Host.
Very cool idea Dickson! This opens a lot of doors for us as we are a blended environment (Asterisk, Avaya and others). Thanks for taking the time to describe this.
This is one of the cases where the old feature code QUEUE* and QUEUE** would be helpful.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
