draft-ietf-siprec-req-02.txt   draft-ietf-siprec-req-03.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: April 1, 2011 IPC Systems Expires: April 15, 2011 IPC Systems
L. Portman L. Portman
NICE Systems NICE Systems
A. Hutton A. Hutton
Siemens Enterprise Communications Siemens Enterprise Communications
September 28, 2010 October 12, 2010
Requirements for SIP-based Media Recording (SIPREC) Requirements for SIP-based Media Recording (SIPREC)
draft-ietf-siprec-req-02 draft-ietf-siprec-req-03
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 1, 2011. This Internet-Draft will expire on April 15, 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 16 skipping to change at page 3, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15 11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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 8, line 36 skipping to change at page 8, line 36
CS |------------- Communication Session -----------| CS |------------- Communication Session -----------|
RS |---- RS 1 ----| |---- RS 2 -----| RS |---- RS 1 ----| |---- RS 2 -----|
Figure 5 Figure 5
Also known as Mid-session or Mid-call Recording. Also known as Mid-session or Mid-call Recording.
Use Case 4: Persistent Recording: A single Recording Session captures Use Case 4: Persistent Recording: A single Recording Session captures
one or more Communication Sessions, in sequence (Fig. 6) or in one or more Communication Sessions, in sequence (Fig. 6) or in
parallel (Fig. 7). The recording session is a single RTP stream, parallel (Fig. 7).
therefore consists of a single offer/answer exchange. There may be
mid-session RE-INVITE offer/answer exchanges for codec changes or for
moving the RTP streams to handle failure scenarios.
|--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |---------------------- Recording Session ---------------------| RS |---------------------- Recording Session ---------------------|
Figure 6 Figure 6
A Recording Session records continuously without interruption. A Recording Session records continuously without interruption.
Applications include financial trading desks and emergency (first- Silent periods must be reproduced upon playback (e.g. by recording
responder) service bureaus. The length of a Persistent Recording the silent period, by not recording the silent periods but marking
Sessions is independent from the length of the actual Communication them as metadata for a player to utilize, etc.) Applications include
Sessions. Persistent Recording Sessions avoid issues such as media financial trading desks and emergency (first-responder) service
clipping that can occur due to delays in Recording Session bureaus. The length of a Persistent Recording Sessions is
establishment. independent from the length of the actual Communication Sessions.
Persistent Recording Sessions avoid issues such as media clipping
that can occur due to delays in Recording Session establishment.
The connection and attributes of media in the Recording Session are The connection and attributes of media in the Recording Session are
not dynamically signaled for each Communication Session before it can not dynamically signaled for each Communication Session before it can
be recorded; however, codec re-negotiation is possible. CS details be recorded; however, codec re-negotiation is possible. CS details
and CS metadata will still be signaled, but can be post-correlated to and CS metadata will still be signaled, and can be correlated to the
the recorded media. There will still need to be a means of recorded media. There will still need to be a means of correlating
correlating the recorded media connection/packets to the the recorded media connection/packets to the Communication Session.
Communication Session, however this may be on a permanent filter-type
basis, such as based on a SIP AoR of an agent that is always
recorded.
In some cases, more than one concurrent Communication Session (on a In some cases, more than one concurrent Communication Session (on a
single end-user apparatus, e.g. trading floor turret) is mixed into single end-user apparatus, e.g. trading floor turret) is mixed into
one Recording Session: one Recording Session:
|-------- CS 1 -------| |-------- CS 1 -------|
|-------- CS 2 -------| |-------- CS 2 -------|
|-------- CS 3 -------| |-------- CS 3 -------|
RS |----------- Recording Session --------------| RS |----------- Recording Session --------------|
skipping to change at page 12, line 15 skipping to change at page 12, line 11
o REQ-003 The mechanism MUST support the ability to record selected o REQ-003 The mechanism MUST support the ability to record selected
parts of selected CSs. parts of selected CSs.
o REQ-004 The mechanism MUST support the ability to record a CS o REQ-004 The mechanism MUST support the ability to record a CS
without an intentional loss of media (for example, clipping media at without an intentional loss of media (for example, clipping media at
the beginning of the CS) and without impacting the quality or timing the beginning of the CS) and without impacting the quality or timing
of the CS (for example, delaying the start of the CS while of the CS (for example, delaying the start of the CS while
preparation for recording takes place). See Use Case 4 in Section 5. preparation for recording takes place). See Use Case 4 in Section 5.
o REQ-005 The mechanism MUST support establishing Recording Sessions
from the SRC to the SRS. This requirement typically applies when the
decision about whether a session should be recorded or not resides in
the SRC.
o REQ-006 The mechanism MUST support establishing Recording Sessions
from the SRS to the SRC (SRS initiates recording). This requirement
typically applies when the decision about whether a session should be
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-007bis1 The mechanism MUST support the recording of DTMF in-
Recording Sessions to a working SRS without disconnecting the band audio.
Communication Sessions.
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,
etc.)
o REQ-010 A request for a new Recording Session MUST be redirected to o REQ-007bis2 The mechanism MUST support the recording of DTMF out-
an available SRS. of-band according to RFC2833.
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 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 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.
skipping to change at page 13, line 32 skipping to change at page 13, line 13
correlate RS media with CS participant media described in metadata. correlate RS media with CS participant media described in metadata.
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 a means to cancel and discard a o REQ-022: The mechanism MUST support a means to cancel and discard
Recording Session during a Communication Session. the recording and associated metadata for a Communication Session.
o REQ-022bis: The mechanism MUST support a means to cancel and
discard the recording but not the associated metadata for a
Communication Session.
o REQ-023 The mechanism MUST support a means for a SIP UA involved in o REQ-023 The mechanism MUST support a means for a SIP UA involved in
a CS to request, prior to the start of recording, that the CS not be a CS to request, prior to the start of recording, that the CS not be
recorded recorded
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 The mechanism MUST provide a way for metadata to be
conveyed to the SRS incrementally.
o REQ-028 The mechanism MUST NOT prevent high availability o REQ-028 The mechanism MUST NOT prevent high availability
deployments. 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 provide a means for the Recording o REQ-030 The mechanism MUST provide a means for the Recording
Session identifier so that the Recording Session itself is labeled as Session identifier so that the Recording Session itself is labeled as
a SIP session that is established for the purpose of recording. a SIP session that is established for the purpose of recording.
o REQ-031 If the Communication Session is encrypted, the Recording
Session MUST be able to use the same keys.
o REQ-032 If the Communication Session is encrypted, the Recording o REQ-032 If the Communication Session is encrypted, the Recording
Session MUST use different keys. Session MUST be able to 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, 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
 End of changes. 16 change blocks. 
44 lines changed or deleted 35 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/