internet engineering task force (ietf) r. ravindranath ... · pdf fileissn: 2070-1721 nokia...

Internet Engineering Task Force (IETF) R. RavindranathRequest for Comments: 8068 Cisco Systems, Inc.Category: Informational P. RavindranISSN: 2070-1721 Nokia Networks P. Kyzivat Huawei February 2017
Session Initiation Protocol (SIP) Recording Call Flows
Abstract
Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer-protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows with metadata snapshots sent from a Session Recording Client (SRC) to a Session Recording Server (SRS).
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8068.
Ravindranath, et al. Informational [Page 1]

RFC 8068 SIP Recording Call Flows February 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trusts 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 ........................................................3 2. Terminology .....................................................3 3. Metadata XML Instances ..........................................3 3.1. Sample Call Flow ...........................................3 3.2. Call Scenarios with SRC Recording Streams without Mixing ...5 3.2.1. Example 1: Basic Call ...............................5 3.2.2. Example 2: Hold/Resume ..............................9 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER Based) .......................................12 3.2.4. Example 4: Call Disconnect .........................19 3.3. Call Scenarios with SRC Recording Streams by Mixing .......20 3.3.1. Example 1: Basic Call with SRC Mixing Streams ......20 3.3.2. Example 2: Hold/Resume with SRC Recording by Mixing Streams ..................................23 3.3.3. Example 3: Metadata Snapshot of Joining/Dropping of a ..............................25 3.3.4. Example 4: Call Disconnect .........................28 3.4. Call Scenarios with Persistent RS between SRC and SRS .....28 3.4.1. Example 1: Metadata Snapshot during CS Disconnect with ....................................29 3.5. Turret-Case: Multiple CS into Single RS with Mixed Stream ....................................................30 4. Security Considerations ........................................32 5. IANA Considerations ............................................32 6. References .....................................................33 6.1. Normative References ......................................33 6.2. Informative References ....................................33 Acknowledgements ..................................................34 Authors Addresses ................................................34

1. Overview
Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer-protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. [RFC7865] focuses on the recording metadata that describes the Communication Session (CS). This document lists few examples and shows the snapshots of metadata sent from a Session Recording Client (SRC) to Session Recording Server (SRS). For the sake of simplicity, the entire Session Initiation Protocol (SIP) [RFC3261] messages are not shown, instead only snippets of the SIP and Session Description Protocol (SDP) [RFC4566] messages and the XML snapshot of metadata is shown.
2. Terminology
The terms used in this document are defined in [RFC7865] and [RFC6341]. No new definitions are introduced in this document.
3. Metadata XML Instances
The following subsections have examples that contain the metadata snapshot sent from the SRC to the SRS.
3.1. Sample Call Flow
The following is a sample call flow that shows the SRC establishing a Recording Session (RS) towards the SRS. In this example, the SRC could be part of any one of the architectures described in Section 3 of [RFC7245].

Figure 1: Sample Call Flow between SRC and SRS
SRC SRS | | |(1) INVITE (metadata snapshot) F1 | |---------------------------------------------------->| | 200 OK | || |(4) RTP | |====================================================>| |====================================================>| |====================================================>| |====================================================>| |(5) UPDATE/RE-INVITE (metadata update 1) F2 | |---------------------------------------------------->| | 200 OK | || |====================================================>| |(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 | |---------------------------------------------------->| | 200 OK | |

o Special flows like turret flows (used on financial trading floors to manage call activity). A trading turret is a specialized telephony key system that has a highly distributed switching architecture enabling parallel processing of calls. Figure 6 in Section 4 of [RFC6341] has the turret use case.
Note that only those examples where metadata changes are listed in each category. For some of the call flows, the snapshots may be the same (like in case of endpoint or B2BUA acting as SRC) and the same is mentioned in the text preceding the example.
3.2. Call Scenarios with SRC Recording Streams without Mixing
This section describes example flows where SRC can be a SIP-UA or B2BUA as described in Section 3 of [RFC7245]. The SRS here can be a SIP-UA or an entity part of the MEDIACTRL architecture described in Section 3 of [RFC7245].
3.2.1. Example 1: Basic Call
Basic call between two participants, Alice and Bob, who are part of the same CS. In this use case, each participant sends two media streams (audio and video). Media streams sent by each participant are received by the other participant in this use case. In this example, the SRC is a B2BUA in the path between Alice and Bob, as described in Section 3.1.1 of [RFC7245]. Below is the initial snapshot sent by SRC in the INVITE to SRS. This snapshot has the complete metadata. For the sake of simplicity, only snippets of SIP/ SDP are shown. In this example, the SRCs records the streams of each participant to SRS without mixing.

Metadata snapshot for CS setup:
INVITE SRC --------------> SRS
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: C