draft-ietf-siprec-req-06.txt   draft-ietf-siprec-req-07.txt 
DISPATCH K. Rehor, Ed. DISPATCH K. Rehor, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational L. Portman, Ed. Intended status: Informational L. Portman, Ed.
Expires: July 4, 2011 NICE Systems Expires: September 8, 2011 NICE Systems
A. Hutton A. Hutton
Siemens Enterprise Communications Siemens Enterprise Communications
R. Jain R. Jain
IPC Systems IPC Systems
December 31, 2010 March 07, 2011
Requirements for SIP-based Media Recording (SIPREC) Requirements for SIP-based Media Recording (SIPREC)
draft-ietf-siprec-req-06 draft-ietf-siprec-req-07
Abstract Abstract
Session recording is a critical requirement in many business Session recording is a critical requirement in many business
communications environments such as call centers and financial communications environments such as call centers and financial
trading floors. In some of these environments, all calls must be trading floors. In some of these environments, all calls must be
recorded for regulatory and compliance reasons. In others, calls may recorded for regulatory and compliance reasons. In others, calls may
be recorded for quality control or business analytics. be recorded for quality control or business analytics.
Recording is typically done by sending a copy of the session media to Recording is typically performed by sending a copy of the session
the recording devices. This document specifies requirements for media to the recording devices. This document specifies requirements
extensions to SIP that will manage delivery of RTP media from an end- for extensions to SIP that will manage delivery of RTP media to a
point that originates media (or that has access to it) to a recording recording device. This is being referred to as SIP-based Media
device. This is being referred to as SIP-based Media Recording. Recording.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 4, 2011. This Internet-Draft will expire on September 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] and indicate document are to be interpreted as described in [RFC2119] and indicate
requirement levels for compliant mechanisms. requirement levels for compliant mechanisms.
2. Introduction 2. Introduction
skipping to change at page 5, line 37 skipping to change at page 5, line 37
This document only considers active recording, where the Session This document only considers active recording, where the Session
Recording Client purposefully streams media to a Session Recording Recording Client purposefully streams media to a Session Recording
Server. Passive recording, where a recording device detects media Server. Passive recording, where a recording device detects media
directly from the network, is outside the scope of this document. directly from the network, is outside the scope of this document.
3. Definitions 3. Definitions
Session Recording Server (SRS): A Session Recording Server (SRS) is a Session Recording Server (SRS): A Session Recording Server (SRS) is a
SIP User Agent (UA) that is a specialized media server or collector SIP User Agent (UA) that is a specialized media server or collector
that acts as the sink of the recorded media. An SRS is a logical that acts as the sink of the recorded media. An SRS is typically
function that typically archives media for extended durations of time implemented as a multi-port device that is capable of receiving media
and provides interfaces for search and retrieval of the archived from multiple sources simultaneously. An SRS is the sink of the
media. An SRS is typically implemented as a multi-port device that recorded session metadata.
is capable of receiving media from several sources simultaneously.
An SRS is typically also the sink of the recorded session metadata.
Session Recording Client (SRC): A Session Recording Client (SRC) is a Session Recording Client (SRC): A Session Recording Client (SRC) is a
SIP User Agent (UA) that acts as the source of the recorded media, SIP User Agent (UA) that acts as the source of the recorded media,
sending it to the SRS. An SRC is a logical function. Its sending it to the SRS. An SRC is a logical function. Its
capabilities may be implemented across one or more physical devices. capabilities may be implemented across one or more physical devices.
In practice, an SRC could be a personal device (such as a SIP phone), In practice, an SRC could be a personal device (such as a SIP phone),
a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP
Media Server (MS) integrated with an Application Server (AS). This Media Server (MS) integrated with an Application Server (AS). This
specification defines the term SRC such that all such SIP entities specification defines the term SRC such that all such SIP entities
can be generically addressed under one definition. The SRC itself or can be generically addressed under one definition. The SRC provides
another entity working on its behalf (such as a SIP Application metadata to the SRS.
Server) may act as the source of the recording metadata.
Communication Session (CS): A session created between two or more SIP Communication Session (CS): A session created between two or more SIP
User Agents (UAs) that is the target for recording. User Agents (UAs) that is the subject of recording.
Recording Session (RS): The SIP session created between an SRC and Recording Session (RS): The SIP session created between an SRC and
SRS for the purpose of recording a Communication Session. SRS for the purpose of recording a Communication Session.
Figure 1 pictorially represents the relationship between a Recording Figure 1 pictorially represents the relationship between a Recording
Session and Communication Session. Session and Communication Session.
+-------------+ +-----------+ +-------------+ +-----------+
| | Communication Session | | | | Communication Session | |
| A |<------------------------------------>| B | | A |<------------------------------------>| B |
skipping to change at page 7, line 7 skipping to change at page 7, line 7
Metadata: Information that describes recorded media and the CS to Metadata: Information that describes recorded media and the CS to
which they relate. which they relate.
Pause and Resume during a Communication Session: Pause: The action of Pause and Resume during a Communication Session: Pause: The action of
temporarily discontinuing the transmission and collection of RS media temporarily discontinuing the transmission and collection of RS media
Resume: The action of recommencing the transmission and collection of Resume: The action of recommencing the transmission and collection of
RS media RS media
4. Use Cases 4. Use Cases
Use Case 1: Full-time Recording: One (or more, in the case of Use Case 1: Full-time Recording: One Recording Session for each
redundant recording) Recording Session for each Communication Communication Session.
Session.
For example, the diagram below shows the lifecycle of Communication For example, the diagram below shows the lifecycle of Communication
Sessions (CS) and the relationship to the Recording Sessions (RS) Sessions (CS) and the relationship to the Recording Sessions (RS)
CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---| RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---|
Figure 2 Figure 2
skipping to change at page 7, line 41 skipping to change at page 7, line 40
In this example, Communication Sessions 1 and 3 are recorded but CS 2 In this example, Communication Sessions 1 and 3 are recorded but CS 2
is not. is not.
CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |--- RS 1----| |--- RS 2 ---| RS |--- RS 1----| |--- RS 2 ---|
Figure 3 Figure 3
Use Case 3: Dynamic Recording: Start/Stop a Recording Session during Use Case 3: Start/Stop a Recording Session during a Communication
a Communication Session. Session.
The Recording Session starts during a Communication Session, either The Recording Session starts during a Communication Session, either
manually via a user-controlled mechanism (e.g. button on user's manually via a user-controlled mechanism (e.g. button on user's
phone) or automatically via an application (e.g. a Contact Center phone) or automatically via an application (e.g. a Contact Center
customer service application) or business event. A Recording Session customer service application) or business event. A Recording Session
either ends during the Communication Session, or when the either ends during the Communication Session, or when the
Communication Session ends. Communication Session ends. One or more Recording Sessions may
record each Communication Session.
One or more Recording Sessions per Communication Session:
CS |------------- Communication Session -----------| CS |------------- Communication Session -----------|
RS |---- RS 1 ----| |---- RS 2 -----| RS |---- RS 1 ----| |---- RS 2 -----|
Figure 4 Figure 4
Also known as Mid-session or Mid-call Recording.
Use Case 4: Persistent Recording: A single Recording Session captures Use Case 4: Persistent Recording: A single Recording Session captures
one or more Communication Sessions, in sequence (Fig. 6) or in one or more Communication Sessions.
parallel (Fig. 7).
|--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |---------------------- Recording Session ---------------------| RS |---------------------- Recording Session ---------------------|
Figure 5 Figure 5
A Recording Session records continuously without interruption. A Recording Session records continuously without interruption.
Silent periods must be reproduced upon playback (e.g. by recording Periods when there is no CS in progress must be reproduced upon
the silent period, by not recording the silent periods but marking playback (e.g. by recording silence during such periods or by not
them as metadata for a player to utilize, etc.) Applications include recording such periods but marking them by means of metadata for
financial trading desks and emergency (first-responder) service utilization on playback, etc.). Applications include financial
bureaus. The length of a Persistent Recording Sessions is trading desks and emergency (first-responder) service bureaus. The
independent from the length of the actual Communication Sessions. length of a Persistent Recording Session is independent from the
Persistent Recording Sessions avoid issues such as media clipping length of the actual Communication Sessions. Persistent Recording
that can occur due to delays in Recording Session establishment. Sessions avoid issues such as media clipping that can occur due to
delays in Recording Session establishment.
The connection and attributes of media in the Recording Session are The connection and attributes of media in the Recording Session are
not dynamically signaled for each Communication Session before it can not dynamically signaled for each Communication Session before it can
be recorded; however, codec re-negotiation is possible. CS details be recorded; however, codec re-negotiation is possible.
and CS metadata will still be signaled, and can be correlated to the
recorded media. There will still need to be a means of correlating
the recorded media connection/packets to the Communication Session.
In some cases, more than one concurrent Communication Session (on a In some cases, more than one concurrent Communication Session (on a
single end-user apparatus, e.g. trading floor turret) is mixed into single end-user apparatus, e.g. trading floor turret) is mixed into
one Recording Session: one Recording Session:
|-------- CS 1 -------| |-------- CS 1 -------|
|-------- CS 2 -------| |-------- CS 2 -------|
|-------- CS 3 -------| |-------- CS 3 -------|
RS |----------- Recording Session --------------| RS |----------- Recording Session --------------|
skipping to change at page 9, line 29 skipping to change at page 9, line 11
For an active Recording Session, privacy or security reasons may For an active Recording Session, privacy or security reasons may
demand not capturing a specific portion of a conversation. An demand not capturing a specific portion of a conversation. An
example is for PCI (payment card industry) compliance where credit example is for PCI (payment card industry) compliance where credit
card info must be protected. One solution is to not record a caller card info must be protected. One solution is to not record a caller
speaking their credit card information. speaking their credit card information.
An example of a real-time controls is Pause/Resume. An example of a real-time controls is Pause/Resume.
Use Case 6: IVR / Voice Portal Recording. Use Case 6: IVR / Voice Portal Recording.
Self-service Interactive Voice Response (DTMF or ASR) applications Self-service Interactive Voice Response applications may need to be
may need to be recorded for application performance tuning or to meet recorded for application performance tuning or to meet compliance
compliance requirements. requirements.
Metadata about an IVR session recording must include session Metadata about an IVR session recording must include session
information and may include application context information (e.g. information and may include application context information (e.g.
VoiceXML session variables, dialog names, etc.) VoiceXML session variables, dialog names, etc.)
Use Case 7: Enterprise Mobility Recording. Use Case 7: Enterprise Mobility Recording.
Many agents and enterprise workers are not located on company Many agents and enterprise workers whose calls are to be recorded are
premises. not located on company premises.
Examples: Examples:
o Home-based agents or enterprise workers. o Home-based agents or enterprise workers.
o Mobile phones of knowledge workers when they conduct work related o Mobile phones of knowledge workers when they conduct work related
(and legally required recording) calls. i.e. insurance agents, (and legally required recording) calls. e.g. insurance agents,
brokers, physicians. brokers, physicians.
Use Case 8: Geographically distributed or centralized recording. Use Case 8: Geographically distributed or centralized recording.
Global banks with multiple branches up to thousands of small sites. Enterprises such as banks, insurance agencies, and retail stores may
have many locations, possibly up to thousands of small sites.
o Only phones and network infrastructure in branches, no recording Frequently only phones and network infrastructure are installed in
services. branches, without local recording services. In cases where calls
inside or between branches must be recorded, a centralized recording
o Internal calls inside or between branches must be recorded. system in data centers together with telephony infrastructure (e.g.
PBX) me deployed.
o Centralized recording system in data centers together with
telephony infrastructure (e.g. PBX).
Use Case 9: Record complex call scenarios. Use Case 9: Record complex call scenarios.
Record a call that is associated with another call. The following is an example of a scenario where one call that is
recorded must be associated with a related call that also must be
Example: recorded.
o Customer in conversation with Agent o A Customer is in a conversation with a Customer Service Agent.
o Agent puts customer on hold in order to consult with a Supervisor. o Agent puts Customer on hold in order to consult with a Supervisor.
o Agent in conversation with Supervisor. o Agent enters into a conversation with Supervisor.
o Agent disconnects from Supervisor, reconnects with Customer. o Agent disconnects from Supervisor, then reconnects with Customer.
o The Supervisor call must be associated with the original customer o The Supervisor call must be associated with the original customer
call. call.
Use case 10: High availability and continuous recording. Use case 10: High availability and continuous recording.
Specific deployment scenarios present different requirements for Specific deployment scenarios present different requirements for
system availability, error handling, etc. including: system availability, error handling, etc. including:
o An SRS must always be available at call setup time. o An SRS must always be available at call setup time.
o No loss of media recording, including during failure of an SRS. o No loss of media recording, including during failure of an SRS.
o The Communication Session must be terminated (or suitable o The Communication Session must be terminated (or suitable
notification) in the event of a recording failure. notification given to parties) in the event of a recording failure.
Use Case 11: Record multi-channel, multi-media session. Use Case 11: Record multi-channel, multi-media session.
Some applications require the recording of more than one media Some applications require the recording of more than one media
stream, possibly of different types. Media is synchronized, either stream, possibly of different types. Media are synchronized, either
at storage or at playback. at storage or at playback.
Speech analytics technologies (e.g. word spotting, emotion detection, Speech analytics technologies (e.g. word spotting, emotion detection,
speaker identification) may require speaker-separated recordings for speaker identification) may require speaker-separated recordings for
optimum performance. optimum performance.
Multi-modal Contact Centers may include audio, video, IM or other Multi-modal Contact Centers may include audio, video, IM or other
interaction modalities. interaction modalities.
In trading floors environments, in order to save resources, it may be In trading floors environments, in order to minimize storage and
preferable to mix multiple concurrent calls (Communication Sessions) recording system resources, it may be preferable to mix multiple
on different handsets/speakers on the same turret into single concurrent calls (Communication Sessions) on different handsets/
recording session. speakers on the same turret into single recording session.
Use Case 12: Real-time media processing. Use Case 12: Real-time media processing.
Recorder must support real-time media processing, such as speech It must be possible for an SRS to support real-time media processing,
analytics. such as speech analytics of trading floor interactions. Ral-time
analytics may be employed for automatic intervention (stopping
Recording and real-time analytics of trading floor interactions interaction or alerting) if for example, a trader is not following
(including video and instant messaging). Real time analytics is regulations.
required for automatic intervention (stopping interaction or alert)
if for example, trader is not following regulations.
Speaker separation is required in order to reliably detect who is Speaker separation is required in order to reliably detect who is
saying specific phrases. saying specific phrases.
5. Requirements 5. Requirements
The following are requirements for SIP-based Media Recording: The following are requirements for SIP-based Media Recording:
o REQ-001 The mechanism MUST provide a means for "using the SIP o REQ-001 The mechanism MUST provide a means for "using the SIP
protocol for" establishing, maintaining and terminating Recording protocol for" establishing, maintaining and terminating Recording
skipping to change at page 11, line 43 skipping to change at page 11, line 24
o REQ-002 The mechanism MUST support the ability to record all CSs in o REQ-002 The mechanism MUST support the ability to record all CSs in
their entirety. their entirety.
o REQ-003 The mechanism MUST support the ability to record selected o REQ-003 The mechanism MUST support the ability to record selected
CSs in their entirety, according to policy. CSs in their entirety, according to policy.
o REQ-004 The mechanism MUST support the ability to record selected o REQ-004 The mechanism MUST support the ability to record selected
parts of selected CSs. parts of selected CSs.
o REQ-005 The mechanism MUST support the ability to record a CS o REQ-005 The mechanism MUST support the ability to record a CS
without an intentional loss of media (for example, clipping media at without loss of media (for example, clipping media at the beginning
the beginning of the CS) and without impacting the quality or timing of the CS) due to RS recording preparation and also, without
of the CS (for example, delaying the start of the CS while impacting the quality or timing of the CS (for example, delaying the
preparation for recording takes place). See Use Case 4 in Section 5. start of the CS while preparation for recording session). See Use
Case 4 in Section 4 for more details.
o REQ-006 The mechanism MUST support the recording of IVR sessions. o REQ-006 The mechanism MUST support the recording of IVR sessions.
o REQ-007 The mechanism MUST support the recording of RTP media types o REQ-007 The mechanism MUST support the recording of RTP media types
voice, DTMF (as defined by [RFC4733]), video, and text (as defined by voice, DTMF (as defined by [RFC4733]), video, and text (as defined by
[RFC4103]). [RFC4103]).
o REQ-008 The mechanism MUST support the ability for an SRC to o REQ-008 The mechanism MUST support the ability for an SRC to
deliver mixed audio streams from multiple Communication Sessions to deliver mixed audio streams from multiple Communication Sessions to
an SRS. an SRS.
skipping to change at page 12, line 31 skipping to change at page 12, line 11
SRS multiple media streams for a given CS. SRS multiple media streams for a given CS.
o REQ-011 The mechanism MUST support the ability to pause and resume o REQ-011 The mechanism MUST support the ability to pause and resume
the transmission and collection of RS media. the transmission and collection of RS media.
o REQ-012 The mechanism MUST provide the SRS with metadata describing o REQ-012 The mechanism MUST provide the SRS with metadata describing
CSs that are being recorded, including the media being used and the CSs that are being recorded, including the media being used and the
identities of parties involved. identities of parties involved.
o REQ-013 The mechanism MUST provide the SRS with the means to o REQ-013 The mechanism MUST provide the SRS with the means to
correlate RS media with CS participant media described in metadata. correlate RS media with CS participant media.
o REQ-014 Metadata format must be agnostic of the transport protocol. o REQ-014 Metadata format must be agnostic of the transport protocol.
o REQ-015: The mechanism MUST support a means to cancel and discard o REQ-015: The mechanism MUST support a means to stop the recording.
the recording and associated metadata for a CS.
o REQ-016: The mechanism MUST support a means to cancel and discard o REQ-016: The mechanism MUST support a means for a recording-aware
the recording but not the associated metadata for a CS. UA involved in a CS to request at session establishment time that the
CS should be recorded or should not be recorded, the honoring of such
a request being dependent on policy.
o REQ-017 The mechanism MUST support a means for an authorized o REQ-017: The mechanism MUST support a means for a recording-aware
participant involved in a CS to request, prior to the start of UA involved in a CS to request during a session that the recording of
recording, that the CS not be recorded the CS should be started, paused, resumed or stopped, the honoring of
such a request being dependent on policy.
o REQ-018 The mechanism MUST provide a means of indicating to the o REQ-018 The mechanism MUST NOT prevent the application of tones or
participants involved in a CS that their session is being recorded. announcements during recording or at the start of a CS to support
notification to participants that the call is being recorded or may
be recorded.
Examples include: inject tones into the CS from the SRC, play a o REQ-019 The mechanism MUST provide a means of indicating to
message at the beginning of a session, a visual indicator on a recording-aware UAs whether recording is taking place, for
display, etc. appropriate rendering at the user interface.
o REQ-019 The mechanism MUST provide a way for metadata to be o REQ-020 The mechanism MUST provide a way for metadata to be
conveyed to the SRS incrementally during the CS. conveyed to the SRS incrementally during the CS.
o REQ-020 The mechanism MUST NOT prevent high availability o REQ-021 The mechanism MUST NOT prevent high availability
deployments. deployments.
o REQ-021 The mechanism MUST support means to relate Recording
Session(s) with Communication Session(s).
o REQ-022 The mechanism MUST provide the SRS the starting wall clock o REQ-022 The mechanism MUST provide the SRS the starting wall clock
time for each RS media stream corresponding to the CS participant time for each RS media stream corresponding to the CS participant
media. media.
o REQ-023 The mechanism MUST provide the SRS the wall clock time when o REQ-023 The mechanism MUST provide the SRS the wall clock time when
the Recording Session is paused and resumed. the Recording Session is paused and resumed.
o REQ-024 The mechanism MUST support functionality such that if the o REQ-024 The mechanism MUST support functionality such that if the
CS is encrypted, the RS may use the same or different encryption CS is encrypted, the RS may use the same or different encryption
keys. keys.
skipping to change at page 13, line 45 skipping to change at page 13, line 25
o REQ-028 The mechanism MUST ensure that the integrity of the media o REQ-028 The mechanism MUST ensure that the integrity of the media
sent from SRC to SRS is an accurate representation of the original CS sent from SRC to SRS is an accurate representation of the original CS
media. media.
o REQ-029 The mechanism MUST ensure the confidentiality of the o REQ-029 The mechanism MUST ensure the confidentiality of the
Metadata sent from SRC to SRS. Metadata sent from SRC to SRS.
o REQ-030 The mechanism MUST provide a means to support RS o REQ-030 The mechanism MUST provide a means to support RS
confidentiality. confidentiality.
o REQ-031 The mechanism MUST support the ability to deliver to the
SRS multiple media streams of the same media type (e.g. audio,
video). For example in the case of delivering unmixed audio for each
participant in the CS.
6. Privacy Considerations 6. Privacy Considerations
Respecting the privacy rights and wishes of users engaged in a call Respecting the privacy rights and wishes of users engaged in a call
is of paramount importance. In many jurisdictions participants have is of paramount importance. In many jurisdictions participants have
a right to know that the session is being recorded or might be a right to know that the session is being recorded or might be
recorded, and have a right to opt out, either by terminating the call recorded, and have a right to opt out, either by terminating the call
or by demanding that the call not be recorded. Therefore this or by demanding that the call not be recorded. Therefore this
document contains requirements for being able to notify users that a document contains requirements for being able to notify users that a
call is being recorded and for users to be able to request that a call is being recorded and for users to be able to request that a
call not be recorded. Use cases where users participating in a call call not be recorded. Use cases where users participating in a call
skipping to change at page 14, line 19 skipping to change at page 14, line 4
outside the scope of this document. outside the scope of this document.
Requirements for participant notification of recording varies widely Requirements for participant notification of recording varies widely
by jurisdiction. In a given deployment, not all users will be by jurisdiction. In a given deployment, not all users will be
authorized to stop the recording of a CS (although any user can authorized to stop the recording of a CS (although any user can
terminate a CS). Typically users within the domain that is carrying terminate a CS). Typically users within the domain that is carrying
out the recording will be subject to policies of that domain out the recording will be subject to policies of that domain
concerning whether CSs are recorded. For example, in a call centre, concerning whether CSs are recorded. For example, in a call centre,
agents will be subject to policies of the call centre and may or may agents will be subject to policies of the call centre and may or may
not have the right to prevent the recording of a CS or part of a CS. not have the right to prevent the recording of a CS or part of a CS.
Users calling into the call centre, on the other hand, will typically Users calling into the call centre, on the other hand, will typically
have to ask the agent not to record the CS. If the agent is unable have to ask the agent not to record the CS. If the agent is unable
to prevent recording, or if caller does not trust the agent, the only to prevent recording, or if the caller does not trust the agent, the
option generally is to terminate the CS. only option generally is to terminate the CS.
Privacy considerations also extend to what happens to a recording Privacy considerations also extend to what happens to a recording
once it has been created. Typical issues are who can access the once it has been created. Typical issues are who can access the
recording (e.g., receive a copy of the recording, view the metadata, recording (e.g., receive a copy of the recording, view the metadata,
play back the media, etc.), for what purpose can the recording be play back the media, etc.), for what purpose the recording can be
used (e.g., for non-repudiation, for training purposes, for quality used (e.g., for non-repudiation, for training purposes, for quality
control purposes, etc.) and for how long the recording is to be control purposes, etc.) and for how long the recording is to be
retained before deletion. These are typically policies of the domain retained before deletion. These are typically policies of the domain
that makes the recording, rather than policies of individual users that makes the recording, rather than policies of individual users
involved in a recorded CS, whether those users be in the same domain involved in a recorded CS, whether those users be in the same domain
or in a different domain. Taking the call centre example again, or in a different domain. Taking the call centre example again,
agents might be made aware of call centre policy regarding retention agents might be made aware of call centre policy regarding retention
and use of recordings as part of their employment contract, and and use of recordings as part of their employment contract, and
callers from outside the call centre might be given some information callers from outside the call centre might be given some information
about policy when notified that a CS will be recorded (e.g., through about policy when notified that a CS will be recorded (e.g., through
 End of changes. 44 change blocks. 
105 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/