Tuesday, September 13, 2011

CUCM Assistant (IPMA) Feature


UCM Assistant Functionality and Architecture

UCM Manager Assistant (or called IPMA) feature consists of three components: Cisco IP Manager Assistant service (IPMA service), the assistant console, and manager console (IP Phone interface).
 

Cisco IP Manager Assistant service

Once IPMA service is activated on UCM server, it will check to see whether this server is the primary IPMA. This is done by comparing server IP to Cisco IPMA Server (Primary) IP Address service parameter.  If it is, IPMA service attempts to become the active one. Currently, a UCM cluster supports only one active IPMA, i.e active/standby redundancy model
The Cisco IP Manager Assistant service performs the following tasks:
·         Communication with assistant console and manager console through HTTP protocol (Tomcat)
·         Call routing decision in IPMA proxy-mode based on manager filter configuration (in shared mode this is not applicable and filter will be showing down in assistant console). More details are provided later.
·         Passing call control instructions from assistant and manager consoles to UCM CTI manager for phone control.
·         Access UCM database for user authentication and settings (this is different from UCM assistant (IPMA) database which is covered next)

Assistant Console Interface

This is used for user-login, call control, assistant preferences, monitoring managers call activity, keyboard shortcuts.
Assistant console can be downloaded and installed by navigating to CUCM Administration > Applications > Plugins.

Manager (Cisco Unified IP Phone) Interface

This is used to configure call routing filters (which calls are sent to assistant and which are routed to directly manager), immediate divert target (for this iDivert feature should be configured for manager phone), and DND
Note: Both managers and assistants use special softkeys templates to access and control their respective features.

UCM Assistant Database Access Architecture

The database stores all UCM Assistant configuration information. When the manager or assistant logs in, the Cisco IP Manager Assistant service retrieves all data that is related to the manager or assistant from the database and stores it in memory.

UCM Assistant Modes

The Unified CM Assistant application can operate in two modes: proxy line mode and shared line mode. Both modes can be configured within a single cluster. However, mixing modes on the same assistant is not allowed.

UCM Assistant Proxy Line Mode

·         In this mode manager and assistant are having two different DNs
·         CTI RP is required and should have the same DN as manager (acting as proxy line)
·         Manager DN should be reachable from assistant DN and CTI RP DN ONLY
·         CTI RP and assistant DN MUST be able to reach each other
·         Assistant DN and CTI RP should be reachable for any caller
·         CTI RP DN should be associated with IPMA service configuration
·         A call destined to manager DN will hit CTI RP DN (since both are sharing same DN and CTI RP only is allowed for outside callers)
·         The call on CTI RP will trigger IPMA service which in turn will forward the call to assistant DN (This can be tuned according to manager filter settings)
·         In case IPMA service isn’t available (IPMA service down, CTI RP down, assistant DN down), the call will be dropped
·         For redundancy purpose, fall-through mechanism can forward the call directly to manager DN in case IPMA service isn’t available. This can be done using CallFowardNoAnswer (CFNA) configuration on CTI RP DN pointing to manager DN directly


UCM Assistant Shared Line Mode

In this example, Phone A calls the Manager phone with directory number (DN) 60001, which is a shared line on the Assistant phone (step 1). The call will ring at both the Assistant and Manager phones unless the Manager has invoked the Do Not Disturb (DND) feature, in which case the Assistant's phone will be the only phone that rings audibly (step 2). In this mode Assistant RP isn’t required.
 

UCM Assistant Configuration Steps

IPMA Proxy Line Mode Checklist


[Call Intercept]
1) Create Partitions & CSSes as follow:
CSS
Partition
CSS_DEFAULT
PT_INTERNAL
CSS_IPMA
PT_MANAGER

2) All DNs should reside in PT_INTERNAL except manager DN. This should be isolated in totally separate partition such as PT_MANAGER.
3) All endpoints should have proper CSS (CSS_DEFAULT) to communicate with each other including manager endpoint which should be able to communicate to all other DNs.
4) ONLY CTI RP and Assistant DN (it can be same as primary DN or another separate DN dedicated to manager) should be able to communicate with Manager DN by having CSS_IPMA.

Notes:
a.       CTI RP DN should have same DN as Manager Primary. Else calls won’t be routed to assistant (proxy DN) when RP DN is called. Based on CTI RP DN dialed, IPMA determines manager DN, and accordingly identify assistant DN (proxy DN) to route the call to.
b.      CTI RP DN can be associated with single DN (representing single manager) or wildcard range of DNs (range of managers)
c.       Set CFNA to “100X” or to “1001” if you provide call coverage for just one manager. This will provide call backup if the IPMA application fails.
d.      The reason of having manager DN isolated is to avoid mixing between CTI RP and Manager DNs since both will have the same number. When outsider dials the number CTI RP DN should be only selected (NOT manager DN directly) to achieve IPMA.

[IP Phones]
1) Create a new Button Template, say “3+3 7960” to allow more than two lines on an IP Phone. You will need this template for assistant’s phone, to accommodate three lines: primary, proxy and intercom. (Optionally primary DN can be used as proxy as well simultaneously).
2) Configure the Manager’s Phone
2.1) Set Softkey template to “Standard IPMA Manager”
2.2) Configure the primary line in “PT_MANAGER”
2.3) Add an intercom line, “*1001” and a speed-dial to “*1002” to reach the assistant
2.4) Create IPMA IP Phone service & subscribe the IP Phone to it. IPMA service URL is:
http://:8080/ma/servlet/MAService?cmd=doPhoneService&Name=#DEVICENAME#

3) Configure the Assistant’s Phone
3.1) Set Softkey template to “Standard IPMA Assistant”
3.2) Set Button Template to “3+3 7960” (assistant needs extra lines)
3.2) Add a proxy line “1112/PT_INTERNAL” and set the Line CSS to “CSS_IPMA” for this line
3.3) Add an intercom line, “*1002” and a speed-dial to “*1001” to reach the assistant

[Users]
1) Create a new user named “manager”
1.1) Allow Control of Device from CTI and assign CTI roles
1.2) Associate this user with manager’s IP Phone
1.3) Assign Primary DN
1.4) From Related Links tab, navigate to Manager Configuration
1.5) Uncheck Automatic Configuration
1.6) Select Manager Device, Associate Assistant, and Define Manager Primary DN

 
2) Create a new user named “assistant”
2.1) Allow Control of Device from CTI and assign CTI roles
2.2) Associate this user with assistant’s IP Phone
2.3) Assign Primary DN
2.4) From Related Links tab, navigate to Assistant Configuration
2.5) Uncheck Automatic Configuration
2.6) Select Assistant Device, associate Manager, and associate Assistant DN (whether dedicated or primary) with Manager DN to be proxied.



[IPMA Application]
1) Activate Cisco IP Assistant Service
2) Choose Service Parameters for Cisco IPMA Application
2) Configure CTI Manager IP Addresses (primary/backup). In simplest case just use your Publisher IP
3) Configure IPMA Application IP Addresses (primary/backup). In simplest case just use your Publisher IP
4) Set the CTI RP name for the IPMA application
5) Restart IPMA and CTI services

[Verification]
1) Check that manager’s phone has IPMA softkey set on its screen
2) Install the Cisco IPMA Console Application and log in there as “assistant”
3) Place a call to manager’s primary line, ensure it gets routed to the assistant phone, and pick it up from the IPMA console. Forward the call back to manager’s primary line.
4) Configure from the manager’s phone to accept all calls and place a call to manager’s primary line once again.
Notes:
1. Phones will connect to IPMA service automatically without the need for manual login.
2. Proxy mode has the capability to add filters. Using this feature, either manager or assistant can define set of DNs which can call the manager directly. Those calling DNs don’t need to have CSS to access manager PT as this will be managed by IPMA and filtering service. Same applied to CFNA fall-through where no need for caller to have manager CSS in order to connect.
3. Filtering decision is made before forwarding the call to manager or assistant. Thus filtering service should be up for call to be completed successfully.

4. In case modifications are done to IPMA configuration, IPMA service should be restarted else abnormal behavior can occur such as filter down, call control down, etc.

IPMA Shared Line Mode Checklist

The checklist is similar to proxy mode with following differences.
1. Under manager configuration, Uses Shared Lines option should be checked. This will allow manager and assistant shared DN to ring simultaneously
2. Add new shared DN to both manager and assistant phones. The dialer should have access to shared DN partition.
3. CTI RP related configuration isn’t required.
4. Filtering service isn’t applicable since both phones (manager and assistant) will ring


Saturday, September 10, 2011

TCL Example: B-ACD Based TCL

I thought to elaborate more on TCL side since VXML complexity is centerlized at server level (from gateway side nothing is required that pointing to VXML server). For this purpose I thought about explaining B-ACD based TCL in details.


B-ACD application is used to provide call queuing with IVR capabilities. Each B-ACD application is made of two TCL scripts: Auto-Attendant script and Call Queue script. Call queuing is provided by the combining call queue script and ephone-hunt groups (Voice Hunt Groups can’t be used with B-ACD. You can still forward from ephone-hunt to voice hunt-group but voice hunt-group pilot can’t be assigned to call queue script).

Before going into application details, below is the flow chart to understand how it works:


Following the TCL implmentation steps mentioned in the previous blog:

1. Upload the scripts (both AA & Call queue) into gateway flash (Completed)
2. Upload the associated audio files into gateway flash (Completed)

3. Initialize local and global parameters. 

This is the major part of B-ACD application. As mentioned  B-ACD application is made of two scripts (AA & Call Queue). Therefore, the parameters for both scripts should be initialized.


a.       AA-IVR pilot DN under aa-script (param aa-pilot number). Secondary number can be configured (param aa-pilot2 number).
b.      Welcome prompt and other audio files under aa-script. Customized prompts can be uploaded using the same default prompt name (overrite) or using different names.
c.       Language and language codes under aa-script (global parameter). Default language used is English and code is en. Other supported lanaguages are Chinese (ch) and Spanish (sp). Also, all three lanaguages can be enabled simultenously (aa)
d.      Map menu options under aa-script. AA-script contain the following menu options:
a.       3 hunt groups (range from 1-3)
b.      1 operator (0)
c.       1 dial-by-extension (param dial-by-extension-option menu-number)
Therefore the max number of hunt-groups to be configured in aa-script is 3 since operator and dial-by-extension are not counted in aa-script as hunt-groups (param numer-of-hunt-grps number).

The hunt-groups and operator in aa-script are mapped to ephone-hunt pilots through queue script as follow:

param aa-huntmenu-number ephone-hunt-pilot

*** The highest configured menu number will be used for operator when 0 is pressed. It can point to ephone directly instead of hunt pilot. ONLY EPHONES NOT DIAL-PEERS***

param number-of-hunt-grps number

***This varies from (1-10). BUT, Why the max number of hunt-groups can be 10 if only 3 hunt groups can be supported in aa-script ????

The main reason is that one queue script can be shared between multiple aa-scripts. Assume aa-script-1 has 3 hunt-groups and 1 operator, aa-script-2/3/4/5 have drop-through-option to different ephone-hunt groups, and all of those aa-scripts are using same queue script.

In this case the number of hunt-groups under queue script should be 3 (aa-script1) + 1 (aa-script-1 operator) + 4 (aa-script-2/3/4/5) = 8***

Important Note: dial-by-extension menu-number shouldn’t match any of hunt-group menu numbers in queue script. Example: If dial-by-extension menu-number is 1, then options 2, 3, 4 will be available in aa-script. Accrodingly aa—huntmenu-number in queue-script should have numbers 2, 3, 4 (and shouldn’t have number 1).

e.      AA-script can be used in drop-through mode. In this case AA will send the call directly to call-queue script without playing any prompt to caller (as if the caller is dialing the hunt group directly).  If an agent is avialalbe the caller will hear a ringback however, if all agents are busy the caller will hear MOH. To set drop-through-option parameter:

param drop-though-option ephone-hunt-group-number
param drop-though-prompt audio-file-name     !!... In case prompt is required

f.        Call queue exit option in aa-script. Upto 3 hunt groups can be configured for call queue exit option using the command param queue-exit-optionephone_hunt_group_number menu_number. The prompt used for call queue exit is the second greeting stored under the name en_bacd_allagentbusy.au. Optionally the call queue can point to extension directly using the command param queue-exit-extensionoption_number extension_number

g.       Voice Mail pilot number in aa-script. In case the call isn’t answered it can be forwarded to voice mail pilot using param voice-mail number. This number can be a voice mail pilot, SCCP/SIP extension, or any other destination matching dial-peer.


Adding to above parameters, following are some restrictions to be considered when deploying B-ACD:

1.       MoH source should be configured either in telephony service ro call-manager-fallback. Else, the application will throw error and drop the call.
2.       The codec used for voip calls should be G711 only. Even, if XCODE is available, B-ACD won’t trigger it.

Here is a full configuration example including all TCL implementation steps in the previous blog:

voice register dn  1
 number 3005
 name br2 phn 3
!        
voice register dn  2
 number 3006
 name br2 phn 4
!
voice hunt-group 1 parallel
!!!... Forward to voice-mail (5015) if no answer
 final 5015
 list 3001,3005,3006
 timeout 89
 pilot 3210
 !
application
 service aa flash:app-b-acd-aa-3.0.0.2.tcl
!!!... Define the language used by the script
  paramspace english index 1
!!!... Define language prefix
  paramspace english language en
!!!... Define audio files location for this language
  paramspace english location flash:
  param number-of-hunt-grps 2
!!!... Define welcome prompt audio file. Note that en prefix is removed from file name (_bacd_welcome.au). The reason is that we defined language as English (en), thus prefix will be added to prompt name making the full audio file name as en_bacd_welcome.au which is matching the file name in flash (location of English audio files).
  param welcome-prompt _bacd_welcome.au
  param aa-pilot2 3500
  param handoff-string aa
!!!... Define the maximum timer to set call in queue before sending it to voice mail
  param max-time-call-retry 90
  param voice-mail 5015
!!!... Assocaite call queue script with aa script
  param service-name queue
  param aa-pilot 32143500
 !
 service aa-drop flash:app-b-acd-aa-3.0.0.2.tcl
  param voice-mail 5015
  param max-time-call-retry 90
  param handoff-string aa-drop
  paramspace english index 1
  paramspace english language en
  param aa-pilot 32143501
  param service-name queue
  paramspace english location flash:
  param number-of-hunt-grps 1
  param drop-through-option 2
  param aa-pilot2 3501
 !
 service queue flash:app-b-acd-3.0.0.2.tcl
  param aa-hunt3 3001
!!!... Call queue length
  param queue-len 10
  param aa-hunt2 3211
!!!... To enable call queue traces
  param queue-manager-debugs 1
  param number-of-hunt-grps 2
 !
 dial-peer voice 12 pots
 description *** PSTN ---> AA ***
 service aa
 incoming called-number 32143500
 direct-inward-dial
 port 0/2/0:23
!
!!!... This dial-peer is a dummy one used for allow ephones to call B-ACD application. As mentioned earlier, we can’t assigned application to ephones directly. The workaround is to create and outbound dial-peer for B-ACD application pilot having session-target as gateway loopback interface, i.e. gateway calling it self.
dial-peer voice 13 voip
 description *** BR2 ---> AA ***
 service aa
 destination-pattern 3500
 voice-class codec 1
 session target ipv4:142.5.65.254
 incoming called-number 3500
!
dial-peer voice 14 pots
 description *** PSTN ---> AA-DROP ***
 service aa-drop
 incoming called-number 32143501
 direct-inward-dial
 port 0/2/0:23
!
dial-peer voice 15 voip
 description *** BR2 ---> AA-DROP ***
 service aa-drop
 destination-pattern 3501
 voice-class codec 1
 session target ipv4:142.5.65.254
 incoming called-number 3501
 !
 telephony-service
 moh en_bacd_music_on_hold.au
!
ephone-dn  1  octo-line
 number 3001 no-reg primary
 description 32143001
 name br2 phn1
!
ephone-hunt 1 sequential
 pilot 3211
 list 3001
 final 3210
!!!... To enable call queue statistics reporting
 statistics-collect
 max-timeout 90
 timeout 1

Verification and troubleshooting commands:

-          debug voice application
-          debug  voice application error
-          show call application ?
-          show ephone-hunt


DNS Performance Troubleshooting

When you are troubleshooting internet performance, there are different parts of the connection should be verified:   ·         DNS Pe...