draft-ietf-siprec-callflows-08.txt   rfc8068.txt 
SIPREC Ram. Ravindranath Internet Engineering Task Force (IETF) R. Ravindranath
Internet-Draft Cisco Systems, Inc. Request for Comments: 8068 Cisco Systems, Inc.
Intended status: Informational Parthasarathi. Ravindran Category: Informational P. Ravindran
Expires: June 22, 2017 Nokia Networks ISSN: 2070-1721 Nokia Networks
Paul. Kyzivat P. Kyzivat
Huawei Huawei
December 19, 2016 February 2017
Session Initiation Protocol (SIP) Recording Call Flows Session Initiation Protocol (SIP) Recording Call Flows
draft-ietf-siprec-callflows-08
Abstract Abstract
Session recording is a critical requirement in many communications Session recording is a critical requirement in many communications
environments, such as call centers and financial trading environments, such as call centers and financial trading
organizations. In some of these environments, all calls must be organizations. In some of these environments, all calls must be
recorded for regulatory, compliance, and consumer protection reasons. recorded for regulatory, compliance, and consumer-protection reasons.
The recording of a session is typically performed by sending a copy The recording of a session is typically performed by sending a copy
of a media stream to a recording device. This document lists call of a media stream to a recording device. This document lists call
flows with metadata snapshots sent from a Session Recording flows with metadata snapshots sent from a Session Recording Client
Client(SRC) to a Session Recording Server(SRS). (SRC) to a Session Recording Server (SRS).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on June 22, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8068.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Overview ........................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology .....................................................3
3. Metadata XML Instances . . . . . . . . . . . . . . . . . . . 3 3. Metadata XML Instances ..........................................3
3.1. Sample Call flow . . . . . . . . . . . . . . . . . . . . 3 3.1. Sample Call Flow ...........................................3
3.2. Call Scenarios with SRC recording streams without mixing 5 3.2. Call Scenarios with SRC Recording Streams without Mixing ...5
3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 5 3.2.1. Example 1: Basic Call ...............................5
3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . 8 3.2.2. Example 2: Hold/Resume ..............................9
3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 12 3.2.3. Example 3:Call Transfer (RE-INVITE and
3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . 18 REFER Based) .......................................12
3.3. Call Scenarios with SRC recording streams by mixing . . . 19 3.2.4. Example 4: Call Disconnect .........................19
3.3.1. Example 1: Basic call with SRC mixing streams . . . . 20 3.3. Call Scenarios with SRC Recording Streams by Mixing .......20
3.3.2. Example 2: Hold/resume with SRC recording by mixing 3.3.1. Example 1: Basic Call with SRC Mixing Streams ......20
streams . . . . . . . . . . . . . . . . . . . . . . . 22 3.3.2. Example 2: Hold/Resume with SRC Recording
3.3.3. Example 3: Metadata snapshot of joining/dropping of a by Mixing Streams ..................................23
participant to a session . . . . . . . . . . . . . . 24 3.3.3. Example 3: Metadata Snapshot of
3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . 27 Joining/Dropping of a ..............................25
3.4. Call scenarios with persistent RS between SRC and SRS . . 27 3.3.4. Example 4: Call Disconnect .........................28
3.4.1. Example 1: Metadata snapshot during CS disconnect 3.4. Call Scenarios with Persistent RS between SRC and SRS .....28
with persistent RS between SRC and SRS . . . . . . . 27 3.4.1. Example 1: Metadata Snapshot during CS
3.5. Turret-Case: Multiple CS into single RS with mixed stream 29 Disconnect with ....................................29
4. Security Considerations . . . . . . . . . . . . . . . . . . . 31 3.5. Turret-Case: Multiple CS into Single RS with Mixed
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 Stream ....................................................30
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 32 4. Security Considerations ........................................32
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 5. IANA Considerations ............................................32
7.1. Normative References . . . . . . . . . . . . . . . . . . 32 6. References .....................................................33
7.2. Informative References . . . . . . . . . . . . . . . . . 32 6.1. Normative References ......................................33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 6.2. Informative References ....................................33
Acknowledgements ..................................................34
Authors' Addresses ................................................34
1. Overview 1. Overview
Session recording is a critical requirement in many communications Session recording is a critical requirement in many communications
environments, such as call centers and financial trading environments, such as call centers and financial trading
organizations. In some of these environments, all calls must be organizations. In some of these environments, all calls must be
recorded for regulatory, compliance, and consumer protection reasons. recorded for regulatory, compliance, and consumer-protection reasons.
The recording of a session is typically performed by sending a copy The recording of a session is typically performed by sending a copy
of a media stream to a recording device. [RFC7865] focuses on the of a media stream to a recording device. [RFC7865] focuses on the
recording metadata which describes the Communication Session(CS). recording metadata that describes the Communication Session (CS).
This document lists few examples and shows the snapshots of metadata This document lists few examples and shows the snapshots of metadata
sent from a Session Recording Client(SRC) to Session Recording Server sent from a Session Recording Client (SRC) to Session Recording
(SRS). For the sake of simplicity the entire Session Initiation Server (SRS). For the sake of simplicity, the entire Session
Protocol (SIP) [RFC3261] messages are not shown, instead only Initiation Protocol (SIP) [RFC3261] messages are not shown, instead
snippets of the SIP and Session Description Protocol (SDP)[RFC4566] only snippets of the SIP and Session Description Protocol (SDP)
messages and the XML snapshot of metadata is shown. [RFC4566] messages and the XML snapshot of metadata is shown.
2. Terminology 2. Terminology
The terms used in this document are defined in [RFC7865] and The terms used in this document are defined in [RFC7865] and
[RFC6341]. No new definitions are introduced in this document. [RFC6341]. No new definitions are introduced in this document.
3. Metadata XML Instances 3. Metadata XML Instances
The following sub-sections have examples that contain the metadata The following subsections have examples that contain the metadata
snapshot sent from SRC to SRS. snapshot sent from the SRC to the SRS.
3.1. Sample Call flow 3.1. Sample Call Flow
The following is a sample call flow that shows the SRC establishing a The following is a sample call flow that shows the SRC establishing a
Recording Session(RS) towards the SRS. The SRC in this example could Recording Session (RS) towards the SRS. In this example, the SRC
be part of any one of the architectures described in section 3 of could be part of any one of the architectures described in Section 3
[RFC7245]. of [RFC7245].
Figure 1: Sample call flow between SRC and SRS Figure 1: Sample Call Flow between SRC and SRS
SRC SRS SRC SRS
| | | |
|(1) INVITE (metadata snapshot) F1 | |(1) INVITE (metadata snapshot) F1 |
|---------------------------------------------------->| |---------------------------------------------------->|
| 200 OK | | 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
|(3) ACK | |(3) ACK |
|---------------------------------------------------->| |---------------------------------------------------->|
|(4) RTP | |(4) RTP |
skipping to change at page 4, line 36 skipping to change at page 4, line 36
| | | |
|====================================================>| |====================================================>|
|====================================================>| |====================================================>|
|(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 | |(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 |
|---------------------------------------------------->| |---------------------------------------------------->|
| 200 OK | | 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
For the sake of simplicity, ACKs to RE-INVITES and BYEs are not For the sake of simplicity, ACKs to RE-INVITES and BYEs are not
shown. The subsequent sections describe the snapshot of metadata shown. The subsequent sections describe the snapshot of metadata
sent from SRC to SRS for each of the above transactions (F1 ... Fn- sent from the SRC to the SRS for each of the above transactions (F1
1). There may be multiple UPDATES/RE-INVITES mid call to indicate ... Fn-1). There may be multiple UPDATES/RE-INVITES mid call to
snapshots of different CS changes. Depending on the architecture indicate snapshots of different CS changes. Depending on the
described in section 3 of [RFC7245] an SRC may be an endpoint or architecture described in Section 3 of [RFC7245], an SRC may be an
Back-to-Back User Agent(B2BUA) or as part of MEDIACTRL or Conference endpoint, a B2BUA, or part of the MEDIACTRL architecture or the
focus. The subsequent sections in this document try to list some Conference focus. The subsequent sections in this document try to
example metadata snapshots for three major categories. list some example metadata snapshots for three major categories.
o SRC recording streams unmixed to SRS. This includes cases where o The SRC recording streams unmixed to the SRS. This includes cases
SRC is SIP UA or B2BUA. where the SRC is a SIP UA or B2BUA.
o SRC recording mixed streams to SRS. This includes cases where SRC o The SRC recording mixed streams to the SRS. This includes cases
is part of SIP conference model explained in [RFC4353]. where the SRC is part of SIP conference model, as explained in
[RFC4353].
o SRC having a persistent RS with SRS. o The SRC having a persistent RS with the SRS.
o Special flows like Turret flows (used on financial trading floors o Special flows like turret flows (used on financial trading floors
to manage call activity). A trading turret is a specialized to manage call activity). A trading turret is a specialized
telephony key system that has a highly distributed switching telephony key system that has a highly distributed switching
architecture enabling parallel processing of calls. Figure 6 in architecture enabling parallel processing of calls. Figure 6 in
Section 4 of [RFC6341] has the turret use-case. Section 4 of [RFC6341] has the turret use case.
Note that only those examples for which metadata changes are listed Note that only those examples where metadata changes are listed in
in each category. For some of the call flows the snapshots may be 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 same (like in case of endpoint or B2BUA acting as SRC) and the same
is mentioned in the text preceding the example. is mentioned in the text preceding the example.
3.2. Call Scenarios with SRC recording streams without mixing 3.2. Call Scenarios with SRC Recording Streams without Mixing
This section describes example flows where SRC can be a SIP-UA or This section describes example flows where SRC can be a SIP-UA or
B2BUA as described in section 3 of [RFC7245]. The SRS here can be a B2BUA as described in Section 3 of [RFC7245]. The SRS here can be a
SIP-UA or an entity part of MEDIACTRL architecture described in SIP-UA or an entity part of the MEDIACTRL architecture described in
section 3 of [RFC7245]. Section 3 of [RFC7245].
3.2.1. Example 1: Basic Call 3.2.1. Example 1: Basic Call
Basic call between two participants Alice and Bob who are part of the Basic call between two participants, Alice and Bob, who are part of
same CS. In this use case each participant sends two media the same CS. In this use case, each participant sends two media
streams(audio and video). Media streams sent by each participant are streams (audio and video). Media streams sent by each participant
received by the other participant in this use-case. In this example are received by the other participant in this use case. In this
the SRC is a B2BUA in the path between Alice and Bob as described in example, the SRC is a B2BUA in the path between Alice and Bob, as
section 3.1.1 of [RFC7245]. Below is the initial snapshot sent by described in Section 3.1.1 of [RFC7245]. Below is the initial
SRC in the INVITE to SRS. This snapshot has the complete metadata. snapshot sent by SRC in the INVITE to SRS. This snapshot has the
For the sake of simplicity only snippets of SIP/SDP are shown. In complete metadata. For the sake of simplicity, only snippets of SIP/
this example the SRCs records the streams of each participant to SRS SDP are shown. In this example, the SRCs records the streams of each
without mixing. participant to SRS without mixing.
Metadata snapshot for CS setup: Metadata snapshot for CS setup:
INVITE SRC --------------> SRS INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
skipping to change at page 8, line 31 skipping to change at page 9, line 4
<recv>EiXGlc+4TruqqoDaNE76ag==</recv> <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc> </participantstreamassoc>
<participantstreamassoc <participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send> <send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send> <send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
3.2.2. Example 2: Hold/Resume
3.2.2. Example 2: Hold/resume 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
A call between two participants Alice and Bob is established and a RS and then resumes as part of the same CS. The 'send' and 'recv' XML
is created for recording as in example 1. One of the participants elements of a 'participantstreamassoc' XML element is used to
Bob puts Alice on hold and then resumes as part of the same CS. The indicate whether or not a participant is contributing to a media
'send' and 'recv' XML elements of a 'participantstreamassoc' XML stream. SRC sends a snapshot with only the changed XML elements.
element is used to indicate whether a participant is contributing to
a media stream or not. SRC sends a snapshot with only the changed
XML elements.
During hold During hold
Metadata snapshot for CS hold: Metadata snapshot for CS hold:
RE-INVITE SRC-------------------->SRS RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
skipping to change at page 10, line 16 skipping to change at page 10, line 32
</participantstreamassoc> </participantstreamassoc>
<participantstreamassoc <participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send> <send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send> <send>EiXGlc+4TruqqoDaNE76ag==</send>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
In the above snippet, Alice with participant_id In the above snippet, Alice with participant_id
srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not
send any media. The same is indicated by the absence of 'send' XML send any media. The same is indicated by the absence of a 'send' XML
element. Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other element. On the other hand, Bob (participant_id
hand would be sending media but does not receive any media from Alice zSfPoSvdSDCmU3A3TRDxAw==) would be sending media, but he does not
and so 'recv' XML element is absent in this instance. receive any media from Alice; therefore, the 'recv' XML element is
absent in this instance.
During resume During resume
The snapshot now has 'send' and 'recv' XML elements for both Alice The snapshot now has 'send' and 'recv' XML elements for both Alice
and Bob indicating that both are receiving and sending media. and Bob, indicating that both are receiving and sending media.
Metadata snapshot for CS resume: Metadata snapshot for CS resume:
RE-INVITE SRC-------------------->SRS RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
skipping to change at page 12, line 5 skipping to change at page 12, line 23
</participantstreamassoc> </participantstreamassoc>
<participantstreamassoc <participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send> <send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send> <send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER Based)
Basic call between two Participants Alice and Bob is connected and A basic call between two participants, Alice and Bob, is connected,
SRC(B2BUA acting as SRC as per section 3.1.1 of [RFC7245]) has sent a and SRC (a B2BUA acting as SRC as per Section 3.1.1 of [RFC7245]) has
snapshot as described in example 1. Transfer is initiated by one of sent a snapshot as described in example 1. Transfer is initiated by
the participants(Alice). After the transfer is completed, SRC sends one of the participants (Alice). After the transfer is completed,
a snapshot of the participant changes to SRS. In this transfer the SRC sends a snapshot of the participant changes to the SRS. In
scenario, Alice drops out after transfer is completed and Bob and this transfer scenario, Alice drops out after transfer is completed,
Carol gets connected and recording of media between Bob and Carol is Bob and Carol get connected, and recording of media between Bob and
done by SRC. There are two flows that can happen here as described Carol is done by the SRC. There are two flows that can happen here
below. as described below.
Transfer with in the same session - (.e.g. RE-INVITE based Transfer within the same session (e.g., a RE-INVITE-based transfer):
transfer). Participant Alice drops out and Carol is added to the Alice drops out and Carol is added to the same session. No change to
same session. No change to session/group element. A the session/group element is made. A 'participantsessassoc' XML
'participantsessassoc' XML element indicating that Alice has element indicating that Alice has disassociated from the CS will be
disassociated from the CS will be present in the snapshot. A new present in the snapshot. A new 'participant' XML element
'participant' XML element representing Carol with mapping to the same representing Carol with mapping to the same RS SDP stream used for
RS SDP stream used for mapping earlier Alice's stream is sent in the mapping earlier Alice's stream is sent in the snapshot. A new
snapshot. A new 'sipSessionID' XML element that has UUID tuples 'sipSessionID' XML element that has Universally Unique Identifier
which corresponds to Bob and Carol is sent in the snapshot from SRC (UUID) tuples and that corresponds to Bob and Carol is sent in the
to SRS. Note that one half of the session ID that corresponds to Bob snapshot from the SRC to the SRS. Note that one half of the session
remains same. ID, that which corresponds to Bob, remains the same.
Metadata snapshot for INVITE based transfer in CS: Metadata snapshot for INVITE based transfer in CS:
RE-INVITE SRC-------------------->SRS RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
skipping to change at page 14, line 20 skipping to change at page 15, line 5
<participantstreamassoc <participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>60JAJm9UTvik0Ltlih/Gzw==</send> <send>60JAJm9UTvik0Ltlih/Gzw==</send>
<send>AcR5FUd3Edi8cACQJy/3JQ==</send> <send>AcR5FUd3Edi8cACQJy/3JQ==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv> <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv> <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
<associate-time>2013-12-16T23:42:07Z</associate-time> <associate-time>2013-12-16T23:42:07Z</associate-time>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
Transfer with new session - (.e.g. REFER based transfer). In this 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 case, a new session (CS) is created and shall be part of same CS-
(done by SRC). group (done by the SRC).
SRC first sends an optional snapshot indicating disassociation of The SRC first sends an *optional* snapshot indicating disassociation
participant from the old CS. Please note this is an optional of the participant from the old CS. An SRC may choose to just send
message. An SRC may choose to just send an INVITE with a new an INVITE with a new 'session' XML element to implicitly indicate
'session' XML element to implicitly indicate that the participants that the participants are now part of a different CS without sending
are now part of a different CS without sending disassociation from disassociation from the old CS. In this example, the SRC uses the
the old CS. The SRC in this example uses the same RS. In case the same RS. In case the SRC wishes to use a new RS, it will tear down
SRC wishes to use a new RS, it will tear down the current RS using the current RS using normal SIP procedures (BYE) with metadata, as in
normal SIP procedures (BYE) with metadata as in example 4. example 4.
Metadata snapshot for REFER based transfer in CS: Metadata snapshot for REFER based transfer in CS:
RE-INVITE SRC-------------------->SRS RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
skipping to change at page 16, line 6 skipping to change at page 16, line 39
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time> <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc> </participantsessionassoc>
<participantsessionassoc <participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time> <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc> </participantsessionassoc>
</recording> </recording>
In the above snapshot, the 'participantsessionassoc' XML element is In the above snapshot, the 'participantsessionassoc' XML element is
optional as indicating 'session' XML element with a 'stop-time' optional as indicating a 'session' XML element with a 'stop-time' XML
implicitly means that all the participants associated with that element implicitly means that all the participants associated with
session have been disassociated. that session have been disassociated.
SRC sends another snapshot to indicate the participant change (due to The SRC sends another snapshot to indicate the participant change
REFER) and new session information after transfer. In this example (due to REFER) and new session information after transfer. In this
it is assumed SRC uses the same RS to continue recording the call. example, it is assumed that the SRC uses the same RS to continue
The 'sipSessionID' XML element in metadata snapshot now indicates Bob recording the call. The 'sipSessionID' XML element in the metadata
and Carol in the (local, remote) uuid pair. snapshot now indicates Bob and Carol in the (local, remote) UUID
pair.
Metadata snapshot for REFER based transfer in CS: Metadata snapshot for REFER based transfer in CS:
RE-INVITE SRC-------------------->SRS RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
skipping to change at page 18, line 27 skipping to change at page 19, line 15
</participantstreamassoc> </participantstreamassoc>
<participantstreamassoc <participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>60JAJm9UTvik0Ltlih/Gzw==</send> <send>60JAJm9UTvik0Ltlih/Gzw==</send>
<send>AcR5FUd3Edi8cACQJy/3JQ==</send> <send>AcR5FUd3Edi8cACQJy/3JQ==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv> <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv> <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
3.2.4. Example 4: Call disconnect 3.2.4. Example 4: Call Disconnect
This example shows a snapshot of metadata sent by the SRC to SRS when This example shows a snapshot of metadata sent by the SRC to the SRS
a CS with Alice and Bob as participants is disconnected. when a CS with Alice and Bob as participants is disconnected.
SRC SRS SRC SRS
| | | |
|(1) BYE (metadata snapshot) F1 | |(1) BYE (metadata snapshot) F1 |
|---------------------------------------------------->| |---------------------------------------------------->|
| 200 OK F2 | | 200 OK F2 |
|<----------------------------------------------------| |<----------------------------------------------------|
Metadata snapshot for a CS disconnect: Metadata snapshot for a CS disconnect:
skipping to change at page 19, line 37 skipping to change at page 20, line 23
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time> <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc> </participantsessionassoc>
<participantsessionassoc <participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time> <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc> </participantsessionassoc>
</recording> </recording>
3.3. Call Scenarios with SRC recording streams by mixing 3.3. Call Scenarios with SRC Recording Streams by Mixing
This section describes a few example call flows where SRC may be part This section describes a few example call flows where the SRC may be
of conference model either as focus or a participant in conference as part of conference model either as focus or a participant in
explained in section 3.1.5 of [RFC7245]. The SRS here can be a SIP conference as explained in Section 3.1.5 of [RFC7245]. The SRS here
UA or an entity part of MEDIACTRL architecture. Note that the can be a SIP User Agent (UA) or an entity part of the MEDIACTRL
disconnect case is not shown since the metadata snapshot will be same architecture. Note that the disconnect case is not shown since the
as for a non-mixing case. metadata snapshot will be same as for a non-mixing case.
3.3.1. Example 1: Basic call with SRC mixing streams 3.3.1. Example 1: Basic Call with SRC Mixing Streams
Basic call between two participants Alice and Bob who are part of one A basic call between two participants, Alice and Bob, who are part of
CS. In this use case each participant calls into a conference server one CS. In this use case, each participant calls into a conference
(say, an MCU) to attend one of many conferences hosted on or managed server (say, a Multipoint Control Unit (MCU)) to attend one of many
by that server. Media streams sent by each participant are received conferences hosted on or managed by that server. Media streams sent
by all the other participants in the conference. Below is the by each participant are received by all the other participants in the
initial snapshot sent by SRC in the INVITE to SRS that has the conference. Below is the initial snapshot sent by the SRC in the
complete metadata. For the sake of simplicity only snippets of SIP/ INVITE to the SRS that has the complete metadata. For the sake of
SDP are shown. The SRC records the streams of each participant to simplicity, only snippets of SIP/SDP are shown. The SRC records the
SRS by mixing in this example. The SRC here is part of conference streams of each participant to SRS by mixing in this example. The
model described in section 3 of [RFC7245] as a focus and does mixing. SRC here is part of conference model described in Section 3 of
The SRC here is not a participant by itself and hence it does not [RFC7245] as a focus and does mixing. The SRC here is not a
contribute to media. participant by itself and hence it does not contribute to media.
Metadata snapshot with SRC mixing streams to SRS: Metadata snapshot with the SRC mixing streams to the SRS:
F1 INVITE SRC --------------> SRS F1 INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7 Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=00000000000000000000000000000000 ;remote=00000000000000000000000000000000
skipping to change at page 22, line 4 skipping to change at page 22, line 37
participant_id="srfBElmCRp2QB23b7Mpk0w=="> participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send> <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc> </participantstreamassoc>
<participantstreamassoc <participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send> <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
In the above example there are two participants Alice and Bob in the In the above example, there are two participants, Alice and Bob, in
conference. Among other things, SRC sends Session-ID in the metadata the conference. Among other things, the SRC sends Session-ID in the
snapshot. There are two Session-ID's here, one that corresponds to metadata snapshot. There are two Session-IDs here: one that
the SIP session between Alice and conference focus and the other for corresponds to the SIP session between Alice and the Conference focus
the SIP session between Bob and conference focus. In this use-case, and the other for the SIP session between Bob and the Conference
since Alice and Bob calls into the conference these Session-ID's are focus. In this use case, since Alice and Bob call into the
different. conference, these Session-IDs are different.
3.3.2. Example 2: Hold/resume with SRC recording by mixing streams 3.3.2. Example 2: Hold/Resume with SRC Recording by Mixing Streams
This is the continuation of Example 1: Basic call with SRC mixing This is the continuation of example 1 (basic call with SRC mixing
streams. Given a call between two participants Alice and Bob is streams). A call between two participants, Alice and Bob, is
established and a RS is created for recording as in example 5. One 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 participants, Bob, puts Alice on hold, and then resumes as
of the same CS. The 'send' and 'recv' XML elements of a part of the same CS. The 'send' and 'recv' XML elements of a
'participant' XML element are used to indicate whether a participant 'participant' XML element are used to indicate whether or not a
is contributing or not to a media stream. The metadata snapshot participant is contributing to a media stream. The metadata snapshot
looks as below: is represented below:
During hold During hold
Metadata snapshot when a CS participant goes hold and SRC mixing streams: 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 RE-INVITE SRC --------------> SRS
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 INVITE sip:recorder@example.com SIP/2.0
Content-Type: application/SDP Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
... From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
m=audio 49170 RTP/AVP 0 To: <sip:recorder@example.com>
a=rtpmap:0 PCMU/8000 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
a=label:96 Session-ID: a358d2b81a444a8c8fb05950cef331e7
a=sendonly ;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/rs-metadata Content-Type: application/SDP
Content-Disposition: recording-session ...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
<?xml version="1.0" encoding="UTF-8"?> ....
<recording xmlns='urn:ietf:params:xml:ns:recording:1'> --foobar
<datamode>partial</datamode> Content-Type: application/rs-metadata
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw==" Content-Disposition: recording-session
session_id="hVpd7YQgRW2nD22h7q60JQ=="> <?xml version="1.0" encoding="UTF-8"?>
<label>96</label> <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
</stream> <datamode>partial</datamode>
<participantstreamassoc <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
participant_id="srfBElmCRp2QB23b7Mpk0w=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <label>96</label>
</participantstreamassoc> </stream>
<participantstreamassoc <participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc> </participantstreamassoc>
</recording> <participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
</participantstreamassoc>
</recording>
During resume a snapshot shown below will be sent from SRC to SRS. During resumption, a snapshot shown below will be sent from the SRC
to the SRS.
Metadata snapshot when a CS participant resumes and SRC mixing streams: Metadata snapshot when a CS participant resumes and
the SRC is mixing the streams:
RE-INVITE SRC --------------> SRS RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7 Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
Require: siprec Require: siprec
Accept: application/sdp, application/rs-metadata, Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length] 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 --foobar
Content-Type: application/SDP Content-Type: application/rs-metadata
... Content-Disposition: recording-session
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'> <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode> <datamode>partial</datamode>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw==" <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label> <label>96</label>
</stream> </stream>
<participantstreamassoc <participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="> participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send> <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc> </participantstreamassoc>
<participantstreamassoc <participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send> <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
3.3.3. Example 3: Metadata snapshot of joining/dropping of a 3.3.3. Example 3: Metadata Snapshot of Joining/Dropping of a
participant to a session Participant to a Session
In a conference model, participants can join and drop a session any In a conference model, participants can join and drop a session any
time during the session. Below is a snapshot sent from SRC to SRS in time during the session. Below is a snapshot sent from the SRC to
this case. Note the SRC here can be a focus or a participant in the the SRS in this case. Note the SRC here can be a focus or a
conference. In the case where the SRC is a participant it may learn participant in the conference. In the case where the SRC is a
the information required for metadata by subscribing to conference participant, it may learn the information required for metadata by
event package [RFC4575]. Assume Alice and Bob were in the conference subscribing to a conference event package [RFC4575]. Assume Alice
and a third participant Carol joins, then SRC sends the below and Bob were in the conference and a third participant (Carol) joins,
snapshot with the indication of new participant. then the SRC sends the below snapshot with the indication of new
participant.
Metadata snapshot for a new participant joining CS: Metadata snapshot for a new participant joining CS:
RE-INVITE SRC --------------> SRS RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
skipping to change at page 26, line 19 skipping to change at page 27, line 19
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2013-12-16T23:41:07Z</associate-time> <associate-time>2013-12-16T23:41:07Z</associate-time>
</participantsessionassoc> </participantsessionassoc>
<participantstreamassoc <participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send> <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
Given Alice drops after some time from the conference. SRC generates After some time, Alice drops from the conference. The SRC generates
a new snapshot showing Alice disassociating from the session. a new snapshot showing Alice disassociating from the session.
Metadata snapshot for a participant dropping from CS: Metadata snapshot for a participant dropping from CS:
RE-INVITE SRC --------------> SRS RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
skipping to change at page 27, line 25 skipping to change at page 28, line 25
<sipSessionID>497c0f13929643b4a16858e2a3885edc <sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID> ;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID>
</session> </session>
<participantsessionassoc <participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==" participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time> <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc> </participantsessionassoc>
</recording> </recording>
3.3.4. Example 4: Call disconnect 3.3.4. Example 4: Call Disconnect
When a CS is disconnected, SRC sends BYE with a snapshot of metadata When a CS is disconnected, the SRC sends a BYE with a snapshot of
having session stop time and participant dis-associate times. The metadata having a session stop time and participant disassociation
snapshot looks same as listed in section 3.2.4 times. The snapshot looks the same as listed in Section 3.2.4.
3.4. Call scenarios with persistent RS between SRC and SRS 3.4. Call Scenarios with Persistent RS between SRC and SRS
This section shows the snapshots of metadata for the cases where a This section shows the snapshots of metadata for the cases where a
persistent RS exists between SRC and SRS. An SRC here may be SIP UA persistent RS exists between the SRC and the SRS. An SRC here may be
or a B2BUA or may be part of Conference model either as focus or a a SIP UA or a B2BUA, or it may be part of a conference model as
participant in a conference. The SRS here could be a SIP UA or an either the focus or a participant in a conference. The SRS here
entity part of MEDIACTRL architecture. Except in the disconnect could be a SIP UA or an entity part of the MEDIACTRL architecture.
case, the snapshot remains same as mentioned in previous sections. Except in the disconnect case, the snapshot remains same as mentioned
in previous sections.
3.4.1. Example 1: Metadata snapshot during CS disconnect with 3.4.1. Example 1: Metadata Snapshot during CS Disconnect with
persistent RS between SRC and SRS Persistent RS between SRC and SRS
Metadata snapshot for a CS disconnect with a persistent RS: Metadata snapshot for a CS disconnect with a persistent RS:
RE-INVITE sent from SRC -----------> SRS RE-INVITE sent from SRC -----------> SRS
INVITE sip:2001@example.com SIP/2.0 INVITE sip:2001@example.com SIP/2.0
Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
skipping to change at page 29, line 5 skipping to change at page 30, line 5
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time> <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc> </participantsessionassoc>
<participantsessionassoc <participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time> <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc> </participantsessionassoc>
</recording> </recording>
3.5. Turret-Case: Multiple CS into single RS with mixed stream 3.5. Turret-Case: Multiple CS into Single RS with Mixed Stream
In trading floor environments, in order to minimize storage and In trading-floor environments, in order to minimize storage and
recording system resources, it may be preferable to mix multiple recording system resources, it may be preferable to mix multiple
concurrent calls (each call is one CS) on different handsets/ concurrent calls (each call is one CS) on different handsets/speakers
speakers on the same turret into a single RS. This would means media on the same turret into a single RS. This would mean media in each
in each CS is mixed and recorded as part of single media stream and CS is mixed and recorded as part of single media stream, and multiple
multiple such CSs are recording in one RSfrom a SRC to SRS. such CSs are recording in one RS from an SRC to an SRS.
Taking an example where there are two CS [CS1 and CS2]. Assume Taking an example where there are two CSs [CS1 and CS2]: assume
mixing is done in each of these CS and both these CS are recorded as mixing is done in each of these CSs and both these CSs are recorded
part of single RS from a single SRC which is part of both the CS. as part of single RS from a single SRC, which is part of both the
There are three possibilities here: CSs. There are three possibilities here:
o CS1 and CS2 uses the same focus for mixing and that focus is also o CS1 and CS2 use the same focus for mixing, and that focus is also
acting as SRC in each of the CS. acting as SRC in each of the CSs.
o One of the CS (e.g. CS1), SRC is Focus and the other CS (e.g. o One CS (e.g. CS1) SRC is the focus and the other CS (e.g. CS2),
CS2), SRC is just one of the participant of the conference. SRC is just one of the participants of the conference.
o In both CS1 and CS2, SRC is just a participant of conference. o In both CS1 and CS2, the SRC is just a participant of conference.
The following example shows the first possibility where CS1 and CS2 The following example shows the first possibility where CS1 and CS2
uses the same focus for mixing and that focus is also acting as SRC use the same focus for mixing, and that focus is also acting as SRC
in each of the CS. in each of the CSs.
Metadata snapshot with two CS recorded as part of same RS: Metadata snapshot with two CSs recorded as part of the same RS:
INVITE SRC --------------> SRS INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7 Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=00000000000000000000000000000000 ;remote=00000000000000000000000000000000
skipping to change at page 31, line 43 skipping to change at page 32, line 45
<participantstreamassoc <participantstreamassoc
participant_id="EiXGlc+4TruqqoDaNE76ag=="> participant_id="EiXGlc+4TruqqoDaNE76ag==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send> <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
4. Security Considerations 4. Security Considerations
Security and privacy considerations mentioned in [RFC7865] and Security and privacy considerations mentioned in [RFC7865] and
[RFC7866] has to be followed by SRC and SRS for setting up RS SIP [RFC7866] have to be followed by the SRC and the SRS for setting up
dialog and sending metadata. RS SIP dialogs and sending metadata.
5. IANA Considerations 5. IANA Considerations
This document has no IANA considerations This document does not require any IANA actions.
6. Acknowledgement
Thanks to Ofir Rath, Charles Eckel, Yaron Pdut, Dmitry Andreyev and
Charles Armitage for their review comments.
Thanks to Alissa Cooper, Stephen Farrell, Kathleen Moriarty, Suresh
Krishnan, Benoit Claise, Carlos Pignataro, Dan Romascanu and Derek
Atkins for their feedback and comments during IESG reviews.
7. References 6. References
7.1. Normative References 6.1. Normative References
[RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain, [RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain,
"Use Cases and Requirements for SIP-Based Media Recording "Use Cases and Requirements for SIP-Based Media Recording
(SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011, (SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011,
<http://www.rfc-editor.org/info/rfc6341>. <http://www.rfc-editor.org/info/rfc6341>.
[RFC7865] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session [RFC7865] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session
Initiation Protocol (SIP) Recording Metadata", RFC 7865, Initiation Protocol (SIP) Recording Metadata", RFC 7865,
DOI 10.17487/RFC7865, May 2016, DOI 10.17487/RFC7865, May 2016,
<http://www.rfc-editor.org/info/rfc7865>. <http://www.rfc-editor.org/info/rfc7865>.
skipping to change at page 32, line 38 skipping to change at page 33, line 29
[RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A. [RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A.
Hutton, "Session Recording Protocol", RFC 7866, Hutton, "Session Recording Protocol", RFC 7866,
DOI 10.17487/RFC7866, May 2016, DOI 10.17487/RFC7866, May 2016,
<http://www.rfc-editor.org/info/rfc7866>. <http://www.rfc-editor.org/info/rfc7866>.
[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
"An Architecture for Media Recording Using the Session "An Architecture for Media Recording Using the Session
Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May
2014, <http://www.rfc-editor.org/info/rfc7245>. 2014, <http://www.rfc-editor.org/info/rfc7245>.
7.2. Informative References 6.2. Informative References
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
Session Initiation Protocol (SIP) Event Package for Session Initiation Protocol (SIP) Event Package for
Conference State", RFC 4575, DOI 10.17487/RFC4575, August Conference State", RFC 4575, DOI 10.17487/RFC4575, August
2006, <http://www.rfc-editor.org/info/rfc4575>. 2006, <http://www.rfc-editor.org/info/rfc4575>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353, Session Initiation Protocol (SIP)", RFC 4353,
DOI 10.17487/RFC4353, February 2006, DOI 10.17487/RFC4353, February 2006,
<http://www.rfc-editor.org/info/rfc4353>. <http://www.rfc-editor.org/info/rfc4353>.
skipping to change at page 33, line 15 skipping to change at page 34, line 5
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
Acknowledgements
Thanks to Ofir Rath, Charles Eckel, Yaron Pdut, Dmitry Andreyev, and
Charles Armitage for their review comments.
Thanks to Alissa Cooper, Stephen Farrell, Kathleen Moriarty, Suresh
Krishnan, Benoit Claise, Carlos Pignataro, Dan Romascanu, and Derek
Atkins for their feedback and comments during IESG reviews.
Authors' Addresses Authors' Addresses
Ram Mohan Ravindranath Ram Mohan Ravindranath
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Cessna Business Park,
Kadabeesanahalli Village, Varthur Hobli, Kadabeesanahalli Village, Varthur Hobli,
Sarjapur-Marathahalli Outer Ring Road Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
skipping to change at page 33, line 37 skipping to change at page 34, line 36
Parthasarathi Ravindran Parthasarathi Ravindran
Nokia Networks Nokia Networks
Bangalore, Karnataka Bangalore, Karnataka
India India
Email: partha@parthasarathi.co.in Email: partha@parthasarathi.co.in
Paul Kyzivat Paul Kyzivat
Huawei Huawei
Hudson, MA Hudson, MA
USA United States of America
Email: pkyzivat@alum.mit.edu Email: pkyzivat@alum.mit.edu
 End of changes. 85 change blocks. 
335 lines changed or deleted 340 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/