draft-ietf-siprec-req-12.txt   rfc6341.txt 
SIPREC K. Rehor, Ed. Internet Engineering Task Force (IETF) K. Rehor, Ed.
Internet-Draft Cisco Systems Request for Comments: 6341 Cisco Systems
Intended status: Informational L. Portman, Ed. Category: Informational L. Portman, Ed.
Expires: December 11, 2011 NICE Systems ISSN: 2070-1721 NICE Systems
A. Hutton A. Hutton
Siemens Enterprise Siemens Enterprise Communications
Communications
R. Jain R. Jain
IPC Systems IPC Systems
June 09, 2011 August 2011
Use Cases and Requirements for SIP-based Media Recording (SIPREC) Use Cases and Requirements for SIP-Based Media Recording (SIPREC)
draft-ietf-siprec-req-12
Abstract Abstract
Session recording is a critical requirement in many business Session recording is a critical requirement in many business
communications environments such as call centers and financial communications environments, such as call centers and financial
trading floors. In some of these environments, all calls must be trading floors. In some of these environments, all calls must be
recorded for regulatory and compliance reasons. In others, calls may recorded for regulatory and compliance reasons. In others, calls may
be recorded for quality control or business analytics. be recorded for quality control or business analytics.
Recording is typically performed by sending a copy of the session Recording is typically performed by sending a copy of the session
media to the recording devices. This document specifies requirements media to the recording devices. This document specifies requirements
for extensions to SIP that will manage delivery of RTP media to a for extensions to SIP that will manage delivery of RTP media to a
recording device. This is being referred to as SIP-based Media recording device. This is being referred to as SIP-based Media
Recording. Recording.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on December 11, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6341.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 19 skipping to change at page 2, line 22
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation ...........................................4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions .....................................................4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Use Cases .......................................................5
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Requirements ...................................................10
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 6. Privacy Considerations .........................................13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations ........................................14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements ...............................................15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Normative References ...........................................15
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
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
support call centers typically employ call recording for quality customer support call centers, typically employ call recording for
control or business analytics, with different requirements. quality 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. In contrast, call trading floors typically must record all calls. In contrast, call
centers typically only record a subset of the calls, and calls must centers typically only record a subset of the calls, and calls must
not fail regardless of the availability of the recording device. not fail, regardless of the availability of the recording device.
Respecting the privacy rights and wishes of users engaged in a call Respecting the privacy rights and wishes of users engaged in a call
is of paramount importance. In many jurisdictions participants have is of paramount importance. In many jurisdictions, participants have
a right to know that the session is being recorded or might be a right to know that the session is being recorded or might be
recorded, and have a right to opt out, either by terminating the call recorded, and they have a right to opt out, either by terminating the
or by demanding that the call not be recorded. Therefore this call or by demanding that the call not be recorded. Therefore, this
document contains requirements for being able to notify users that a document contains requirements for being able to notify users that a
call is being recorded and for users to be able to request that a call is being recorded and for users to be able to request that a
call not be recorded. Use cases where users participating in a call call not be recorded. Use cases where users participating in a call
are not informed that the call is or might be recorded are outside are not informed that the call is or might be recorded are outside
the scope of this document. In particular, lawful intercept is the scope of this document. In particular, lawful intercept is
outside the scope of this document. outside the scope of this document.
Furthermore, one-size-fits-all model will not fit all markets where Furthermore, a one-size-fits-all model will not fit all markets where
the scale and cost burdens vary widely having different needs for the scale and cost burdens vary widely and where needs differ for
solution capabilities such as media injection, transcoding, and such solution capabilities as media injection, transcoding, and
security. If a standardized solution supports all of the security. If a standardized solution supports all of the
requirements from every recording market, but doing so would be requirements from every recording market but doing so would be
expensive for markets with lesser needs, then proprietary solutions expensive for markets with lesser needs, then proprietary solutions
for those markets will continue to propagate. Care must be taken, for those markets will continue to propagate. Care must be taken,
therefore, to make a standards-based solution support optionality and therefore, to make a standards-based solution support optionality and
flexibility. 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. A Communication Session is the "call" between Communication Session. A Communication Session is the "call" between
participants. The Session Recording Client is the source of the participants. The Session Recording Client is the source of the
recorded media. The Session Recording Server is the sink of recorded recorded media. The Session Recording Server is the sink of recorded
media. It should be noted that the requirements for the protocol media. It should be noted that the requirements for the protocol
between a Session Recording Server and Session Recording Client have between a Session Recording Server and Session Recording Client have
very similar requirements (such as codec and transport negotiation, very similar requirements (such as codec and transport negotiation,
encryption key interchange, firewall traversal) as compared to encryption key interchange, and firewall traversal) as compared to
regular SIP media sessions. The choice of SIP for session recording regular SIP media sessions. The choice of SIP for session recording
provides reuse of an existing protocol. 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 dual-tone multifrequency (DTMF) (as defined by [RFC4733]), video, and
[RFC4103]). text (as defined by [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 Session Recording Server.
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. directly from the network, is outside the scope of this document.
2. Requirements notation 2. 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.
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
that acts as the sink of the recorded media. An SRS is typically collector that acts as the sink of the recorded media. An SRS is
implemented as a multi-port device that is capable of receiving media typically implemented as a multi-port device that is capable of
from multiple sources simultaneously. An SRS is the sink of the receiving media from multiple sources simultaneously. An SRS is
recorded session metadata. the sink of the recorded session metadata.
Session Recording Client (SRC): A Session Recording Client (SRC) is a Session Recording Client (SRC): A Session Recording Client (SRC) is a
SIP 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
In practice, an SRC could be a personal device (such as a SIP phone), devices. In practice, an SRC could be a personal device (such as
a SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP a SIP phone), a SIP Media Gateway (MG), a Session Border
Media Server (MS) integrated with an Application Server (AS). This Controller (SBC), or a SIP Media Server (MS) integrated with an
specification defines the term SRC such that all such SIP entities Application Server (AS). This specification defines the term
can be generically addressed under one definition. The SRC provides "SRC" such that all such SIP entities can be generically addressed
metadata to the SRS. under one definition. The SRC provides metadata to the SRS.
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 subject of recording. User Agents (UAs) that is the subject of 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 Figure 1 pictorially represents the relationship between a Recording
Session and Communication Session. Session and Communication Session.
+-------------+ +-----------+ +-------------+ +-----------+
| | Communication Session | | | | Communication Session | |
| A |<------------------------------------>| B | | A |<------------------------------------>| B |
| | | | | | | |
+-------------+ +-----------+ +-------------+ +-----------+
.................................................................. ..................................................................
skipping to change at page 5, line 39 skipping to change at page 5, line 29
v v
+------------+ +------------+
| Session | | Session |
| Recording | | Recording |
| Server | | Server |
+------------+ +------------+
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.
Pause and Resume during a Communication Session: Pause: The action of Pause and Resume during a Communication Session:
temporarily discontinuing the transmission and collection of RS media Pause: The action of temporarily discontinuing the transmission
Resume: The action of recommencing the transmission and collection of and collection of RS media.
RS media Resume: The action of recommencing the transmission and collection
of RS media.
Most security-related terms in this document are to be understood in Most security-related terms in this document are to be understood in
the sense defined in [RFC4949]; such terms include, but are not the sense defined in [RFC4949]; such terms include, but are not
limited to, "authentication", "confidentiality", "encryption", limited to, "authentication", "confidentiality", "encryption",
"identity", and "integrity". "identity", and "integrity".
4. Use Cases 4. Use Cases
Use Case 1: Full-time Recording: One Recording Session for each Use Case 1: Full-time Recording: One Recording Session for each
Communication Session. Communication Session.
For example, the diagram below shows the lifecycle of Communication For example, the diagram below shows the life cycle of
Sessions (CS) and the relationship to the Recording Sessions (RS) Communication Sessions (CSs) 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 ---|
t---> t--->
Figure 2 Figure 2
Record every CS for specific extension/person. Record every CS for each specific extension/person.
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)
to ensure compliance with governmental regulations. Applications or to ensure compliance with governmental regulations.
include enterprise, contact center, and financial trading floors. Applications include enterprise, contact center, and financial
trading floors.
Also commonly known as Total Recording. This is 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 to be recorded is established. Communication Session to be recorded is established.
In this example, Communication Sessions 1 and 3 are recorded but CS 2 In this example, Communication Sessions 1 and 3 are recorded but
is not. CS 2 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 ---|
t---> t--->
Figure 3 Figure 3
Use Case 3: Start/Stop a Recording Session during a Communication Use Case 3: Start/Stop a Recording Session during a Communication
Session. Session.
The Recording Session starts during a Communication Session, either The Recording Session starts during a Communication Session,
manually via a user-controlled mechanism (e.g. button on user's either manually via a user-controlled mechanism (e.g., a button on
phone) or automatically via an application (e.g. a Contact Center a user's phone) or automatically via an application (e.g., a
customer service application) or business event. A Recording Session contact center customer service application) or business event. A
either ends during the Communication Session, or when the Recording Session ends either during the Communication Session or
Communication Session ends. One or more Recording Sessions may when the Communication Session ends. One or more Recording
record each Communication Session. Sessions may record each Communication Session.
CS |------------- Communication Session -----------| CS |------------- Communication Session -----------|
RS |---- RS 1 ----| |---- RS 2 -----| RS |---- RS 1 ----| |---- RS 2 -----|
t---> t--->
Figure 4 Figure 4
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. one or more Communication Sessions.
|--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---| |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |---------------------- Recording Session ---------------------| RS |------------------- Recording Session ------------------|
t---> t--->
Figure 5 Figure 5
A Recording Session records continuously without interruption. A Recording Session records continuously without interruption.
Periods when there is no CS in progress must be reproduced upon Periods when there is no CS in progress must be reproduced upon
playback (e.g. by recording silence during such periods or by not playback (e.g., by recording silence during such periods, or by
recording such periods but marking them by means of metadata for not recording such periods but marking them by means of metadata
utilization on playback, etc.). Applications include financial for utilization on playback, etc.). Applications include
trading desks and emergency (first-responder) service bureaus. The financial trading desks and emergency (first-responder) service
length of a Persistent Recording Session is independent from the bureaus. The length of a Persistent Recording Session is
length of the actual Communication Sessions. Persistent Recording independent from the length of the actual Communication Sessions.
Sessions avoid issues such as media clipping that can occur due to Persistent Recording Sessions avoid issues such as media clipping
delays in Recording Session establishment. 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
not dynamically signaled for each Communication Session before it can are not dynamically signaled for each Communication Session before
be recorded; however, codec re-negotiation is possible. it can be recorded; however, codec re-negotiation is possible.
In some cases, more than one concurrent Communication Session (on a In some cases, more than one concurrent Communication Session (on
single end-user apparatus, e.g. trading floor turret) is mixed into a single end-user apparatus, e.g., trading-floor turret) is mixed
one Recording Session: into one Recording Session:
|-------- CS 1 -------| |-------- CS 1 -------|
|-------- CS 2 -------| |-------- CS 2 -------|
|-------- CS 3 -------| |-------- CS 3 -------|
RS |----------- Recording Session --------------| RS |----------- Recording Session --------------|
t---> t--->
Figure 6 Figure 6
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 information must be protected. One solution is not to record
speaking their credit card information. a caller speaking their credit card information.
An example of a real-time controls is Pause/Resume. An example of a real-time control is Pause/Resume.
Use Case 6: IVR / Voice Portal Recording. Use Case 6: IVR / Voice Portal Recording.
Self-service Interactive Voice Response applications may need to be Self-service Interactive Voice Response (IVR) applications may
recorded for application performance tuning or to meet compliance need to be recorded for application performance tuning or to meet
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.).
Use Case 7: Enterprise Mobility Recording. Use Case 7: Enterprise Mobility Recording.
Many agents and enterprise workers whose calls are to be recorded are Many agents and enterprise workers whose calls are to be recorded
not located on company premises. are not located on company premises.
Examples: Examples:
o Home-based agents or enterprise workers. o Home-based agents or enterprise workers.
o Mobile phones of knowledge workers when they conduct work related o Mobile phones of knowledge workers (e.g., insurance agents,
(and legally required recording) calls. e.g. insurance agents, brokers, or physicians) when they conduct work-related (and
brokers, physicians. legally required recording) calls.
Use Case 8: Geographically distributed or centralized recording. Use Case 8: Geographically distributed or centralized recording.
Enterprises such as banks, insurance agencies, and retail stores may Enterprises such as banks, insurance agencies, and retail stores
have many locations, possibly up to thousands of small sites. may have many locations, possibly up to thousands of small sites.
Frequently only phones and network infrastructure are installed in Frequently, only phones and network infrastructure are installed
branches, without local recording services. In cases where calls in branches, without local recording services. In cases where
inside or between branches must be recorded, a centralized recording calls inside or between branches must be recorded, a centralized
system in data centers together with telephony infrastructure (e.g. recording system in data centers together with telephony
PBX) may be deployed. infrastructure (e.g., Private Branch Exchange (PBX)) may be
deployed.
Use Case 9: Record complex call scenarios. Use Case 9: Record complex call scenarios.
The following is an example of a scenario where one call that is The following is an example of a scenario where one call that is
recorded must be associated with a related call that also must be recorded must be associated with a related call that also must be
recorded. recorded.
o A Customer is in a conversation with a Customer Service Agent. o A Customer is in a conversation with a Customer Service Agent.
o Agent puts Customer on hold in order to consult with a Supervisor. o The Agent puts the Customer on hold in order to consult with a
Supervisor.
o Agent enters into a conversation with Supervisor. o The Agent enters into a conversation with the Supervisor.
o Agent disconnects from Supervisor, then reconnects with Customer. o The Agent disconnects from the Supervisor, then reconnects with
the Customer.
o The Supervisor call must be associated with the original customer o The Supervisor call must be associated with the original
call. Customer call.
Use case 10: High availability and continuous recording. Use Case 10: High availability and continuous recording.
Specific deployment scenarios present different requirements for Specific deployment scenarios present different requirements for
system availability, error handling, etc. including: system availability, error handling, etc., including the
following:
o An SRS must always be available at call setup time. o An SRS must always be available at call setup time.
o No loss of media recording, including during failure of an SRS. o No loss of media recording can occur, including during failure
of an SRS.
o The Communication Session must be terminated (or suitable o The Communication Session must be terminated (or suitable
notification given to parties) in the event of a recording failure. notification given to parties) in the event of a recording
failure.
Use Case 11: Record multi-channel, multi-media session. Use Case 11: Record multi-channel, multimedia 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 are synchronized, either stream, possibly of different types. Media are synchronized,
at storage or at playback. either at storage or at playback.
Speech analytics technologies (e.g. word spotting, emotion detection, Speech analytics technologies (e.g., word spotting, emotion
speaker identification) may require speaker-separated recordings for detection, speaker identification) may require speaker-separated
optimum performance. recordings for optimum performance.
Multi-modal Contact Centers may include audio, video, IM or other Multi-modal contact centers may include audio, video, IM, or other
interaction modalities. interaction modalities.
In trading floors environments, in order to minimize storage and In trading-floor environments, in order to minimize storage and
recording system resources, it may be preferable to mix multiple recording system resources, it may be preferable to mix multiple
concurrent calls (Communication Sessions) on different handsets/ concurrent calls (Communication Sessions) on different handsets/
speakers on the same turret into single recording session. speakers on the same turret into a single recording session.
Use Case 12: Real-time media processing. Use Case 12: Real-time media processing.
It must be possible for an SRS to support real-time media processing, It must be possible for an SRS to support real-time media
such as speech analytics of trading floor interactions. Real-time processing, such as speech analytics of trading-floor
analytics may be employed for automatic intervention (stopping interactions. Real-time analytics may be employed for automatic
interaction or alerting) if for example, a trader is not following intervention (stopping interaction or alerting) if, for example, a
regulations. 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.
5. Requirements 5. Requirements
The following are requirements for SIP-based Media Recording: The following are requirements for SIP-based Media Recording:
o REQ-001 The mechanism MUST provide a means for using the SIP o REQ-001: The mechanism MUST provide a means for using the SIP
protocol for establishing, maintaining and terminating Recording protocol for establishing, maintaining, and terminating Recording
Sessions between a Session Recording Client and a Session Recording Sessions between a Session Recording Client and a Session
Server. Recording Server.
o REQ-002 The mechanism MUST support the ability to record all CSs in
their entirety.
o REQ-003 The mechanism MUST support the ability to record selected o REQ-002: The mechanism MUST support the ability to record all CSs
CSs in their entirety, according to policy. in their entirety.
o REQ-004 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. CSs in their entirety, according to policy.
o REQ-005 The mechanism MUST support the ability to record a CS o REQ-004: The mechanism MUST support the ability to record selected
without loss of media of RS (for example, clipping media at the parts of selected CSs.
beginning of the CS) due to RS recording preparation and also,
without impacting the quality or timing of the CS (for example,
delaying the start of the CS while preparation for recording
session). See Use Case 4 in Section 4 for more details.
o REQ-006 The mechanism MUST support the recording of IVR sessions. o REQ-005: The mechanism MUST support the ability to record a CS
without loss of media of RS (for example, clipping media at the
beginning of the CS) due to RS recording preparation and also
without impacting the quality or timing of the CS (for example,
delaying the start of the CS while preparing for a recording
session). See Use Case 4 in Section 4 for more details.
o REQ-007 The mechanism MUST support the recording of RTP media types o REQ-006: The mechanism MUST support the recording of IVR sessions.
voice, DTMF (as defined by [RFC4733]), video, and text (as defined by
[RFC4103]). o REQ-007: The mechanism MUST support the recording of the following
RTP media types: voice, DTMF (as defined by [RFC4733]), video, and
text (as defined by [RFC4103]).
o REQ-008 The mechanism MUST support the ability for an SRC to o REQ-008: The mechanism MUST support the ability for an SRC to
deliver mixed audio streams from multiple Communication Sessions to deliver mixed audio streams from multiple Communication Sessions
an SRS. to an SRS.
Note: A mixed audio stream is where several related Communication Note: A mixed audio stream is where several related Communication
Sessions are carried in a single Recording Session. A mixed media Sessions are carried in a single Recording Session. A mixed-media
stream is typically produced by a mixer function. The RS MAY be stream is typically produced by a mixer function. The RS MAY be
informed about the composition of the mixed streams through session informed about the composition of the mixed streams through
metadata. session metadata.
o REQ-009: The mechanism MUST support the ability for an SRC to o REQ-009: The mechanism MUST support the ability for an SRC to
deliver mixed audio streams from different parties of a given deliver mixed audio streams from different parties of a given
Communication Session to an SRS. Communication Session to an SRS.
o REQ-010 The mechanism MUST support the ability to deliver to the o REQ-010: The mechanism MUST support the ability to deliver to the
SRS multiple media streams for a given CS. SRS multiple media streams for a given CS.
o REQ-011 The mechanism MUST support the ability to pause and resume o REQ-011: The mechanism MUST support the ability to pause and
the transmission and collection of RS media. resume the transmission and collection of RS media.
o REQ-012 The mechanism MUST include a means for providing the SRS o REQ-012: The mechanism MUST include a means for providing the SRS
with metadata describing CSs that are being recorded, including the with metadata describing CSs that are being recorded, including
media being used and the identifiers of parties involved. the media being used and the identifiers of parties involved.
o REQ-013 The mechanism MUST include a means for the SRS to be able o REQ-013: The mechanism MUST include a means for the SRS to be able
to correlate RS media with CS participant media. to correlate RS media with CS participant media.
o REQ-014 Metadata format must be agnostic of the transport protocol. o REQ-014: Metadata format must be agnostic of the transport
protocol.
o REQ-015: The mechanism MUST support a means to stop the recording. o REQ-015: The mechanism MUST support a means to stop the recording.
o REQ-016: The mechanism MUST support a means for a recording-aware o REQ-016: The mechanism MUST support a means for a recording-aware
UA involved in a CS to request at session establishment time that the UA involved in a CS to request at session establishment time that
CS should be recorded or should not be recorded, the honoring of such the CS should be recorded or should not be recorded, the honoring
a request being dependent on policy. of such a request being dependent on policy.
o REQ-017: The mechanism MUST support a means for a recording-aware o REQ-017: The mechanism MUST support a means for a recording-aware
UA involved in a CS to request during a session that the recording of UA involved in a CS to request during a session that the recording
the CS should be started, paused, resumed or stopped, the honoring of of the CS should be started, paused, resumed, or stopped, the
such a request being dependent on policy. Such recording-aware UA honoring of such a request being dependent on policy. Such
MUST be notified about outcome of such requests. recording-aware UAs MUST be notified about the outcome of such
requests.
o REQ-018 The mechanism MUST NOT prevent the application of tones or o REQ-018: The mechanism MUST NOT prevent the application of tones
announcements during recording or at the start of a CS to support or announcements during recording or at the start of a CS to
notification to participants that the call is being recorded or may support notification to participants that the call is being
be recorded. recorded or may be recorded.
o REQ-019 The mechanism MUST provide a means of indicating to o REQ-019: The mechanism MUST provide a means of indicating to
recording-aware UAs whether recording is taking place, for recording-aware UAs whether recording is taking place, for
appropriate rendering at the user interface. appropriate rendering at the user interface.
o REQ-020 The mechanism MUST provide a way for metadata to be o REQ-020: 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-021 The mechanism MUST NOT prevent high availability o REQ-021: The mechanism MUST NOT prevent high-availability
deployments. deployments.
o REQ-022 The mechanism MUST provide means for facilitating o REQ-022: The mechanism MUST provide means for facilitating
synchronization of the recorded media streams and metadata. synchronization of the recorded media streams and metadata.
o REQ-023 The mechanism MUST provide means for facilitating o REQ-023: The mechanism MUST provide means for facilitating
synchronization among the recorded media streams. synchronization among the recorded media streams.
o REQ-024 The mechanism MUST provide means to relate recording and o REQ-024: The mechanism MUST provide means to relate recording and
recording controls such as start/stop/pause/resume to the wall clock recording controls, such as start/stop/pause/resume, to the wall
time. clock time.
o REQ-025 The mechanism MUST provide means for an SRS to authenticate o REQ-025: The mechanism MUST provide means for an SRS to
the SRC on RS initiation. authenticate the SRC on RS initiation.
o REQ-026 The mechanism MUST provide means for an SRC to authenticate o REQ-026: The mechanism MUST provide means for an SRC to
the SRS on RS initiation. authenticate the SRS on RS initiation.
o REQ-027 The mechanism MUST include a means for ensuring that the o REQ-027: The mechanism MUST include a means for ensuring that the
integrity of the metadata sent from SRC to SRS is an accurate integrity of the metadata sent from the SRC to the SRS is an
representation of the original CS metadata. accurate representation of the original CS metadata.
o REQ-028 The mechanism MUST include a means for ensuring that the o REQ-028: The mechanism MUST include a means for ensuring that the
integrity of the media sent from SRC to SRS is an accurate integrity of the media sent from the SRC to the SRS is an accurate
representation of the original CS media. representation of the original CS media.
o REQ-029 The mechanism MUST include a means for ensuring the o REQ-029: The mechanism MUST include a means for ensuring the
confidentiality of the Metadata sent from SRC to SRS. confidentiality of the metadata sent from the SRC to the SRS.
o REQ-030 The mechanism MUST provide a means to support RS o REQ-030: The mechanism MUST provide a means to support RS
confidentiality. confidentiality.
o REQ-031 The mechanism MUST support the ability to deliver to the o REQ-031: The mechanism MUST support the ability to deliver to the
SRS multiple media streams of the same media type (e.g. audio, SRS multiple media streams of the same media type (e.g., audio,
video). For example in the case of delivering unmixed audio for each video). One example is the case of delivering unmixed audio for
participant in the CS. each participant in the CS.
6. Privacy Considerations 6. Privacy Considerations
Respecting the privacy rights and wishes of users engaged in a call Respecting the privacy rights and wishes of users engaged in a call
is of paramount importance. In many jurisdictions participants have is of paramount importance. In many jurisdictions, participants have
a right to know that the session is being recorded or might be a right to know that the session is being recorded or might be
recorded, and have a right to opt out, either by terminating the call recorded, and they have a right to opt out, either by terminating the
or by demanding that the call not be recorded. Therefore this call or by demanding that the call not be recorded. Therefore, this
document contains requirements for being able to notify users that a document contains requirements for being able to notify users that a
call is being recorded and for users to be able to request that a call is being recorded and for users to be able to request that a
call not be recorded. Use cases where users participating in a call call not be recorded. Use cases where users participating in a call
are not informed that the call is or might be recorded are outside are not informed that the call is or might be recorded are outside
the scope of this document. In particular, lawful intercept is the scope of this document. In particular, lawful intercept is
outside the scope of this document. outside the scope of this document.
Requirements for participant notification of recording vary widely by Requirements for participant notification of recording vary widely by
jurisdiction. In a given deployment, not all users will be jurisdiction. In a given deployment, not all users will be
authorized to stop the recording of a CS (although any user can authorized to stop the recording of a CS (although any user can
terminate its participation in a CS). Typically users within the terminate its participation in a CS). Typically, users within the
domain that is carrying out the recording will be subject to policies domain that is carrying out the recording will be subject to policies
of that domain concerning whether CSs are recorded. For example, in of that domain concerning whether CSs are recorded. For example, in
a call centre, agents will be subject to policies of the call centre a call center, agents will be subject to policies of the call center
and may or may not have the right to prevent the recording of a CS or 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, part of a CS. Users calling into the call center, on the other hand,
will typically have to ask the agent not to record the CS. If the will typically have to ask the agent not to record the CS. If the
agent is unable to prevent recording, or if the caller does not trust agent is unable to prevent recording, or if the caller does not trust
the agent, the only option generally is to terminate the CS. the agent, the only option generally is to terminate the CS.
Privacy considerations also extend to what happens to a recording Privacy considerations also extend to what happens to a recording
once it has been created. Typical issues are who can access the once it has been created. Typical issues are who can access the
recording (e.g., receive a copy of the recording, view the metadata, recording (e.g., receive a copy of the recording, view the metadata,
play back the media, etc.), for what purpose the recording can be play back the media, etc.), for what purpose the recording can be
used (e.g., for training purposes, for quality control purposes, used (e.g., for training purposes, for quality control purposes,
etc.) and for how long the recording is to be retained before etc.), and for how long the recording is to be retained before
deletion. These are typically policies of the domain that makes the deletion. These are typically policies of the domain that makes the
recording, rather than policies of individual users involved in a recording, rather than policies of individual users involved in a
recorded CS, whether those users be in the same domain or 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 different domain. Taking the call center example again, agents might
be made aware of call centre policy regarding retention and use of be made aware of call center policy regarding retention and use of
recordings as part of their employment contract, and callers from recordings as part of their employment contract, and callers from
outside the call centre might be given some information about policy outside the call center might be given some information about policy
when notified that a CS will be recorded (e.g., through an when notified that a CS will be recorded (e.g., through an
announcement that says that calls may be recorded for quality announcement that says that calls may be recorded for quality
purposes). purposes).
This document does not specify any requirements for a user engaged in 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 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. It is for such information to be conveyed from an SRC to an SRS. It is
assumed that the SRS has access to policy applicable to its assumed that the SRS has access to policy applicable to its
environment and can ensure that recordings are stored and used in environment and can ensure that recordings are stored and used in
accordance with that policy. accordance with that policy.
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. UAs being recorded, the SRC, and the SRS.
For the SIP UA's involved in the Communication Session, the For the SIP UAs involved in the Communication Session, the
requirements in this draft enable the UA to identify that a requirements in this document enable the UA to identify that a
Communication Session is being recorded and for the UA to request Communication Session is being recorded and to request that a given
that a given Communication Session is not subject to recording. Communication Session not be 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 Public Switched Telephone Network (PSTN) gateway without any
indications of recording, users can be notified of recording in the ability to pass on in-signaling indications of recording, users can
media itself through voice announcements, a visual indicator on the be notified of recording in the media itself through voice
endpoint, or other means. announcements, a visual indicator on the endpoint, or other means.
With regards to security implications of the protocol(s), clearly With regard to security implications of the protocol(s), clearly
there is a need for authentication, authorization and eavesdropping there is a need for authentication, authorization, and eavesdropping
protection for the solution. The SRC needs to know the SRS it is protection for the solution. The SRC needs to know the SRS it is
communicating with is legitimate, and vice-versa, even if they are in communicating with is legitimate, and vice versa, even if they are in
different domains. Both the signaling and media for the Recording different domains. Both the signaling and media for the Recording
Session need the ability to be authenticated and protected from Session need the ability to be authenticated and protected from
eavesdropping. Requirements are detailed in the requirements eavesdropping. Requirements are detailed in Section 5.
section.
Communication Sessions and Recording Sessions can require different Communication Sessions and Recording Sessions can require different
security levels both for signaling and media, depending on deployment security levels both for signaling and media, depending on deployment
configurations. For some environments, for example, SRS and SRC will configurations. For some environments, e.g., the SRS and SRC will be
be collocated in a secure network region and therefore the RS will collocated in a secure network region, and therefore the RS will not
not require the same protection level as a CS that extends over a require the same protection level as a CS that extends over a public
public network, for example. For other environments, the SRS can be network, for example. For other environments, the SRS can be located
located in a public cloud, for example, and the RS will require a in a public cloud, for example, and the RS will require a higher
higher protection level than the CS. For these reasons, there is not protection level than the CS. For these reasons, there is not a
a direct relationship between the security level of Communication direct relationship between the security level of Communication
Sessions and the security level of Recording Sessions. Sessions and the security level of Recording Sessions.
A malicious or corrupt SRC can tamper with media and metadata A malicious or corrupt SRC can tamper with media and metadata
relating to a CS before sending to an SRS. Also CS media and relating to a CS before sending the data to an SRS. Also, CS media
signaling can be tampered with in the network prior to reaching an and signaling can be tampered with in the network prior to reaching
SRC, unless proper means are provided to ensure integrity protection an SRC, unless proper means are provided to ensure integrity
during transmission on the CS. Means for ensuring the correctness of protection during transmission on the CS. Means for ensuring the
media and metadata emitted by an SRC are outside the scope of this correctness of media and metadata emitted by an SRC are outside the
work. Other organizational and technical controls will need to be scope of this work. Other organizational and technical controls will
used to prevent tampering. need to be used to prevent tampering.
8. IANA Considerations
This document has no IANA actions.
9. Acknowledgements 8. Acknowledgements
Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings, Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings,
Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper, Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper,
Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and
Charles Eckel for their significant contributions and assistance with Charles Eckel for their significant contributions and assistance with
this document and Working Group, and to all the members of the this document and the SIPREC WG, and to all the members of the
DISPATCH WG and SIPREC WG mailing lists for providing valuable input DISPATCH WG and SIPREC WG mailing lists for providing valuable input
to this work. to this work.
10. Normative References 9. 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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005. Conversation", RFC 4103, June 2005.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733, Digits, Telephony Tones, and Telephony Signals", RFC 4733,
December 2006. December 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. FYI 36, RFC 4949, August 2007.
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) Leon Portman (editor)
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 Rajnish Jain
IPC Systems IPC Systems
777 Commerce Drive 777 Commerce Drive
Fairfield, CT 06825 Fairfield, CT 06825
USA USA
Email: rajnish.jain@ipc.com EMail: rajnish.jain@ipc.com
 End of changes. 132 change blocks. 
324 lines changed or deleted 325 lines changed or added

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