draft-ietf-siprec-req-07.txt   draft-ietf-siprec-req-08.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: September 8, 2011 NICE Systems Expires: September 15, 2011 NICE Systems
A. Hutton A. Hutton
Siemens Enterprise Communications Siemens Enterprise Communications
R. Jain R. Jain
IPC Systems IPC Systems
March 07, 2011 March 14, 2011
Requirements for SIP-based Media Recording (SIPREC) Requirements for SIP-based Media Recording (SIPREC)
draft-ietf-siprec-req-07 draft-ietf-siprec-req-08
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 45
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 8, 2011. This Internet-Draft will expire on September 15, 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
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 10. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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 10, line 45 skipping to change at page 9, line 45
interaction modalities. interaction modalities.
In trading floors environments, in order to minimize storage and In trading floors environments, in order to minimize storage and
recording system resources, it may be preferable to mix multiple recording system resources, it may be preferable to mix multiple
concurrent calls (Communication Sessions) on different handsets/ concurrent calls (Communication Sessions) on different handsets/
speakers on the same turret into single 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.
It must be possible for an SRS to support real-time media processing, It must be possible for an SRS to support real-time media processing,
such as speech analytics of trading floor interactions. Ral-time such as speech analytics of trading floor interactions. Real-time
analytics may be employed for automatic intervention (stopping analytics may be employed for automatic intervention (stopping
interaction or alerting) if for example, a trader is not following interaction or alerting) if for example, a trader is not following
regulations. 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
Sessions between a Session Recording Client and a Session Recording Sessions between a Session Recording Client and a Session Recording
Server. Server.
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
skipping to change at page 11, line 40 skipping to change at page 10, line 40
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.
Note: A mixed audio stream is where several Communication Sessions Note: A mixed audio stream is where several related Communication
are carried in a single Recording Session. A mixed media stream is Sessions are carried in a single Recording Session. A mixed media
typically produced by a mixer function. The RS MAY be informed about stream is typically produced by a mixer function. The RS MAY be
the composition of the mixed streams through session metadata. informed about the composition of the mixed streams through session
metadata.
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.
skipping to change at page 13, line 44 skipping to change at page 12, line 45
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
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 varies widely Requirements for participant notification of recording vary widely by
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 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 the caller does not trust the agent, the to prevent recording, or if the caller does not trust the agent, the
only 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 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
skipping to change at page 15, line 30 skipping to change at page 14, line 32
Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, and Ram Mohan R for Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, and Ram Mohan R for
their significant contributions and assistance with this document and their significant contributions and assistance with this document and
Working Group, and to all the members of the DISPATCH WG and SIPREC Working Group, and to all the members of the DISPATCH WG and SIPREC
WG mailing lists for providing valuable input to this work. 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.
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
May 2000.
[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.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733,
December 2006.
Authors' Addresses Authors' Addresses
Ken Rehor (editor) Ken Rehor (editor)
Cisco Systems Cisco Systems
170 West Tasman Dr. 170 West Tasman Dr.
Mail Stop SJC30/2/ Mail Stop SJC30/2/
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: krehor@cisco.com Email: krehor@cisco.com
 End of changes. 13 change blocks. 
40 lines changed or deleted 32 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/