Categories

CUC (6) CUCM (27) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (2)

Thursday, 16 June 2016

How to Add an ARC Console queue

This post describes, what to do on an existing ARC server to add an additional console Queue to the system, assuming your servers are already set up, you have TAPI with CUCM and directory integration with CUCM working. So before you begin, a couple of things will need to be configured on the CUCM side of it. Let me start with that


CUCM prerequisites


In all you will need to provision 5 types of devices




These prerequisites are suggestions in terms of naming convention. In the convention below the # increases and each number has an extension. also there are always two devices; one is registered on your on your primary CUCM and the second one is registered on your secondary CUCM, this provides redundancy. Do this by means of assigning two different Device pool each with a unique call manager group in them, forcing a registration split between SUB and PUB.  This does mean however,  that you will require twice the number of extensions.



Also, before you go any further, reserve a bunch of extension to allocated to the ARC devices, for my particular test setup i needed 64 extensions. They can be internal extensions as they are predominately used for comms between ARC and CUCM

Add the following devices to CUCM:  

  • Host PBX: ARC_PUB_<loc>_HP# and repeat for ARC_SUB_<loc>_HP#.
  • Pre-CT: ARC_PUB_<loc>_PCT# and again repeat for ARC_SUB_<loc>_PCT#
  • Service Queue: ARC_PUB_<loc>_SQ# and repeat for ARC_SUB_<loc>_SQ#
  • Call Parking: ARC_PUB_<loc>_PK# and ARC_SUB_<loc>_PK#
  • Static Voice Ports: ARC_PUB_<loc>_VL# and ARC_SUB_<loc>_VL# .
  • Queue Locations: ARC_PUB_<loc>_QL# and ARC_SUB_<loc>_QL#



So for instance, you have two Subscribers; SUB1 (primary) and SUB2 (secondary).  ARC_PUB_NewYork_HP01 registers on your primary call manager SUB1 and will fail over to SUB2. ARC_SUB_NewYork_HP01 will register on SUB2 first and will fail over to SUB1.  Again, all this is done through the use of two separate Devicepools, each with a different call manager group, forcing the device in question to register at opposite subscribers. 


Most of the ARC configuration, is done through ARC Administration, so lets spin that up, and go to CT Gateway. Now, assuming that you have already that you have already provisioned the CUCM side of things, this should be easy.


Fig.1.- ARC administration

1 - Add a resource group


In the ARC administration menu (Fig 1,)  > CT Gateway  > Resource Group

Fig. 2 - Resource Groups

In this case, called E_RG. 

2-Configure Resource Group devices


Now that the resource group is configured, it will need to be populated with parameters. So in Fig.2. select the tab "Resource Group Devices".   So the following configuration items are applied to a single resource group and you can make the apply to a single ARC console queue. So for the next few steps you can stay withing the "Resource Group Devices" (Fig.3).

Start off with the Tab "Host PBX devices" (See figure 3) and populate it with the extensions that were added to Call Manager under  ARC_PUB/SUB_<loc>_HP



Fig. 3 - Host PBX devices
Add the Pre-CT Gateway devices (ARC_PUB/SUB_<loc>_PCT#) and add the extensions that you added to the CTI Route Points in CUCM, in our example I added 3 CTI RP's (901831,2 and 3), see Fig.4.


Fig.4. Add Pre CT Gateway Devices
Now select the Service queue TAB in figure 4 and add the Service Q devices, pretty much the same way as the CT and PBX gateways.

Now allocate the Voice lacantions (separate tab in Fig.4) and Call Park (also a tab in Fig.4.)  and use the extensions previously configured on CUCM, for ARC_PUB/SUB_<loc>_PK# and  ARC_PUB/SUB_<loc>_VL# respectively.

After having done all this, it is a good test to see if all your CTI ports and Route Points are registered. If there are not, well no point continuing any further, and get it sorted out first. (and ARC server reboot might be required especially after you have added additional licenses to the machine).


3 - Add Operator(s)

In order for people to log into the ARC console for a particular queue, you will need to add users, i.e. Operators. 

on your ARC server, in ARC administration, open the User Management tool (Fig.5)



Fig.5. add console user

First go to the Permissions tab, and add a new permissions group that you will apply to the new operator in the Next step. Once done, go to the Operators TAB to add a new operator console login. 

Fig 6 - add console user

Create the name, password and assign the previously added permissions group.


Now we are getting somewhere, we have added the communications between ARC and CUCM by means of the gateway devices, we added an Operator with some permissions and now we still need some way to actually hand the calls over to a queue/operator. Most of this is done through the console connect Configuration, so let's bounce.

4-Console Connect Configuration

Again, in the ARC administration page, go to Configuration > Console Connect.  The main page is depicted in Fig.7

First add the queues as these will actually hand off the calls to the operator. 

So let us look at queue 1 first,  in Figure 7, queue 1 has the extension 901846 assigned to it, on the primary ARC server, Queue 1 on the primary server is CTI Route Point ARC_PUB_<loc>_QL01 on CUCM



Fig. 7- Queue details

After the queue is created select the "queue overflow" tab (fig.8) where, who would have guessed it, overflow is configured. Please note that overflow settings can also be configured through the supervisor console, but that is for another post.


Fig. 8 Console connect main page
For example let's say we wanted all calls to go to a certain phone number (12345) on CUCM, in the event that no Operator is logged into the queue, in that case we populate the No Operators property in the overflow tab (fig.9). to go to device with extension 12345 (see below).



Fig.9.- Queue overflow details


This overflow extension could be a hunt group, a mobile, anything that your CUCM can route, typically what happens is that as soon as an operator logs off at 5 o'clock in the evening when their shift finishes, this setting kicks in an will direct an incoming queue call to for instance a night shift or after hours security desk. But I will leave that up to you.

There is one more important items to set up in the Console Connect Configuration namely Call Filters. Call Filters defines what call actually land on a particular queue. Call Filters very much link the incoming CUCM DDI into the appropriate queue, using the already defined Pre-CT gateway. in Fig.10 extension 901831 is assigned as the primary PreCT gateway.


Fig. 10 - Call Filters

The call filter in Fig.10 means that any incoming call to 901831 (which is a Pre_CT device) will be delivered to the Transport queue (DDI/DNIS exact match). You could, if you wanted also filter based on the ANI of the caller, but that's for another time, maybe. PLease note that in the call filters the Queue DDI is also, added. this DDI is the extension 901846 in this case, which is a QueueLocation CTI routepoint.


After you finished configuring all this on ARC, you will probabaly need to restart the CT server. You could decide to reboot the servers themselves, but let me show you how to do it elegantly.

On your ARC servers's desk top, open up ARC Connect server, go to FILE > 


and STOP the CT server, once done, start it again.




Good luck folks.

No comments:

Post a Comment