Cisco MediaSense Solution Reference Network Design Guide, Release 10.0(1) - Codecs supported [Cisco MediaSense]

Contents
Codecs supported
Codecs supported

Basic recordings

MediaSense can accept

audio in
g.711 µLaw and aLaw

g.722

g.729, g.729a, g.729b

AAC-LD (also known as MP4A/LATM)

and video in h.264 encoding.

Note that off-the-shelf streaming media players typically do not support the AAC-LD, g.722 and g.729 codecs, though the media player which is embedded in the built-in Search and Play application can support either g.722 or g.729 but neither it nor any commonly available media player can support AAC-LD. AAC-LD-based recordings must be converted to .mp4 or .wav format and played as downloaded files. Conversations that use AAC-LD cannot be monitored live.

Neither Unified Communications Manager nor CUBE performs a full codec negotiation with MediaSense. They negotiate codecs among the conversation endpoints first and then initiate a connection to MediaSense. If they happen to select a codec which is not supported by MediaSense, the call will not be recorded.

Therefore, for all phones that need to be recorded, it is important to configure them so that the codec that gets selected for the phones is the codecs that MediaSense supports.

For Unified Communications Manager recording, some of the newer Cisco IP phones support iLBC or iSAC. For those phones, Unified Communications Manager may prefer to negotiate them (if possible). However, since MediaSense does not accept these codecs, they must be disabled for recording enabled devices in Unified Communications Manager's service parameter settings.

MediaSense is capable of recording the audio portion of Telepresence calls among EX-90 and SX-20 devices when the conversation traverses a CUBE device. However, these endpoints must be configured to use a g.711(aLaw or µLaw), g.722, or AAC-LD codec.

Mid-call codec changes may be implemented based on call flow activities—most notably when a call is transferred or conferenced with a phone which has different codec requirements than those which were negotiated during the initial invitation. This is particularly common in CVP-based contact center deployments where a call may be queued at a VXML gateway playing g.711 music, and is then delivered to a g.729 agent.

The results of a mid-call codec change differ depending on whether CUBE or Unified Communications Manager is providing the forked media. With Unified Communications Manager forking, once the recording codec has been established, it cannot be changed. If a remote party transfers the call to a phone which cannot accept the previously selected codec, then Unified Communications Manager tries to insert a transcoder between the two phones so that the recording codec can remain constant. If no transcoder is available, Unified Communications Manager drops the transferred call and terminates the recording.

With CUBE-based forking, the codec is allowed to change. If that happens, MediaSense terminates the existing recording session and begins a new one using the new codec. The conversation then appears in MediaSense in the form of two successive but separate sessions, with different sessionIds, but sharing the same CCID call identifier.

For both CUBE and Unified CM recording, it is not possible for the two audio tracks in a session to be assigned different codecs.

Video greetings

Video voice-mail greetings (used with Unity Connection integration) are designed to work only with Cisco 9971 (or similar) phones using g.711 uLaw or aLaw and with h.264 video. These greetings can only be played back on phones that support these codecs and the video resolution at which the greeting was recorded. When an incompatible phone reaches a video-enabled mailbox, the caller does not see the video portion of the greeting. See http://www.cisco.com/en/US/docs/voice_ip_comm/connection/10x/design/guide/10xcucdg070.html for a detailed list of supported phones.

Uploaded videos

Uploaded videos must be provided in .mp4 format using h.264 for video and AAC-LC for audio (see the exact Studio Specification below). The audio is converted to AAC-LD, g.711 µLaw (not aLaw), and g.722 for streaming playback. Most media players (including the built-in one) and most endpoints (including Cisco 9971 video phones, Jabber soft phones, and Cisco EX-60 and EX-90 Telepresence endpoints) can play at least one of these formats.

	Cisco MediaSense Solution Reference Network Design Guide, Release 10.0(1)
	Codecs supported
Cisco MediaSense Solution Reference Network Design Guide, Release 10.0(1) Product overview Characteristics and features Codecs supported Metadata database and the MediaSense API Disk space management System resiliency and overload throttling MediaSense-specific deployment models Solution environment High availability Security Reporting and call correlation Serviceability and administration Design guidance Compatibility matrix Scalability and sizing Index	Download this chapter Codecs supported Download the complete book Solution Reference Network Design for MediaSense, Release 10.0(1) (PDF - 5 MB) Feedback Contents Codecs supported Codecs supported Basic recordings MediaSense can accept audio in g.711 µLaw and aLaw g.722 g.729, g.729a, g.729b AAC-LD (also known as MP4A/LATM) and video in h.264 encoding. Note that off-the-shelf streaming media players typically do not support the AAC-LD, g.722 and g.729 codecs, though the media player which is embedded in the built-in Search and Play application can support either g.722 or g.729 but neither it nor any commonly available media player can support AAC-LD. AAC-LD-based recordings must be converted to .mp4 or .wav format and played as downloaded files. Conversations that use AAC-LD cannot be monitored live. Neither Unified Communications Manager nor CUBE performs a full codec negotiation with MediaSense. They negotiate codecs among the conversation endpoints first and then initiate a connection to MediaSense. If they happen to select a codec which is not supported by MediaSense, the call will not be recorded. Therefore, for all phones that need to be recorded, it is important to configure them so that the codec that gets selected for the phones is the codecs that MediaSense supports. For Unified Communications Manager recording, some of the newer Cisco IP phones support iLBC or iSAC. For those phones, Unified Communications Manager may prefer to negotiate them (if possible). However, since MediaSense does not accept these codecs, they must be disabled for recording enabled devices in Unified Communications Manager's service parameter settings. MediaSense is capable of recording the audio portion of Telepresence calls among EX-90 and SX-20 devices when the conversation traverses a CUBE device. However, these endpoints must be configured to use a g.711(aLaw or µLaw), g.722, or AAC-LD codec. Mid-call codec changes may be implemented based on call flow activities—most notably when a call is transferred or conferenced with a phone which has different codec requirements than those which were negotiated during the initial invitation. This is particularly common in CVP-based contact center deployments where a call may be queued at a VXML gateway playing g.711 music, and is then delivered to a g.729 agent. The results of a mid-call codec change differ depending on whether CUBE or Unified Communications Manager is providing the forked media. With Unified Communications Manager forking, once the recording codec has been established, it cannot be changed. If a remote party transfers the call to a phone which cannot accept the previously selected codec, then Unified Communications Manager tries to insert a transcoder between the two phones so that the recording codec can remain constant. If no transcoder is available, Unified Communications Manager drops the transferred call and terminates the recording. With CUBE-based forking, the codec is allowed to change. If that happens, MediaSense terminates the existing recording session and begins a new one using the new codec. The conversation then appears in MediaSense in the form of two successive but separate sessions, with different sessionIds, but sharing the same CCID call identifier. For both CUBE and Unified CM recording, it is not possible for the two audio tracks in a session to be assigned different codecs. Video greetings Video voice-mail greetings (used with Unity Connection integration) are designed to work only with Cisco 9971 (or similar) phones using g.711 uLaw or aLaw and with h.264 video. These greetings can only be played back on phones that support these codecs and the video resolution at which the greeting was recorded. When an incompatible phone reaches a video-enabled mailbox, the caller does not see the video portion of the greeting. See http://www.cisco.com/en/US/docs/voice_ip_comm/connection/10x/design/guide/10xcucdg070.html for a detailed list of supported phones. Uploaded videos Uploaded videos must be provided in .mp4 format using h.264 for video and AAC-LC for audio (see the exact Studio Specification below). The audio is converted to AAC-LD, g.711 µLaw (not aLaw), and g.722 for streaming playback. Most media players (including the built-in one) and most endpoints (including Cisco 9971 video phones, Jabber soft phones, and Cisco EX-60 and EX-90 Telepresence endpoints) can play at least one of these formats.
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks