SIPREC Ram Mohan. Ravindranath
Internet-Draft Parthasarathi. Ravindran
Intended status: Standards Track Paul. Kyzivat
Expires: April 10, 2011 Cisco Systems, Inc.
October 7, 2010
Session Initiation Protocol (SIP) Recording Metadata
draft-ram-siprec-metadata-01
Abstract
Session recording is a critical requirement in many communications
environments such as call centers and financial trading. In some of
these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons. Recording of a session
is typically performed by sending a copy of a media stream to a
recording device. This document describes the metadata model as
viewed by Session Recording Server(SRS).
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 April 10, 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
Ravindranath, et al. Expires April 10, 2011 [Page 1]
Internet-Draft SIP Recording Metadata October 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Metadata Model . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Recording Metadata elements . . . . . . . . . . . . . . . . . . 5
4.1. Recording Session . . . . . . . . . . . . . . . . . . . . . 5
4.2. Communication Session . . . . . . . . . . . . . . . . . . . 5
4.3. Recorded Media Streams . . . . . . . . . . . . . . . . . . 6
4.4. Received Media Streams . . . . . . . . . . . . . . . . . . 6
4.5. Participant . . . . . . . . . . . . . . . . . . . . . . . . 6
4.6. Application Data . . . . . . . . . . . . . . . . . . . . . 6
5. Association of different Recording metadata elements . . . . . 6
5.1. Recording Session : Communication Session . . . . . . . . . 6
5.2. Communication Session : Recorded Media Stream . . . . . . . 7
5.3. Recorded Media Stream : Received Media Stream . . . . . . . 7
5.4. Received Media Stream : Participant . . . . . . . . . . . . 7
5.5. Participant : Application Data . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Ravindranath, et al. Expires April 10, 2011 [Page 2]
Internet-Draft SIP Recording Metadata October 2010
1. Introduction
Session recording is a critical requirement in many communications
environments such as call centers and financial trading. In some of
these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons. Recording of a session
is typically performed by sending a copy of a media stream to a
recording device. This document focuses on the Recording metadata
which describes the communication session. The document describes a
metadata modelas viewed by Session Recording Server, the architecture
for which is described in [I-D.ietf-siprec-architecture] and the
requirements for which are described in [I-D.ietf-siprec-req].
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 [RFC2119]. This
document only uses these key words when referencing normative
statements in existing RFCs."
3. Metadata Model
Metadata is the data that describes the communication session. Below
diagram shows a model for Metadata as viewed by Session Recording
Server (SRS).
Ravindranath, et al. Expires April 10, 2011 [Page 3]
Internet-Draft SIP Recording Metadata October 2010
+-------------------------------+
| Recording Session (RS) |
+-------------------------------+
| Recording RequestorID(SRC or |
| SRS) | 1
| Reason for Recording |---------------+
| Recording Type (Selective | |
| Persistant) | |
+-------------------------------+ |
| 1..* |
| |
| 0..* |
+-------------------------------+ 1 |
| Communication Session (CS) |---------------|
+-------------------------------+ | +--------------+
| 1 | | |
| | 0..* |Application |
| 0..* |------| Data |
+-------------------------------+ | | |
| Recorded Media Stream | | +--------------+
+-------------------------------+ |
| Recorded Media Stream | |
| Type (audio/video/...) | 1 |
| Recorded Encoding |---------------|
| Recorded Bits | |
+-------------------------------+ |
| 1 |
| |
| 1..* |
+-------------------------------+ |
| Received Media Stream | |
+-------------------------------+ |
| Start Time | 1 |
| End Time |---------------|
| Codec | |
| Media Stream Reference | |
+-------------------------------+ |
| 1..* |
| |
| 1..* |
+-------------------------------+ |
| Participant | |
+-------------------------------+ 1 |
| AoR |---------------+
| Name |
+-------------------------------+
Ravindranath, et al. Expires April 10, 2011 [Page 4]
Internet-Draft SIP Recording Metadata October 2010
The metadata model above MUST be used by a SRS. (NOTE: Not entirely
clear what sort of normative statement to make about this.)
The Session Recording Client (SRC) MUST initiate the Recording
Session. It should be noted that the Recording Session is a
completely independent from the Communication Session that is being
recorded at both the SIP dialog level and at the session level. The
metadata MUST be conveyed from SRC to SRS. The metadata MAY be
conveyed in Recording Session Dialog.
Note that the metadata model captures changes that occur over the
duration of the recording session. For example, if the call is
transferred from one participant to another, then the SRC MUST convey
a change of participant and received media stream in the
communication session.
Some of the data in the model may not be conveyed explicitly from the
SRC to the SRS, if it can be obtained contextually by the SRS. For
instance, the timing of changes may not explicitly conveyed from the
SRC to the SRC, because the mechanism (yet to be defined) which
conveys the metadata may implicitly provide the timing. (E.g. the
time a change occurred by be assumed to be the same as the time when
notification of the change is received by the SRS.)
4. Recording Metadata elements
This section describes the different elements and its attributes of
the metadata model shown above.
4.1. Recording Session
A Recording Session element represents one instance of a Recording
Session. It MAY have attributes like Recording requestor ID(which
could be SRS or SRC), reason for recording and recording type. The
reason for recording MUST be a policy(in a financial trading floor or
Call centre) or to monitor a agent, or for quality purposes etc. The
recording type attribute indicates whether the recording session is
selective or persistant.
4.2. Communication Session
A Communication Session element represents one instance of a
Communication Session.
NOTE: Discussions are needed to determine different attributes of CS
which are needed for SRS
Ravindranath, et al. Expires April 10, 2011 [Page 5]
Internet-Draft SIP Recording Metadata October 2010
4.3. Recorded Media Streams
A Recorded Media Stream represents the content of a media stream
captured and stored by the SRS. A Communication Session MUST have
one, and MAY have several, Recorded Media Streams. In addition to
the recorded media, it has attributes describing the encoding of the
recording.
4.4. Received Media Streams
A Received Media Stream is an element that represents a media stream
received by the SRS that contributed content to a recorded media
stream. There MUST be one Received Media Stream per Recorded Media
Stream if mixing is done before recording, or several if a separate
unmixed stream per participant is supplied. Or there could be
multiple per source (with disjoint time intervals) due to codec
changes.
The Received Media Stream element can have attributes like Start
time, End time, Codec, Media Stream reference.
4.5. Participant
A Participant represents one contributor of media. Participant has
attributes like AoR, Name. AoR MAY be SIP/SIPS/TEL URI.
4.6. Application Data
A recording metadata object MAY have a opaque application data. This
opaque data is intended to be used by vendor specific applications on
SRS.
5. Association of different Recording metadata elements
This section describes in brief on how the different elements of
metadata are associated.
5.1. Recording Session : Communication Session
A Recording Session element MAY have zero or more CS per RS. One CS
per RS is typical. Multiple CS per RS can arise due to private side
conversations, etc. Having no Communication Sessions is possible if
the RS is established in anticipation of future CS.
NOTE: We are currently modeling exactly one RS per CS, as a stake in
the ground. The assumption is that its difficult to distinguish a
single CS viewed from two different RSs. But this requires
Ravindranath, et al. Expires April 10, 2011 [Page 6]
Internet-Draft SIP Recording Metadata October 2010
discussion.
5.2. Communication Session : Recorded Media Stream
Communication Session MAY have zero or more Recorded Media Streams
for various reasons. Distinct media might have their own. (Or not -
maybe audio/video together.) Independent sources might be recorded
separately.
A Recorded Media Stream is always associated with exactly one
Recording Session.
5.3. Recorded Media Stream : Received Media Stream
There MUST be one or more Received Media Streams per Recorded Media
Stream. There may be one if mixing is done before recording, or if
media only flows in one direction. There may be several if a
separate unmixed stream per participant is supplied and mixing is
done at the recorder. Or there could be multiple for a single
participant (with disjoint time intervals) due to codec changes.
A Received Media Stream is always associated with exactly one
Recorded Media Stream.
5.4. Received Media Stream : Participant
A Received Media Stream MUST have one or more participants.
Typically there will be one, unless mixed before being sent to RS, in
which case there may be several.
A Participant MAY supply multiple Received Media Streams.
5.5. Participant : Application Data
NOTE: This is a place holder for as yet undefined data.
6. Security Considerations
The Recording Session is fundamentally a standard SIP dialog
[RFC3261] and media session and therefore make use of existing SIP
security mechanisms for securing the Recording Session and Media
Recording Metadata.
7. IANA Considerations
Not Applicable
Ravindranath, et al. Expires April 10, 2011 [Page 7]
Internet-Draft SIP Recording Metadata October 2010
8. Acknowledgement
We wish to thank John Elwell, Henry Lum and Leon Portman for the
valuable comments.
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.
[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.ietf-siprec-req]
Rehor, K., Jain, R., Portman, L., and A. Hutton,
"Requirements for SIP-based Media Recording (SIPREC)",
draft-ietf-siprec-req-02 (work in progress),
September 2010.
[I-D.ietf-siprec-architecture]
Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
Architecture for Media Recording using the Session
Initiation Protocol", draft-ietf-siprec-architecture-00
(work in progress), June 2010.
Authors' Addresses
Ram Mohan R
Cisco Systems, Inc.
Cessna Business Park,
Kadabeesanahalli Village, Varthur Hobli,
Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: rmohanr@cisco.com
Ravindranath, et al. Expires April 10, 2011 [Page 8]
Internet-Draft SIP Recording Metadata October 2010
Parthasarathi R
Cisco Systems, Inc.
Cessna Business Park,
Kadabeesanahalli Village, Varthur Hobli,
Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: partr@cisco.com
P. Kyzivat
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Email: pkyzivat@cisco.com
Ravindranath, et al. Expires April 10, 2011 [Page 9]