Basic
Recordings
MediaSense can
accept
In MediaSense, the
following frame sizes are supported for the codecs.
Codec
|
Frame Size
|
g.711
|
20 ms
and 40 ms
|
g.722
|
20 ms
|
g.729
|
10 ms
|

Note |
If a user uses
a frame size other than the specified one, MediaSense will record the audio.
However, the audio playback will be choppy.
|
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 Unified Border Element 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 is not 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 and video portion of Telepresence calls among
EX-90 and SX-20 devices when the conversation traverses a Unified Border
Element 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 Unified Border Element or
Unified Communications Manager is providing the forked media. With Unified
Communications Manager (BiB or NBR) 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 Unified
Border Element dial peer-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 Unified
Border Element and Unified Communications Manager recording, it is not possible
for the two audio tracks in a session to be assigned different codecs.