-
Cisco Unified Communications SRND Based on Cisco Unified CallManager 4.x
-
Preface
-
Introduction
-
IP Telephony Deployment Models
-
Network Infrastructure
-
Gateways
-
Cisco Unified CallManager Trunks
-
Media Resources
-
Music on Hold
-
Call Processing
-
Call Admission Control
-
Dial Plan
-
Emergency Services
-
Third-Party Voicemail Design
-
Cisco Unity
-
Cisco Unity Express
-
Cisco Unified MeetingPlace Integration
-
Cisco Unified MeetingPlace Express
-
IP Video Telephony
-
LDAP Directory Integration
-
IP Telephony Migration Options
-
Voice Security
-
IP Telephony Endpoints
-
Device Mobility
-
Recommended Hardware and Software Combinations
-
Glossary
-
Index
-
Table Of Contents
IP Video Telephony Solution Components
Media Resource Groups and Lists
Supported Gatekeeper Platforms
Summary of Endpoint Gatekeepers
Migrating from Cisco Unified CallManager 4.0
Cisco Unified CallManager Assistant
Cisco IP Interactive Voice Response and Cisco IP Contact Center
Cisco IP SoftPhone and Cisco IP Communicator
Cisco Aironet 802.11b Networking Solutions
Cisco Unified Wireless IP Phone 7920
IP Video Telephony
Cisco introduced its IP Video Telephony solution in Cisco Unified CallManager Release 4.0. Video is fully integrated into Cisco Unified CallManager, and there are also many video endpoints available from Cisco and its strategic partners. Cisco Unified Video Advantage is just as easy to deploy, manage, and use as a Cisco Unified IP Phone.
IP Video Telephony Solution Components
The Cisco IP Video Telephony solution consists of Cisco Unified CallManager 4.2, Cisco Unified Videoconferencing 3500 Series Multipoint Control Units (MCUs) for both H.323 and Skinny Client Control Protocol (SCCP) conference calls, Cisco Unified Videoconferencing 3500 Series H.320 Gateways, Cisco IOS H.323 Gatekeeper, Cisco Unified Video Advantage, Cisco IP Video Phone 7985, Sony and Tandberg SCCP endpoint solutions, and the existing range of H.323 products from partners such as Polycom, Tandberg, Sony, and others. (See Figure 17-1.)
Figure 17-1 IP Video Telephony Components
Administration Considerations
This section discusses the following configuration elements in Cisco Unified CallManager Administration that pertain to Video Telephony:
Protocols
Cisco Unified CallManager supports a large number of protocols. Any device can call any other device, but video is supported only on SCCP and H.323 devices. Specifically, video is not supported in the following protocols in Cisco Unified CallManager Release 4.2:
•
Computer Telephony Integration (CTI) applications (TAPI and JTAPI)
•
•
Therefore, Cisco Unified CallManager currently supports the types of calls listed in Table 17-1.
Table 17-2 lists the audio and video algorithms and protocols currently supported in Cisco Unified CallManager.
Regions
When configuring a region, you set two fields in Cisco Unified CallManager Administration: the Audio Codec and the Video Bandwidth. The audio setting specifies a codec type, while the video setting specifies the amount of bandwidth you want to allow. However, even though the notation is different, the Audio Codec and Video Bandwidth fields actually perform similar functions. The Audio Codec field defines the maximum bit-rate allowed for audio-only calls as well as for the audio channel in video calls. For instance, if you set the Audio Codec for a region to G.711, Cisco Unified CallManager allocates 64 kbps as the maximum bandwidth allowed for the audio channel for that region. In this case, Cisco Unified CallManager will permit calls using either G.711, G.722, G.728, or G.729. However, if you set the Audio Codec to G.729, Cisco Unified CallManager allocates only 8 kbps as the maximum amount of bandwidth allowed for the audio channel, and it will permit calls using only G.729 because G.728, G.711, and G.722 all take more than 8 kbps.
Note
Note
The Video Bandwidth field defines the maximum bit-rate allowed for the video channel of the call. However, for historical continuity with the practices used in traditional videoconferencing products, the value used in this field also includes the bandwidth of the audio channel. For instance, if you want to allow calls at 384 kbps using G.711 audio, you would set the Video Bandwidth field to 384 kbps and not 320 kbps.
In summary, the Audio Codec field defines the maximum bit-rate used for audio-only calls and for the audio channel of video calls, while the Video Bandwidth field defines the maximum bit-rate allowed for video calls and should include the audio portion of the call.
Choosing the correct audio codec bandwidth limit is very important because each device supports only certain audio codecs, as shown in Table 17-3. (For the most recent list of codecs supported by a particular endpoint, refer to the product documentation for that endpoint.)
As Table 17-3 indicates, if you set the region to G.729, not all videoconferencing devices are able to support this type of codec. For example, calls between a Cisco Unified Video Advantage endpoint and a Tandberg endpoint would fail, or Cisco Unified CallManager would allocate an audio transcoding resource for the call.
Transcoders do not currently support the pass-through capability, so the call would connect as audio-only and would be transcoded between G.729 and G.711. To avoid this situation without using Cisco IOS Enhanced Transcoders, you would have to set the region to use G.711 instead. However, a region set for G.711 would also use G.711 for audio calls between two IP phones, which you might not want due to the increased consumption of bandwidth over the WAN.
If you want to use G.729 for audio-only calls to conserve bandwidth and to use G.711 for video calls, then you should configure one region to use G.711 for video endpoints that do not support G.729 and a separate region (or regions) to use G.729 for IP phones. (See Figure 17-2.) This method increases the number of regions needed but provides the desired codec and bandwidth allocations.
Figure 17-2 Using G.711 for Video Calls and G.729 for Audio-Only Calls
Note
Table 17-4 lists some example configurations and their outcomes.
The Video Bandwidth field accepts values in the range of 1 to 8128 kbps.However, to allow for compatibility with H.323 and H.320 videoconferencing devices, Cisco recommends that you always enter values for this field in increments of either 56 or 64 kbps. Therefore, valid values for this field include 112 kbps, 128 kbps, 224 kbps, 256 kbps, 336 kbps, 384 kbps, and so forth.
When the call speed requested by the endpoint exceeds the bandwidth value configured for the region, Cisco Unified CallManager automatically negotiates the call down to match the value allowed in the region setting. For instance, assume that an H.323 endpoint calls another H.323 endpoint at 768 kbps, but the region is set to allow a maximum of 384 kbps. The incoming H.225 setup request from the calling party would indicate that the call speed is 768 kbps, but Cisco Unified CallManager would change that value to 384 kbps in the outgoing H.225 setup message to the called party. Thus, the called endpoint would think that it was a 384-kbps call to begin with, and the call would be negotiated at that rate. The calling endpoint would show the requested bandwidth as 768 kbps, but the negotiated bandwidth would be 384 kbps.
However, if you set the Video Bandwidth to "None" in the region, Cisco Unified CallManager will either terminate the call (and send an H.225 Release Complete message back to the calling party) or will allow the call to pass as an audio-only call instead, depending on whether or not the called device has the Retry Video Call as Audio option enabled. (See Retry Video Call as Audio.)
Locations
When configuring static locations, you also set two fields in Cisco Unified CallManager Administration: the Audio Bandwidth and the Video Bandwidth. Unlike regions however, the Audio Bandwidth for static locations applies only to audio-only calls, while the Video Bandwidth applies to both the audio and video channels of video calls. The audio and video bandwidth are kept separate because, if both types of calls shared a single allocation of bandwidth, then it is very likely that audio calls would take all the available bandwidth and leave no room for any video calls, or vice versa. Also, separate bandwidth pools for audio and video correspond to the way queues are configured in the switches and routers in the network, which typically have a priority queue for voice traffic and a separate priority queue or a Class-Based Weighted Fair Queue for video traffic. (See WAN Quality of Service (QoS), page 3-28, for more details.)
Both the Audio Bandwidth and the Video Bandwidth fields offer three options: None, Unlimited, or a field that accepts numeric values. However, the values entered in these fields use two different calculation models. For the Audio Bandwidth field, the values entered should include the Layers 3 to 7 overhead required for the call. For instance, if you want to permit a single G.729 call to or from a location, you would enter the value of 24 kbps. For a G.711 call, you would enter the value of 80 kbps. The Video Bandwidth field, by contrast, should be entered without the overhead included. For instance, for a 128-kbps call you would enter 128 kbps, and for a 384-kbps call you would enter 384 kbps. As with the values used in the Video Bandwidth field for regions, Cisco recommends that you always use increments of 56 kbps or 64 kbps for the Video Bandwidth field for locations as well.
For example, assume that a company has a three-site network. The San Francisco location has a 1.544-Mbps T1 circuit connecting it to the San Jose main campus. The system administrator wants to allow four G.729 voice calls and one 384-kbps (or two 128-kbps) video calls to/from that location. The Dallas location has two 1.544-Mbps T1 circuits connecting it to the San Jose main campus, and the administrator wants to allow eight G.711 voice calls and two 384-kbps video calls to/from that location. For this example, the administrator would set the San Francisco and Dallas locations to the following values:
When the call speed requested by the endpoint exceeds the value configured for the location, Cisco Unified CallManager will not automatically negotiate the call speed (as it does for regions) to match the value allowed in the location setting. Instead, the call will be rejected or will be retried as an audio-only call (if the Retry Video as Audio setting is enabled on the called device). Therefore, you should always set the region's video bandwidth to a value lower than the location's video bandwidth value. For example, if you have two regions (region A and region B) and you set the video bandwidth between those two regions to 768 kbps but the devices in region A are in a location that has a video bandwidth set to 384 kbps, then all calls between those two regions will fail or will result in audio-only calls (depending on the Retry Video Call as Audio setting).
Retry Video Call as Audio
This check-box is available on all endpoint types that support video, including Cisco Unified IP Phones 7940, 7941, 7960, 7961, 7970, 7971, and Cisco IP Video Phone 7985, as well as Sony or Tandberg SCCP endpoints, and all H.323 devices (clients, gateways and all types of H.323 trunks). When this option is activated (checked), if there is not enough bandwidth to reach the device (for example, if the Cisco Unified CallManager regions or locations do not allow video for that call), then Cisco Unified CallManager will retry the call as an audio-only call. When this option is deactivated (unchecked), Cisco Unified CallManager will not retry the call as audio-only but instead will either fail the call or reroute the call by whatever automated alternate routing (AAR) path is configured. By default, this retry option is enabled (checked).
This feature applies to the following scenarios only:
•
•
•
The Retry Video Call as Audio option takes effect only on the terminating (called) device, thus allowing the flexibility for the calling device to have different options (retry or AAR) for different destinations.
If the video call fails due to bandwidth limitations but automated alternate routing (AAR) is enabled, Cisco Unified CallManager will attempt to reroute the failed call as a video call to the AAR destination. If AAR is not enabled, the failed call will result in a busy tone and an error message being sent to the caller. (See Figure 17-3.) Depending on the type of device that is calling, the failed call will result in one of the following conditions:
•
•
•
Figure 17-3 Possible Scenarios for a Video Call
See the chapter on Call Admission Control, page 9-1, for further details on the use of AAR.
Figure 17-4 illustrates the steps of a call between two clusters using non-gatekeeper controlled intercluster trunks.
Figure 17-4 Call Flow Between Two Clusters Using Non-Gatekeeper Controlled Intercluster Trunks
Wait for Far-End to Send TCS
This check-box is available on all H.323 devices, including H.323 clients, H.323 gateways, and H.225 gatekeeper-controlled trunks This feature pertains to the H.245 capabilities-exchange phase of H.323 calls. When this feature is enabled, Cisco Unified CallManager waits for the remote H.323 device to send its Terminal Capabilities Set (TCS) to Cisco Unified CallManager before Cisco Unified CallManager will send its TCS to the H.323 device. When the option is disabled, Cisco Unified CallManager does not wait but sends its TCS to the remote H.323 device immediately.
By default, the Wait for Far-End to Send TCS option is enabled (checked). However, you must uncheck (disable) it in the following circumstances:
•
In this case, a stalemate occurs because neither side sends its TCS, and the H.245 connection times out after a few seconds. Examples of devices that also wait for the far-end to send TCS are some H.323 routed-mode gatekeepers, H.320 gateways, H.323 proxies (or IP-to-IP gateways) and some H.323 multipoint conference bridges. These devices wait for the far-end to send TCS for the same reason Cisco Unified CallManager does: because they are waiting for both sides of the connection to send their TCSs before forwarding them to the other side.
•
Note
In many scenarios, Cisco Unified CallManager performs the role of a software switch connecting two endpoint devices (such as two H.323 clients that are trying to call each other). In such cases, it is best if Cisco Unified CallManager waits until both devices have sent their TCS messages so that it knows the capabilities of each device and can therefore make the most intelligent decision about what TCS to send back to each party (depending on region and location configurations, among other things). In these cases, the Wait for Far-End to Send TCS feature should be enabled.
However, some other H.323 devices (such as an H.320 gateway, which connects an H.323 device to an H.320 device) also perform the function of connecting two or more parties together. The gateway also prefers to wait until both ends send their TCS messages, so that it can make the most intelligent choice about how to set up the call. A stalemate could result if Cisco Unified CallManager and the gateway both wait for the other side to send their TCSs. To avoid this stalemate situation, disable (uncheck) the Wait for Far-End to Send TCS feature.
For instance, consider the following call scenarios illustrated in Figure 17-5:
•
•
In both of these scenarios, Wait for Far-End to Send TCS feature can be left at its default setting of enabled (checked)
Figure 17-5 Scenarios with the Wait for Far-End to Send TCS Feature Enabled (Checked)
In Scenario 1 from Figure 17-5, Cisco Unified CallManager already knows the capabilities of the Cisco Unified Video Advantage client because SCCP devices provide Cisco Unified CallManager with their media capabilities during registration. But Cisco Unified CallManager does not know the capabilities of the H.320 gateway until the gateway sends its TCS to Cisco Unified CallManager during the H.245 phase of the call. Likewise, the H.320 gateway does not know what TCS to send to Cisco Unified CallManager until the H.320 endpoint sends its TCS to the gateway. In this case it is better to leave the Wait for Far-End to Send TCS feature enabled because the H.320 endpoint will send its TCS to the gateway, the gateway will send its TCS to Cisco Unified CallManager, and Cisco Unified CallManager will then have the TCSs from both endpoints with which to make a decision.
Figure 17-6 shows the following call scenarios, in which the call will fail unless the Wait for Far-End to Send TCS feature is disabled:
•
•
Figure 17-6 Scenarios with the Wait for Far-End to Send TCS Feature Disabled (Unchecked)
In both scenarios from Figure 17-6, there will be a stalemate because both Cisco Unified CallManagers will wait to receive the TCSs from the gateways, and the gateways will both wait to receive the TCS from the ISDN side as well. The call will time-out after a few seconds and fail. From the perspective of the users, the caller will hear ringback tone indicating that the call is progressing and the called party will hear a ring indicating an incoming call. When the called party attempts the answer the call, the H.245 phase will fail due to the stalemate, and the call will then fail by hanging up on both parties.
To work around this issue in scenarios such as these, Cisco recommends that you disable (uncheck) the Wait for Far-End to Send TCS option on the device representing the H.320 gateway in Cisco Unified CallManager. This device could be an H.225 gatekeeper-controlled trunk or an H.323 gateway device, depending on how you have configured Cisco Unified CallManager to reach the H.320 gateway.
However, if the Wait for Far-End to Send TCS option is disabled, there is a possibility that the initial capabilities exchanged will not work for the remote device. For instance, the Cisco Unified CallManager region might be set to 768-kbps video but the H.320 device might only support 384 kbps, or the selected audio codec might not work for the remote party. In such cases, the initially negotiated logical channels might have to be torn down and reopened with the correct speed and codec. Many legacy H.323 and H.320 devices do not handle this situation well and will disconnect the call when Cisco Unified CallManager sends a CloseLogicalChannel message to renegotiate the channel to a different value. Thus, you must be careful where and when you disable the Wait for Far-End to Send TCS option.
Multipoint Conferencing
Whenever three or more parties want to engage in the same video call together, a Multipoint Control Unit (MCU) is required. An MCU consists of the following main components:
•
•
The MC handles all aspects of call setup and teardown for the conference, including media negotiation, call signaling, and choosing which MP to use for the call. The MP processes all the audio and video packets. The MC controls the MP, and one MC can control multiple MPs. The MP can be either software-based or hardware-based. Software-based MPs are typically not capable of advanced transcoding, transrating (multiple speeds), or composition features.
Since 1999, Cisco has offered the IP/VC 3500 Series H.323 Multipoint Conference Units (MCUs). The first product in this family was the Cisco Unified Videoconferencing 3510. This model is no longer available for sale, and is not compatible with Cisco Unified CallManager. In 2002, Cisco introduced the IP/VC 3511 and 3540 models. These models offer significantly improved features and scalability unavailable on the older 3510 model.
In 2003, Cisco introduced software version 3.2+ on the IP/VC 3511 and 3540 models, which adds support for the Skinny Client Control Protocol (SCCP). SCCP support is not available on the IP/VC 3510. In addition, there are three types of MPs available in the IP/VC MCUs:
•
•
•
Cisco Unified CallManager Release 4.2 supports the IP/VC 3511 and 3540 models in SCCP and H.323 modes. Each protocol offers different features and is used for different reasons, so each of these MCUs is equipped to run both protocols. The IP/VC 3511 can be configured to run in either SCCP mode or H.323 mode, while the IP/VC 3540 model can be configured to run both protocols simultaneously and divide the total number of available MP resources between the two.
Regardless of signaling protocol, the MCU provides the same basic function of receiving the audio and video streams from each participant and sending those streams back out to all other participants in some sort of combined view. There are two types of views in a multipoint video conference:
•
•
Voice Activation
Voice-activated conferences take in the audio and video streams of all the participants, decide which participant is the dominant speaker, and send only the dominant speaker's video stream back out to all other participants. The participants then see a full-screen image of the dominant speaker (and the current speaker sees the previous dominant speaker). The audio streams from all participants are mixed together, so everyone hears everyone else, but only the dominant speaker's video is displayed.
You can use any of the following methods to select the dominant speaker:
•
Using this mode, the MCU automatically selects the dominant speaker by determining which conference participant is speaking the loudest and the longest. To determine loudness, the MCU calculates the strength of the voice signal for each participant. As conditions change throughout the conversation, the MCU automatically selects a new dominant speaker and switches the video to display that participant. A hold timer prevents the video from switching too hastily. To become the dominant speaker, a participant has to speak for a specified number of seconds and be more dominant than all other participants.
•
The conference controller (or chairperson) can log onto the MCU's web page, highlight a participant, and select that person as the dominant speaker. This action disables voice activity detection, and the dominant speaker remains constant until the chairperson either selects a new dominant speaker or re-enables voice activation mode.
•
With this method, the MCU stays on each participant for a configured period of time and then switches to the next participant in the list. The conference controller (or chairperson) can turn this feature on and off (re-enable voice activation mode) via the web interface.
Continuous Presence
Continuous-presence conferences display some or all of the participants together in a composite view. The view can display from 2 to 16 squares (participants) in a variety of different layouts. Each layout offers the ability to make one of the squares voice-activated, which is useful if there are more participants in the conference than there are squares to display them all in the composite view. For instance, if you are using a four-way view but there are five participants in the call, only four of them will be displayed at any given time. You can make one of the squares in this case voice-activated so that participants 4 and 5 will switch in and out of that square, depending on who is the dominant speaker. The participants displayed in the other three squares would be fixed, and all of the squares can be manipulated via the conference control web-based user interface.
Note
MP Resources
For both types of conferences, the type of MP resource determines which video formats, transrating, and transcoding capabilities the MCU can support. If endpoints connect to the conference at different speeds, a transrating-capable MP is required. The RM and EMP modules are both capable of transrating between speeds. If a transrating-capable MP is not available, the MCU will send out flow-control messages to all the endpoints, instructing them to lower their transmit speed to match the maximum receive rate of the slowest endpoint. For example, if three participants are connected in a 384-kbps conference and a fourth participant joins at 128 kbps, the MCU will send flow-control messages to the other three participants instructing them to lower their transmit rates to match the 128-kbps participant. This method causes all participants to suffer degraded quality because one participant is less capable. A transrating-capable MP would, instead, convert the 128-kbps stream to 384 kbps, and vice versa, so that each participant can enjoy the best quality their connection allows.
For continuous-presence conferences, a transrating-capable MP is also very important. The software-based MP built into the MCU combines all the input streams and sends the resulting combination back out to each participant. For instance, if four participants are connected in a continuous-presence conference at 384 kbps using G.711 audio, each participant will transmit 320 kbps of video and 64 kbps of audio into the MCU. The MCU will take these four input video streams and combine them into the four-way composite view. The MCU will then transmit 1280 kbps of video back to each endpoint, along with the mixed 64 kbps of audio, for a total of 1344 kbps per endpoint. This method is known as Asynchronous Continuous Presence, and it can have a negative impact on bandwidth requirements, call admission control mechanisms, and interoperability with certain devices.
Note
With the RM or EMP modules, the MCU is capable of transrating each input stream before combining them, so that the total output bandwidth matches the input bandwidth. For instance, if the MCU is using the four-quadrant layout and each participant transmits 320 kbps of video and 64 kbps of audio into the MCU, the MCU would essentially transrate each input stream down to 80 kbps, combine them so that the resulting four-quadrant view is 320 kbps of video (4 * 80 kbps), combine this video with the mixed 64 kbps audio, and transmit the final combination back to each participant. This method is known as Synchronous Continuous Presence. Cisco strongly recommends that all continuous-presence conferences use the Synchronous Continuous Presence mode. However, use of this mode means that each MCU must have a transrating-capable MP (such as an RM or EMP) available, which does increase the cost of the MCU.
Note
SCCP MCU Resources
As stated previously, the Cisco Unified Videoconferencing 3511 and 3540 MCUs both offer support for SCCP beginning with software version 3.2+ for those models and with Cisco Unified CallManager Release 4.0. When configured in SCCP mode, Cisco Unified CallManager provides the MC function while the MCU provides the MP function. The SCCP MCU is controlled completely by Cisco Unified CallManager.
Only the following events invoke SCCP MCU resources:
•
•
Participants in either of these types of conferences can include any type of endpoint (that is, video and non-video devices using any signaling protocol that Cisco Unified CallManager supports via any supported gateway type); however, only SCCP endpoints can invoke the SCCP MCU resources. In other words, an H.323 video endpoint cannot invoke an SCCP MCU resource, but an SCCP video endpoint can invoke the resource and then join an H.323 video participant to the call. For example, the user at the SCCP endpoint could press the Conf softkey, dial the directory number of an H.323 client, and then press the Conf softkey again to complete the transaction. The H.323 client will be joined as a participant on the SCCP MCU conference.
However, for ad-hoc conferences initiated via the Conf, Join, or cBarge softkey, the signaling protocol used by the other participants must support the ability to be placed on hold and then have their audio and video channels redirected to the MCU. For H.323 devices (H.323 clients, H.323 gateways, H.320 gateways, and all types of H.323 trunks) Cisco Unified CallManager uses the Empty Capabilities Set (ECS) method defined in the H.245 specification to achieve this functionality. If the H.323 endpoint does not support receiving an ECS message from Cisco Unified CallManager, it will react by hanging up or possibly even crashing and/or rebooting. To work around this problem, you can enable (check) the "MTP Required" option on the H.323 device but assign it a media resource group list (MRGL) that does not contain any MTP devices, and then set the Cisco CallManager Service Parameter "Fail Call if MTP Allocation Fails" to False. (For details, see Media Resource Groups and Lists.) This configuration will cause the softkeys to be greyed out on the phone, disabling the user from invoking any supplementary services with that endpoint, including placing it on hold, conferencing it into an existing call, joining it with an existing call, or barging into an existing call containing that endpoint.
For reservationless conferences via the MeetMe softkey, the signaling protocol used by the other endpoints does not have to support being placed on hold and transferred. For these types of conferences, each endpoint dials the MeetMe dial-in number arranged by the SCCP client who initiated the conference.
Figure 17-7 illustrates how H.323 and SCCP endpoints can participate in the same SCCP conference. In this example, the conference was initiated by an SCCP endpoint using the Conf softkey to invite the three members.
Figure 17-7 Ad-Hoc Conference Between SCCP and H.323 Endpoints
SCCP conferences support voice-activated mode as well as continuous presence. Furthermore, SCCP conferences support the integrated software-based MP of the MCU and the Rate Matching (RM) module as well as the Enhanced Media Processor (EMP) module.
Media Resource Groups and Lists
Cisco Unified CallManager uses media resource groups (MRGs) and media resource group lists (MRGLs) to determine which specific conference bridge resource to use for a given endpoint. How you group the resources is completely at your discretion, but it is typically done either by geographical placement (so that all endpoints at a given site use the MCU closest to them) or by endpoint type (so that video-capable endpoints use a video-capable MCU while audio-only endpoints use a different conference bridge resource). When a user of an SCCP device activates the Conf, Join, or MeetMe softkey, Cisco Unified CallManager uses the MRGL of the initiating endpoint to determine which conference bridge should be used.
Cisco Unified CallManager applies the following criteria, in the order listed, to select which conference bridge resource to use:
1.
2.
Because of this selection process, the video-capable MCU must be at the top of the MRGL for the video-capable SCCP endpoint in order for that MCU to be selected when the user activates the Conf, Join, or MeetMe softkey on that endpoint. However, some endpoints are not dedicated video endpoints. For example, the IP Phone used in conjunction with Cisco Unified Video Advantage might be used for audio-only calls most of the time and for video calls only occasionally. Thus, if you place the MCU at the top of the MRGL for that phone, the MCU will always be chosen even for audio-only conferences that do not involve any video-capable participants. In this scenario, the MCU resources might be wasted on audio-only conferences and not be available to satisfy the request for a video conference when it occurs.
Therefore, Cisco recommends that you carefully select which users you want to give access to the video-capable MCU resources through MRGLs. The following considerations can help you make that selection:
•
•
•
The answers to these selection criteria will be different for every company. One company might deem multipoint video to be a critical feature and be willing to spend the money necessary to outfit their network with enough MCU resources so that, even if a few ports get wasted on audio-only conferences, there will still be resources available to satisfy all of their video conferences. Another company might choose to enable video resources only for their Sony and Tandberg endpoints and assign audio-only conference bridge resources to Cisco Unified Video Advantage users. A third company might choose to enable video resources for all Sony and Tandberg SCCP endpoints and for select Cisco Unified Video Advantage users (perhaps managers and above), but allocate audio-only resources for the rest of the user population.
H.323 MCU Resources
When configured in H.323 mode, the MCU provides the MC function and behaves like an H.323 peer to Cisco Unified CallManager. H.323 MCU conferences can be invoked in a number of different ways, but they all fall into two major categories:
•
•
A scheduled conference uses a scheduling application to reserve the MCU resources in advance of the call. The scheduling function typically is provided through a web-based user interface such as Cisco Unified MeetingPlace, MagicSoft VCWizard, RADVision VCS, Tandberg TMS, or FVC.COM Click to Meet. The scheduling application usually generates an invitation that provides the user with the date and time of the conference, the number of ports reserved for the conference, and the dial-in information. Alternatively, the scheduling system can be configured to dial out to some or all of the participants at the beginning of the conference.
For a reservationless conference, the MCU has a certain number of resources that are available on demand. To create a conference, a user simply dials into the MCU at any time. If that user is the first participant to dial in, the MCU dynamically creates a new conference using the settings defined in the service template. (For more information on service templates, see Service Templates and Prefixes.) Subsequent users who dial into the same conference number are joined to that conference.
Any type of endpoint can create and participate in scheduled and reservationless H.323 conferences. For instance, an SCCP endpoint can dial into the H.323 MCU to create a reservationless conference just as well as an H.323 endpoint can.
Figure 17-8 illustrates how H.323 and SCCP endpoints can participate in the same H.323 conference. In this example, the conference was initiated by an SCCP endpoint that dialed into the H.323 MCU to create a new reservationless conference, and the other two parties subsequently dialed into that conference.
Figure 17-8 SCCP and H.323 Endpoints in a Reservationless Conference
H.323 conferences support both voice-activated and continuous-presence modes. Furthermore, H.323 conferences support all of the MP types, including the integrated software-based MP of the MCU, the Rate Matching (RM) module, and the Enhanced Media Processor (EMP) module.
Service Templates and Prefixes
A service on the MCU defines the settings that pertain to each conference. You can have different services defined for the different types of conferences. Each service defines, at a minimum, the following settings:
•
This setting might include multiple speeds if a transrating-capable MP is used.
•
The minimum number defines how many ports will be reserved at the beginning of the conference. The maximum number defines the maximum number of participants that the MCU will allow to join this conference.
•
•
•
•
•
A conference can include multiple layouts or even dynamic layouts that change as the number of participants in the conference increases or decreases.
•
When the "SCCP service" check-box is enabled (checked), the service is used for SCCP conferences. When this box is disabled (unchecked), the service is used for H.323 conferences.
For H.323 services, each service is assigned a service prefix that is dialed by the endpoints to reach that particular service. The service prefix forms the leading digits of the conference number, and the trailing digits define the conference ID. This format allows multiple conferences to run simultaneously using the same service prefix. For instance, you can have a service prefix of 555, while the full dial string of the conference is seven digits. This scheme would allow for conference numbers in the range of 5550000 through 5559999, with four digits for the conference ID. The user must dial the full string to access the conference. When the call is received by the MCU, the MCU parses the dialed digits to try to match a service prefix. Once it determines which service prefix is being dialed, the MCU then uses the remaining digits as the conference ID. If the conference ID does not exist yet, the MCU creates a new reservationless conference with that ID. If the conference already exists, the user is added to that conference.
SCCP services must also have a service prefix defined, but the digits themselves do not mean anything because users do not "dial" into an SCCP service. The prefix is used only in the SCCP registration messages between Cisco Unified CallManager and the SCCP MCU resource. Users either use the Conf, Join, or cBarge softkeys to access the SCCP MCU conference (ad hoc), or they dial a MeetMe number assigned by Cisco Unified CallManager to join the conference (reservationless). Therefore, the digits you specify for the SCCP service prefix do not matter and can be any digits you wish, such as 999999 for instance. This prefix is not exposed outside of the SCCP signaling between the MCU and Cisco Unified CallManager (that is, it cannot be dialed, it is not included in the MCU's registration with the gatekeeper, and so forth).
Sizing the MCU
As mentioned previously, the current MCU models are the IP/VC 3511 and 3540. The IP/VC 3511 MCU supports a fixed number of ports, while the IP/VC 3540 MCU is a modular system that can accept various sizes of modules. When calculating the total number of ports available, you must also consider the number of sessions that the Audio Transcoder Daughter Card and the Rate Matching (RM) module or Enhanced Media Processor (EMP) module can support. Therefore, consider the following factors when calculating the size of the MCU:
•
This value depends on the speed of the conference; as the speed increases, the number of supported ports decreases.
•
This value depends on which audio codecs are used in the conference.
•
This value depends on how many participants need to be transrated and how many views are in use in the conference.
For specific information about the number of ports supported, refer to the product documentation for your MCU hardware, available on Cisco.com. Due to the almost infinite number of possible variations, it is very difficult to provide any concrete design guidance in this document. Many customers end up with a mixture of SCCP ad-hoc conferences, H.323 reservationless conferences, and H.323 scheduled conferences. The MCUs must be sized to accommodate all of those types of conferences at the correct speeds and video layouts. Needless to say, this can become quite complex to determine. Please consult with your Cisco sales representative for assistance on sizing the MCUs for your particular environment.
IVR for Dial-In Conference
Dial-in conferences typically use an interactive voice response (IVR) system to prompt users to enter the conference ID and the password (if one is configured) of the conference they want to join. You can use either of the following types of IVRs with the Cisco Unified Videoconferencing 3500 Series MCUs:
•
•
The built-in IVR of the MCU has the following characteristics:
•
It cannot prompt the user for the conference ID first. In other words, the users must dial the specific conference number they wish to join, then they are prompted for the password of that conference.
•
•
The only thing that can be customized is the recorded audio file that is played to the user.
If you want to have a single dial-in number and then prompt the user for the conference ID, you can use Cisco Unified IP-IVR in conjunction with the MCU.
Cisco Unified IP-IVR has the following characteristics:
•
•
That is, the calling device must support an out-of-band DTMF method, such as H.245 alpha-numeric on H.323 devices. These out-of-band DTMF messages are then relayed by Cisco Unified CallManager to the Cisco IP IVR server. If the calling device supports only in-band DTMF tones, the Cisco IP IVR server will not recognize them and the calling device will be unable to enter the conference.
•
Customizations can include such things as verifying the user's account against a back-end database before permitting that user to enter into the conference, or queuing the participants until the chairperson joins.
Note
With Cisco Unified IP-IVR, users dial a CTI route point that routes the call to the Cisco Unified IP-IVR server instead of dialing a route pattern that routes directly to the MCU. After collecting the DTMF digits of the conference ID, the Cisco Unified IP-IVR then transfers the call to the route pattern that routes the call to the MCU. This transfer operation requires that the calling device supports having its media channels closed and reopened to a new destination. For example, an H.323 video device that calls the Cisco Unified IP-IVR will initially negotiate an audio channel to the Cisco Unified IP-IVR server and then, after entering the appropriate DTMF digits, it will be transferred to the MCU, at which point Cisco Unified CallManager will invoke the Empty Capabilities Set (ECS) procedure described earlier in this chapter to close the audio channel between the endpoint and the Cisco Unified IP-IVR server and open new logical channels between the endpoint and the MCU. If the H.323 video endpoint does not support receiving an ECS from Cisco Unified CallManager, it will react by disconnecting the call or, worse, crashing and/or rebooting.
Gatekeepers
Prior to the introduction of video support in Cisco Unified CallManager, H.323 videoconferencing networks relied on gatekeepers to perform device registration management, call routing, and bandwidth control. The Cisco IOS Gatekeeper, formerly known as the Multimedia Conference Manager (MCM), provides these functions. However, most gatekeepers, including Cisco's, offer only rudimentary call routing capabilities compared to what might be expected in a typical enterprise-class PBX. When used to route H.323 video calls, Cisco Unified CallManager supplements the basic gatekeeper features and provides full enterprise-class PBX functionality to H.323 video calls.
Cisco Unified CallManager and the gatekeeper work as a team to manage H.323 video endpoints. The gatekeeper handles all Registration, Admission, and Status (RAS) signaling, while Cisco Unified CallManager handles all of the H.225 call signaling and H.245 media negotiations. Therefore, you have to deploy gatekeepers along with the Cisco Unified CallManager servers if RAS signaling procedures are required for the H.323 endpoints in your network, as illustrated in Figure 17-9.
Figure 17-9 Cisco Unified CallManager and IOS Gatekeeper Provide RAS Signaling for H.323 Endpoints
RAS signaling is required any time either of the following conditions exists:
•
If the endpoint uses a static IP address, Cisco Unified CallManager does not require RAS procedures to locate the endpoint. Instead, the endpoint is provisioned in Cisco Unified CallManager Administration with its static IP address, and calls to that H.323 client's directory number are routed directly to that static IP address. If the endpoint does not use a static IP address, then Cisco Unified CallManager must query the gatekeeper to obtain the endpoint's current IP address each time Cisco Unified CallManager extends a call to the endpoint.
•
Most H.323 videoconferencing endpoints are capable of dialing another endpoint directly only when dialing by IP address (that is, the user enters the IP address of the destination endpoint in dotted-decimal format and then pushes the call button). However, if the user dials an E.164-formatted number (a numeric value not in the dotted-decimal format of an IP address) or an H.323-ID (in the format of username or username@domain), most endpoints today provide only one way to resolve these types of destinations - by a RAS query to their gatekeeper. A growing number of endpoints, however, can be configured so that, for any call to an E.164 address, they skip any RAS procedures and instead send an H.225 SETUP message directly to a specified IP address. This method of operation is known as peer-to-peer mode. Tandberg H.323 endpoints are one example that use this mode, in which you can either configure a gatekeeper address for them to register with, or configure the IP address of the Cisco Unified CallManager server they should use. In the latter case, the endpoint sends all calls directly to the specified IP address, bypassing the need for RAS procedures with any gatekeeper.
In addition to managing RAS procedures for H.323 video endpoints, gatekeepers also continue to play an important role in managing dial plan resolution and bandwidth restrictions between Cisco Unified CallManager clusters in large multisite distributed call processing environments. A gatekeeper can also integrate with large numbers of H.323 VoIP gateways within the organization, or it can act as a session border controller between an enterprise IP Telephony network and a service provider VoIP transport network.
Therefore, as it pertains to Cisco IP Video Telephony deployments, the Cisco IOS Gatekeeper can perform one or both of the following roles:
•
An endpoint gatekeeper is configured to manage all RAS procedures for calls to, from, and between H.323 clients, MCUs, and H.320 video gateways. The endpoint gatekeeper directs all such calls to the appropriate Cisco Unified CallManager cluster so that Cisco Unified CallManager can perform all of the H.225 call routing and H.245 media negotiations.
•
An infrastructure gatekeeper is configured to manage all dial plan resolution and bandwidth restrictions (call admission control) between Cisco Unified CallManager clusters, between a Cisco Unified CallManager cluster and a network of H.323 VoIP gateways, or between a Cisco Unified CallManager cluster and a service provider's H.323 VoIP transport network.
In Cisco Unified CallManager Release 4.0, the endpoint gatekeeper and the infrastructure gatekeeper had to run on separate routers, and each endpoint gatekeeper could service only a single Cisco Unified CallManager cluster. If multiple Cisco Unified CallManager clusters existed within the enterprise, a separate endpoint gatekeeper had to be deployed for each Cisco Unified CallManager cluster. With Cisco Unified CallManager Release 4.1 or above, it is possible to combine these roles on a single gatekeeper, using it as an endpoint gatekeeper for one or more Cisco Unified CallManager clusters and as the infrastructure gatekeeper for managing calls between clusters or between a cluster and other H.323 VoIP networks. However, for the following reasons (among others), Cisco recommends that you still separate these roles onto two or more gatekeepers:
•
Depending on the Cisco IOS router platform you choose to deploy and your estimated busy hour call volume, you might need several gatekeepers to handle the load.
•
Putting all of your eggs into one basket may not be wise in a large, multi-national VoIP network. Having gatekeepers placed throughout your network (typically by geography) can provide better fault isolation in the event of a gatekeeper failure.
•
Some configuration aspects of the gatekeeper are global in nature (they pertain to all endpoints registered with that gatekeeper). For example, the command arq reject-unknown-prefix, which may be useful in some H.323 VoIP transport environments, conflicts with the use of the gw-type-prefix <prefix> default-technology command, which is used in endpoint gatekeepers to route calls to Cisco Unified CallManager. While Cisco IOS does not stop you from configuring both commands on the same gatekeeper, the arq reject-unknown-prefix command takes precedence and, therefore, calls to unknown numbers will be rejected instead of being routed to Cisco Unified CallManager. In this case, you would have to use one gatekeeper for the H.323 VoIP transport network and another gatekeeper for the Cisco Unified CallManager cluster(s).
Another example of incompatibility can occur in the way you configure the gatekeeper for redundancy. Most Cisco H.323 voice devices, including Cisco Voice Gateways and Cisco Unified CallManager, support the H.323v3 Alternate Gatekeeper feature, which would allow you to configure the gatekeepers as a gatekeeper cluster using the Gatekeeper Update Protocol (GUP) to keep in sync with each other. However, many H.323 video endpoints do not support Alternate Gatekeeper, so the gatekeepers must be configured to use Hot Standby Routing Protocol (HSRP) for redundancy. You cannot mix and match these two redundancy methods on the same gatekeeper. In this case, you might decide to use a gatekeeper cluster for those endpoints that support Alternate Gatekeeper and an HSRP pair of gatekeepers for those that do not.
Figure 17-10 illustrates a network scenario with two Cisco Unified CallManager clusters. Each cluster consists of SCCP and H.323 clients, H.323 MCUs, and H.320 gateways. To manage the RAS aspects of the H.323 clients, MCUs, and H.320 gateways, an endpoint gatekeeper is deployed with each cluster. A separate infrastructure gatekeeper manages dial plan resolution and bandwidth between the clusters. Gatekeeper redundancy is not shown in the figure, although each of these gatekeepers may actually be multiple gatekeepers configured for either Alternate Gatekeeper or HSRP-based redundancy.
Figure 17-10 Two Cisco Unified CallManager Clusters with Required Gatekeepers
Supported Gatekeeper Platforms
To act as an endpoint gatekeeper with Cisco Unified CallManager 4.1 and above, the Cisco IOS Gatekeeper must run Cisco IOS Release 12.3(11)T or greater. For minimum Cisco IOS release requirements on the infrastructure gatekeeper, see Recommended Hardware and Software Combinations, page A-1.
The following router platforms support the Cisco IOS Gatekeeper:
•
•
•
•
•
•
To determine which release and feature set you should use for your router platform, use the Cisco Feature Navigator (requires a Cisco.com login account), available at
http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp
More information is also available at
That document states that Cisco IOS Release 12.3(11)T provides integrated voice and video services, therefore it is the recommended minimum release.
Endpoint Gatekeepers
An endpoint gatekeeper is required any time both of the following conditions are met:
•
•
–
–
The role of the endpoint gatekeeper is simply to handle the RAS aspects of communications with the endpoints, providing a place for these H.323 endpoints to register. The endpoint gatekeeper responds to all call requests made to, from, or between these endpoints by directing the call to the appropriate Cisco Unified CallManager server(s) so that Cisco Unified CallManager can perform all of the call routing and bandwidth control functions. To accomplish this call routing and bandwidth control, you configure Cisco Unified CallManager to register H.323 trunk(s) with the gatekeeper and configure the gatekeeper to route calls to those trunks for all calls to, from, or within that zone.
Cisco Unified CallManager Release 4.1 introduced a new type of H.323 trunk called the RASAggregator trunk. This type of trunk is used for all H.323 client, H.323 MCU, or H.320 gateway zones, while the gatekeeper-controlled intercluster trunk and gatekeeper-controlled H.225 trunk from previous Cisco Unified CallManager releases are used to integrate with infrastructure gatekeepers. If you have deployed H.323 video endpoints based on the recommendations documented in the IP Video Telephony SRND for Cisco Unified CallManager 4.0, you should modify your configuration to use the new RASAggregator trunk so that you can take advantage of its flexibility. This configuration change should be carefully planned and done at a time when it is convenient for the administrator so as to minimize disruption to the existing H.323 video endpoints. For a description of the procedure for migrating from a Cisco Unified CallManager 4.0 deployment, see Migrating from Cisco Unified CallManager 4.0.
Provisioning H.323 Clients
H.323 clients are provisioned much the same way as other phones are, in that you create a new phone (model type = H.323 Client), assign a directory number to it, and assign it a calling search space, device pool, and so forth. You configure the H.323 clients in Cisco Unified CallManager in one of the following ways. The method you use depends on whether or not the client uses a static IP address and whether or not the client requires RAS procedures to dial E.164 addresses.
•
This type of configuration is used for clients that do not have a static IP address assigned to them (they use a DHCP-assigned address) and that require RAS procedures to dial E.164 addresses. A RASAggregator trunk is used to communicate to and from these clients. (See Figure 17-11 and Figure 17-12.)
•
This type of configuration is used for clients that have a static IP address assigned to them but that require RAS procedures to dial E.164 addresses. While Cisco Unified CallManager can signal directly to them without the need of a gatekeeper to resolve their IP addresses, they are not able to signal directly to Cisco Unified CallManager but instead must query the gatekeeper to resolve the E.164 address they are trying to dial (thus, asynchronous communications). To support these types of clients, you must have at least one gatekeeper-controlled client defined in Cisco Unified CallManager for each zone on the gatekeeper, even if all the clients actually use static IP addresses. In this case, the non-gatekeeper controlled client may be a "dummy" client that does not actually exist. It's purpose is merely to create the RASAggregator trunk so that the gatekeeper will be able to route calls from the clients to Cisco Unified CallManager. (See Figure 17-13 and Figure 17-14.)
•
This type of configuration is used for clients that have a static IP address and are also capable of peer-to-peer signaling (that is, they do not require RAS procedures to dial E.164 numbers). Cisco Unified CallManager signals directly to them, and they signal directly to Cisco Unified CallManager (thus, synchronous communications). No gatekeeper or RASAggregator trunk is needed for this type of client. (See Figure 17-15 and Figure 17-16.)
Figure 17-11 through Figure 17-16 illustrate the call signaling flows used in these three scenarios.
Figure 17-11 Call to Gatekeeper-Controlled Client from Cisco Unified CallManager
Figure 17-12 Call from Gatekeeper-Controlled Client to Cisco Unified CallManager
Figure 17-13 Call to Non-Gatekeeper Controlled Client from Cisco Unified CallManager (Asynchronous)
Figure 17-14 Call from Non-Gatekeeper Controlled Client to Cisco Unified CallManager (Asynchronous)
Figure 17-15 Call to Non-Gatekeeper Controlled Client from Cisco Unified CallManager (Synchronous)
Figure 17-16 Call from Non-Gatekeeper Controlled Client to Cisco Unified CallManager (Synchronous)
Gatekeeper-Controlled Clients
When you configure an H.323 client as gatekeeper-controlled, you may enter any alpha-numeric string (such as a descriptive name) in the Device Name field, check the Gatekeeper-controlled box, and fill in the following fields:
•
The device pool you want the client to use. All H.323 clients (whether gatekeeper-controlled or non-gatekeeper controlled) that are registered in the same zone must use the same device pool. If you accidentally assign different device pools across the endpoints, Cisco Unified CallManager will register multiple RASAggregator trunks within the zone, and an inbound call might be rejected by Cisco Unified CallManager if the call is directed to the wrong RASAggregator trunk.
•
A drop-down list of gatekeeper IP addresses. You must define the gatekeeper in Cisco Unified CallManager before configuring any gatekeeper-controlled H.323 clients.
•
The technology prefix used by the RASAggregator trunk to register in the client zone on the gatekeeper. This technology prefix must match what is configured as the default technology prefix on the gatekeeper. All gatekeeper-controlled H.323 clients that are registered in the same zone must use the same technology prefix. If you accidentally assign different technology prefixes across the endpoints, Cisco Unified CallManager will register multiple RASAggregator trunks within the zone, and an inbound call might be rejected by Cisco Unified CallManager if the call is directed to the wrong RASAggregator trunk. Cisco recommends that you use 1# for this prefix.
•
The (case-sensitive) name of the client zone as configured in the gatekeeper. All gatekeeper-controlled H.323 clients that are registered in the same zone must use the same zone name. If you accidentally assign different zone names (remember, the field is case sensitive) across the endpoints, Cisco Unified CallManager will attempt to register multiple RASAggregator trunks with the gatekeeper (but the one with the incorrect zone name will fail to register), and an inbound call might be rejected by Cisco Unified CallManager if the call is directed to the wrong RASAggregator trunk.
Also, you must set the Cisco CallManager service parameter Send Product ID and Version ID to True. This parameter allows the RASAggregator trunk to register with the gatekeeper as an H323-GW, so that the gatekeeper can direct all H.323 calls to, from, or within the client zone to the RASAggregator trunk.
Non-Gatekeeper Controlled Clients
When provisioning an H.323 client as non-gatekeeper controlled, you must enter the static IP address of the client into the Device Name field and leave all of the settings under the Gatekeeper-controlled section blank (unchecked). Cisco Unified CallManager then uses the static IP address to reach the client any time a call is extended to its directory number.
If the client is configured to use peer-to-peer mode, then no further configuration is required. If the client requires RAS procedures to place calls to E.164 addresses, then you must also configure a dummy gatekeeper-controlled H.323 client in order to create the RASAggregator trunk, by filling in the following fields:
•
A descriptive name that identifies this client as a dummy client used for the purpose of creating the RASAggregator trunk for the client zone.
•
The device pool you chose when configuring the non-gatekeeper controlled H.323 client(s). If the device pool assigned to the dummy client is different than that assigned to the real clients, inbound calls from the real clients might be rejected by Cisco Unified CallManager.
•
A drop-down list of gatekeeper IP addresses. You must define the gatekeeper in Cisco Unified CallManager before configuring the dummy gatekeeper-controlled H.323 client.
•
The technology prefix used by the RASAggregator trunk to register in the client zone on the gatekeeper. This technology prefix must match what is configured as the default technology prefix on the gatekeeper. Cisco recommends that you use 1# for this prefix.
•
The (case-sensitive) name of the client zone as configured in the gatekeeper.
Also, you must set the Cisco CallManager service parameter Send Product ID and Version ID to True. This parameter allows the RASAggregator trunk to register with the gatekeeper as an H323-GW, so that the gatekeeper can direct all H.323 calls to, from, or within the client zone to the RASAggregator trunk.
Provisioning H.323 MCUs
H.323 MCUs are provisioned in Cisco Unified CallManager as H.323 gateways, and then route patterns are configured to extend calls to these devices. When provisioning an H.323 gateway, you must enter the static IP address and TCP signaling port of the MCU into the Device Name field. Cisco Unified CallManager then uses the static IP address and TCP port to reach the MCU any time a call matches the route pattern(s) associated with it.
Note
