Feedback
Table Of Contents
Cisco IPICS Component Considerations
Allocation of RMS DS0 Resources
DSP Channel Optimization and Allocation
Examples of Hardware Configuration and Supported Voice Streams
Channel Mixing in the RMS using the Cisco Hoot `n' Holler Feature
Cisco IPICS Endpoint Scenarios
Integrating Cisco IPICS with SIP Providers
Call Flow and Dial Peer Examples
When is a PMC Direct Dial prefix needed?
Connectivity to Cisco Unified CallManager Releases that do not Provide Native SIP Trunk Support
Configuring the Trunk on Cisco Unified CallManager 4.1
Configuring the Trunk on the Router
Cisco Unified CallManager Configuration Overview
Cisco Unified CallManager Express Configuration Overview
Cisco IPICS Component Considerations
This 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:
•
Integrating Cisco IPICS with SIP Providers
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:
•
For detailed information about configuring an RMS for Cisco IPICS, refer to the "RMS Configuration" appendix in Cisco IPICS Server Administration Guide, Release 2.0(1).
For a list of Cisco IOS versions that Cisco IPICS supports for use as an RMS, refer to Cisco IPICS Compatibility Matrix. Each supported Cisco IOS version includes the Cisco Hoot `n' Holler feature.
RMS Overview
The primary role of an 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 Cisco IPICS Server Administration Guide, Release 2.0(1).) When you use the Cisco IPICS Administration Console to add an RMS, the loopback pairs will be available for assignment. A properly configured RMS will make a list of DS0 loopback channels available for dynamic allocation by the 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 IPICS server dynamically allocates a DS0 loopback pair (two DS0 channels) in the following scenarios:
•
•
•
RMSs for Locations
An RMS supports one Cisco IPICS location, which is defined as a multicast domain. If an IPICS deployment requires RMS functionality in more than one location, there must be an RMS 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 IPICS server when it configures an RMS. The IPICS server keeps track of the in-use and the available addresses.
The multicast address pool is a global resource that it is shared across all RMSs 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 RMSs. The IPICS server will attempt to load balance across all RMSs that are in the same location.
The following information applies to locations:
•
•
•
Multiple Location Example
As an example of how Cisco IPICS and RMSs functions in multiple locations, consider the following scenario:
•
•
•
•
•
•
•
When the Cisco IPICS dispatcher activates VTG Emergency, 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 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.
RMS Configuration Example
The following example shows what the 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 following Cisco IOS configuration output shows what the Cisco IPICS server configured in the RMS to support putting the Police channel in 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 vadvoice-port 0/2/0: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 90929093description #0/2/0:3#1164200525742# INUSE 284voice-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 284dial-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 g711ulawThe following Cisco IOS configuration output shows what the IPICS server configured in the RMS to support putting the Fire channel in 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 vadvoice-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 285voice-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 285dial-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 vadThe following Cisco IOS configuration outputs show what the IPICS server configures in the RMS when a PMC user that is assigned both the Police and Fire channels connects using the remote location. This configuration allows the PMC to communicate with RMS using unicast. The RMS forwards the unicast stream, which is received from the PMC, through a DS0 loopback then 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 unicast
This Cisco IOS configuration output is for 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 vadvoice-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 909290914voice-port 0/2/1: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 40description #0/2/1:14#1164659525783# INUSE 295dial-peer voice 909291914 potsdescription #0/2/1:14#1164659525783# INUSE 295destination-pattern 1990000275909291914port 0/2/1:14This Cisco IOS configuration output is for 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 vadvoice-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 296voice-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 296dial-peer voice 909291915 potsdescription #0/2/1:15#1164659525833# INUSE 296destination-pattern 1990000275909291915port 0/2/1:15When is an RMS Required?
Cisco IPICS requires an RMS to establish connectivity between unicast and multicast endpoints (remote PMC to channel, remote PMC to VTG, dial-in user to channel or VTG), and to establish connectivity between multicast endpoints that are on different channels (channel to VTG, 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. In this example, after the users log in to the Cisco IPICS server, they receive their channel information, which is 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.
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
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 PMC users on the Remote location), but it will 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.
When a PMC successfully authenticates using the Remote location, the RMS will allocate a DS0 pair to each channel or VTG that is assigned to that authenticated PMC user. (See the "Remote PMC Users" section for related information.)
Table 2-1 illustrates when RMS resources are allocated in various scenarios.
RMS DS0 Resource Requirements for MCS 7825-H1-S31and MCS 7825-H2-S31
•
•
–
–
–
RMS DS0 Resource Requirements for MCS 7845-H1-S31 and MCS 7845-H2-S31
•
•
–
–
–
For the most 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:
•
•
•
•
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
.shtmlExamples 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 (bearer) 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
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
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:
•
•
•
•
•
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.
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:10VTG Combined San Jose Police239.192.21.79 239.192.21.64T1 0/0:14 --------------T1 0/1:14VTG Combined San Jose Fire239.192.21.79 239.192.21.65Also assume that the Cisco IPICS dispatcher places the following users and channels into the Combined VTG channel:
•
–
–
•
–
–
–
–
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 18destination-pattern 90929192voice class permanent 1session protocol multicastsession target ipv4:239.192.21.64:21000codec g711ulaw no vad!voice-port 0/0:10voice class permanent 1auto-cut-through lmr 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-through lmr 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-through lmr 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 18Channel Mixing in the RMS using the Cisco Hoot `n' Holler Feature
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:
•
•
•
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, 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 in 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.
Cisco IPICS Endpoint Scenarios
When a Cisco IPICS dispatcher activates the Combined VTG (as shown in Figure 2-3), Cisco IPICS configures the RMS router to mix the Police, Fire, and Combined VTG channels. Users that 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.
Figure 2-8 Multicast Group Membership
When a user deactivates the Police and or Fire channel and activates the Combined VTG channel, the endpoint sends an Internet Group Management Protocol (IGMP) leave message for the Police and or 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.
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.
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.
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
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 the 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 that are associated with the Stocks channel can communicate with each other, and the users that 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 is activated, these endpoints will simply join the VTG multicast channel that is allocated by the Cisco IPICS server. See Figure 2-14.
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:
•
•
See Figure 2-15.
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
Remote PMC Users
PMC 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 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 into 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.
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.64
voice-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 0timing hangover 40connection trunk 909090920description #0/0/0:20#1123534375842# INUSE 92dial-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 vadUnicast Side—239.192.21.64
voice-port 0/0/1: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 0timing hangover 40description #0/0/1:20#1123534375842# INUSE 92dial-peer voice 909091920 potsdescription #0/0/1:20#1123534375842# INUSE 92destination-pattern 8880000081909091920port 0/0/1:20After 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 Plain Old Telephone Service (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 the 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 Unicast Connection Set Up
Figure 2-21 SIP Signaling Flow
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 will be 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.
Integrating Cisco IPICS with SIP Providers
Because a Cisco IPICS deployment can vary depending on the call flow, it is important to understand how call flow works so that you can properly configure supporting components. Cisco IPICS Server Administration Guide, Release 2.0(1) provides instructions for configuring the RMS and the Cisco IOS SIP Gateway and SIP provider. If you choose to deploy Cisco IPICS system components in a different way, review the information in the following sections. These sections describe how the required Cisco IOS dial peers are configured to provide connectivity for various scenarios.
It also is important to understand the different scenarios that require unique configuration considerations. Cisco IPICS supports SIP providers: Cisco Unified CallManager and a Cisco router that is running a supported version of Cisco IOS. The way in which a SIP provider is deployed in a network and the dial plan at your site dictate how components are configured.
Requirements for SIP Sessions
Cisco IPICS imposes the following requirements on SIP sessions:
•
–
–
–
–
•
•
•
Default Dial Peer Scenarios
As described in Cisco IPICS Server Administration Guide, Release 2.0(1), configure the following dial peers on the RMS:
•
•
Configure the following dial peers when a Cisco IOS SIP gateway is used as the SIP provider:
•
•
Note
Dial Peer Use in Scenarios
The following figures describe which dial peers are used in different scenarios:
•
•
•
•
•
•
•
Figure 2-24 Calls to Policy Engine in Deployment that Uses Cisco Unified CallManager 5.0(4a)
Figure 2-25 Calls to Policy Engine in Deployment that Uses Cisco Unified CallManager 4.1(2)
Figure 2-26 Calls from Policy Engine in Deployment that Uses Cisco Unified CallManager 5.0(4a)
Figure 2-27 Calls from Policy Engine in Deployment that Uses Cisco Unified CallManager 4.1(2)
Figure 2-28 PMC Direct Dial Calls in Deployment that Uses Cisco Unified CallManager 5.0(4a)
Figure 2-29 PMC Direct Dial Calls in Deployment that Uses Cisco Unified CallManager 4.1(2), RMS and Cisco IOS SIP Gateway on Separate Routers
Figure 2-30 PMC Direct Dial Calls in Deployment that Uses Cisco Unified CallManager 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 CallManager 5.0(4a)
This scenario requires a SIP trunk between the Cisco IPICS and Cisco Unified CallManager for dial in and dial out. It also requires a SIP trunk between the RMS and Cisco Unified CallManager for PMC direct dial feature.
Figure 2-31 illustrates this scenario.
Figure 2-31 Calls in Deployment that Uses Cisco Unified CallManager 5.0(4a)
This scenario does not include a Cisco IOS SIP GW, 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 CallManager 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 TUI.
dial-peer voice 555 voipvoice-class codec 2session protocol sipv2incoming called-number .dtmf-relay rtp-nteno vad!dial-peer voice 556 voipdescription sip providerdestination-pattern .Tvoice-class codec 1session protocol sipv2session target ipv4:<Cisco Unified CallManager 5.0(4a) IP Address>session transport tcpdtmf-relay rtp-nteScenario 2: Policy Engine <-> SIP <-> Cisco IOS SIP Gateway, with no Cisco Unified CallManager or Cisco Unified CallManager Express
This scenario is dependent on the desired SIP call routing. The appropriate dial peers must be configured based on the your requirements. In most cases, this configuration will be a subset of scenario 3 in which the dial peers used for connectivity with the Cisco Unified CallManager 4.1(2) are modified to reflect the desired dial patterns and destinations.
Scenario 3: Policy Engine <-> SIP <-> Cisco IOS SIP Gateway, Cisco Unified CallManager 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 requirements 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 CallManager without Native SIP Trunk Support, RMS Functionality on the Cisco IOS SIP Gateway
The example dial peer configuration in this scenario assumes the following:
•
•
•
•
This scenario addresses the following call types:
•
•
•
•
RMS/Cisco IOS SIP gateway dial peers are configured as follows:
dial-peer voice 555 voipvoice-class codec 2session protocol sipv2incoming called-number .dtmf-relay rtp-nteno vad!dial-peer voice 25000 voipdestination-pattern .....voice-class codec 1session target ipv4:<Cisco Unified CallManager 4.1 IP Address>session transport tcpdtmf-relay h245-alphanumeric!dial-peer voice 9000 voipdestination-pattern 9Tvoice-class codec 2session target ipv4:<Cisco Unified CallManager 4.1 IP Address>dtmf-relay h245-alphanumeric!dial-peer voice 8000 voipdestination-pattern 8Tvoice-class codec 2session target ipv4:<Cisco Unified CallManager 4.1 IP Address>dtmf-relay h245-alphanumeric!dial-peer voice 25100 voipdestination-pattern 251..session protocol sipv2session target ipv4:<Cisco IPICS Server IP Address>session transport tcpdtmf-relay rtp-nteScenario 4: Policy Engine <-> SIP <-> Cisco IOS SIP Gateway, Cisco Unified CallManager 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 CallManager without Native SIP Trunk Support, RMS Functionality Not on the Cisco IOS SIP Gateway
The example dial peer configuration in this scenario assumes the following:
•
•
•
•
This scenario addresses the following call types:
•
•
•
•
RMS dial peers are configured as follows:
Note
dial-peer voice 555 voipvoice-class codec 2session protocol sipv2incoming called-number .dtmf-relay rtp-nteno vad!dial-peer voice 556 voipdestination-pattern .Tvoice-class codec 1session protocol sipv2session target ipv4:<Cisco IOS SIP Gateway IP Address>session transport tcpdtmf-relay rtp-nteCisco IOS SIP gateway dial peers are configured as follows:
dial-peer voice 555 voipvoice-class codec 2session protocol sipv2incoming called-number .dtmf-relay rtp-nteno vad!dial-peer voice 25000 voipdestination-pattern .....voice-class codec 1session target ipv4:<Cisco Unified CallManager 4.1 IP Address>session transport tcpdtmf-relay h245-alphanumeric!dial-peer voice 9000 voipdestination-pattern 9Tvoice-class codec 2session target ipv4:<Cisco Unified CallManager 4.1 IP Address>dtmf-relay h245-alphanumeric!dial-peer voice 8000 voipdestination-pattern 8Tvoice-class codec 2session target ipv4:<Cisco Unified CallManager 4.1 IP Address>dtmf-relay h245-alphanumeric!dial-peer voice 25100 voipdestination-pattern 251..session protocol sipv2session target ipv4:<Cisco IPICS Server IP Address>session transport tcpdtmf-relay rtp-nteWhen is a PMC Direct Dial prefix needed?
Because the PMC direct dial feature always use 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 1rule 1 /^9\(.*\)$/ /\1/voice translation-profile 1translate called 1dial-peer voice 556 voipdestination-pattern 9Ttranslation-profile outgoing 1preference 10voice-class codec 1session protocol sipv2session target ipv4:<SIP Provider IP Address>session transport tcpdtmf-relay rtp-nteConnectivity to Cisco Unified CallManager 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 CallManager or a Cisco router that is running a supported version of Cisco IOS. For information about configuring the SIP provider, refer to Cisco IPICS Server Administration Guide, Release 2.0(1). For detailed information about supported versions of these applications, refer to Cisco IPICS Compatibility Matrix.
If you are using an older version of Cisco Unified CallManager (a version that is not listed as a compatible version), the SIP provider must be a router that is running a supported version of Cisco IOS. The IP-to-IP gateway of the router may be used to tandem calls from the policy engine to Cisco Unified CallManager using an H.323 trunk between the router and Cisco Unified CallManager.
This following sections illustrate how to configure this trunk for Cisco Unified CallManager 4.1 and a router that is running Cisco IOS 12.4.6(T6). The procedure is similar for other Cisco Unified CallManager releases.
•
•
Configuring the Trunk on Cisco Unified CallManager 4.1
To configure the H.323 trunk for Cisco Unified CallManager 4.1, perform the following procedure:
Procedure
Step 1
Step 2
Step 3
a.
b.
c.
Step 4
a.
b.
c.
d.
e.
Step 5
Step 6
Step 7
a.
b.
c.
d.
Configuring the Trunk on the Router
To configure the H.323 trunk for connectivity from the router to Cisco Unified CallManager 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.0(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 Call 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 SIP
Router# 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 Mode
Router# 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-peer
Router# 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 CallManager, 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 CallManager 4.1>
Router(config-dial-peer)# dtmf-relay h245-alphanumeric
Router(config-dial-peer)# end
Land Mobile Radio Gateway
The Cisco Hoot `n' Holler feature is used to enable land mobile radios (LMRs) in a Cisco IPICS solution. An LMR is integrated by providing an ear and mouth (E&M) interface to an LMR or to other PTT devices, such as Sprint and Nextel phones. This interface is in the form of a voice port that is configured to provide an appropriate electrical interface to the radio. The voice port is configured with a connection trunk entry that corresponds to a VoIP dial peer, which in turn associates the connection to a multicast address. You can configure a corresponding channel in Cisco IPICS, using the same multicast address, which enables Cisco IPICS to provide communication paths between the desired endpoints.
For additional information about LMRs, refer to the documentation at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_7/lmrip/index
.htmCisco Unified IP Phones
If your Cisco IPICS deployment includes Cisco Unified CallManager or Cisco Unified CallManager 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 is displayed 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 CallManager or Cisco Unified CallManager 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 use 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.0(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/univercd/cc/td/doc/product/cis/c_ipics/index.htm
Cisco Unified CallManager Configuration Overview
You use the Cisco IP Phone Services Configuration page in the Cisco Unified CallManager 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 CallManager 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 CallManager System Guide, which is available at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/
Cisco Unified CallManager Express Configuration Overview
The following is a sample Cisco IOS router configuration that enables Cisco Unified CallManager 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 pool1network 10.1.1.0 255.255.255.248domain-name yourdomainnamedns-server dns1 dns2default-router 10.1.1.1option 150 ip 10.1.1.1tftp-server flash:filename1tftp-server flash:filename2telephony-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 -6ephone-dn 1 dual-linenumber abcd!ephone-dn 2 dual-linenumber efgh
