(also known as MP4A/LATM)
and video in
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.
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.
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.
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
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.
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
For both CUBE and
Unified CM recording, it is not possible for the two audio tracks in a session
to be assigned different codecs.
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.