1.22 Voice-Messaging Call Flows in SRST and AAR Mode

This topic shows the call flow when the WAN is unavailable or CAC blocks the call.

SRST and Cisco Unity Connection

  • The WAN is down and SRST takes over basic telephony.
  • Add alternate extensions (E.164 number) in Cisco Unity Connection.

When the WAN is unavailable, IP phones register with the SRST router. The figure shows how voice messaging is processed in SRST mode.

By default, there is no activity when a user presses the Messages button after the IP phones have registered with the SRST router. IP phones configured through the following commands can reach the mailbox in case of SRST fallback. Users can leave a message if the called user does not answer or is busy. The following commands need to be configured on the SRST router to offer voice messaging over PSTN as a backup during a WAN failure:

  • call-manager-fallback
  • voicemail 914083552300
  • call-forward busy 914083552300
  • call-forward noan 914083552300 timeout 5

When you dial out, voice translation rules on the voice gateway modify the calling number to the E.164 format for all Cisco Unity Connection users. Therefore, add the alternate number (E.164) for all Cisco Unity Connection users in the centralized voicemail system. Voice translation rules might also modify the redirected number, either outgoing or incoming.

AAR and Cisco Unity Connection

  • Hunt pilot for voicemail needs to be set up for AAR.
  • Redirecting numbers need to be transmitted; outgoing on remote router and incoming on main router.
  • AAR CSS on remote site router needs to be set.
  • Cisco Unity Connection user needs an alternate E.164 number to be configured.

When the WAN is busy and the AAR process takes over call processing, the AAR process rebuilds the voicemail number. This process combines the AAR group, external phone-number mask, and directory number; for example, 91 + 408355XXXX + 2300 = 914083552300. Be sure to configure the AAR CSS in the inbound call section on the remote gateway; otherwise, the calls will not be rerouted over the PSTN.

If a caller dials a remote phone via PSTN and the remote user does not answer, then the call is sent to the voice-messaging system via PSTN. The same behavior occurs if a user presses the Messages button. The redirected number must be sent in addition to the calling and called numbers. If the gateway configuration is not correct, the redirected number cannot be sent and the caller reaches the standard opening greeting.

If the redirected number is sent as an E.164 number, then configure an alternate extension on Cisco Unity Connection. For a call via the PSTN, the calling and redirected numbers are sent in E.164 format. Unless an alternate extension is configured, the standard opening greeting is played instead of the user greeting. Redirected numbers can be modified via voice translation rules.

1.21 Call Flows

This topic describes the call flows in voice messaging and the purpose of the Cisco Unity Connection ports.

Leaving or Retrieving a Message

A PSTN caller dials the number 408 555-1001. The called party has set a CFA to send calls to voicemail. The call is extended to the Cisco Unity Connection system.

The user of IP phone 1001 presses the Messages button to receive the voice messages. Alternatively, the user can dial, from any phone, the voice-messaging number 408 555-2100.

Cisco Unity Connection can notify users when new messages are recorded. The Cisco Unity Connection system starts a call to the mobile phone, which requires the voicemail port to have the CSS to call the PSTN.

Additional Call-Flow Options

  • Voicemail ports can offer different functionalities, and a port can be dedicated to the following:
    1. Answer call
    2. Perform message notification
    3. Send MWI requests
    4. Allow TRAP connections
  • The voicemail port or SIP trunk CSS determines whether calls can be made, in general.

You can add new ports, per server, in an active-active Cisco Unity Connection cluster. The figure shows two ports that are dedicated for MWI dial-out (turn MWI on and MWI off) and six ports that are used to perform message notification and to answer calls so that the calls can be dropped or retrieved.

The ports can be used and dedicated to the four events that are listed in the figure.

1.20 Design Guidelines for Video Greetings

The figure shows the hardware and resource guidelines for planning and sizing Cisco Unity Connection video greetings.

Follow these guidelines when planning to implement video greetings:

  • The video greeting feature is currently supported only using the 7-vCPU OVA template for Cisco Unity Connection. Each server in a Unity Connection cluster can support up to 20 concurrent video calls for a total of 40 video calls within the cluster.
  • Cisco MediaSense must be colocated with Cisco Unity Connection with 1-Gbps connectivity between the servers:
    1. The MediaSense instance must be a single server using the larger 7-vCPU OVA template.
    2. MediaSense must be dedicated for the Cisco Unity Connection video greeting feature.
    3. Less than 10-ms RTT latency is required between the servers when video greetings are used.

The Cisco Unity Connection video greeting feature is currently supported only using the 7-vCPU OVA template. Each server in a Cisco Unity Connection cluster can support up to 20 concurrent video calls for a total of 40 video calls within the cluster. For a single Unity Connection server, 35 concurrent video calls are supported.

Cisco MediaSense must also be deployed using the larger 7-vCPU OVA template. Smaller OVAs will be tested and the design guide will be updated as the testing is completed. This Cisco MediaSense instance must be a single server and cannot be part of a Cisco MediaSense cluster. Also, Cisco MediaSense must be dedicated to the Unity Connection video greeting feature. Only one Cisco Unity Connection high-availability pair or single server can be integrated per Cisco MediaSense server.

Cisco MediaSense must be colocated with Cisco Unity Connection with 1-Gbps connectivity between the servers and less than 10-ms RTT latency.

Video Greetings Operation

Follow these guidelines when planning to implement video greetings:

  • Cisco Unity Connection supports the use of 360p (640 x 360), 480p (720 x 480), 720p (1280 x 720) and 1080p (1920 x 1080) video greetings.
  • Cisco MediaSense and Cisco Unity Connection allow the recording of video greetings up to 1080p (1920 x 1080).
  • Cisco MediaSense does not support transcoding video to reduce the resolution for non-1080p video devices.
  • To restrict video greetings to 360p, Cisco Unity Connection uses Cisco Unified Communications Manager region configurations on the SIP trunk:
    1. Maximum audio bit rate: 64 kbps
    2. Maximum session bit rate for video calls: 600 kbps
    3. Maximum session bit rate for immersive video calls: 600 kbps

p = progressive scan

Video greetings are supported only using SIP trunk integrations. Cisco Unity Connection 10.5.(2) supports the use of 360p (640 x 360), 480p (720 x 480), 720p (1280 x 720), and 1080p (1920 x 1080) video greetings. Cisco MediaSense and Cisco Unity Connection allow the recording of video greetings up to 1080p (1920 x 1080). This situation offers limited compatibility across the video-enabled phone portfolio and is not a supported configuration because Cisco MediaSense does not support transcoding video to reduce the resolution for non-1080p video devices. To restrict video greetings to 360p, Cisco Unity Connection leverages Cisco Unified Communications Manager Region configurations. When video greetings are used in Cisco Unity Connection 10.x, only G.711 mu-law codec is supported for audio and H.264 codec is supported for video. The Cisco Unity Connection SIP trunks must be put in a region that has the following relationship settings, with all other regions containing video-enabled devices that might call Cisco Unity Connection and expect video greetings:

  • Audio Codec Preference List: (default or preference of the administrator)
  • Maximum Audio Bit Rate: 64 kbps
  • Maximum Session Bit Rate for Video Calls: 600 kbps
  • Maximum Session Bit Rate for Immersive Video Calls: 600 kbps

These settings will ensure maximum compatibility across the Cisco video-enabled phone portfolio and provide the best possible experience for using video greetings.

When a video greeting is recorded, the audio and video RTP streams are both sent directly to Cisco Unity Connection. Cisco Unity Connection saves the audio RTP stream locally as an audio-only version of the video greeting and forks the audio and video RTP streams to Cisco MediaSense for recording. For playback, if the device is video-enabled, Cisco Unity Connection will instruct Cisco MediaSense to stream the video greeting to Cisco Unity Connection to be forked to the device. If Cisco MediaSense is not available or unable to play back the video greetings or if the device calling Cisco Unity Connection is not video-enabled, then Cisco Unity Connection will play the audio-only portion of the video greeting that it recorded. The audio-only greeting is the audio track from the video greeting. Different greetings can be used for audio-only callers and for video-enabled callers.

1.19 Video Compatibility Matrix and Network Topology

This topic describes the requirements for video greetings in Cisco Unity Connection and the network topology.

The requirements for video greetings are as follows:

  • Video endpoints with SIP; for example, Cisco Unified IP Phone 9971 or Cisco Jabber for Desktop
  • Video-enabled endpoints with SCCP; for example, Cisco Unified IP Phone 8945
  • Cisco Unity Connection version 10.0(1)
  • Cisco MediaSense version 10.0(1)
  • Cisco Unified Communications Manager version 8.5(1) and later

Cisco Unity Connection must be integrated via SIP.

SIP = Session Initiation Protocol; SCCP = Skinny Client Control Protocol.

Video greetings are available as of Cisco Unity Connection version 10.0(1). Before you can record or play video greetings, you need to integrate video endpoints, Cisco Unified Communications Manager, and Cisco MediaSense into one video-enabled voice-messaging solution. The figure shows an overview of the supported version combinations to configure the video greetings feature.

The supported version combinations are determined by testing. Although other combinations may provide acceptable results to customers, Cisco must test or approve these combinations before they are supported.

For more information go to the Video Greetings in Cisco Unity Connection 10.x document at http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/10x/design/guide/10xcucdgx/10xcucdg070.html#65685.

Network Topology

The overview shows the integration and protocols that are used for video greetings. Only user accounts can be enabled for video greetings.

The figure shows the integration requirements for Cisco Unity Connection video greetings.

If your voice-messaging solution is integrated with SCCP, you need to reconfigure the integration to use SIP. Cisco Unity Connection and Cisco MediaSense can both run as standalone or in a cluster.

Note that the Cisco Unity Connection video greeting feature needs a dedicated Cisco MediaSense server. The Cisco MediaSense server cannot be shared for any other Cisco MediaSense features.

Only user accounts can be enabled for video greetings, and all forms of call handlers remain audio-only. The only way to enable a video-enabled call handler is to use user accounts as call handlers. User accounts have many options that are similar to call handlers and can use input to route calls to other user greetings or to transfer outside of the Cisco Unity Connection system. Each branch in a user-based video-enabled call handler represents one user account. For example, if a root video greeting is built with three options and each of those three options have two suboptions, a total of 10 video-enabled user accounts would be required to facilitate that call handler structure.

1.18 Cisco MediaSense Virtualization and Platform Overlays

This topic describes the virtualization of Cisco MediaSense and the limitations per platform overlay.

Cisco MediaSense can be virtualized.

Node Type vCPU vRAM [GB] vDisk Audio Media Streams Nodes per Cluster
2vCPU Configuration Primary and Secondary Node 2 6 Disk 1: 80 GB for OS Disk 2: 80 (600) GB for Database and working storage Disk 3: 210 GB Minimum. Can be expanded to 12 TB. 40 2
4vCPU Configuration Primary and Secondary Node 4 8 200 2
7vCPU Configuration Primary, Secondary, or Expansion Node 7 16 400 5

Cisco MediaSense also can be virtualized. The table shows the virtual resource requirements and some selected system limitations per OVAtemplate.

The node type can be primary, secondary, or expansion node. Only the 7-vCPU template can be used as an expansion node. Calculate the number of video streams that are required to choose the correct OVA template size. The Cisco MediaSense server has three hard disks for the operating system, the database, and the storage of the recordings. The number of vCPUs has a direct impact on the number of available audio or video streams.

1.17 Cisco MediaSense Overview

This topic describes Cisco MediaSense Cisco Unity Connection video greetings and how to deploy the platform.

Cisco MediaSense is an open-standards, network-based platform that supports the following:

  • Recording, playback, live streaming, and storage of media—including audio and video—with rich recording metadata.
  • It provides an efficient, cost-effective platform for capturing business conversations, including customer service interactions.
  • It supports integration with the Cisco Finesse agent desktop.

In addition to recording and playback, Cisco MediaSense provides media streaming on the network, which supports the following:

  • VoH with Cisco Unified Communications Manager
  • ViQ with Cisco Remote Expert
  • Video greeting with Cisco Unity Connection
  • Live monitoring of customer service calls

Businesses and organizations need to record calls for various reasons, including regulatory compliance, quality management, legal discovery, employee education, business intelligence, and customer service optimization. Unfortunately, traditional recording solutions can make recording difficult and expensive to implement. Cisco MediaSense solves these challenges by recording audio and video on the network, simplifying the architecture, lowering costs, and providing optimum scalability across various scenarios such as selective recording, call transfers, site-based recording, and multiparty conferences.

The network-based architecture of Cisco MediaSense allows for quick availability of the captured media for different applications, regardless of location, through simple APIs. These interfaces implement open web standards, enabling a rich ecosystem of applications from Cisco technology partners, including quality management and advanced quality management solutions.

The new features and benefits of Cisco MediaSense as of version 10.x are as follows:

  • Recording with Cisco Unified Contact Center Express
  • VoH
  • ViQ with Cisco Remote Expert
  • Cisco Unity Connection video greeting
  • Search and play enhancements

Cisco MediaSense is a SIP-based, network-level service that provides voice and video media recording capabilities for other network devices. MediaSense is fully integrated into Cisco’s Unified Communications architecture and automatically captures and stores every VoIP conversation that traverses appropriately configured Unified Communications Manager IP phones or Cisco Unified Border Element devices. In addition, an IP phone user or SIP endpoint device may call the MediaSense system directly in order to leave a recording consisting of media generated only by that user. Such recordings can include video and audio and thus offer a simple and easy method for recording video blogs and podcasts.

No matter how recordings are captured, they may be accessed in several ways. A recording still in progress can be streamed live (“monitored”) through a computer that is equipped with a media player such as VLC or RealPlayer, or one provided by a partner or third party. Completed recordings may be played back in the same way or downloaded in raw form via HTTP. They may also be converted into .mp4 or .wav files and downloaded in that format. All access to recordings, either in progress or completed, is through web-friendly URIs. MediaSense also offers a web-based Search and Play application with a built-in media player that allows authorized users to choose individual calls to monitor, playback, or download directly from a supported web browser. In addition to its primary media recording functionality, MediaSense offers four other capabilities:

  • It can play back specific video media files on demand on video phones or supported players. This capability supports ViQ, VoD, or VoH use cases in which a separate call controller invites MediaSense into an existing video call in order to play a previously designated recording.
  • It can integrate with Cisco Unity Connection to provide video voice-mail greetings. Videos are recorded on MediaSense directly by Cisco Unity Connection subscribers and are then played back to their video-capable callers before they leave their messages.
  • Media recordings occupy a fair amount of disk space, so space management is a significant concern.
  • MediaSense also maintains a metadata database where information about all recordings is maintained. A comprehensive Web 2.0 API is provided that allows client equipment to perform the following actions:
    • Query and search the metadata in various ways
    • Control recordings that are in progress
    • Stream or download recordings
    • Bulk-delete recordings that meet certain criteria
    • Apply custom tags to individual recording sessions.

Five-Server Deployment

Five servers is the maximum in a Cisco MediaSense cluster.

  • Also supported are single-, dual-, three-, and four-server deployments.
  • Dual-server deployments provide high availability and load balancing.

In a Cisco MediaSense deployment, a cluster contains a set of servers, with each server containing a set of services. Cluster architecture provides high availability (for recording but not for playback) and failover (if the primary server fails, there is automatic failover to the secondary server). High-availability servers must be in the same LAN.

Cisco MediaSense functions only within LANs. WANs are not supported. All Cisco MediaSense servers and Cisco Unified Communications Manager servers must be located in the same LAN. Within a LAN, the maximum round-trip delay between any two servers must be less than 2 ms. More details are available in the “MediaSense cluster deployments” section of the “MediaSense Features and Services” chapter in the “MediaSense Use Guide” document at http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/mediasense/911/user_guide/CUMS_BK_M5B01864_00_ms-user-guide-911.html.

The primary and secondary servers in a Cisco MediaSense deployment are synchronized when administrative changes are made on either server. Database replication copies the data automatically from the primary server to the secondary server, and vice versa.

There are three types of servers:

  • Primary (required): Supports all database operations and media operations.
  • Secondary (optional): Supports all database operations and media operations. Provides high-availability for the database.
  • Expansion (optional): Provides additional capacity for media operations, but not for database operations. Expansion servers are used only in 7-vCPU deployments, and are never used in UCS-E module deployments.

The primary and secondary servers in a Cisco MediaSense deployment are synchronized when administrative changes are made on either server. Database replication copies the data automatically from the primary server to the secondary server, and vice versa.

Cisco MediaSense supports any of the following combinations of servers:

  • One primary server
  • One primary server and one expansion server
  • One primary, one secondary server, and from one to three expansion servers

A single-server deployment has one Cisco MediaSense server on the Cisco Collaboration System operating system platform. All network services are enabled by default. Each single-server deployment supports a maximum of 300 simultaneous sessions and a BHCC rate of 9000 sessions per hour (with a 2-minute average call duration).

Single-service deployments enable you to perform the following actions:

  • Add servers later to address redundancy issues
  • Provide high availability
  • Increase storage capacity
  • Increase simultaneous recording capacity

A dual-server deployment has two Cisco MediaSense servers on the Cisco Collaboration System operating system platform. The first server is called the primary server. The second server is called the secondary server. All network services are enabled on both servers. Dual-server deployments provide high availability. The recording load is automatically balanced across the primary and secondary servers because all services are always active on both servers.

Three-server deployments have a primary server, a secondary server, and one expansion server. All network services are enabled by default on all servers in the cluster. The three-server model provides redundancy and increases storage capacity and simultaneous recording and playback capacity. The recording load is automatically balanced across the servers.

Four-server and five-server deployments have one primary server, one secondary server, and two or three expansion servers. This deployment model provides redundancy, increases storage capacity, and increases capacity for simultaneous recording and playback sessions. The recording load is automatically balanced across the servers because services are always active on their respective servers.

1.16 Voice Profile for Internet Mail

This topic describes the VPIM option to connect different kinds of voice-messaging solutions.

  • VPIM is an industry standard that allows different voice-messaging systems to exchange voice and text messages.
  • VPIM is based on the SMTP and MIME protocols.
  • Up to 100 locations or systems are supported.
  • A maximum of 150,000 VPIM contacts are supported.

Cisco Unity Connection supports the VPIM protocol, which is an industry standard that allows different voice-messaging systems to exchange voice and text messages over the Internet or any TCP/IP network. VPIM is based on the SMTP and MIME protocols. VPIM Networking is supported for use with Cisco Business Edition 6000.

Cisco Unity Connection supports up to 100 VPIM locations and 150,000 VPIM and system contacts in the Cisco Unity Connection directory. These limits apply either to the directory of a single Cisco Unity Connection server, cluster pair, or the global directory in a network.

If you deploy VPIM in an HTTPS network, you can designate one or more Cisco Unity Connection locations in the network as VPIM bridgehead servers. The Cisco Unity Connection server that is configured for VPIM networking is referred to as the bridgehead server. This server handles the configuration of VPIM locations and contacts, depending on your requirements. The VPIM location data and all contacts at the VPIM location (including automatically created contacts) are replicated from the bridgehead to other locations within the network. A VPIM message that is sent by a user who is homed on a Cisco Unity Connection location other than the bridgehead first passes to the bridgehead, which forwards the message to the destination server. Similarly, messages from VPIM contacts are received by the bridgehead and relayed to the home server of the Cisco Unity Connection recipient.