draft-ietf-siprec-req-04.txt   draft-ietf-siprec-req-05.txt 
DISPATCH K. Rehor, Ed. DISPATCH K. Rehor, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational R. Jain Intended status: Informational L. Portman, Ed.
Expires: April 29, 2011 IPC Systems Expires: June 12, 2011 NICE Systems
L. Portman
NICE Systems
A. Hutton A. Hutton
Siemens Enterprise Communications Siemens Enterprise Communications
October 25, 2010 R. Jain
IPC Systems
December 9, 2010
Requirements for SIP-based Media Recording (SIPREC) Requirements for SIP-based Media Recording (SIPREC)
draft-ietf-siprec-req-04 draft-ietf-siprec-req-05
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 done by sending a copy of the session media to
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 April 29, 2011. This Internet-Draft will expire on June 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
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. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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 4, line 24 skipping to change at page 4, line 24
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.
Depending on the country and its regulatory requirements, financial Depending on the country and its regulatory requirements, financial
trading floors typically must record all calls. The recorded media trading floors typically must record all calls. In contrast, call
content must be an exact copy of the actual conversation (i.e. centers typically only record a subset of the calls, and calls must
clipping and loss of media are unacceptable). A new call attempt not fail regardless of the availability of the recording device.
would be automatically rejected if the recording device becomes
temporarily unavailable. An existing call would be dropped in the Respecting the privacy rights and wishes of users engaged in a call
same situation. In contrast, support call centers typically only is of paramount importance. In many jurisdictions participants have
record a subset of the calls, and calls must not fail regardless of a right to know that the session is being recorded or might be
the availability of the recording device. recorded, and have a right to opt out, either by terminating the call
or by demanding that the call not be recorded. Therefore this
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 not be recorded. In addition, lawful intercept is outside the
scope of this document.
Furthermore, the scale and cost burdens vary widely, in all markets, Furthermore, the scale and cost burdens vary widely, in all markets,
where the different needs for solution capabilities such as media where the different needs for solution capabilities such as media
injection, transcoding, and security-related needs do not conform injection, transcoding, and security-related needs do not conform
well to a one-size-fits-all model. If a standardized solution well to a one-size-fits-all model. If a standardized solution
supports all of the requirements from every recording market, but supports all of the requirements from every recording market, but
doing so would be expensive for markets with lesser needs, then doing so would be expensive for markets with lesser needs, then
proprietary solutions for those markets will continue to propagate. proprietary solutions for those markets will continue to propagate.
Care must be taken, therefore, to make a standards-based solution Care must be taken, therefore, to make a standards-based solution
support optionality and flexibility. support optionality and flexibility.
This document specifies requirements for using SIP [RFC3261] between This document specifies requirements for using SIP [RFC3261] between
a Session Recording Client and a Session Recording Server to control a Session Recording Client and a Session Recording Server to control
the recording of media that has been transmitted in the context of a the recording of media that has been transmitted in the context of a
Communication Session." The Session Recording Client is the source Communication Session. A Communication Session is the "call" between
of the recorded media. The Session Recording Server is the sink of participants. The Session Recording Client is the source of the
recorded media. It should be noted that the requirements for the recorded media. The Session Recording Server is the sink of recorded
protocol between a Session Recording Server and Session Recording media. It should be noted that the requirements for the protocol
Client have very similar requirements (such as codec and transport between a Session Recording Server and Session Recording Client have
negotiation, encryption key interchange, firewall traversal) as very similar requirements (such as codec and transport negotiation,
compared to regular SIP media sessions. The choice of SIP for encryption key interchange, firewall traversal) as compared to
session recording provides reuse of an existing protocol. regular SIP media sessions. The choice of SIP for session recording
provides reuse of an existing protocol.
The recorded sessions can be any RTP media sessions including voice, The recorded sessions can be any RTP media sessions including voice,
DTMF (as defined by [RFC4733]), video, and text (as defined by DTMF (as defined by [RFC4733]), video, and text (as defined by
[RFC4103]). [RFC4103]).
An archived session recording is typically comprised of the An archived session recording is typically comprised of the
Communication Session media content and the Communication Session Communication Session media content and the Communication Session
Metadata. The Communication Session Metadata allows recording Metadata. The Communication Session Metadata allows recording
archives to be searched and filtered at a later time and allows a archives to be searched and filtered at a later time and allows a
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 requirements for session metadata the Session Recording Server. (The requirements for session metadata
delivery are specified separately [draft-ram-siprec-metadata-00]). delivery are specified separately [draft-ram-siprec-metadata-00]).
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. In directly from the network, is outside the scope of this document.
addition, lawful intercept 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 a logical
function that typically archives media for extended durations of time function that typically archives media for extended durations of time
and provides interfaces for search and retrieval of the archived and provides interfaces for search and retrieval of the archived
media. An SRS is typically implemented as a multi-port device that media. An SRS is typically implemented as a multi-port device that
is capable of receiving media from several sources simultaneously. is capable of receiving media from several sources simultaneously.
skipping to change at page 6, line 42 skipping to change at page 6, line 47
Figure 1 Figure 1
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.
SIPREC: The set of SIP extensions that supports recording of SIPREC: The set of SIP extensions that supports recording of
Communication Sessions. Communication Sessions.
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 recording of media during a CS. temporarily discontinuing the transmission and collection of RS media
Resume: The action of recommencing the recording of media for a CS Resume: The action of recommencing the transmission and collection of
following a pause. 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 (or more, in the case of
redundant recording) Recording Session for each Communication redundant recording) Recording Session for each 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)
skipping to change at page 12, line 29 skipping to change at page 12, line 29
o REQ-013 The mechanism MUST support the ability to deliver multiple o REQ-013 The mechanism MUST support the ability to deliver multiple
media streams for a given Communication Session over separate media streams for a given Communication Session over separate
Recording Sessions to the SRS. Recording Sessions to the SRS.
o REQ-014 The mechanism MUST support the ability to deliver multiple o REQ-014 The mechanism MUST support the ability to deliver multiple
media streams for a given Communication Session over a single media streams for a given Communication Session over a single
Recording Session to the SRS. Recording Session to the SRS.
o REQ-015 The mechanism MUST support the ability to pause and resume o REQ-015 The mechanism MUST support the ability to pause and resume
the Recording Session from the SRC. the transmission and collection of RS media.
o REQ-016 The mechanism MUST support the ability to pause and resume
the RS from the SRS.
o REQ-017 The mechanism MUST provide the SRS with metadata describing o REQ-017 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-018 The mechanism MUST provide the SRS with the means to o REQ-018 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 described in metadata.
o REQ-021 Metadata format must be agnostic of the transport protocol. o REQ-021 Metadata format must be agnostic of the transport protocol.
skipping to change at page 13, line 17 skipping to change at page 13, line 15
Examples include: inject tones into the CS from the SRC, play a Examples include: inject tones into the CS from the SRC, play a
message at the beginning of a session, a visual indicator on a message at the beginning of a session, a visual indicator on a
display, etc. display, etc.
o REQ-025 The mechanism MUST provide a way for metadata to be o REQ-025 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-028 The mechanism MUST NOT prevent high availability o REQ-028 The mechanism MUST NOT prevent high availability
deployments. deployments.
SECURITY o REQ-033 The mechanism SHALL support means to relate Recording
Session(s) with Communication Session(s).
o REQ-029 The mechanism MUST support a means of providing security o REQ-035 The mechanism MUST provide the SRS the starting clock time
(confidentiality, integrity and authentication) for the SIPREC. for each RS media stream corresponding to the CS participant media.
o REQ-030 The mechanism MUST provide a means for the Recording o REQ-036 The mechanism MUST provide the SRS the clock time when the
Session identifier so that the Recording Session itself is labeled as Recording Session is paused and resumed.
a SIP session that is established for the purpose of recording.
o REQ-032 If the Communication Session is encrypted, the Recording SECURITY
Session MUST be able to use different keys.
o REQ-033 The mechanism SHALL support means to relate Recording o REQ-032 The mechanism MUST support functionality such that if the
Session(s) with Communication Session(s). CS is encrypted, the RS may use different encryption keys.
AUTHENTICATION AUTHENTICATION
o REQ-040 The mechanism SHALL provide means for an SRS to SRC on RS o REQ-040 The mechanism SHALL provide means for an SRS to
initiation. authenticate the SRC on RS initiation.
o REQ-041 The mechanism SHALL provide means for an SRC to o REQ-041 The mechanism SHALL provide means for an SRC to
authenticate SRS on RS initiation. authenticate the SRS on RS initiation.
AUTHORIZATION
o REQ-050 The mechanism SHALL allow only authorized SRC/SRS to
initiate an RS.
INTEGRITY INTEGRITY
o REQ-060 The mechanism SHALL ensure the integrity of the Metadata o REQ-060 The mechanism SHALL ensure that the integrity of the
sent from SRC to SRS. metadata sent from SRC to SRS is an accurate representation of the
original CS metadata.
o REQ-061 The mechanism SHALL ensure the integrity of the Media sent o REQ-061 The mechanism SHALL ensure that the integrity of the media
from SRC to SRS. sent from SRC to SRS is an accurate representation of the original CS
media.
CONFIDENTIALITY CONFIDENTIALITY
o REQ-070 The mechanism SHALL ensure the confidentiality of the o REQ-070 The mechanism SHALL ensure the confidentiality of the
Metadata sent from SRC to SRS. Metadata sent from SRC to SRS.
o REQ-071 The mechanism SHALL ensure the confidentiality of the Media o REQ-071 The mechanism MUST provide a means to support RS
sent from SRC to SRS. confidentiality.
o REQ-072 It SHALL be possible to establish an RS without notifying 6. Privacy Considerations
the CS participants.
o REQ-073 The mechanism SHALL provide means to ensure the Requirements for participant notification of recording varies widely
confidentiality of the encryption keys used in CS. by jurisdiction. In a given deployment, not all users will be
authorized to stop the recording of a CS (although any user can
terminate a CS). Typically users within the domain that is carrying
out the recording will be subject to policies of that domain
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
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
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
option generally is to terminate the CS.
6. Security Considerations Privacy considerations also extend to what happens to a recording
once it has been created. Typical issues are who can access the
recording (e.g., receive a copy of the recording, view the metadata,
play back the media, etc.), for what purpose can the recording be
used (e.g., for non-repudiation, for training purposes, for quality
control purposes, etc.) and for how long the recording is to be
retained before deletion. These are typically policies of the domain
that makes the recording, rather than policies of individual users
involved in a recorded CS, whether those users be in the same domain
or in a different domain. Taking the call centre example again,
agents might be made aware of call centre policy regarding retention
and use of recordings as part of their employment contract, and
callers from outside the call centre might be given some information
about policy when notified that a CS will be recorded (e.g., through
an announcement that says that calls may be recorded for quality
purposes).
This document does not specify any requirements for a user engaged in
a CS to be able to dictate policy for what happens to a recording, or
for such information to be conveyed from an SRC to an SRS, since
typical deployments would not need this. Instead, it is assumed that
the SRS has access to policy applicable to its environment and can
ensure that recordings are stored and used appropriately."
7. Security Considerations
Session recording has substantial security implications, for the SIP Session recording has substantial security implications, for the SIP
UA's being recorded, the SRC, and the SRS. UA's being recorded, the SRC, and the SRS.
For the SIP UA's involved in the Communication Session, the For the SIP UA's involved in the Communication Session, the
requirements in this draft enable the UA to identify that a requirements in this draft enable the UA to identify that a
Communication Session is being recorded and for the UA to request Communication Session is being recorded and for the UA to request
that a given Communication Session is not subject to recording. that a given Communication Session is not subject to recording.
Since humans don't typically look at or know about protocol signaling Since humans don't typically look at or know about protocol signaling
skipping to change at page 14, line 45 skipping to change at page 15, line 26
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 SIPREC needs the ability to be authenticated and protected for the SIPREC needs the ability to be authenticated and protected
from eavesdropping and non-repudiation. Requirements are detailed in from eavesdropping and non-repudiation. Requirements are detailed in
the requirements section. the requirements section.
7. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
8. Acknowledgements 9. Acknowledgements
Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, and Cullen Jennings Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, and Cullen Jennings
for their help with this document, and to all the members of the for their help with this document, and to all the members of the
DISPATCH WG mailing list for providing valuable input to this work. DISPATCH WG mailing list for providing valuable input to this work.
9. Contributors 10. Contributors
In addition to the editors, the following people provided substantial In addition to the editors, the following people provided substantial
technical and writing contributions to this document, listed technical and writing contributions to this document, listed
alphabetically: alphabetically:
Hadriel Kaplan Hadriel Kaplan
Acme Packet Acme Packet
71 Third Ave. 71 Third Ave.
Burlington, MA 01803 Burlington, MA 01803
USA USA
skipping to change at page 15, line 44 skipping to change at page 16, line 23
Sunbury on Thames Middlesex TW16 5DJ Sunbury on Thames Middlesex TW16 5DJ
UK UK
martin.4.palmer@bt.com martin.4.palmer@bt.com
Dave Smith Dave Smith
Genesys, Alcatel-Lucent Genesys, Alcatel-Lucent
2001 Junipero Serra Blvd, Daly City, CA 94014 2001 Junipero Serra Blvd, Daly City, CA 94014
USA USA
dsmith@genesyslab.com dsmith@genesyslab.com
10. Normative References 11. 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, [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
May 2000. 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,
skipping to change at page 16, line 20 skipping to change at page 17, line 4
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
Leon Portman (editor)
Rajnish Jain
IPC Systems
777 Commerce Drive
Fairfield, CT 06825
USA
Email: rajnish.jain@ipc.com
Leon Portman
NICE Systems NICE Systems
8 Hapnina 8 Hapnina
Ra'anana 43017 Ra'anana 43017
Israel Israel
Email: leon.portman@nice.com Email: leon.portman@nice.com
Andrew Hutton Andrew Hutton
Siemens Enterprise Communications Siemens Enterprise Communications
Email: andrew.hutton@siemens-enterprise.com Email: andrew.hutton@siemens-enterprise.com
URI: http://www.siemens-enterprise.com URI: http://www.siemens-enterprise.com
Rajnish Jain
IPC Systems
777 Commerce Drive
Fairfield, CT 06825
USA
Email: rajnish.jain@ipc.com
 End of changes. 29 change blocks. 
80 lines changed or deleted 103 lines changed or added

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