SIPREC                                                 Ram.
Internet Engineering Task Force (IETF)                   R. Ravindranath
Internet-Draft
Request for Comments: 8068                           Cisco Systems, Inc.
Intended status:
Category: Informational                  Parthasarathi.                                     P. Ravindran
Expires: June 22, 2017
ISSN: 2070-1721                                           Nokia Networks
                                                           Paul.
                                                              P. Kyzivat
                                                                  Huawei
                                                       December 19, 2016
                                                           February 2017

         Session Initiation Protocol (SIP) Recording Call Flows
                     draft-ietf-siprec-callflows-08

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 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) Client
   (SRC) to a Session Recording Server(SRS). Server (SRS).

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid 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 maximum candidate for any level of Internet
   Standard; see Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 22, 2017.
   http://www.rfc-editor.org/info/rfc8068.

Copyright Notice

   Copyright (c) 2016 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  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Metadata XML Instances  . . . . . . . . . . . . . . . . . . .   3
     3.1.  Sample Call flow Flow  . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Call Scenarios with SRC recording streams Recording Streams without mixing Mixing    5
       3.2.1.  Example 1: Basic Call . . . . . . . . . . . . . . . .   5
       3.2.2.  Example 2: Hold/resume Hold/Resume  . . . . . . . . . . . . . . .   8
       3.2.3.  Example 3:Call Transfer (RE-INVITE and REFER based) Based) .  12
       3.2.4.  Example 4: Call disconnect Disconnect  . . . . . . . . . . . . .  18
     3.3.  Call Scenarios with SRC recording streams Recording Streams by mixing Mixing . . .  19
       3.3.1.  Example 1: Basic call Call with SRC mixing streams Mixing Streams . . . .  20
       3.3.2.  Example 2: Hold/resume Hold/Resume with SRC recording Recording by mixing
               streams Mixing
               Streams . . . . . . . . . . . . . . . . . . . . . . .  22
       3.3.3.  Example 3: Metadata snapshot Snapshot of joining/dropping Joining/Dropping of a
               participant
               Participant to a session Session  . . . . . . . . . . . . . .  24
       3.3.4.  Example 4: Call disconnect Disconnect  . . . . . . . . . . . . .  27
     3.4.  Call scenarios Scenarios with persistent Persistent RS between SRC and SRS . .  27
       3.4.1.  Example 1: Metadata snapshot Snapshot during CS disconnect Disconnect
               with persistent Persistent RS between SRC and SRS  . . . . . . .  27  28
     3.5.  Turret-Case: Multiple CS into single Single RS with mixed stream Mixed Stream  29
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  31
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  31
   6.  Acknowledgement  References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
   7.
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  32
     6.2.  Informative References  . . . . . . .  32
     7.1.  Normative References  . . . . . . . . . . .  32
   Acknowledgements  . . . . . . .  32
     7.2.  Informative References . . . . . . . . . . . . . . . . .  32  33
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

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 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 which that describes the Communication Session(CS). Session (CS).
   This document lists few examples and shows the snapshots of metadata
   sent from a Session Recording Client(SRC) Client (SRC) to Session Recording
   Server (SRS).  For the sake of simplicity simplicity, the entire Session
   Initiation Protocol (SIP) [RFC3261] messages are not shown, instead
   only snippets of the SIP and Session Description Protocol (SDP)[RFC4566] (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 sub-sections subsections have examples that contain the metadata
   snapshot sent from the SRC to the SRS.

3.1.  Sample Call flow Flow

   The following is a sample call flow that shows the SRC establishing a
   Recording Session(RS) Session (RS) towards the SRS.  The SRC in  In this example example, the SRC
   could be part of any one of the architectures described in section Section 3
   of [RFC7245].

                   Figure 1: Sample call flow 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). 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 Section 3 of [RFC7245] [RFC7245], an SRC may be an endpoint or
   Back-to-Back User Agent(B2BUA)
   endpoint, a B2BUA, or as 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 model, as explained in
      [RFC4353].

   o  The SRC having a persistent RS with the SRS.

   o  Special flows like Turret 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. use case.

   Note that only those examples for which where metadata changes are listed in
   each category.  For some of the call flows 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 Recording Streams without mixing Mixing

   This section describes example flows where SRC can be a SIP-UA or
   B2BUA as described in section Section 3 of [RFC7245].  The SRS here can be a
   SIP-UA or an entity part of the MEDIACTRL architecture described in
   section
   Section 3 of [RFC7245].

3.2.1.  Example 1: Basic Call

   Basic call between two participants participants, Alice and Bob Bob, who are part of
   the same CS.  In this use case case, each participant sends two media
   streams(audio
   streams (audio and video).  Media streams sent by each participant
   are received by the other participant in this use-case. use case.  In this example
   example, the SRC is a B2BUA in the path between Alice and Bob Bob, as
   described in
   section 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 simplicity, only snippets of SIP/SDP SIP/
   SDP are shown.  In this example example, the SRCs records the streams of each
   participant to SRS without mixing.

   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

<?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>
        <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>

3.2.2.  Example 2: Hold/resume Hold/Resume

   A call between two participants Alice and Bob is established and a an
   RS is created for recording recording, as in example 1.  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 'participantstreamassoc' XML element is used to
   indicate whether or not a participant is contributing to a media stream or not.
   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
      ...
      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.  Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on  On the other
   hand hand, Bob (participant_id
   zSfPoSvdSDCmU3A3TRDxAw==) would be sending media media, but he does not
   receive any media from Alice
   and so 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 Bob, indicating that both are receiving and sending media.

      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
      <?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)

   Basic Based)

   A basic call between two Participants participants, Alice and Bob Bob, is connected connected,
   and
   SRC(B2BUA SRC (a B2BUA acting as SRC as per section Section 3.1.1 of [RFC7245]) has
   sent a snapshot as described in example 1.  Transfer is initiated by
   one of the participants(Alice). 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 and completed,
   Bob and Carol gets connected 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 with in within the same session - (.e.g.  RE-INVITE based
   transfer).  Participant (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. 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 UUID Universally Unique Identifier
   (UUID) tuples
   which 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
   ID, that which corresponds to Bob Bob, remains the same.

     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
  <?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>
   Transfer with a new session - (.e.g.  REFER based transfer).  In (e.g., REFER-based transfer): in this
   case
   case, a new session (CS) is created and shall be part of same CS-group CS-
   group (done by the SRC).

   The SRC first sends an optional *optional* snapshot indicating disassociation
   of the participant from the old CS.  Please note this is an optional
   message.  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.  The SRC in  In this example 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 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
     ...
     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
   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 UUID
   pair.

      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
   <?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>
          </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 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

   <?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 Recording Streams by mixing 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 Section 3.1.5 of [RFC7245].  The SRS here
   can be a SIP
   UA 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 Call with SRC mixing streams

   Basic Mixing Streams

   A basic call between two participants participants, Alice and Bob Bob, who are part of
   one CS.  In this use case case, each participant calls into a conference
   server (say, an MCU) 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
   simplicity, only snippets of SIP/
   SDP 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 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.

      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>
          </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 example, there are two participants participants, Alice and Bob Bob, in
   the conference.  Among other things, the SRC sends Session-ID in the
   metadata snapshot.  There are two Session-ID's here, Session-IDs here: one that
   corresponds to the SIP session between Alice and conference the Conference focus
   and the other for the SIP session between Bob and conference the Conference
   focus.  In this use-case, use case, since Alice and Bob calls call into the conference
   conference, these Session-ID's Session-IDs are different.

3.3.2.  Example 2: Hold/resume Hold/Resume with SRC recording Recording by mixing streams Mixing Streams

   This is the continuation of Example 1: Basic example 1 (basic call with SRC mixing
   streams.  Given a
   streams).  A call between two participants participants, Alice and Bob Bob, is
   established and a an RS is created for recording recording, as in example 5.  One
   of the participants, Bob Bob, puts Alice on hold 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 or not to a media stream.  The metadata snapshot
   looks as
   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
   <?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 resume 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]

      --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 Snapshot of joining/dropping Joining/Dropping of a
        participant
        Participant to a session 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
   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 (Carol) joins,
   then the SRC sends the below snapshot with the indication of new
   participant.

      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>
            </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>

   Given

   After some time, Alice drops after some time 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

      ....
   --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 Disconnect

   When a CS is disconnected, the SRC sends a BYE with a snapshot of
   metadata having a session stop time and participant dis-associate disassociation
   times.  The snapshot looks the same as listed in section 3.2.4 Section 3.2.4.

3.4.  Call scenarios Scenarios with persistent 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 B2BUA, or it may be part of Conference a conference model either 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.

3.4.1.  Example 1: Metadata snapshot Snapshot during CS disconnect Disconnect with
        persistent
        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>

3.5.  Turret-Case: Multiple CS into single Single RS with mixed stream Mixed Stream

   In trading floor 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 handsets/speakers
   on the same turret into a single RS.  This would means mean media in each
   CS is mixed and recorded as part of single media stream stream, and multiple
   such CSs are recording in one RSfrom a RS from an SRC to an SRS.

   Taking an example where there are two CS CSs [CS1 and CS2].  Assume CS2]: assume
   mixing is done in each of these CS CSs and both these CS CSs are recorded
   as part of single RS from a single SRC SRC, which is part of both the CS.
   CSs.  There are three possibilities here:

   o  CS1 and CS2 uses use the same focus for mixing mixing, and that focus is also
      acting as SRC in each of the CS. CSs.

   o  One of the CS (e.g.  CS1),  CS1) SRC is Focus the focus and the other CS (e.g.  CS2),
      SRC is just one of the participant 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
   uses
   use the same focus for mixing mixing, and that focus is also acting as SRC
   in each of the CS. CSs.

      Metadata snapshot with two CS 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
      ...

   <?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>
          <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] has have to be followed by the SRC and the SRS for setting up
   RS SIP
   dialog dialogs and sending metadata.

5.  IANA Considerations

   This document has no IANA considerations considerations.

6.  Acknowledgement

   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.

7.  References

7.1.

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>.

7.2.

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>.

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
   USA
   United States of America

   Email: pkyzivat@alum.mit.edu