draft-ietf-siprec-req-08.txt   draft-ietf-siprec-req-09.txt 
DISPATCH 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: September 15, 2011 NICE Systems Expires: October 2, 2011 NICE Systems
A. Hutton A. Hutton
Siemens Enterprise Communications Siemens Enterprise
Communications
R. Jain R. Jain
IPC Systems IPC Systems
March 14, 2011 March 31, 2011
Requirements for SIP-based Media Recording (SIPREC) Use Cases and Requirements for SIP-based Media Recording (SIPREC)
draft-ietf-siprec-req-08 draft-ietf-siprec-req-09
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 45 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 September 15, 2011. This Internet-Draft will expire on October 2, 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
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
skipping to change at page 2, line 18 skipping to change at page 2, line 19
(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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] and indicate
requirement levels for compliant mechanisms.
2. 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
support call centers typically employ call recording for quality support call centers typically employ call recording for quality
control or business analytics, with different requirements. control or business analytics, with different requirements.
skipping to change at page 4, line 33 skipping to change at page 4, line 25
session to be played back in a meaningful way, e.g., with correct session to be played back in a meaningful way, e.g., with correct
synchronization between the media. The Communication Session synchronization between the media. The Communication Session
Metadata needs to be conveyed from the Session Recording Client to Metadata needs to be conveyed from the Session Recording Client to
the Session Recording Server. the Session Recording Server.
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.
2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] and indicate
requirement levels for compliant mechanisms.
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 typically that acts as the sink of the recorded media. An SRS is typically
implemented as a multi-port device that is capable of receiving media implemented as a multi-port device that is capable of receiving media
from multiple sources simultaneously. An SRS is the sink of the from multiple sources simultaneously. An SRS is the sink of the
recorded session metadata. 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
skipping to change at page 11, line 8 skipping to change at page 11, line 8
o REQ-009: The mechanism MUST support the ability for an SRC to o REQ-009: The mechanism MUST support the ability for an SRC to
deliver mixed audio streams from different parties of a given deliver mixed audio streams from different parties of a given
Communication Session to an SRS. Communication Session to an SRS.
o REQ-010 The mechanism MUST support the ability to deliver to the o REQ-010 The mechanism MUST support the ability to deliver to the
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 include a means for providing the SRS
CSs that are being recorded, including the media being used and the with metadata describing CSs that are being recorded, including the
identities of parties involved. media being used and the identities of parties involved.
o REQ-013 The mechanism MUST provide the SRS with the means to o REQ-013 The mechanism MUST include a means for the SRS to be able
correlate RS media with CS participant media. to 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 stop the recording. o REQ-015: The mechanism MUST support a means to stop the recording.
o REQ-016: The mechanism MUST support a means for a recording-aware o REQ-016: The mechanism MUST support a means for a recording-aware
UA involved in a CS to request at session establishment time that the 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 CS should be recorded or should not be recorded, the honoring of such
a request being dependent on policy. a request being dependent on policy.
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 provide the SRS the starting wall clock o REQ-022 The mechanism MUST include a means for the SRS to receive
time for each RS media stream corresponding to the CS participant the starting wall clock time for each RS media stream corresponding
media. to the CS participant media.
o REQ-023 The mechanism MUST provide the SRS the wall clock time when o REQ-023 The mechanism MUST include a means for the SRS to receive
the Recording Session is paused and resumed. the wall clock time when 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.
o REQ-025 The mechanism MUST provide means for an SRS to authenticate o REQ-025 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-026 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 ensure that the integrity of the o REQ-027 The mechanism MUST include a means for ensuring that the
metadata sent from SRC to SRS is an accurate representation of the integrity of the metadata sent from SRC to SRS is an accurate
original CS metadata. representation of the original CS metadata.
o REQ-028 The mechanism MUST ensure that the integrity of the media o REQ-028 The mechanism MUST include a means for ensuring that the
sent from SRC to SRS is an accurate representation of the original CS integrity of the media sent from SRC to SRS is an accurate
media. representation of the original CS media.
o REQ-029 The mechanism MUST ensure the confidentiality of the o REQ-029 The mechanism MUST include a means for ensuring 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-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 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, 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
skipping to change at page 12, line 48 skipping to change at page 12, line 48
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
are not informed that the call is or might be recorded are outside are not informed that the call is or might be recorded are outside
the scope of this document. In particular, lawful intercept is the scope of this document. In particular, lawful intercept is
outside the scope of this document. outside the scope of this document.
Requirements for participant notification of recording vary widely by Requirements for participant notification of recording vary widely by
jurisdiction. In a given deployment, not all users will be 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 its participation in a CS). Typically users within the
out the recording will be subject to policies of that domain domain that is carrying out the recording will be subject to policies
concerning whether CSs are recorded. For example, in a call centre, of that domain concerning whether CSs are recorded. For example, in
agents will be subject to policies of the call centre and may or may a call centre, agents will be subject to policies of the call centre
not have the right to prevent the recording of a CS or part of a CS. and may or may not have the right to prevent the recording of a CS or
Users calling into the call centre, on the other hand, will typically part of a CS. Users calling into the call centre, on the other hand,
have to ask the agent not to record the CS. If the agent is unable will typically have to ask the agent not to record the CS. If the
to prevent recording, or if the caller does not trust the agent, the agent is unable to prevent recording, or if the caller does not trust
only option generally is to terminate the CS. the agent, the 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 the recording can 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
skipping to change at page 14, line 14 skipping to change at page 14, line 14
With regards to security implications of the protocol(s), clearly With regards to security implications of the protocol(s), clearly
there is a need for authentication, authorization, eavesdropping there is a need for authentication, authorization, eavesdropping
protection, and non-repudiation for the solution. The SRC needs to protection, and non-repudiation for the solution. The SRC needs to
know the SRS it is communicating with is legitimate, and vice-versa, know the SRS it is communicating with is legitimate, and vice-versa,
even if they are in different domains. Both the signaling and media even if they are in different domains. Both the signaling and media
for the Recording Session need the ability to be authenticated and for the Recording Session need the ability to be authenticated and
protected from eavesdropping and non-repudiation. Requirements are protected from eavesdropping and non-repudiation. Requirements are
detailed in the requirements section. detailed in the requirements section.
Communication Sessions and Recording Sessions can require different
security levels both for signaling and media, depending on deployment
configurations. For some environments, for example, SRS and SRC 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
public network, for example. For other environments, the SRS can be
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
a direct relationship between the security level of Communication
Sessions and the security level of Recording Sessions.
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, and Ram Mohan R for Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and
their significant contributions and assistance with this document and Charles Eckel for their significant contributions and assistance with
Working Group, and to all the members of the DISPATCH WG and SIPREC this document and Working Group, and to all the members of the
WG mailing lists for providing valuable input to this work. DISPATCH WG and SIPREC WG mailing lists for providing valuable input
to this work.
10. Normative References 10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
 End of changes. 21 change blocks. 
50 lines changed or deleted 62 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/