[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits] [IPR]

Versions: 00 draft-rehor-dispatch-session-recording-req

DISPATCH                                                    R. Jain, Ed.
Internet-Draft                                               IPC Systems
Intended status: Standards Track                              L. Portman
Expires: January 7, 2010                                    NICE Systems
                                                              V. Gurbani
                                       Bell Laboratories, Alcatel-Lucent
                                                               H. Kaplan
                                                             Acme Packet
                                                               A. Hutton
                                       Siemens Enterprise Communications
                                                                K. Rehor
                                                           Cisco Systems
                                                            July 6, 2009


           Requirements for Session Recording Protocol (SRP)
         draft-jain-dispatch-session-recording-protocol-req-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



Jain, et al.             Expires January 7, 2010                [Page 1]


Internet-Draft            Requirements for SRP                 July 2009


   This Internet-Draft will expire on January 7, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   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.

























Jain, et al.             Expires January 7, 2010                [Page 2]


Internet-Draft            Requirements for SRP                 July 2009


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  General Overview . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11





































Jain, et al.             Expires January 7, 2010                [Page 3]


Internet-Draft            Requirements for SRP                 July 2009


1.  Requirements notation

   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.


2.  Introduction

   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.

   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.

   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.

   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 [RFC3261] itself.  The Recording Client is the
   source of the recorded media.  The Recording Server is the sink of



Jain, et al.             Expires January 7, 2010                [Page 4]


Internet-Draft            Requirements for SRP                 July 2009


   the recorded media.

   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.

   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.

   Another, related IETF draft is draft-wing-sipping-srtp-key
   [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.

   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.


3.  Definitions

   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.

   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



Jain, et al.             Expires January 7, 2010                [Page 5]


Internet-Draft            Requirements for SRP                 July 2009


   (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.

   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.

   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.

   Recorded Session: A session created between a UAC and UAS that is
   recorded by the RC and RS systems.

   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.

   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.

   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.


4.  General Overview

   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.



Jain, et al.             Expires January 7, 2010                [Page 6]


Internet-Draft            Requirements for SRP                 July 2009


   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:


   +-----+              +-----+              +-----+
   |     |     Call     |     |   Call       |     |
   |UA-A +<------------>+B2BUA+<------------>+UA-B |
   |     |              |     |              |     |
   +-----+              +-++--+              +-----+
                           \\
                            \\
                         SRP \\
                              \\+----------+
                               \+          |
                                + Recorder |
                                |          |
                                +----------+

   In some other cases, the recording is performed from an endpoint (RC)
   to a recorder (RS).  A simple diagram of this is shown below:


      +-----+              +-----+
      |     |   Call       |     |
      |UA-A +<------------>+UA-B |
      |     |              |     |
      +-++--+              +-----+
         \\
          \\
       SRP \\
            \\+----------+
             \+          |
              + Recorder |
              |          |
              +----------+

   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.





Jain, et al.             Expires January 7, 2010                [Page 7]


Internet-Draft            Requirements for SRP                 July 2009


5.  Requirements

   The basic requirements for the Session Recording Protocol can be
   summarized as follows:

   o REQ-001 The mechanism MUST support the ability to perform
   persistent (always-on) or dynamic (on-demand) Recording Sessions.

   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.

   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.

   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.

   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.

   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.

   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.

   o REQ-007 The mechanism SHOULD support RS failover and migration of
   Recording Sessions to a working RS without disconnecting the Recorded
   Sessions.

   o REQ-008 The mechanism MUST support a means of providing security



Jain, et al.             Expires January 7, 2010                [Page 8]


Internet-Draft            Requirements for SRP                 July 2009


   (confidentiality, integrity and authentication) for the SRP.

   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.

   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.

   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.

   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.

   o REQ-012 The mechanism MUST support the ability to pause and resume
   the Recording Session either from RC or from the RS.

   o REQ-013 The mechanism MUST support the ability to inject tones into
   the Recorded Session either from the RS or from the RC.

   o REQ-014 If SIP [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.

   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.

   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.

   o REQ-017 The mechanism MUST support the ability to provide
   eavesdropping protection and non-repudiation for the SRP.

   o REQ-018 The mechanism MUST support the ability to correlate the SRP
   request to record a call, with the session being recorded.

   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.




Jain, et al.             Expires January 7, 2010                [Page 9]


Internet-Draft            Requirements for SRP                 July 2009


   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.

   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.


6.  Security Considerations

   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.

   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 [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.

   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.







Jain, et al.             Expires January 7, 2010               [Page 10]


Internet-Draft            Requirements for SRP                 July 2009


7.  IANA Considerations

   This document has no IANA actions.


8.  Acknowledgements

   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.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2804]  IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
              May 2000.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

9.2.  Informative References

   [I-D.wing-sipping-srtp-key]
              Wing, D., Audet, F., Fries, S., Tschofenig, H., and A.
              Johnston, "Secure Media Recording and Transcoding with the
              Session Initiation  Protocol",
              draft-wing-sipping-srtp-key-04 (work in progress),
              October 2008.


Authors' Addresses

   Rajnish Jain (editor)
   IPC Systems
   777 Commerce Drive
   Fairfield, CT  06825
   USA

   Email: rajnish.jain@ipc.com




Jain, et al.             Expires January 7, 2010               [Page 11]


Internet-Draft            Requirements for SRP                 July 2009


   Leon Portman
   NICE Systems
   8 Hapnina
   Ra'anana  43017
   Israel

   Email: leon.portman@nice.com


   Vijay Gurbani
   Bell Laboratories, Alcatel-Lucent
   2000 Lucent Lane
   Rm 6G-440
   Naperville, IL  60566
   USA

   Email: vkg@lucent.com


   Hadriel Kaplan
   Acme Packet
   71 Third Ave.
   Burlington, MA  01803
   USA

   Email: hkaplan@acmepacket.com


   Andrew Hutton
   Siemens Enterprise Communications
   Technology Drive
   Nottingham NG9 5ET
   UK

   Email: andrew.hutton@siemens-enterpise.com


   Ken Rehor
   Cisco Systems
   707 Tasman Dr.
   Mail Stop SJC30/2/
   Milpitas, CA  95035
   USA

   Email: krehor@cisco.com






Jain, et al.             Expires January 7, 2010               [Page 12]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/