CH A P T E R
2
Cisco IPICS Component Considerations
This chapter provides information about various components and features that can be part of a
Cisco IPICS solution. This information will help you to understand how these items interoperate in a
Cisco IPICS deployment.
This chapter includes these topics:
•
Router Media Service, page 2-1
•
Integrating Cisco IPICS with SIP Providers, page 2-29
•
IDC Dialer Configuration and Integration with Unified Communications Platform, page 2-35
•
Cisco IPICS Mobile Client for Apple iPhone, page 2-38
•
Cisco Unified IP Phones, page 2-47
•
Text to Speech, page 2-48
•
Video Considerations, page 2-53
•
Notification, page 2-55
Router Media Service
The Cisco IPICS solution uses one or more of the supported Cisco IOS routers to provide the router
media service (RMS) functionality.
The following sections provide additional information about the RMS:
•
RMS Overview, page 2-2
•
RMS Components for Locations, page 2-2
•
When is an RMS Required?, page 2-7
•
Allocation of RMS DS0 Resources, page 2-9
•
Media Resource Allocation for the Dial Engine, page 2-10
•
Virtual Talk Groups, page 2-11
•
Remote IDC Users, page 2-24
For detailed information about configuring an RMS for Cisco IPICS, refer to the “Configuring the
Cisco IPICS RMS Component” appendix in Cisco IPICS Server Administration Guide, Release 4.02.
For a list of Cisco IOS releases that Cisco IPICS supports for use as an RMS, refer to Cisco IPICS
Compatibility Matrix. Each supported Cisco IOS release includes the Cisco Hoot ‘n’ Holler feature.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-1
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
RMS Overview
The primary role of the RMS is to provide media stream mixing by looping back DS0 resources. When
an RMS is installed, it must have one or more pairs of T1 or E1 interfaces that are connected back to
back with a T1 loopback cable. These loopback interface pairs are manually configured in the RMS by
adding the DS0-Group to timeslot mapping. (For related information, refer to the “Configuring the
Cisco IPICS RMS Component” appendix in Cisco IPICS Server Administration Guide, Release 4.0(2).)
When you use the Cisco IPICS Administration Console to add an RMS, the loopback pairs becomes
available for assignment. A properly configured RMS will make a list of DS0 loopback channels
available for dynamic allocation by the Cisco IPICS server.
The RMS can be installed as a stand-alone component (RMS router) or as an additional feature that is
installed in the LMR gateway.
The Cisco IPICS server dynamically allocates a DS0 loopback pair (two DS0 channels) in the following
scenarios:
•
Successful Authentication of an IPICS Dispatch Console (IDC) from the remote location—When a
remote IDC connection is started, the IDC authenticates to the Cisco IPICS server. The Cisco IPICS
server then configures the RMS to allocate a DS0 loopback pair for each channel or virtual talk
group (VTG) that is assigned to the IDC user. The IDC retrieves configuration information that
contains the IP address of the RMS and the channel details with the Plain Old Telephone Service
(POTS) dial-peer information that the Cisco IPICS server configured in the RMS. Then, when the
IDC user activates a channel or VTG, the IDC places a SIP call to the POTS dial-peer in the RMS
and connects to that channel or VTG.
•
Activation or change of a VTG—When a Cisco IPICS dispatcher performs VTG operations that
affects an RMS, the Cisco IPICS server updates the RMS as needed. For example, if a VTG with
two channels is activated, the Cisco IPICS server configures two DS0 loopback pairs, one for each
channel. This configuration will include assigning each side of corresponding voice-port for the
allocated DS0 loopback pair to a connection trunk.
•
A dial-in user joins a channel or VTG—A single DS0 loopback pair is added per channel or VTG
regardless of the number of dial-in users who join the channel or VTG.
•
A mobile client user log in to the Cisco IPICS server—A single DS0 loopback pair is used for each
incident.
RMS Components for Locations
An RMS supports one Cisco IPICS location, which is defined as a multicast domain. If a Cisco IPICS
deployment requires RMS functionality in more than one location, there must be an RMS configured for
each of those locations. The multicast address pool contains a list of multicast addresses and their
respective port assignments. The addresses in the pool are allocated, as needed, by the Cisco IPICS
server when it configures an RMS. The Cisco IPICS server keeps track of the in-use and the available
addresses.
The multicast address pool is a global resource that is shared across all RMS components that are
configured in that Cisco IPICS server. Therefore the network configuration must be able to support all
of the configured addresses in all of the configured RMS components. The IPICS server attempts to load
balance across all RMS components that are in the same location. For this reason, it is important that
you configure each RMS according to the instructions that are documented in the “Configuring the
Cisco IPICS RMS Component” appendix in Cisco IPICS Server Administration Guide, Release 4.0(2)
if you have more than one RMS configured in the server.
The following information applies to locations:
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-2
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
•
A channel is associated to a location.
•
A VTG is a global resource that can span multiple locations.
•
A user may be assigned channels from multiple locations, but when the user authenticates, the user
must select the desired location. Channel resources are allocated based on the selected location.
Multiple Location Example
As an example of how Cisco IPICS and RMS components function in multiple locations, consider the
following scenario:
•
User A is in the Site 1 location and is assigned the Emergency VTG
•
User B is in the Site 2 location and is assigned the Emergency VTG
•
Channel EMT1 is in the Site 1 location
•
Channel EMT2 is in the Site 2 location
•
The Emergency VTG is assigned both channel EMT1 and channel EMT2
•
RMS 1 is in the Site 1 location
•
RMS 2 is in the Site 2 location
When the Cisco IPICS dispatcher activates the Emergency VTG, the Cisco IPICS server assigns to the
VTG a multicast address from the multicast address pool. It also configures DS0 loopback resources in
RMS 1 and RMS 2.
In this way, users in both locations can communicate by using the VTG. Be aware that this scenario
requires that there must be multicast connectivity between both locations. If both locations are isolated
multicast domains, there must be a way to route the multicast traffic between locations. For related
information, see the “Multiple Site Model” section on page 7-2.
RMS Configuration Example
The following example shows what the Cisco IPICS server configures in the RMS when a VTG that
contains two channels is activated. This example allows the RMS to receive voice on the Police channel
and to transmit it to the VTG multicast address, and to receive voice on the VTG multicast address and
to transmit it to the Police channel. In this example,
•
The VTG is named Combined and its multicast IP address is 239.192.21.79:21000. (This address is
dynamically allocated for the VTG from the address range that is configured in the multicast pool.)
•
The IP address for the Police channel is 239.192.21.64:21000.
•
The IP address for the Fire channel is 239.192.21.65:21000.
•
One side of the DS0 loopback, 0/2/0:3, is assigned a connection trunk (90929093) that maps to a
VoIP dial peer destination pattern. This dial peer has a session target of 239.192.21.79:21000 (the
VTG multicast address).
•
The other side of the DS0 loopback, 0/2/1:3, is assigned a connection trunk (90929193) that maps
to a VoIP dial peer destination pattern. This dial peer has a session target of 239.192.21.64:21000
(the Police channel multicast address).
The following Cisco IOS configuration output shows the RMS configuration in the Cisco IPICS server
to support adding the Police channel to the Combined VTG:
dial-peer voice 90929093 voip
description #0/2/0:3#1164200525742# INUSE 284
destination-pattern 90929093
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-3
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
voice-class permanent 1
session protocol multicast
session target ipv4:239.192.21.79:21000
codec g711ulaw
no vad
voice-port 0/2/0:3
voice-class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timeouts teardown lmr infinity
timing hookflash-in 0
timing hangover 80
connection trunk 90929093
description #0/2/0:3#1164200525742# INUSE 284
voice-port 0/2/1:3
voice-class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timeouts teardown lmr infinity
timing hookflash-in 0
timing hangover 80
connection trunk 90929193
description #0/2/1:3#1164200525742# INUSE 284
dial-peer voice 90929193 voip
description #0/2/1:3#1164200525742# INUSE 284
destination-pattern 90929193
voice-class permanent 1
session protocol multicast
session target ipv4:239.192.21.64:21000
codec g711ulaw
The following Cisco IOS configuration output shows the RMS configuration in the Cisco IPICS server
to support adding the Fire channel to the Combined VTG:
dial-peer voice 90929094 voip
description #0/2/0:4#1164200525776# INUSE 285
destination-pattern 90929094
voice-class permanent 1
session protocol multicast
session target ipv4:239.192.21.79:21000
codec g711ulaw
no vad
voice-port 0/2/0:4
voice-class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-4
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
timeouts call-disconnect 3
timeouts teardown lmr infinity
timing hookflash-in 0
timing hangover 80
connection trunk 90929094
description #0/2/0:4#1164200525776# INUSE 285
voice-port 0/2/1:4
voice-class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timeouts teardown lmr infinity
timing hookflash-in 0
timing hangover 80
connection trunk 90929194
description #0/2/1:4#1164200525776# INUSE 285
dial-peer voice 90929194 voip
description #0/2/1:4#1164200525776# INUSE 285
destination-pattern 90929194
voice-class permanent 1
session protocol multicast
session target ipv4:239.192.21.65:21000
codec g711ulaw
no vad
The following Cisco IOS configuration outputs shows the RMS configuration in the Cisco IPICS server
to support an IDC user who is assigned both the Police and Fire channels connecting by using the remote
location. This configuration allows the IDC to communicate with RMS by using a unicast connection.
The RMS forwards the unicast stream, which is received from the IDC, through a DS0 loopback to the
multicast address. Packets that the RMS receives for a multicast address are forwarded through a DS0
loopback to the receiving IDC device as a unicast stream.
This Cisco IOS configuration output pertains to the Police channel:
dial-peer voice 909290914 voip
description #0/2/0:14#1164659525783# INUSE 295
destination-pattern 909290914
voice-class permanent 1
session protocol multicast
session target ipv4:239.192.21.64:21000
codec g711ulaw
no vad
voice-port 0/2/0:14
voice-class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timeouts teardown lmr infinity
timing hookflash-in 0
timing hangover 80
connection trunk 909290914
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-5
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
voice-port 0/2/1:14
voice-class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timeouts teardown lmr infinity
timing hookflash-in 0
timing hangover 80
description #0/2/1:14#1164659525783# INUSE 295
dial-peer voice 909291914 pots
description #0/2/1:14#1164659525783# INUSE 295
destination-pattern 1990000275909291914
port 0/2/1:14
This Cisco IOS configuration output pertains to the Fire channel:
dial-peer voice 909290915 voip
description #0/2/0:15#1164659525833# INUSE 296
destination-pattern 909290915
voice-class permanent 1
session protocol multicast
session target ipv4:239.192.21.65:21000
codec g711ulaw
no vad
voice-port 0/2/0:15
voice-class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timeouts teardown lmr infinity
timing hookflash-in 0
timing hangover 80
connection trunk 909290915
description #0/2/0:15#1164659525833# INUSE 296
voice-port 0/2/1:15
voice-class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timeouts teardown lmr infinity
timing hookflash-in 0
timing hangover 80
description #0/2/1:15#1164659525833# INUSE 296
dial-peer voice 909291915 pots
description #0/2/1:15#1164659525833# INUSE 296
destination-pattern 1990000275909291915
port 0/2/1:15
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-6
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
When is an RMS Required?
Cisco IPICS requires an RMS to establish connectivity between unicast and multicast endpoints (such
as remote IDC to channel, mobile client to Cisco IPICS server, remote IDC to VTG, and dial-in user to
channel or VTG), and to establish connectivity between multicast endpoints that are on different
channels (such as channel to VTG, and VTG to VTG).
However, there are some communication scenarios that do not require RMS DS0 resources. For example,
two multicast users can communicate on a single Cisco IPICS channel without consuming RMS DS0
resources, as illustrated in Figure 2-1. This examples shows that, after the users log in to the Cisco IPICS
server, they receive their channel information, Metro Police using the multicast group 239.192.21.64. If
the users activate the Metro Police channel, they will be able to communicate without using RMS DS0
resources.
Figure 2-1
Single Cisco IPICS Channel
R1
R2
IP MulticastEnabled Network
IDC User: User A
Channel: Metro Police
239.192.21.64
Cisco IPICS
Server
User: PIT User B
Channel: Metro Police
239.192.21.64
237530
IP
Adding an LMR gateway and an LMR user to this scenario does not necessarily require RMS DS0
resources. If the LMR user is statically configured to use the same channel as the other users, all users
can communicate without consuming RMS DS0 resources, as shown in Figure 2-2.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-7
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Figure 2-2
Single Cisco IPICS Channel with LMR Gateway
R3
LMR 1
E&M
239.192.21.64
Metro Police
R1
R2
IP MulticastEnabled Network
IP
User: PIT User B
Channel: Metro Police
239.192.21.64
Cisco IPICS
Server
237531
IDC User: User A
Channel: Metro Police
239.192.21.64
As another example, a scenario with two sets of users on two separate channels does not consume RMS
DS0 resources if communication between the channels is not required. In the scenario shown in
Figure 2-3, Metro Police users can communicate with each other, and Metro Fire users can communicate
with each other, without consuming RMS DS0 resources. In this scenario, no RMS resources are
required because there is no communication between Metro Police and Metro Fire users.
Figure 2-3
Several Cisco IPICS Channels
R3
LMR 1
E&M
239.192.21.64
Metro Police
R1
LMR 2
E&M
239.192.21.65
Metro Fire
IP
User: PIT User D
Channel: Metro Fire
239.192.21.64
R2
IP MulticastEnabled Network
IDC User: User C
Channel: Metro Fire
239.192.21.65
IP
Group 1 Metro Police
Channel 239.192.21.64
IDC 1, IDC 2, LMR/Hootie 1
User: PIT User B
Channel: Metro Police
239.192.21.64
Group 2 Metro Fire
Channel 239.192.21.65
IDC 3, IDC 4, LMR/Hootie 2
237532
IDC User: User A
Channel: Metro Police
239.192.21.64
Cisco IPICS
Server
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-8
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Allocation of RMS DS0 Resources
You can create a VTG that allows only specific users to communicate by using that VTG. In this case,
the VTG does not include channels and it does not use RMS DS0 resources (unless there are IDC users
who connect by using the Remote location), but it does use a multicast address from the multicast pool.
If a VTG needs to include LMR endpoints, each of the LMR channels must be added to the VTG, in
addition to the channels for the IDC or phone users. If a user is not added to the VTG but has a channel
that is in the VTG, the user will still be able to send to and receive from the VTG.
After an IDC successfully authenticates by using the Remote location, the RMS allocates a DS0 pair to
each channel or VTG that is assigned to that authenticated IDC user. (See the “Remote IDC Users”
section on page 2-24 for related information.)
Table 2-1 illustrates the various scenarios in which RMS resources are allocated
Table 2-1
RMS Resource Allocation
Scenario
Multicast Address from the
Multicast Address Pool
RMS DS0 Pair
Active VTG with channel
Yes
1 per channel in the VTG
Channel not in VTG
No
No
VTG with users only
Yes
No
Remote IDC
No
1 per assigned channel or VTG
Mobile client
No
1 per assigned incident
For detailed information about RMS DS0 requirements, refer to Cisco IPICS Compatibility Matrix.
DSP Channel Optimization and Allocation
Follow these recommendations for optimizing DS0 channels and DSP channels:
•
So that digital signal processors (DSPs) can be shared, first enable dspfarm, and make sure that all
modules are participating in the network clock.
•
When you enable dspfarm, you add specific voice cards to the DSP resource pool. This configuration
allows several interface cards to share the installed DSP resources. (DSPs can be shared among
digital modules or ports (such as T1/E1) and the motherboard, but DSPs cannot be shared among
analog ports (such as an FXS)).
•
At a minimum, you should enable one dspfarm.
•
After the dspfarm is enabled on all modules that have DSPs installed, and all modules are
participating in the main network clock, Cisco IOS interacts with these DSPs as part of the DSP
resource pool.
To help calculate the DSPs that you need for your configuration, refer to High-Density Packet Voice
Digital Signal Processor Modules, which is available at the following URL:
http://www.cisco.com/en/US/products/hw/modules/ps3115/products_qanda_item0900aecd8016c6ad
.shtml
For detailed information about configuring DSP farms, refer to the “Configuring the Cisco IPICS RMS
Component” appendix in Cisco IPICS Server Administration Guide, Release 4.0(2).
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-9
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Examples of Hardware Configuration and Supported Voice Streams
This section provides examples of various hardware configurations and the number of voice streams that
can be supported for use with Cisco IPICS.
When you use the Cisco 2811 with one T1/E1 Multiflex Trunk Voice/WAN Interface
(VWIC-2MFT-T1/E1) card installed on the motherboard, up to 24 pairs of DS0 channels are available
for use if the card is configured for T1 mode. If the card is configured for E1 mode, up to 30 DS0
channels are available. The number of supported voice streams varies based on the configuration that
you use. For example, with one 64-channel high-density Packet Voice/Fax DSP Module (PVDM2-64)
installed, support is provided for up to 32 pairs of voice streams when using the G.711 u-law codec. If
you use the G.729 u-law codec, the PVDM2-64 provides support for 16 pairs of voice streams. In this
situation, one PVDM2-64 does not support full utilization of all pairs of DS0 channels on a T1 line.
The following options are also available for use with the Cisco 2811:
Note
•
Three VWIC-2MFT-T1/E1 interface cards installed on the motherboard with two PVDM2-64
modules, for a total of 128 channels.
•
One T1/E1 High Density Digital Voice Network Module (NM-HDV2-2T1/E1) that is fully
populated with four PVDM2-64 modules, for a total of 256 channels, and two VWIC-MFT-T1/E1
interface cards.
Before you order router hardware for your Cisco IPICS deployment, Cisco recommends that you
determine the number of DS0 channels that you need and your DSP requirements, based on the interface
modules and codec configurations that you use, to ensure full support for your deployment. For example,
if you configure the T1/E1 cards for E1 connectivity, support is provided for 150 pairs of DS0 channels
and 384 DSP resources. Based on the codec that you use, this DSP resource can provide support for 96
G.729 voice streams or 150 G.711 voice streams.
For more information about Cisco interfaces and modules, go to the following URL:
http://www.cisco.com/en/US/products/hw/modules/prod_module_category_home.html
Media Resource Allocation for the Dial Engine
When a user dials in to the Cisco IPICS dial engine, the user accesses the system through a SIP-based
(unicast) connection and obtains a media connection to the Cisco IPICS server. When the user joins a
channel or VTG, Cisco IPICS configures a T1 loopback (DS0) resource on the RMS to enable a
multicast connection from the Cisco IPICS server to the allocated loopback. This loopback configuration
facilitates a multicast connection between the Cisco IPICS server and the selected channel or VTG on
the RMS.
This multicast connection is made one time for a channel or VTG, regardless of the number of dial-in
users who select the channel or VTG. When the last dial-in user disconnects from the channel or VTG,
the resource is released in the RMS and becomes available for use.
When a dial-in user makes a unicast media connection to the media driver on the Cisco IPICS server, the
policy engine sends and receives multicast streams as follows:
1.
After the dial-in user successfully authenticates and selects a resource, Cisco IPICS allocates a DS0
loopback in the RMS for the user and allocates a multicast address from the multicast pool.
Cisco IPICS then performs an Internet Group Management Protocol (IGMP) join operation on the
multicast address so that when additional dial-in users select the same resource, the Cisco IPICS
server can continue to use same the multicast address.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-10
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
2.
When the dial-in user presses 1 on a telephone and begins to talk, Cisco IPICS transmits the audio
to the multicast address of the selected resources.
3.
When the RMS receives the multicast packets, it forwards the packets to the multicast address that
has been allocated from the multicast pool. Cisco IPICS receives that multicast audio stream and
forwards it as a unicast stream to all dial-in users who have selected that resource.
Virtual Talk Groups
A virtual talk group (VTG) enables participants on various channels to communicate by using a single
multicast address. A VTG contains, in a temporary channel, any combination of the following members:
•
Channels
•
Channel groups
•
Users
•
User groups
•
Other VTGs
A Cisco IPICS administrator creates Cisco IPICS channels and assigns a multicast address to each one.
A Cisco IPICS dispatcher creates VTGs as needed. When a dispatcher creates a VTG, the Cisco IPICS
server automatically allocates to the VTG an available address from the multicast pool. So while VTGs
are dynamically assigned addresses from the multicast pool, channels are configured as static addresses
that are outside the range of the addresses that are used by VTGs.
A VTG allows communication between endpoints that are assigned different multicast addresses, such
as two endpoints that have activated different channels. When a VTG is enabled to facilitate
communications between two or more endpoints with different multicast addresses, an RMS must
bridge, or mix, the multicast streams of each channel. In this VTG scenario, the Cisco IPICS sever
allocates a loopback voice port for each channel in the VTG.
For example, assume that a dispatcher creates a VTG named Combined and that this VTG includes the
Police channel and Fire channel as members. Also assume that each LMR voice port is statically
configured with a multicast address, so that LMR police users always send to the Police channel, and
LMR fire users always send to the Fire channel. To provide communication between the Police channel
and the Fire channel, an RMS must bridge the multicast streams from these channels.
In this example, when a user talks on the Police channel (channel 1), the RMS router must bridge that
multicast stream to the Fire channel (channel 2) and to the VTG channel. The RMS must perform similar
operations when a user talks on channel 2 or on the VTG channel. See Figure 2-4.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-11
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Channel 1
Police
239.192.21.64
Channel 2
Fire
239.192.21.65
VTG Channel Mixing
RMS
Channel 1
Channel 2
VTG
RMS
Channel 1
Channel 2
VTG
RMS
VTG
Combined
239.192.21.79
Channel 1
VTG
180552
Figure 2-4
Channel 2
The RMS accomplishes this media mixing by using T1 or E1 interfaces, which are connected
back-to-back with a T1 loopback cable, as illustrated in Figure 2-5.
Figure 2-5
RMS
NM-HDV or NM-HDV2-2T1-E1
VWIC
2MFT-T1
T1 0/0
T1 Loopback Cable
Pinouts
1-4
2-5
4-1
5-2
T1 0/0
DS0
T1 0/1
DS0
DS1
DS1
...
DS23
...
DS23
180553
T1 0/1
In this scenario, the Cisco IPICS server automatically selects two DS0 pairs from the RMS router to use
for mixing the channels. The Cisco IPICS server also configures associated voice ports and dial peers.
To continue this example, assume that Cisco IPICS selects timeslots 10 and 14 as shown:
T1 0/0:10 --------------T1 0/1:10
VTG Combined
San Jose Police
239.192.21.79
239.192.21.64
T1 0/0:14 --------------T1 0/1:14
VTG Combined
San Jose Fire
239.192.21.79
239.192.21.65
Also assume that the Cisco IPICS dispatcher places the following users and channels into the Combined
VTG channel:
•
Channels:
– Police
– Fire
•
Users:
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-12
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
– User 1
– User 2
– User 3
– User 4
When the dispatcher activates this VTG, Cisco IPICS uses the Cisco router to configure on the RMS the
voice ports and dial peers that are associated with the selected T1 DS0s. See Figure 2-6 and the
configuration example that follows this figure.
Figure 2-6
RMS Configuration and Management
Cisco IPICS
Server
RMS
Login (SSH)
Authentication and Authorization
Configuration Management
180554
Reporting
Update Push and Verify
The following example shows configurations for this scenario:
dial-peer voice 90929090 voip
description #0/0:10#1152296144646# INUSE
destination-pattern 90929090
voice class permanent 1
session protocol multicast
session target ipv4:239.192.21.79:21000
codec g711ulaw
no vad
!
dial-peer voice 90929190 voip
description #0/1:10#1152296144646# INUSE
destination-pattern 90929190
voice class permanent 1
session protocol multicast
session target ipv4:239.192.21.65:21000
codec g711ulaw
no vad
!
dial-peer voice 90929092 voip
description #0/0:14#1152296144696# INUSE
destination-pattern 90929092
voice class permanent 1
session protocol multicast
session target ipv4:239.192.21.79:21000
codec g711ulaw
no vad
!
dial-peer voice 90929192 voip
description #0/1:14#1152296144696# INUSE
16
16
18
18
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-13
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
destination-pattern 90929192
voice class permanent 1
session protocol multicast
session target ipv4:239.192.21.64:21000
codec g711ulaw
no vad
!
voice-port 0/0:10
voice class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timing hookflash-in 0
timing hangover 80
connection trunk 90929090
description #0/0:10#1152296144646#
!
voice-port 0/0:14
voice class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timeouts teardown lmr infinity
timing hookflash-in 0
timing hangover 80
connection trunk 90929092
description #0/0:14#1152296144696#
!
voice-port 0/1:10
voice class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timing hookflash-in 0
timing hangover 80
connection trunk 90929190
description #0/1:10#1152296144646#
!
voice-port 0/0:14
voice class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timeouts teardown lmr infinity
timing hookflash-in 0
timing hangover 80
connection trunk 90929192
description #0/1:14#1152296144696#
INUSE 16
INUSE 18
INUSE 16
INUSE 18
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-14
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Using the Cisco Hoot ‘n’ Holler Feature to Mix Channels in the RMS
The RMS uses the Cisco Hoot ‘n’ Holler feature to mix channels. Cisco Hoot 'n' Holler is a
communications system in which the three most recent talkers are mixed into one multicast output
stream. Also known as hootie, these networks provide “always on” multi-user conferences without
requiring that users dial in to a conference.
For additional information about Cisco Hoot ‘n’ Holler, refer to the documentation at the following
URLs:
•
http://www.cisco.com/en/US/products/ps6552/products_ios_technology_home.html
•
http://www.cisco.com/en/US/tech/tk828/tsd_technology_support_protocol_home.html
•
Multicast Hoot ‘n’ Holler White Paper:
http://www.cisco.com/warp/public/cc/so/neso/vvda/hthllr/hhoip_wp.pdf
A virtual interface (VIF) is used to associate an IP address with the voice ports on the RMS. In the
example shown in Figure 2-4 on page 2-12, the RMS joins channels Police (239.192.21.64), Fire
(239.192.21.65), and the Combined VTG (239.192.21.79).
In the Cisco Hoot ‘n’ Holler over IP implementation, all participants in a VTG can speak simultaneously,
However, when voice packets from various sources arrive at the router, the IOS arbitration algorithm
selects only the three most active voice streams and presents them to the router DSP for mixing. If other
voice streams are present, the router drops the longest talker by using a round-robin arbitration
algorithm. See Figure 2-7.
Figure 2-7
Mixing Voice Streams
1
2
IOS
Arbitration
Algorithm
3
4
...
n
DSP
180555
Multicast
Voice
Streams
Table 2-2 shows an example of how mixing works in a VTG that has four active users on a channel.
Table 2-2
Mixing Example
Event
Remarks
User A starts speaking.
1 user speaking.
User B and User C join User A.
3 users speaking simultaneously.
Cisco IOS arbitration engine at each router
receives 3 voice streams.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-15
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Table 2-2
Mixing Example
Event
Remarks
User D starts speaking while the other 3 users
continue speaking.
Cisco IOS arbitration engine at each router
receives 4 voice streams.
The algorithm can present up to 3 voice streams to
the DSP. It drops the voice stream from the
longest talker, User A, and adds User D to the
streams that it presents.
Voice streams in the DSP are now from User B,
User C, and User D.
After 2 seconds, all 4 users are still speaking.
The current longest talker, User B, is dropped, and
User A is added.
Voice streams in the DSP are now User C, User D,
and User A.
After 2 seconds, all 4 users are still speaking.
The current longest talker, User C, is dropped, and
User A is added.
Voice streams in the DSP are now User D, User A,
and User B.
All users continue speaking.
The round-robin process of dropping the current
longest talker and adding the other user every 2
seconds continues.
Cisco IPICS Endpoint Scenarios
When a Cisco IPICS dispatcher activates the Combined VTG (as shown in Figure 2-3 on page 2-8),
Cisco IPICS configures the RMS router to mix the Police, Fire, and Combined VTG channels. Users who
have been added to the VTG will see the new Combined VTG channel on their IDCs or Cisco Unified
IP Phones. LMR endpoints do not have associated users. An LMR channel is statically configured, so an
LMR user can send and receive only from the Cisco IPICS channel that is configured with the same
multicast address as the LMR channel. An LMR user can communicate only with endpoints that are not
using the same channel if the channel of the LMR user is in a VTG with other channels or users.
Figure 2-8 illustrates a scenario in which four users have deactivated their police or fire channels and
have activated the Combined VTG channel.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-16
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Figure 2-8
Multicast Group Membership
R3
Joined 64, 79
LMR 1
E&M
239.192.21.64
Police
LMR 2
239.192.21.65
Fire
R1
Joined 65, 79
E&M
IP
User: PIT User D
Channel: Combined
239.192.21.79
R2
Joined 79
IP MulticastEnabled Network
IDC User: User C
Channel: Combined
239.192.21.79
IP
User: PIT User B
Channel: Combined
239.192.21.79
RMS
Joined 64, 65, 79
237533
Cisco IPICS
IDC User: User A
Server
Channel: Combined
239.192.21.79
When a user deactivates the Police and Fire channel and activates the Combined VTG channel, the
endpoint sends an Internet Group Management Protocol (IGMP) leave message for the Police and Fire
Channel and an IGMP join message for the Combined VTG channel. The LMR voice port channels are
statically configured and the VIF will have already joined the configured multicast group. As shown in
Figure 2-9, when user A transmits, the system sends the multicast packets via the multicast distribution
tree to each endpoint that has joined the combined group, and to the RMS, which mixes the audio and
sends it to the channels in the VTG.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-17
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Figure 2-9
Transmitting to the VTG Channel
R3
Joined 64, 79
79
LMR 1
E&M
239.192.21.64
Police
IP
User: PIT User D
Channel: Combined
239.192.21.79
79
LMR 2
239.192.21.65
Fire
R1
Joined 65, 79
E&M
79
R2
79 Joined 79
IP MulticastEnabled Network
79
79
79
IDC User: User C
Channel: Combined
239.192.21.79
79
IP
IDC User: User A
Channel: Combined
239.192.21.79
Cisco IPICS
Server
User: PIT User B
Channel: Combined
239.192.21.79
Joined 64, 65, 79
237534
RMS
When the RMS router receives the traffic over the Combined VTG channel, it mixes this channel with
the Police and Fire channels and forwards the mixed stream to the LMR endpoints, as shown in
Figure 2-10.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-18
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Figure 2-10
Transmitting VTG Channel to Police and Fire Channels
R3
Joined 64, 79
LMR 1
E&M
239.192.21.64
Police
64
IP
User: PIT User D
Channel: Combined
239.192.21.79
64
R1
Joined 65, 79
LMR 2
E&M
239.192.21.65
Fire
65
R2
Joined 79
IP MulticastEnabled Network
65
65
IDC User: User C
Channel: Combined
239.192.21.79
64
IP
Cisco IPICS
Server
User: PIT User B
Channel: Combined
239.192.21.79
RMS
Joined 64, 65, 79
237535
IDC User: User A
Channel: Combined
239.192.21.79
When the LMR Police user transmits, the only other endpoint that has joined this multicast channel is
the RMS router. The multicast distribution tree forwards the multicast voice traffic to the RMS, where
it is mixed with the Fire channel and the Combined VTG channel and then forwarded to the other
endpoints in the VTG. See Figure 2-11.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-19
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Figure 2-11
LMR Multicast Traffic Flow
R3
Joined 64, 79
LMR 1
E&M
239.192.21.64
Police
64
79
IP
R1
Joined 65, 79
LMR 2
E&M
239.192.21.65
Fire
65 79
79
User: PIT User D
Channel: Combined
239.192.21.79
64
79
R2
79 Joined 79
IP MulticastEnabled Network
65
79
IDC User: User C
Channel: Combined
239.192.21.79
64
IDC User: User A
Channel: Combined
239.192.21.79
79
IP
Cisco IPICS
Server
65
User: PIT User B
Channel: Combined
239.192.21.79
79
237536
RMS
Joined 64, 65, 79
Figure 2-12 shows User C with two active channels: the Fire channel and the Combined VTG channel.
Figure 2-12
Traffic Flow with Two Active Channels
R3
Joined 64, 79
79
LMR 1
E&M
239.192.21.64
Police
64
IP
79
65
79
79
R2
Receives packets
Joined 65, 79
twice
79
79
IP MulticastEnabled Network
65
79
64
IDC User: User A
Channel: Combined
239.192.21.79
65
IDC User: User C
Channel: Combined and Fire
239.192.21.65 and 79
65
IP
Cisco IPICS
Server
65
79
User: PIT User B
Channel: Combined
239.192.21.79
RMS
Joined 64, 65, 79
237537
LMR 2
239.192.21.65
Fire
R1
Joined 65, 79
E&M
User: PIT User D
Channel: Combined
239.192.21.79
64
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-20
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Because User C activated two channels (Fire and the Combined VTG), two multicast groups are joined
through IGMP. As a result, when an endpoint in the Combined VTG transmits, User C will receive the
transmitted packets twice. (In this case, the duplicate packets can cause audio quality issues. Take care
to avoid this scenario.)
If there are no LMR endpoints in a VTG, RMS DS0 resources may not be required for the VTG. For
example, consider a financial institution with one Cisco IPICS channel called Stocks and one channel
called Bonds. The users who are associated with the Stocks channel can communicate with each other,
and the users who are associated with the Bonds channel can communicate with each other. Figure 2-13
illustrates this scenario.
Figure 2-13
Cisco IPICS Scenario with no LMR Endpoints
Finance Organization
2 divisions: Stocks, Bonds
2 channels: Stocks, Bonds
Stocks can talk with each other
Bonds can talk with each other
R3
IP
User: PIT User D
Channel: Bonds
239.192.21.65
R1
R2
IP MulticastEnabled Network
IDC User: User A
Channel: Stocks
239.192.21.64
Cisco IPICS
Server
User: PIT User B
Channel: Stocks
239.192.21.64
237538
IP
IDC User: User C
Channel: Bonds
239.192.21.65
If a VTG is created that contains users but no channels, RMS DS0 resources are not required. The only
resource that is required in this case is a multicast channel from the multicast pool. RMS DS0 resources
are not needed because IDC and Cisco Unified IP Phone users, unlike LMR users, are not statically
configured for one channel. If users only are placed in the VTG, users will see the VTG on their IDCs
or phones. When the VTG activates, these endpoints will simply join the VTG multicast channel that is
allocated by the Cisco IPICS server. See Figure 2-14.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-21
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Figure 2-14
VTG with Users Only
If stocks and bonds users need to
talk with each other, simply create
another channel (Combined) with
all users in this channel. There is
no need for a VTG or an RMS.
Or create a VTG that contains only
users (RMS resources are not needed
unless a user is remote).
R3
IP
User: PIT User D
Channel: Combined
239.192.21.79
R1
R2
IP MulticastEnabled Network
IDC User: User A
Channel: Combined
239.192.21.79
Cisco IPICS
Server
User: PIT User B
Channel: Combined
239.192.21.79
237539
IP
IDC User: User C
Channel: Combined
239.192.21.79
You can also avoid consuming RMS DS0 resources by creating a new channel and associating all users
with that channel, instead of creating a VTG. In this example shown in Figure 2-14, there is a channel
called Combined. Users will see two channels on their IDCs or phones: the Combined VTG channel, and
either the Stocks channel or the Bonds channel.
If you do not want a user (for example, User C) to participate in such a combined VTG channel, you can
take either of these actions:
•
Create a channel (you could name it Combined) and associate with it all users except User C
•
Create a combined VTG with all users except User C
See Figure 2-15 for in illustration of this scenario.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-22
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Figure 2-15
Restricting VTG Access
Assume that everyone needs to talk
except User C.
Solution 1: Do not put this user
in the combined channel.
Solution 2: Do not put this user
in the combined VTG (there are
also no channels in the VTG)
R3
IP
User: PIT User D
Channel: Combined
239.192.21.79
R1
R2
IP MulticastEnabled Network
IDC User: User C
Channel: Bonds
239.192.21.65
IP
User: PIT User B
Channel: Combined
239.192.21.79
Cisco IPICS
Server
237540
IDC User: User A
Channel: Combined
239.192.21.79
If you create a VTG that includes the Stocks channel, the Bonds channel, and all users except User C,
all of the users except User C will see the Combined VTG channel on their IDCs or phones. However,
because the Stocks channel and the Bonds channel are in the VTG, User C will be able to receive from
and transmit to the VTG. See Figure 2-16.
Combined VTG with a User Omitted
In the Combined VTG with the
Stocks channel, the Bonds channel,
and all users except User C, User C
can still particpate in the VTG.
R3
79
IP
79
R1
79
79
Joined
65, 79
R2
User: PIT User D
Channel: Combined
239.192.21.79
IP MulticastEnabled Network
65
79
79
79
Cisco IPICS
IDC User: User A Server
Channel: Combined
239.192.21.79
65
IP
User: PIT User B
Channel: Combined
239.192.21.79
RMS
65
IDC User: User C
Channel: Bonds
239.192.21.65
237541
Figure 2-16
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-23
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Remote IDC Users
IDC users who are not connected to the Cisco IPICS multicast domain must choose the Remote location
when they log in to Cisco IPICS, as shown in Figure 2-17. An IDC user that is logged into Cisco IPICS
in this way is sometimes called a remote IDC user. Examples of such users include those using a satellite
connection or those connecting the network through a VPN.
Figure 2-17
Remote IDC User
Login
Location = REMOTE HTTPS
IP Unicast
Network
IDC
Remote
IP MulticastEnabled Network
IDC
239.192.21.64
RMS
237542
Cisco IPICS
Server
A remote IDC user cannot connect to the Cisco IPICS domain by using multicast. Instead, the remote
IDC user connects to the RMS by using a SIP-based (unicast) connection. The RMS then mixes the
unicast stream to a multicast stream for the channel that the remote IDC user activated. After the remote
IDC user logs in to Cisco IPICS, the Cisco IPICS server allocates a DS0 pair on the RMS for every
channel that is associated with the user. See Figure 2-18.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-24
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Figure 2-18
Timeslot Allocation
IP Unicast
Network
IDC
Remote
After login, Cisco IPICS server
allocates a DS0 pair for each
associated channel
IP MulticastEnabled Network
Cisco IPICS
Server
IDC
239.192.21.64
RMS
237543
One side is a multicast VoIP dial peer,
the other side is a POTS dial peer
Assume that the Cisco IPICS server allocates timeslot 20 for the remote IDC user. In this case, the
Cisco IPICS server configures the voice ports and dial peers as follows:
Multicast Side—239.192.21.64
voice-port 0/0/0:20
voice class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timing hookflash-in 0
timing hangover 80
connection trunk 909090920
description #0/0/0:20#1123534375842# INUSE 92
dial-peer voice 909090920 voip
description #0/0/0:20#1123534375842# INUSE 92
destination-pattern 909090920
voice class permanent 1
session protocol multicast
session target ipv4:239.192.21.64:21000
codec g711ulaw
no vad
Unicast Side—239.192.21.64
voice-port 0/0/1:20
voice class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
playout-delay maximum 100
no comfort-noise
timeouts call-disconnect 3
timing hookflash-in 0
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-25
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
timing hangover 80
description #0/0/1:20#1123534375842# INUSE 92
dial-peer voice 909091920 pots
description #0/0/1:20#1123534375842# INUSE 92
destination-pattern 8880000081909091920
port 0/0/1:20
After the Cisco IPICS server configures the voice ports and the dial peers, it sends to the remote IDC
user the IP address of the RMS and the POTS number for the unicast connection. See Figure 2-19.
Figure 2-19
Providing RMS and POTS Number to Remote User
IP Unicast
Network
IDC
Remote
Server sends RMS address
and POTS number
IP MulticastEnabled Network
IDC
239.192.21.64
RMS
237544
Cisco IPICS
Server
When a channel is activated by a remote IDC user, the remote IDC uses SIP to set up the unicast call.
After the SIP call is established, the remote IDC user can send to and receive from the Police channel.
For an example of this process, see the following figures:
•
Figure 2-20 on page 2-27, “Unicast Connection Set Up”
•
Figure 2-21 on page 2-27, “SIP Signaling Flow”
•
Figure 2-22 on page 2-28, “Unicast to Multicast Call Flow”
•
Figure 2-23 on page 2-28, “Multicast to Unicast Call Flow”
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-26
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Figure 2-20
Unicast Connection Set Up
IP Unicast
Network
IDC
Remote
IP MulticastEnabled Network
Cisco IPICS
Server
IDC
239.192.21.64
Figure 2-21
237545
IDC uses SIP
for call setup
RMS
SIP Signaling Flow
RMS
IDC Remote
INVITE
TRYING
SESSION PROGRESS
ACK
237546
OK
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-27
Chapter 2
Cisco IPICS Component Considerations
Router Media Service
Figure 2-22
Unicast to Multicast Call Flow
If a remote IDC has several channels,
a DS0 Pair with a corresponding POTS
number is configured for each channel.
IP Unicast
Network
IDC
Remote
IP MulticastEnabled Network
Cisco IPICS
Server
Out:
Multicast
In: Unicast to
POTS number/loopback
Figure 2-23
RMS
237547
IDC
239.192.21.64
Multicast to Unicast Call Flow
IP Unicast
Network
IDC
Remote
IP MulticastEnabled Network
Cisco IPICS
Server
In:
Multicast
RMS
237548
IDC
239.192.21.64
Out:
Unicast
When you add an RMS on the Cisco IPICS server, use the loopback address of the RMS router. If there
are several paths to the RMS router and a physical interface is used, the RMS becomes unreachable if
the physical interface goes down or becomes unreachable. If the loopback address is used as the IP
address when adding the RMS on the Cisco IPICS server, that server will push this IP address to the IDCs
as the SIP proxy address.
Note
You can use an interface other than the loopback if specific criteria are met. For more information, refer
to the “Configuring the Cisco IPICS RMS Component” appendix in Cisco IPICS Server Administration
Guide, Release 4.0(2).
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-28
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Integrating Cisco IPICS with SIP Providers
Integrating Cisco IPICS with SIP Providers
The Cisco IPICS dial engine requires a SIP provider to place or receive calls. See Cisco IPICS
Compatibility Matrix for a list of supported SIP providers (Cisco Unified Communications Manager or
Cisco Unified Communications Manager Express with a router running a supported Cisco IOS release).
It is important to consider how the RMS router fits into a deployment topology when determining how
to properly configure the required dial peers. Key guidelines include:
•
All calls to or from the Cisco IPICS dial engine go through the configured SIP provider
•
IDC direct dial calls go from the IDC to the RMS
•
The RMS can also be the SIP provider
Because a Cisco IPICS deployment can vary depending on the call flow, it is important to understand
how a call flow works so that you can properly configure supporting components. Cisco IPICS Server
Administration Guide, Release 4.0(2) provides instructions for configuring the RMS and the Cisco IOS
SIP gateway and SIP provider. The way in which a SIP provider is deployed in a network and the dial
plan at your site dictate how components are configured.
The following sections describe how Cisco IOS dial peers are configured to provide connectivity for
various scenarios:
•
Requirements for SIP Sessions, page 2-29
•
Default Dial Peer Scenarios, page 2-29
•
When is an IDC Direct Dial prefix needed?, page 2-34
Requirements for SIP Sessions
Cisco IPICS imposes the following requirements on SIP sessions:
•
SIP sessions between the SIP provider and Cisco IPICS are restricted to the following media
capabilities:
– Codec must be G.711u-law
– Packet size must be 20 bytes (the default value for G.711 u-law)
– Sampling rate must be 8000 Hz (the default value for G.711 u-law)
– Telephone event payload must be 101
•
The multicast packets that Cisco IPICS sends to the RMS must have a Time to Live (TTL) of 64.
This value is not configurable. Make sure that a TTL of 64 is enough for the worst-case path between
the RMS and Cisco IPICS.
•
There cannot be a firewall that blocks Real-Time Transport Protocol (RTP), Real-time Transport
Control Protocol Control Protocol (RTCP), or SIP traffic between Cisco IPICS and the SIP provider.
•
NAT traversal is not supported by Cisco IPICS. There cannot be a NAT between Cisco IPICS and
the RMS or between Cisco IPICS and the SIP provider.
Default Dial Peer Scenarios
You must configure specific incoming dial peers and outgoing dial peers on the RMS component. These
configurations vary depending on whether you use the Cisco IOS gateway or Cisco Unified
Communications Manager. There also are dial peer requirements when you use the Cisco IPICS direct
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-29
Chapter 2
Cisco IPICS Component Considerations
Integrating Cisco IPICS with SIP Providers
dial feature. For related information about configuring Cisco IPICS for the direct dial feature, refer to
the “Configuring SIP” section in Cisco IPICS Server Administration Guide, Release 4.0(2). Form related
information about configuring dial peers on the RMS, refer to the “Configuring the Cisco IPICS RMS
Component” appendix in Cisco IPICS Server Administration Guide, Release 4.0(2).
Dial Peer Use in Scenarios
The following figures describe which dial peers are used in different scenarios:
•
Figure 2-24 on page 2-30, “Calls to Policy Engine in Deployment that Uses Cisco Unified
Communications Manager 5.1(2b)”
•
Figure 2-25 on page 2-30, “Calls from Policy Engine in Deployment that Uses Cisco Unified
Communications Manager 7.0(2)”
•
Figure 2-26 on page 2-31, “IDC Direct Dial Calls in Deployment that Uses Cisco Unified
Communications Manager 5.1(2b)”
Figure 2-24
Calls to Policy Engine in Deployment that Uses Cisco Unified Communications
Manager 5.1(2b)
Cisco Unified
Communications
Manager 5.1(2b)
Cisco IPICS
Server
SIP Trunk
No Dial Peers
237549
V
PSTN
Figure 2-25
Calls from Policy Engine in Deployment that Uses Cisco Unified Communications
Manager 7.0(2)
Cisco Unified
Communications
Manager 7.0(2)
Cisco IPICS
Server
SIP Trunk
No Dial Peers
PSTN
239012
V
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-30
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Integrating Cisco IPICS with SIP Providers
Figure 2-26
IDC Direct Dial Calls in Deployment that Uses Cisco Unified Communications
Manager 5.1(2b)
Cisco Unified
Communications
Manager 7.0(2)
RMS
V
V
PSTN
239013
IDC
555 In
556 Out
Call Flow and Dial Peer Examples
The following sections describe possible call flows and provide dial peer configuration examples for
various scenarios:
•
Scenario 1: Policy Engine < - > SIP < - > Cisco Unified Communications Manager 5.1(2b),
page 2-31
•
Scenario 2: Policy Engine <-> SIP <-> Cisco IOS SIP Gateway, with no Cisco Unified
Communications Manager or Cisco Unified Communications Manager Express, page 2-32
•
Scenario 3: Policy Engine <-> SIP <-> Cisco IOS SIP Gateway, Cisco Unified Communications
Manager, RMS Functionality Not on the Cisco IOS SIP Gateway, page 2-33
Scenario 1: Policy Engine < - > SIP < - > Cisco Unified Communications Manager 5.1(2b)
This scenario requires a SIP trunk between Cisco IPICS and Cisco Unified Communications Manager
for dial in and dial out. It also requires a SIP trunk between the RMS and Cisco Unified Communications
Manager for IDC direct dial feature.
Figure 2-27 illustrates this scenario.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-31
Chapter 2
Cisco IPICS Component Considerations
Integrating Cisco IPICS with SIP Providers
Figure 2-27
Calls in Deployment that Uses Cisco Unified Communications Manager 5.1(2b)
RMS
SIP Trunk for
IDC Direct Dial
V
Cisco Unified
Communications
Manager 5.1(2b)
Cisco IPICS
Server
SIP Trunk for
Policy Engine
Voice Gateway to
PSTN
239011
V
This scenario does not include a Cisco IOS SIP gateway, so only relevant dial peer entries are configured
in the RMS. The RMS dial peers are used for remote IDC connections and IDC direct dial calls. These
calls will match on incoming dial peer 555. The IDC direct dial calls use outgoing dial peer 556 to route
to Cisco Unified Communications Manager via the SIP trunk.
RMS dial peers are configured as follows. The dtmf-relay rtp-nte setting is required to allow parties
called by the dial engine to enter DTMF digits when the parties connect to the Cisco IPICS telephony
user interface (TUI).
dial-peer voice 555 voip
voice-class codec 2
session protocol sipv2
incoming called-number .
dtmf-relay rtp-nte
no vad
!
dial-peer voice 556 voip
description sip provider
destination-pattern .T
voice-class codec 1
session protocol sipv2
session target ipv4:<Cisco Unified Communications Manager 5.1(2b) IP Address>
session transport tcp
dtmf-relay rtp-nte
Scenario 2: Policy Engine <-> SIP <-> Cisco IOS SIP Gateway, with no Cisco Unified Communications Manager or Cisco Unified
Communications Manager Express
This scenario is dependent on the desired SIP call routing. The appropriate dial peers must be configured
based on your requirements. In most cases, this configuration will be a subset of scenario 3 in which the
dial peers that are used for connectivity with the Cisco Unified Communications Manager are modified
to reflect the desired dial patterns and destinations.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-32
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Integrating Cisco IPICS with SIP Providers
Scenario 3: Policy Engine <-> SIP <-> Cisco IOS SIP Gateway, Cisco Unified Communications Manager, RMS Functionality Not
on the Cisco IOS SIP Gateway
In scenario, the Cisco IOS SIP gateway is the SIP provider and the RMS is on a separate router.
Figure 2-28 illustrates this scenario.
Figure 2-28
Calls in Deployment that Uses Cisco IOS SIP Gateway and Cisco Unified
Communications Manager, RMS Functionality not on the Cisco IOS SIP Gateway
Cisco Unified
Communications
Manager 7.0(2)
Cisco IOS
SIP Gateway
SIP or H.323 Trunk for Policy Engine
Dial In/Out and IDC Direct Dial
V
SIP Trunk for
Policy Engine
Dial In/Out
V
Voice Gateway to
PSTN
Cisco IPICS
Server
237544
V
SIP Trunk for IDC
Direct Dial
RMS
The example dial peer configuration in this scenario assumes the following:
•
Phones that are connected to Cisco Unified Communications Manager have five-digit extensions.
•
Outbound calls to the PSTN and to other Cisco Unified Communications Manager servers are routed
in the Cisco Unified Communications Manager servers by using 9 and 8.
•
Dial numbers that ops views use to reach the dial engine are five-digit numbers that start with 251.
•
There is no direct dial prefix so no translation rules are required.
This scenario addresses the following call types:
•
IDC remote (incoming dial peer 555 on RMS)
•
Calls from Cisco Unified Communications Manager (incoming dial peer 555, outgoing dial peer
25100 on Cisco IOS SIP gateway)
•
SIP calls from the dial engine through the Cisco IOS SIP gateway to Cisco Unified Communications
Manager (incoming dial peer 555, outgoing dial peers 25000.8000 and 9000 on Cisco IOS SIP
gateway)
•
IDC direct dial through RMS to Cisco IOS SIP gateway to Cisco Unified Communications Manager
(RMS incoming dial peer 555, RMS outgoing dial peer 556, Cisco IOS SIP gateway incoming dial
peer 555, Cisco IOS SIP gateway outgoing dial peer 557)
RMS dial peers are configured as follows:
Note
When several RMS components exist, they must each have outgoing dial peers to support connectivity
to the SIP provider.
dial-peer voice 555 voip
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-33
Chapter 2
Cisco IPICS Component Considerations
Integrating Cisco IPICS with SIP Providers
voice-class codec 2
session protocol sipv2
incoming called-number .
dtmf-relay rtp-nte
no vad
!
dial-peer voice 556 voip
destination-pattern .T
voice-class codec 1
session protocol sipv2
session target ipv4:<Cisco IOS SIP Gateway IP Address>
session transport tcp
dtmf-relay rtp-nte
Cisco IOS SIP gateway dial peers are configured as follows:
dial-peer voice 555 voip
voice-class codec 2
session protocol sipv2
incoming called-number .
dtmf-relay rtp-nte
no vad
!
dial-peer voice 25000 voip
destination-pattern .....
voice-class codec 1
session target ipv4:<Cisco Unified Communications Manager 4.1 IP Address>
session transport tcp
dtmf-relay h245-alphanumeric
!
dial-peer voice 9000 voip
destination-pattern 9T
voice-class codec 2
session target ipv4:<Cisco Unified Communications Manager 4.1 IP Address>
dtmf-relay h245-alphanumeric
!
dial-peer voice 8000 voip
destination-pattern 8T
voice-class codec 2
session target ipv4:<Cisco Unified Communications Manager 4.1 IP Address>
dtmf-relay h245-alphanumeric
!
dial-peer voice 25100 voip
destination-pattern 251..
session protocol sipv2
session target ipv4:<Cisco IPICS Server IP Address>
session transport tcp
dtmf-relay rtp-nte
When is an IDC Direct Dial prefix needed?
A Direct Dial prefix is an optional digit string that the server prepends to each direct dial number when
it dials the number. Using a dial prefix can help to avoid dial plan conflicts. For example, if the dial prefix
string is 9 and the direct dial destination number is 1234, the number 91234 is dialed.
Because the IDC direct dial feature always uses the RMS as a proxy, there may be cases where a unique
dial pattern is required to perform digit manipulation on dialed strings so that they can be differentiated
from other calls that do not require digit manipulation.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-34
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
IDC Dialer Configuration and Integration with Unified Communications Platform
In these cases, you can employ a combination of dial peers and translation rules in the RMS to
manipulate the digits before they are sent to the desired destination.
The following example configures a translation rule for the outgoing dial peer in the RMS. This
configuration allows the use of a direct dial prefix for the direct dial feature. Although this configuration
is required for most scenarios, the default configuration allows for a dial prefix of 9, which is removed
by the following RMS configuration.
voice translation-rule 1
rule 1 /^9\(.*\)$/ /\1/
voice translation-profile 1
translate called 1
dial-peer voice 556 voip
destination-pattern 9T
translation-profile outgoing 1
preference 10
voice-class codec 1
session protocol sipv2
session target ipv4:<SIP Provider IP Address>
session transport tcp
dtmf-relay rtp-nte
IDC Dialer Configuration and Integration with Unified
Communications Platform
The IDC dialer functionality enables users with the Cisco IPICS Dispatcher role to make and receive
PSTN calls and patch a VTG, channel, or incident to a PSTN user. The IDC dialer provides two lines,
which can be used separately.
Setting up the IDC dialer functionality involves these general steps:
•
Configuring an IDC dialer endpoint in Cisco Unified Communications Manager or Cisco Unified
Communications Manage Express
•
Configuring the IDC dialer in Cisco IPICS
To configure the IDC dialer, you must obtain the following information:
•
The IP address of the Cisco Unified Call Manager or Cisco Unified Call Manager Express that you
will use
•
A directory number (DN) for each Cisco IPICS dispatcher that will use the IDC dialer
•
The user name and password that are configured for the DN in Cisco Unified Call Manager and
Cisco Unified Call Manager Express
The following sections provide information about configuring the IDC dialer feature and describe how
to integrate this feature with Cisco Unified Communications Manager and Cisco Unified
Communications Manager Express:
•
Configuring an IDC Dialer End Point on Cisco Unified Communications Manager, page 2-36
•
Configuring an IDC Dialer End Point on Cisco Unified Communications Manager Express,
page 2-36
•
Configuring the IDC Dialer in the Cisco IPICS Administration Console, page 2-37
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-35
Chapter 2
Cisco IPICS Component Considerations
IDC Dialer Configuration and Integration with Unified Communications Platform
Configuring an IDC Dialer End Point on Cisco Unified Communications Manager
This section explains how to configure an IDC Dialer endpoint in Cisco Unified Communications
Manager. You must configure such and end point for each Cisco IPICS dispatcher who will use the IDC
Dialer.
Procedure
Step 1
Log in to the Cisco Unified Communications Manager Administration console.
Step 2
Take these actions to configure an end user, which will be an IDC Dialer end point:
Step 3
a.
Choose User Management > End User.
b.
Choose the Add New tab.
c.
Configure the end user. At a minimum, enter information in the User ID, Password, Confirm
Password, and Last Name fields.
d.
Click Save
Take these actions to configure a phone with the DN that the IDC dialer requires:
a.
Choose Device > Phone.
b.
Click Add New.
c.
From the Phone Type drop-down list, choose Third-Party SIP Device Basic.
d.
Make configuration settings as appropriate.
The MAC can be a unique dummy address.
In the Owner User ID and Digest User fields, choose the use ID that you configured in Step 2.
From the SIP Profile drop-down list, choose Standard SIP Profile.
e.
Click Save.
Step 4
In the Association Information area, click Line [1] - Add a new DN and configure the DN for the phone
with the DN you want to use and save the configuration.
Step 5
Perform this procedure for each Cisco IPICS dispatcher who will use the IDC dialer.
Configuring an IDC Dialer End Point on Cisco Unified Communications Manager
Express
The following example shows how to configure an IDC dialer endpoint in Cisco Unified
Communications Manager Express. You must configure such and end point for each Cisco IPICS
dispatcher who will use the IDC Dialer.
voice register dn 1
number 4100
!
voice register pool 2
id mac 0000.0000.0000
number 1 dn 2
dtmf-relay rtp-nte
voice-class codec 1
username dispatch password cisco
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-36
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
IDC Dialer Configuration and Integration with Unified Communications Platform
description ipics-idc
!
Configuring the IDC Dialer in the Cisco IPICS Administration Console
To use the IDC dialer, several items must be configured in the Cisco IPICS Administration Console.
Table 2-3 provides an overview of these items. For complete configuration instructions, refer to Cisco
IPICS Server Administration Guide, Release 4.0(2).
Table 2-3
Overview of IDC Configuration Items in Cisco IPICS Administration
Location in Cisco IPICS
Administration Console
Configuration Item
CUCM Host Name or IP Address Administration >
Options window > General tab
Users > User Name link >
Communications tab
•
IDC Dialer Phone Number
•
End User Name
•
End User Password
•
Confirm End User Password
Explanation
Host name or IP address of the
Cisco Unified Communications
Manager or Cisco Unified
Communications Manager
Express that the IDC uses for the
dialer functionality.
DN information for each Cisco
IPICS dispatcher who will use
the IDC.
The IDC Dialer Phone Number
corresponds to the DN that is
configured in Cisco Unified
Communications Manager or
Cisco Unified Communications
Manager Express.
Each DN must be unique.
In addition, be aware of these guidelines:
•
Only one Cisco Unified Communications Manager Cisco Unified Communications Manager
Express at a time can be associated with the IDC dialer.
•
Each of the DNs and Cisco IPICS dispatches that will use the IDC dialer must be configured in an
associated Cisco Unified Communications Manager or Cisco Unified Communications Manager
Express.
•
If an IDC dialer configuration item is changed in the Cisco IPICS Administration Console, the IDC
must be restarted before it will recognize the change. In addition, if such changes are made, the IDC
dialer will drop any existing calls.
The IDC does not require specific configuration to use the IDC dialer. The IDC receives the IDC
configuration from the Cisco IPICS server. If the configuration is valid, the IDC registers the DN with
the designated Cisco Unified Communications Manager or Cisco Unified Communications Manager
Express and enables the Dial Pad and Channel Patch area.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-37
Chapter 2
Cisco IPICS Component Considerations
Cisco IPICS Mobile Client for Apple iPhone
Cisco IPICS Mobile Client for Apple iPhone
The IPICS Mobile Client is an application for the Apple iPhone that allows you to use an iPhone to
interact with other participants in a Cisco IP Interoperability and Collaboration System (IPICS) incident.
The iPhone can communicate with Cisco IPICS either via a WiFi network connection or a 3G connection
by using the Cisco Incident app. For detailed information about this application, and information about
feature limits when using a WiFi connection, refer to Cisco IPICS Mobile Client for Apple iPhone
Reference Guide.
When using the iPhone as a mobile client, be aware of the following:
•
If you are using a WiFi connection, the Cisco IPICS server and the RMS component must be
accessible on the wireless network.
•
Network connectivity for all Cisco IPICS components that are to be used with the mobile client
should be established before using the mobile client.
•
The Incident App PTT feature is supported only on WiFi networks.
•
Uploading photographs and video clips over a 3G connection can be extremely slow, depending on
the ISP that the iPhone us using.
•
When you view a list of incidents or a list of resources in an incident, the information in the screen
updates automatically. The update interval is defined by the IDC Update Poll option in the
Administration > Options > IDC/Client tab in the Cisco IPCS Administration Console. The
default update interval is 5 seconds.
The following sections provide related information:
•
DNS Configuration, page 2-38
•
Wireless Network Configurations, page 2-41
•
Wireless Configuration on an iPhone, page 2-46
DNS Configuration
The mobile client uses SSL to communicate with the server. SSL requires that DNS be enabled in your
network.
The following sections provide information about the models that you can use to configure DNS in you
network.
•
Intranet Access Model, page 2-38
•
Internet/Intranet Access Model, page 2-39
Intranet Access Model
This section provides guidelines for how to configure DNS when an iPhone will connect to an IPICS
server only on a local intranet.
•
Ensure that a DNS server is configured in your LAN.
•
Configure each component in the Cisco IPICS component to us this DNS server for hostname
resolution.
•
Configure the hostname for the DNS server as an entry in the DNS server.
•
Do not use the Hosts file on an IDC client PC to bypass the DNS name resolution.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-38
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Cisco IPICS Mobile Client for Apple iPhone
•
Ensure that you can ping the Cisco IPICS server by its hostname from each IDC client PC.
•
If you are using DHCP for IP address assignments, ensure that the correct search domain is
configured on the DHCP server or the wireless controller that is acting as a DCHP server. The search
domain is not populated automatically.
•
If you are not using DHCP for IP address assignment, ensure that the correct domain name and client
ID are configured on the iPhone. Also, ensure that you populate the DNS server address on the
iPhone in addition to the IP address, mask, and default gateway values. For information about how
to configure these options on an iPhone, see the “Wireless Configuration on an iPhone” section on
page 2-46.
DHCP servers use the client ID to bind the iPhone to a specific IP address. This binding ensures that
the iPhone can communicates through firewalls, and access restrictions (Access Control Lists) in
your network. If you do not configure a client ID, you cannot access the Incident app on an iPhone.
Internet/Intranet Access Model
This section provides guidelines for how to configure DNS when an iPhone will connect to an IPICS
server via the Internet and a local intranet.
•
Ensure that a DNS server is configured in your LAN.
•
Configure each component in the Cisco IPICS component to us this DNS server for hostname
resolution.
•
Configure the hostname for the DNS server as an entry in the DNS server.
•
Do not use the Hosts file on an IDC client PC to bypass the DNS name resolution.
•
Ensure that you can ping the Cisco IPICS server by its hostname from each IDC client PC.
•
If you are using DHCP for IP address assignments, ensure that the correct search domain is
configured on the DHCP server or the wireless controller that is acting as a DCHP server. The search
domain is not populated automatically.
•
If you are not using DHCP for IP address assignment, ensure that the correct domain name and client
ID are configured on the iPhone. Also, ensure that you populate the DNS server address on the
iPhone in addition to the IP address, mask, and default gateway values For information about how
to configure these options on an iPhone, see the “Wireless Configuration on an iPhone” section on
page 2-46.
DHCP servers use the client ID to bind the iPhone to a specific IP address. This binding ensures that
the iPhone can communicates through firewalls, and access restrictions (Access Control Lists) in
your network. If you do not configure a client ID, you cannot access the Incident app on an iPhone.
•
If you are not using the DHCP Server for IP Address assignment, then you also need to ensure that
you populate the DNS Server address on the iPhone in addition to the IP Address, Mask and Default
Gateway that you may specify.
•
If the mobile client needs to access two domains (one for the intranet and one for the Internet), the
intranet DNS must be configured to forward requests from the mobile client to the Internet DNS,
and the Internet DNS must be configured to forward requests to the intranet DNS.
•
If the Cisco IPICS server is reachable on the Internet and has a FQDN registered on the web, any
Internet DNS can be used to resolve the IP address of the server. In such a scenario, the local DNS
should configured with the DNS address that is provided by the local ISP. Alternatively, you can use
a public DNS, such as 4.2.2.2 and 8.2.2.2, ro provide name resolution.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-39
Chapter 2
Cisco IPICS Component Considerations
Cisco IPICS Mobile Client for Apple iPhone
Configuring DNS Settings on an iPhone.
To configure DNS settings on an iPhone, follow these steps:
Procedure
Step 1
On the iPhone, launch the Settings app.
Step 2
Touch Wi-Fi settings icon, make sure that WiFi is on, then choose the SSID to use to associate the iPhone
to the Cisco IPICS server.
Step 3
Touch the SSID name and choose to expand the configuration options.
Step 4
Touch the DHCP tab and enter information for the Search Domains in the Client ID options.
You may need to scroll down to see these options.
Configuring a Cisco Multiservices Platform Devices as a DNS Server
To configure a Cisco Multiservice Platform Series device that is running SLES 10 as a DNS server,
follow these steps:
Procedure
Step 1
On the device, start the YaST Control Center.
Step 2
Choose Network Services > DNS Server.
Step 3
Choose DNS Zones, enter a zone name, then choose Add.
Step 4
Highlight the zone that you added and choose Edit.
Step 5
Check the Choose Enable Zone Transport check box, and check these ACLs: any, localhosts, and
localnests.
Step 6
Choose NS Records.
Step 7
Enter the fully qualified domain name of the DNS server in the Name Server to Add field, then click
Add.
Step 8
Choose Records.
Step 9
In the Record Settings area, take these actions:
Step 10
a.
In the Record key field, enter the hostname of the Cisco IPICS server.
b.
In the Type field, choose A:
c.
In the Value field, enter the IP address of the Cisco IPICS server
d.
Choose Add.
Choose OK.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-40
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Cisco IPICS Mobile Client for Apple iPhone
Wireless Network Configurations
Using an iPhone mobile client on a wireless network provides two primary benefits: The PTT key in the
Cisco Incidents app is available, and uploading photographs and video clips is much faster than on a 3G
network.
This section describes two main types of wireless networks: IOS-based and LWAPP-based. IOS-based
networks use one access point (AP) and one router. LWAPP-based networks are hierarchical. In addition,
and IOS implementation requires manual configuration, but in an LWAPP implementation, configuration
and the software images for access points is downloaded from the WLAN controller.
The following sections provide configurations for various wireless options in a Cisco IPICS deployment:
•
IOS-Based Wireless Configuration, page 2-41
•
LWAPP-Based Wireless Configuration, page 2-45
For more detailed information about deploying wireless networks, refer to the documentation for your
wireless components.
IOS-Based Wireless Configuration
In an IOS-based wireless network, a wireless NIC can be part of the RMS or a standalone AP can connect
to the network and provide wireless connectivity. The former is useful in small site deployments or an
emergency deployment in which a wireless network must be brought up quickly.
The following sections provide three configuring options for an OS-based wireless network:
•
Wireless Bridge Configuration, page 2-41
•
Non-Root Bridge Configuration, page 2-43
•
NAT Configuration using the ISR and Wireless, page 2-44
Wireless Bridge Configuration
The following example shows a Layer 2 configuration for a Cisco router in a wireless implementation:
aaa new-model
!
!
aaa group server radius rad_eap
server 20.0.0.1 auth-port 1812 acct-port 1813
!
aaa authentication login eap_methods group rad_eap
!
aaa session-id common
!
resource policy
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
dot11 ssid airlink2-bridge
vlan 1
authentication open
authentication key-management wpa
wpa-psk ascii 0 12345678
!
dot11 priority-map avvid
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-41
Chapter 2
Cisco IPICS Component Considerations
Cisco IPICS Mobile Client for Apple iPhone
ip cef
!
!
no ip domain lookup
!
!
bridge irb
!
!
interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 30.0.0.1 255.0.0.0
duplex auto
speed auto
!
interface Dot11Radio0/0/0
no ip address
!
encryption vlan 1 mode ciphers tkip
!
ssid airlink2-bridge
!
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0
station-role root bridge
!
interface Dot11Radio0/0/0.1
encapsulation dot1Q 1 native
no snmp trap link-status
bridge-group 1
bridge-group 1 spanning-disabled
!
interface Dot11Radio0/0/1
no ip address
speed basic-6.0 9.0 basic-12.0 18.0 basic-24.0 36.0 48.0 54.0
station-role root
!
interface BVI1
ip address 20.0.0.1 255.0.0.0
!
ip route 0.0.0.0 0.0.0.0 20.0.0.5
!
!
ip http server
no ip http secure-server
!
!
radius-server local
nas 20.0.0.1 key 0 wireless
user non-root nthash 0 3741A4EE66E1AA56CD8B3A9038580DC9
!
radius-server host 20.0.0.1 auth-port 1812 acct-port 1813 key wireless
!
control-plane
!
bridge 1 route ip
!
!
line con 0
exec-timeout 0 0
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-42
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Cisco IPICS Mobile Client for Apple iPhone
line aux 0
line vty 0 4
!
!
webvpn context Default_context
ssl authenticate verify all
!
no inservice
!
end
Non-Root Bridge Configuration
The following example shows a Layer 3 configuration for a Cisco router in a wireless implementation:
no aaa new-model
!
resource policy
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
dot11 ssid airlink2-bridge
vlan 1
authentication open
authentication key-management wpa
wpa-psk ascii 0 12345678
!
dot11 priority-map avvid
ip cef
!
!
bridge irb
!
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
bridge-group 1
bridge-group 1 spanning-disabled
!
interface Dot11Radio0/1/0
no ip address
!
encryption vlan 1 mode ciphers tkip
!
ssid airlink2-bridge
!
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0
station-role non-root bridge
!
interface Dot11Radio0/1/0.1
encapsulation dot1Q 1 native
no snmp trap link-status
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-43
Chapter 2
Cisco IPICS Component Considerations
Cisco IPICS Mobile Client for Apple iPhone
bridge-group 1
bridge-group 1 spanning-disabled
!
interface BVI1
ip address 20.0.0.5 255.0.0.0
!
ip route 0.0.0.0 0.0.0.0 20.0.0.1
!
!
ip http server
no ip http secure-server
!
!
control-plane
!
bridge 1 route ip
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
login
!
!
webvpn context Default_context
ssl authenticate verify all
!
no inservice
!
end
NAT Configuration using the ISR and Wireless
The following example shows a Layer 3 configuration for a Cisco router in a wireless implementation
with NAT:
C1803W_UC#
C1803W_UC#sh run
Building configuration...
Current configuration : 2189 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname C1803W_UC
!
boot-start-marker
boot-end-marker
!
logging buffered 4096 debugging
no logging console
!
no aaa new-model
!
resource policy
!
!
ip nat inside source list 1 interface Virtual-Dot11Radio0 overload
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-44
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Cisco IPICS Mobile Client for Apple iPhone
!
dot11 ssid hurricane
authentication open
authentication key-management wpa
wpa-psk ascii 0 allyouneedislove
!
dot11 ssid tsunami
authentication open
guest-mode
!
dot11 priority-map avvid
!
!
ip cef
no ip dhcp use vrf connected
ip dhcp excluded-address 100.1.1.1
!
ip dhcp pool jimmy
network 100.1.1.0 255.255.255.0
default-router 100.1.1.1
!
!
controller DSL 0
line-term cpe
!
!
bridge irb
!
interface Dot11Radio0
ip address 100.1.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly
no ip route-cache cef
no ip route-cache
!
ssid tsunami
!
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0
station-role root
rts threshold 2312
no cdp enable
!
interface Dot11Radio1
ip address dhcp
ip nat outside
ip virtual-reassembly
!
encryption mode ciphers tkip
!
ssid hurricane
!
speed basic-6.0 9.0 basic-12.0 18.0 basic-24.0 36.0 48.0 54.0
station-role non-root
!
End
LWAPP-Based Wireless Configuration
This section provides an overview of LWAPP configuration for a single WLAN-based wireless
implementation. Detailed configuration information is outside the scope of this manual, but is available
in the documentation for your wireless controller.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-45
Chapter 2
Cisco IPICS Component Considerations
Cisco IPICS Mobile Client for Apple iPhone
A typical LWAPP-based wireless network requires at least two pieces of hardware: the WLAN controller
and the an LWAPP-based access point. The information in this section assumes that an Ethernet network
is in place and that the WLAN controller and the LWAPP-based access can reach each other
On the LWAPP controller, you must configure the Management Interface, AP-Manager, and WLAN
SSID with the appropriate security settings. Optionally, the DHCP server and the VPN passthrough also
can be configured on the WLAN controller to provide a richer and more integrated user experience to
iPhone users. The DNS server cannot be configured on the WLAN controller and must be configured
separately.
Configuring the Management Interface and AP-Manager is straightforward: you must assign an IP
address assigned to each of these interfaces. The Management Interface is used by a system
administrator to access the WLAN controller. The AP-Manager is used by access points to reach the
WLAN controller and download their configurations.
Configuring the SSID requires the name of the SSID and the radio policy that is associated with the
SSID. In addition, broadcast SSID should be enabled. Authentication is optional but recommended.
Note
If you do not enable the broadcast SSID on the WLAN, you must configure the WLAN on an iPhone
each time you access the Incident application. This approach is not recommended. It is best to broadcast
the SSID and enable some level of encryption on the Wireless connectivity that is shared between he
iPhone and the WLAN controller.
If your deployment includes a standalone DHCP server that allocates IP addresses mobile clients, ensure
that you configure Override for the DCHP server in the SSID configuration pages and specify the IP
address of this DHCP server.
The WLAN controller includes a built-in DHCP server that also can be enabled to provide IP addresses
for mobile clients. However, this DHCP server has limited functionality and is not recommended for a
large enterprise with many clients that require specialized DHCP configuration.
Wireless Configuration on an iPhone
After the configuration of the wireless infrastructure is complete, it is a relatively simple process to
configure a iPhone for wireless connectivity. This section describes how to configure an iPhone for
connectivity to the Cisco IPICS server over a wireless network. After For additional information about
wireless connectivity for an iPhone, see your iPhone documentation and online forums.
To configure wireless on an iPhone, follow these steps:
Procedure
Step 1
On the iPhone, launch the Settings app.
Step 2
Touch Wi-Fi settings icon, then choose the WLAN ID that you configured from the list of IDs.
Step 3
If security is enabled for your wireless network, enter the security passphrase.
The iPhone automatically determines the encryption method to use to connect to the WLAN controller.
In some situations, it might be necessary to enter the security information manually on the iPhone.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-46
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Cisco Unified IP Phones
Cisco Unified IP Phones
If your Cisco IPICS deployment includes Cisco Unified Communications Manager or Cisco Unified
Communications Manager Express, you can use the Cisco Unified IP Phone services application
programming interface (API) to provide PTT capabilities to certain Cisco Unified IP Phone models. A
phone with the PTT capability enabled can function similarly to an IDC, providing an easy-to-use GUI
that allows users to monitor or participate in a PTT channels or VTG over a VoIP network. However,
unlike an IDC, a phone can participate in only one channel or VTG at a time. To participate in a channel
or VTG, a phone user chooses the desired channel or VTG from a list that displays on the phone.
A phone that is configured to work as a PTT device uses a stand-alone LMR PTT audio client. This
Extensible Markup Language (XML) application enables the display of interactive content with text and
graphics on the phone.
To enable this feature, Cisco Unified Communications Manager or Cisco Unified Communications
Manager Express must be deployed in your IP telephony (IPT) network, and either of these applications
must be configured with the IP address of the Cisco IPICS server. A Cisco Unified IP Phone uses this IP
address to locate the server and download the PTT XML application.
For related information about configuring this feature, refer to the “Setting Up the Cisco IP Phone for
use with Cisco IPICS” appendix in Cisco IPICS Server Administration Guide, Release 4.0(2). For a list
of Cisco Unified IP Phones that Cisco IPICS supports as PTT devices, refer to Cisco IPICS
Compatibility Matrix.
This section includes these topics:
•
Cisco Unified Communications Manager Configuration Overview, page 2-47
•
Cisco Unified Communications Manager Express Configuration Overview, page 2-47
Cisco Unified Communications Manager Configuration Overview
You use the Cisco IP Phone Services Configuration page in the Cisco Unified Communications Manager
Administration application to define and maintain the list of Cisco Unified IP Phone services to which
users can subscribe. These services are XML applications that enable the display of interactive content
on supported models of a Cisco Unified IP Phone.
After you configure a list of IP phone services, Cisco Unified IP Phone users can access the
Cisco Unified Communications Manager User Options menu and subscribe to the services, or an
administrator can add services to Cisco Unified IP Phones and device profiles. Administrators can assign
services to speed-dial buttons, so users have one-button access to the services.
For detailed information about configuring phone services, refer to the “Cisco IP Phone Services”
chapter in Cisco Unified Communications Manager System Guide, which is available at this URL:
http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html
Cisco Unified Communications Manager Express Configuration Overview
The following is a sample Cisco IOS router configuration that enables Cisco Unified Communications
Manager Express to support a Cisco Unified IP Phone as a Cisco IPICS PTT device:
ip dhcp excluded-address 10.1.1.1
!
ip dhcp pool pool1
network 10.1.1.0 255.255.255.248
domain-name yourdomainname
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-47
Chapter 2
Cisco IPICS Component Considerations
Text to Speech
dns-server dns1 dns2
default-router 10.1.1.1
option 150 ip 10.1.1.1
tftp-server flash:filename1
tftp-server flash:filename2
telephony-service
load 7960-7940 filename1
load 7970 filename2
max-ephones n
max-dn m
ip source-address 10.1.1.1 port 2000
auto assign 1 to n
url services http://10.1.2.1/ipics_server/servlet/IPPhoneManager
create cnf-files
max-conferences 8 gain -6
ephone-dn 1
number abcd
!
ephone-dn 2
number efgh
dual-line
dual-line
Text to Speech
Cisco IPICS provides an interface to the Nuance text to speech (TTS) server, which is available from
Nuance. This interface uses Media Resource Control Protocol (MRCP) to enable the Cisco IPICS dial
engine to pass text strings to the TTS server, which in turn converts the text to audio. The dial engine
then play the TTS audio to connected devices. This feature enables a more dynamic notification
environment than is possible by prerecorded audio prompts.
Cisco IPICS uses the following rules to determine how to play prompts:
1.
If a recorded prompt .wav file exists, it is played.
2.
If no recorded prompt exists and a TTS provider is configured and accessible, TTS is used.
3.
If no recorded prompt or TTS provider are available, the text is spelled out as the prompt. For
example, if the name of a channel is “chan1” but there is no recorded prompt or TTS provider, Cisco
IPICS might play this prompt: “Press 1 to select C H A N one.”
These rules apply to the standard Cisco IPICS capabilities for announcing resource names during dial-in
or dial-out call scenarios.
In addition, you can deploy custom scripts to use TTS prompts in a wide variety of scenarios. Custom
scripts are available through Cisco Advanced Services.
The following sections provide additional information about TTS:
•
Installing Nuance TTS, page 2-49
•
Configuring a Language Pack Other than en-US, page 2-50
•
TTS Configuration and Operation, page 2-51
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-48
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Text to Speech
Installing Nuance TTS
Cisco IPICS operates with a dedicated TTS server that runs on a Microsoft Windows platform. This
section describes how to install Nuance TTS (no ASR) and assume that the Cisco IPICS software is
already installed on the Cisco IPICS server.
Installation of Cisco IPICS is not required to install Nuance TTS.
Note
The default Nuance TTS installation contains licenses for TTS ports. If you need more licenses, obtain
them from your Nuance TTS vendor.
To install the Nuance TTS software, perform the following procedure on the dedicated TTS server. All
Nuance TTS components are available from Nuance.
Procedure
Step 1
Step 2
If there is Nuance software already installed on the server, take these actions:
a.
Uninstall the Nuance software.
b.
Delete the following directories, if they exist:
c.
C:/Nuance
d.
C:/Program Files/Nuance
e.
Reboot the server.
Follow the instructions that are provided with your Nuance software to install Nuance MRCP.
This process installs all Nuance TTS components except Vocalizer (TTS).
Step 3
Follow the instructions that are provided with your Nuance software to install the Nuance Vocalizer TTS
software.
Step 4
Follow the instructions that are provided with your Nuance software to install the English language pack
for TTS.
Step 5
Take these actions to configure TTS for use with Cisco IPICS.
a.
Modify the watcher.startup file in the C:\Nuance\V8.5.0\mrcp to add the tts.ResourceName
parameter for the vocalizer process.
For example, modify the existing line for Vocalizer from:
vocalizer -text_type SSML -config %MRCP%/nuance-resources.txt
lm.Addresses=localhost:8471
to:
vocalizer -text_type SSML tts.ResourceName=en-US-female -config
%MRCP%/nuance-resources.txt lm.Addresses=localhost:8471
b.
If you are using TTS in high load scenarios, make these modifications to the watcher.startup file:
– Use the num_channels parameter to allow for the maximum number of TTS ports that you are
provisioning for.
– Use the preallocate_licenses parameter to improve response time.
– Use the load_voices_in_memory parameter to load the complete voice pack in memory. Note:
This configuration increases process memory and initialization time.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-49
Chapter 2
Cisco IPICS Component Considerations
Text to Speech
– Use the pruning parameter with a value of 80 to reduce the CPU requirement for Vocalizer
process
For example, if you will use 50 TTS ports, modify this line:
vocalizer -text_type SSML tts.ResourceName=en-US-female -config
%MRCP%/nuance-resources.txt lm.Addresses=localhost:8471
to this line:
vocalizer -load_voices_in_memory -preallocate_licenses -num_channels 50 -pruning 80
-text_type SSML tts.ResourceName=en-US-female -config %MRCP%/nuance-resources.txt
lm.Addresses=localhost:8471
Step 6
Reboot the server.
Step 7
Take these actions to ensure that Nuance services and processes are operating:
a.
Open the Windows Services Control Panel and make sure that the Nuance Watcher Daemon service
is shown as Started.
The startup type typically is Automatic, so this service should be running.
b.
(Optional) Open a browser window and enter this URL: <http://<Speech Server Hostname>:7080>.
A session with the Nuance Watcher Daemon opens. The VP State for the following processes should
be shown as Ready. It can take approximately 1 minute for the processes to go to this state. Click
Update Home Page to display the current status of all the processes.
– watcher-daemon
– NLM
– Resource-Manager
– MRCP-Server
– Nutts-server
Step 8
(Optional) Install additional language packs for TTS.
Step 9
If you install a language pack other than en-US (US English), follow the instructions in the “Configuring
a Language Pack Other than en-US” section on page 2-50.
Configuring a Language Pack Other than en-US
If you install a language pack other than en-US, update the following parameters for the Vocalizer
process:
•
tts.ResourceName—For example, to use a Spanish female voice, set this value to es-US-female.
•
voice—For example, to use a Spanish female voice, set this value to atalinaromero. Table 2-4shows
the language pack names for various TTS voices.
Table 2-4
Language Packs for TTS Voices
Language Pack
Voice
North American English Female
Lauriewoods (default)
North American English Male
reedjohnston
U.K English Female
clairekingston
U.K English Male
Timcooper
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-50
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Text to Speech
Table 2-4
Language Packs for TTS Voices (continued)
Language Pack
Voice
Australian English Female
sarahbrown
Australian English Male
joshdonnelly
Canadian French Female
juliedeschamps
American Spanish Female
catalinaromero
Brazilian Portuguese Female
marinacosta
•
region—If you are using a Spanish voice, set this parameter either US or CALA, depending on the
region version that you want.
Example
The Vocalizer process for a Spanish Female voice could be set as follows:
vocalizer -text_type SSML tts.ResourceName=es-US-female -voice catalinaromero -region CALA
-config %MRCP%/nuance-resources.txt lm.Addresses=localhost:8471
The preceding example applies if you start only one language pack. If you start more than one language
pack at the same time, you must update the following parameters for each additional Vocalizer process:
•
tts.Port—The default value is 32323. This value must be changed for additional processes. Cisco
recommends that you increase this value by 1 for each additional process.
•
dictionary_port: The default value is 22552. This value must be changed for additional processes.
Cisco recommends that you increase this value by 1 for each additional process.
Example
A language pack for en-US female and es-US female that are to run simultaneously could be started as
follows:
vocalizer -text_type SSML tts.ResourceName=en-US-female -config
C:\Nuance\V8.5.0\mrcp/nuance-resources.txt lm.Addresses=localhost:8471
vocalizer tts.Port=32324 -dictionary_port 22553 -text_type SSML -voice catalinaromero
-region CALA tts.ResourceName=es-US-female -config
C:\Nuance\V8.5.0\mrcp/nuance-resources.txt lm.Addresses=localhost:8471
TTS Configuration and Operation
Table 2-5 describes some of the items in the Cisco IPICS options that should be configured when you
operate TTS. You configure these options in the TTS Management window, which you access from the
Cisco IPICS Administration Console by choosing Dial Engine > TTS Management from the Policy
Engine tab.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-51
Chapter 2
Cisco IPICS Component Considerations
Text to Speech
Table 2-5
Cisco IPICS Configuration Options for TTS
TTS Configuration Option
Explanation
Provider Name
The provider name for the supported version of Nuance Vocalizer is
Nuance Vocalizer 4.0.
Number of Licenses
This value should match the number of port licenses on the TTS
server.
Server Name
IP address or hostname of the TTS server.
Port
The default Nuance port number is 554.
Language
Language that TTS should use for its pronunciation rules.
Gender
Should match the gender that is configured on the TTS server.
To check the setting on the TTS server, go to the following URL,
where <TTS_server_IP> is the IP address of the TTS server, and
look at the nutts-server setting.
http://<TTS_server_IP>:7080/
For example, if the nutts-server setting is en_US and the gender is
Female, the gender setting for TTS in the IPICS Administration
Console must be Female.
In addition, choose Dial Engine > Dial Engine Parameters from the Policy Engine tab and, in the Dial
Engine Parameters window, check the TTS Enabled check box.
Table 2-6 describes expected results for a variety of common use cases when TTS is enabled.
Table 2-6
Common TTS Use Cases
Use Case
Expected Results
Designate users are called and hear the message
In the Cisco IPICS Administration Console,
choose Policy Management > Policies, click the played by the TTS server.
Action tab, choose a notification action, enter
enter a large message, and click Activate Policy.
A user calls the Cisco IPICS TUI, authenticates,
and selects a resource.
The resource (VTG, channel, or policy name) is
spoken by the TTS system.
TTS configuration is complete and saved and the The entry for the MRCP TTS subsystem in the
TTS server is reachable
Cisco IPICS Administration Console Dial Engine
> Control Center > Status screen should show
IN_SERVICE.
Note
The TTS subsystem pings the TTS server
periodically to determine if it is reachable.
Even if the TTS configuration is complete
but the TTS subsystem cannot reach the
TTS server, the TTS subsystem will be in
service.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-52
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Video Considerations
Table 2-6
Common TTS Use Cases (continued)
Use Case
Expected Results
The TTS server is manually brought down, then a The system should revert to spelling out names or
caller dials in or is sent a notification.
spelling out notifications. The Policy Engine tab >
Dial Engine > Control Center > Status window in
the Cisco IPICS Administration Console should
show that the TTS subsystem is down. If the TTS
server is brought down while a user is dialed in,
the user hears the prompt “Sorry the system is
having trouble.”
The TTS server is manually brought up then a
caller dials in or is sent a notification.
The system should revert to reading out names or
reading out notifications. The Policy Engine tab >
Dial Engine > Control Center > Status window in
the Cisco IPICS Administration Console should
show the TTS subsystem as up. If the TTS server
is brought up or down while a user is dialed in, the
user may hear the prompt “Sorry the system is
having trouble.”
Video Considerations
The IDC provides the ability to include video, photographs, and journals (text) in an incident VTG. In
addition, a Cisco IPICS dispatcher can include video from a video surveillance system in an incident
VTG and a first responder can capture video, take photographs, and enter text from a mobile client and
add these items to an incident VTG. These photographs and video files are stored on the IPICS server in
the /documents folder.
Using Video from Cisco Video Surveillance Manager
The IDC uses three video players to stream video from a Cisco Video Surveillance Manager (VSM)
system (and for all other video). The video players used are VLC Media Player, Windows Media Player
and Cisco Video Surveillance AX Client.
The order in which the media players are selected to play video are as follows:
1.
Cisco Video Surveillance Active X client
2.
Windows Media Player
3.
VLC Player
For versions of these media players that have been tested for compatibility with Cisco IPICS, refer to
Cisco IPICS Compatibility Matrix.
An IDC client PC must include each of these media players or the IDC cannot display video from the
Cisco IPICS server.
To display video from a Cisco VSM system, must create a link in the IDC to the video surveillance proxy
on the Cisco VSM server. To determine the VSM proxy link, follow these steps:
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-53
Chapter 2
Cisco IPICS Component Considerations
Video Considerations
Procedure
Step 1
Access the VSM Management Console for VSMS host that manages the cameras that provides the video
that you want, and take the following actions.
For information about accessing the Management Console, see the “Using the VSM Management
Console” chapter in Cisco Video Surveillance Manager User Guide.
Step 2
Click BWT Pages under Other Utilities near the bottom of the left panel in the Management Console
page.
Step 3
Click Proxy Commands in the left panel of the page that appears.
A list of proxy commands appears.
Step 4
Click All Running Proxies in the list of proxy commands.
A table of running proxies appears.
Step 5
Make a note of the proxy name for the camera feed that you want to include in the incident VTG.
Step 6
(Optional) Exit the Management Console.
After you determine the VSM proxy link, start the IDC, choose the incident VTG in which you want to
include the video, select the option to add media, and enter video using the proxy name that you
determined in the previous procedure.
After the proxy information in entered into an incident VTG, this can be enabled and disabled as needed.
It also can be used in other incident VTGs.
For information about using incident VTGs, refer to Cisco IPICS Dispatch Console User Guide.
Guidelines for Video
When including video in an incident, be aware of the following guidelines:
•
If you use a URL for a video that starts with bwims://, the ActiveX player from the VSM server is
used to play the video on the IDC. The iPhone cannot play this video because it cannot interpret the
URL.
•
To view video on an iPhone, use an MJPEG video URL that starts with http://.
•
The IDC supports any video format that Windows Media Player and VLC Player support. For
limitations of various protocols, refer to Cisco IPICS Dispatch Console User Guide.
•
If want to stream video from Cisco VSM to an iPhone, you must use the secondary stream when
configuring the video stream in VSM. (For instructions, refer to Cisco Video Surveillance Manager
User Guide.) After you configure a secondary stream in VSM, all the secondary streaming video
appears with a “_2” at the end of the proxy when you display proxies as described in the “Using
Video from Cisco Video Surveillance Manager” section on page 2-53. When adding video in the
IDC that is intended to display on an iPhone, it is a best practice to give the video a name that clearly
indicates that the stream is meant for viewing on an iPhone.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-54
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Notification
•
The follow video streaming configuration is supported on an iPhone:
– Protocol—MJPEG
– Resolution—CIF (352 × 288)
– Frame rate—Up to 5 fps
– Streaming—Suggested Up to 10 minutes continuous
If you exceed these rates or use a different protocol, the mobile client displays a question mark (?)
in the area where you expect the video to appear. The video displays on the IDC if the media players
can support those formats.
•
In Cisco IPICS 4.0.1, the maximum size of media files that can be uploaded to the IPICS Server by
using the IDC is 4 MB. In Cisco IPICS 4.0.2, the maximum size of media files is configurable up to
2,048 MB (the default value is 4 MB).
•
There are no restrictions on the URL that can be attached to an incident. The Cisco IPICS server
does not verify the URL and every URL that is entered is considered valid. Take care to ensure
accuracy when entering a URL.
•
When high availability (HA) is implemented in a Cisco IPICS deployment, media files that are
stored on the active service must be synchronized with the standby server. As a best practice in an
HA implementation, create and use URL links to the proxy from a Cisco CSM system whenever
possible instead of uploading video files of different formats. This approach helps conserve
bandwidth on the network between the active and standby servers. It also helps conserve storage
space on the Cisco IPICS server.
Notification
Notification is the process of Cisco IPICS contacting designated recipients and provide them with
information that you specify. Cisco IPICS offers the following notification implementations:
•
Policy engine notification—Controlled through the Cisco IPICS Administration Console and can
provide notification to recipients that are configured in Cisco IPICS. You designate the way in which
notification is provided by configuring notification actions. Policy engine notifications include
e-mail, IP phone text, dial, talk group, and dial engine script notifications.
•
External (Bulk) notification—Administered outside of the Cisco IPICS Administration Console.
The recipient list and prompts are passed to Cisco IPICS by a third-party application.
Cisco IPICS supports multiple Cisco Unified Communications Managers for notification, which enables
text and audio paging to Cisco Unified IP Phone devices that are registered on different Cisco Unified
Communications Managers.
The following sections describe following policy engine notification actions that you can configure for
Cisco IPICS:
•
Email Notification Action, page 2-56
•
IP Phone Text Notification Action, page 2-56
•
Dial Notification Action, page 2-57
•
Talk Group Notification Action, page 2-57
•
Dial Engine Script Notification, page 2-58
•
Alert Notification Action, page 2-58
•
External (Bulk) Notification, page 2-58
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-55
Chapter 2
Cisco IPICS Component Considerations
Notification
Email Notification Action
An Email notification action sends a message that you enter to the e-mail, SMS, and pager addresses that
are configured as notification preferences for each user that you designate as a recipient. When this type
of notification executes, the policy engine sends the message via SMTP to the SMTP server that is
configured on the IPICS Dial Engine Parameters screen. Email notification recipients can be Cisco
IPICS users or user groups.
IP Phone Text Notification Action
An IP phone text notification action displays a designated message on supported Cisco Unified IP Phone
models. The telephone numbers of each phone must be configured as a dial preference for the associated
user. This type of notification action requires that you use the Cisco IPICS Administration Console to
configure parameters in the Cisco Unified Communications Manager Configuration for IP Phone
Notifications area in the SIP Configuration menu. For instructions, see Cisco IPICS Server
Administration Guide. Recipients of this notification action can be Cisco IPICS users or user groups.
When an IP phone text notification action executes, several activities, including the following, occur:
1.
IPICS sends an AXL query to the first configured Cisco Unified Communications Manager.
2.
Cisco Unified Communications Manager returns the IP address of each device for which a DN is
configured.
3.
Cisco IPICS sends notification via XML to each device for which it receives a valid IP address.
Notes:
•
The IP phone text notification action requires that the IP phone text notification parameters be
configured on the SIP configuration page in the Cisco IPICS Administration Console.
•
Cisco IPICS sends each DN in the notification list as a query to each Cisco Unified Communications
Manager that is configured for notification.
•
The Cisco Unified Communications Manager must be running the Cisco AXL service.
•
Each Cisco Unified Communications Manager must be configured in the IP Phone Notification
Configuration page with the correct version number, administrator and phone user name and
password. This information is required validate Cisco Unified Communications Manager and send
appropriate AXL queries because the queries are different for various Cisco Unified
Communications Manager versions.
•
The configured Cisco Unified Communications Managers must be reachable or “Connection
Failure” errors result when the Cisco IPICS attempts to send and AXL query.
•
The Cisco Unified Communications Manager should be configured to accept SOAP requests.
•
Cisco Unified Communications Manager limits the number of DNs in an AXL query to 200. It
truncates requests that contain more than 200 DNs. To accommodate this limit, Cisco IPICS sends
requests that contain no more than 200 DNs. If Cisco IPICS needs more than 200 DNs, it send
requests in batches that contain 200 or fewer DN requests.
•
Cisco IPICS precedes a text notification with an audible tone, which comes from a prerecorded .wav
file that is sent to each phone in the recipient list. Cisco IPICS requires that an available multicast
address be configure in the multicast address pool for each batch of simultaneous broadcasts of the
alert audio.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-56
OL-24067-01
Chapter 2
Cisco IPICS Component Considerations
Notification
•
If Cisco IPICS cannot reach a Cisco Unified IP Phone or if notification to a phone fails, Cisco IPICS
adds the phone to a retry list. When Cisco IPICS completes a round of notification to identified
phones, it attempts to resend the notification to the phones in the retry list. Cisco IPICS will attempt
notification up to three times (one regular notification attempt and up to two retry notification
attempts). Any phones that it cannot reach after these attempts are not notified via IP phone text
notification.
•
Cisco IPICS an AXL query to all Cisco Unified Communications Managers in a cluster. If more than
one Cisco Unified Communications Manager is configured with phones that register to the same
DN, all the phones associated to that DN are notified.
Dial Notification Action
The policy engine executes a dial notification action as follows:
•
If the Cisco Unified Communications Manager Configuration for IP Phone Notifications parameters
are configured in the SIP Configuration menu, the Cisco IPICS checks whether each designated user
has an associated Cisco Unified IP Phone configured in Cisco Unified Communications Manager. If
a user does have an associated phone, Cisco IPICS plays the designated message on the speaker of
the phone.
•
If Cisco Unified Communications Manager Configuration for IP Phone Notifications parameters are
configured but a user does not have an associated Cisco Unified IP Phone, or if the phone of a user
is busy, the system calls the user as specified in the dial preferences and plays the designated
message.
•
If Cisco Unified Communications Manager Configuration for IP Phone Notifications parameters are
not configured, the Cisco IPICS calls the user as specified in the dial preferences and plays the
designated message.
When you create a dial notification action, you can specify a pre-recorded prompt or record a new
prompt. A prompt should be no more than 90 seconds long.
If you use this action to contact Cisco Unified IP Phones, make sure that at least one multicast address
is available in the multicast pool.
For more detailed information, see Cisco IPICS Server Administration Guide.
Talk Group Notification Action
A talk group notification action plays the selected prompt to all participants in the selected VTG.
When you create a talk group notification action, you can specify a pre-recorded prompt or record a new
prompt. A prompt should be no more than 90 seconds long.
Note
•
When a Talk Group notification executes, the designated message is added to the multicast stream
of the VTG. To inform users that a system message is being played, consider starting the message
with a statement such as, “This is the Cisco IPICS administrator with an important recorded
message.”
•
A VTG participant who is dialed in through the TUI and who has the floor does not hear the talk
group notification message.
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
OL-24067-01
2-57
Chapter 2
Cisco IPICS Component Considerations
Notification
Dial Engine Script Notification
A dial engine script notification action executes the designated dial engine script once for each
designated recipient.
Alert Notification Action
An alert notification action sends an alert message to the IDC and mobile client of each user who is
associated with the policy and show has executed the policy from the IDC. The alert message appears in
a pop-up window on the IDC and mobile client. A subsequent notification is not displayed until the
existing notification is acknowledged.
External (Bulk) Notification
This section provides notes that apply to external (bulk) notification. For more detailed information
about this functionality, see Cisco IPICS Server Administration Guide.
•
To debug the Bulk notification without pushing out the XML to the phones add the parameter
“notificationMode=mute” to the external notification HTTP request.
•
Cisco IPICS now periodically stores the results of calls that it makes when an external notification
executes. These results are stored as XML files, which are purged after 30 days by default.
The purge time is based on a cron entry that is made for the ipicsadmin user. This cron entry purges
all notification result XML files that are older than 30 days, by default. You can change the purge
interval as follows:
#--- Purge notification result xml files older than 30 days daily @ 04:00
0 4 * * * find /opt/cisco/ippe/temp/notificationIncidentXmlResults/* -mtime +30 |
xargs rm -fR 2>&1
•
The stopNotification method can be used to terminate a running capId. Always verify that the capId
status is not running before restarting a bulk notification request that uses the same CapId.
http://“ + ipicsServer + ”:8080/ipics_server/
BulkNotify?method=stopNotification&capId=<CAP_ID>
Solution Reference Network Design (SRND) for Cisco IPICS Release 4.0(2)
2-58
OL-24067-01