alert & cisco callmanager - micromedia international
TRANSCRIPT
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:
21/10/2013 ALERT & Cisco CallManager 2/36
21/10/2013 ALERT & Cisco CallManager 3/36
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
21/10/2013 ALERT & Cisco CallManager 4/36
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.
21/10/2013 ALERT & Cisco CallManager 5/36
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#
?
+-
7941 SERIESCISCO IP PHONE
1 2ABC
3DEF
4 5JKL
6MNOGHI
7 8TUV
9WXYZPQRS
*0
OPER#
?
+-
7941 SERIESCISCO IP PHONE
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#
?
+-
7941 SERIESCISCO IP PHONE
Cisco XML
PhoneALERT serverSupervision server
VOICE
TEXT
Proprietary link
21/10/2013 ALERT & Cisco CallManager 6/36
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
21/10/2013 ALERT & Cisco CallManager 7/36
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#
?
+-
7941 SERIESCISCO IP PHONE
Cisco XML
Phone
DataBase
21/10/2013 ALERT & Cisco CallManager 8/36
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
21/10/2013 ALERT & Cisco CallManager 9/36
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#
?
+-
7941 SERIESCISCO IP PHONE
Cisco phone
IP : 192.168.38.95
N°:1000
1 2ABC
3DEF
4 5JKL
6MNOGHI
7 8TUV
9WXYZPQRS
*0
OPER#
?
+-
7941 SERIESCISCO 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
21/10/2013 ALERT & Cisco CallManager 10/36
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".
21/10/2013 ALERT & Cisco CallManager 11/36
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).
21/10/2013 ALERT & Cisco CallManager 12/36
With those settings, ALERT is ready to send and receive SIP calls in a Cisco CallManager 4and 5
environment.
21/10/2013 ALERT & Cisco CallManager 13/36
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.
21/10/2013 ALERT & Cisco CallManager 14/36
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.
21/10/2013 ALERT & Cisco CallManager 15/36
There we see the controlled devices list. This user and his password are the ones we set in the ALERT SIP registration fields.
21/10/2013 ALERT & Cisco CallManager 16/36
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:
21/10/2013 ALERT & Cisco CallManager 17/36
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:
21/10/2013 ALERT & Cisco CallManager 18/36
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.
21/10/2013 ALERT & Cisco CallManager 19/36
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.
21/10/2013 ALERT & Cisco CallManager 20/36
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”:
21/10/2013 ALERT & Cisco CallManager 21/36
Now the trunk is ready !
21/10/2013 ALERT & Cisco CallManager 22/36
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.
21/10/2013 ALERT & Cisco CallManager 23/36
21/10/2013 ALERT & Cisco CallManager 24/36
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”.
21/10/2013 ALERT & Cisco CallManager 25/36
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.
21/10/2013 ALERT & Cisco CallManager 26/36
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”
21/10/2013 ALERT & Cisco CallManager 27/36
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).
21/10/2013 ALERT & Cisco CallManager 28/36
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.
21/10/2013 ALERT & Cisco CallManager 29/36
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.
21/10/2013 ALERT & Cisco CallManager 30/36
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.
21/10/2013 ALERT & Cisco CallManager 31/36
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.
21/10/2013 ALERT & Cisco CallManager 32/36
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.
21/10/2013 ALERT & Cisco CallManager 33/36
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.
21/10/2013 ALERT & Cisco CallManager 34/36
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
21/10/2013 ALERT & Cisco CallManager 35/36
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:
21/10/2013 ALERT & Cisco CallManager 36/36
You may have to restart the service for it to take effect but it should work.