Caller ID Display over ISDN PRI - PART 1

I thought to divide this topic into two blogs to make it more clear. First we will understand Caller ID Display from ISDN side, then we will map it to call control protocols (MGCP/SIP/H323).

Advanced ISDN IEs Configuration (Facility & Display)

Display IE is used mainly to provide the calling name over PRI Trunk. It can be sent in SETUP, ALERTING, or CALLPROC messages. For example,

Nov 23 12:36:11.610: ISDN Se0/2/0:23 Q931: TX -> SETUP pd = 8  callref = 0x00A3

        Bearer Capability i = 0x8090A2

                Standard = CCITT

                Transfer Capability = Speech 

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA98383

                Exclusive, Channel 3

        Progress Ind i = 0x8183 - Origination address is non-ISDN 

        Display i = 'user01'

        Calling Party Number i = 0x4180, '2023001'

                Plan:ISDN, Type:Subscriber(local)

        Called Party Number i = 0xC1, '3023001'

                Plan:ISDN, Type:Subscriber(local)

Nov 23 12:36:11.642: ISDN Se0/2/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x80A3

        Channel ID i = 0xA98383

                Exclusive, Channel 3

Nov 23 12:36:11.694: ISDN Se0/2/0:23 Q931: RX <- ALERTING pd = 8  callref = 0x80A3

        Progress Ind i = 0x8188 - In-band info or appropriate now available

However, Display IE isn’t enabled by default. In order to enable it different methods are available.

1)

interface Serial0/2/0:23

 no ip address

 encapsulation hdlc

 isdn switch-type primary-ni

 isdn incoming-voice voice

 isdn outgoing display-ie

 no cdp enable

2)

interface Serial0/2/0:23

 no ip address

 encapsulation hdlc

 isdn switch-type primary-ni

 isdn incoming-voice voice

 isdn outgoing ie display

 no cdp enable

Also, calling name is considered as supplementary service and therefore it can be carried over Facility IE instead of Display IE. Facility IE is enabled by default on PRI trunk, however, calling name as supplementary service isn’t enabled by default. Facility IE can be carried in SETUP and ALERTING messages.

interface Serial0/2/0:23

 no ip address

 encapsulation hdlc

 isdn switch-type primary-ni

 isdn incoming-voice voice

 isdn supp-service name calling

 no cdp enable

end

Nov 23 12:26:23.558: ISDN Se0/2/0:23 Q931: TX -> SETUP pd = 8  callref = 0x009D

        Bearer Capability i = 0x8090A2

                Standard = CCITT

                Transfer Capability = Speech 

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA98383

                Exclusive, Channel 3

        Facility i = 0x9F8B0100A10E0201080201008006757365723031

                Protocol Profile =  Networking Extensions

                0xA10E0201080201008006757365723031

                Component = Invoke component

                        Invoke Id = 8

                        Operation = CallingName

                                Name Presentation Allowed Extended

                                Name = user01

        Progress Ind i = 0x8183 - Origination address is non-ISDN 

        Calling Party Number i = 0x4180, '2023001'

                Plan:ISDN, Type:Subscriber(local)

        Called Party Number i = 0xC1, '3023001'

                Plan:ISDN, Type:Subscriber(local)

Nov 23 12:26:23.594: ISDN Se0/2/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x809D

        Channel ID i = 0xA98383

                Exclusive, Channel 3

Nov 23 12:26:23.642: ISDN Se0/2/0:23 Q931: RX <- ALERTING pd = 8  callref = 0x809D

        Progress Ind i = 0x8188 - In-band info or appropriate now available

The same command should be applied on the terminating gateway in order to decode the Facility IE value as calling name and send the displayed text to the phone (in case of CME) or to CUCM. Else, Facility IE will be forwarded without decode (raw value) and the calling name won’t be displayed since Facility IE isn’t recognized by phone or CUCM (KEEP THIS IN MIND CAUSE WE WILL USE IT IN THE SECOND BLOG).

Notes:

1.       Calling Name (CNAM) as Facility IE and Display IE can be enabled simultenously.

2.       IEs can be enabled/disabled invidually under D-Channel configuration. E.g. “no isdn outgoing ie facility”, “no isdn outgoing ie calling-number”, “no isdn outgoing ie called-number”, etc. This can be used to hide calling number by disabling Calling Number IE. Still CLID feature can be used as well.

3.       Converting the hex value of Facility IE to ASCII, you can see the calling name.

Another hint is that CNAM can be sent as Facility IE without enabling CNAM as supplementary service. How??

IOS Gateways have the option to decode application protocol data units (APDUs) for supplementary services. If this command is not enabled, data units are not interpreted and are tunneled through the router.

voice service voip

qsig decode

Decoding those APDUs by the gateway locally enables it to use their contents. Since those APDUs are representing supplementary services, then those are Facility IEs.

Back to name display, once this feature is enabled on both gateways (mandatory on both gateways), IOS will encode all supplementary services on one side to Facility IE and decode them on the other side. Those supplementary services include CNAM and ALERTING name (display the name of called party on calling phone).

Very Important TIP: This is the only way to display the ALERTING NAME on calling phone. Note that ALERTING NAME is carried in the Facility IE of ALERTING message.

Nov 23 12:13:12.123: ISDN Se0/2/0:23 Q931: TX -> SETUP pd = 8  callref = 0x0095

        Bearer Capability i = 0x8090A2

                Standard = CCITT

                Transfer Capability = Speech 

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA98383

                Exclusive, Channel 3

        Facility i = 0x9FAA068001018201018B0100A10E02012D0201008006757365723031

                Protocol Profile =  Networking Extensions

                0x010182

                0x01018B

                0x0100

                0xA10E02012D0201008006757365723031

                Component = Invoke component

        Progress Ind i = 0x8183 - Origination address is non-ISDN 

        Calling Party Number i = 0x4180, '2023001'

                Plan:ISDN, Type:Subscriber(local)

        Called Party Number i = 0xC1, '3023001'

                Plan:ISDN, Type:Subscriber(local)

Nov 23 12:13:12.159: ISDN Se0/2/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x8095

        Channel ID i = 0xA98383

                Exclusive, Channel 3

Nov 23 12:13:12.219: ISDN Se0/2/0:23 Q931: RX <- ALERTING pd = 8  callref = 0x8095

        Facility i = 0x9FAA068001018201018B0100A10E02012A0201018006757365723032

                Protocol Profile =  Networking Extensions

                0x010182

                0x01018B

                0x0100

                0xA10E02012A0201018006757365723032

                Component = Invoke component, Unsupported operation 

        Progress Ind i = 0x8188 - In-band info or appropriate now available

Note: In case CNAM as supplementary service is enabled as well as ‘qsig decode’ feature, ‘qsig decode’ feature will take precedence.

Also note the difference between Facility IE for CNAM as supplementary service and CNAM using ‘qsig decode’ feature. For this reason ‘qsig decode’ should be enabled at both sides in order to decode the Facility IE.

At this stage ISDN part should be clear and we can start the second blog.

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