One document matched: draft-jain-dispatch-session-recording-protocol-req-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc2804 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2804.xml">
<!ENTITY I-D.I-D.wing-sipping-srtp-key PUBLIC ""
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-sipping-srtp-key.xml'>
]>
<rfc category="std"
ipr="full3978"
ipr="trust200811"
ipr="noModificationTrust200811"
ipr="noDerivativesTrust200811"
ipr="trust200902"
ipr="noModificationTrust200902"
ipr="noDerivativesTrust200902"
ipr="pre5378Trust200902"
docName="draft-jain-dispatch-session-recording-protocol-req-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc strict="no" ?>
<front>
<title abbrev="Requirements for SRP">Requirements for
Session Recording Protocol (SRP)</title>
<author fullname="Rajnish Jain" initials="R.J" role="editor" surname="Jain">
<organization>IPC Systems</organization>
<address>
<postal>
<street>777 Commerce Drive</street>
<city>Fairfield</city>
<region>CT</region>
<code>06825</code>
<country>USA</country>
</postal>
<email>rajnish.jain@ipc.com</email>
</address>
</author>
<author fullname="Leon Portman" initials="L.P" surname="Portman">
<organization>NICE Systems</organization>
<address>
<postal>
<street>8 Hapnina</street>
<city>Ra'anana</city>
<code>43017</code>
<country>Israel</country>
</postal>
<email>leon.portman@nice.com</email>
</address>
</author>
<author fullname="Vijay Gurbani" initials="V.G" surname="Gurbani">
<organization>Bell Laboratories, Alcatel-Lucent</organization>
<address>
<postal>
<street>2000 Lucent Lane</street>
<street>Rm 6G-440</street>
<city>Naperville</city>
<region>IL</region>
<code>60566</code>
<country>USA</country>
</postal>
<email>vkg@lucent.com</email>
</address>
</author>
<author fullname="Hadriel Kaplan" initials="H.K" surname="Kaplan">
<organization>Acme Packet</organization>
<address>
<postal>
<street>71 Third Ave.</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>USA</country>
</postal>
<email>hkaplan@acmepacket.com</email>
</address>
</author>
<author fullname="Andrew Hutton" initials="A.H" surname="Hutton">
<organization>Siemens Enterprise Communications</organization>
<address>
<postal>
<street>Technology Drive</street>
<city>Nottingham NG9 5ET</city>
<country>UK</country>
</postal>
<email>andrew.hutton@siemens-enterpise.com</email>
</address>
</author>
<author fullname="Ken Rehor" initials="K.R" surname="Rehor">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>707 Tasman Dr.</street>
<street>Mail Stop SJC30/2/</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>USA</country>
</postal>
<email>krehor@cisco.com</email>
</address>
</author>
<date month="July" year="2009"/>
<workgroup>DISPATCH</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>Session recording is a critical requirement in many business
communications environments such as call centers and financial trading
floors. In some of these environments, all calls must be recorded for
regulatory and compliance reasons. In others, calls may be recorded for
quality control or business analytics. Recording is typically done by
sending a copy of the media to the recording devices. This document
specifies requirements for a protocol that will manage delivery of
media from an end-point that originates media or that has access to it to
a recording device. This protocol is being referred to as Session
Recording Protocol and will most likely be based on SIP. </t>
</abstract>
</front>
<middle>
<section title="Requirements notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] and indicate
requirement levels for compliant mechanisms.</t>
</section>
<section title="Introduction">
<t>Session recording is a critical operational requirement in many
businesses, especially where voice is used as a medium for commerce and
customer support. A prime example where voice is used for trade is the
financial industry. The call recording requirements in this industry are
quite stringent. The recorded calls are used for dispute resolution and
compliance. Other businesses such as customer support call centers
typically employ call recording for quality control or business
analytics, with different requirements.</t>
<t>Depending on the country and its regulatory requirements, financial
trading floors typically must record all calls. The recorded media
content must be an exact copy of the actual conversation (i.e. clipping
and loss of media are unacceptable). A new call attempt would be
automatically rejected if the recording device becomes temporarily
unavailable. An existing call would be dropped in the same situation. In
contrast, support call centers typically only record a subset of the
calls, and calls must not fail regardless of the availability of the
recording device.</t>
<t>Furthermore, the scale and cost burdens vary widely, in all markets,
where the different needs for solution capabilities such as media
injection, transcoding, and security-related needs do not conform well
to a one-size-fits-all model. If a standardized solution supports all of
the requirements from every recording market, but doing so would be
expensive for markets with lesser needs, then proprietary solutions for
those markets will continue to propagate. Care must be taken, therefore,
to make a standards-based solution support optionality and
flexibility.</t>
<t>It should be noted that the requirements for the protocol between a
Recording Server and Recording Client have very similar requirements
(such as codec and transport negotiation, encryption key interchange,
firewall traversal) as compared to regular SIP media sessions. The
choice of SIP for session recording provides reuse of an existing
protocol. This document specifies requirements for a protocol between a
Recording Client and a Recording Server, which is most likely going to
be SIP <xref target="RFC3261"/> itself. The Recording Client is the
source of the recorded media. The Recording Server is the sink of the
recorded media.</t>
<t>The recorded sessions can be of any kind such as voice, video and
instant messaging. An archived session recording is typically comprised
of the session media content and the session metadata. The session
metadata allows recording archives to be searched and filtered at a
later time. The conveyance of session metadata from the Recording Client
to the 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.</t>
<t>This document only looks into active recording, where the Recording
Client purposefully streams media to a Recording Server. Passive
recording, where a recording device detects media directly from the
network, is outside the scope of this document. In addition, lawful
intercept is outside the scope of this document.</t>
<t>Another, related IETF draft is draft-wing-sipping-srtp-key
<xref target="I-D.wing-sipping-srtp-key"/>, which
describes an approach for providing SRTP session keys to a recorder-type
server. That draft focuses on the mechanism to provide the SRTP session
key, rather than the mechanism to invoke and sustain recording sessions
themselves.</t>
<t>There are already IETF Working Groups focusing on related or similar
concepts: Mediactrl and Xcon. The work to address the requirements
outlined in this draft may end up being done in those Working Groups, or
a new one may be formed.</t>
</section>
<section title="Definitions">
<t>Recording Server (RS): A Recording Server (RS) is a specialized media
server or collector that acts as the sink of the recorded media. An RS
typically archives media for extended durations of time and provides
interfaces for search and retrieval of the archived media. An RS is
typically implemented as a multi-port device that is capable of
receiving media from several sources simultaneously. An RS is typically
also the sink of the recorded session metadata. Note that the term
"Server" does not imply the RS is the server side of a signaling
protocol - the RS may be the initiator of recording requests, for
example.</t>
<t>Recording Client (RC): A Recording Client (RC) is a SIP User Agent
(UA) or a Back-to-Back User Agent (B2BUA) that acts as the source of
the recorded media, sending it to the RS. An RC is a logical function.
Its capabilities may be implemented across one or more physical devices.
In practice, an RC could be a personal device (such as a SIP phone), a
SIP Media Gateway (MG), a Session Border Controller (SBC) or a SIP
Media Server (MS) integrated with an Application Server (AS). This
specification defines the term RC such that all such SIP entities can
be generically addressed under one definition. The RC itself or another
entity working on its behalf (such as a SIP Application Server) may act
as the source of the recording metadata.</t>
<t>Session Recording Protocol (SRP): The Session Recording Protocol
(SRP) is a to-be-defined protocol that will be used to establish media
sessions between an RC and RS, for the purpose of delivering media
from the RC to the RS. It may, for example, be SIP.</t>
<t>Recording Session: The session created between an RC and RS for the
purpose of recording a Recorded Session. The Recorded Session may
itself be based on SIP, but it is a separate session from the Recording
Session.</t>
<t>Recorded Session: A session created between a UAC and UAS that is
recorded by the RC and RS systems.</t>
<t>Dynamic Recording: Dynamic recording is a mode of recording where the
recording sessions are established on an as needed basis. The length
of these sessions is typically same as the length of the actual media
sessions.</t>
<t>Persistent Recording: Persistent recording is a mode of recording
where the recording sessions are established at system start-up and
kept-alive from that point on. The length of these sessions is
independent from the length of the actual recorded media sessions.
Persistent recording sessions avoid issues such as media clipping that
can occur due to delays in recording session establishment.</t>
<t>Business Analytics: Business analytics refers to analyzing recorded
media and the related metadata for various kinds of business goals such
as decision making, statistical and quantitative analysis.</t>
<t/>
</section>
<section title="General Overview">
<t>Although this document discusses requirements and not solutions,
there are certain assumptions made regarding the solution space. One
goal is to support existing, deployed architectures for Session Recording.
Session Recording is an established practice, albeit with proprietary
protocols; it is the protocols between systems that this document aims at
addressing requirements towards, in order to eventually produce an IETF
defined protocol, or a set of protocols, for performing Session Recording
in a non-proprietary fashion. </t>
<t>The current Session Recording market typically performs recording
in one of the two ways. In some cases, a middle-box acts as a RC and sends
media to the recorder (RS). A simple diagram of this is shown below:
</t>
<figure>
<artwork><![CDATA[
+-----+ +-----+ +-----+
| | Call | | Call | |
|UA-A +<------------>+B2BUA+<------------>+UA-B |
| | | | | |
+-----+ +-++--+ +-----+
\\
\\
SRP \\
\\+----------+
\+ |
+ Recorder |
| |
+----------+
]]></artwork>
</figure>
<t/>
<t>In some other cases, the recording is performed from an endpoint (RC)
to a recorder (RS). A simple diagram of this is shown below:
</t>
<figure>
<artwork><![CDATA[
+-----+ +-----+
| | Call | |
|UA-A +<------------>+UA-B |
| | | |
+-++--+ +-----+
\\
\\
SRP \\
\\+----------+
\+ |
+ Recorder |
| |
+----------+
]]></artwork>
</figure>
<t/>
<t>In some deployments the RS notifies the RC when to record a session,
which requires the RS to have some means of identifying that a session
is taking place and how to reference the particular session to record.
In other cases, the RC notifies the RS when it wants to record a
session. In both cases, there is often a separate connection, or even
separate protocol, for communicating metadata about a session, distinct
from the protocol connection used for communicating the recording
information.</t>
</section>
<section title="Requirements">
<t>The basic requirements for the Session Recording Protocol can be
summarized as follows:</t>
<t>o REQ-001 The mechanism MUST support the ability to perform
persistent (always-on) or dynamic (on-demand) Recording Sessions.</t>
<t>o REQ-002 The mechanism MUST support the ability to perform persistent
Recording Sessions, such that the connection and attributes of media in
the Recording Session are not dynamically signaled for each Recorded
Session before it can be recorded. Call details and metadata will still
be signaled, but can be post-correlated to the recorded media. There
will still need to be a means of correlating the recorded media
connection/packets to the Recorded Session, however this may be on a
permanent filter-type basis, such as based on a SIP AoR of an agent that
is always recorded, or based on identifiers in the recorded media
itself.</t>
<t>o REQ-003 The mechanism MUST support establishing Recording Sessions
from the RC to the RS. This requirement typically applies when the
decision on whether a session should be recorded or not resides in the
RC.</t>
<t>o REQ-004 The mechanism MUST support establishing Recording
Sessions from the RS to the RC. This requirement typically applies when
the decision on whether a session should be recorded or not resides in
the RS.</t>
<t>o REQ-005 The mechanism SHOULD support loss less delivery of media
content from RC to the RS. Note that the specific use of recording will
dictate the integrity of the media. Trading floors or financial offices
will prefer complete loss less delivery of media whereas call centers,
for instance, may tolerate some media loss.</t>
<t>o REQ-006 The mechanism SHOULD support means to avoid clipping media
(leading or trailing samples) when the media is transported from the RC
to the RS.</t>
<t>Note: Media clipping can occur due to delays in recording session
establishment. RC implementations typically buffer some portion of the
media to overcome this problem.</t>
<t>o REQ-007 The mechanism SHOULD support RS failover and migration of
Recording Sessions to a working RS without disconnecting the Recorded
Sessions.</t>
<t>o REQ-008 The mechanism MUST support a means of providing security
(confidentiality, integrity and authentication) for the SRP.</t>
<t>o REQ-009 The mechanism MUST support the ability to deliver mixed
media streams to the RS. The RS MAY be informed about the composition of
the mixed streams through session metadata.</t>
<t>Note: A mixed media stream is where several recorded sessions are
carried in a single recording session. A mixed media stream is typically
produced by a mixer function.</t>
<t>o REQ-010 The mechanism MUST support the ability to deliver multiple
media streams for a given Recorded Session over separate Recording Sessions
to the RS.</t>
<t>o REQ-011 The mechanism MUST support the ability to deliver multiple
media streams for a given Recorded Session over a single Recording Session
to the RS.</t>
<t>o REQ-012 The mechanism MUST support the ability to pause and resume
the Recording Session either from RC or from the RS.</t>
<t>o REQ-013 The mechanism MUST support the ability to inject tones into
the Recorded Session either from the RS or from the RC.</t>
<t>o REQ-014 If SIP <xref target="RFC3261"/> is chosen as the Session
Recording Protocol, there MUST be a way for the Recording Session to
identify itself as a SIP session that is established for the purpose
of recording. This will provide a way to disambiguate the Recording
Session from the Recorded Session.</t>
<t>o REQ-015 The mechanism MUST support the ability to provide
authentication, eavesdropping protections, and non-repudiation for the
media sent in the Recording Session, between the RC and RS.</t>
<t>o REQ-016 The mechanism MUST support the ability to provide
authorization and authentication of the RS to the RC, and the RC to the
RS.</t>
<t>o REQ-017 The mechanism MUST support the ability to provide
eavesdropping protection and non-repudiation for the SRP.</t>
<t>o REQ-018 The mechanism MUST support the ability to correlate the SRP
request to record a call, with the session being recorded.</t>
<t>o REQ-019 The mechanism MUST support the ability to correlate the SRP
request to record specific media sessions, with the SIP session and
media to be recorded.</t>
<t>o REQ-020 The mechanism MUST support the ability to have a separate
session/connection for the Session Recording Protocol, from that for the
Session Metadata transport.</t>
<t>o REQ-021 The mechanism MUST support the ability for the RC to
only perform media replication to the RS, without needing to decode or
mix audio/video/etc., and without needing to be an RTP agent. This will
allow the RC to replicate media at layers below RTP. Clearly, such an RC
mode would not be able to provide transcoding, or media injection from
the RS back into the Recorded Session.</t>
</section>
<section title="Security Considerations">
<t>Session recording has substantial security implications, both for the
SIP UA's being recorded, and for the Session Recording Protocol itself
in terms of the RC and RS.</t>
<t>For the SIP UA's involved in the Recorded Session, the requirements
listed in this draft enable recording such that consent may not be asked
for, and instead they may be "silently" recorded without the knowledge
of the UA's. To some, this may smack of a form of (un)Lawful
Interception, which the IETF has explicitly ruled out of scope, due to
the nationally-specific variances in LI requirements (see <xref target="RFC2804"/>).
This is not the case with Session Recording. Session Recording has
requirements dictated by market needs, just as any IETF-defined protocol
does, and they are not nationally-specific. Session Recording may be
limited or constrained by nationally-specific restrictions, but such is
true of any communication protocols. For example, they typically require
the recorded users be notified of the recording taking place. This is
done in the media itself through voice announcements, since humans don't
typically look at or know about protocol signaling such as SIP, and
indeed the SIP session might have originated through a PSTN Gateway
without any ability to pass on in-signaling indications of
recording.</t>
<t>With regards to security implications of the protocol(s), clearly
there is a need for authentication, authorization, eavesdropping
protection, and non-repudiation for the solution. The RC needs to know
the RS it is communicating with is legitimate, and vice-versa, even if
they are in different domains. Both the signaling and media for the SRP
needs the ability to be authenticated and protected from eavesdropping
and non-repudiation. Requirements for this are detailed in the
requirements section.</t>
</section>
<section title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Dan Wing for his help with this document, and to all the
members of the DISPATCH WG mailing list for providing valuable input to
this work. Due to time constraints, not all of their input was included
in this version of the document.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc3261;
&rfc2804;
</references>
<references title='Informative References'>
<?rfc include="reference.I-D.wing-sipping-srtp-key" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:33 |