SIPREC L. Portman, Ed.
Internet-Draft NICE Systems
Intended status: Informational December 13, 2010
Expires: June 16, 2011
The SIP-based Media Recording Protocol (SIPREC)
draft-portman-siprec-protocol-00
Abstract
SIPREC Session Recording Protocol is used for establishing recording
session and reporting of the medata of the communication session.
This document specifies the SIPREC Protocol (SIPREC). SIPREC is used
between Session Recording Client (SRC) and Session Recording Server
(SRS).
Status of this Memo
This Internet-Draft is submitted 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 June 16, 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
Portman Expires June 16, 2011 [Page 1]
Internet-Draft SIPREC Protocol December 2010
described in the Simplified BSD License.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
5. SIP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Authentication and Authorization . . . . . . . . . . . . . . . 9
8. Recording Pause and Resume . . . . . . . . . . . . . . . . . . 9
9. Failover and Recovery . . . . . . . . . . . . . . . . . . . . 9
10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
15. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Portman Expires June 16, 2011 [Page 2]
Internet-Draft SIPREC Protocol December 2010
1. Introduction
Communication Session recording requires establishment of the
recording session between communication system and recording system.
In order to allow access to such recordings, information about the
communication session (metadata) is also shared between SRC and SRS.
The SIPREC Requirements [?] list a set of requirements that need to
be met by session recording protocols. The SIPREC protocol, which is
specified in this document, meets these requirements.
The SIPREC protocol is designed to support both UDP and TCP for SIP
session establishment with special attention to reducing size of the
required SIP messages. In addition, it is designed for future
extendability and protocol version management (backward
compatability).
The remainder of this document is organized as follows: Section 2
defines the terminology used throughout this document, Section 3
discusses the scope of SIPREC (i.e., which tasks fall within the
scope of SIPREC and which ones are performed using different
mechanisms), Section 4 provides a non-normative overview of SIPREC
operation, and subsequent sections provide the normative
specification of SIPREC.
2. 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 a logical
function that typically archives media for extended durations of time
and provides interfaces for search and retrieval of the archived
media. An SRS is typically implemented as a multi-port device that
is capable of receiving media from several sources simultaneously.
An SRS is typically also 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 itself or
another entity working on its behalf (such as a SIP Application
Server) may act as the source of the recording metadata.
Portman Expires June 16, 2011 [Page 3]
Internet-Draft SIPREC Protocol December 2010
Communication Session (CS): A session created between two or more SIP
User Agents (UAs) that is the target for recording.
Recording Session (RS): The SIP session created between an SRC and
SRS for the purpose of recording a Communication Session.
Figure 1 shows communication and recording sessions.
+-------------+ +-----------+
| | 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.
SIPREC: The set of SIP extensions that supports recording of
Communication Sessions.
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.
Portman Expires June 16, 2011 [Page 4]
Internet-Draft SIPREC Protocol December 2010
3. Scope
The scope of the SIPREC protocol is establishment of the recording
sessions and reporting of the metadata. The actual recording policy
logic and access to the recorded sessions are out of scope of SIPREC.
Figure 2 shows the tasks that SIPEC can perform.
+-----------+
(Recording Session) | Session |
+----SIP-------->| Recording |
| | Server |
| +----RTP---->| (SRS) |
| | +-----------+
V | ^
+-------------+ |
| | |
| |--- MetaData -+
| |
| B2BUA |
| |
| Session |
+--------+ | Recording | +---------+
| |<- SIP ->| Client |<- SIP ->| |
| UA-A | | (SRC) | | UA-B |
| |<- RTP ->| |<- RTP ->| |
+--------+ | | +---------+
+-------------+
(Communication Session) (Communication Session)
Figure 2
4. Overview of Operation
This section provides a description of SIPREC operations.
Figure 3 shows basic recording flow
Portman Expires June 16, 2011 [Page 5]
Internet-Draft SIPREC Protocol December 2010
UA A SRC UA B SRS
|(1)CS INVITE | | |
|--------------------->| | |
| |(2)CS INVITE | |
| |---------------------->| |
| | (3)OK | |
| |<----------------------| |
| (4)OK | | |
|<---------------------| | |
| |(5)RS INVITE (CallId + Participants) with SDP |
| |---------------------------------------------------->|
| | | (6)OK with SDP |
| |<----------------------------------------------------|
|(7)CS RTP | | |
|--------------------->|---------------------->| |
|<---------------------|<----------------------| |
| |(8)RS RTP | |
| |---------------------------------------------------->|
| |---------------------------------------------------->|
| |(10)INFO with mid session metadata |
| |---------------------------------------------------->|
|(10)CS BYE | | |
|--------------------->| | |
| |(11)RS BYE | |
| |---------------------------------------------------->|
| | | |
Figure 3
5. SIP Extensions
The SRC should be able to accept re-Invite from SRS with the updated
SDP as part of the session timer mechanism.
The SRC and SRS should support inactive/receive only attributes in
SDP and re- INVITE for media updates.
When SRC sends INVITE to SRC, SRS might respond with a=inactive
attribute as part of the SDP in the 200 OK response. A re-INVITE
will be sent in order to update the SRC with the updated SDP.
As SRS only receives RTP streams from SRS, the 200 OK response will
contain SDP with a=recvonly attribute.
The From header must contain the SRC identity. Participants
information will be reported via metadata mechanism
Portman Expires June 16, 2011 [Page 6]
Internet-Draft SIPREC Protocol December 2010
Basic metadata information such as participants,call identifiers and
direction should be passed in METADATA SIP header within INVITE
request.
Any other metadata should be passed as part of metadata event. The
meatadata reporting is using SIP Subscribe/Notify messages.
SRC will send one or more streams to the SRC. SRS will respond with
the same number of media descriptors in the SDP body of the 200 OK.
The SDP from the SRS will contain i attribute (information) to
describe content of media lines. For example, i=rx:1 tx:2 means that
the first media descriptor is intended for the RX and the second
media descriptor is intended for TX. The following SDP example shows
the use of i for specifying the directions:
v=0
o=SRS 0 0 IN IP4 172.22.3.8
s=SRS
i=rx:1 tx:2
c=IN IP4 172.22.3.8
t=0 0
m=audio 12241 RTP/AVP 0 4 8
a=sendrecv
m=audio 12242 RTP/AVP 0 4 8
a=sendrecv
Figure 4
Note: SRC RX stream is the stream (duplication) from the Customer to
the Agent. SRC TX stream is the stream (duplication) from the Agent
to the Customer.
[LEON] Open question: do we want to support both SDP in SRC offer and
SRS answer?
The following SIP example for RS establishment between SRC and SRS
Portman Expires June 16, 2011 [Page 7]
Internet-Draft SIPREC Protocol December 2010
INVITE sip:97753210@10.240.3.10:5060 SIP/2.0
From: <sip:2000@10.226.240.3>;tag=35e195d2-947d-4585-946f-098392474d66-91866485
To: <sip:Recorder@10.240.3.10>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a@10.226.240.3
CSeq: 101 INVITE
Date: Thu, 26 Nov 2009 02:38:49 GMT
Metadata: [TBD];
Supported: timer
Supported: replaces
User-Agent: B2BUA
Max-Forwards: 70
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY,PUBLISH
Allow-Events: presence,kpml Min-SE: 90
Contact: <sip:2000@10.226.240.3:5060;transport=tcp>;isfocus
Via: SIP/2.0/TCP 10.226.240.3:5060;branch=z9hG4bKdf6b622b648d9
Session-Expires: 1800
Figure 5
The following sequence diagram shows an example of SRS responds with
SDP that contain a=inactive + a media information update with re-
INVITE.
Portman Expires June 16, 2011 [Page 8]
Internet-Draft SIPREC Protocol December 2010
SRC SRS
| |
|(1) INVITE |
|---------------------------------------------------->|
| (2)200 OK with SDP inactive |
|<----------------------------------------------------|
|(3) ACK with SDP |
|---------------------------------------------------->|
| ... |
| (4) re-INVITE with SDP recv-only|
|<----------------------------------------------------|
|(5)200 OK with SDP |
|---------------------------------------------------->|
| (6) ACK with SDP |
|<----------------------------------------------------|
| ... |
|(7) BYE |
|---------------------------------------------------->|
| (8) ACK |
|<----------------------------------------------------|
Figure 6
6. Transport
TBD
7. Authentication and Authorization
TBD
8. Recording Pause and Resume
TBD
9. Failover and Recovery
TBD
10. Error Handling
TBD
Portman Expires June 16, 2011 [Page 9]
Internet-Draft SIPREC Protocol December 2010
11. Security Considerations
TBD
12. IANA Considerations
TBD.
13. Acknowledgements
TBD
14. Contributors
TBD
15. 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.
Author's Address
Leon Portman (editor)
NICE Systems
8 Hapnina
Ra'anana 43017
Israel
Email: leon.portman@nice.com
Portman Expires June 16, 2011 [Page 10]