draft-ietf-siprec-req-00.txt   draft-ietf-siprec-req-01.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 R. Jain
Expires: November 28, 2010 IPC Systems Expires: February 2, 2011 IPC Systems
L. Portman L. Portman
NICE Systems NICE Systems
A. Hutton A. Hutton
Siemens Enterprise Communications Siemens Enterprise Communications
May 27, 2010 August 31, 2010
Requirements for SIP-based Media Recording (SIPREC) Requirements for SIP-based Media Recording (SIPREC)
draft-ietf-siprec-req-00 draft-ietf-siprec-req-01
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 November 28, 2010. This Internet-Draft will expire on February 2, 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 13 skipping to change at page 3, line 13
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. Example Deployment Architectures . . . . . . . . . . . . . . . 6 4. Example Deployment Architectures . . . . . . . . . . . . . . . 6
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 16 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
skipping to change at page 10, line 45 skipping to change at page 10, line 45
o Centralized recording system in data centers together with o Centralized recording system in data centers together with
telephony infrastructure (e.g. PBX). telephony infrastructure (e.g. PBX).
Obtain media by forking: Obtain media by forking:
o In data centers (inbound/outbound): fork media in gateway. o In data centers (inbound/outbound): fork media in gateway.
o At branch locations (internal): fork from end points or from site o At branch locations (internal): fork from end points or from site
level gateways. level gateways.
o Conference based solution is not applicable because it will require Use Case 9: Record complex call scenarios.
to reroute all communications via data centers.
Use Case 9: Record complex calls.
Record a call that is associated with another call. Record a call that is associated with another call.
Example: Example:
o Customer in conversation with Agent o Customer in conversation with 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 in conversation with Supervisor.
o Agent disconnects from Supervisor, reconnects with Customer. o Agent disconnects from Supervisor, 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, High Reliability Recording. Use case 10: High availability and continuous recording.
If recorder is not available at call setup time:
o Reject request to establish Communication Session.
o Redirect to alternate recorder.
If recorder has failed during a call, take specific action: Specific deployment scenarios present different requirements for
system availability, error handling, etc. including:
o Fail/Transfer call / fail over to a different recorder (may involve o An SRS must always be available at call setup time.
loss of recording during transition time).
o Failover recovery situation: continuation of a call recorded on a o No loss of media recording, including during failure of an SRS.
different recorder. Protocol must indicate that a Recording Session
is a continuation of a previous Recording Session.
For some use cases, if recording is not available or failed in a o The Communication Session must be terminated (or suitable
middle of the call, original conversation has to be terminated or notification) in the event of a recording failure.
alerted as well.
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 is 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.
skipping to change at page 12, line 40 skipping to change at page 12, line 29
o REQ-002 The mechanism MUST support Selective Recording Sessions. o REQ-002 The mechanism MUST support Selective Recording Sessions.
o REQ-003 The mechanism MUST support Dynamic (on-demand) Recording o REQ-003 The mechanism MUST support Dynamic (on-demand) Recording
Sessions. Sessions.
o REQ-004 The mechanism MUST support Persistent Recording Sessions. o REQ-004 The mechanism MUST support Persistent Recording Sessions.
o REQ-005 The mechanism MUST support establishing Recording Sessions o REQ-005 The mechanism MUST support establishing Recording Sessions
from the SRC to the SRS. This requirement typically applies when the from the SRC to the SRS. This requirement typically applies when the
decision on whether a session should be recorded or not resides in decision about whether a session should be recorded or not resides in
the SRC. the SRC.
o REQ-006 The mechanism MUST support establishing Recording Sessions o REQ-006 The mechanism MUST support establishing Recording Sessions
from the SRS to the SRC. This requirement typically applies when the from the SRS to the SRC (SRS initiates recording). This requirement
decision on whether a session should be recorded or not resides in typically applies when the decision about whether a session should be
the RS. recorded or not resides in the SRS.
o REQ-007 The mechanism MUST support the recording of IVR sessions. o REQ-007 The mechanism MUST support the recording of IVR sessions.
o REQ-008 The mechanism SHOULD support SRS failover and migration of o REQ-008 The mechanism SHOULD support SRS failover and migration of
Recording Sessions to a working SRS without disconnecting the Recording Sessions to a working SRS without disconnecting the
Communication Sessions. Communication Sessions.
o REQ-009 A request for a new Recording Session MUST be rejected by o REQ-009 A request for a new Recording Session MUST be rejected by
the SRS if service is unavailable (e.g. system overload, disk full, the SRS if service is unavailable (e.g. system overload, disk full,
etc.) etc.)
o REQ-010 A request for a new Recording Session MUST be redirected to o REQ-010 A request for a new Recording Session MUST be redirected to
an available SRS. an available SRS.
o REQ-011 If no recording resources are available, appropriate error o REQ-011 If no recording resources are available, appropriate error
message MUST be returned. message MUST be returned.
o REQ-012 The mechanism MUST support the ability for an SRC to o REQ-012 The mechanism MUST support the ability for an SRC to
deliver mixed audio streams from a single or multiple Communication deliver mixed audio streams from multiple Communication Sessions to
Sessions to an SRS. an SRS.
Note: A mixed audio stream is where several Communication Sessions Note: A mixed audio stream is where several Communication Sessions
are carried in a single Recording Session. A mixed media stream is are carried in a single Recording Session. A mixed media stream is
typically produced by a mixer function. The RS MAY be informed about typically produced by a mixer function. The RS MAY be informed about
the composition of the mixed streams through session metadata. the composition of the mixed streams through session metadata.
o REQ-012bis: The mechanism MUST support the ability for an SRC to
deliver mixed audio streams from different parties of a given
Communication Session to an SRS.
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 Recording Session from the SRC.
o REQ-016 The mechanism MUST support the ability to pause and resume o REQ-016 The mechanism MUST support the ability to pause and resume
the Recording Session from the SRS. the Recording Session from the SRS.
o REQ-017 The mechanism MUST support the ability to correlate the o REQ-017 The mechanism MUST provide the SRS with metadata describing
request to record a call with the session being recorded. CSs that are being recorded, including the media being used and the
identities of parties involved.
o REQ-018 The mechanism MUST support the ability to correlate the o REQ-018 The mechanism MUST provide the SRS with the means to
request to record specific media sessions with the SIP session and correlate RS media with CS participant media described in metadata
media to be recorded (Recorded Session).
o REQ-019 The mechanism MUST support the ability to transport the o REQ-019 The mechanism MUST support the ability to transport the
metadata in the same SIP dialog as the Recording Session. metadata in the same SIP dialog as the Recording Session.
o REQ-020 The mechanism MUST support the ability to transport the o REQ-020 The mechanism MUST support the ability to transport the
metadata outside of the Recording Session SIP dialog. metadata outside of the Recording Session SIP dialog.
o REQ-021 Metadata format must be agnostic of the transport protocol. o REQ-021 Metadata format must be agnostic of the transport protocol.
o REQ-022 The mechanism MUST support the ability to correlate o REQ-022: The mechanism MUST support a means to cancel and discard a
metadata to the Recording Session. Recording Session during a Communication Session.
o REQ-023 The mechanism MUST support a means for a SIP UA to request o REQ-023 The mechanism MUST support a means for a SIP UA to request
that a session is not recorded. that a Communication Session is not recorded prior to recording.
o REQ-024 The mechanism MUST provide a means of indicating to the end o REQ-024 The mechanism MUST provide a means of indicating to the end
users of a Communication Session that the session in which they are users of a Communication Session that the session in which they are
participating is being recorded. participating is being recorded.
Examples include: inject tones into the Communication Session from Examples include: inject tones into the Communication Session from
the SRC, play a message at the beginning of a session, a visual the SRC, play a message at the beginning of a session, a visual
indicator on a display, etc. indicator on a display, etc.
o REQ-025 A Recording Session may start at call setup. o REQ-025 The mechanism MUST support the initiation of a Recording
Session at the beginning of a Communication Session.
o REQ-026 A Recording Session may start during a call. o REQ-026 The mechanism MUST support the initiation of a Recording
Session during a Communication Session.
o REQ-027 The mechanism SHOULD support means to avoid clipping media o REQ-027 The mechanism SHOULD support means to avoid clipping media
(leading or trailing samples) when the media is transported from the (leading or trailing samples) when the media is transported from the
SRC to the SRS. SRC to the SRS.
Note: Media clipping can occur due to delays in recording session Note: Media clipping can occur due to delays in recording session
establishment. SRC implementations typically buffer some portion of establishment. SRC implementations typically buffer some portion of
the media to overcome this problem. the media to overcome this problem.
o REQ-028 Recorder MUST provide alarm notifications when a failure o REQ-028 The mechanism MUST NOT prevent high availability
occurs. deployments.
o REQ-029 The mechanism MUST support a means of providing security o REQ-029 The mechanism MUST support a means of providing security
(confidentiality, integrity and authentication) for the SIPREC. (confidentiality, integrity and authentication) for the SIPREC.
o REQ-030 The mechanism MUST enable the Recording Session to identify o REQ-030 The mechanism MUST provide a means for the Recording
itself as a SIP session that is established for the purpose of Session identifier so that the Recording Session itself is labeled as
recording. a SIP session that is established for the purpose of recording.
o REQ-031 The mechanism MUST support the existing SIP security model, o REQ-031 The mechanism MUST support the existing SIP security model,
including eavesdropping protection, authorization and authentication. including eavesdropping protection, authorization and authentication.
o REQ-032 If the Communication Session is encrypted, the Recording o REQ-032 If the Communication Session is encrypted, the Recording
Session must not share the same keys. Session MUST use different keys.
o REQ-033 The mechanism SHALL support means to relate Recording o REQ-033 The mechanism SHALL support means to relate Recording
Session(s) with Communication Session(s). Session(s) with Communication Session(s).
7. Security Considerations 7. Security Considerations
Session recording has substantial security implications, both for the Session recording has substantial security implications, both for the
SIP UA's being recorded, and for the Session Recording Protocol SIP UA's being recorded, and for the Session Recording Protocol
itself in terms of the SRC and SRS. itself in terms of the SRC and SRS.
skipping to change at page 15, line 38 skipping to change at page 15, line 32
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.
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 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.
10. 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
 End of changes. 26 change blocks. 
49 lines changed or deleted 42 lines changed or added

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