Trick asterisk to behave like a softphone

Trick asterisk to behave like a softphone

We had a situation with 20+ remote agents belonging to an Elastix/Issabel contact center that needed to start taking queue calls via PSTN mobile phones vs their SIP office hardsets, which were being removed.   As this was an active queue with other functioning agents, I wanted a fast, risk free transition for these agents.  No playing around with queue settings that could impact customers.

Some testing with callforwarding and follow-me, along with a few other suggestions, showed that, although I could send calls to the agents, the reporting mechanism didn’t function properly, and in a call center, its ALL about the reporting metrics.

I also needed this reporting system to function properly because I needed the agents desktop to continue to show screen pops and allow them to update customer information.

 
In order to satisfy the needs of CC system and the PSTN requirement, I did this as a trick.
 
Any extension that is going to be a remote user will probably need to have NAT turned on in their respective extension setting and will need to have PEER enabled.
 
I installed a 2nd asterisk server with the purpose of “pretending” to be these agents SIP phones. 
I registered an individual trunk connection, 1 for each of the SIP phones, from this new asterisk box to the CC asterisk system.  This gave the appearance to the CC’s Asterisk that the SIP extensions were now registered.
 
 
 
Now when an agent went “ready” in the GUI, the CC would send the call to this SIP connection.
On the 2nd asterisk, when the call arrived, it arrived as a DID being their 4 digit extension.  I forwarded it each DID to a unique MISC DESTINATION, which had their moblie PSTN number in it.  This would immediately forward the call to their mobile phone.  
 
When they answered, this would trigger an “answer” in asterisk, which got passed by asterisk to the CC system, and the customer was connected to the agent.  Metrics were proper and the screen information was still delivered.
 
To register the 2nd server to the CC, I created trunks.  Each trunk had a name that reflected the 4 digit number, but the outgoing/incoming context I left blank.  On each trunk, in the incoming section at the bottom there is a registration string.  The syntax i put in here as follows:
 
extension:password@CCipADDRESS/extensions
 
ie:
1009:password@10.1.100.50/1009
 
================================================================
Some more additional implementation details:
 
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.
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:password@10.1.1.10/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


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.