SIPREC                                           Ram Mohan. Ravindranath
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                Parthasarathi. Ravindran
Expires: September 26, 2013 January 14, 2014                         Nokia Siemens Networks
                                                           Paul. Kyzivat
                                                                  Huawei
                                                          March 25,
                                                           July 13, 2013

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

Abstract

   Session recording is a critical requirement in many communications
   environments such as call centers and financial trading.  In some of
   these environments, all calls must be recorded for regulatory,
   compliance, and consumer protection reasons.  Recording of a session
   is typically performed by sending a copy of a media stream to a
   recording device.  This document lists call flows that has snapshot
   of metadata sent from SRC to SRS, the metadata format for which is
   described in [I-D.ietf-siprec-metadata] .  This is purely an
   informational document that is written to support the model defined
   in the metadata draft.

Status of this Memo

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

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

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

   This Internet-Draft will expire on September 26, 2013. January 14, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Metadata XML schema Instances  . . . . . . . . . . . . . . . .  3
     3.1.  Sample Call flow . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Call Scenarios with SRC recording streams with out
           mixing . . . . . . . . . . . . . . . . . . . . . . . . . .  5
       3.2.1.  Example 1: Basic Call  . . . . . . . . . . . . . . . .  5
       3.2.2.  Example 2: Hold/resume . . .  5 . . . . . . . . . . . . .  7
       3.2.3.  Example 3:Call Transfer (RE-INVITE and REFER based)  . 10
       3.2.4.  Example 4: Call disconnect . . . . . . . . . . . . . . 16
     3.3.  Call Scenarios with SRC recording streams by mixing  . . . 18
       3.3.1.  Example 1: Basic call with SRC mixing streams  . . . . 18
       3.3.2.  Example 2: Hold/resume with SRC recording by
               mixing streams . . . . . . . . . . . . . . . . . .  7
     3.4. . . 20
       3.3.3.  Example 3: Basic Call with transfer Metadata snapshot of joining/dropping
               of a participant to a session  . . . . . . . . . . . 10
     3.5. . 23
       3.3.4.  Example 4: Call disconnect . . . . . . . . . . . . . . 26
     3.4.  Call scenarios with persistent RS between SRC and SRS  . . 14
     3.6. 26
       3.4.1.  Example 5: 1: Metadata snapshot during CS disconnect
               with persistent RS between SRC and SRS . . . . . . . . 26
     3.5.  Turrent-Case: Multiple CS into single RS with mixed
           stream . 15 . . . . . . . . . . . . . . . . . . . . . . . . . 27
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17 29
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17 29
   6.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 17 30
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 30
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 18 30
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 18 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 30

1.  Overview

   [I-D.ietf-siprec-metadata] document focuses on the Recording metadata
   which describes the communication session.  The document lists a few
   examples and shows the snapshots of metadata sent from SRC to SRS.
   For the sake of simplicity the entire SIP [RFC3261] messages are not
   shown at various points, instead only a snip snippets of the SIP/SDP message
   messages and the XML snapshot of metadata is shown.  This document is
   informational and is not normative on any aspect of SIPREC.

2.  Terminology

   The terms using in this defined are defined in
   [I-D.ietf-siprec-metadata].  No new terms/definitions are introduced
   in this document.

3.  Metadata XML schema Instances

   This section describes the metadata model XML instances for different
   use cases of SIPREC.  For the sake of simplicity the complete SIP
   messages SIP/SDP
   snippets are NOT shown here.

3.1.  Sample Call flow

   The following is a sample call flow that shows the SRC establishing a
   recording session towards the SRS.  The call flow is essentially
   identical when the SRC is a B2BUA or as the endpoint itself.  Note
   that the SRC can choose when to establish the Recording Session
   independent in this example could be
   part of any one of the Communication Session, even though the following
   call flow suggests that the architectures described in section 3 of
   [I-D.ietf-siprec-architecture].

               SRC is establishing the Recording Session
   (message #5) after the Communication Session is established.

         UA A           SRC                    UA B                                                   SRS
         |(1)CS INVITE  |                       |
               |
         |------------->|                                                     |                      |
         |              |(2)CS
               |(1) INVITE (metadata snapshot)   F1                  |
               |---------------------------------------------------->|
               |
         |              |---------------------->|                      |
         |              |           (3)                            200 OK                   |
               |<----------------------------------------------------|
               |(3) ACK                                              |
               |---------------------------------------------------->|
               |(4) RTP                                              |              |<----------------------|
               |====================================================>|
               |====================================================>|
               |====================================================>|
               |====================================================>|
               |(5) UPDATE/RE-INVITE (metadata update 1)     F2      |
               |---------------------------------------------------->|
               |   (4)                      200 OK                         |
               |<----------------------------------------------------|
               | ................................................... |
         |<-------------|                       |                      |
         |              |(5)RS INVITE with SDP
               | ................................................... |
               |              |--------------------------------------------->|                                                     |
               |====================================================>|
               |====================================================>|
               |(7) UPDATE/RE-INVITE (metadata update  n-1)    Fn-1  |
               |---------------------------------------------------->|
               |  (6)                       200 OK with SDP |
         |              |<---------------------------------------------|
         |(7)CS RTP     |                       |                      |
         |=============>|======================>|                      |
         |<=============|<======================|                      |
         |              |(8)RS RTP              |                      |                        |              |=============================================>|
         |              |=============================================>|
         |              |                       |                      |
         |         Mid call updates(hold/resume/re-invite(new offer)   |
         |              |                       |                      |
         |(9)CS BYE     |                       |                      |
         |------------->|                       |                      |
         |              |(10)CS BYE             |                      |
         |              |---------------------->|                      |
         |              |(11)RS BYE             |                      |
         |              |--------------------------------------------->|
         |              |                       |                      |

   The above call flow can also apply to
               |<----------------------------------------------------|

   For the case sake of a centralized
   conference with a mixer.  For clarity, simplicity, ACKs to INVITEs RE-INVITES and 200 OKs to BYEs are not
   shown.  The conference focus can provide the SRC
   functionality since the conference focus has access to all subsequent sections describes the media snapshot of metadata
   sent from each conference participant.  When a recording is requested, the SRC delivers the metadata and the media streams to SRS for each of the SRS.  Since
   the conference focus has access above transactions (F1 ...
   Fn-1).  There may be multiple UPDATES/RE-INVITES mid call to a mixer,
   indicates snapshots of different CS changes.  Depending on the
   architecture described in section 3 of [I-D.ietf-siprec-architecture]
   an SRC may choose to mix
   the media streams from all participants as be a single mixed media
   stream towards the SRS.

   An endpoint or B2BUA or as part of MEDIACTRL or
   Conference Focus.  The subsequent sections in this document tries to
   list some example metadata snapshots for three major categories.

   o  SRC can use a single recording session streams unmixed to record multiple
   communication sessions.  Every time the SRS.  This includes cases where
      SRC wants to record a new
   call, the is SIP UA or B2BUA.
   o  SRC updates the recording session with a new SDP offer to
   add new recorded mixed streams to the recording session, and
   correspondingly also update the metadata for the new call.

3.2.  Example 1: Basic SRS.  This includes cases where SRC
      is part of SIP conference model explained in [RFC4353]
   o  SRC having a persistent RS with SRS
   o  Special flows like Turrent flows

   Note that only those examples for which metadata changes are listed
   in each category.  For some of the call flows the snapshots may be
   same (like in case of endpoint or B2BUA acting as SRC) and the same
   is mentioned in the text preceding the example.

3.2.  Call Scenarios with SRC recording streams with out mixing

   The section covers the models mentioned in the architecture document
   in section 3 of [I-D.ietf-siprec-architecture] where an SRC may be a
   SIP-UA or B2BUA.  The SRS
               |                                                     |
               |(1) INVITE (metadata snapshot)   F1                  |
               |---------------------------------------------------->|
               |                            200 OK    F2             |
               |<----------------------------------------------------|
               |(3) ACK         F3                                   |
               |---------------------------------------------------->|
               |(4) RTP                                              |
               |====================================================>|
               |====================================================>|
               |====================================================>|
               |====================================================>|
               |(5) UPDATE/RE-INVITE (metadata update 1)     F4      |
               |---------------------------------------------------->|
               |                      200 OK        F5               |
               |<----------------------------------------------------|
               |====================================================>|
               |====================================================>|
               |(7) UPDATE/RE-INVITE (metadata update 2)       F6    |
               |---------------------------------------------------->|
               |                       200 OK         F7             |
               |<----------------------------------------------------| here could be a SIP-UA or an entity part of
   MEDIACTRL architecture described in [RFC6230].

3.2.1.  Example 1: Basic Call

   Basic call between two Participants Ram Alice and Partha Bob who are part of one session.
   CS.  In this use case each participant sends two Media Streams.
   Media Streams sent by each participant are received all other
   participants of that CS in this use-case.  Below is the initial snapshot sent by
   SRC in the INVITE to SRS that has complete metadata.  For the sake of
   simplicity only snippets of SDP SIP/SDP are shown.  Here  The SRCs records the RS
   stream is unmixed.
   streams of each participant to SRS with out mixing in this example.

      F1  INVITE SRC --------------> SRS

      INVITE sip:recorder@example.com SIP/2.0
      Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
      From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
      To: <sip:recorder@example.com>
      Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
      CSeq: 101 INVITE
      Max-Forwards: 70
      Require: siprec
      Accept: application/sdp, application/rs-metadata,
      application/rs-metadata-request
      Contact: <sip: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'>
              <datamode>complete</datamode>
         <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
            <start-time>2010-12-16T23:41:07Z</start-time>
         </session>
          <participant
             participant_id="srfBElmCRp2QB23b7Mpk0w==">
            <nameID aor=sip:ram@example.com> aor=sip:alice@atlanta.com>
             <name xml:lang="it">RamMohan R</name> xml:lang="it">Alice</name>
            </nameID>
          </participant>
          <participantsessionassoc
             participant_id="srfBElmCRp2QB23b7Mpk0w=="
             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>
          <participant
              participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
              <nameID aor=sip:partha@example.com> aor=sip:bob@biloxy.com>
               <name xml:lang="it">Parthasarathi R</name> xml:lang="it">Bob</name>
            </nameID>
          </participant>
          <participantsessionassoc
              participant="zSfPoSvdSDCmU3A3TRDxAw=="
              participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
                   session_id="hVpd7YQgRW2nD22h7q60JQ==">
             <associate-time>2010-12-16T23:41:07Z</associate-time>
          </participantsessionassoc>
          <participantstreamassoc
              participant="zSfPoSvdSDCmU3A3TRDxAw==">
              participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
            <send>8zc6e0lYTlWIINA6GR+3ag==</send>
            <send>EiXGlc+4TruqqoDaNE76ag==</send>
            <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
            <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
          </participantstreamassoc>
          <stream id="UAAMm5GRQKSCMVvLyl4rFw=="
              session="hVpd7YQgRW2nD22h7q60JQ==">
              session_id="hVpd7YQgRW2nD22h7q60JQ==">
              <label>96</label>
          </stream>
          <stream id="i1Pz3to5hGk8fuXl+PbwCw=="
              session="hVpd7YQgRW2nD22h7q60JQ==">
              session_id="hVpd7YQgRW2nD22h7q60JQ==">
              <label>97</label>
          </stream>
          <stream id="8zc6e0lYTlWIINA6GR+3ag=="
              session="zSfPoSvdSDCmU3A3TRDxAw==">
              session_id="zSfPoSvdSDCmU3A3TRDxAw==">
              <label>98</label>
          </stream>
          <stream id="EiXGlc+4TruqqoDaNE76ag=="
              session="zSfPoSvdSDCmU3A3TRDxAw==">
              session_id="zSfPoSvdSDCmU3A3TRDxAw==">
              <label>99</label>
          </stream>
     </recording>

3.3.

3.2.2.  Example 2: Hold/resume

   Basic

   Assume a call between two Participants Ram Alice and Partha. Bob is established
   and a RS is created for recording as in example1.  This is the
   continuation of above use-case.  One of the participants(say Ram)
   goes on participants Bob puts
   Alice hold and then resumes as part of the same session.  The send
   and recv XML elements of a participant is used to indicate whether a
   participant is sending not sending a particular media stream whose
   properties are represented by stream element.  The metadata snapshot
   looks as below

   During hold

      F4

      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
      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=inactive
      a=sendonly
      ...
      m=video 49174 RTP/AVPF 96
      a=rtpmap:96 H.264/90000
      a=label:97
      a=inactive
      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'>
          <datamode>partial</datamode>
            <participantstreamassoc
             participant="srfBElmCRp2QB23b7Mpk0w==">
             participant_id="srfBElmCRp2QB23b7Mpk0w==">
             <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
             <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
            </participantstreamassoc>
            <participantstreamassoc
             participant="zSfPoSvdSDCmU3A3TRDxAw==">
             participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
              <send>8zc6e0lYTlWIINA6GR+3ag==</send>
              <send>EiXGlc+4TruqqoDaNE76ag==</send>
             </participantstreamassoc>
           <stream id="UAAMm5GRQKSCMVvLyl4rFw=="
              session="hVpd7YQgRW2nD22h7q60JQ==">
              <label>96</label>
          </stream>
          <stream id="i1Pz3to5hGk8fuXl+PbwCw=="
              session="hVpd7YQgRW2nD22h7q60JQ==">
              <label>97</label>
          </stream>
          <stream id="8zc6e0lYTlWIINA6GR+3ag=="
              session="zSfPoSvdSDCmU3A3TRDxAw==">
              <label>98</label>
          </stream>
          <stream id="EiXGlc+4TruqqoDaNE76ag=="
              session="zSfPoSvdSDCmU3A3TRDxAw==">
              <label>99</label>
          </stream>
           </recording>

   During resume

   The snapshot will look pretty much same as

   In the above snippet during Alice with just participant_id
   srfBElmCRp2QB23b7Mpk0w== only receives media streams since Alice is
   put on hold and does not send any media.  The same is indicated by
   the SDP
   dir change.

    F5 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
      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'>
          <datamode>partial</datamode>
            <participantstreamassoc
             participant_id="srfBElmCRp2QB23b7Mpk0w==">
             <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
             <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
             <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
             <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
             <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
             <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
            </participantstreamassoc>
            <participantstreamassoc
              participant="zSfPoSvdSDCmU3A3TRDxAw==">
             participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
              <send>8zc6e0lYTlWIINA6GR+3ag==</send>
              <send>EiXGlc+4TruqqoDaNE76ag==</send>
            <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
              <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
             <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
             </participantstreamassoc>

           <stream id="UAAMm5GRQKSCMVvLyl4rFw=="
              session="hVpd7YQgRW2nD22h7q60JQ==">
              <label>96</label>
          </stream>
          <stream id="i1Pz3to5hGk8fuXl+PbwCw=="
              session="hVpd7YQgRW2nD22h7q60JQ==">
              <label>97</label>
          </stream>
          <stream id="8zc6e0lYTlWIINA6GR+3ag=="
              session="zSfPoSvdSDCmU3A3TRDxAw==">
              <label>98</label>
          </stream>
          <stream id="EiXGlc+4TruqqoDaNE76ag=="
              session="zSfPoSvdSDCmU3A3TRDxAw==">
              <label>99</label>
          </stream>
           </recording>

3.4.

3.2.3.  Example 3: Basic Call with transfer 3:Call Transfer (RE-INVITE and REFER based)

   Basic call between two Participants Ram Alice and Partha Bob is connected and
   SRC has sent a snapshot as in
   Use-case example 1.  Transfer is initiated by
   one of the participants or by
   other entity(3PCC case). participants(Alice).  After the transfer is completed, SRC
   sends a snapshot of the participant changes to SRS.  In this instance participant Ram transfer
   scenario, Alice drops out during
   the after transfer is completed and Participant Paul joins the session. Bob and
   Carol gets connected and recording of media between Bob and Carol is
   done by SRC.  There can may be two cases here, same session continues after transfer or a new
   session (e.g.  REFER based transfer) is created here as described below.

   Transfer with in the same session retained - (.e.g.  RE-INVITE based
   transfer).  Participant Ram Alice drops out and Paul Carol is added to the
   same session.  No change to session/group element.  Paul  A
   participantsessassoc element indicating that Alice has disassociated
   from the CS will have be present in the snapshot.  A new
   stream participant XML
   element which maps representing Carol with mapping to RS SDP using the same labels RS SDP stream
   used for mapping earlier Alice's stream is sent in this
   instance. the snapshot.

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

     INVITE sip:recorder@example.com SIP/2.0
     Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
     From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
     To: <sip:recorder@example.com>
     Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
     CSeq: 101 INVITE
     Max-Forwards: 70
     Require: siprec
     Accept: application/sdp, application/rs-metadata,
     application/rs-metadata-request
     Contact: <sip:2000@src.example.com>;+sip.src
     Content-Type: multipart/mixed;boundary=foobar
     Content-Length: [length]

     --foobar
     Content-Type: application/SDP
     ...
     m=audio 49170 49180 RTP/AVP 0
     a=rtpmap:0 PCMU/8000
     a=label:96
     a=sendonly
     ...
     m=video 49174 49182 RTP/AVPF 96
     a=rtpmap:96 H.264/90000
     a=label:97
     a=sendonly
     ...
     m=audio 51372 51374 RTP/AVP 0
     a=rtpmap:0 PCMU/8000
     a=label:98
     a=sendonly
     ...
     m=video 49176 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'>
             <datamode>partial</datamode>
              <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>
         <participant
            participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
             <nameIDaor=sip:paul@example.com>
            <nameIDaor=sip:carol@example.com>
             <name xml:lang="it">Paul Kyzivat</name> xml:lang="it">Carol</name>
           </nameID>
         </participant>
         <participantsessionassoc
            participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
            session_id="hVpd7YQgRW2nD22h7q60JQ==">
             <associate-time>2010-12-16T23:41:07Z</associate-time>
            <associate-time>2013-12-16T23:41:07Z</associate-time>
         </participantsession>
         <participantstreamassoc
            participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
           <send>60JAJm9UTvik0Ltlih/Gzw==</send>
           <send>AcR5FUd3Edi8cACQJy/3JQ==</send>
           <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
           <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
            <associate-time>2010-12-16T23:41:07Z</associate-time>
           <associate-time>2013-12-16T23:42:07Z</associate-time>
         </participantstreamassoc>
          <stream stream_id="60JAJm9UTvik0Ltlih/Gzw=="
              session_id="hVpd7YQgRW2nD22h7q60JQ==">
              <label>96</label>
          </stream>
          <stream stream_id="AcR5FUd3Edi8cACQJy/3JQ=="
              session_id="hVpd7YQgRW2nD22h7q60JQ==">
              <label>97</label>
          </stream>
          <stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
              session_id="zSfPoSvdSDCmU3A3TRDxAw==">
              <label>98</label>
          </stream>
          <stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
              session_id="zSfPoSvdSDCmU3A3TRDxAw==">
              <label>99</label>
          </stream>
    </recording>

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

   SRC may send first sends an optional snapshot indicating stop for disassociation of
   participant from the old
   session.

          <?xml version="1.0" encoding="UTF-8"?>
      <recording xmlns='urn:ietf:params:xml:ns:recording'>
             <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==">
            <disasociate-time>2010-12-16T23:41:07Z</disassociate-time>
          </participantsessionassoc>
    </recording>

   SRC sends CS.  Please note this is a snapshot to indicate the optional message.
   An SRC may choose to just send a INVITE with a new session element to
   implicitly indicate that the participants are now part of a different
   CS with out sending disassociation from the old CS.  Also note that
   the SRC in this example uses the same RS.  In case it decides to use
   a new RS, it will tear down the current RS using normal SIP
   procedures (BYE) with metadata as in example 4.

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

     INVITE sip:recorder@example.com SIP/2.0
     Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
     From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
     To: <sip:recorder@example.com>
     Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
     CSeq: 101 INVITE
     Max-Forwards: 70
     Require: siprec
     Accept: application/sdp, application/rs-metadata,
     application/rs-metadata-request
     Contact: <sip: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'>
             <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==">
            <disasociate-time>2010-12-16T23:41:07Z</disassociate-time>
          </participantsessionassoc>
    </recording>

   Note in the above snapshot the participantsessionassoc element is
   optional as indicating session XML element with a stop-time
   implicitly means that all the participants associated with that
   session have been disassociated.

   SRC sends another snapshot to indicate the participant change (due to
   REFER) and new session information after transfer.  In this example the same RS
   it is
   used. assumed SRC uses the same.

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

      INVITE sip:recorder@example.com SIP/2.0
      Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
      From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
      To: <sip:recorder@example.com>
      Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
      CSeq: 101 INVITE
      Max-Forwards: 70
      Require: siprec
      Accept: application/sdp, application/rs-metadata,
      application/rs-metadata-request
      Contact: <sip:2000@src.example.com>;+sip.src
      Content-Type: multipart/mixed;boundary=foobar
      Content-Length: [length]

      --foobar
      Content-Type: application/SDP
      ...
      m=audio 49170 49180 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      a=label:96
      a=sendonly
      ...
      m=video 49174 49182 RTP/AVPF 96
      a=rtpmap:96 H.264/90000
      a=label:97
      a=sendonly
      ...
      m=audio 51372 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'>
              <datamode>complete</datamode>
          <session session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
            <start-time>2010-12-16T23:41:07Z</start-time>
          </session>
          <participant
              participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
              <nameID aor=sip:Bob@biloxy.com/>
           </participant>
          <participantsessionassoc
              participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
              session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
              <associate-time>2010-12-16T23:32:03Z</associate-time>
           </participantsessionassoc>

          <participantstreamassoc
              participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
            <send>8zc6e0lYTlWIINA6GR+3ag==</send>
            <send>EiXGlc+4TruqqoDaNE76ag==</send>
            <recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
            <recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
          </participantstreamassoc>
          <participant
             participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
             <nameID aor=sip:carol@example.com/>
          </participant>
          <participantsessionassoc
             participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
             session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
           <associate-time>2010-12-16T23:41:07Z</associate-time>
          </participantsessionassoc>
          <participantstreamassoc
             participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
           <send>60JAJm9UTvik0Ltlih/Gzw==</send>
           <send>AcR5FUd3Edi8cACQJy/3JQ==</send>
           <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
           <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
           </participantstreamassoc>
          <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>
     </recording>

3.2.4.  Example 4: Call disconnect

   This example shows a snapshot of metadata sent by an SRC at CS
   disconnect where the participants of CS are Alice and Bob
           SRC                                                   SRS
               |                                                     |
               |(1) BYE (metadata snapshot)   F1                     |
               |---------------------------------------------------->|
               |                            200 OK    F2             |
               |<----------------------------------------------------|

   F1  BYE SRC  -----------> SRS

   BYE sip:2001@8.3.2.12:5060 SIP/2.0
   Via: SIP/2.0/UDP 8.3.2.34:5060;branch=z9hG4bK47c8eb30
   From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
   To: <sip:recorder@example.com>
   Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
   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'>
              <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==">
             <disasociate-time>2010-12-16T23:41:07Z</disassociate-time>
           </participantsessionassoc>
      </recording>

3.3.  Call Scenarios with SRC recording streams by mixing

   The section covers the models mentioned in the architecture document
   in section 3 of [I-D.ietf-siprec-architecture] where an SRC may be
   part of Conference model either as Focus or a participant in
   Conference.  The SRS here could be a SIP UA or an entity part of
   MEDIACTRL architecture.  Note that the disconnect case is not shown
   since the metadata snapshot will be same as for a non-mixing case.

3.3.1.  Example 1: Basic call with SRC mixing streams

   Basic call between two Participants Alice and Bob who are part of one
   CS.  In this use case each participant sends one Media Streams.
   Media Streams sent by each participant is received by the other
   participant.  Below is the initial snapshot sent by SRC in the INVITE
   to SRS that has complete metadata.  For the sake of simplicity only
   snippets of SIP/SDP are shown.  The SRCs records the streams of each
   participant to SRS by mixing in this example.  The SRC here could be
   part of conference Focus model described in section 3 of
   [I-D.ietf-siprec-architecture].

                           F1  INVITE SRC --------------> SRS

      INVITE sip:recorder@example.com SIP/2.0
      Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
      From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
      To: <sip:recorder@example.com>
      Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
      CSeq: 101 INVITE
      Max-Forwards: 70
      Require: siprec
      Accept: application/sdp, application/rs-metadata,
      application/rs-metadata-request
      Contact: <sip: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'>
              <datamode>complete</datamode>
         <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
            <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>
          <participantsessionassoc
             participant_id="srfBElmCRp2QB23b7Mpk0w=="
             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>
          <participant
              participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
              <nameID aor=sip:bob@biloxy.com>
               <name xml:lang="it">Bob</name>
            </nameID>
          </participant>
          <participantsessionassoc
              participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
                   session_id="hVpd7YQgRW2nD22h7q60JQ==">
             <associate-time>2010-12-16T23:41:07Z</associate-time>
          </participantsessionassoc>
          <participantstreamassoc
              participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
            <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
            <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
          </participantstreamassoc>
          <stream id="i1Pz3to5hGk8fuXl+PbwCw=="
              session_id="hVpd7YQgRW2nD22h7q60JQ==">
              <label>96</label>
          </stream>
     </recording>

3.3.2.  Example 2: Hold/resume with SRC recording by mixing streams

   Assume a call between two Participants Alice and Bob is established
   and a RS is created for recording as in example 5.  This is the
   continuation of above use-case.  One of the participants Bob puts
   Alice hold and then resumes as part of the same session.  The send
   and recv XML elements of a participant is used to indicate whether a
   participant is sending not sending a particular media stream whose
   properties are represented by stream element.  The metadata snapshot
   looks as below:

   During hold
                           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
      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'>
              <datamode>partial</datamode>
          <participantstreamassoc
             participant_id="srfBElmCRp2QB23b7Mpk0w==">
              <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
          </participantstreamassoc>
          <participantstreamassoc
              participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
            <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
          </participantstreamassoc>
          <stream id="i1Pz3to5hGk8fuXl+PbwCw=="
              session_id="hVpd7YQgRW2nD22h7q60JQ==">
              <label>96</label>
          </stream>
     </recording>

   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
      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'>
              <datamode>partial</datamode>
          <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>
          <stream id="i1Pz3to5hGk8fuXl+PbwCw=="
              session_id="hVpd7YQgRW2nD22h7q60JQ==">
              <label>96</label>
          </stream>
     </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.  The below shows a snapshot sent from SRC to
   SRC in these case.  Note the SRC here can be a focus or a participant
   in the conference.  In case where the SRC is a participant it may
   learn the information required for metadata by subscribing to
   conference event package [RFC4575].  Assume Alice and Bob were in the
   conference and a third participant Carol joins, then SRC sends the
   below snapshot with the indication of new participant.

                           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
      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'>
              <datamode>partial</datamode>
              <participant
             participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
             <nameIDaor=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>
          </participantsession>
          <participantstreamassoc
             participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
             <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
             <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
          </participantstreamassoc>
     </recording>

   Assume Alice drops after some time from the conference.  SRC
   generates a new snapshot showing Alice disassociating from the
   session

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

      INVITE sip:recorder@example.com SIP/2.0
      Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
      From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
      To: <sip:recorder@example.com>
      Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
      CSeq: 101 INVITE
      Max-Forwards: 70
      Require: siprec
      Accept: application/sdp, application/rs-metadata,
      application/rs-metadata-request
      Contact: <sip: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:98
      a=sendonly
      ...
      m=video 49176 RTP/AVPF 96
      a=rtpmap:96 H.264/90000
      a=label:99
      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'>
              <datamode>partial</datamode>
          <session session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
            <start-time>2010-12-16T23:41:07Z</start-time>
          </session>
          <participant
              participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
              <nameID aor=sip:partha@example.com/>
           </participant>
          <participantsessionassoc
              participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
              session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
              <associate-time>2010-12-16T23:32:03Z</associate-time>
           </participantsessionassoc>
          <participantstreamassoc
              participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
            <send>8zc6e0lYTlWIINA6GR+3ag==</send>
            <send>EiXGlc+4TruqqoDaNE76ag==</send>
            <recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
            <recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
          </participantstreamassoc>
          <participant
             participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
             <nameID aor=sip:paul@example.com/>
          </participant>
              <participantsessionassoc
             participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
             session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
             participant_id="srfBElmCRp2QB23b7Mpk0w=="
             session_id="hVpd7YQgRW2nD22h7q60JQ==">
           <associate-time>2010-12-16T23:41:07Z</associate-time>
          </participantsessionassoc>
          <participantstreamassoc
             participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
           <send>60JAJm9UTvik0Ltlih/Gzw==</send>
           <send>AcR5FUd3Edi8cACQJy/3JQ==</send>
           <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
           <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
           </participantstreamassoc>
          <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>
      </recording>

3.5.

3.3.4.  Example 4: Call disconnect

   This example shows

   When a CS is disconnected, SRC sends BYE with a snapshot of metadata sent by an
   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 at CS and SRS

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

3.4.1.  Example 1: Metadata snapshot during CS are Ram and Partha disconnect with
        persistent RS between SRC and SRS
               |                                                     |
               |(1) BYE (metadata snapshot)   F1                     |
               |---------------------------------------------------->|
               |                            200 OK    F2             |
               |<----------------------------------------------------|

   F1  BYE

   RE-INVITE sent from SRC  -----------> SRS

   INVITE sip:2001@8.3.2.12:5060 SIP/2.0
   Via: SIP/2.0/UDP 8.3.2.34:5060;branch=z9hG4bK47c8eb30
   From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
   To: <sip:recorder@example.com>
   Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
   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'>
              <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==">
             <disasociate-time>2010-12-16T23:41:07Z</disassociate-time>
           </participantsessionassoc>
      </recording>

3.6.  Example 5:

3.5.  Turrent-Case: Multiple CS into single RS with mixed stream

   In trading turret, audio mixing is done locally before forwarding to
   the recording server.  Sender and receiver audio is mixed for each
   communication session.  The audio from multiple communication
   sessions is also mixed, or multiplexed, in a single RTP session to
   the recording server.

      F1

      snapshot of metadata  INVITE SRC --------------> SRS

      Content-Type: application/SDP
      ...
      m=audio 49170 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      a=label:96
      a=sendonly
      ...
   <?xml version="1.0" encoding="UTF-8"?>
       <recording xmlns='urn:ietf:params:xml:ns:recording'>
              <datamode>complete</datamode>
           <group group_id="7+OTCyoxTmqmqyA/1weDAg==">
                  <associate-time>2010-12-16T23:41:07Z</associate-time>
          </group>
          <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
             <group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
            <start-time>2010-12-16T23:41:07Z</start-time>
          </session>
         <session session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
             <group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
            <start-time>2010-12-16T23:43:07Z</start-time>
          </session>
          <participant
             participant_id="srfBElmCRp2QB23b7Mpk0w==">
            <nameID aor=sip:ram@example.com>
             <name xml:lang="it">RamMohan R</name>
            </nameID>
          </participant>
          <participantsessionassoc
             participant_id="srfBElmCRp2QB23b7Mpk0w=="
             session_id="hVpd7YQgRW2nD22h7q60JQ==">
           <associate-time>2010-12-16T23:41:07Z</associate-time>
          </participantsessionassoc>
          <participantstreamassoc
             participant_id="srfBElmCRp2QB23b7Mpk0w==">
             <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
             <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
          </participantstreamassoc>
          <participant
              participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
              <nameID aor=sip:partha@example.com>
               <name xml:lang="it">Parthasarathi R</name>
            </nameID>
          </participant>
          <participantsessionassoc
              participant="zSfPoSvdSDCmU3A3TRDxAw=="
              session="hVpd7YQgRW2nD22h7q60JQ==">
              participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
              session_id="hVpd7YQgRW2nD22h7q60JQ==">

             <associate-time>2010-12-16T23:41:07Z</associate-time>
          </participantsessionassoc>
          <participantsessionassoc
              participant="zSfPoSvdSDCmU3A3TRDxAw=="
              session="zzlafnvvjlCHllaHF6mn8kkSS==">
              participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
              session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
             <associate-time>2010-12-16T23:43:07Z</associate-time>
          </participantsessionassoc>
          <participantstreamassoc
              participant="zSfPoSvdSDCmU3A3TRDxAw==">
              participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
            <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
            <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
          </participantstreamassoc>
          <participant
             participant_id="EiXGlc+4TruqqoDaNE76ag==">
            <nameID aor=sip:paul@example.com>
             <name xml:lang="it">Paul</name>
            </nameID>
          </participant>
          <participantsessionassoc
              participant="EiXGlc+4TruqqoDaNE76ag=="
              session="zzlafnvvjlCHllaHF6mn8kkSS==">
              participant_id="EiXGlc+4TruqqoDaNE76ag=="
              session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
             <associate-time>2010-12-16T23:43:07Z</associate-time>
          </participantsessionassoc>
          <participantstreamassoc
              participant="EiXGlc+4TruqqoDaNE76ag==">
              participant_id="EiXGlc+4TruqqoDaNE76ag==">
            <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
            <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
          </participantstreamassoc>

          <stream id="UAAMm5GRQKSCMVvLyl4rFw=="
              session="hVpd7YQgRW2nD22h7q60JQ==">
              session_id="hVpd7YQgRW2nD22h7q60JQ==">
              <label>96</label>
          </stream>
     </recording>

4.  Security Considerations

   There is no security consideration as it is informatioal callflow
   document.

5.  IANA Considerations

   This document has no IANA considerations

6.  Acknowledgement

   Thanks to Ofir Rath, Charles Eckel for their review comments.

7.  References

7.1.  Normative References

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

7.2.  Informative References

   [I-D.ietf-siprec-metadata]
              R, R., Ravindran, P., and P. Kyzivat, "Session Initiation
              Protocol (SIP) Recording Metadata",
              draft-ietf-siprec-metadata-11
              draft-ietf-siprec-metadata-12 (work in progress),
              January
              May 2013.

   [I-D.ietf-siprec-architecture]
              Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
              Architecture for Media Recording using the Session
              Initiation Protocol", draft-ietf-siprec-architecture-08
              (work in progress), May 2013.

   [RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
              Initiation Protocol (SIP) Event Package for Conference
              State", RFC 4575, August 2006.

   [RFC4353]  Rosenberg, J., "A Framework for Conferencing with the
              Session Initiation Protocol (SIP)", RFC 4353,
              February 2006.

   [RFC6230]  Boulton, C., Melanchuk, T., and S. McGlashan, "Media
              Control Channel Framework", RFC 6230, May 2011.

Authors' Addresses

   Ram Mohan Ravindranath
   Cisco Systems, Inc.
   Cessna Business Park,
   Kadabeesanahalli Village, Varthur Hobli,
   Sarjapur-Marathahalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: rmohanr@cisco.com

   Parthasarathi Ravindran
   Nokia Siemens Networks
   Manyata Embassy business Park
   Bangalore, Karnataka  560045
   India

   Email: partha@parthasarathi.co.in

   Paul Kyzivat
   Huawei
   Hudson, MA
   USA

   Email: pkyzivat@alum.mit.edu