ALERT & Cisco CallManager

(1)

26/05/2011 ALERT & Cisco CallManager 1/28

Micromedia International

Technical

specification

Author : Pierre Chevrier

Company : Micromedia International

Date : 26/05/2011

Pages : 28

ALERT & Cisco CallManager

Réf. : ETT_20090618_000001.docx

This document describes the interaction between Alert and the Cisco CallManager

To A CC Company

(2)

(3)

1

2 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.

(5)

3 Features

Alert and the CallManager use the Cisco XML phones as alarms recipients or/and as Alert user interface.

3.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 ABC2 3DEF 4 5 JKL 6 MNO GHI 7 TUV8 WXYZ9 PQRS * 0 OPER # ? + -7941 SERIES CISCO IP PHONE 1 2 ABC 3 DEF 4 JKL5 MNO6 GHI 7 8 TUV 9 WXYZ PQRS * OPER0 # ? + -7941 SERIES CISCO IP PHONE 1 ABC2 DEF3 4 JKL5 MNO6 GHI 7 8 TUV 9 WXYZ PQRS * OPER0 # ? + -7941 SERIES CISCO IP PHONE ALERT TEXT VOICE

3.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 ABC2 DEF3 4 JKL5 MNO6 GHI 7 TUV8 WXYZ9 PQRS *OPER0 # ? + -7941 SERIES CISCO IP PHONE Cisco XML Phone ALERT server Supervision server VOICE TEXT Proprietary link

(6)

4 System architecture

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

4.1 Vocal case

4.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.

4.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)

4.1.1.2 Phones requirements:

- Working with the CallManager - DTMF enabled

4.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.

4.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

(7)

26/05/2011 ALERT & Cisco CallManager 7/28 Communications between the CallManager and the Cisco Phones use the Skinny protocol. The CallManager is a SIP proxy for ALERT.

4.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.

4.2.1 Limits and requirements

4.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

4.2.1.2 Phones requirements:

- XML compliant phones - DTMF enabled

4.2.1.3 ALERT Requirements:

- CiscoXML driver activated. - IIS working on the same machine.

4.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 2ABC3DEF 4 5JKL6MNO GHI 7 8TUVWXYZ9 PQRS *OPER0 # ? + -7941 SERIES CISCO IP PHONE Cisco XML Phone DataBase

(8)

26/05/2011 ALERT & Cisco CallManager 8/28 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 CiscoPhone Web server Database

Call number X

Request IP from Number

IP vs Number Return IP Put message in DB HTTP Post Request messages Get messages Find messages Messages for number X

Return XML messages

Display

Display and key result

Message status request

Message displayed ? Message sent

Result code

(9)

5 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/IP 1 2ABCDEF3 4 5JKL MNO6 GHI 7 8TUVWXYZ9 PQRS * OPER0 # ? + -7941 SERIES CISCO IP PHONE Cisco phone IP : 192.168.38.95 N°:1000 1 ABC2 DEF3 4 JKL5 MNO6 GHI 7 TUV8 WXYZ9 PQRS * OPER0 # ? + -7941 SERIES CISCO IP PHONE 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

(10)

5.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.

5.1.1 For vocal calls

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

5.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".

(11)

26/05/2011 ALERT & Cisco CallManager 11/28 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.

(12)

26/05/2011 ALERT & Cisco CallManager 12/28 With those settings, ALERT is ready to send and receive SIP calls in a Cisco CallManager 4and 5

(13)

5.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, 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.

(14)

26/05/2011 ALERT & Cisco CallManager 14/28 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.

(15)

26/05/2011 ALERT & Cisco CallManager 15/28 There we see the controlled devices list.

(16)

26/05/2011 ALERT & Cisco CallManager 16/28 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.

5.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.

(17)

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.

(18)

26/05/2011 ALERT & Cisco CallManager 18/28 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”.

(19)

26/05/2011 ALERT & Cisco CallManager 19/28 With those settings, the next screenshot shows a message sent by Alert on a Cisco IP Soft Phone.

(20)

5.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:

(21)

26/05/2011 ALERT & Cisco CallManager 21/28 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).

(22)

5.2 Alert configuration

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

5.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!

5.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.

(23)

26/05/2011 ALERT & Cisco CallManager 23/28 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.

(24)

26/05/2011 ALERT & Cisco CallManager 24/28 The next screenshot shows the same driver settings for a CallManager 4 or 5.

5.2.1.2 CiscoXML driver

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

(25)

26/05/2011 ALERT & Cisco CallManager 25/28 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.

(26)

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.

(27)

26/05/2011 ALERT & Cisco CallManager 27/28 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.

(28)

5.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).

5.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

ALERT & Cisco CallManager

Micromedia International

Technical

specification

Author : Pierre Chevrier

Company : Micromedia International

Date : 26/05/2011

Pages : 28

ALERT & Cisco CallManager

1

Contents

2

Introduction

3

Features

3.1

Alarm dispatching

3.2

User interface

4

System architecture

4.1

Vocal case

4.2

Text case

5

System configuration

5.1

Callmanager configuration

5.2

Alert configuration

5.3

Network configuration