draft-ietf-siprec-req-09.txt   draft-ietf-siprec-req-10.txt 
SIPREC K. Rehor, Ed. SIPREC K. Rehor, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational L. Portman, Ed. Intended status: Informational L. Portman, Ed.
Expires: October 2, 2011 NICE Systems Expires: November 4, 2011 NICE Systems
A. Hutton A. Hutton
Siemens Enterprise Siemens Enterprise
Communications Communications
R. Jain R. Jain
IPC Systems IPC Systems
March 31, 2011 May 03, 2011
Use Cases and Requirements for SIP-based Media Recording (SIPREC) Use Cases and Requirements for SIP-based Media Recording (SIPREC)
draft-ietf-siprec-req-09 draft-ietf-siprec-req-10
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 performed by sending a copy of the session Recording is typically performed by sending a copy of the session
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 October 2, 2011. This Internet-Draft will expire on November 4, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . . 14 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Session recording is a critical operational requirement in many Session recording is a critical operational requirement in many
businesses, especially where voice is used as a medium for commerce businesses, especially where voice is used as a medium for commerce
and customer support. A prime example where voice is used for trade and customer support. A prime example where voice is used for trade
is the financial industry. The call recording requirements in this is the financial industry. The call recording requirements in this
industry are quite stringent. The recorded calls are used for industry are quite stringent. The recorded calls are used for
dispute resolution and compliance. Other businesses such as customer dispute resolution and compliance. Other businesses such as customer
skipping to change at page 8, line 40 skipping to change at page 8, line 40
brokers, physicians. brokers, physicians.
Use Case 8: Geographically distributed or centralized recording. Use Case 8: Geographically distributed or centralized recording.
Enterprises such as banks, insurance agencies, and retail stores may Enterprises such as banks, insurance agencies, and retail stores may
have many locations, possibly up to thousands of small sites. have many locations, possibly up to thousands of small sites.
Frequently only phones and network infrastructure are installed in Frequently only phones and network infrastructure are installed in
branches, without local recording services. In cases where calls branches, without local recording services. In cases where calls
inside or between branches must be recorded, a centralized recording inside or between branches must be recorded, a centralized recording
system in data centers together with telephony infrastructure (e.g. system in data centers together with telephony infrastructure (e.g.
PBX) me deployed. PBX) may be deployed.
Use Case 9: Record complex call scenarios. Use Case 9: Record complex call scenarios.
The following is an example of a scenario where one call that is 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 recorded must be associated with a related call that also must be
recorded. recorded.
o A Customer is in a conversation with a Customer Service 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.
skipping to change at page 11, line 44 skipping to change at page 11, line 44
o REQ-019 The mechanism MUST provide a means of indicating to o REQ-019 The mechanism MUST provide a means of indicating to
recording-aware UAs whether recording is taking place, for recording-aware UAs whether recording is taking place, for
appropriate rendering at the user interface. appropriate rendering at the user interface.
o REQ-020 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-021 The mechanism MUST NOT prevent high availability o REQ-021 The mechanism MUST NOT prevent high availability
deployments. deployments.
o REQ-022 The mechanism MUST include a means for the SRS to receive o REQ-022 The mechanism MUST provide means for facilitating
the starting wall clock time for each RS media stream corresponding synchronization of the recorded media streams and metadata.
to the CS participant media.
o REQ-023 The mechanism MUST include a means for the SRS to receive o REQ-023 The mechanism MUST provide means for facilitating
the wall clock time when the Recording Session is paused and resumed. synchronization among the recorded media streams.
o REQ-024 The mechanism MUST support functionality such that if the o REQ-024 The mechanism MUST provide means to relate recording and
recording controls such as start/stop/pause/resume to the wall clock
time.
o REQ-025 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.
o REQ-025 The mechanism MUST provide means for an SRS to authenticate o REQ-026 The mechanism MUST provide means for an SRS to authenticate
the SRC on RS initiation. the SRC on RS initiation.
o REQ-026 The mechanism MUST provide means for an SRC to authenticate o REQ-027 The mechanism MUST provide means for an SRC to authenticate
the SRS on RS initiation. the SRS on RS initiation.
o REQ-027 The mechanism MUST include a means for ensuring that the o REQ-028 The mechanism MUST include a means for ensuring that the
integrity of the metadata sent from SRC to SRS is an accurate integrity of the metadata sent from SRC to SRS is an accurate
representation of the original CS metadata. representation of the original CS metadata.
o REQ-028 The mechanism MUST include a means for ensuring that the o REQ-029 The mechanism MUST include a means for ensuring that the
integrity of the media sent from SRC to SRS is an accurate integrity of the media sent from SRC to SRS is an accurate
representation of the original CS media. representation of the original CS media.
o REQ-029 The mechanism MUST include a means for ensuring the o REQ-030 The mechanism MUST include a means for ensuring the
confidentiality of the Metadata sent from SRC to SRS. confidentiality of the Metadata sent from SRC to SRS.
o REQ-030 The mechanism MUST provide a means to support RS o REQ-031 The mechanism MUST provide a means to support RS
confidentiality. confidentiality.
o REQ-031 The mechanism MUST support the ability to deliver to the o REQ-032 The mechanism MUST support the ability to deliver to the
SRS multiple media streams of the same media type (e.g. audio, SRS multiple media streams of the same media type (e.g. audio,
video). For example in the case of delivering unmixed audio for each video). For example in the case of delivering unmixed audio for each
participant in the CS. 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
skipping to change at page 14, line 25 skipping to change at page 14, line 27
security levels both for signaling and media, depending on deployment security levels both for signaling and media, depending on deployment
configurations. For some environments, for example, SRS and SRC will configurations. For some environments, for example, SRS and SRC will
be collocated in a secure network region and therefore the RS will be collocated in a secure network region and therefore the RS will
not require the same protection level as a CS that extends over a not require the same protection level as a CS that extends over a
public network, for example. For other environments, the SRS can be public network, for example. For other environments, the SRS can be
located in a public cloud, for example, and the RS will require a located in a public cloud, for example, and the RS will require a
higher protection level than the CS. For these reasons, there is not higher protection level than the CS. For these reasons, there is not
a direct relationship between the security level of Communication a direct relationship between the security level of Communication
Sessions and the security level of Recording Sessions. Sessions and the security level of Recording Sessions.
A malicious or corrupt SRC can tamper with media and metadata
relating to a CS before sending to an SRS. Also CS media and
signaling can be tampered with in the network prior to reaching an
SRC, unless proper means are provided to ensure integrity protection
during transmission on the CS. Means for ensuring the integrity and
correctness of media and metadata emitted by an SRC are outside the
scope of this work. Other organizational and technical controls will
need to be used to prevent tampering.
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. Acknowledgements 9. Acknowledgements
Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings, Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings,
Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper, Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper,
Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and
Charles Eckel for their significant contributions and assistance with Charles Eckel for their significant contributions and assistance with
 End of changes. 17 change blocks. 
19 lines changed or deleted 31 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/