SIPREC Ram Mohan. Ravindranath
Internet-Draft Parthasarathi. Ravindran
Intended status: Standards Track Paul. Kyzivat
Expires: February 24, 2011 Cisco Systems, Inc.
August 23, 2010
Session Initiation Protocol (SIP) Recording Metadata
draft-ram-siprec-metadata-00
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 February 24, 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 February 24, 2011 [Page 1]
Internet-Draft SIP Recording Metadata August 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 Group . . . . . . . . . . . . . . . . . . 5
4.2. Recording Session . . . . . . . . . . . . . . . . . . . . . 5
4.3. Communication Session . . . . . . . . . . . . . . . . . . . 5
4.4. Recorded Media Streams . . . . . . . . . . . . . . . . . . 5
4.5. Received Media Streams . . . . . . . . . . . . . . . . . . 6
4.6. Participant . . . . . . . . . . . . . . . . . . . . . . . . 6
4.7. Application Data . . . . . . . . . . . . . . . . . . . . . 6
5. Association of different Recording metadata elements . . . . . 6
5.1. Recording Session Group : Recording Session . . . . . . . . 6
5.2. Recording Session : Communication Session . . . . . . . . . 6
5.3. Communication Session : Recorded Media Stream . . . . . . . 7
5.4. Recorded Media Stream : Received Media Stream . . . . . . . 7
5.5. Received Media Stream : Participant . . . . . . . . . . . . 7
5.6. Participant : Application Data . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Ravindranath, et al. Expires February 24, 2011 [Page 2]
Internet-Draft SIP Recording Metadata August 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", "MUST", "MUST 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).
+-------------------------------+
| Recording Session Group |
+-------------------------------+
| 0..*
|
| 1..*
+-------------------------------+
| Recording Session (RS) |
+-------------------------------+
| Recording RequestorID(SRC or |
| SRS) |
| Reason for Recording |
| Recording Type (Selective |
| Persistant) |
+-------------------------------+
| 1..*
|
| 0..*
Ravindranath, et al. Expires February 24, 2011 [Page 3]
Internet-Draft SIP Recording Metadata August 2010
+-------------------------------+
| Communication Session (CS) |
+-------------------------------+
| 1
|
| 0..*
+-------------------------------+
| Recorded Media Stream |
+-------------------------------+
| Type (audio/video/...) |
| Recorded Encoding |
| Recorded Bits |
+-------------------------------+
| 1
|
| 1..*
+-------------------------------+
| Received Media Stream |
+-------------------------------+
| Start Time |
| End Time |
| Codec |
| Media Stream Reference |
+-------------------------------+
| 1..*
|
| 1..*
+-------------------------------+
| Participant |
+-------------------------------+
| AoR |
| Name |
+-------------------------------+
| 0
|
| 1..*
+-------------------------------+
| Application Data |
+-------------------------------+
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
Ravindranath, et al. Expires February 24, 2011 [Page 4]
Internet-Draft SIP Recording Metadata August 2010
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.
4. Recording Metadata elements
This section describes the different elements and its attributes of
the metadata model shown above.
4.1. Recording Session Group
A recording Session Group represents a collection of related
Recording Sessions maintained by SRS. Recording Session Groups are
optional - they need not be present in the common case where
Recording Sessions are independent of one another.
(A group with multiple sessions might arise when recordings of the
same or different communication sessions independently initiate
recording sessions.)
4.2. 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.3. 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
4.4. 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.
Ravindranath, et al. Expires February 24, 2011 [Page 5]
Internet-Draft SIP Recording Metadata August 2010
4.5. 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.6. Participant
A Participant represents one contributor of media. Participant has
attributes like AoR, Name. AoR MAY be SIP/SIPS/TEL URI.
4.7. 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 Group : Recording Session
A Recording Session Group element MUST have one or more Recording
Session elements.
NOTE: Model is currently permitting a single Recording Session to
participate in more than one Recording Session Group. Its unclear if
this makes sense. Might be better to restrict to one or none.
5.2. 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
Ravindranath, et al. Expires February 24, 2011 [Page 6]
Internet-Draft SIP Recording Metadata August 2010
single CS viewed from two different RSs. But this requires
discussion.
5.3. 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.4. 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.5. 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.6. 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 and
media session and therefore make use of existing SIP security
mechanisms for securing the Recording Session and Media Recording
Metadata.
Ravindranath, et al. Expires February 24, 2011 [Page 7]
Internet-Draft SIP Recording Metadata August 2010
7. IANA Considerations
Not Applicable
8. References
8.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.
8.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-00 (work in progress), May 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 February 24, 2011 [Page 8]
Internet-Draft SIP Recording Metadata August 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 February 24, 2011 [Page 9]