Session Initiation Protocol (SIP) Recording Call Flows

The following subsections have examples that contain the metadata snapshot sent from the SRC to the SRS.

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

| | 200 OK | |<----------------------------------------------------| |(3) ACK | |---------------------------------------------------->| |(4) RTP | |====================================================>| |====================================================>| |====================================================>| |====================================================>| |(5) UPDATE/RE-INVITE (metadata update 1) F2 | |---------------------------------------------------->| | 200 OK | |<----------------------------------------------------| | ................................................... | | ................................................... | | | |====================================================>| |====================================================>| |(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 | |---------------------------------------------------->| | 200 OK | |<----------------------------------------------------| ]]> For the sake of simplicity, ACKs to RE-INVITES and BYEs are not shown. The subsequent sections describe the snapshot of metadata sent from the SRC to the SRS for each of the above transactions (F1 ... Fn-1). There may be multiple UPDATES/RE-INVITES mid call to indicate snapshots of different CS changes. Depending on the architecture described in Section 3 of , an SRC may be an endpoint, a B2BUA, or part of the MEDIACTRL architecture or the Conference focus. The subsequent sections in this document try to list some example metadata snapshots for three major categories. The SRC recording streams unmixed to the SRS. This includes cases where the SRC is a SIP UA or B2BUA. The SRC recording mixed streams to the SRS. This includes cases where the SRC is part of SIP conference model, as explained in . 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 that has a highly distributed switching architecture enabling parallel processing of calls. Figure 6 in Section 4 of has the turret use case. Note that only those examples where metadata changes are listed in each category. For some of the call flows, the snapshots may be the same (like in case of endpoint or B2BUA acting as SRC) and the same is mentioned in the text preceding the example.

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

Basic call between two participants, Alice and Bob, who are part of the same CS. In this use case, each participant sends two media streams (audio and video). Media streams sent by each participant are received by the other participant in this use case. In this example, the SRC is a B2BUA in the path between Alice and Bob, as described in Section 3.1.1 of . Below is the initial snapshot sent by SRC in the INVITE to SRS. This snapshot has the complete metadata. For the sake of simplicity, only snippets of SIP/SDP are shown. In this example, the SRCs records the streams of each participant to SRS without mixing.

2010-12-16T23:41:07Z

sip:alice@atlanta.com

FOO! bar ab30317f1a784dc48ff824d0d3715d86; remote=47755a9de7794ba387653f2099600ef2

7+OTCyoxTmqmqyA/1weDAg==

FOO! bar Alice FOO! bar Bob FOO! bar 96 97 98 99

2010-12-16T23:41:07Z

i1Pz3to5hGk8fuXl+PbwCw== UAAMm5GRQKSCMVvLyl4rFw== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== UAAMm5GRQKSCMVvLyl4rFw== i1Pz3to5hGk8fuXl+PbwCw== ]]>

A call between two participants Alice and Bob is established and an RS is created for recording, as in example 1. Bob puts Alice on hold and then resumes as part of the same CS. The 'send' and 'recv' XML elements of a 'participantstreamassoc' XML element is used to indicate whether or not a participant is contributing to a media stream. SRC sends a snapshot with only the changed XML elements. During hold

SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: 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.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 partial 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== ]]> In the above snippet, Alice with participant_id srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not send any media. The same is indicated by the absence of a 'send' XML element. On the other hand, Bob (participant_id zSfPoSvdSDCmU3A3TRDxAw==) would be sending media, but he does not receive any media from Alice; therefore, the 'recv' XML element is absent in this instance. During resume The snapshot now has 'send' and 'recv' XML elements for both Alice and Bob, indicating that both are receiving and sending media.

SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: 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.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 partial i1Pz3to5hGk8fuXl+PbwCw== UAAMm5GRQKSCMVvLyl4rFw== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== i1Pz3to5hGk8fuXl+PbwCw== UAAMm5GRQKSCMVvLyl4rFw== ]]>

A basic call between two participants, Alice and Bob, is connected, and SRC (a B2BUA acting as SRC as per Section 3.1.1 of ) has sent a snapshot as described in example 1. Transfer is initiated by one of the participants (Alice). After the transfer is completed, the SRC sends a snapshot of the participant changes to the SRS. In this transfer scenario, Alice drops out after transfer is completed, Bob and Carol get connected, and recording of media between Bob and Carol is done by the SRC. There are two flows that can happen here as described below. Transfer within the same session (e.g., a RE-INVITE-based transfer): Alice drops out and Carol is added to the same session. No change to the session/group element is made. A 'participantsessassoc' XML element indicating that Alice has disassociated from the CS will be present in the snapshot. A new 'participant' XML element representing Carol with mapping to the same RS SDP stream used for mapping earlier Alice's stream is sent in the snapshot. A new 'sipSessionID' XML element that has Universally Unique Identifier (UUID) tuples and that corresponds to Bob and Carol is sent in the snapshot from the SRC to the SRS. Note that one half of the session ID, that which corresponds to Bob, remains the same.

2013-12-16T23:41:07Z

8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 60JAJm9UTvik0Ltlih/Gzw== AcR5FUd3Edi8cACQJy/3JQ== 60JAJm9UTvik0Ltlih/Gzw== AcR5FUd3Edi8cACQJy/3JQ== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag==

2013-12-16T23:42:07Z

]]> Transfer with a new session (e.g., REFER-based transfer): in this case, a new session (CS) is created and shall be part of same CS-group (done by the SRC). The SRC first sends an *optional* snapshot indicating disassociation of the participant from the old CS. An SRC may choose to just send an INVITE with a new 'session' XML element to implicitly indicate that the participants are now part of a different CS without sending disassociation from the old CS. In this example, the SRC uses the same RS. In case the SRC wishes to use a new RS, it will tear down the current RS using normal SIP procedures (BYE) with metadata, as in example 4.

2010-12-16T23:41:07Z

]]> In the above snapshot, the 'participantsessionassoc' XML element is optional as indicating a 'session' XML element with a 'stop-time' XML element implicitly means that all the participants associated with that session have been disassociated. The SRC sends another snapshot to indicate the participant change (due to REFER) and new session information after transfer. In this example, it is assumed that the SRC uses the same RS to continue recording the call. The 'sipSessionID' XML element in the metadata snapshot now indicates Bob and Carol in the (local, remote) UUID pair.

2010-12-16T23:41:07Z

96 97 98 99

2010-12-16T23:32:03Z

2010-12-16T23:41:07Z

8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== 60JAJm9UTvik0Ltlih/Gzw== AcR5FUd3Edi8cACQJy/3JQ== 60JAJm9UTvik0Ltlih/Gzw== AcR5FUd3Edi8cACQJy/3JQ== 8zc6e0lYTlWIINA6GR+3ag== EiXGlc+4TruqqoDaNE76ag== ]]>

This example shows a snapshot of metadata sent by the SRC to the SRS when a CS with Alice and Bob as participants is disconnected.

| | 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: ;tag=35e195d2-947d-4585-946f-09839247 To: 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.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/rs-metadata partial

2010-12-16T23:41:07Z

]]>

This section describes a few example call flows where the SRC may be part of conference model either as focus or a participant in conference as explained in Section 3.1.5 of . The SRS here can be a SIP User Agent (UA) or an entity part of the MEDIACTRL architecture. Note that the disconnect case is not shown since the metadata snapshot will be same as for a non-mixing case.

A basic call between two participants, Alice and Bob, who are part of one CS. In this use case, each participant calls into a conference server (say, a Multipoint Control Unit (MCU)) to attend one of many conferences hosted on or managed by that server. Media streams sent by each participant are received by all the other participants in the conference. Below is the initial snapshot sent by the SRC in the INVITE to the SRS that has the complete metadata. For the sake of simplicity, only snippets of SIP/SDP are shown. The SRC records the streams of each participant to SRS by mixing in this example. The SRC here is part of conference model described in Section 3 of as a focus and does mixing. The SRC here is not a participant by itself and hence it does not contribute to media.

2010-12-16T23:41:07Z

Alice Bob 96

2010-12-16T23:41:07Z

i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== ]]> In the above example, there are two participants, Alice and Bob, in the conference. Among other things, the SRC sends Session-ID in the metadata snapshot. There are two Session-IDs here: one that corresponds to the SIP session between Alice and the Conference focus and the other for the SIP session between Bob and the Conference focus. In this use case, since Alice and Bob call into the conference, these Session-IDs are different.

This is the continuation of example 1 (basic call with SRC mixing streams). A call between two participants, Alice and Bob, is established and an RS is created for recording, as in example 5. One of the participants, Bob, puts Alice on hold, and then resumes as part of the same CS. The 'send' and 'recv' XML elements of a 'participant' XML element are used to indicate whether or not a participant is contributing to a media stream. The metadata snapshot is represented below: During hold

In a conference model, participants can join and drop a session any time during the session. Below is a snapshot sent from the SRC to the SRS in this case. Note the SRC here can be a focus or a participant in the conference. In the case where the SRC is a participant, it may learn the information required for metadata by subscribing to a conference event package . Assume Alice and Bob were in the conference and a third participant (Carol) joins, then the SRC sends the below snapshot with the indication of new participant.

2013-12-16T23:41:07Z

i1Pz3to5hGk8fuXl+PbwCw== i1Pz3to5hGk8fuXl+PbwCw== ]]> After some time, Alice drops from the conference. The SRC generates a new snapshot showing Alice disassociating from the session.

2010-12-16T23:41:07Z

]]>

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

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

SRS INVITE sip:2001@example.com SIP/2.0 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 From: ;tag=35e195d2-947d-4585-946f-09839247 To: 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.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] --foobar Content-Type: application/rs-metadata partial

2010-12-16T23:41:07Z

]]>

In trading-floor environments, in order to minimize storage and recording system resources, it may be preferable to mix multiple concurrent calls (each call is one CS) on different handsets/speakers on the same turret into a single RS. This would mean media in each CS is mixed and recorded as part of single media stream, and multiple such CSs are recording in one RS from an SRC to an SRS. Taking an example where there are two CSs [CS1 and CS2]: assume mixing is done in each of these CSs and both these CSs are recorded as part of single RS from a single SRC, which is part of both the CSs. There are three possibilities here: 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 use the same focus for mixing, and that focus is also acting as SRC in each of the CSs.

SRS INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: ;tag=35e195d2-947d-4585-946f-09839247 To: 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 ... complete

2010-12-16T23:41:07Z

fa3b60f27e91441e84c55a9a0095f075 ;remote=a358d2b81a444a8c8fb05950cef331e7 ca718e1430474b5485a53aa5d0bea45e ;remote=a358d2b81a444a8c8fb05950cef331e7 497c0f13929643b4a16858e2a3885edc ;remote=a358d2b81a444a8c8fb05950cef331e7

7+OTCyoxTmqmqyA/1weDAg==

2010-12-16T23:41:07Z

ae10731ca50343a5aaae2dd0904a65de ;remote=a358d2b81a444a8c8fb05950cef331e7 33c77aac7deb414cbc8c10f363fccb71 ;remote=a358d2b81a444a8c8fb05950cef331e7 fd6932e9e5fc489fae2d5b3779723b7e ;remote=a358d2b81a444a8c8fb05950cef331e7

7+OTCyoxTmqmqyA/1weDAg==

2010-12-16T23:43:07Z

Alice Bob Carol 96

2010-12-16T23:41:07Z

2010-12-16T23:43:07Z

UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== ]]>