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: ;tag=35e195d2-947d-4585-946f-098392474d66-91866485 To: 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: ;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]