draft-ietf-siprec-req-10.txt   draft-ietf-siprec-req-11.txt 
SIPREC K. Rehor, Ed. SIPREC K. Rehor, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational L. Portman, Ed. Intended status: Informational L. Portman, Ed.
Expires: November 4, 2011 NICE Systems Expires: November 30, 2011 NICE Systems
A. Hutton A. Hutton
Siemens Enterprise Siemens Enterprise
Communications Communications
R. Jain R. Jain
IPC Systems IPC Systems
May 03, 2011 May 29, 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-10 draft-ietf-siprec-req-11
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
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 4, 2011. This Internet-Draft will expire on November 30, 2011.
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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
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 have a right to opt out, either by terminating the call
or by demanding that the call not be recorded. Therefore this 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, the scale and cost burdens vary widely, in all markets, Furthermore, one-size-fits-all model will not fit all markets where
where the different needs for solution capabilities such as media the scale and cost burdens vary widely having different needs for
injection, transcoding, and security-related needs do not conform solution capabilities such as media injection, transcoding, and
well to a one-size-fits-all model. If a standardized solution security. If a standardized solution supports all of the
supports all of the requirements from every recording market, but requirements from every recording market, but doing so would be
doing so would be expensive for markets with lesser needs, then expensive for markets with lesser needs, then proprietary solutions
proprietary solutions for those markets will continue to propagate. for those markets will continue to propagate. Care must be taken,
Care must be taken, therefore, to make a standards-based solution therefore, to make a standards-based solution support optionality and
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,
skipping to change at page 6, line 5 skipping to change at page 5, line 46
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: Pause: The action of
temporarily discontinuing the transmission and collection of RS media temporarily discontinuing the transmission and collection of RS media
Resume: The action of recommencing the transmission and collection of Resume: The action of recommencing the transmission and collection of
RS media RS media
Most security-related terms in this document are to be understood in
the sense defined in [RFC4949]; such terms include, but are not
limited to, "authentication", "confidentiality", "encryption",
"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 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 ---|
t--->
Figure 2 Figure 2
Record every CS for specific extension/person. Record every CS for 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) 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.
skipping to change at page 6, line 37 skipping to change at page 6, line 39
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 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 ---|
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, either
manually via a user-controlled mechanism (e.g. button on user's manually via a user-controlled mechanism (e.g. button on user's
phone) or automatically via an application (e.g. a Contact Center phone) or automatically via an application (e.g. a Contact Center
customer service application) or business event. A Recording Session customer service application) or business event. A Recording Session
either ends during the Communication Session, or when the either ends during the Communication Session, or when the
Communication Session ends. One or more Recording Sessions may Communication Session ends. One or more Recording Sessions may
record each Communication Session. record each Communication Session.
CS |------------- Communication Session -----------| CS |------------- Communication Session -----------|
RS |---- RS 1 ----| |---- RS 2 -----| RS |---- RS 1 ----| |---- RS 2 -----|
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--->
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 not
recording such periods but marking them by means of metadata for recording such periods but marking them by means of metadata for
utilization on playback, etc.). Applications include financial utilization on playback, etc.). Applications include financial
trading desks and emergency (first-responder) service bureaus. The trading desks and emergency (first-responder) service bureaus. The
length of a Persistent Recording Session is independent from the length of a Persistent Recording Session is independent from the
skipping to change at page 7, line 44 skipping to change at page 8, line 14
In some cases, more than one concurrent Communication Session (on a In some cases, more than one concurrent Communication Session (on a
single end-user apparatus, e.g. trading floor turret) is mixed into single end-user apparatus, e.g. trading floor turret) is mixed into
one Recording Session: one Recording Session:
|-------- CS 1 -------| |-------- CS 1 -------|
|-------- CS 2 -------| |-------- CS 2 -------|
|-------- CS 3 -------| |-------- CS 3 -------|
RS |----------- Recording Session --------------| RS |----------- Recording Session --------------|
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 info must be protected. One solution is to not record a caller
speaking their credit card information. speaking their credit card information.
skipping to change at page 10, line 24 skipping to change at page 10, line 41
o REQ-002 The mechanism MUST support the ability to record all CSs in o REQ-002 The mechanism MUST support the ability to record all CSs in
their entirety. their entirety.
o REQ-003 The mechanism MUST support the ability to record selected o REQ-003 The mechanism MUST support the ability to record selected
CSs in their entirety, according to policy. CSs in their entirety, according to policy.
o REQ-004 The mechanism MUST support the ability to record selected o REQ-004 The mechanism MUST support the ability to record selected
parts of selected CSs. parts of selected CSs.
o REQ-005 The mechanism MUST support the ability to record a CS o REQ-005 The mechanism MUST support the ability to record a CS
without loss of media (for example, clipping media at the beginning without loss of media of RS (for example, clipping media at the
of the CS) due to RS recording preparation and also, without beginning of the CS) due to RS recording preparation and also,
impacting the quality or timing of the CS (for example, delaying the without impacting the quality or timing of the CS (for example,
start of the CS while preparation for recording session). See Use delaying the start of the CS while preparation for recording
Case 4 in Section 4 for more details. 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-006 The mechanism MUST support the recording of IVR sessions.
o REQ-007 The mechanism MUST support the recording of RTP media types o REQ-007 The mechanism MUST support the recording of RTP media types
voice, DTMF (as defined by [RFC4733]), video, and text (as defined by voice, DTMF (as defined by [RFC4733]), video, and text (as defined by
[RFC4103]). [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 to
an SRS. 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 session
skipping to change at page 11, line 10 skipping to change at page 11, line 29
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 resume
the transmission and collection of RS media. 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 the
media being used and the identities of parties involved. 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 the
CS should be recorded or should not be recorded, the honoring of such CS should be recorded or should not be recorded, the honoring of such
a request being dependent on policy. 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 of
the CS should be started, paused, resumed or stopped, the honoring of the CS should be started, paused, resumed or stopped, the honoring of
such a request being dependent on policy. such a request being dependent on policy. Such recording-aware UA
MUST be notified about 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 or
announcements during recording or at the start of a CS to support announcements during recording or at the start of a CS to support
notification to participants that the call is being recorded or may notification to participants that the call is being recorded or may
be recorded. 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.
skipping to change at page 12, line 5 skipping to change at page 12, line 25
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 clock
time. time.
o REQ-025 The mechanism MUST support functionality such that if the o REQ-025 The mechanism MUST provide means for an SRS to authenticate
CS is encrypted, the RS may use the same or different encryption
keys.
o REQ-026 The mechanism MUST provide means for an SRS to authenticate
the SRC on RS initiation. the SRC on RS initiation.
o REQ-027 The mechanism MUST provide means for an SRC to authenticate o REQ-026 The mechanism MUST provide means for an SRC to authenticate
the SRS on RS initiation. the SRS on RS initiation.
o REQ-028 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 SRC to SRS is an accurate
representation of the original CS metadata. representation of the original CS metadata.
o REQ-029 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 SRC to SRS is an accurate
representation of the original CS media. representation of the original CS media.
o REQ-030 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 SRC to SRS.
o REQ-031 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-032 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). For example in the case of delivering unmixed audio for each
participant in the CS. 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 have a right to opt out, either by terminating the call
skipping to change at page 13, line 17 skipping to change at page 13, line 36
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 centre, 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 non-repudiation, for training purposes, for quality used (e.g., for training purposes, for quality control purposes,
control purposes, etc.) and for how long the recording is to be etc.) and for how long the recording is to be retained before
retained before deletion. These are typically policies of the domain deletion. These are typically policies of the domain that makes the
that makes the recording, rather than policies of individual users recording, rather than policies of individual users involved in a
involved in a recorded CS, whether those users be in the same domain recorded CS, whether those users be in the same domain or in a
or in a different domain. Taking the call centre example again, different domain. Taking the call centre example again, agents might
agents might be made aware of call centre policy regarding retention be made aware of call centre policy regarding retention and use of
and use of recordings as part of their employment contract, and recordings as part of their employment contract, and callers from
callers from outside the call centre might be given some information outside the call centre might be given some information about policy
about policy when notified that a CS will be recorded (e.g., through when notified that a CS will be recorded (e.g., through an
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
skipping to change at page 14, line 8 skipping to change at page 14, line 25
that a given Communication Session is not subject to recording. that a given Communication Session is not subject to recording.
Since humans don't typically look at or know about protocol signaling Since humans don't typically look at or know about protocol signaling
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, and
protection, and non-repudiation for the solution. The SRC needs to protection for the solution. The SRC needs to know the SRS it is
know the SRS it is communicating with is legitimate, and vice-versa, communicating with is legitimate, and vice-versa, even if they are in
even if they are in different domains. Both the signaling and media different domains. Both the signaling and media for the Recording
for the Recording Session need the ability to be authenticated and Session need the ability to be authenticated and protected from
protected from eavesdropping and non-repudiation. Requirements are eavesdropping. Requirements are detailed in the requirements
detailed in the requirements section. 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, for example, SRS and SRC will
be collocated in a secure network region and therefore the RS will be collocated in a secure network region and therefore the RS will
not require the same protection level as a CS that extends over a not require the same protection level as a CS that extends over a
public network, for example. For other environments, the SRS can be public network, for example. For other environments, the SRS can be
located in a public cloud, for example, and the RS will require a located in a public cloud, for example, and the RS will require a
higher protection level than the CS. For these reasons, there is not higher protection level than the CS. For these reasons, there is not
a direct relationship between the security level of Communication a 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 to an SRS. Also CS media and
signaling can be tampered with in the network prior to reaching an signaling can be tampered with in the network prior to reaching an
SRC, unless proper means are provided to ensure integrity protection SRC, unless proper means are provided to ensure integrity protection
during transmission on the CS. Means for ensuring the integrity and during transmission on the CS. Means for ensuring the correctness of
correctness of media and metadata emitted by an SRC are outside the media and metadata emitted by an SRC are outside the scope of this
scope of this work. Other organizational and technical controls will work. Other organizational and technical controls will need to be
need to be used to prevent tampering. used to prevent tampering.
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. Acknowledgements 9. Acknowledgements
Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, 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
skipping to change at page 15, line 22 skipping to change at page 15, line 37
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",
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
 End of changes. 27 change blocks. 
57 lines changed or deleted 68 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/