Cisco Cisco MediaSense Release 9.1(1) Guia Do Desenho
Transfers and Conferences
Cisco MediaSense recordings are made up of one or more
. As described above, each media forking session contains two media
sessions
streams, one for the incoming stream and one for the outgoing stream. A simple scenario consisting of a straightforward two-party
conversation is represented entirely by a single session. A multi-party conference is no different: there is still only one stream in either
direction, with the conference bridge itself combining all but one of the parties into a single Cisco MediaSense participant. In the case of
phone forked media, there is an indication in the metadata that one of the streams represents a conference bridge, but in no case does Cisco
MediaSense have the full list of conferenced parties.
conversation is represented entirely by a single session. A multi-party conference is no different: there is still only one stream in either
direction, with the conference bridge itself combining all but one of the parties into a single Cisco MediaSense participant. In the case of
phone forked media, there is an indication in the metadata that one of the streams represents a conference bridge, but in no case does Cisco
MediaSense have the full list of conferenced parties.
Transfers behave somewhat differently depending on whether the call is forked from a Unified CM phone or from a CUBE. With Unified CM
recordings, the forking phone itself anchors the recording. Transfers which end up dropping the forking phone will terminate the recording
session, whereas transfers which keep the forking phone in the conversation do not. With CUBE forking, the situation is more symmetric.
CUBE is an intermediary network element and neither party is an anchor. Therefore, transfers on either side of the device are usually
accommodated within the same recording session. (See Solution Level Deployment Models for more information.)
recordings, the forking phone itself anchors the recording. Transfers which end up dropping the forking phone will terminate the recording
session, whereas transfers which keep the forking phone in the conversation do not. With CUBE forking, the situation is more symmetric.
CUBE is an intermediary network element and neither party is an anchor. Therefore, transfers on either side of the device are usually
accommodated within the same recording session. (See Solution Level Deployment Models for more information.)
When sessions included transfer and conference activities, Cisco MediaSense does its best to retain the related information in its metadata.
Except when conferences are involved, the metadata keeps track of which participants are recorded in which track of the session, as well as
when they entered and exited the conversation. If a recording gets divided into multiple sessions, metadata is also available to help client
applications correlate those sessions together.
Except when conferences are involved, the metadata keeps track of which participants are recorded in which track of the session, as well as
when they entered and exited the conversation. If a recording gets divided into multiple sessions, metadata is also available to help client
applications correlate those sessions together.
Hold and Pause
These two concepts sound similar, but they are not the same:
Hold/Resume takes place as a result of a user pressing a key on his phone. Cisco MediaSense is a passive observer;
Pause/Resume takes place as a result of a client application issuing a Cisco MediaSense API request to temporarily stop recording
while the conversation continues.
Pause/Resume takes place as a result of a client application issuing a Cisco MediaSense API request to temporarily stop recording
while the conversation continues.
Hold/Resume behavior differs depending on which device is forking media. In Unified CM deployments, one party places the call on hold,
blocking all media to or from that party's phone. The other phone typically receives music (MOH). If the forking phone is the one which
invokes the hold operation, then Unified CM actually terminates the recording session, and creates a new recording session once the call is
resumed. Metadata fields allow client applications to gather together all of the sessions in a given conversation. However, this behavior has
implications for live monitoring, since the call being monitored is identified by its recording sessionId. Once the forking phone goes on hold, the
current recording session terminates and the live monitoring listener will hear nothing more, even after the phone call resumes, because it will
be resumed under a new sessionId.
blocking all media to or from that party's phone. The other phone typically receives music (MOH). If the forking phone is the one which
invokes the hold operation, then Unified CM actually terminates the recording session, and creates a new recording session once the call is
resumed. Metadata fields allow client applications to gather together all of the sessions in a given conversation. However, this behavior has
implications for live monitoring, since the call being monitored is identified by its recording sessionId. Once the forking phone goes on hold, the
current recording session terminates and the live monitoring listener will hear nothing more, even after the phone call resumes, because it will
be resumed under a new sessionId.
If the forking phone is not the one which invokes the hold operation, then the recording session continues without a break, and even includes
the music on hold (if it is unicast; multicast MOH does not get recorded).
the music on hold (if it is unicast; multicast MOH does not get recorded).
For CUBE deployments, hold and resume are implemented as direct SIP operations, and the SIP protocol itself has no direct concept of hold
and resume. Instead, these operations are implemented in terms of media stream inactivity events. Cisco MediaSense captures these events
in its metadata and makes it available to application clients if required, but the recording session itself continues uninterrupted.
and resume. Instead, these operations are implemented in terms of media stream inactivity events. Cisco MediaSense captures these events
in its metadata and makes it available to application clients if required, but the recording session itself continues uninterrupted.
The
feature allows applications such as Customer Relationship Management (CRM) systems or VoiceXML-driven IVR systems to
Pause
automatically suppress recording of sensitive information based on the caller's position in a menu or scripted interaction. Pause is invoked by
a Cisco MediaSense API client in order to temporarily stop recording. The result is similar to what happens when you press the Pause button
while recording on a VCR. The subsequent playback will simply skip over the paused segment. Cisco MediaSense does however store the
information in its metadata, and makes it available to application clients if required.
a Cisco MediaSense API client in order to temporarily stop recording. The result is similar to what happens when you press the Pause button
while recording on a VCR. The subsequent playback will simply skip over the paused segment. Cisco MediaSense does however store the
information in its metadata, and makes it available to application clients if required.
The Pause feature behaves identically for CUBE and Unified CM recording.
Direct Inbound Recording
In addition to Compliance Recording, controlled by a CUBE or Unified CM Recording Profile, recordings can be initiated by directly dialing a
number which is associated with Cisco MediaSense, and configured in Cisco MediaSense for automatic recording. Such recordings are not
carried out through media forking technology, and are therefore not limited to CUBE or Cisco IP phones, and they are not limited to audio
media. This is in fact how the Video Blogging use case is accomplished. Even a non-IP phone such as a home phone can be recorded, if it is
converted to IP using a supported codec, via some sort of gateway and delivered to Cisco MediaSense.
number which is associated with Cisco MediaSense, and configured in Cisco MediaSense for automatic recording. Such recordings are not
carried out through media forking technology, and are therefore not limited to CUBE or Cisco IP phones, and they are not limited to audio
media. This is in fact how the Video Blogging use case is accomplished. Even a non-IP phone such as a home phone can be recorded, if it is
converted to IP using a supported codec, via some sort of gateway and delivered to Cisco MediaSense.
Direct Outbound Recording
Using the Cisco MediaSense API, it is possible for a client to request Cisco MediaSense to call a phone number. When the recipient answers,
his call will be recorded just as if he had dialed the recording server as in direct Inbound Recording. The client can be any device capable of
issuing an HTTP request to Cisco MediaSense; for example a button on a web page could cause Cisco MediaSense to call the user's phone,
at which point the system would begin recording his message. Any phone, even a non-IP phone such as a home phone can be recorded, if it
is converted to IP using a supported codec, via some sort of gateway and delivered to Cisco MediaSense. Supported IP video phones can
also be recorded in this way.
his call will be recorded just as if he had dialed the recording server as in direct Inbound Recording. The client can be any device capable of
issuing an HTTP request to Cisco MediaSense; for example a button on a web page could cause Cisco MediaSense to call the user's phone,
at which point the system would begin recording his message. Any phone, even a non-IP phone such as a home phone can be recorded, if it
is converted to IP using a supported codec, via some sort of gateway and delivered to Cisco MediaSense. Supported IP video phones can
also be recorded in this way.
Direct Outbound Recording is only supported if Cisco MediaSense can reach the target phone number through a Unified CM system. In