draft-ietf-siprec-req-01.txt   draft-ietf-siprec-req-02.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: February 2, 2011 IPC Systems Expires: April 1, 2011 IPC Systems
L. Portman L. Portman
NICE Systems NICE Systems
A. Hutton A. Hutton
Siemens Enterprise Communications Siemens Enterprise Communications
August 31, 2010 September 28, 2010
Requirements for SIP-based Media Recording (SIPREC) Requirements for SIP-based Media Recording (SIPREC)
draft-ietf-siprec-req-01 draft-ietf-siprec-req-02
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 February 2, 2011. This Internet-Draft will expire on April 1, 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. Example Deployment Architectures . . . . . . . . . . . . . . . 6 4. Example Deployment Architectures . . . . . . . . . . . . . . . 6
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 16 11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
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 43 skipping to change at page 4, line 43
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.
It should be noted that the requirements for the protocol between a This document specifies requirements for using SIP [RFC3261] between
Session Recording Server and Session Recording Client have very a Session Recording Client and a Session Recording Server to control
similar requirements (such as codec and transport negotiation, the recording of media that has been transmitted in the context of a
encryption key interchange, firewall traversal) as compared to Communication Session." The Session Recording Client is the source
regular SIP media sessions. The choice of SIP for session recording of the recorded media. The Session Recording Server is the sink of
provides reuse of an existing protocol. This document specifies recorded media. It should be noted that the requirements for the
requirements for using SIP [RFC3261] to record a media session protocol between a Session Recording Server and Session Recording
between a Session Recording Client and a Session Recording Server, Client have very similar requirements (such as codec and transport
The Session Recording Client is the source of the recorded media. negotiation, encryption key interchange, firewall traversal) as
compared to regular SIP media sessions. The choice of SIP for
The Session Recording Server is the sink of recorded media. session recording provides reuse of an existing protocol.
The recorded sessions can be any SIP-based RTP media sessions
including voice, video, and text (as defined by [RFC4103]).
An archived session recording is typically comprised of the session The recorded sessions can be any RTP media sessions including voice,
media content and the session metadata. The session metadata allows video, and text (as defined by [RFC4103]).
recording archives to be searched and filtered at a later time. The
conveyance of session metadata from the Session Recording Client to
the Session Recording Server may or may not be over SIP. The
requirements for session metadata delivery will be specified in a
future revision of this document or in a separate document.
In some situations it may be advantageous to correlate the An archived session recording is typically comprised of the
Communication Session with other information, such as an IM or other Communication Session media content and the Communication Session
text chat session. Metadata. The Communication Session Metadata allows recording
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
synchronization between the media. The Communication Session
Metadata needs to be conveyed from the Session Recording Client to
the Session Recording Server. (The requirements for session metadata
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. In
addition, lawful intercept 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.
An SRS is typically also the sink of the recorded session metadata. An SRS is typically also the sink of the recorded session metadata.
Note that the term "Server" does not imply the SRS is the server side
of a signaling protocol - the SRS may be the initiator of recording
requests, for example.
Session Recording Client (SRC): A Recording Client (SRC) is a SIP Session Recording Client (SRC): A Session Recording Client (SRC) is a
User Agent (UA) that acts as the source of the recorded media, SIP User Agent (UA) that acts as the source of the recorded media,
sending it to the SRS. An SRC is a logical function. Its sending it to the SRS. An SRC is a logical function. Its
capabilities may be implemented across one or more physical devices. capabilities may be implemented across one or more physical devices.
In practice, an SRC could be a personal device (such as a SIP phone), In practice, an SRC could be a personal device (such as a SIP phone),
a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP
Media Server (MS) integrated with an Application Server (AS). This Media Server (MS) integrated with an Application Server (AS). This
specification defines the term SRC such that all such SIP entities specification defines the term SRC such that all such SIP entities
can be generically addressed under one definition. The SRC itself or can be generically addressed under one definition. The SRC itself or
another entity working on its behalf (such as a SIP Application another entity working on its behalf (such as a SIP Application
Server) may act as the source of the recording metadata. Server) may act as the source of the recording metadata.
Communication Session (CS): A session created between two or more SIP Communication Session (CS): A session created between two or more SIP
User Agents (UAs) that is the target for recording. User Agents (UAs) that is the target for recording.
Recording Session (RS): The SIP session created between an SRC and Recording Session (RS): The SIP session created between an SRC and
SRS for the purpose of recording a Communication Session. SRS for the purpose of recording a Communication Session.
Figure 1 pictorially represents the relationship between a Recording
Session and Communication Session.
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| (Session Recording Client) | | (Session Recording Client) |
| +-------------+ +-----------+ | | +-------------+ +-----------+ |
| | | Communication Session | | | | | | Communication Session | | |
| | A |<------------------------->| B | | | | A |<------------------------->| B | |
| | | | | | | | | | | |
| +-------------+ +-----------+ | | +-------------+ +-----------+ |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| |
| Recording | Recording
skipping to change at page 6, line 35 skipping to change at page 6, line 34
+-------------+ +-------------+
| | | |
| Session | | Session |
| Recording | | Recording |
| Server | | Server |
| | | |
+-------------+ +-------------+
Figure 1 Figure 1
Metadata: Data that describes the Communication Session and Recording Metadata: Information that describes recorded media and the CS to
Session.. 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/Resume recording: Pause: Temporarily discontinue capture and Pause and Resume during a Communication Session: Pause: The action of
storage of the incoming media stream. Recording may continue via the temporarily discontinuing the recording of media during a CS.
Resume command. Resume: Continue capture and storage of the incoming Resume: The action of recommencing the recording of media for a CS
media stream into the same recording session. following a pause.
4. Example Deployment Architectures 4. Example Deployment Architectures
A recording system deployment consists of the Recording Client and A recording system deployment consists of the Recording Client and
Recording Server. Recording Control is bi-directional; Recording Recording Server. Recording Control is bi-directional; Recording
Media and Call Metadata are sent from the RC to RS. Media and Communication Session (CS) Metadata are sent from the SRC
to SRS.
+-------------+ +--------------+ +-------------+ +--------------+
| | Call Metadata | | | | CS Metadata | |
| Session |-------------------------->| Session | | Session |-------------------------->| Session |
| Recording | | Recording | | Recording | | Recording |
| Client | Recording Control | Server | | Client | Recording Control | Server |
| (SRC) |<------------------------->| (SRS) | | (SRC) |<------------------------->| (SRS) |
| | | | | | | |
| | Recorded Media | | | | Recorded Media | |
| |-------------------------->| | | |-------------------------->| |
| | | | | | | |
+-------------+ +--------------+ +-------------+ +--------------+
skipping to change at page 7, line 36 skipping to change at page 7, line 35
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)
CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---| RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---|
Figure 3 Figure 3
Record every call for specific extension/person. One Recording Record every call for specific extension/person.
Session is created per Communication Session.
The need to record all calls is typically due to business process The need to record all calls is typically due to business process
purposes (such as transaction confirmation or dispute resolution) or purposes (such as transaction confirmation or dispute resolution) or
to ensure compliance with governmental regulations. Applications to ensure compliance with governmental regulations. Applications
include enterprise, contact center, and financial trading floors. include enterprise, contact center, and financial trading floors.
Also commonly known as Total Recording. Also commonly known as Total Recording.
Use Case 2: Selective Recording: Start a Recording Session when a Use Case 2: Selective Recording: Start a Recording Session when a
Communication Session is established. Only specific calls are Communication Session to be recorded is established.
recorded, possibly based on business rules. A Communication Session
may or may not have a Recording Session (record only specific calls).
In this example, Communication Sessions 1 and 3 are recorded but CS 2 In this example, Communication Sessions 1 and 3 are recorded but CS 2
is not. is not.
CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |--- RS 1----| |--- RS 2 ---| RS |--- RS 1----| |--- RS 2 ---|
Figure 4 Figure 4
skipping to change at page 8, line 34 skipping to change at page 8, line 34
One or more Recording Sessions per Communication Session: One or more Recording Sessions per Communication Session:
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.
Applications include:
o Enterprise back office recording where only specific calls (based
on privacy) have to be recorded
o A user requests session recording at call setup time or during a
call.
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). The recording session is a single RTP stream,
therefore consists of a single offer/answer exchange. There may be therefore consists of a single offer/answer exchange. There may be
mid-session RE-INVITE offer/answer exchanges for codec changes or for mid-session RE-INVITE offer/answer exchanges for codec changes or for
moving the RTP streams to handle failure scenarios. 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 ---------------------|
skipping to change at page 9, line 21 skipping to change at page 9, line 9
A Recording Session records continuously without interruption. A Recording Session records continuously without interruption.
Applications include financial trading desks and emergency (first- Applications include financial trading desks and emergency (first-
responder) service bureaus. The length of a Persistent Recording responder) service bureaus. The length of a Persistent Recording
Sessions is independent from the length of the actual Communication Sessions is independent from the length of the actual Communication
Sessions. Persistent Recording Sessions avoid issues such as media Sessions. Persistent Recording Sessions avoid issues such as media
clipping that can occur due to delays in Recording Session clipping that can occur due to delays in Recording Session
establishment. 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. Call details be recorded; however, codec re-negotiation is possible. CS details
and metadata will still be signaled, but can be post- correlated to and CS metadata will still be signaled, but can be post-correlated to
the recorded media. There will still need to be a means of the recorded media. There will still need to be a means of
correlating the recorded media connection/packets to the correlating the recorded media connection/packets to the
Communication Session, however this may be on a permanent filter-type 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 basis, such as based on a SIP AoR of an agent that is always
recorded. 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:
skipping to change at page 9, line 49 skipping to change at page 9, line 37
Figure 7 Figure 7
Use Case 5: Real-time Recording Controls. Use Case 5: Real-time Recording Controls.
For an active Recording Session, privacy or security reasons may For an active Recording Session, privacy or security reasons may
demand not capturing a specific portion of a conversation. An demand not capturing a specific portion of a conversation. An
example is for PCI (payment card industry) compliance where credit example is for PCI (payment card industry) compliance where credit
card info must be protected. One solution is to not record a caller card info must be protected. One solution is to not record a caller
speaking their credit card information. speaking their credit card information.
Real-time controls may include Pause/Resume, or Mute/Unmute. An example of a real-time controls is Pause/Resume.
Use Case 6: IVR / Voice Portal Recording. Use Case 6: IVR / Voice Portal Recording.
Self-service Interactive Voice Response (DTMF or ASR) applications Self-service Interactive Voice Response (DTMF or ASR) applications
may need to be recorded for application performance tuning or to meet may need to be recorded for application performance tuning or to meet
compliance requirements. compliance requirements.
Metadata about an IVR session recording must include session Metadata about an IVR session recording must include session
information and may include application context information (e.g. information and may include application context information (e.g.
VoiceXML session variables, dialog names, etc.) VoiceXML session variables, dialog names, etc.)
skipping to change at page 10, line 38 skipping to change at page 10, line 26
Global banks with multiple branches up to thousands of small sites. Global banks with multiple branches up to thousands of small sites.
o Only phones and network infrastructure in branches, no recording o Only phones and network infrastructure in branches, no recording
services. services.
o Internal calls inside or between branches must be recorded. o Internal calls inside or between branches must be recorded.
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:
o In data centers (inbound/outbound): fork media in gateway.
o At branch locations (internal): fork from end points or from site
level gateways.
Use Case 9: Record complex call scenarios. Use Case 9: Record complex call scenarios.
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 and continuous recording. Use case 10: High availability and continuous recording.
skipping to change at page 12, line 10 skipping to change at page 11, line 41
Recording and real-time analytics of trading floor interactions Recording and real-time analytics of trading floor interactions
(including video and instant messaging). Real time analytics is (including video and instant messaging). Real time analytics is
required for automatic intervention (stopping interaction or alert) required for automatic intervention (stopping interaction or alert)
if for example, trader is not following regulations. if for example, trader is not following 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.
6. Requirements 6. Requirements
The following are requirements for the Session Recording Protocol: The following are requirements for SIP-based Media Recording:
o REQ-000 The mechanism MUST provide a means for establishing, o REQ-000 The mechanism MUST provide a means for "using the SIP
maintaining and clearing Recording Sessions between a Session protocol for" establishing, maintaining and terminating Recording
Recording Client and a Session Recording Server for the purpose of Sessions between a Session Recording Client and a Session Recording
recording, at the Session Recording Server, media from Communication Server.
Sessions.
o REQ-001 The mechanism MUST support Full-time Recording Sessions. o REQ-001 The mechanism MUST support the ability to record all CSs in
their entirety.
o REQ-002 The mechanism MUST support Selective Recording Sessions. o REQ-002 The mechanism MUST support the ability to record selected
CSs in their entirety, according to policy.
o REQ-003 The mechanism MUST support Dynamic (on-demand) Recording o REQ-003 The mechanism MUST support the ability to record selected
Sessions. parts of selected CSs.
o REQ-004 The mechanism MUST support Persistent Recording Sessions. o REQ-004 The mechanism MUST support the ability to record a CS
without an intentional loss of media (for example, clipping media at
the beginning of the CS) and without impacting the quality or timing
of the CS (for example, delaying the start of the CS while
preparation for recording takes place). See Use Case 4 in Section 5.
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 about 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 (SRS initiates recording). This requirement from the SRS to the SRC (SRS initiates recording). This requirement
typically applies when the decision about whether a session should be typically applies when the decision about whether a session should be
recorded or not resides in the SRS. recorded or not resides in the SRS.
skipping to change at page 12, line 50 skipping to change at page 12, line 38
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
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 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.
o REQ-012bis: The mechanism MUST support the ability for an SRC to o REQ-012bis: The mechanism MUST support the ability for an SRC to
skipping to change at page 13, line 37 skipping to change at page 13, line 22
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 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-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 a
Recording Session during a Communication 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 involved in
that a Communication Session is not recorded prior to recording. a CS to request, prior to the start of recording, that the CS not be
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 support the initiation of a Recording
Session at the beginning of a Communication Session.
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
(leading or trailing samples) when the media is transported from the
SRC to the SRS.
Note: Media clipping can occur due to delays in recording session
establishment. SRC implementations typically buffer some portion of
the media to overcome this problem.
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 The mechanism MUST support the existing SIP security model,
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 use different 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, for the SIP
SIP UA's being recorded, and for the Session Recording Protocol UA's being recorded, the SRC, and the SRS.
itself in terms of the SRC and 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 session requirements in this draft enable the UA to identify that a
is being recorded and for the UA to request that a given session is Communication Session is being recorded and for the UA to request
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
such as SIP, and indeed the SIP session might have originated through such as SIP, and indeed the SIP session might have originated through
a PSTN Gateway without any ability to pass on in-signaling a PSTN Gateway without any ability to pass on in-signaling
indications of recording, users can be notified of recording in the indications of recording, users can be notified of recording in the
media itself through voice announcements, a visual indicator on the media itself through voice announcements, a visual indicator on the
endpoint, or other means. endpoint, or other means.
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
 End of changes. 37 change blocks. 
108 lines changed or deleted 75 lines changed or added

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