ALERT & Cisco CallManager

Micromedia International Technical specification Author : Pierre Chevrier Pages : 28 Company : Micromedia International Date : 26/05/2011 Réf. : ETT_20090618_000001.docx ALERT & Cisco CallManager This document describes the interaction between Alert and the Cisco CallManager To A CC Company Attached documents: 26/05/2011 ALERT & Cisco CallManager 1/28

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

1 Contents 1... 1 1... 1 2 Introduction... 4 3 Features... 5 3.1 Alarm dispatching... 5 3.2 User interface... 5 4 System architecture... 6 4.1 Vocal case... 6 4.1.1 Limits and requirements... 6 4.1.2 Principle schema... 6 4.2 Text case... 7 4.2.1 Limits and requirements... 7 4.2.2 Principle schema... 7 5 System configuration... 9 5.1 Callmanager configuration... 10 5.1.1 For vocal calls... 10 5.1.2 For the text messages... 16 5.1.3 Cisco XML Phones as an ALERT user interface... 20 5.2 Alert configuration... 22 5.2.1 Driver settings... 22 5.2.2 User settings... 28 5.3 Network configuration... 28 26/05/2011 ALERT & Cisco CallManager 3/28

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

1 2 ABC 4 5 GHI JKL 7 8 PQRS TUV 0 OPER 3 DEF 6 MNO 9 WXYZ # CISCO IP PHONE 7941 SERIES -? 1 2 ABC 4 5 GHI JKL 7 8 PQRS TUV 0 OPER + 1 2 ABC 4 5 GHI JKL 7 8 PQRS TUV 3 DEF 6 MNO 9 WXYZ # 0 OPER 3 DEF 6 MNO 9 WXYZ # CISCO IP PHONE 7941 SERIES - CISCO IP PHONE 7941 SERIES? - +? + 1 2 ABC 4 5 GHI JKL 7 8 PQRS TUV 0 OPER 3 DEF 6 MNO 9 WXYZ # CISCO IP PHONE 7941 SERIES -? + 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) * VOICE * ALERT TEXT * 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. VOICE Proprietary link * Supervision server ALERT server TEXT Cisco XML Phone 26/05/2011 ALERT & Cisco CallManager 5/28

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. Cisco phone IP : 192.168.0.2 N :1010 Cisco phone IP : 192.168.0.3 N :1011 TCP/IP SKINNY Cisco CallManager IP : 192.168.0.10 SIP ALERT server IP : 192.168.0.1 N : 1001 26/05/2011 ALERT & Cisco CallManager 6/28

1 2 ABC 4 5 GHI JKL 7 8 PQRS TUV 0 OPER 3 DEF 6 MNO 9 WXYZ # CISCO IP PHONE 7941 SERIES -? + 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 HTTP connection (AXL or admin interface) Cisco CallManager ALERT DataBase HTTP WEB Server HTTP * Cisco XML Phone 26/05/2011 ALERT & Cisco CallManager 7/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 Put message in DB Request IP from Number Return IP IP vs Number HTTP Post Request messages Return XML messages Get messages Messages for number X Find messages Message status request Display Display and key result Result code Call result Message sent Message displayed? 26/05/2011 ALERT & Cisco CallManager 8/28

1 2 ABC 4 5 GHI JKL 7 8 PQRS TUV 0 OPER 3 DEF 6 MNO 9 WXYZ # CISCO IP PHONE 7941 SERIES -? + 1 2 ABC 4 5 GHI JKL 7 8 PQRS TUV 0 OPER 3 DEF 6 MNO 9 WXYZ # CISCO IP PHONE 7941 SERIES -? + 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. Cisco CallManager IP : 192.168.38.50 * Cisco phone IP : 192.168.38.95 N :1000 TCP/IP * Cisco phone IP : 192.168.38.3 N :1003 ALERT server IP : 192.168.38.111 N : 1002 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 26/05/2011 ALERT & Cisco CallManager 9/28

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". 26/05/2011 ALERT & Cisco CallManager 10/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. The pattern to create is the 1002 (ALERT phone number) which will use our trunk (SipAlert). 26/05/2011 ALERT & Cisco CallManager 11/28

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

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. This screenshot displays the CM6 phone configuration for our example. 26/05/2011 ALERT & Cisco CallManager 13/28

We can notice the owner user ID field which contains the controlling user. In the ALERT SIP driver we used sip:1002@192.168.38.50 as the sip URI. This corresponds to the previously defined phone device. The next one shows the user configuration. 26/05/2011 ALERT & Cisco CallManager 14/28

There we see the controlled devices list. This user and his password are the ones we set in the ALERT SIP registration fields. 26/05/2011 ALERT & Cisco CallManager 15/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. 26/05/2011 ALERT & Cisco CallManager 16/28

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

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

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: Select the menu Features/Cisco IP Phone Services then select the link Add a new IP phone service 26/05/2011 ALERT & Cisco CallManager 20/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). 26/05/2011 ALERT & Cisco CallManager 21/28

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. 26/05/2011 ALERT & Cisco CallManager 22/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. The phone number (1002) and the username and password are the ones defined in the Callmanager. 26/05/2011 ALERT & Cisco CallManager 23/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. 26/05/2011 ALERT & Cisco CallManager 24/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/05/2011 ALERT & Cisco CallManager 25/28

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