doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc6341.txt b/doc/rfc/rfc6341.txt
new file mode 100644
index 0000000..e6397ae
--- /dev/null
+++ b/doc/rfc/rfc6341.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     K. Rehor, Ed.
+Request for Comments: 6341                                 Cisco Systems
+Category: Informational                                  L. Portman, Ed.
+ISSN: 2070-1721                                             NICE Systems
+                                                               A. Hutton
+                                       Siemens Enterprise Communications
+                                                                 R. Jain
+                                                             IPC Systems
+                                                             August 2011
+
+
+   Use Cases and Requirements for SIP-Based Media Recording (SIPREC)
+
+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 performed by sending a copy of the session
+   media to the recording devices.  This document specifies requirements
+   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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+Rehor, et al.                 Informational                     [Page 1]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Requirements Notation ...........................................4
+   3. Definitions .....................................................4
+   4. Use Cases .......................................................5
+   5. Requirements ...................................................10
+   6. Privacy Considerations .........................................13
+   7. Security Considerations ........................................14
+   8. Acknowledgements ...............................................15
+   9. Normative References ...........................................15
+
+1.  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.  In contrast, call
+   centers typically only record a subset of the calls, and calls must
+   not fail, regardless of the availability of the recording device.
+
+   Respecting the privacy rights and wishes of users engaged in a call
+   is of paramount importance.  In many jurisdictions, participants have
+   a right to know that the session is being recorded or might be
+   recorded, and they have a right to opt out, either by terminating the
+   call or by demanding that the call not be recorded.  Therefore, this
+
+
+
+Rehor, et al.                 Informational                     [Page 2]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+   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 not be recorded.  Use cases where users participating in a call
+   are not informed that the call is or might be recorded are outside
+   the scope of this document.  In particular, lawful intercept is
+   outside the scope of this document.
+
+   Furthermore, a one-size-fits-all model will not fit all markets where
+   the scale and cost burdens vary widely and where needs differ for
+   such solution capabilities as media injection, transcoding, and
+   security.  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.
+
+   This document specifies requirements for using SIP [RFC3261] between
+   a Session Recording Client and a Session Recording Server to control
+   the recording of media that has been transmitted in the context of a
+   Communication Session.  A Communication Session is the "call" between
+   participants.  The Session Recording Client is the source of the
+   recorded media.  The Session Recording Server is the sink of recorded
+   media.  It should be noted that the requirements for the protocol
+   between a Session Recording Server and Session Recording Client have
+   very similar requirements (such as codec and transport negotiation,
+   encryption key interchange, and firewall traversal) as compared to
+   regular SIP media sessions.  The choice of SIP for session recording
+   provides reuse of an existing protocol.
+
+   The recorded sessions can be any RTP media sessions, including voice,
+   dual-tone multifrequency (DTMF) (as defined by [RFC4733]), video, and
+   text (as defined by [RFC4103]).
+
+   An archived session recording is typically comprised of the
+   Communication Session media content and the Communication Session
+   Metadata.  The Communication Session Metadata allows recording
+   archives to be searched and filtered at a later time and allows a
+   session to be played back in a meaningful way, e.g., with correct
+   synchronization between the media.  The Communication Session
+   Metadata needs to be conveyed from the Session Recording Client to
+   the Session Recording Server.
+
+   This document only considers active recording, where the Session
+   Recording Client purposefully streams media to a Session Recording
+   Server.  Passive recording, where a recording device detects media
+   directly from the network, is outside the scope of this document.
+
+
+
+
+Rehor, et al.                 Informational                     [Page 3]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+2.  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.
+
+3.  Definitions
+
+   Session Recording Server (SRS): A Session Recording Server (SRS) is a
+      SIP User Agent (UA) that is a specialized media server or
+      collector that acts as the sink of the recorded media.  An SRS is
+      typically implemented as a multi-port device that is capable of
+      receiving media from multiple sources simultaneously.  An SRS is
+      the sink of the recorded session metadata.
+
+   Session Recording Client (SRC): A Session Recording Client (SRC) is a
+      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
+      capabilities may be implemented across one or more physical
+      devices.  In practice, an SRC could be a personal device (such as
+      a SIP phone), a SIP Media Gateway (MG), a Session Border
+      Controller (SBC), or a SIP Media Server (MS) integrated with an
+      Application Server (AS).  This specification defines the term
+      "SRC" such that all such SIP entities can be generically addressed
+      under one definition.  The SRC provides metadata to the SRS.
+
+   Communication Session (CS): A session created between two or more SIP
+      User Agents (UAs) that is the subject of recording.
+
+   Recording Session (RS): The SIP session created between an SRC and
+      SRS for the purpose of recording a Communication Session.
+
+   Figure 1 pictorially represents the relationship between a Recording
+   Session and Communication Session.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rehor, et al.                 Informational                     [Page 4]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+     +-------------+                                      +-----------+
+     |             |        Communication Session         |           |
+     |     A       |<------------------------------------>|     B     |
+     |             |                                      |           |
+     +-------------+                                      +-----------+
+     ..................................................................
+     .                             Session                            .
+     .                            Recording                           .
+     .                             Client                             .
+     ..................................................................
+                                      |
+                                      | Recording
+                                      | Session
+                                      |
+                                      v
+                               +------------+
+                               |   Session  |
+                               |  Recording |
+                               |   Server   |
+                               +------------+
+
+                                 Figure 1
+
+   Metadata: Information that describes recorded media and the CS to
+      which they relate.
+
+   Pause and Resume during a Communication Session:
+      Pause: The action of temporarily discontinuing the transmission
+      and collection of 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
+   the sense defined in [RFC4949]; such terms include, but are not
+   limited to, "authentication", "confidentiality", "encryption",
+   "identity", and "integrity".
+
+4.  Use Cases
+
+   Use Case 1: Full-time Recording: One Recording Session for each
+      Communication Session.
+
+      For example, the diagram below shows the life cycle of
+      Communication Sessions (CSs) and the relationship to the Recording
+      Sessions (RS).
+
+
+
+
+
+
+Rehor, et al.                 Informational                     [Page 5]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+         CS  |--- CS 1 ---|      |--- CS 2 ---|     |--- CS 3 ---|
+
+         RS  |--- RS 1 ---|      |--- RS 2 ---|     |--- RS 3 ---|
+         t--->
+
+                                 Figure 2
+
+      Record every CS for each specific extension/person.
+
+      The need to record all calls is typically due to business process
+      purposes (such as transaction confirmation or dispute resolution)
+      or to ensure compliance with governmental regulations.
+      Applications include enterprise, contact center, and financial
+      trading floors.
+
+      This is also commonly known as Total Recording.
+
+   Use Case 2: Selective Recording: Start a Recording Session when a
+      Communication Session to be recorded is established.
+
+      In this example, Communication Sessions 1 and 3 are recorded but
+      CS 2 is not.
+
+         CS  |--- CS 1 ---|      |--- CS 2 ---|     |--- CS 3 ---|
+
+         RS  |--- RS 1----|                         |--- RS 2 ---|
+         t--->
+
+                                 Figure 3
+
+   Use Case 3: Start/Stop a Recording Session during a Communication
+      Session.
+
+      The Recording Session starts during a Communication Session,
+      either manually via a user-controlled mechanism (e.g., a button on
+      a user's phone) or automatically via an application (e.g., a
+      contact center customer service application) or business event.  A
+      Recording Session ends either during the Communication Session or
+      when the Communication Session ends.  One or more Recording
+      Sessions may record each Communication Session.
+
+
+
+
+
+
+
+
+
+
+
+Rehor, et al.                 Informational                     [Page 6]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+         CS  |------------- Communication Session -----------|
+
+         RS           |---- RS 1 ----|  |---- RS 2 -----|
+         t--->
+
+                                 Figure 4
+
+   Use Case 4: Persistent Recording: A single Recording Session captures
+      one or more Communication Sessions.
+
+                |--- CS 1 ---|      |--- CS 2 ---|     |--- CS 3 ---|
+
+         RS  |------------------- Recording Session ------------------|
+         t--->
+
+                                 Figure 5
+
+      A Recording Session records continuously without interruption.
+      Periods when there is no CS in progress must be reproduced upon
+      playback (e.g., by recording silence during such periods, or by
+      not recording such periods but marking them by means of metadata
+      for utilization on playback, etc.).  Applications include
+      financial trading desks and emergency (first-responder) service
+      bureaus.  The length of a Persistent Recording Session is
+      independent from the length of the actual Communication Sessions.
+      Persistent Recording Sessions avoid issues such as media clipping
+      that can occur due to delays in Recording Session establishment.
+
+      The connection and attributes of media in the Recording Session
+      are not dynamically signaled for each Communication Session before
+      it can be recorded; however, codec re-negotiation is possible.
+
+      In some cases, more than one concurrent Communication Session (on
+      a single end-user apparatus, e.g., trading-floor turret) is mixed
+      into one Recording Session:
+
+                       |-------- CS 1 -------|
+                          |-------- CS 2 -------|
+                     |-------- CS 3 -------|
+
+         RS  |----------- Recording Session --------------|
+         t--->
+
+                                 Figure 6
+
+
+
+
+
+
+
+Rehor, et al.                 Informational                     [Page 7]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+   Use Case 5: Real-time Recording Controls.
+
+      For an active Recording Session, privacy or security reasons may
+      demand not capturing a specific portion of a conversation.  An
+      example is for PCI (payment card industry) compliance where credit
+      card information must be protected.  One solution is not to record
+      a caller speaking their credit card information.
+
+      An example of a real-time control is Pause/Resume.
+
+   Use Case 6: IVR / Voice Portal Recording.
+
+      Self-service Interactive Voice Response (IVR) applications may
+      need to be recorded for application performance tuning or to meet
+      compliance requirements.
+
+      Metadata about an IVR session recording must include session
+      information and may include application context information (e.g.,
+      VoiceXML session variables, dialog names, etc.).
+
+   Use Case 7: Enterprise Mobility Recording.
+
+      Many agents and enterprise workers whose calls are to be recorded
+      are not located on company premises.
+
+      Examples:
+
+      o  Home-based agents or enterprise workers.
+
+      o  Mobile phones of knowledge workers (e.g., insurance agents,
+         brokers, or physicians) when they conduct work-related (and
+         legally required recording) calls.
+
+   Use Case 8: Geographically distributed or centralized recording.
+
+      Enterprises such as banks, insurance agencies, and retail stores
+      may have many locations, possibly up to thousands of small sites.
+      Frequently, only phones and network infrastructure are installed
+      in branches, without local recording services.  In cases where
+      calls inside or between branches must be recorded, a centralized
+      recording system in data centers together with telephony
+      infrastructure (e.g., Private Branch Exchange (PBX)) may be
+      deployed.
+
+
+
+
+
+
+
+
+Rehor, et al.                 Informational                     [Page 8]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+   Use Case 9: Record complex call scenarios.
+
+      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.
+
+      o  A Customer is in a conversation with a Customer Service Agent.
+
+      o  The Agent puts the Customer on hold in order to consult with a
+         Supervisor.
+
+      o  The Agent enters into a conversation with the Supervisor.
+
+      o  The Agent disconnects from the Supervisor, then reconnects with
+         the Customer.
+
+      o  The Supervisor call must be associated with the original
+         Customer call.
+
+   Use Case 10: High availability and continuous recording.
+
+      Specific deployment scenarios present different requirements for
+      system availability, error handling, etc., including the
+      following:
+
+      o  An SRS must always be available at call setup time.
+
+      o  No loss of media recording can occur, including during failure
+         of an SRS.
+
+      o  The Communication Session must be terminated (or suitable
+         notification given to parties) in the event of a recording
+         failure.
+
+   Use Case 11: Record multi-channel, multimedia session.
+
+      Some applications require the recording of more than one media
+      stream, possibly of different types.  Media are synchronized,
+      either at storage or at playback.
+
+      Speech analytics technologies (e.g., word spotting, emotion
+      detection, speaker identification) may require speaker-separated
+      recordings for optimum performance.
+
+      Multi-modal contact centers may include audio, video, IM, or other
+      interaction modalities.
+
+
+
+
+
+Rehor, et al.                 Informational                     [Page 9]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+      In trading-floor environments, in order to minimize storage and
+      recording system resources, it may be preferable to mix multiple
+      concurrent calls (Communication Sessions) on different handsets/
+      speakers on the same turret into a single recording session.
+
+   Use Case 12: Real-time media processing.
+
+      It must be possible for an SRS to support real-time media
+      processing, such as speech analytics of trading-floor
+      interactions.  Real-time analytics may be employed for automatic
+      intervention (stopping interaction or alerting) if, for example, a
+      trader is not following regulations.
+
+      Speaker separation is required in order to reliably detect who is
+      saying specific phrases.
+
+5.  Requirements
+
+   The following are requirements for SIP-based Media Recording:
+
+   o  REQ-001: The mechanism MUST provide a means for using the SIP
+      protocol for establishing, maintaining, and terminating Recording
+      Sessions between a Session Recording Client and a Session
+      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
+      CSs in their entirety, according to policy.
+
+   o  REQ-004: The mechanism MUST support the ability to record selected
+      parts of selected CSs.
+
+   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-006: The mechanism MUST support the recording of IVR sessions.
+
+   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]).
+
+
+
+
+
+Rehor, et al.                 Informational                    [Page 10]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+   o  REQ-008: The mechanism MUST support the ability for an SRC to
+      deliver mixed audio streams from multiple Communication Sessions
+      to an SRS.
+
+      Note: A mixed audio stream is where several related Communication
+      Sessions are carried in a single Recording Session.  A mixed-media
+      stream is typically produced by a mixer function.  The RS MAY be
+      informed about the composition of the mixed streams through
+      session metadata.
+
+   o  REQ-009: The mechanism MUST support the ability for an SRC to
+      deliver mixed audio streams from different parties of a given
+      Communication Session to an SRS.
+
+   o  REQ-010: The mechanism MUST support the ability to deliver to the
+      SRS multiple media streams for a given CS.
+
+   o  REQ-011: The mechanism MUST support the ability to pause and
+      resume the transmission and collection of RS media.
+
+   o  REQ-012: The mechanism MUST include a means for providing the SRS
+      with metadata describing CSs that are being recorded, including
+      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
+      to correlate RS media with CS participant media.
+
+   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-016: The mechanism MUST support a means for a recording-aware
+      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 a request being dependent on policy.
+
+   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 the CS should be started, paused, resumed, or stopped, the
+      honoring of such a request being dependent on policy.  Such
+      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 announcements during recording or at the start of a CS to
+      support notification to participants that the call is being
+      recorded or may be recorded.
+
+
+
+Rehor, et al.                 Informational                    [Page 11]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+   o  REQ-019: The mechanism MUST provide a means of indicating to
+      recording-aware UAs whether recording is taking place, for
+      appropriate rendering at the user interface.
+
+   o  REQ-020: The mechanism MUST provide a way for metadata to be
+      conveyed to the SRS incrementally during the CS.
+
+   o  REQ-021: The mechanism MUST NOT prevent high-availability
+      deployments.
+
+   o  REQ-022: The mechanism MUST provide means for facilitating
+      synchronization of the recorded media streams and metadata.
+
+   o  REQ-023: The mechanism MUST provide means for facilitating
+      synchronization among the recorded media streams.
+
+   o  REQ-024: The mechanism MUST provide means to relate recording and
+      recording controls, such as start/stop/pause/resume, to the wall
+      clock time.
+
+   o  REQ-025: The mechanism MUST provide means for an SRS to
+      authenticate the SRC on RS initiation.
+
+   o  REQ-026: The mechanism MUST provide means for an SRC to
+      authenticate the SRS on RS initiation.
+
+   o  REQ-027: The mechanism MUST include a means for ensuring that the
+      integrity of the metadata sent from the SRC to the SRS is an
+      accurate representation of the original CS metadata.
+
+   o  REQ-028: The mechanism MUST include a means for ensuring that the
+      integrity of the media sent from the SRC to the SRS is an accurate
+      representation of the original CS media.
+
+   o  REQ-029: The mechanism MUST include a means for ensuring the
+      confidentiality of the metadata sent from the SRC to the SRS.
+
+   o  REQ-030: The mechanism MUST provide a means to support RS
+      confidentiality.
+
+   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,
+      video).  One example is the case of delivering unmixed audio for
+      each participant in the CS.
+
+
+
+
+
+
+
+Rehor, et al.                 Informational                    [Page 12]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+6.  Privacy Considerations
+
+   Respecting the privacy rights and wishes of users engaged in a call
+   is of paramount importance.  In many jurisdictions, participants have
+   a right to know that the session is being recorded or might be
+   recorded, and they have a right to opt out, either by terminating the
+   call or by demanding that the call not be recorded.  Therefore, this
+   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 not be recorded.  Use cases where users participating in a call
+   are not informed that the call is or might be recorded are outside
+   the scope of this document.  In particular, lawful intercept is
+   outside the scope of this document.
+
+   Requirements for participant notification of recording vary widely by
+   jurisdiction.  In a given deployment, not all users will be
+   authorized to stop the recording of a CS (although any user can
+   terminate its participation in a CS).  Typically, users within the
+   domain that is carrying out the recording will be subject to policies
+   of that domain concerning whether CSs are recorded.  For example, in
+   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
+   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
+   agent is unable to prevent recording, or if the caller does not trust
+   the agent, the only option generally is to terminate the CS.
+
+   Privacy considerations also extend to what happens to a recording
+   once it has been created.  Typical issues are who can access the
+   recording (e.g., receive a copy of the recording, view the metadata,
+   play back the media, etc.), for what purpose the recording can be
+   used (e.g., for training purposes, for quality control purposes,
+   etc.), and for how long the recording is to be retained before
+   deletion.  These are typically policies of the domain that makes the
+   recording, rather than policies of individual users involved in a
+   recorded CS, whether those users be in the same domain or in a
+   different domain.  Taking the call center example again, agents might
+   be made aware of call center policy regarding retention and use of
+   recordings as part of their employment contract, and callers from
+   outside the call center might be given some information about policy
+   when notified that a CS will be recorded (e.g., through an
+   announcement that says that calls may be recorded for quality
+   purposes).
+
+
+
+
+
+
+
+
+Rehor, et al.                 Informational                    [Page 13]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+   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
+   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
+   environment and can ensure that recordings are stored and used in
+   accordance with that policy.
+
+7.  Security Considerations
+
+   Session recording has substantial security implications, for the SIP
+   UAs being recorded, the SRC, and the SRS.
+
+   For the SIP UAs involved in the Communication Session, the
+   requirements in this document enable the UA to identify that a
+   Communication Session is being recorded and to request that a given
+   Communication Session not be subject to recording.
+
+   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 Public Switched Telephone Network (PSTN) gateway without any
+   ability to pass on in-signaling indications of recording, users can
+   be notified of recording in the media itself through voice
+   announcements, a visual indicator on the endpoint, or other means.
+
+   With regard to security implications of the protocol(s), clearly
+   there is a need for authentication, authorization, and eavesdropping
+   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
+   different domains.  Both the signaling and media for the Recording
+   Session need the ability to be authenticated and protected from
+   eavesdropping.  Requirements are detailed in Section 5.
+
+   Communication Sessions and Recording Sessions can require different
+   security levels both for signaling and media, depending on deployment
+   configurations.  For some environments, e.g., the SRS and SRC 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 public
+   network, for example.  For other environments, the SRS can be 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 a
+   direct relationship between the security level of Communication
+   Sessions and the security level of Recording Sessions.
+
+   A malicious or corrupt SRC can tamper with media and metadata
+   relating to a CS before sending the data to an SRS.  Also, CS media
+   and signaling can be tampered with in the network prior to reaching
+   an SRC, unless proper means are provided to ensure integrity
+   protection during transmission on the CS.  Means for ensuring the
+
+
+
+Rehor, et al.                 Informational                    [Page 14]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+   correctness of media and metadata emitted by an SRC are outside the
+   scope of this work.  Other organizational and technical controls will
+   need to be used to prevent tampering.
+
+8.  Acknowledgements
+
+   Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings,
+   Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper,
+   Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and
+   Charles Eckel for their significant contributions and assistance with
+   this document and the SIPREC WG, and to all the members of the
+   DISPATCH WG and SIPREC WG mailing lists for providing valuable input
+   to this work.
+
+9.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [RFC4103]  Hellstrom, G. and P. Jones, "RTP Payload for Text
+              Conversation", RFC 4103, June 2005.
+
+   [RFC4733]  Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
+              Digits, Telephony Tones, and Telephony Signals", RFC 4733,
+              December 2006.
+
+   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
+              FYI 36, RFC 4949, August 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rehor, et al.                 Informational                    [Page 15]
+
+RFC 6341                 Requirements for SIPREC             August 2011
+
+
+Authors' Addresses
+
+   Ken Rehor (editor)
+   Cisco Systems
+   170 West Tasman Dr.
+   Mail Stop SJC30/2/
+   San Jose, CA  95134
+   USA
+
+   EMail: krehor@cisco.com
+
+
+   Leon Portman (editor)
+   NICE Systems
+   8 Hapnina
+   Ra'anana  43017
+   Israel
+
+   EMail: leon.portman@nice.com
+
+
+   Andrew Hutton
+   Siemens Enterprise Communications
+
+   EMail: andrew.hutton@siemens-enterprise.com
+   URI:   http://www.siemens-enterprise.com
+
+
+   Rajnish Jain
+   IPC Systems
+   777 Commerce Drive
+   Fairfield, CT  06825
+   USA
+
+   EMail: rajnish.jain@ipc.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rehor, et al.                 Informational                    [Page 16]
+