RFC 8068

Session Initiation Protocol (SIP) Recording Call Flows

📅 published February 2017, from ietf

RFC 8068: Session Initiation Protocol (SIP) Recording Call Flows 🎀

Okay bestie, let's get into this one. It's RFC 8068, published in February 2017 by the IETF as an Informational doc (so not a Standards Track spec, just helpful reading 📖). The ISSN is 2070-1721 🧚

The authors are R. Ravindranath from Cisco Systems, Inc. 💙, P. Ravindran from Nokia Networks 🩷, and P. Kyzivat from Huawei 💜. Three companies, one doc, very collab energy 🫶

Abstract ✨

Okay so session recording is a huge deal in places like call centers and financial trading orgs 💼. In some of these environments, every single call has to be recorded for regulatory, compliance, and consumer-protection reasons. Lowkey intense 💀

Recording usually works by sending a copy of a media stream to a recording device 🎙️. This doc lists call flows with metadata snapshots sent from a Session Recording Client (SRC) to a Session Recording Server (SRS). Main character energy 👑

Status of This Memo 📝

Real talk, this document is not an Internet Standards Track specification. It's published just for informational purposes 🌸

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🤝. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 if you want the deets 🔍

For the current status, errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc8068 🦋

Copyright Notice 💅

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please read them carefully, because they spell out your rights and restrictions for this doc 📜. Any Code Components pulled from this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license ⚖️

Table of Contents 🗺️

   1. Overview ........................................................3
   2. Terminology .....................................................3
   3. Metadata XML Instances ..........................................3
      3.1. Sample Call Flow ...........................................3
      3.2. Call Scenarios with SRC Recording Streams without Mixing ...5
           3.2.1. Example 1: Basic Call ...............................5
           3.2.2. Example 2: Hold/Resume ..............................9
           3.2.3. Example 3:Call Transfer (RE-INVITE and
                  REFER Based) .......................................12
           3.2.4. Example 4: Call Disconnect .........................19
      3.3. Call Scenarios with SRC Recording Streams by Mixing .......20
           3.3.1. Example 1: Basic Call with SRC Mixing Streams ......20
           3.3.2. Example 2: Hold/Resume with SRC Recording
                  by Mixing Streams ..................................23
           3.3.3. Example 3: Metadata Snapshot of
                  Joining/Dropping of a ..............................25
           3.3.4. Example 4: Call Disconnect .........................28
      3.4. Call Scenarios with Persistent RS between SRC and SRS .....28
           3.4.1. Example 1: Metadata Snapshot during CS
                  Disconnect with ....................................29
      3.5. Turret-Case: Multiple CS into Single RS with Mixed
           Stream ....................................................30
   4. Security Considerations ........................................32
   5. IANA Considerations ............................................32
   6. References .....................................................33
      6.1. Normative References ......................................33
      6.2. Informative References ....................................33
   Acknowledgements ..................................................34
   Authors' Addresses ................................................34

1. Overview 🌈

Session recording is a critical requirement in tons of comms environments, like call centers and financial trading orgs 📞. In some of these, all calls must be recorded for regulatory, compliance, and consumer-protection reasons. Non-negotiable vibes 😤

Recording a session usually means sending a copy of a media stream to a recording device 🎧. [RFC7865] is all about the recording metadata that describes the Communication Session (CS) 💖. This doc gives a few examples and shows the metadata snapshots sent from a Session Recording Client (SRC) to a Session Recording Server (SRS) 🧚

To keep things simple, we're not showing entire Session Initiation Protocol (SIP) [RFC3261] messages. Instead you get snippets of the SIP and Session Description Protocol (SDP) [RFC4566] messages, plus the XML metadata snapshot 🍓

2. Terminology 📚

The terms in this doc are defined in [RFC7865] and [RFC6341]. No new definitions are introduced here, so no new vocab to memorize 🙌

3. Metadata XML Instances 🎀

The subsections below have examples of the metadata snapshot sent from the SRC to the SRS 💜

3.1. Sample Call Flow 🦋

This is a sample call flow where the SRC sets up a Recording Session (RS) towards the SRS. In this example, the SRC could be part of any of the architectures described in Section 3 of [RFC7245]. It's giving architecture options 🏗️

Figure 1: Sample Call Flow between SRC and SRS

               SRC                                                   SRS
               |                                                     |
               |(1) INVITE (metadata snapshot)   F1                  |
               |---------------------------------------------------->|
               |                            200 OK                   |
               |<----------------------------------------------------|
               |(3) ACK                                              |
               |---------------------------------------------------->|
               |(4) RTP                                              |
               |====================================================>|
               |====================================================>|
               |====================================================>|
               |====================================================>|
               |(5) UPDATE/RE-INVITE (metadata update 1)     F2      |
               |---------------------------------------------------->|
               |                      200 OK                         |
               |<----------------------------------------------------|
               | ................................................... |
               | ................................................... |
               |                                                     |
               |====================================================>|
               |====================================================>|
               |(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1      |
               |---------------------------------------------------->|
               |                       200 OK                        |
               |<----------------------------------------------------|

For simplicity, ACKs to RE-INVITES and BYEs aren't shown 🙈. The next sections describe the metadata snapshot the SRC sends to the SRS for each transaction in that flow (F1 through Fn-1) ✨. There may be several UPDATES/RE-INVITES mid-call to show snapshots of different CS changes, so expect some plot twists 🎢

Depending on the architecture in Section 3 of [RFC7245], an SRC might be an endpoint, a B2BUA, part of the MEDIACTRL architecture, or the Conference focus. The later sections list some example metadata snapshots for three major categories 📋

The SRC recording unmixed streams to the SRS. This covers cases where the SRC is a SIP UA or B2BUA 🎯
The SRC recording mixed streams to the SRS. This covers cases where the SRC is part of the SIP conference model, as explained in [RFC4353] 🎶
The SRC having a persistent RS with the SRS 🔁
Special flows, like turret flows (used on financial trading floors to manage call activity). A trading turret is a specialized telephony key system with a highly distributed switching architecture that enables parallel processing of calls. Figure 6 in Section 4 of [RFC6341] covers the turret use case 💅

Heads up: only the examples where metadata changes get listed in each category. For some call flows the snapshots might be the same (like when an endpoint or B2BUA is the SRC), and the text before the example will say so 👀

3.2.2. Example 2: Hold/Resume ☎️

okay so Alice and Bob are on a call, which is the CS, and an RS gets created for recording just like in example 1 🎀. Then Bob puts Alice on hold and un-holds her, all inside the same CS. The send and recv XML elements inside a participantstreamassoc are how you show whether a participant is contributing to a media stream 💅. SRC doesn't resend everything every time. It only sends a snapshot with the XML elements that actually changed ✨

During hold 🌸

Metadata snapshot for CS hold:

RE-INVITE SRC-------------------->SRS

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

--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....

--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session

<?xml version="1.0" encoding="UTF-8"?>
  <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
    <datamode>partial</datamode>
      <participantstreamassoc
       participant_id="srfBElmCRp2QB23b7Mpk0w==">
       <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
       <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
      </participantstreamassoc>
      <participantstreamassoc
       participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
        <send>8zc6e0lYTlWIINA6GR+3ag==</send>
        <send>EiXGlc+4TruqqoDaNE76ag==</send>
       </participantstreamassoc>
     </recording>

In the snippet above, Alice (participant_id srfBElmCRp2QB23b7Mpk0w==) is only receiving media streams and isn't sending any, which is why there's no send element for her 🙈. Bob (participant_id zSfPoSvdSDCmU3A3TRDxAw==) is the one sending media, but he isn't receiving any from Alice, so the recv element is missing for him in this one 🦋

During resume 💖

The snapshot now has send and recv elements for both Alice and Bob, which means they're both receiving and sending media again 🎉

Metadata snapshot for CS resume:

RE-INVITE SRC-------------------->SRS

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

--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session

<?xml version="1.0" encoding="UTF-8"?>
  <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
    <datamode>partial</datamode>
      <participantstreamassoc
       participant_id="srfBElmCRp2QB23b7Mpk0w==">
       <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
       <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
       <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
       <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
      </participantstreamassoc>
      <participantstreamassoc
       participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
        <send>8zc6e0lYTlWIINA6GR+3ag==</send>
        <send>EiXGlc+4TruqqoDaNE76ag==</send>
        <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
       <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
       </participantstreamassoc>
     </recording>

3.2.3. Example 3: Call Transfer (RE-INVITE and REFER Based) 🦋

Okay bestie, picture a basic call between Alice and Bob 📞✨. It's already connected, and SRC (a B2BUA acting as SRC, per Section 3.1.1 of [RFC7245]) has already sent over the snapshot from Example 1. Then Alice decides she wants to transfer the call 💅. Once the transfer is done, SRC sends the SRS a snapshot of the participant changes. In this transfer situation, Alice drops out after the transfer completes, Bob and Carol get connected, and SRC records the media between Bob and Carol 🎀. There are two flows that can happen here, so let's go through both.

Transfer within the same session (e.g., a RE-INVITE-based transfer): Alice drops out and Carol gets added to the same session 🥹. The session/group element doesn't change at all. The snapshot has a 'participantsessassoc' XML element showing that Alice has disassociated from the CS. There's also a new 'participant' XML element for Carol, mapped to the same RS SDP stream that was used for Alice's stream earlier 🌸. Then SRC sends a new 'sipSessionID' XML element with UUID tuples that match Bob and Carol 💜. Note that one half of the session ID, the part that belongs to Bob, stays the same ✨.

Metadata snapshot for INVITE based transfer in CS:

RE-INVITE SRC-------------------->SRS

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

--foobar
Content-Type: application/SDP
...
m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
    <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
           <datamode>partial</datamode>
            <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
         <sipSessionID>3363127f0d084c10876dddd4f8e5eeb9
         ;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID>
      </session>
       <participant
          participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
          <nameID aor="sip:carol@example.com">
           <name xml:lang="it">Carol</name>
         </nameID>
       </participant>
       <participantsessionassoc
          participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
          session_id="hVpd7YQgRW2nD22h7q60JQ==">
          <associate-time>2013-12-16T23:41:07Z</associate-time>
       </participantsessionassoc>
       <participantsessionassoc
          participant_id="srfBElmCRp2QB23b7Mpk0w=="
          session_id="hVpd7YQgRW2nD22h7q60JQ==">
           <disassociate-time>2013-12-16T23:41:07Z</disassociate-time>
        </participantsessionassoc>
        <participantstreamassoc
           participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
          <send>8zc6e0lYTlWIINA6GR+3ag==</send>
          <send>EiXGlc+4TruqqoDaNE76ag==</send>
          <recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
          <recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
       </participantstreamassoc>
       <participantstreamassoc
          participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
         <send>60JAJm9UTvik0Ltlih/Gzw==</send>
         <send>AcR5FUd3Edi8cACQJy/3JQ==</send>
         <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
         <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
         <associate-time>2013-12-16T23:42:07Z</associate-time>
       </participantstreamassoc>
  </recording>

Transfer with a new session (e.g., REFER-based transfer): here a brand new session (CS) gets created, and it's gotta be part of the same CS-group (SRC takes care of that) 🧚.

The SRC first sends an optional snapshot showing that the participant has left the old CS 🍓. SRC can also skip that and just send an INVITE with a new 'session' XML element, which implicitly tells the SRS that the participants are now part of a different CS, with no disassociation sent for the old one. In this example, SRC uses the same RS. If SRC wants a new RS instead, it tears down the current RS with normal SIP procedures (BYE) and metadata, just like in example 4 💫.

Metadata snapshot for REFER based transfer in CS:

RE-INVITE SRC-------------------->SRS

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

--foobar
Content-Type: application/SDP
...
m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....

--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session

        <?xml version="1.0" encoding="UTF-8"?>
    <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
           <datamode>partial</datamode>
       <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
         <stop-time>2010-12-16T23:41:07Z</stop-time>
       </session>
       <participantsessionassoc
          participant_id="srfBElmCRp2QB23b7Mpk0w=="
          session_id="hVpd7YQgRW2nD22h7q60JQ==">
           <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
        </participantsessionassoc>
       <participantsessionassoc
          participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
          session_id="hVpd7YQgRW2nD22h7q60JQ==">
          <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
        </participantsessionassoc>
  </recording>

In the snapshot above, the 'participantsessionassoc' XML element is optional. A 'session' XML element with a 'stop-time' XML element already implies that everyone associated with that session has been disassociated 🙈.

Then SRC sends another snapshot to show the participant change from the REFER and the new session info after the transfer 🎉. In this example, it's assumed that SRC keeps using the same RS to keep recording the call. The 'sipSessionID' XML element in this metadata snapshot now lists Bob and Carol as the (local, remote) UUID pair 💖.

Metadata snapshot for REFER based transfer in CS:

RE-INVITE SRC-------------------->SRS

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

--foobar
Content-Type: application/SDP
...
m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....

--foobar
Content-Type: application/rs-metadata
<?xml version="1.0" encoding="UTF-8"?>
    <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
           <datamode>complete</datamode>
       <session session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
         <sipSessionID>3363127f0d084c10876dddd4f8e5eeb9
         ;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID>
         <start-time>2010-12-16T23:41:07Z</start-time>
       </session>
       <participant
           participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
           <nameID aor="sip:Bob@biloxy.com"/>
        </participant>
        <participant
          participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
          <nameID aor="sip:carol@example.com"/>
       </participant>
        <stream stream_id="60JAJm9UTvik0Ltlih/Gzw=="
           session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
           <label>96</label>
       </stream>
       <stream stream_id="AcR5FUd3Edi8cACQJy/3JQ=="
           session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
           <label>97</label>
       </stream>
       <stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
           session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
           <label>98</label>
       </stream>
       <stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
           session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
           <label>99</label>
       </stream>
       <participantsessionassoc
           participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
           session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
           <associate-time>2010-12-16T23:32:03Z</associate-time>
        </participantsessionassoc>
       <participantsessionassoc
          participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
          session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
        <associate-time>2010-12-16T23:41:07Z</associate-time>
       </participantsessionassoc>
       <participantstreamassoc
           participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
         <send>8zc6e0lYTlWIINA6GR+3ag==</send>
         <send>EiXGlc+4TruqqoDaNE76ag==</send>
         <recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
         <recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
       </participantstreamassoc>
       <participantstreamassoc
          participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
        <send>60JAJm9UTvik0Ltlih/Gzw==</send>
        <send>AcR5FUd3Edi8cACQJy/3JQ==</send>
        <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
        <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
        </participantstreamassoc>
  </recording>

3.2.4. Example 4: Call Disconnect 💔✨

okay bestie, this one shows a snapshot of metadata that the SRC sends to the SRS when a CS with Alice and Bob as participants gets disconnected 📞💅 the whole flow is basically one BYE with a metadata snapshot attached, and the SRS replies with a 200 OK 🫶

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

Metadata snapshot for a CS disconnect:

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

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

--foobar
Content-Type: application/rs-metadata
<?xml version="1.0" encoding="UTF-8"?>
    <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
           <datamode>partial</datamode>
       <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
          <stop-time>2010-12-16T23:41:07Z</stop-time>
       </session>
       <participantsessionassoc
          participant_id="srfBElmCRp2QB23b7Mpk0w=="
          session_id="hVpd7YQgRW2nD22h7q60JQ==">
         <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
        </participantsessionassoc>

       <participantsessionassoc
          participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
         session_id="hVpd7YQgRW2nD22h7q60JQ==">
          <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
        </participantsessionassoc>
   </recording>

3.3. Call Scenarios with SRC Recording Streams by Mixing 🌈

okay so this section walks through a few example call flows where the SRC might be part of a conference model, either as the focus or as a participant in the conference, like we covered in Section 3.1.5 of [RFC7245] 🎪 the SRS here can be a SIP User Agent (UA) or an entity that's part of the MEDIACTRL architecture. also, the disconnect case isn't shown, because the metadata snapshot is the same as the non-mixing one, so no need to repeat it 🙈

3.3.1. Example 1: Basic Call with SRC Mixing Streams 🎀

this is a basic call between two participants, Alice and Bob, who are both part of one CS. each participant calls into a conference server (say, a Multipoint Control Unit (MCU)) to join one of the many conferences hosted on or managed by that server 📱 media streams sent by each participant get received by everyone else in the conference, which is so iconic 👑 below is the initial snapshot the SRC sends in the INVITE to the SRS, with all the metadata. to keep things simple, only snippets of SIP/SDP are shown. in this example, the SRC records each participant's streams to the SRS by mixing them. the SRC here is part of the conference model described in Section 3 of [RFC7245] as a focus, and it does the mixing. the SRC isn't a participant by itself, so it doesn't contribute any media 🦋

Metadata snapshot with the SRC mixing streams to the SRS:

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

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

--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly

....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session

<?xml version="1.0" encoding="UTF-8"?>
    <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
           <datamode>complete</datamode>
      <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
         <sipSessionID>fa3b60f27e91441e84c55a9a0095f075
          ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
          <sipSessionID>ca718e1430474b5485a53aa5d0bea45e
          ;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID>
          <start-time>2010-12-16T23:41:07Z</start-time>
      </session>
       <participant
          participant_id="srfBElmCRp2QB23b7Mpk0w==">
         <nameID aor="sip:alice@atlanta.com">
          <name xml:lang="it">Alice</name>
         </nameID>

       </participant>
       <participant
           participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
           <nameID aor="sip:bob@biloxy.com">
            <name xml:lang="it">Bob</name>
         </nameID>
       </participant>
       <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
           session_id="hVpd7YQgRW2nD22h7q60JQ==">
           <label>96</label>
       </stream>
       <participantsessionassoc
          participant_id="srfBElmCRp2QB23b7Mpk0w=="
          session_id="hVpd7YQgRW2nD22h7q60JQ==">
        <associate-time>2010-12-16T23:41:07Z</associate-time>
       </participantsessionassoc>
       <participantsessionassoc
           participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
    session_id="hVpd7YQgRW2nD22h7q60JQ==">
          <associate-time>2010-12-16T23:41:07Z</associate-time>
       </participantsessionassoc>
       <participantstreamassoc
          participant_id="srfBElmCRp2QB23b7Mpk0w==">
          <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
          <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
       </participantstreamassoc>

       <participantstreamassoc
           participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
         <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
         <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
       </participantstreamassoc>
  </recording>

In the above example there are two participants, Alice and Bob, in the conference. among other things, the SRC sends the Session-ID in the metadata snapshot 🧚 there are two Session-IDs here: one that matches the SIP session between Alice and the Conference focus, and another for the SIP session between Bob and the Conference focus. in this use case, since Alice and Bob each call into the conference, those two Session-IDs are different ✨

3.3.2. Example 2: Hold/Resume with SRC Recording by Mixing Streams 🦋

this is a continuation of example 1 (the basic call with SRC mixing streams) 💜 a call between Alice and Bob gets set up and an RS is created for recording, as in example 5. then one of the participants, Bob, puts Alice on hold, and then resumes, all within the same CS 📞 the send and recv XML elements of a participant XML element are used to show whether or not a participant is contributing to a media stream. the metadata snapshot looks like this:

During hold

Metadata snapshot when a CS participant goes on hold and the SRC is mixing the streams:

RE-INVITE SRC --------------> SRS

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

--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly

....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
    <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
           <datamode>partial</datamode>
           <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
           session_id="hVpd7YQgRW2nD22h7q60JQ==">
           <label>96</label>
       </stream>
       <participantstreamassoc
          participant_id="srfBElmCRp2QB23b7Mpk0w==">
           <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
       </participantstreamassoc>
       <participantstreamassoc
           participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
         <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
       </participantstreamassoc>
  </recording>

During resumption, the SRC sends the snapshot shown below to the SRS ✨

Metadata snapshot when a CS participant resumes and the SRC is mixing the streams:

RE-INVITE SRC --------------> SRS

INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
    ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly

....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session

<?xml version="1.0" encoding="UTF-8"?>
    <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
           <datamode>partial</datamode>
           <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
           session_id="hVpd7YQgRW2nD22h7q60JQ==">
           <label>96</label>
       </stream>
      <participantstreamassoc
          participant_id="srfBElmCRp2QB23b7Mpk0w==">
          <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
          <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
       </participantstreamassoc>
       <participantstreamassoc
           participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
         <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
        <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
       </participantstreamassoc>
  </recording>

3.3.3. Example 3: Metadata Snapshot of Joining/Dropping of a Participant to a Session ✨

okay so in a conference, people can join and drop the session literally any time 🦋 Here's a snapshot the SRC sends to the SRS for that. The SRC can be a focus or a participant in the conference 💅 If it's a participant, it may figure out the metadata it needs by subscribing to a conference event package [RFC4575] 🧚 Say Alice and Bob are already in the call and Carol joins. The SRC then sends this snapshot, flagging the new participant 🎀

Metadata snapshot for a new participant joining CS:

RE-INVITE SRC --------------> SRS

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

--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly

....

--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session

<?xml version="1.0" encoding="UTF-8"?>
    <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
        <datamode>partial</datamode>
        <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
            <sipSessionID>fa3b60f27e91441e84c55a9a0095f075
            ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
            <sipSessionID>ca718e1430474b5485a53aa5d0bea45e
            ;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID>
            <sipSessionID>497c0f13929643b4a16858e2a3885edc
            ;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID>
        </session>
        <participant
            participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
            <nameID aor="sip:carol@example.com">
                <name xml:lang="it">Carol</name>

            </nameID>
        </participant>
        <participantsessionassoc
            participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
            session_id="hVpd7YQgRW2nD22h7q60JQ==">
            <associate-time>2013-12-16T23:41:07Z</associate-time>
        </participantsessionassoc>
        <participantstreamassoc
            participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
            <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
            <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
        </participantstreamassoc>
    </recording>

After a bit, Alice drops out of the conference 😭 The SRC makes a fresh snapshot showing Alice disassociating from the session 💜

Metadata snapshot for a participant dropping from CS:

RE-INVITE SRC --------------> SRS

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

--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....

--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session

<?xml version="1.0" encoding="UTF-8"?>
    <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
        <datamode>partial</datamode>
        <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
            <sipSessionID>ca718e1430474b5485a53aa5d0bea45e
            ;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID>
            <sipSessionID>497c0f13929643b4a16858e2a3885edc
            ;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID>
        </session>
        <participantsessionassoc
            participant_id="srfBElmCRp2QB23b7Mpk0w=="
            session_id="hVpd7YQgRW2nD22h7q60JQ==">
            <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
        </participantsessionassoc>
    </recording>

3.3.4. Example 4: Call Disconnect 📞

when a CS gets disconnected, the SRC sends a BYE 💅 It comes with a snapshot that has the session stop time and the participant disassociation times 🫶 The snapshot looks the same as the one in Section 3.2.4 🌸

3.4. Call Scenarios with Persistent RS between SRC and SRS 🌈

this section is about snapshots for when a persistent RS exists between the SRC and the SRS 🦋 The SRC can be a SIP UA or a B2BUA, or it can be part of a conference model as either the focus or a participant 👑 The SRS can be a SIP UA or an entity that's part of the MEDIACTRL architecture 🧚 Except in the disconnect case, the snapshot stays the same as in the earlier sections ✨

3.4.1. Example 1: Metadata Snapshot during CS Disconnect with Persistent RS between SRC and SRS 💖

Metadata snapshot for a CS disconnect with a persistent RS:

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

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

--foobar
Content-Type: application/rs-metadata

<?xml version="1.0" encoding="UTF-8"?>
    <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
        <datamode>partial</datamode>
        <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
            <stop-time>2010-12-16T23:41:07Z</stop-time>
        </session>
        <participantsessionassoc
            participant_id="srfBElmCRp2QB23b7Mpk0w=="
            session_id="hVpd7YQgRW2nD22h7q60JQ==">
            <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
        </participantsessionassoc>

        <participantsessionassoc
            participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
            session_id="hVpd7YQgRW2nD22h7q60JQ==">
            <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
        </participantsessionassoc>
    </recording>

3.5. Turret-Case: Multiple CS into Single RS with Mixed Stream 🎙️

okay trading floors are chaotic, so the goal here is to save storage and recording resources. 💅 It may be preferable to mix multiple concurrent calls (each call is one CS) on different handsets or speakers on the same turret into a single RS. So the media in each CS gets mixed and recorded as one media stream, and several CSs end up recorded in one RS from an SRC to an SRS. ✨

Say there are two CSs, [CS1 and CS2]. Assume mixing happens in each of them, and both get recorded as part of a single RS from a single SRC, which is in both CSs. There are three possibilities here 👀:

CS1 and CS2 use the same focus for mixing, and that focus is also acting as SRC in each of the CSs.
One CS (e.g. CS1) SRC is the focus and the other CS (e.g. CS2), SRC is just one of the participants of the conference.
In both CS1 and CS2, the SRC is just a participant of conference.

The following example shows the first possibility, where CS1 and CS2 share the same focus for mixing and that focus is also the SRC in each CS. Let's gooo 🚀

Metadata snapshot with two CSs recorded as part of the same RS:

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

INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
 ;remote=00000000000000000000000000000000
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...

And here's the metadata snapshot, which is basically the full group chat of who's in what 🫶:

<?xml version="1.0" encoding="UTF-8"?>
    <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
           <datamode>complete</datamode>
        <group group_id="7+OTCyoxTmqmqyA/1weDAg==">
               <associate-time>2010-12-16T23:41:07Z</associate-time>
       </group>
       <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
          <sipSessionID>fa3b60f27e91441e84c55a9a0095f075
          ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
          <sipSessionID>ca718e1430474b5485a53aa5d0bea45e
          ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
          <sipSessionID>497c0f13929643b4a16858e2a3885edc
          ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
          <group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
          <start-time>2010-12-16T23:41:07Z</start-time>
       </session>
      <session session_id="e6370VVGEeWAG6886p18uA==">
         <sipSessionID>ae10731ca50343a5aaae2dd0904a65de
         ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
         <sipSessionID>33c77aac7deb414cbc8c10f363fccb71
         ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
         <sipSessionID>fd6932e9e5fc489fae2d5b3779723b7e
        ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
        <group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
        <start-time>2010-12-16T23:43:07Z</start-time>
       </session>
       <participant
          participant_id="srfBElmCRp2QB23b7Mpk0w==">
         <nameID aor="sip:alice@atlanta.com">
          <name xml:lang="it">Alice</name>
         </nameID>
       </participant>
       <participant
           participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
           <nameID aor="sip:Bob@biloxy.com">
            <name xml:lang="it">Bob</name>
         </nameID>
       </participant>
       <participant
          participant_id="EiXGlc+4TruqqoDaNE76ag==">
         <nameID aor="sip:Carol@example.com">
          <name xml:lang="it">Carol</name>
         </nameID>
       </participant>
       <stream stream_id="UAAMm5GRQKSCMVvLyl4rFw=="
           session_id="hVpd7YQgRW2nD22h7q60JQ==">
           <label>96</label>
       </stream>
       <participantsessionassoc
          participant_id="srfBElmCRp2QB23b7Mpk0w=="
          session_id="hVpd7YQgRW2nD22h7q60JQ==">
        <associate-time>2010-12-16T23:41:07Z</associate-time>
       </participantsessionassoc>
       <participantsessionassoc
           participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
           session_id="hVpd7YQgRW2nD22h7q60JQ==">
          <associate-time>2010-12-16T23:41:07Z</associate-time>
       </participantsessionassoc>
       <participantsessionassoc
           participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
           session_id="e6370VVGEeWAG6886p18uA==">
          <associate-time>2010-12-16T23:43:07Z</associate-time>
       </participantsessionassoc>
       <participantsessionassoc
           participant_id="EiXGlc+4TruqqoDaNE76ag=="
           session_id="e6370VVGEeWAG6886p18uA==">
          <associate-time>2010-12-16T23:43:07Z</associate-time>
       </participantsessionassoc>

       <participantstreamassoc
          participant_id="srfBElmCRp2QB23b7Mpk0w==">
          <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
          <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
       </participantstreamassoc>
       <participantstreamassoc
           participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
         <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
         <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
       </participantstreamassoc>
       <participantstreamassoc
           participant_id="EiXGlc+4TruqqoDaNE76ag==">
         <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
         <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
       </participantstreamassoc>
  </recording>

4. Security Considerations 🔐

Okay, this part is super serious, no cap. 🚨 Security and privacy considerations mentioned in [RFC7865] and [RFC7866] have to be followed by the SRC and the SRS when they set up RS SIP dialogs and send metadata. Like, non-negotiable. 💀🫶

5. IANA Considerations 📋

This document does not require any IANA actions. Easy peasy, nothing to register here 🌸

6. References ✨

6.1. Normative References

[RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain, "Use Cases and Requirements for SIP-Based Media Recording (SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011, <http://www.rfc-editor.org/info/rfc6341>.
[RFC7865] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session Initiation Protocol (SIP) Recording Metadata", RFC 7865, DOI 10.17487/RFC7865, May 2016, <http://www.rfc-editor.org/info/rfc7865>.
[RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A. Hutton, "Session Recording Protocol", RFC 7866, DOI 10.17487/RFC7866, May 2016, <http://www.rfc-editor.org/info/rfc7866>.
[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, "An Architecture for Media Recording Using the Session Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 2014, <http://www.rfc-editor.org/info/rfc7245>.

6.2. Informative References

[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, DOI 10.17487/RFC4575, August 2006, <http://www.rfc-editor.org/info/rfc4575>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, <http://www.rfc-editor.org/info/rfc4353>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.

Acknowledgements 🙏

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

Thanks to Alissa Cooper, Stephen Farrell, Kathleen Moriarty, Suresh Krishnan, Benoit Claise, Carlos Pignataro, Dan Romascanu, and Derek Atkins for their feedback and comments during IESG reviews. You all are iconic 🌈👑

Authors' Addresses 🦋

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

Email: rmohanr@cisco.com

Parthasarathi Ravindran
Nokia Networks
Bangalore, Karnataka
India

Email: partha@parthasarathi.co.in

Paul Kyzivat
Huawei
Hudson, MA
United States of America

Email: pkyzivat@alum.mit.edu

that's the whole thing bestie 💜 The authors are literally the reason this works, so go give them a follow 🧚✨

📦 where this page comes from

ietf: rfc8068 2017-02
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms