SIPREC Ram Mohan. Ravindranath Internet-Draft Cisco Systems, Inc. Intended status: Standards Track Parthasarathi. Ravindran Expires: January 14, 2014 Nokia Siemens Networks Paul. Kyzivat Huawei July 13, 2013 Session Initiation Protocol (SIP) Recording Call Flows draft-ietf-siprec-callflows-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 lists call flows that has snapshot of metadata sent from SRC to SRS, the metadata format for which is described in [I-D.ietf-siprec-metadata] . This is purely an informational document that is written to support the model defined in the metadata draft. 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 January 14, 2014. Copyright Notice Copyright (c) 2013 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 Ravindranath, et al. Expires January 14, 2014 [Page 1] Internet-Draft SIP Recording Callflows July 2013 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 schema Instances . . . . . . . . . . . . . . . . 3 3.1. Sample Call flow . . . . . . . . . . . . . . . . . . . . . 3 3.2. Call Scenarios with SRC recording streams with out mixing . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 5 3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . . 7 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 10 3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . . 16 3.3. Call Scenarios with SRC recording streams by mixing . . . 18 3.3.1. Example 1: Basic call with SRC mixing streams . . . . 18 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams . . . . . . . . . . . . . . . . . . . . 20 3.3.3. Example 3: Metadata snapshot of joining/dropping of a participant to a session . . . . . . . . . . . . 23 3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . . 26 3.4. Call scenarios with persistent RS between SRC and SRS . . 26 3.4.1. Example 1: Metadata snapshot during CS disconnect with persistent RS between SRC and SRS . . . . . . . . 26 3.5. Turrent-Case: Multiple CS into single RS with mixed stream . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4. Security Considerations . . . . . . . . . . . . . . . . . . . 29 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 30 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30 7.2. Informative References . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Ravindranath, et al. Expires January 14, 2014 [Page 2] Internet-Draft SIP Recording Callflows July 2013 1. Overview [I-D.ietf-siprec-metadata] document focuses on the Recording metadata which describes the communication session. The document lists a few examples and shows the snapshots of metadata sent from SRC to SRS. For the sake of simplicity the entire SIP [RFC3261] messages are not shown at various points, instead only a snippets of the SIP/SDP messages and the XML snapshot of metadata is shown. 2. Terminology The terms using in this defined are defined in [I-D.ietf-siprec-metadata]. No new terms/definitions are introduced in this document. 3. Metadata XML schema Instances This section describes the metadata model XML instances for different use cases of SIPREC. For the sake of simplicity the complete SIP/SDP snippets are NOT shown here. 3.1. Sample Call flow The following is a sample call flow that shows the SRC establishing a recording session towards the SRS. The SRC in this example could be part of any one of the architectures described in section 3 of [I-D.ietf-siprec-architecture]. Ravindranath, et al. Expires January 14, 2014 [Page 3] Internet-Draft SIP Recording Callflows July 2013 SRC SRS | | |(1) INVITE (metadata snapshot) F1 | |---------------------------------------------------->| | 200 OK | |<----------------------------------------------------| |(3) ACK | |---------------------------------------------------->| |(4) RTP | |====================================================>| |====================================================>| |====================================================>| |====================================================>| |(5) UPDATE/RE-INVITE (metadata update 1) F2 | |---------------------------------------------------->| | 200 OK | |<----------------------------------------------------| | ................................................... | | ................................................... | | | |====================================================>| |====================================================>| |(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 | |---------------------------------------------------->| | 200 OK | |<----------------------------------------------------| For the sake of simplicity, ACKs to RE-INVITES and BYEs are not shown. The subsequent sections describes the snapshot of metadata sent from SRC to SRS for each of the above transactions (F1 ... Fn-1). There may be multiple UPDATES/RE-INVITES mid call to indicates snapshots of different CS changes. Depending on the architecture described in section 3 of [I-D.ietf-siprec-architecture] an SRC may be a endpoint or B2BUA or as part of MEDIACTRL or Conference Focus. The subsequent sections in this document tries to list some example metadata snapshots for three major categories. o SRC recording streams unmixed to SRS. This includes cases where SRC is SIP UA or B2BUA. o SRC recording mixed streams to SRS. This includes cases where SRC is part of SIP conference model explained in [RFC4353] o SRC having a persistent RS with SRS o Special flows like Turrent flows Note that only those examples for which metadata changes are listed in each category. For some of the call flows the snapshots may be Ravindranath, et al. Expires January 14, 2014 [Page 4] Internet-Draft SIP Recording Callflows July 2013 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 with out mixing The section covers the models mentioned in the architecture document in section 3 of [I-D.ietf-siprec-architecture] where an SRC may be a SIP-UA or B2BUA. The SRS here could be a SIP-UA or an entity part of MEDIACTRL architecture described in [RFC6230]. 3.2.1. Example 1: Basic Call Basic call between two Participants Alice and Bob who are part of one CS. In this use case each participant sends two Media Streams. Media Streams sent by each participant are received all other participants in this use-case. Below is the initial snapshot sent by SRC in the INVITE to SRS that has complete metadata. For the sake of simplicity only snippets of SIP/SDP are shown. The SRCs records the streams of each participant to SRS with out mixing in this example. F1 INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49174 RTP/AVPF 96 a=rtpmap:96 H.264/90000 Ravindranath, et al. Expires January 14, 2014 [Page 5] Internet-Draft SIP Recording Callflows July 2013 a=label:97 a=sendonly ... m=audio 51372 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49176 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session complete 2010-12-16T23:41:07Z Alice 2010-12-16T23:41:07Z i1Pz3to5hGk8fuXl+PbwCw== UAAMm5GRQKSCMVvLyl4rFw== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== Bob 2010-12-16T23:41:07Z 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== UAAMm5GRQKSCMVvLyl4rFw== i1Pz3to5hGk8fuXl+PbwCw== 3.2.2. Example 2: Hold/resume Assume a call between two Participants Alice and Bob is established and a RS is created for recording as in example1. This is the continuation of above use-case. One of the participants Bob puts Alice hold and then resumes as part of the same session. The send and recv XML elements of a participant is used to indicate whether a participant is sending not sending a particular media stream whose properties are represented by stream element. The metadata snapshot looks as below During hold F2 mid call RE-INVITE SRC-------------------->SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Ravindranath, et al. Expires January 14, 2014 [Page 7] Internet-Draft SIP Recording Callflows July 2013 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49174 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51372 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49176 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== Ravindranath, et al. Expires January 14, 2014 [Page 8] Internet-Draft SIP Recording Callflows July 2013 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== In the above snippet during Alice with participant_id srfBElmCRp2QB23b7Mpk0w== only receives media streams since Alice is put on hold and does not send any media. The same is indicated by the absence of send XML element. Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other hand would be sending media but does not receive any media from Alice and so recv XML element is absent in this instance. During resume The snapshot now has send and recv XML elements for both Alice and Bob indicating that both are receiving and sending media. F3 mid call RE-INVITE SRC-------------------->SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49174 RTP/AVPF 96 Ravindranath, et al. Expires January 14, 2014 [Page 9] Internet-Draft SIP Recording Callflows July 2013 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51372 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49176 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== i1Pz3to5hGk8fuXl+PbwCw== UAAMm5GRQKSCMVvLyl4rFw== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== i1Pz3to5hGk8fuXl+PbwCw== UAAMm5GRQKSCMVvLyl4rFw== 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) Basic call between two Participants Alice and Bob is connected and SRC has sent a snapshot as in example 1. Transfer is initiated by one of the participants(Alice). After the transfer is completed, SRC sends a snapshot of the participant changes to SRS. In this transfer scenario, Alice drops out after transfer is completed and Bob and Carol gets connected and recording of media between Bob and Carol is done by SRC. There may be two cases here as described below. Ravindranath, et al. Expires January 14, 2014 [Page 10] Internet-Draft SIP Recording Callflows July 2013 Transfer with in the same session - (.e.g. RE-INVITE based transfer). Participant Alice drops out and Carol is added to the same session. No change to session/group element. A participantsessassoc element indicating that Alice has disassociated from the CS will be present in the snapshot. A new participant XML element representing Carol with mapping to the same RS SDP stream used for mapping earlier Alice's stream is sent in the snapshot. mid call RE-INVITE SRC-------------------->SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49180 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49182 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51374 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49178 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 Ravindranath, et al. Expires January 14, 2014 [Page 11] Internet-Draft SIP Recording Callflows July 2013 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial 2013-12-16T23:41:07Z 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 60JAJm9UTvik0Ltlih/Gzw== AcR5FUd3Edi8cACQJy/3JQ== Carol 2013-12-16T23:41:07Z 60JAJm9UTvik0Ltlih/Gzw== AcR5FUd3Edi8cACQJy/3JQ== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 2013-12-16T23:42:07Z Transfer with new session - (.e.g. REFER based transfer). In this case a new session (CS) is created and shall be part of same CS-group (done by SRC). SRC first sends an optional snapshot indicating disassociation of Ravindranath, et al. Expires January 14, 2014 [Page 12] Internet-Draft SIP Recording Callflows July 2013 participant from the old CS. Please note this is a optional message. An SRC may choose to just send a INVITE with a new session element to implicitly indicate that the participants are now part of a different CS with out sending disassociation from the old CS. Also note that the SRC in this example uses the same RS. In case it decides to use a new RS, it will tear down the current RS using normal SIP procedures (BYE) with metadata as in example 4. mid call RE-INVITE SRC-------------------->SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49180 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49182 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51374 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49178 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 Ravindranath, et al. Expires January 14, 2014 [Page 13] Internet-Draft SIP Recording Callflows July 2013 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session Partial 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z Note in the above snapshot the participantsessionassoc element is optional as indicating session XML element with a stop-time implicitly means that all the participants associated with that session have been disassociated. SRC sends another snapshot to indicate the participant change (due to REFER) and new session information after transfer. In this example it is assumed SRC uses the same. mid call RE-INVITE SRC-------------------->SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Ravindranath, et al. Expires January 14, 2014 [Page 14] Internet-Draft SIP Recording Callflows July 2013 Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49180 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49182 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51374 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49178 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... --foobar Content-Type: application/rs-metadata complete 2010-12-16T23:41:07Z 2010-12-16T23:32:03Z Ravindranath, et al. Expires January 14, 2014 [Page 15] Internet-Draft SIP Recording Callflows July 2013 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 60JAJm9UTvik0Ltlih/Gzw== AcR5FUd3Edi8cACQJy/3JQ== 2010-12-16T23:41:07Z 60JAJm9UTvik0Ltlih/Gzw== AcR5FUd3Edi8cACQJy/3JQ== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 3.2.4. Example 4: Call disconnect This example shows a snapshot of metadata sent by an SRC at CS disconnect where the participants of CS are Alice and Bob Ravindranath, et al. Expires January 14, 2014 [Page 16] Internet-Draft SIP Recording Callflows July 2013 SRC SRS | | |(1) BYE (metadata snapshot) F1 | |---------------------------------------------------->| | 200 OK F2 | |<----------------------------------------------------| F1 BYE SRC -----------> SRS BYE sip:2001@8.3.2.12:5060 SIP/2.0 Via: SIP/2.0/UDP 8.3.2.34:5060;branch=z9hG4bK47c8eb30 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 102 BYE Max-Forwards: 70 Require: siprec Accept: application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/rs-metadata Partial 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z Ravindranath, et al. Expires January 14, 2014 [Page 17] Internet-Draft SIP Recording Callflows July 2013 3.3. Call Scenarios with SRC recording streams by mixing The section covers the models mentioned in the architecture document in section 3 of [I-D.ietf-siprec-architecture] where an SRC may be part of Conference model either as Focus or a participant in Conference. The SRS here could be a SIP UA or an entity part of MEDIACTRL architecture. Note that the disconnect case is not shown since the metadata snapshot will be same as for a non-mixing case. 3.3.1. Example 1: Basic call with SRC mixing streams Basic call between two Participants Alice and Bob who are part of one CS. In this use case each participant sends one Media Streams. Media Streams sent by each participant is received by the other participant. Below is the initial snapshot sent by SRC in the INVITE to SRS that has complete metadata. For the sake of simplicity only snippets of SIP/SDP are shown. The SRCs records the streams of each participant to SRS by mixing in this example. The SRC here could be part of conference Focus model described in section 3 of [I-D.ietf-siprec-architecture]. F1 INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly .... --foobar Ravindranath, et al. Expires January 14, 2014 [Page 18] Internet-Draft SIP Recording Callflows July 2013 Content-Type: application/rs-metadata Content-Disposition: recording-session complete 2010-12-16T23:41:07Z Alice 2010-12-16T23:41:07Z i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== Bob 2010-12-16T23:41:07Z i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== Ravindranath, et al. Expires January 14, 2014 [Page 19] Internet-Draft SIP Recording Callflows July 2013 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams Assume a call between two Participants Alice and Bob is established and a RS is created for recording as in example 5. This is the continuation of above use-case. One of the participants Bob puts Alice hold and then resumes as part of the same session. The send and recv XML elements of a participant is used to indicate whether a participant is sending not sending a particular media stream whose properties are represented by stream element. The metadata snapshot looks as below: During hold Ravindranath, et al. Expires January 14, 2014 [Page 20] Internet-Draft SIP Recording Callflows July 2013 mid call hold RE-INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== During resume a snapshot shown below will be sent from SRC to SRS Ravindranath, et al. Expires January 14, 2014 [Page 21] Internet-Draft SIP Recording Callflows July 2013 mid call resume RE-INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== Ravindranath, et al. Expires January 14, 2014 [Page 22] Internet-Draft SIP Recording Callflows July 2013 3.3.3. Example 3: Metadata snapshot of joining/dropping of a participant to a session In a conference model, participants can join and drop a session any time during the session. The below shows a snapshot sent from SRC to SRC in these case. Note the SRC here can be a focus or a participant in the conference. In case where the SRC is a participant it may learn the information required for metadata by subscribing to conference event package [RFC4575]. Assume Alice and Bob were in the conference and a third participant Carol joins, then SRC sends the below snapshot with the indication of new participant. Ravindranath, et al. Expires January 14, 2014 [Page 23] Internet-Draft SIP Recording Callflows July 2013 mid call resume RE-INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial Carol 2013-12-16T23:41:07Z i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== Ravindranath, et al. Expires January 14, 2014 [Page 24] Internet-Draft SIP Recording Callflows July 2013 Assume Alice drops after some time from the conference. SRC generates a new snapshot showing Alice disassociating from the session mid call resume RE-INVITE SRC --------------> SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly .... --foobar Content-Type: application/rs-metadata Content-Disposition: recording-session partial 2010-12-16T23:41:07Z Ravindranath, et al. Expires January 14, 2014 [Page 25] Internet-Draft SIP Recording Callflows July 2013 3.3.4. Example 4: Call disconnect When a CS is disconnected, SRC sends BYE with a snapshot of metadata having session stop-time and participant dis-associate times. The snapshot looks same as listed in section 3.2.4 3.4. Call scenarios with persistent RS between SRC and SRS The section shows the snapshots of metadata for the cases there a persistent RS exists between SRC and SRS. An SRC here may be SIP UA or a B2BUA or may be part of Conference model either as Focus or a participant in Conference. The SRS here could be a SIP UA or an entity part of MEDIACTRL architecture. Except disconnect case, the snapshot remains same as one of the examples mentioned in previous sections. 3.4.1. Example 1: Metadata snapshot during CS disconnect with persistent RS between SRC and SRS Ravindranath, et al. Expires January 14, 2014 [Page 26] Internet-Draft SIP Recording Callflows July 2013 RE-INVITE sent from SRC -----------> SRS INVITE sip:2001@8.3.2.12:5060 SIP/2.0 Via: SIP/2.0/UDP 8.3.2.34:5060;branch=z9hG4bK47c8eb30 From: ;tag=35e195d2-947d-4585-946f-09839247 To: Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/rs-metadata, application/rs-metadata-request Contact: ;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/rs-metadata Partial 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z 2010-12-16T23:41:07Z 3.5. Turrent-Case: Multiple CS into single RS with mixed stream In trading turret, audio mixing is done locally before forwarding to the recording server. Sender and receiver audio is mixed for each communication session. The audio from multiple communication sessions is also mixed, or multiplexed, in a single RTP session to the recording server. Ravindranath, et al. Expires January 14, 2014 [Page 27] Internet-Draft SIP Recording Callflows July 2013 snapshot of metadata INVITE SRC --------------> SRS Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... complete 2010-12-16T23:41:07Z 7+OTCyoxTmqmqyA/1weDAg== 2010-12-16T23:41:07Z 7+OTCyoxTmqmqyA/1weDAg== 2010-12-16T23:43:07Z RamMohan R 2010-12-16T23:41:07Z UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== Parthasarathi R Ravindranath, et al. Expires January 14, 2014 [Page 28] Internet-Draft SIP Recording Callflows July 2013 2010-12-16T23:41:07Z 2010-12-16T23:43:07Z UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== Paul 2010-12-16T23:43:07Z UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== 4. Security Considerations There is no security consideration as it is informatioal callflow document. 5. IANA Considerations This document has no IANA considerations Ravindranath, et al. Expires January 14, 2014 [Page 29] Internet-Draft SIP Recording Callflows July 2013 6. Acknowledgement Thanks to Ofir Rath, Charles Eckel for their review comments. 7. References 7.1. Normative References [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. 7.2. Informative References [I-D.ietf-siprec-metadata] R, R., Ravindran, P., and P. Kyzivat, "Session Initiation Protocol (SIP) Recording Metadata", draft-ietf-siprec-metadata-12 (work in progress), May 2013. [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-08 (work in progress), May 2013. [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media Control Channel Framework", RFC 6230, May 2011. Ravindranath, et al. Expires January 14, 2014 [Page 30] Internet-Draft SIP Recording Callflows July 2013 Authors' Addresses Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Email: rmohanr@cisco.com Parthasarathi Ravindran Nokia Siemens Networks Manyata Embassy business Park Bangalore, Karnataka 560045 India Email: partha@parthasarathi.co.in Paul Kyzivat Huawei Hudson, MA USA Email: pkyzivat@alum.mit.edu Ravindranath, et al. Expires January 14, 2014 [Page 31]