alert & cisco callmanager - micromedia international

21/10/2013 ALERT & Cisco CallManager 1/36

Micromedia International Technical

specification

Author : Pierre Chevrier

Company : Micromedia International

Date : 21/10/2013

Pages : 36

ALERT & Cisco CallManager

Réf. : ETT_20090618_000001.docx

This document describes the interaction between Alert and the Cisco CallManager

To A CC Company

Attached documents:


Content 1 Introduction .................................................................................................................................... 4

2 Features .......................................................................................................................................... 5

2.1 Alarm dispatching .................................................................................................................... 5

2.2 User interface .......................................................................................................................... 5

3 System architecture ........................................................................................................................ 6

3.1 Vocal case ................................................................................................................................ 6

3.1.1 Limits and requirements ................................................................................................. 6

3.1.2 Principle schema .............................................................................................................. 6

3.2 Text case .................................................................................................................................. 7

3.2.1 Limits and requirements ................................................................................................. 7

3.2.2 Principle schema .............................................................................................................. 7

4 System configuration ...................................................................................................................... 9

4.1 Callmanager configuration .................................................................................................... 10

4.1.1 For vocal calls ................................................................................................................ 10

4.1.2 For the text messages.................................................................................................... 22

4.1.3 Cisco XML Phones as an ALERT user interface .............................................................. 26

4.2 Alert configuration ................................................................................................................ 28

4.2.1 Driver settings ............................................................................................................... 28

4.2.2 User settings .................................................................................................................. 34

4.3 Network configuration .......................................................................................................... 34

4.4 IIS configuration .................................................................................................................... 35


1 Introduction

Under Cisco CallManager environment, Alert can use the Cisco phones for alarm dispatching via two

media:

- Voice messages

- Text messages

The interaction between Alert and the Cisco phones can be stronger. As a matter of fact, each phone

can be used as a user interface for Alert. The Alert vocal server is the voice interface. The

CallManager XML services offer a new remote interface for Alert. A Cisco phone can interact with

Alert like AlertWeb or AlertMobile.


2 Features Alert and the CallManager use the Cisco XML phones as alarms recipients or/and as Alert user

interface.

2.1 Alarm dispatching The Cisco CallManager is a full IP system. All data exchanges are TCP/IP communications. So, vocal

messages are sent with the voice over IP driver (SIP protocol). To send text messages on Cisco

phones, a specific driver has been developed: CiscoXML driver. (Using Cisco XML services)

1 2ABC

3DEF

4 5JKL

6MNOGHI

7 8TUV

9WXYZPQRS

*0

OPER#

?

+-

7941 SERIESCISCO IP PHONE

1 2ABC

3DEF

4 5JKL

6MNOGHI

7 8TUV

9WXYZPQRS

*0

OPER#

?

+-


1 2ABC

3DEF

4 5JKL

6MNOGHI

7 8TUV

9WXYZPQRS

*0

OPER#

?

+-


ALERT

TEXT

VOICE

2.2 User interface Alert is registered with the CallManager as an XML Service. The phone can then interact with Alert

and with the supervision. A Cisco XML phone offers two interfaces: a text interface (XML) and a vocal

interface.

1 2ABC

3DEF

4 5JKL

6MNOGHI

7 8TUV

9WXYZPQRS

*0

OPER#

?

+-


Cisco XML

PhoneALERT serverSupervision server

VOICE

TEXT

Proprietary link


3 System architecture We need to explain two architectures: for vocal connections or for text connections.

3.1 Vocal case

3.1.1 Limits and requirements

The Cisco CallManager uses a proprietary protocol for vocal communications: SCCP (or Skinny).

ALERT can only communicate through SIP protocol in VoIP environments.

3.1.1.1 CallManager requirements:

- SIP proxy activated

- Accept DTMF on SIP (need a Media Termination Point)

- A sip extension created (to receive calls in ALERT)

3.1.1.2 Phones requirements:

- Working with the CallManager

- DTMF enabled

3.1.1.3 ALERT Requirements:

- SIP driver activated and licensed

- VoIP users created with address as phone numbers or with sip URIs as phone numbers.

3.1.2 Principle schema

The following picture shows the interconnection between ALERT and a Cisco CallManager.

ALERT server

IP : 192.168.0.1

N°: 1001

Cisco phone

IP : 192.168.0.2

N°:1010

Cisco phone

IP : 192.168.0.3

N°:1011

Cisco CallManager

IP : 192.168.0.10

TCP/IP

SKINNY

SIP


Communications between the CallManager and the Cisco Phones use the Skinny protocol. The

CallManager is a SIP proxy for ALERT.

3.2 Text case To send text messages, ALERT uses the CallManager XML Services. Each compatible phone acts as an

XML browser. All the displayed information comes from an HTTP server.

3.2.1 Limits and requirements

3.2.1.1 CallManager requirements:

- A new service created for ALERT, and authorized for the phones to call

- Admin access authorized for ALERT (CM 4) or an AXL authorized user (CM 5 or more)

- A user access on all the XML compliant phones

3.2.1.2 Phones requirements:

- XML compliant phones

- DTMF enabled

3.2.1.3 ALERT Requirements:

- CiscoXML driver activated.

- IIS working on the same machine.

3.2.2 Principle schema

The following picture shows all the involved components for text message sending.

ALERT SERVER

WEB Server

ALERT

HTTP connection

(AXL or admin interface)

HTTP

Cisco CallManager

HTTP

1 2ABC

3DEF

4 5JKL

6MNOGHI

7 8TUV

9WXYZPQRS

*0

OPER#

?

+-


Cisco XML

Phone

DataBase


Let us describe the interactions between all those elements:

1) ALERT requests for sending a message to a specific phone extension. The driver stores the

message in the database.

2) ALERT needs the CallManager to get the IP address corresponding to the phone extensions.

3) ALERT sends an HTTP Post on the phone with the web server address.

4) The Cisco phone is an XML browser. It asks the IIS web server for the message.

5) The data is extracted from ALERT or from the database and formatted by the web application

and displayed on the phone.

The next diagram illustrates this sequence of a call.

Alert CiscoXMLDriver CallManager DatabaseCiscoPhone Web server

Call number X

Request IP from Number

IP vs NumberReturn IP

Put message in DB

HTTP Post

Request messages

Get messages

Find messagesMessages for number X

Return XML messages

Display

Display and key result

Message status request

Message displayed ?Message sent

Result code

Call result


4 System configuration This part will illustrate the whole system configuration (Alert, CallManager, Web server …) with an

example. In this example, we are using a CallManager version 6, Alert 3.6 Rev 1 Build 4, IIS7 running

on Windows Vista, Cisco IP phones.

ALERT server

IP : 192.168.38.111

N°: 1002

Cisco CallManager

IP : 192.168.38.50

TCP/IP1 2

ABC3

DEF

4 5JKL

6MNOGHI

7 8TUV

9WXYZPQRS

*0

OPER#

?

+-


Cisco phone

IP : 192.168.38.95

N°:1000

1 2ABC

3DEF

4 5JKL

6MNOGHI

7 8TUV

9WXYZPQRS

*0

OPER#

?

+-


Cisco phone

IP : 192.168.38.3

N°:1003

The following configuration description will use those IP addresses and phone numbers.

During the ALERT installation, the database and the web server are automatically configured on the

server 192.168.38.111. The CiscoXML driver and the VoIP driver have been installed (if selected

during installation).

The next step is to configure all the involved parties:

- Cisco CallManager

- Alert and its drivers

- Firewalls


4.1 CallManager configuration This configuration needs to be done by a user familiar with the CallManager.

To work with the CallManager, ALERT needs the following options.

4.1.1 For vocal calls

The settings are different on CM and CM5 than CM6 and more. Let’s describe them both.

4.1.1.1 CallManager 4 and 5

A SIP trunk is needed for those versions.

Since a SIP trunk requires MTP (Media Termination Point), make sure you have one: “Service -> Media Resource -> Media Termination Point” Normally your CallManager server should appear there if you do an empty query. If not, go to the CallManager Serviceabilty web page, and activate the Cisco IP Voice Media Streaming App service For the trunk Creation, select the menu:

Select the "Add a New Trunk" link from the upper right hand corner of the "Find and List Trunks"

page.

Select "SIP Trunk" as the "Trunk type" and "SIP" as the "Device Protocol". Click on the "Next" button.

Enter a name in the "Device Name". Valid characters are letters, numbers, dashes, dots (periods),

and underscores. The device name is only used internally in Call Manager so it can be anything you

want.

Enter the IP address of your ALERT server in the "Destination Address" field.

Select "UDP" as the "Outgoing Transport Type".


Modify any other settings as needed. The next screenshot is the trunk configuration of our example.

Click on the "Insert" button.

Then the calls from ALERT to the Cisco phone can be placed.

The other way (Cisco phone -> ALERT) needs a few more settings: Add route patterns in CallManager

that send calls to ALERT using the SIP trunk that you just created.

The pattern to create is the 1002 (ALERT phone number) which will use our trunk (SipAlert).


With those settings, ALERT is ready to send and receive SIP calls in a Cisco CallManager 4and 5

environment.


4.1.1.2 CallManager 6 and more

To use Alert, DTMF reception is needed. To do this, check that a MTP (Media Termination Point), is active. “Media Resource -> Media Termination Point” Normally you should see a registered MTP if you do an empty query. If not, go to the CallManager Serviceabilty web page, and activate the Cisco IP Voice Media Streaming App service. Then the MTP should then be registered. For those versions, Alert acts either as a SIP trunk or as a User Agent (UA).

4.1.1.2.1 Alert as a User Agent

In that case, a SIP user is needed. A specific phone number must be defined if we want to call ALERT. (The 1002 in our example). In the example, we have created a SIP phone with extension 1002 and a user (whose name is alert)

for SIP registration and to control this phone.

This screenshot displays the CM6 phone configuration for our example.


We can notice the “owner user ID” field which contains the controlling user. In the ALERT SIP driver

we used sip:[email protected] as the sip URI. This corresponds to the previously defined phone

device.

The next one shows the user configuration.

sip:[email protected]


There we see the controlled devices list. This user and his password are the ones we set in the ALERT SIP registration fields.


The others phones are defined in the CallManager device configuration:

We see the SIP phone with extension 1002, registered on the IP 192.168.38.111. The extension 1000

with the Skinny protocol (SCCP) registered on the 192.168.38.95. And the extension 1003, not yet

registered.

Don’t forget to activate the DTMF for all users. Depending on the phone device, the “Require DTMF

reception” option may be checked.

4.1.1.2.2 Alert as a SIP Trunk

The configuration is the same as in CCM 4 or 5.

First we need to create a trunk. Select the following menu:

Then select “Add New”. The next screen will be displayed:


Then, fill the name field. (Optionally, give a description).

Check the “Media termination point” and “Retry video calls as audio” options.

Leave the default values for the next fields:


Then enter the IP address of your ALERT server in the "Destination Address" field.

Now we need to configure the trunk security profile. To do this, click on the “Sip Trunk Security

Profile” link: at right.


This new window is now opened:

Chose the following options:

"Device Security Mode" -> NON_SECURE

"Outgoing transport Type" -> "USER_DATAGRAM_PROTOCOL"

The trunk is now correctly configured. The outgoing calls can be placed. We need now to define a “Route pattern”

for the trunk incoming calls.


The route pattern can be a fixed number (for ex. 3212) or a range(32XX).Then we must tell the CCM

to route this number to the previously defined SIP trunk.

Set the “Gateway/Route List”:


Now the trunk is ready !


4.1.2 For the text messages

The configuration in the CallManager is to define user access rights. Two accesses are needed:

- Access to the phone numbers / IP address map. (If the “Dynamic extension/IP map“ option is

selected in ALERT)

- Access the XML phones web server (for http push)

The extension/IP map access

It is done on reading the /CCMAdmin/Reports/Devicelistx.asp web file on CM 4. This page needs

Admin privileges. This access cannot be done more than once per minute.

To have a correct mapping, the device description should be NN – XX. Where NN is the phone

number and XX a string description.

On the CM 5 and more, the map is created thanks to AXL (XML administration). An AXL user is

mandatory to create this map.

If those requirements are incompatible with the security policy, the mapping can be done manually

in the ALERT driver database, or at least, the static IP address can be used as ALERT user addresses.

Phones access

This user is mandatory to send the HTTP post on the phone. This user should control the recipient

phones. See the httpPush user of our case.

Create the user and associate him with the phones which will receive the messages.

Screenshot on CM4 interface.


Screenshot on CM6 interface.

This user controls the two XML phones of our configuration (extension 1000 and 1003).

Phone access checking

Follow those instructions to check that Alert can access the phone to send the messages.

- From the Alert computer, check that a ping on the phone IP address is successful. - To check the HTTP connection and phone user access, connect a web browser on

http://phoneip/CGI/CCMUser and connect with the previously defined user (httpPush in our example).

The displayed data should be an XML string <CiscoIPPhoneError Number=”0”/> If all is successful, the connection from Alert to the phone is working. Web server access checking To display messages, the Cisco phone must connect to the web server on the Alert computer. To check, this configure a Cisco XML service in the CallManager and connect the phone to this service. See “Cisco XML Phones as an ALERT user interface”.


With those settings, the next screenshot shows a message sent by Alert on a Cisco IP Soft Phone.

The two dynamic soft keys offer the call acknowledgement and the call rejection functionalities.


4.1.3 Cisco XML Phones as an ALERT user interface

The IP service is not necessary for text messages. But it will be used in the next Alert version and it

will offer an ALERT interface on the Cisco XML compliant phones.

To configure this service, see following example.

On a CM4:

Select the menu “Features/Cisco IP Phone Services” then select the link “Add a new IP phone service”


On a CM6:

Notice the web server IP address in the service URL field.

When the service is registered in the Callmanager, it is available from the Cisco XML Phone by

pressing the Service key if the phone has subscribed to the service. (In the phone settings select

“Suscribe/Unsuscribe”)

Actually the service only displays the ALERT logo as shown on next picture. This screenshot comes

from a Cisco IP Communicator (Soft XML Cisco phone).


4.2 Alert configuration The configuration is done at the driver level and at the user level.

4.2.1 Driver settings

In this example, the Sip driver and the CiscoXML driver are configured. But only the requested drivers

need to be configured!

4.2.1.1 Sip driver

The configuration of this driver depends on the CallManager configuration. For the CM4 and CM5,

the sip driver does not register on the Callmanager. The SIP connection will use a SIP trunk in the

CallManager.


From the CM6, the registration is mandatory: Alert acts as a SIP phone and does not use a trunk in

the CallManager.

This screenshot shows the ALERT SIP settings with a Callmanager 6 or more.

The phone number (1002) and the username and password are the ones defined in the Callmanager.


The next screenshot shows the same driver settings for a CallManager 4 or 5.

4.2.1.2 CiscoXML driver

The configuration of this driver is more complex. The three following pictures show the three

configuration screens.


This first screen displays the basic configuration. On a Cisco phone, the user can use dynamic keys.

We need to specify here the behaviour of those soft keys.

In the “SoftKeys” group, we can set the displayed label of the dynamic keys and associate the ALERT

functiunality (Call acknowledgement, Call rejection, Alarm acknowledgement, next message, …) with

a dynamic key.

The second screen displays the connection settings.

The UDL file is used to connect to the database where messages are stored by ALERT and read by the

web server. This database is polled by ALERT for the calls and alarms acknowledgements at a defined

period.

The Callmanager group contains the options for the IP address requests. In the user settings (see

next paragraph), the user can define the Phone IP address or the phone number. In case of phone

numbers, ALERT needs to find the IP address corresponding to the number.

The database can contain the IP address / phone number mapping. But the best practice is to request

the Callmanager for this map which can then be dynamic (DHCP address).

To connect to the Callmanager for the IP address request, we need a user login and password. For

CM5 and higher, the user is an AXL user (XML administration). For the CM4, the user needs to be an

admin user.


The IP service group displays the Cisco IP Service parameters. The web server address is sent (via

HTTP post) to the phone during the call. The user name and password define a user which can make

HTTP posts on the Cisco XML phones.

The third screen shows the advanced settings. Those settings are stored in the database and are

shared between ALERT and the web server.


Those values are used to fill the message database and will be read by the web server to display the

message to the phone.

The value stored in message table is the result of the pressed softkey (corresponding value). When

generated by ALERT, the result value is initialized at zero.

In the example: 1 is the result when message is displayed 2 is the result when the user pressed the “next” button ... The display filter is the threshold of displayed messages. All messages with result values more than

the threshold won’t be displayed.


4.2.2 User settings

The next screenshot shows a user with two media: a SIP media for voice calls and the CiscoXML

driver for text messages on Cisco XML complaints phones.

In that case (the simplest), the phone number is used for SIP and for Cisco XML. In the SIP address we

could set either the phone number or the complete uri sip:[email protected]. For the CiscoXML

we could set either the phone number or the IP address 192.168.38.95 (only if it is not a DHCP

address).

4.3 Network configuration Find the list of the used IP ports:

- Alert to CM in SIP: 5060 UDP

- CM to Alert in SIP: 5060 UDP

- Audio stream in RTP, Alert to CM: random port from 16384 to 32767 UDP

- Audio stream in RTP, CM to Alert: port from 16384 to 32767 UDP

- XML message Alert to Phones: 80 TCP

- XML message phones to IIS: 80 TCP

sip:[email protected]


4.4 IIS configuration On 64bit platforms, the ISS must accept the 32bits applications.

For Windows 2008: Navigate to Server Manager > Roles > Web Server (IIS) > Internet Information

Services (IIS) Manager, then look under your machine name > Application Pool.

For Windows 7: Navigate to Programs > Administrative Tools > Internet Information Services (IIS)

Manager, then look under your machine name > Application Pool.

Under there you can call the DefaultAppPool’s advanced settings to change Enable 32-Bits

Applications to True:


You may have to restart the service for it to take effect but it should work.

alert & cisco callmanager - micromedia international

Documents