SIP Call Control - Recording Extensions
draft-johnston-siprec-cc-rec-00

Abstract

This document defines SIP extensions for session recording to meet the requirements in the "Requirements for SIP-based Media Recording (SIPREC)" document. In particular, mechanisms to allow SIP elements to distinguish between the Recording Session and the Communication Session. Also a mechanism for a UA to learn that the communication session is being recorded is proposed. The Metadata about the session is not covered by this document. SIP feature tags 'srs', 'src', and 'recorded' are defined to identify the Session Recording Server, Session Recording Client, and the presence of recording in the communication session.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months 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.”

This Internet-Draft will expire on January 4, 2011.

Copyright Notice

Copyright (c) 2010 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.  Overview
2.  Terminology
3.  Requirements
4.  Callee Capabilities Extensions for SIP Recording
    4.1.  src Feature Tag
    4.2.  srs Feature Tag
    4.3.  recorded Feature Tag
5.  Architecture
6.  Security Considerations
7.  Normative References
§  Authors' Addresses

1.  Overview

The motivation, requirements, and use cases for SIP recording are discussed in in [I‑D.ietf‑siprec‑req] (Rehor, K., Jain, R., Portman, L., and A. Hutton, “Requirements for SIP-based Media Recording (SIPREC),” May 2010.). This draft discusses the use of SIP [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) as the session recording protocol. While most of the functions of the call recording protocol can be met by unextended SIP, there are a few that need extensions. This draft looks at a few of these functions and proposes some extensions to implement them.

2.  Terminology

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 BCP 14, RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Requirements

This section discusses the requirements in [I‑D.ietf‑siprec‑req] (Rehor, K., Jain, R., Portman, L., and A. Hutton, “Requirements for SIP-based Media Recording (SIPREC),” May 2010.) relating to the session recording protocol that require SIP extensions. They are:

REQ-010 A request for a new Recording Session MUST be redirected to an available SRS.

REQ-023 The mechanism MUST support a means for a SIP UA to request that a session is not recorded.

REQ-024 The mechanism MUST provide a means of indicating to the end users of a Communication Session that the session in which they are participating is being recorded.

REQ-030 The mechanism MUST enable the Recording Session to identify itself as a SIP session that is established for the purpose of recording.

The proposed mechanism extends the SIP callee capabilties and caller preferences to meet these requirements.

4.  Callee Capabilities Extensions for SIP Recording

This section discusses how the callee capabilities defined in [RFC3840] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.) can be extended for SIP call recording.

SIP Callee Capabilities defines feature tags which are used to represent characteristics and capabilities of a UA. From RFC 3840:

"Capability and characteristic information about a UA is carried as parameters of the Contact header field. These parameters can be used within REGISTER requests and responses, OPTIONS responses, and requests and responses that create dialogs (such as INVITE)."

Note that feature tags are also used in dialog modifying requests and responses such as re-INVITE and responses to a re-INVITE, and UPDATE. The 'isfocus' feature tag, defined in [RFC4579] (Johnston, A. and O. Levin, “Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents,” August 2006.) is similar semantically to this case: it indicates that the UA is acting as a SIP conference focus, and is performing a specific action (mixing) on the resulting media stream. This information is available from OPTIONS queries, dialog package notifications, and the SIP registration event package.

We propose the definition of three new feature tags: 'src', 'srs', and 'recorded'.

4.1.  src Feature Tag

The 'src' feature tag is used in Contact URIs by the Session Recording Client (SRC) related to recording sessions. A Session Recording Server uses the presence of this feature tag in dialog creating and modifying requests and responses to confirm that the dialog being created is for the purpose of a Recording Session (REQ-30). In addition, a registrar could discover that a UA is an SRC based on the presence of this feature tag in a registration. Other SIP Recording extensions and behaviors can be triggered by the presence of this feature tag.

Note that we could use a single feature tag, such as 'recording' used by either an SRC or SRS to identify that the session is a recording session. However, due to the differences in functionality and behavior between an SRC and SRS, using only one feature tag for both is not ideal. For instance, if a routing mistake resulted in a request from a SRC being routed back to another SRC, if only one feature tag were defined, they would not know right away about the error and could become confused. With separate feature tags, they would realize the error immediately and terminate the session. Also, call logs would clearly show the routing error.

4.2.  srs Feature Tag

The 'srs' feature tag is used in Contact URIs by the Session Recording Server (SRS) related to recording sessions. A Session Recording Client uses the presence of this feature tag in dialog creating and modifying requests and responses to confirm that the dialog being created is for the purpose of a Recording Session (REQ-30). In addition, a registrar could discover that a UA is an SRS based on the presence of this feature tag in a registration. Other SIP Recording extensions and behaviors can be triggered by the presence of this feature tag.

To ensure a recording session is redirected to an SRS (REQ-10), an SRC can utilize the SIP Caller Preferences extensions, defined in [RFC3841] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” August 2004.). The presence of a Accept-Contact: *;sip.srs allows a UA to request that the INVITE be routed to an SRS. Note that to be completely sure, the SRC would need to include a Require: prefs header field field in the request.

4.3.  recorded Feature Tag

The 'recorded' feature tag is used exclusively in recorded Communication Sessions by the Session Recording Client (SRC). An SRC recording a session includes this feature tag in the Communicaton Session to indicate that some part of the media for the session is being recorded (REQ-24). A UA receiving the 'recorded' feature tag in a dialog establishing or modifying request or response knows the media is being recorded and renders this information to the user.

When recording is initiated (in the initial INVITE or 200 OK, or by a re-INVITE or UPDATE mid-call), the UA can use the presence of the 'recorded' feature tag to initiate a disconnect of the session, sending a BYE with a Reason header field indicating that the termination is due to the UA refusing recording of the session. Also note that a signaling indication such as this does not replace other notifications such as tones and announcements played in the media path. However, the ability to set a policy for no recording in a UA and have the UA able to take automatic action is useful. A UA can also render this information to the user - consider an incoming INVITE with the 'recorded' feature tag included - the UA can tell the user during alerting that the resulting call, if answered, will be recorded, allowing the user to take appropriate action. This partially supports REQ-24.

Editor's Note: We considered the use of the SIP Caller Preferences extensions, defined in [RFC3841] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” August 2004.) to allow a UA to request a call not be recorded, i.e. using a Reject-Contact: *;sip.recorded allows a UA to request that recording not be used. However, this requires the all proxies and UAs support caller prefs (Require: prefs). Some other mechanism to fully support REQ-23, perhaps a 'norecord' SIP option tag is needed instead.

5.  Architecture

The SIP feature tags 'srs' and 'src' defined in this document support the proposed architecture by providing a clear indication that a session is a Recording Session and identifying the Session Recording Server (SRS) and Session Recording Client (SRC) which are described in the architecture [I‑D.ietf‑siprec‑architecture] (Hutton, A., Portman, L., Jain, R., and K. Rehor, “An Architecture for Media Recording using the Session Initiation Protocol,” June 2010.).

6.  Security Considerations

This draft defines three new SIP feature tags. Feature tags are transported as Contact header field parameters. In order to rely on them, integrity protection of the SIP message or response is required. SIP transport over TLS over a single hop provides integrity protection for feature tags. Unfortunately, multi-hop integrity protection provided by RFC 4474 does not help, as only the address part of the Contact URI is protected by the signature in the Identity header field.

An attacker modifying or removing an 'src' or 'srs' feature tag could attempt to impersonate a SIP Recording Server or a SIP Recording Client. An SRS and SRC must authenticate each other before establishing or modifying recording sessions and can not just rely on the presence of these feature tags.

An attacker removing or adding a 'recorded' feature tag could try to hide the fact that recording is taking place, or pretend that recording is taking place when it is not. This could result in incorrect announcements and indications being played to the user, and possibly the teardown of calls if the UA has a policy of not allowing recording.

7. Normative References

Authors' Addresses