diff options
Diffstat (limited to 'doc/rfc/rfc8068.txt')
| -rw-r--r-- | doc/rfc/rfc8068.txt | 1907 |
1 files changed, 1907 insertions, 0 deletions
diff --git a/doc/rfc/rfc8068.txt b/doc/rfc/rfc8068.txt new file mode 100644 index 0000000..7fed496 --- /dev/null +++ b/doc/rfc/rfc8068.txt @@ -0,0 +1,1907 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Ravindranath +Request for Comments: 8068 Cisco Systems, Inc. +Category: Informational P. Ravindran +ISSN: 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 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 + 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 + + + + + +Ravindranath, et al. Informational [Page 2] + +RFC 8068 SIP Recording Call Flows February 2017 + + +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]. + + + + + + + + + + + + + + + + + + + +Ravindranath, et al. Informational [Page 3] + +RFC 8068 SIP Recording Call Flows February 2017 + + + Figure 1: Sample Call Flow between SRC and SRS + + 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 describe the snapshot of metadata + sent from the SRC to the SRS for each of the above transactions (F1 + ... Fn-1). There may be multiple UPDATES/RE-INVITES mid call to + indicate snapshots of different CS changes. Depending on the + architecture described in Section 3 of [RFC7245], an SRC may be an + endpoint, a B2BUA, or part of the MEDIACTRL architecture or the + Conference focus. The subsequent sections in this document try to + list some example metadata snapshots for three major categories. + + o The SRC recording streams unmixed to the SRS. This includes cases + where the SRC is a SIP UA or B2BUA. + + o The SRC recording mixed streams to the SRS. This includes cases + where the SRC is part of SIP conference model, as explained in + [RFC4353]. + + o The SRC having a persistent RS with the SRS. + + + + +Ravindranath, et al. Informational [Page 4] + +RFC 8068 SIP Recording Call Flows February 2017 + + + 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. + + + + + + + + + + + + + + + + + + + + + +Ravindranath, et al. Informational [Page 5] + +RFC 8068 SIP Recording Call Flows February 2017 + + + Metadata snapshot for CS setup: + + INVITE SRC --------------> SRS + + INVITE sip:recorder@example.com SIP/2.0 + Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: ab30317f1a784dc48ff824d0d3715d86 + ;remote=00000000000000000000000000000000 + CSeq: 101 INVITE + Max-Forwards: 70 + Require: siprec + Accept: application/sdp, application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+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 + + + + + +Ravindranath, et al. Informational [Page 6] + +RFC 8068 SIP Recording Call Flows February 2017 + + +<?xml version="1.0" encoding="UTF-8"?> +<recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>complete</datamode> + <group group_id="7+OTCyoxTmqmqyA/1weDAg=="> + <associate-time>2010-12-16T23:41:07Z</associate-time> + <!-- Standardized extension --> + <call-center xmlns='urn:ietf:params:xml:ns:callcenter'> + <supervisor>sip:alice@atlanta.com</supervisor> + </call-center> + <mydata xmlns='http://example.com/my'> + <structure>FOO!</structure> + <whatever>bar</whatever> + </mydata> + </group> + <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <sipSessionID>ab30317f1a784dc48ff824d0d3715d86; + remote=47755a9de7794ba387653f2099600ef2</sipSessionID> + <group-ref>7+OTCyoxTmqmqyA/1weDAg== + </group-ref> + <!-- Standardized extension --> + <mydata xmlns='http://example.com/my'> + <structure>FOO!</structure> + <whatever>bar</whatever> + </mydata> + </session> + <participant + participant_id="srfBElmCRp2QB23b7Mpk0w=="> + <nameID aor="sip:alice@atlanta.com"> + <name xml:lang="it">Alice</name> + </nameID> + <!-- Standardized extension --> + <mydata xmlns='http://example.com/my'> + <structure>FOO!</structure> + <whatever>bar</whatever> + </mydata> + </participant> + <participant + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <nameID aor="sip:bob@biloxy.com"> + <name xml:lang="it">Bob</name> + </nameID> + <!-- Standardized extension --> + <mydata xmlns='http://example.com/my'> + <structure>FOO!</structure> + <whatever>bar</whatever> + </mydata> + </participant> + + + + +Ravindranath, et al. Informational [Page 7] + +RFC 8068 SIP Recording Call Flows February 2017 + + + <stream stream_id="UAAMm5GRQKSCMVvLyl4rFw==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <label>96</label> + </stream> + <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <label>97</label> + </stream> + <stream stream_id="8zc6e0lYTlWIINA6GR+3ag==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <label>98</label> + </stream> + <stream stream_id="EiXGlc+4TruqqoDaNE76ag==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <label>99</label> + </stream> + <sessionrecordingassoc session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <associate-time>2010-12-16T23:41:07Z</associate-time> + </sessionrecordingassoc> + <participantsessionassoc + participant_id="srfBElmCRp2QB23b7Mpk0w==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <associate-time>2010-12-16T23:41:07Z</associate-time> + </participantsessionassoc> + <participantsessionassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <associate-time>2010-12-16T23:41:07Z</associate-time> + </participantsessionassoc> + <participantstreamassoc + participant_id="srfBElmCRp2QB23b7Mpk0w=="> + <send>i1Pz3to5hGk8fuXl+PbwCw==</send> + <send>UAAMm5GRQKSCMVvLyl4rFw==</send> + <recv>8zc6e0lYTlWIINA6GR+3ag==</recv> + <recv>EiXGlc+4TruqqoDaNE76ag==</recv> + </participantstreamassoc> + <participantstreamassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <send>8zc6e0lYTlWIINA6GR+3ag==</send> + <send>EiXGlc+4TruqqoDaNE76ag==</send> + <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> + <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> + </participantstreamassoc> +</recording> + + + + + + + +Ravindranath, et al. Informational [Page 8] + +RFC 8068 SIP Recording Call Flows February 2017 + + +3.2.2. Example 2: Hold/Resume + + A call between two participants Alice and Bob is established and an + RS is created for recording, as in example 1. Bob puts Alice on hold + and then resumes as part of the same CS. The 'send' and 'recv' XML + elements of a 'participantstreamassoc' XML element is used to + indicate whether or not a participant is contributing to a media + stream. SRC sends a snapshot with only the changed XML elements. + + During hold + + Metadata snapshot for CS hold: + + RE-INVITE SRC-------------------->SRS + + INVITE sip:recorder@example.com SIP/2.0 + Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: ab30317f1a784dc48ff824d0d3715d86 + ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 + CSeq: 101 INVITE + Max-Forwards: 70 + Require: siprec + Accept: application/sdp, application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+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 + + + +Ravindranath, et al. Informational [Page 9] + +RFC 8068 SIP Recording Call Flows February 2017 + + + ... + 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 + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>partial</datamode> + <participantstreamassoc + participant_id="srfBElmCRp2QB23b7Mpk0w=="> + <recv>8zc6e0lYTlWIINA6GR+3ag==</recv> + <recv>EiXGlc+4TruqqoDaNE76ag==</recv> + </participantstreamassoc> + <participantstreamassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <send>8zc6e0lYTlWIINA6GR+3ag==</send> + <send>EiXGlc+4TruqqoDaNE76ag==</send> + </participantstreamassoc> + </recording> + + In the above snippet, Alice with participant_id + srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not + send any media. The same is indicated by the absence of a 'send' XML + element. On the other hand, Bob (participant_id + zSfPoSvdSDCmU3A3TRDxAw==) would be sending media, but he does not + receive any media from Alice; therefore, the '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. + + + + + + + + + + + + + +Ravindranath, et al. Informational [Page 10] + +RFC 8068 SIP Recording Call Flows February 2017 + + + Metadata snapshot for CS resume: + + RE-INVITE SRC-------------------->SRS + + INVITE sip:recorder@example.com SIP/2.0 + Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: ab30317f1a784dc48ff824d0d3715d86 + ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 + CSeq: 101 INVITE + Max-Forwards: 70 + Require: siprec + Accept: application/sdp, application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+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 + + + + + +Ravindranath, et al. Informational [Page 11] + +RFC 8068 SIP Recording Call Flows February 2017 + + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>partial</datamode> + <participantstreamassoc + participant_id="srfBElmCRp2QB23b7Mpk0w=="> + <send>i1Pz3to5hGk8fuXl+PbwCw==</send> + <send>UAAMm5GRQKSCMVvLyl4rFw==</send> + <recv>8zc6e0lYTlWIINA6GR+3ag==</recv> + <recv>EiXGlc+4TruqqoDaNE76ag==</recv> + </participantstreamassoc> + <participantstreamassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <send>8zc6e0lYTlWIINA6GR+3ag==</send> + <send>EiXGlc+4TruqqoDaNE76ag==</send> + <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> + <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> + </participantstreamassoc> + </recording> + +3.2.3. Example 3:Call Transfer (RE-INVITE and REFER Based) + + A basic call between two participants, Alice and Bob, is connected, + and SRC (a B2BUA acting as SRC as per Section 3.1.1 of [RFC7245]) has + sent a snapshot as described in example 1. Transfer is initiated by + one of the participants (Alice). After the transfer is completed, + the SRC sends a snapshot of the participant changes to the SRS. In + this transfer scenario, Alice drops out after transfer is completed, + Bob and Carol get connected, and recording of media between Bob and + Carol is done by the SRC. There are two flows that can happen here + as described below. + + Transfer within the same session (e.g., a RE-INVITE-based transfer): + Alice drops out and Carol is added to the same session. No change to + the session/group element is made. A 'participantsessassoc' XML + 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. A new + 'sipSessionID' XML element that has Universally Unique Identifier + (UUID) tuples and that corresponds to Bob and Carol is sent in the + snapshot from the SRC to the SRS. Note that one half of the session + ID, that which corresponds to Bob, remains the same. + + + + + + + + + +Ravindranath, et al. Informational [Page 12] + +RFC 8068 SIP Recording Call Flows February 2017 + + + Metadata snapshot for INVITE based transfer in CS: + + RE-INVITE SRC-------------------->SRS + + INVITE sip:recorder@example.com SIP/2.0 + Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: ab30317f1a784dc48ff824d0d3715d86 + ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 + CSeq: 101 INVITE + Max-Forwards: 70 + Require: siprec + Accept: application/sdp, application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+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 + Content-Disposition: recording-session + + + + + +Ravindranath, et al. Informational [Page 13] + +RFC 8068 SIP Recording Call Flows February 2017 + + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>partial</datamode> + <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <sipSessionID>3363127f0d084c10876dddd4f8e5eeb9 + ;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID> + </session> + <participant + participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> + <nameID aor="sip:carol@example.com"> + <name xml:lang="it">Carol</name> + </nameID> + </participant> + <participantsessionassoc + participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <associate-time>2013-12-16T23:41:07Z</associate-time> + </participantsessionassoc> + <participantsessionassoc + participant_id="srfBElmCRp2QB23b7Mpk0w==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <disassociate-time>2013-12-16T23:41:07Z</disassociate-time> + </participantsessionassoc> + <participantstreamassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <send>8zc6e0lYTlWIINA6GR+3ag==</send> + <send>EiXGlc+4TruqqoDaNE76ag==</send> + <recv>60JAJm9UTvik0Ltlih/Gzw==</recv> + <recv>AcR5FUd3Edi8cACQJy/3JQ==</recv> + </participantstreamassoc> + <participantstreamassoc + participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> + <send>60JAJm9UTvik0Ltlih/Gzw==</send> + <send>AcR5FUd3Edi8cACQJy/3JQ==</send> + <recv>8zc6e0lYTlWIINA6GR+3ag==</recv> + <recv>EiXGlc+4TruqqoDaNE76ag==</recv> + <associate-time>2013-12-16T23:42:07Z</associate-time> + </participantstreamassoc> + </recording> + + + + + + + + + + + + +Ravindranath, et al. Informational [Page 14] + +RFC 8068 SIP Recording Call Flows February 2017 + + + Transfer with a 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 the SRC). + + The SRC first sends an *optional* snapshot indicating disassociation + of the participant from the old CS. An SRC may choose to just send + an INVITE with a new 'session' XML element to implicitly indicate + that the participants are now part of a different CS without sending + disassociation from the old CS. In this example, the SRC uses the + same RS. In case the SRC wishes to use a new RS, it will tear down + the current RS using normal SIP procedures (BYE) with metadata, as in + example 4. + + Metadata snapshot for REFER based transfer in CS: + + RE-INVITE SRC-------------------->SRS + + INVITE sip:recorder@example.com SIP/2.0 + Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: ab30317f1a784dc48ff824d0d3715d86 + ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 + CSeq: 101 INVITE + Max-Forwards: 70 + Require: siprec + Accept: application/sdp, application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+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 + + + + + + +Ravindranath, et al. Informational [Page 15] + +RFC 8068 SIP Recording Call Flows February 2017 + + + ... + 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 + Content-Disposition: recording-session + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>partial</datamode> + <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <stop-time>2010-12-16T23:41:07Z</stop-time> + </session> + <participantsessionassoc + participant_id="srfBElmCRp2QB23b7Mpk0w==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <disassociate-time>2010-12-16T23:41:07Z</disassociate-time> + </participantsessionassoc> + <participantsessionassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <disassociate-time>2010-12-16T23:41:07Z</disassociate-time> + </participantsessionassoc> + </recording> + + In the above snapshot, the 'participantsessionassoc' XML element is + optional as indicating a 'session' XML element with a 'stop-time' XML + element implicitly means that all the participants associated with + that session have been disassociated. + + The SRC sends another snapshot to indicate the participant change + (due to REFER) and new session information after transfer. In this + example, it is assumed that the SRC uses the same RS to continue + recording the call. The 'sipSessionID' XML element in the metadata + snapshot now indicates Bob and Carol in the (local, remote) UUID + pair. + + + + + + +Ravindranath, et al. Informational [Page 16] + +RFC 8068 SIP Recording Call Flows February 2017 + + + Metadata snapshot for REFER based transfer in CS: + + RE-INVITE SRC-------------------->SRS + + INVITE sip:recorder@example.com SIP/2.0 + Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: ab30317f1a784dc48ff824d0d3715d86 + ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 + CSeq: 101 INVITE + Max-Forwards: 70 + Require: siprec + Accept: application/sdp, application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+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 + + + + + +Ravindranath, et al. Informational [Page 17] + +RFC 8068 SIP Recording Call Flows February 2017 + + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>complete</datamode> + <session session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> + <sipSessionID>3363127f0d084c10876dddd4f8e5eeb9 + ;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID> + <start-time>2010-12-16T23:41:07Z</start-time> + </session> + <participant + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <nameID aor="sip:Bob@biloxy.com"/> + </participant> + <participant + participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> + <nameID aor="sip:carol@example.com"/> + </participant> + <stream stream_id="60JAJm9UTvik0Ltlih/Gzw==" + session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> + <label>96</label> + </stream> + <stream stream_id="AcR5FUd3Edi8cACQJy/3JQ==" + session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> + <label>97</label> + </stream> + <stream stream_id="8zc6e0lYTlWIINA6GR+3ag==" + session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> + <label>98</label> + </stream> + <stream stream_id="EiXGlc+4TruqqoDaNE76ag==" + session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> + <label>99</label> + </stream> + <participantsessionassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw==" + session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> + <associate-time>2010-12-16T23:32:03Z</associate-time> + </participantsessionassoc> + <participantsessionassoc + participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==" + session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> + <associate-time>2010-12-16T23:41:07Z</associate-time> + </participantsessionassoc> + <participantstreamassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <send>8zc6e0lYTlWIINA6GR+3ag==</send> + <send>EiXGlc+4TruqqoDaNE76ag==</send> + <recv>60JAJm9UTvik0Ltlih/Gzw==</recv> + <recv>AcR5FUd3Edi8cACQJy/3JQ==</recv> + + + +Ravindranath, et al. Informational [Page 18] + +RFC 8068 SIP Recording Call Flows February 2017 + + + </participantstreamassoc> + <participantstreamassoc + participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> + <send>60JAJm9UTvik0Ltlih/Gzw==</send> + <send>AcR5FUd3Edi8cACQJy/3JQ==</send> + <recv>8zc6e0lYTlWIINA6GR+3ag==</recv> + <recv>EiXGlc+4TruqqoDaNE76ag==</recv> + </participantstreamassoc> + </recording> + +3.2.4. Example 4: Call Disconnect + + This example shows a snapshot of metadata sent by the SRC to the SRS + when a CS with Alice and Bob as participants is disconnected. + + SRC SRS + | | + |(1) BYE (metadata snapshot) F1 | + |---------------------------------------------------->| + | 200 OK F2 | + |<----------------------------------------------------| + + Metadata snapshot for a CS disconnect: + + F1 BYE SRC -----------> SRS + + BYE sip:2001@example.com SIP/2.0 + Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: ab30317f1a784dc48ff824d0d3715d86 + ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 + CSeq: 102 BYE + Max-Forwards: 70 + Require: siprec + Accept: application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+sip.src + Content-Type: multipart/mixed;boundary=foobar + Content-Length: [length] + + --foobar + Content-Type: application/rs-metadata + + + + + + + +Ravindranath, et al. Informational [Page 19] + +RFC 8068 SIP Recording Call Flows February 2017 + + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>partial</datamode> + <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <stop-time>2010-12-16T23:41:07Z</stop-time> + </session> + <participantsessionassoc + participant_id="srfBElmCRp2QB23b7Mpk0w==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <disassociate-time>2010-12-16T23:41:07Z</disassociate-time> + </participantsessionassoc> + + <participantsessionassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <disassociate-time>2010-12-16T23:41:07Z</disassociate-time> + </participantsessionassoc> + </recording> + +3.3. Call Scenarios with SRC Recording Streams by Mixing + + This section describes a few example call flows where the SRC may be + part of conference model either as focus or a participant in + conference as explained in Section 3.1.5 of [RFC7245]. The SRS here + can be a SIP User Agent (UA) or an entity part of the 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 + + A basic call between two participants, Alice and Bob, who are part of + one CS. In this use case, each participant calls into a conference + server (say, a Multipoint Control Unit (MCU)) to attend one of many + conferences hosted on or managed by that server. Media streams sent + by each participant are received by all the other participants in the + conference. Below is the initial snapshot sent by the SRC in the + INVITE to the SRS that has the complete metadata. For the sake of + simplicity, only snippets of SIP/SDP are shown. The SRC records the + streams of each participant to SRS by mixing in this example. The + SRC here is part of conference model described in Section 3 of + [RFC7245] as a focus and does mixing. The SRC here is not a + participant by itself and hence it does not contribute to media. + + + + + + + + + +Ravindranath, et al. Informational [Page 20] + +RFC 8068 SIP Recording Call Flows February 2017 + + + Metadata snapshot with the SRC mixing streams to the SRS: + + F1 INVITE SRC --------------> SRS + + INVITE sip:recorder@example.com SIP/2.0 + Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: a358d2b81a444a8c8fb05950cef331e7 + ;remote=00000000000000000000000000000000 + CSeq: 101 INVITE + Max-Forwards: 70 + Require: siprec + Accept: application/sdp, application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+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 + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>complete</datamode> + <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <sipSessionID>fa3b60f27e91441e84c55a9a0095f075 + ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID> + <sipSessionID>ca718e1430474b5485a53aa5d0bea45e + ;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID> + <start-time>2010-12-16T23:41:07Z</start-time> + </session> + <participant + participant_id="srfBElmCRp2QB23b7Mpk0w=="> + <nameID aor="sip:alice@atlanta.com"> + <name xml:lang="it">Alice</name> + </nameID> + + + +Ravindranath, et al. Informational [Page 21] + +RFC 8068 SIP Recording Call Flows February 2017 + + + </participant> + <participant + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <nameID aor="sip:bob@biloxy.com"> + <name xml:lang="it">Bob</name> + </nameID> + </participant> + <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <label>96</label> + </stream> + <participantsessionassoc + participant_id="srfBElmCRp2QB23b7Mpk0w==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <associate-time>2010-12-16T23:41:07Z</associate-time> + </participantsessionassoc> + <participantsessionassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <associate-time>2010-12-16T23:41:07Z</associate-time> + </participantsessionassoc> + <participantstreamassoc + participant_id="srfBElmCRp2QB23b7Mpk0w=="> + <send>i1Pz3to5hGk8fuXl+PbwCw==</send> + <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> + </participantstreamassoc> + + <participantstreamassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <send>i1Pz3to5hGk8fuXl+PbwCw==</send> + <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> + </participantstreamassoc> + </recording> + + In the above example, there are two participants, Alice and Bob, in + the conference. Among other things, the SRC sends Session-ID in the + metadata snapshot. There are two Session-IDs here: one that + corresponds to the SIP session between Alice and the Conference focus + and the other for the SIP session between Bob and the Conference + focus. In this use case, since Alice and Bob call into the + conference, these Session-IDs are different. + + + + + + + + + + +Ravindranath, et al. Informational [Page 22] + +RFC 8068 SIP Recording Call Flows February 2017 + + +3.3.2. Example 2: Hold/Resume with SRC Recording by Mixing Streams + + This is the continuation of example 1 (basic call with SRC mixing + streams). A call between two participants, Alice and Bob, is + established and an RS is created for recording, as in example 5. One + of the participants, Bob, puts Alice on hold, and then resumes as + part of the same CS. The 'send' and 'recv' XML elements of a + 'participant' XML element are used to indicate whether or not a + participant is contributing to a media stream. The metadata snapshot + is represented below: + + During hold + + Metadata snapshot when a CS participant goes on hold + and the SRC is mixing the streams: + + RE-INVITE SRC --------------> SRS + + INVITE sip:recorder@example.com SIP/2.0 + Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: a358d2b81a444a8c8fb05950cef331e7 + ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 + CSeq: 101 INVITE + Max-Forwards: 70 + Require: siprec + Accept: application/sdp, application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+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 + + + + + +Ravindranath, et al. Informational [Page 23] + +RFC 8068 SIP Recording Call Flows February 2017 + + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>partial</datamode> + <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <label>96</label> + </stream> + <participantstreamassoc + participant_id="srfBElmCRp2QB23b7Mpk0w=="> + <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> + </participantstreamassoc> + <participantstreamassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <send>i1Pz3to5hGk8fuXl+PbwCw==</send> + </participantstreamassoc> + </recording> + + During resumption, a snapshot shown below will be sent from the SRC + to the SRS. + + Metadata snapshot when a CS participant resumes and + the SRC is mixing the streams: + + RE-INVITE SRC --------------> SRS + + INVITE sip:recorder@example.com SIP/2.0 + Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: a358d2b81a444a8c8fb05950cef331e7 + ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 + CSeq: 101 INVITE + Max-Forwards: 70 + Require: siprec + Accept: application/sdp, application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+sip.src + Content-Type: multipart/mixed;boundary=foobar + Content-Length: [length] + + + + + + + + + + + +Ravindranath, et al. Informational [Page 24] + +RFC 8068 SIP Recording Call Flows February 2017 + + + --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 + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>partial</datamode> + <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <label>96</label> + </stream> + <participantstreamassoc + participant_id="srfBElmCRp2QB23b7Mpk0w=="> + <send>i1Pz3to5hGk8fuXl+PbwCw==</send> + <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> + </participantstreamassoc> + <participantstreamassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <send>i1Pz3to5hGk8fuXl+PbwCw==</send> + <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> + </participantstreamassoc> + </recording> + +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. Below is a snapshot sent from the SRC to + the SRS in this case. Note the SRC here can be a focus or a + participant in the conference. In the case where the SRC is a + participant, it may learn the information required for metadata by + subscribing to a conference event package [RFC4575]. Assume Alice + and Bob were in the conference and a third participant (Carol) joins, + then the SRC sends the below snapshot with the indication of new + participant. + + + + + + + +Ravindranath, et al. Informational [Page 25] + +RFC 8068 SIP Recording Call Flows February 2017 + + + Metadata snapshot for a new participant joining CS: + + RE-INVITE SRC --------------> SRS + + INVITE sip:recorder@example.com SIP/2.0 + Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: a358d2b81a444a8c8fb05950cef331e7 + ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 + CSeq: 101 INVITE + Max-Forwards: 70 + Require: siprec + Accept: application/sdp, application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+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 + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>partial</datamode> + <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <sipSessionID>fa3b60f27e91441e84c55a9a0095f075 + ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID> + <sipSessionID>ca718e1430474b5485a53aa5d0bea45e + ;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID> + <sipSessionID>497c0f13929643b4a16858e2a3885edc + ;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID> + </session> + <participant + participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> + <nameID aor="sip:carol@example.com"> + <name xml:lang="it">Carol</name> + + + +Ravindranath, et al. Informational [Page 26] + +RFC 8068 SIP Recording Call Flows February 2017 + + + </nameID> + </participant> + <participantsessionassoc + participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <associate-time>2013-12-16T23:41:07Z</associate-time> + </participantsessionassoc> + <participantstreamassoc + participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> + <send>i1Pz3to5hGk8fuXl+PbwCw==</send> + <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> + </participantstreamassoc> + </recording> + + After some time, Alice drops from the conference. The SRC generates + a new snapshot showing Alice disassociating from the session. + + Metadata snapshot for a participant dropping from CS: + + RE-INVITE SRC --------------> SRS + + INVITE sip:recorder@example.com SIP/2.0 + Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: a358d2b81a444a8c8fb05950cef331e7 + ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 + CSeq: 101 INVITE + Max-Forwards: 70 + Require: siprec + Accept: application/sdp, application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+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 + + + + + + + +Ravindranath, et al. Informational [Page 27] + +RFC 8068 SIP Recording Call Flows February 2017 + + + .... + --foobar + Content-Type: application/rs-metadata + Content-Disposition: recording-session + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>partial</datamode> + <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <sipSessionID>ca718e1430474b5485a53aa5d0bea45e + ;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID> + <sipSessionID>497c0f13929643b4a16858e2a3885edc + ;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID> + </session> + <participantsessionassoc + participant_id="srfBElmCRp2QB23b7Mpk0w==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <disassociate-time>2010-12-16T23:41:07Z</disassociate-time> + </participantsessionassoc> + </recording> + + +3.3.4. Example 4: Call Disconnect + + When a CS is disconnected, the SRC sends a BYE with a snapshot of + metadata having a session stop time and participant disassociation + times. The snapshot looks the same as listed in Section 3.2.4. + +3.4. Call Scenarios with Persistent RS between SRC and SRS + + This section shows the snapshots of metadata for the cases where a + persistent RS exists between the SRC and the SRS. An SRC here may be + a SIP UA or a B2BUA, or it may be part of a conference model as + either the focus or a participant in a conference. The SRS here + could be a SIP UA or an entity part of the MEDIACTRL architecture. + Except in the disconnect case, the snapshot remains same as mentioned + in previous sections. + + + + + + + + + + + + + + +Ravindranath, et al. Informational [Page 28] + +RFC 8068 SIP Recording Call Flows February 2017 + + +3.4.1. Example 1: Metadata Snapshot during CS Disconnect with + Persistent RS between SRC and SRS + + Metadata snapshot for a CS disconnect with a persistent RS: + + RE-INVITE sent from SRC -----------> SRS + + INVITE sip:2001@example.com SIP/2.0 + Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: ab30317f1a784dc48ff824d0d3715d86 + ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 + CSeq: 101 INVITE + Max-Forwards: 70 + Require: siprec + Accept: application/rs-metadata, + application/rs-metadata-request + Contact: <sip:2000@src.example.com>;+sip.src + Content-Type: multipart/mixed;boundary=foobar + Content-Length: [length] + + --foobar + Content-Type: application/rs-metadata + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>partial</datamode> + <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <stop-time>2010-12-16T23:41:07Z</stop-time> + </session> + <participantsessionassoc + participant_id="srfBElmCRp2QB23b7Mpk0w==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <disassociate-time>2010-12-16T23:41:07Z</disassociate-time> + </participantsessionassoc> + + <participantsessionassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <disassociate-time>2010-12-16T23:41:07Z</disassociate-time> + </participantsessionassoc> + </recording> + + + + + + + +Ravindranath, et al. Informational [Page 29] + +RFC 8068 SIP Recording Call Flows February 2017 + + +3.5. Turret-Case: Multiple CS into Single RS with Mixed Stream + + In trading-floor environments, in order to minimize storage and + recording system resources, it may be preferable to mix multiple + concurrent calls (each call is one CS) on different handsets/speakers + on the same turret into a single RS. This would mean media in each + CS is mixed and recorded as part of single media stream, and multiple + such CSs are recording in one RS from an SRC to an SRS. + + Taking an example where there are two CSs [CS1 and CS2]: assume + mixing is done in each of these CSs and both these CSs are recorded + as part of single RS from a single SRC, which is part of both the + CSs. There are three possibilities here: + + o CS1 and CS2 use the same focus for mixing, and that focus is also + acting as SRC in each of the CSs. + + o One CS (e.g. CS1) SRC is the focus and the other CS (e.g. CS2), + SRC is just one of the participants of the conference. + + o In both CS1 and CS2, the SRC is just a participant of conference. + + The following example shows the first possibility where CS1 and CS2 + use the same focus for mixing, and that focus is also acting as SRC + in each of the CSs. + + Metadata snapshot with two CSs recorded as part of the same RS: + + INVITE SRC --------------> SRS + + INVITE sip:recorder@example.com SIP/2.0 + Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 + From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 + To: <sip:recorder@example.com> + Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a + Session-ID: a358d2b81a444a8c8fb05950cef331e7 + ;remote=00000000000000000000000000000000 + Content-Type: application/SDP + ... + m=audio 49170 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + a=label:96 + a=sendonly + ... + + + + + + + +Ravindranath, et al. Informational [Page 30] + +RFC 8068 SIP Recording Call Flows February 2017 + + + <?xml version="1.0" encoding="UTF-8"?> + <recording xmlns='urn:ietf:params:xml:ns:recording:1'> + <datamode>complete</datamode> + <group group_id="7+OTCyoxTmqmqyA/1weDAg=="> + <associate-time>2010-12-16T23:41:07Z</associate-time> + </group> + <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <sipSessionID>fa3b60f27e91441e84c55a9a0095f075 + ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID> + <sipSessionID>ca718e1430474b5485a53aa5d0bea45e + ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID> + <sipSessionID>497c0f13929643b4a16858e2a3885edc + ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID> + <group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref> + <start-time>2010-12-16T23:41:07Z</start-time> + </session> + <session session_id="e6370VVGEeWAG6886p18uA=="> + <sipSessionID>ae10731ca50343a5aaae2dd0904a65de + ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID> + <sipSessionID>33c77aac7deb414cbc8c10f363fccb71 + ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID> + <sipSessionID>fd6932e9e5fc489fae2d5b3779723b7e + ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID> + <group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref> + <start-time>2010-12-16T23:43:07Z</start-time> + </session> + <participant + participant_id="srfBElmCRp2QB23b7Mpk0w=="> + <nameID aor="sip:alice@atlanta.com"> + <name xml:lang="it">Alice</name> + </nameID> + </participant> + <participant + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <nameID aor="sip:Bob@biloxy.com"> + <name xml:lang="it">Bob</name> + </nameID> + </participant> + <participant + participant_id="EiXGlc+4TruqqoDaNE76ag=="> + <nameID aor="sip:Carol@example.com"> + <name xml:lang="it">Carol</name> + </nameID> + </participant> + <stream stream_id="UAAMm5GRQKSCMVvLyl4rFw==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <label>96</label> + </stream> + + + +Ravindranath, et al. Informational [Page 31] + +RFC 8068 SIP Recording Call Flows February 2017 + + + <participantsessionassoc + participant_id="srfBElmCRp2QB23b7Mpk0w==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <associate-time>2010-12-16T23:41:07Z</associate-time> + </participantsessionassoc> + <participantsessionassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw==" + session_id="hVpd7YQgRW2nD22h7q60JQ=="> + <associate-time>2010-12-16T23:41:07Z</associate-time> + </participantsessionassoc> + <participantsessionassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw==" + session_id="e6370VVGEeWAG6886p18uA=="> + <associate-time>2010-12-16T23:43:07Z</associate-time> + </participantsessionassoc> + <participantsessionassoc + participant_id="EiXGlc+4TruqqoDaNE76ag==" + session_id="e6370VVGEeWAG6886p18uA=="> + <associate-time>2010-12-16T23:43:07Z</associate-time> + </participantsessionassoc> + + <participantstreamassoc + participant_id="srfBElmCRp2QB23b7Mpk0w=="> + <send>UAAMm5GRQKSCMVvLyl4rFw==</send> + <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> + </participantstreamassoc> + <participantstreamassoc + participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> + <send>UAAMm5GRQKSCMVvLyl4rFw==</send> + <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> + </participantstreamassoc> + <participantstreamassoc + participant_id="EiXGlc+4TruqqoDaNE76ag=="> + <send>UAAMm5GRQKSCMVvLyl4rFw==</send> + <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> + </participantstreamassoc> + </recording> + +4. Security Considerations + + Security and privacy considerations mentioned in [RFC7865] and + [RFC7866] have to be followed by the SRC and the SRS for setting up + RS SIP dialogs and sending metadata. + +5. IANA Considerations + + This document does not require any IANA actions. + + + + +Ravindranath, et al. Informational [Page 32] + +RFC 8068 SIP Recording Call Flows February 2017 + + +6. References + +6.1. Normative References + + [RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain, + "Use Cases and Requirements for SIP-Based Media Recording + (SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011, + <http://www.rfc-editor.org/info/rfc6341>. + + [RFC7865] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session + Initiation Protocol (SIP) Recording Metadata", RFC 7865, + DOI 10.17487/RFC7865, May 2016, + <http://www.rfc-editor.org/info/rfc7865>. + + [RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A. + Hutton, "Session Recording Protocol", RFC 7866, + DOI 10.17487/RFC7866, May 2016, + <http://www.rfc-editor.org/info/rfc7866>. + + [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, + "An Architecture for Media Recording Using the Session + Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May + 2014, <http://www.rfc-editor.org/info/rfc7245>. + +6.2. Informative References + + [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A + Session Initiation Protocol (SIP) Event Package for + Conference State", RFC 4575, DOI 10.17487/RFC4575, August + 2006, <http://www.rfc-editor.org/info/rfc4575>. + + [RFC4353] Rosenberg, J., "A Framework for Conferencing with the + Session Initiation Protocol (SIP)", RFC 4353, + DOI 10.17487/RFC4353, February 2006, + <http://www.rfc-editor.org/info/rfc4353>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <http://www.rfc-editor.org/info/rfc3261>. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, <http://www.rfc-editor.org/info/rfc4566>. + + + + + + +Ravindranath, et al. Informational [Page 33] + +RFC 8068 SIP Recording Call Flows February 2017 + + +Acknowledgements + + Thanks to Ofir Rath, Charles Eckel, Yaron Pdut, Dmitry Andreyev, and + Charles Armitage for their review comments. + + Thanks to Alissa Cooper, Stephen Farrell, Kathleen Moriarty, Suresh + Krishnan, Benoit Claise, Carlos Pignataro, Dan Romascanu, and Derek + Atkins for their feedback and comments during IESG reviews. + +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 Networks + Bangalore, Karnataka + India + + Email: partha@parthasarathi.co.in + + + Paul Kyzivat + Huawei + Hudson, MA + United States of America + + Email: pkyzivat@alum.mit.edu + + + + + + + + + + + + + + + +Ravindranath, et al. Informational [Page 34] + |