SIPREC                                                 Ram. Ravindranath
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Informational                  Parthasarathi. Ravindran
Expires: December 17, 2016                                Nokia Networks
                                                           Paul. Kyzivat
                                                                  Huawei
                                                           June 15, 2016


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

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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 17, 2016.

Copyright Notice

   Copyright (c) 2016 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



Ravindranath, et al.    Expires December 17, 2016               [Page 1]

Internet-Draft           SIP Recording Callflows               June 2016


   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  . . . . . . . . . . . . . . . . . . . .   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  . . . . . . . . . . . . . . .   8
       3.2.3.  Example 3:Call Transfer (RE-INVITE and REFER based) .  11
       3.2.4.  Example 4: Call disconnect  . . . . . . . . . . . . .  18
     3.3.  Call Scenarios with SRC recording streams by mixing . . .  19
       3.3.1.  Example 1: Basic call with SRC mixing streams . . . .  19
       3.3.2.  Example 2: Hold/resume with SRC recording by mixing
               streams . . . . . . . . . . . . . . . . . . . . . . .  21
       3.3.3.  Example 3: Metadata snapshot of joining/dropping of a
               participant to a session  . . . . . . . . . . . . . .  24
       3.3.4.  Example 4: Call disconnect  . . . . . . . . . . . . .  27
     3.4.  Call scenarios with persistent RS between SRC and SRS . .  27
       3.4.1.  Example 1: Metadata snapshot during CS disconnect
               with persistent RS between SRC and SRS  . . . . . . .  27
     3.5.  Turret-Case: Multiple CS into single RS with mixed stream  28
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  31
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  31
   6.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  31
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  32
   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 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 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



Ravindranath, et al.    Expires December 17, 2016               [Page 2]

Internet-Draft           SIP Recording Callflows               June 2016


   snippets of the SIP and Session Description Protocol (SDP)[RFC4566]
   messages and the XML snapshot of metadata is shown.

2.  Terminology

   The terms using 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 has examples showing the metadata snapshot
   sent from SRC to SRS.  In all these use-cases, the SRC is a B2BUA.

3.1.  Sample Call flow

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
































Ravindranath, et al.    Expires December 17, 2016               [Page 3]

Internet-Draft           SIP Recording Callflows               June 2016


               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 SRC to 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 a endpoint or B2BUA
   or as part of MEDIACTRL or Conference focus.  The subsequent sections
   in this document try to list some example metadata snapshots for
   three major categories.

   o  SRC recording streams unmixed to SRS.  This includes cases where
      SRC is SIP UA or B2BUA.

   o  SRC recording mixed streams to SRS.  This includes cases where SRC
      is part of SIP conference model explained in [RFC4353].

   o  SRC having a persistent RS with SRS.

   o  Special flows like Turret flows.



Ravindranath, et al.    Expires December 17, 2016               [Page 4]

Internet-Draft           SIP Recording Callflows               June 2016


   Note that only those examples for which metadata changes are listed
   in each category.  For some of the call flows the snapshots may be
   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 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.



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



Ravindranath, et al.    Expires December 17, 2016               [Page 5]

Internet-Draft           SIP Recording Callflows               June 2016


   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>



Ravindranath, et al.    Expires December 17, 2016               [Page 6]

Internet-Draft           SIP Recording Callflows               June 2016


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



Ravindranath, et al.    Expires December 17, 2016               [Page 7]

Internet-Draft           SIP Recording Callflows               June 2016


               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

   A call between two participants Alice and Bob is established and a RS
   is created for recording as in example 1.  One of the participants
   Bob puts Alice 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 a participant is contributing to
   a media stream or not.  SRC sends a snapshot with only the changed
   XML elements.

   During hold



      F2 mid call  RE-INVITE SRC-------------------->SRS

      INVITE sip:recorder@example.com SIP/2.0
      Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
      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,



Ravindranath, et al.    Expires December 17, 2016               [Page 8]

Internet-Draft           SIP Recording Callflows               June 2016


      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>




Ravindranath, et al.    Expires December 17, 2016               [Page 9]

Internet-Draft           SIP Recording Callflows               June 2016


   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 'send' XML
   element.  Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other
   hand would be sending media but does not receive any media from Alice
   and so 'recv' XML element is absent in this instance.

   During resume

   The snapshot now has 'send' and 'recv' XML elements for both Alice
   and Bob indicating that both are receiving and sending media.



      F3 mid call  RE-INVITE SRC-------------------->SRS

      INVITE sip:recorder@example.com SIP/2.0
      Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
      From: <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



Ravindranath, et al.    Expires December 17, 2016              [Page 10]

Internet-Draft           SIP Recording Callflows               June 2016


      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 call between two Participants Alice and Bob is connected and
   SRC(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, SRC sends
   a snapshot of the participant changes to SRS.  In this transfer
   scenario, Alice drops out after transfer is completed and Bob and
   Carol gets connected and recording of media between Bob and Carol is
   done by SRC.  There are two flows that can happen here as described
   below.

   Transfer with in the same session - (.e.g.  RE-INVITE based
   transfer).  Participant Alice drops out and Carol is added to the
   same session.  No change to session/group element.  A
   'participantsessassoc' XML element indicating that Alice has
   disassociated from the CS will be present in the snapshot.  A new



Ravindranath, et al.    Expires December 17, 2016              [Page 11]

Internet-Draft           SIP Recording Callflows               June 2016


   '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 tuples
   which corresponds to Bob and Carol is sent in the snapshot from SRC
   to SRS.  Note that one half of the session ID that corresponds to Bob
   remains same.


     mid call  RE-INVITE SRC-------------------->SRS


     INVITE sip:recorder@example.com SIP/2.0
     Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
     From: <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



Ravindranath, et al.    Expires December 17, 2016              [Page 12]

Internet-Draft           SIP Recording Callflows               June 2016


     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>






Ravindranath, et al.    Expires December 17, 2016              [Page 13]

Internet-Draft           SIP Recording Callflows               June 2016


   Transfer with new session - (.e.g.  REFER based transfer).  In this
   case a new session (CS) is created and shall be part of same CS-group
   (done by SRC).

   SRC first sends an optional snapshot indicating disassociation of
   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 this example 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.


     mid call  RE-INVITE SRC-------------------->SRS


     INVITE sip:recorder@example.com SIP/2.0
     Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
     From: <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



Ravindranath, et al.    Expires December 17, 2016              [Page 14]

Internet-Draft           SIP Recording Callflows               June 2016


     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 'session' XML element with a 'stop-time'
   implicitly means that all the participants associated with that
   session have been disassociated.

   SRC sends another snapshot to indicate the participant change (due to
   REFER) and new session information after transfer.  In this example
   it is assumed SRC uses the same RS to continue recording the call.
   The 'sipSessionID' XML element in metadata snapshot now indicates Bob
   and Carol in the (local, remote) uuid pair.



      mid call  RE-INVITE SRC-------------------->SRS





Ravindranath, et al.    Expires December 17, 2016              [Page 15]

Internet-Draft           SIP Recording Callflows               June 2016


      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



Ravindranath, et al.    Expires December 17, 2016              [Page 16]

Internet-Draft           SIP Recording Callflows               June 2016


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



Ravindranath, et al.    Expires December 17, 2016              [Page 17]

Internet-Draft           SIP Recording Callflows               June 2016


           <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 SRS when
   a CS with Alice and Bob as participants is disconnected.




           SRC                                                   SRS
               |                                                     |
               |(1) BYE (metadata snapshot)   F1                     |
               |---------------------------------------------------->|
               |                            200 OK    F2             |
               |<----------------------------------------------------|


   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>



Ravindranath, et al.    Expires December 17, 2016              [Page 18]

Internet-Draft           SIP Recording Callflows               June 2016


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

   The section describes a few example call flows where 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
   UA or an entity part of MEDIACTRL architecture.  Note that the
   disconnect case is not shown since the metadata snapshot will be same
   as for a non-mixing case.

3.3.1.  Example 1: Basic call with SRC mixing streams

   Basic call between two participants Alice and Bob who are part of one
   CS.  In this use case each participant calls into a conference server
   (say, an 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 SRC in the INVITE to 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.


                           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



Ravindranath, et al.    Expires December 17, 2016              [Page 19]

Internet-Draft           SIP Recording Callflows               June 2016


      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==">



Ravindranath, et al.    Expires December 17, 2016              [Page 20]

Internet-Draft           SIP Recording Callflows               June 2016


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

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.  Given a call between two participants Alice and Bob is
   established and a RS is created for recording as in example 5.  One
   of the participants, Bob puts Alice 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 a participant is
   contributing or not to a media stream.  The metadata snapshot looks
   as below:

   During hold




Ravindranath, et al.    Expires December 17, 2016              [Page 21]

Internet-Draft           SIP Recording Callflows               June 2016


      mid call hold   RE-INVITE SRC --------------> SRS

      INVITE sip:recorder@example.com SIP/2.0
      Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
      From: <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>




Ravindranath, et al.    Expires December 17, 2016              [Page 22]

Internet-Draft           SIP Recording Callflows               June 2016


   During resume a snapshot shown below will be sent from SRC to SRS.


           mid call resume   RE-INVITE SRC --------------> SRS

      INVITE sip:recorder@example.com SIP/2.0
      Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
      From: <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==">



Ravindranath, et al.    Expires December 17, 2016              [Page 23]

Internet-Draft           SIP Recording Callflows               June 2016


            <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 SRC to SRC 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 conference
   event package [RFC4575].  Assume Alice and Bob were in the conference
   and a third participant Carol joins, then SRC sends the below
   snapshot with the indication of new participant.


           mid call resume   RE-INVITE SRC --------------> SRS

      INVITE sip:recorder@example.com SIP/2.0
      Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
      From: <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



Ravindranath, et al.    Expires December 17, 2016              [Page 24]

Internet-Draft           SIP Recording Callflows               June 2016


   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 Alice drops after some time from the conference.  SRC generates
   a new snapshot showing Alice disassociating from the session.

















Ravindranath, et al.    Expires December 17, 2016              [Page 25]

Internet-Draft           SIP Recording Callflows               June 2016


           mid call resume   RE-INVITE SRC --------------> SRS

      INVITE sip:recorder@example.com SIP/2.0
      Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
      From: <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>





Ravindranath, et al.    Expires December 17, 2016              [Page 26]

Internet-Draft           SIP Recording Callflows               June 2016


3.3.4.  Example 4: Call disconnect

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

3.4.  Call scenarios with persistent RS between SRC and SRS

   The section shows the snapshots of metadata for the cases where a
   persistent RS exists between SRC and SRS.  An SRC here may be SIP UA
   or a B2BUA or may be part of Conference model either as focus or a
   participant in a conference.  The SRS here could be a SIP UA or an
   entity part of MEDIACTRL architecture.  Except in the disconnect
   case, the snapshot remains same as mentioned in previous sections.

3.4.1.  Example 1: Metadata snapshot during CS disconnect with
        persistent RS between SRC and SRS


































Ravindranath, et al.    Expires December 17, 2016              [Page 27]

Internet-Draft           SIP Recording Callflows               June 2016


   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 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 means media



Ravindranath, et al.    Expires December 17, 2016              [Page 28]

Internet-Draft           SIP Recording Callflows               June 2016


   in each CS is mixed and recorded as part of single media stream and
   multiple such CSs are recording in one RSfrom a SRC to SRS.

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

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

   o  One of the CS (e.g.  CS1), SRC is Focus and the other CS (e.g.
      CS2), SRC is just one of the participant of the conference.

   o  In both CS1 and CS2, SRC is just a participant of conference.

   The following example shows the first possibility where CS1 and CS2
   uses the same focus for fixing and that focus is also acting as SRC
   in each of the CS.



      snapshot of metadata  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



Ravindranath, et al.    Expires December 17, 2016              [Page 29]

Internet-Draft           SIP Recording Callflows               June 2016


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



Ravindranath, et al.    Expires December 17, 2016              [Page 30]

Internet-Draft           SIP Recording Callflows               June 2016


          <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 considerations mentioned in [RFC7865] and [RFC7866] has to
   be followed by SRC and SRS for setting up RS SIP dialog and sending
   metadata.

5.  IANA Considerations

   This document has no IANA considerations

6.  Acknowledgement

   Thanks to Ofir Rath, Charles Eckel, Yaron Pdut, Dmitry Andreyev and
   Charles Armitage for their review comments.








Ravindranath, et al.    Expires December 17, 2016              [Page 31]

Internet-Draft           SIP Recording Callflows               June 2016


7.  Informative References

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

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

   [RFC6230]  Boulton, C., Melanchuk, T., and S. McGlashan, "Media
              Control Channel Framework", RFC 6230,
              DOI 10.17487/RFC6230, May 2011,
              <http://www.rfc-editor.org/info/rfc6230>.

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

   [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.    Expires December 17, 2016              [Page 32]

Internet-Draft           SIP Recording Callflows               June 2016


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

   Email: pkyzivat@alum.mit.edu
























Ravindranath, et al.    Expires December 17, 2016              [Page 33]