View
1.927
Download
0
Embed Size (px)
DESCRIPTION
Citation preview
Solution Reference NeOL-12996-03
C H A P T E R 2
Cisco IPICS Component ConsiderationsThis chapter provides information about various components that can be part of a Cisco IPICS solution. This information will help you to understand how these components 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
• Cisco Unified IP Phones, page 2-41
Router Media ServiceThe 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-1
• 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 PMC 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 2.1(1).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.
RMS OverviewThe 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
2-1twork Design (SRND) for Cisco IPICS Release 2.1(1)
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
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 2.1(1).) 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 a PMC from the remote location—When a remote PMC connection is started, the PMC 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 PMC user. The PMC 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 PMC user activates a channel or VTG, the PMC 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.
RMS Components for LocationsAn 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 2.1(1) if you have more than one RMS configured in the server.
The following information applies to locations:
• 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.
2-2Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
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 voipdescription #0/2/0:3#1164200525742# INUSE 284destination-pattern 90929093voice-class permanent 1session protocol multicastsession target ipv4:239.192.21.79:21000codec g711ulawno vad
voice-port 0/2/0:3voice-class permanent 1
2-3Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100no comfort-noisetimeouts call-disconnect 3timeouts teardown lmr infinitytiming hookflash-in 0timing hangover 40connection trunk 90929093description #0/2/0:3#1164200525742# INUSE 284
voice-port 0/2/1:3voice-class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100no comfort-noisetimeouts call-disconnect 3timeouts teardown lmr infinitytiming hookflash-in 0timing hangover 40connection trunk 90929193description #0/2/1:3#1164200525742# INUSE 284
dial-peer voice 90929193 voipdescription #0/2/1:3#1164200525742# INUSE 284destination-pattern 90929193voice-class permanent 1session protocol multicastsession target ipv4:239.192.21.64:21000codec 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 voipdescription #0/2/0:4#1164200525776# INUSE 285destination-pattern 90929094voice-class permanent 1session protocol multicastsession target ipv4:239.192.21.79:21000codec g711ulawno vad
voice-port 0/2/0:4voice-class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100no comfort-noisetimeouts call-disconnect 3timeouts teardown lmr infinitytiming hookflash-in 0timing hangover 40connection trunk 90929094description #0/2/0:4#1164200525776# INUSE 285
2-4Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
voice-port 0/2/1:4voice-class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100no comfort-noisetimeouts call-disconnect 3timeouts teardown lmr infinitytiming hookflash-in 0timing hangover 40connection trunk 90929194description #0/2/1:4#1164200525776# INUSE 285
dial-peer voice 90929194 voipdescription #0/2/1:4#1164200525776# INUSE 285destination-pattern 90929194voice-class permanent 1session protocol multicastsession target ipv4:239.192.21.65:21000codec g711ulawno vad
The following Cisco IOS configuration outputs shows the RMS configuration in the Cisco IPICS server to support a PMC user who is assigned both the Police and Fire channels connecting by using the remote location. This configuration allows the PMC to communicate with RMS by using a unicast connection. The RMS forwards the unicast stream, which is received from the PMC, 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 PMC device as a unicast stream.
This Cisco IOS configuration output pertains to the Police channel:
dial-peer voice 909290914 voipdescription #0/2/0:14#1164659525783# INUSE 295destination-pattern 909290914voice-class permanent 1session protocol multicastsession target ipv4:239.192.21.64:21000codec g711ulawno vad
voice-port 0/2/0:14voice-class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100no comfort-noisetimeouts call-disconnect 3timeouts teardown lmr infinitytiming hookflash-in 0timing hangover 40connection trunk 909290914
voice-port 0/2/1:14voice-class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100
2-5Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
no comfort-noisetimeouts call-disconnect 3timeouts teardown lmr infinitytiming hookflash-in 0timing hangover 40description #0/2/1:14#1164659525783# INUSE 295
dial-peer voice 909291914 potsdescription #0/2/1:14#1164659525783# INUSE 295destination-pattern 1990000275909291914port 0/2/1:14
This Cisco IOS configuration output pertains to the Fire channel:
dial-peer voice 909290915 voipdescription #0/2/0:15#1164659525833# INUSE 296destination-pattern 909290915voice-class permanent 1session protocol multicastsession target ipv4:239.192.21.65:21000codec g711ulawno vad
voice-port 0/2/0:15voice-class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100no comfort-noisetimeouts call-disconnect 3timeouts teardown lmr infinitytiming hookflash-in 0timing hangover 40connection trunk 909290915description #0/2/0:15#1164659525833# INUSE 296
voice-port 0/2/1:15voice-class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100no comfort-noisetimeouts call-disconnect 3timeouts teardown lmr infinitytiming hookflash-in 0timing hangover 40description #0/2/1:15#1164659525833# INUSE 296
dial-peer voice 909291915 potsdescription #0/2/1:15#1164659525833# INUSE 296destination-pattern 1990000275909291915port 0/2/1:15
2-6Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
When is an RMS Required?Cisco IPICS requires an RMS to establish connectivity between unicast and multicast endpoints (such as remote PMC to channel, remote PMC 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
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.
IP
IP Multicast-Enabled Network
R2R1
1805
46
User: User BChannel: Metro Police
239.192.21.64PMC User: User A
Channel: Metro Police239.192.21.64
Cisco IPICSServer
2-7Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Figure 2-2 Single Cisco IPICS Channel with LMR Gateway
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
IPIP Multicast-
Enabled Network
R2
R3
R1
1805
48
User: User BChannel: Metro Police
239.192.21.64
PMC User: User AChannel: Metro Police
239.192.21.64
Cisco IPICSServer
E&MLMR 1239.192.21.64Metro Police
IP
IP Multicast-Enabled Network
R2
R3
R118
0550
User: User BChannel: Metro Police
239.192.21.64
User: User DChannel: Metro Fire239.192.21.64
PMC User: User AChannel: Metro Police
239.192.21.64
PMC User: User CChannel: Metro Fire
239.192.21.65
Cisco IPICSServer
E&MLMR 1239.192.21.64Metro Police
E&MLMR 2239.192.21.65
Metro Fire
IP
Group 2 Metro FireChannel 239.192.21.65PMC 3, PMC 4, LMR/Hootie 2
Group 1 Metro PoliceChannel 239.192.21.64PMC 1, PMC 2, LMR/Hootie 1
2-8Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Allocation of RMS DS0 ResourcesYou 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 PMC 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 PMC 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 a PMC successfully authenticates by using the Remote location, the RMS allocates a DS0 pair to each channel or VTG that is assigned to that authenticated PMC user. (See the “Remote PMC Users” section on page 2-24 for related information.)
Table 2-1 illustrates the various scenarios in which RMS resources are allocated
For detailed current 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 2.1(1).
Table 2-1 RMS Resource Allocation
ScenarioMulticast 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 PMC No 1 per assigned channel or VTG
2-9Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter 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:
• 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.
Note 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 EngineWhen 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.
2-10Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter 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 GroupsA 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.
2-11Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Figure 2-4 VTG Channel Mixing
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
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 Police239.192.21.79 239.192.21.64
T1 0/0:14 --------------T1 0/1:14 VTG Combined San Jose Fire239.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:
Channel 2
Channel 2
VTG
VTG
Channel 1
Channel 1
Channel 1
Channel 2
VTG
RMS
RMS
RMS
Channel 1Police239.192.21.64
Channel 2Fire239.192.21.65
VTGCombined239.192.21.79
1805
52
T1 0/0DS0
DS1
DS23
T1 0/1DS0
DS1
DS23... ...
T1 Loopback CablePinouts
1-42-54-15-2
T1 0/0
T1 0/1
NM-HDV or NM-HDV2-2T1-E1
VWIC2MFT-T1
1805
53
2-12Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter 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
The following example shows configurations for this scenario:
dial-peer voice 90929090 voipdescription #0/0:10#1152296144646# INUSE 16destination-pattern 90929090voice class permanent 1session protocol multicastsession target ipv4:239.192.21.79:21000codec g711ulawno vad
!dial-peer voice 90929190 voipdescription #0/1:10#1152296144646# INUSE 16destination-pattern 90929190voice class permanent 1session protocol multicastsession target ipv4:239.192.21.65:21000codec g711ulawno vad
!dial-peer voice 90929092 voipdescription #0/0:14#1152296144696# INUSE 18destination-pattern 90929092voice class permanent 1session protocol multicastsession target ipv4:239.192.21.79:21000codec g711ulawno vad
!dial-peer voice 90929192 voipdescription #0/1:14#1152296144696# INUSE 18
RMSCisco IPICS
Server
1805
54
Login (SSH)
Authentication and Authorization
Configuration Management
Reporting
Update Push and Verify
2-13Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
destination-pattern 90929192voice class permanent 1session protocol multicastsession target ipv4:239.192.21.64:21000codec g711ulawno vad
!voice-port 0/0:10voice class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100no comfort-noisetimeouts call-disconnect 3timing hookflash-in 0timing hangover 40connection trunk 90929090description #0/0:10#1152296144646# INUSE 16
!voice-port 0/0:14voice class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100no comfort-noisetimeouts call-disconnect 3timeouts teardown lmr infinitytiming hookflash-in 0timing hangover 40connection trunk 90929092description #0/0:14#1152296144696# INUSE 18
!voice-port 0/1:10voice class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100no comfort-noisetimeouts call-disconnect 3timing hookflash-in 0timing hangover 40connection trunk 90929190description #0/1:10#1152296144646# INUSE 16 !
voice-port 0/0:14voice class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100no comfort-noisetimeouts call-disconnect 3timeouts teardown lmr infinitytiming hookflash-in 0timing hangover 40connection trunk 90929192description #0/1:14#1152296144696# INUSE 18
2-14Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter 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
Table 2-2 shows an example of how mixing works in a VTG that has four active users on a channel.
1
2
3
4...n
IOSArbitrationAlgorithm
DSPMulticast
VoiceStreams
1805
55
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.
2-15Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
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 PMCs 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.
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.
Table 2-2 Mixing Example
Event Remarks
2-16Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Figure 2-8 Multicast Group Membership
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.
IP
IP
IP Multicast-Enabled Network
R2Joined 79
R1Joined 65, 79
Joined 64, 65, 79
R3Joined 64, 79
1805
56
User: User BChannel: Combined
239.192.21.79
PMC User: User AChannel: Combined
239.192.21.79
PMC User: User CChannel: Combined
239.192.21.79
User: User DChannel: Combined
239.192.21.79
Cisco IPICSServer
E&MLMR 1239.192.21.64
Police
E&MLMR 2239.192.21.65
Fire
RMS
2-17Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Figure 2-9 Transmitting to the VTG Channel
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.
IP
IP
IP Multicast-Enabled Network
R2Joined 79
R1Joined 65, 79
Joined 64, 65, 79
R3Joined 64, 79
1805
57
User: User BChannel: Combined
239.192.21.79
PMC User: User AChannel: Combined
239.192.21.79
PMC User: User CChannel: Combined
239.192.21.79
User: User DChannel: Combined
239.192.21.79
Cisco IPICSServer
E&MLMR 1239.192.21.64
Police
E&MLMR 2239.192.21.65
Fire
79
79 79 79
7979
79
79
RMS
2-18Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Figure 2-10 Transmitting VTG Channel to Police and Fire Channels
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.
IP
IP
IP Multicast-Enabled Network
R2Joined 79
R1Joined 65, 79
Joined 64, 65, 79
R3Joined 64, 79
1805
58
User: User BChannel: Combined
239.192.21.79
PMC User: User AChannel: Combined
239.192.21.79
PMC User: User CChannel: Combined
239.192.21.79
User: User DChannel: Combined
239.192.21.79
Cisco IPICSServer
E&MLMR 1239.192.21.64
Police
E&MLMR 2239.192.21.65
Fire
64
64
64
65
6565
RMS
2-19Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Figure 2-11 LMR Multicast Traffic Flow
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
79
7979
IP
IP
IP Multicast-Enabled Network
R2Joined 79
R1Joined 65, 79
Joined 64, 65, 79
R3Joined 64, 79
1805
59
User: User BChannel: Combined
239.192.21.79
PMC User: User AChannel: Combined
239.192.21.79
PMC User: User CChannel: Combined
239.192.21.79
User: User DChannel: Combined
239.192.21.79
Cisco IPICSServer
E&MLMR 1239.192.21.64
Police
E&MLMR 2239.192.21.65
Fire
64
64
6479
79
79
65
79
79
6565
RMS
79
79
79
IP
IP
IP Multicast-Enabled Network
R2Joined 65, 79
R1Joined 65, 79
Joined 64, 65, 79
R3Joined 64, 79
1805
60
User: User BChannel: Combined
239.192.21.79
PMC User: User AChannel: Combined
239.192.21.79
PMC User: User CChannel: Combined and Fire
239.192.21.65 and 79
User: User DChannel: Combined
239.192.21.79
Cisco IPICSServer
E&MLMR 1239.192.21.64
Police
E&MLMR 2239.192.21.65
Fire
64
64
6479
79
79
65
79
79
65 65 6565
Receives packetstwice
RMS
2-20Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter 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
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 PMC 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 PMCs 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.
IP
IP
IP Multicast-Enabled Network
R2R1
PMC User: User CChannel: Bonds239.192.21.65
User: User DChannel: Bonds239.192.21.65
1805
61
User: User BChannel: Stocks239.192.21.64
PMC User: User AChannel: Stocks239.192.21.64
Cisco IPICSServer
Finance Organization2 divisions: Stocks, Bonds2 channels: Stocks, BondsStocks can talk with each otherBonds can talk with each other
R3
2-21Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Figure 2-14 VTG with Users Only
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 PMCs 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.
IP
IP
IP Multicast-Enabled Network
R2R1
PMC User: User CChannel: Combined
239.192.21.79
User: User DChannel: Combined
239.192.21.79
1805
62
User: User BChannel: Combined
239.192.21.79PMC User: User A
Channel: Combined239.192.21.79
Cisco IPICSServer
If stocks and bonds users need totalk with each other, simply create another channel (Combined) withall users in this channel. There is no need for a VTG or an RMS.Or create a VTG that contains onlyusers (RMS resources are not neededunless a user is remote).
R3
2-22Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Figure 2-15 Restricting VTG Access
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 PMCs 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.
Figure 2-16 Combined VTG with a User Omitted
IP
IP
IP Multicast-Enabled Network
R2R1
PMC User: User CChannel: Bonds239.192.21.65
User: User DChannel: Combined
239.192.21.79
1805
63
User: User BChannel: Combined
239.192.21.79PMC User: User A
Channel: Combined239.192.21.79
Cisco IPICSServer
Assume that everyone needs to tallkexcept User C.Solution 1: Do not put this userin the combined channel.Solution 2: Do not put this userin the combined VTG (there arealso no channels in the VTG)
R3
IP
IP
IP Multicast-Enabled Network
R2R1
PMC User: User CChannel: Bonds239.192.21.65
User: User DChannel: Combined
239.192.21.79
1805
64
User: User BChannel: Combined
239.192.21.79PMC User: User A
Channel: Combined239.192.21.79
Cisco IPICSServer
In the Combined VTG with the Stocks channel, the Bonds channel,and all users except User C, User Ccan still particpate in the VTG.
R3
79
79
79
79
79
79
79 65
65
65
Joined65, 79
RMS
2-23Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Remote PMC UsersPMC 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. A PMC user that is logged into Cisco IPICS in this way is sometimes called a remote PMC user. Examples of such users include those using a satellite connection or those connecting the network through a VPN.
Figure 2-17 Remote PMC User
A remote PMC user cannot connect to the Cisco IPICS domain by using multicast. Instead, the remote PMC 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 PMC user activated. After the remote PMC 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.
IP Multicast-Enabled Network
IP UnicastNetwork
PMCRemote
PMC239.192.21.64
RMS
Cisco IPICSServer
LoginLocation = REMOTE HTTPS
1805
65
2-24Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Figure 2-18 Timeslot Allocation
Assume that the Cisco IPICS server allocates timeslot 20 for the remote PMC user. In this case, the Cisco IPICS server configures the voice ports and dial peers as follows:
Multicast Side—239.192.21.64voice-port 0/0/0:20voice class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100no comfort-noisetimeouts call-disconnect 3timing hookflash-in 0
timing hangover 40connection trunk 909090920description #0/0/0:20#1123534375842# INUSE 92
dial-peer voice 909090920 voipdescription #0/0/0:20#1123534375842# INUSE 92destination-pattern 909090920voice class permanent 1session protocol multicastsession target ipv4:239.192.21.64:21000codec g711ulawno vad
Unicast Side—239.192.21.64voice-port 0/0/1:20voice class permanent 1auto-cut-throughlmr m-lead audio-gate-inlmr e-lead voiceno echo-cancel enableplayout-delay maximum 100
no comfort-noisetimeouts call-disconnect 3timing hookflash-in 0
IP Multicast-Enabled Network
IP UnicastNetwork
PMCRemote
PMC239.192.21.64
RMS
Cisco IPICSServer
1805
66
One side is a multicast VoIP dial peer,the other side is a POTS dial peer
After login, Cisco IPICS serverallocates a DS0 pair for each
associated channel
2-25Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
timing hangover 40description #0/0/1:20#1123534375842# INUSE 92
dial-peer voice 909091920 potsdescription #0/0/1:20#1123534375842# INUSE 92destination-pattern 8880000081909091920port 0/0/1:20
After the Cisco IPICS server configures the voice ports and the dial peers, it sends to the remote PMC 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
When a channel is activated by a remote PMC user, the remote PMC uses SIP to set up the unicast call. After the SIP call is established, the remote PMC 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”
IP Multicast-Enabled Network
IP UnicastNetwork
PMCRemote
PMC239.192.21.64
RMS
Cisco IPICSServer
1805
67
Server sends RMS addressand POTS number
2-26Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Figure 2-20 Unicast Connection Set Up
Figure 2-21 SIP Signaling Flow
IP Multicast-Enabled Network
IP UnicastNetwork
PMCRemote
PMC239.192.21.64
RMS
Cisco IPICSServer
1805
68
PMC uses SIPfor call setup
RMS PMC Remote
INVITE
TRYING
SESSION PROGRESS
OK
ACK
1805
69
2-27Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsRouter Media Service
Figure 2-22 Unicast to Multicast Call Flow
Figure 2-23 Multicast to Unicast Call Flow
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 PMCs 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 2.1(1).
IP Multicast-Enabled Network
IP UnicastNetwork
PMCRemote
PMC239.192.21.64
RMS
Cisco IPICSServer
1805
70
In: Unicast toPOTS number/loopback
Out:Multicast
If a remote PMC has several channels,a DS0 Pair with a corresponding POTSnumber is configured for each channel.
In:Multicast
IP Multicast-Enabled Network
IP UnicastNetwork
PMCRemote
PMC239.192.21.64
RMS
Cisco IPICSServer
1805
71
Out:Unicast
2-28Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsIntegrating Cisco IPICS with SIP Providers
Integrating Cisco IPICS with SIP ProvidersThe Cisco IPICS dial engine requires a SIP provider to place or receive calls. The dial engine has been tested with these SIP providers:
• Cisco Unified Communications Manager release 5.1(2b)
• Cisco Unified Communications Manager 4.1(3) with a router running a supported Cisco IOS release
Although other Cisco Unified Communications Manager releases have not been tested, the release of Cisco Unified Communications Manager that is used when the SIP provider is a Cisco router is not relevant if you can place VoIP calls between the Cisco Unified Communications Manager and the router that is being used as a SIP provider.
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
• PMC direct dial calls go from the PMC 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 2.1(1) 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-30
• When is a PMC Direct Dial prefix needed?, page 2-38
• Connectivity to Cisco Unified Communications Manager Releases that do not Provide Native SIP Trunk Support, page 2-38
Requirements for SIP SessionsCisco 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.
2-29Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsIntegrating Cisco IPICS with SIP Providers
• 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 ScenariosYou 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 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 2.1(1). 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 2.1(1).
Note If your deployment uses a Cisco IOS SIP gateway as the SIP provider and you are using Cisco Unified Communications Manager 4.1, the Cisco IOS SIP gateway will also have dial peer 557 configured as an outgoing dial peer to reach Cisco Unified Communications Manager. See the Connectivity to Cisco Unified Communications Manager Releases that do not Provide Native SIP Trunk Support, page 2-38
Dial Peer Use in Scenarios
The following figures describe which dial peers are used in different scenarios:
• Figure 2-24 on page 2-31, “Calls to Policy Engine in Deployment that Uses Cisco Unified Communications Manager 5.1(2b)”
• Figure 2-25 on page 2-31, “Calls to Policy Engine in Deployment that Uses Cisco Unified Communications Manager 4.1(2)”
• Figure 2-26 on page 2-31, “Calls from Policy Engine in Deployment that Uses Cisco Unified Communications Manager 5.1(2b)”
• Figure 2-27 on page 2-32, “Calls from Policy Engine in Deployment that Uses Cisco Unified Communications Manager 4.1(2)”
• Figure 2-28 on page 2-32, “PMC Direct Dial Calls in Deployment that Uses Cisco Unified Communications Manager 5.1(2b)”
• Figure 2-29 on page 2-32, “PMC Direct Dial Calls in Deployment that Uses Cisco Unified Communications Manager 4.1(2), RMS and Cisco IOS SIP Gateway on Separate Routers”
• Figure 2-30 on page 2-33, “PMC Direct Dial Calls in Deployment that Uses Cisco Unified Communications Manager 4.1(2), RMS and Cisco IOS SIP Gateway on the Same Router”
2-30Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsIntegrating Cisco IPICS with SIP Providers
Figure 2-24 Calls to Policy Engine in Deployment that Uses Cisco Unified Communications
Manager 5.1(2b)
Figure 2-25 Calls to Policy Engine in Deployment that Uses Cisco Unified Communications
Manager 4.1(2)
Figure 2-26 Calls from Policy Engine in Deployment that Uses Cisco Unified Communications
Manager 5.1(2b)
V
Cisco UnifiedCommunicationsManager 5.0(4a)
PSTN
SIP TrunkNo Dial Peers
Cisco IPICSServer
1852
39
V
Cisco UnifiedCommunicationsManager 4.1(2)
PSTN
Cisco IPICSServer
Cisco IOS SIPGateway
1852
40
V555 In
554 Out
V
Cisco UnifiedCommunicationsManager 5.0(4a)
PSTN
SIP TrunkNo Dial Peers
Cisco IPICSServer
1852
41
2-31Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsIntegrating Cisco IPICS with SIP Providers
Figure 2-27 Calls from Policy Engine in Deployment that Uses Cisco Unified Communications
Manager 4.1(2)
Figure 2-28 PMC Direct Dial Calls in Deployment that Uses Cisco Unified Communications
Manager 5.1(2b)
Figure 2-29 PMC Direct Dial Calls in Deployment that Uses Cisco Unified Communications
Manager 4.1(2), RMS and Cisco IOS SIP Gateway on Separate Routers
V
Cisco UnifiedCommunicationsManager 4.1(2)
PSTN
Cisco IPICSServer
Cisco IOS SIPGateway
1852
42
V555 In
557 Out
V
Cisco UnifiedCommunicationsManager 5.0(4a)
PSTN
RMS
1852
43V
555 In556 OutPMC
V
Cisco UnifiedCommunicationsManager 4.1(2)
PSTN
RMS
1852
44
V555 In
556 Out
Cisco IOS SIPGateway
V555 In
557 OutPMC
2-32Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsIntegrating Cisco IPICS with SIP Providers
Figure 2-30 PMC Direct Dial Calls in Deployment that Uses Cisco Unified Communications
Manager 4.1(2), RMS and Cisco IOS SIP Gateway on the Same Router
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-33
• Scenario 2: Policy Engine <-> SIP <-> Cisco IOS SIP Gateway, with no Cisco Unified Communications Manager or Cisco Unified Communications Manager Express, page 2-34
• Scenario 3: Policy Engine <-> SIP <-> Cisco IOS SIP Gateway, Cisco Unified Communications Manager without Native SIP Trunk Support, RMS Functionality on the Cisco IOS SIP Gateway, page 2-35
• Scenario 4: Policy Engine <-> SIP <-> Cisco IOS SIP Gateway, Cisco Unified Communications Manager without Native SIP Trunk Support, RMS Functionality Not on the Cisco IOS SIP Gateway, page 2-36
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 PMC direct dial feature.
Figure 2-31 illustrates this scenario.
V
Cisco UnifiedCommunicationsManager 4.1(2)
PSTN 1852
45
RMS+ Cisco IOS SIPGateway
V555 In
557 OutPMC
2-33Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsIntegrating Cisco IPICS with SIP Providers
Figure 2-31 Calls in Deployment that Uses Cisco Unified Communications Manager 5.1(2b)
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 PMC connections and PMC direct dial calls. These calls will match on incoming dial peer 555. The PMC 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 4.1(2) are modified to reflect the desired dial patterns and destinations.
V
Cisco UnifiedCommunicationsManager 5.0(4a)
Voice Gateway toPSTN 18
5246
RMS
V
Cisco IPICSServer
SIP Trunk forPolicy Engine
SIP Trunk forPMC Direct Dial
2-34Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsIntegrating Cisco IPICS with SIP Providers
Scenario 3: Policy Engine <-> SIP <-> Cisco IOS SIP Gateway, Cisco Unified Communications Manager without Native SIP Trunk Support, RMS Functionality on the Cisco IOS SIP Gateway
This scenario uses the Cisco IOS SIP gateway as the SIP provider for the Cisco IPICS dial engine and for the RMS. In this example, the dial plan requires custom dial peer configuration to support the desired routing. In this case, the default dial peers (554, 556, and 557) are not used.
Figure 2-32 illustrates this scenario.
Figure 2-32 Calls in Deployment that Uses Cisco IOS SIP Gateway and Cisco Unified
Communications Manager without Native SIP Trunk Support, RMS Functionality on
the Cisco IOS SIP Gateway
The example dial peer configuration in this scenario assumes the following:
• Phones that are connected to Cisco Unified Communications Manager have five-digit extensions, some of which start with 2 but none of which start with 251.
• Outbound calls to the PSTN and to other Cisco Unified Communications Manager servers are routed on the Cisco Unified Communications Manager 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:
• PMC remote (incoming dial peer 555)
• Calls from Cisco Unified Communications Manager (incoming dial peer 555, outgoing dial peer 25100)
• SIP calls from the dial engine through the Cisco IOS SIP gateway to Cisco Unified Communications Manager (incoming dial peer 555, outgoing dial peers 25100.8000 and 9000)
• PMC direct dial through the RMS to Cisco Unified Communications Manager (incoming dial peer 555, outgoing dial peers 25000.8000 and 9000)
RMS/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
V
Cisco UnifiedCommunicationsManager 4.1(2)
Voice Gateway toPSTN
1822
24
V
SIP Trunk forPolicy EngineDial In/Out
Cisco IOSSIP GW/RMS
Cisco IPICSServer
H.323 Trunk for Policy EngineDial In/Out and PMC Direct Dial
2-35Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsIntegrating Cisco IPICS with SIP Providers
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
Scenario 4: Policy Engine <-> SIP <-> Cisco IOS SIP Gateway, Cisco Unified Communications Manager without Native SIP Trunk Support, 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-33 illustrates this scenario.
Figure 2-33 Calls in Deployment that Uses Cisco IOS SIP Gateway and Cisco Unified
Communications Manager without Native SIP Trunk Support, RMS Functionality Not
on the Cisco IOS SIP Gateway
V
Cisco UnifiedCommunicationsManager 4.1(2)
Voice Gateway toPSTN
1852
48
V
V
SIP Trunk forPolicy EngineDial In/Out
Cisco IOSSIP Gateway
H.323 Trunk for Policy EngineDial In/Out and PMC Direct Dial
Cisco IPICSServer
SIP Trunk for PMCDirect Dial
RMS
2-36Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsIntegrating Cisco IPICS with SIP Providers
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:
• PMC 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)
• PMC 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 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!
2-37Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsIntegrating Cisco IPICS with SIP Providers
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 a PMC Direct Dial prefix needed?Because the PMC 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.
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 voipdestination-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
Connectivity to Cisco Unified Communications Manager Releases that do not Provide Native SIP Trunk Support
The policy engine requires that a SIP provider be configured in your network. A SIP provider handles calls to and from the policy engine. For the SIP provider, Cisco IPICS supports Cisco Unified Communications Manager or a Cisco router that is running a supported release of Cisco IOS. For
2-38Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsIntegrating Cisco IPICS with SIP Providers
information about configuring the SIP provider, refer to the “Configuring the SIP Provider section in Cisco IPICS Server Administration Guide, Release 2.1(1). For detailed information about supported releases of these applications, refer to Cisco IPICS Compatibility Matrix.
If you are using an older release of Cisco Unified Communications Manager (a release that is not listed as a compatible release), the SIP provider must be a router that is running a supported release of Cisco IOS. The IP-to-IP gateway of the router may be used to tandem calls from the policy engine to Cisco Unified Communications Manager by using an H.323 trunk between the router and Cisco Unified Communications Manager.
This following sections illustrate how to configure this trunk for Cisco Unified Communications Manager 4.1 and a router that is running Cisco IOS 12.4.6(T6). The procedure is similar for other Cisco Unified Communications Manager releases.
• Configuring the Trunk on Cisco Unified Communications Manager 4.1, page 2-39
• Configuring the Trunk on the Router, page 2-40
Configuring the Trunk on Cisco Unified Communications Manager 4.1
To configure the H.323 trunk for Cisco Unified Communications Manager 4.1, perform the following procedure:
Procedure
Step 1 Start and log in to the Cisco Unified Communications Manager Administration application, and choose Device > Trunk.
Step 2 In the Find and List Trunks page, click Add a New Trunk.
Step 3 In the Add a New Trunk page, take these actions:
a. From the Trunk Type drop-down list, choose Inter-Cluster Trunk (Non-Gatekeeper Controlled).
b. From the Device Protocol drop-down list, choose Inter-Cluster Trunk.
c. Click Next.
Step 4 In the Trunk Configuration page, take these actions:
a. In the Device Information area, check the Media Termination Point Required check box.
b. In the Inbound Calls area, check the Enable Inbound FastStart check box.
c. In the Server 1 IP Address/Host Name field, enter the IP address of the host name of the router with the IP-to-IP gateway.
d. Make other settings as appropriate for your deployment, or leave them at their default values.
e. Click Update.
Step 5 From the Cisco Unified Communications Manager Administration application menu bar, and choose Route Plane > Route/Hunt > Route Pattern.
Step 6 In the Find and List Route Patterns page, click Add a New Route Pattern.
2-39Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsIntegrating Cisco IPICS with SIP Providers
Step 7 In the Route Pattern Configuration page, take these actions:
a. In the Route Pattern field, enter all the DNs to be tandemed through the IP-IP Gateway to the policy engine (DNs for ops views and custom dial engine scripts).
b. From the Gateway or Route List drop-down list, choose the intercluster trunk that you configured earlier in this procedure.
c. Make other settings as appropriate for your deployment, or leave them at their default values.
d. Click Update.
Configuring the Trunk on the Router
To configure the H.323 trunk for connectivity from the router to Cisco Unified Communications Manager 4.1, make sure that the router is configured as described in the “Configuring a Cisco Router as the SIP Provider” section in Cisco IPICS Server Administration Guide, Release 2.1(1). Then, perform the additional configuration on the router.
The H.323 dial peers destination pattern must include the dial pattern that the policy engine uses to reach the Cisco Unified Communications Manager DNs. When PMC direct dial (two-way) calls are placed, the PMC prepends the dial prefix that is assigned in Cisco IPICS Direct Dial Management window (from the Administration Console Policy Engine tab, choose Prompt Management > Direct Dial Management). The H.323 dial peer must account for this prefix. In addition, when dial-in users enter a DN to be called, the H.323 dial peer must be able to match these numbers.
Enable IP-to-IP gateway functionality for SIP to H.323 and for H.323 to SIPRouter# configure terminal
Router(config)# voice service voip
Router(conf-voi-serv)# allow-connections sip to h323
Router(conf-voi-serv)# allow-connections h323 to sip
Router(conf-voi-serv)# allow-connections h323 to h323 (required only if you have other H.323 dial peers defined)
Router(conf- voi-serv)#end
Enable CCM Compatibility ModeRouter# configure terminal
Router(config)# voice service voip
Router(conf-voi-serv)# h323
Router(conf-serv-h323)# ccm-compatible
Router(conf-serv-h323)# end
Create the H.323 dial-peerRouter# configure terminal
Router(config)# dial-peer voice <dial-peer-tag> voip
Router(config-dial-peer)# destination-pattern <route pattern> (set route pattern to route all traffic from the policy engine to Cisco Unified Communications Manager, for example: .T)
Router(config-dial-peer)# voice-class codec <voice class codec tag> (corresponds to a voice-class codec that specifies the preference codecs, for example, G.711 u-law)
Router(config-dial-peer)# session target <address of Cisco Unified Communications Manager 4.1>
2-40Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsCisco Unified IP Phones
Router(config-dial-peer)# dtmf-relay h245-alphanumeric
Router(config-dial-peer)# end
Cisco Unified IP PhonesIf 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 a PMC, 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 a PMC, 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 2.1(1). For a list of Cisco Unified IP Phones that Cisco IPICS supports as PTT devices, refer to Cisco IPICS Compatibility Matrix. These documents are available at the following URL:
http://www.cisco.com/en/US/products/ps7026/tsd_products_support_series_home.html
This section includes these topics:
• Cisco Unified Communications Manager Configuration Overview, page 2-41
• Cisco Unified Communications Manager Express Configuration Overview, page 2-42
Cisco Unified Communications Manager Configuration OverviewYou 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
2-41Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03
Chapter 2 Cisco IPICS Component ConsiderationsCisco Unified IP Phones
Cisco Unified Communications Manager Express Configuration OverviewThe 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.248domain-name yourdomainnamedns-server dns1 dns2default-router 10.1.1.1option 150 ip 10.1.1.1
tftp-server flash:filename1tftp-server flash:filename2
telephony-serviceload 7960-7940 filename1load 7970 filename2max-ephones nmax-dn mip source-address 10.1.1.1 port 2000auto assign 1 to nurl services http://10.1.2.1/ipics_server/servlet/IPPhoneManagercreate cnf-filesmax-conferences 8 gain -6
ephone-dn 1 dual-linenumber abcd
!ephone-dn 2 dual-linenumber efgh
2-42Solution Reference Network Design (SRND) for Cisco IPICS Release 2.1(1)
OL-12996-03