draft-ietf-siprec-callflows-05.txt   draft-ietf-siprec-callflows-06.txt 
SIPREC Ram Mohan. Ravindranath SIPREC Ram. Ravindranath
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track Parthasarathi. Ravindran Intended status: Informational Parthasarathi. Ravindran
Expires: January 31, 2016 Nokia Networks Expires: August 2, 2016 Nokia Networks
Paul. Kyzivat Paul. Kyzivat
Huawei Huawei
July 30, 2015 January 30, 2016
Session Initiation Protocol (SIP) Recording Call Flows Session Initiation Protocol (SIP) Recording Call Flows
draft-ietf-siprec-callflows-05 draft-ietf-siprec-callflows-06
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. In some of environments such as call centers and financial trading. In some of
these environments, all calls must be recorded for regulatory, these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons. Recording of a session compliance, and consumer protection reasons. Recording of a session
is typically performed by sending a copy of a media stream to a is typically performed by sending a copy of a media stream to a
recording device. This document lists call flows that has snapshot recording device. This document lists call flows that has snapshot
of metadata sent from SRC to SRS. This is purely an informational of metadata sent from a Session Recording Client to Session Recording
document that is written to support the model defined in the metadata Server. This is purely an informational document that is written to
draft. support the model defined in the metadata draft.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2016. This Internet-Draft will expire on August 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Metadata XML schema 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 with out 3.2. Call Scenarios with SRC recording streams with out mixing 4
mixing . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 4
3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 5 3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . 7
3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . . 8 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 11
3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 11 3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . 17
3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . . 18 3.3. Call Scenarios with SRC recording streams by mixing . . . 18
3.3. Call Scenarios with SRC recording streams by mixing . . . 20 3.3.1. Example 1: Basic call with SRC mixing streams . . . . 18
3.3.1. Example 1: Basic call with SRC mixing streams . . . . 20 3.3.2. Example 2: Hold/resume with SRC recording by mixing
3.3.2. Example 2: Hold/resume with SRC recording by streams . . . . . . . . . . . . . . . . . . . . . . . 21
mixing streams . . . . . . . . . . . . . . . . . . . . 22 3.3.3. Example 3: Metadata snapshot of joining/dropping of a
3.3.3. Example 3: Metadata snapshot of joining/dropping participant to a session . . . . . . . . . . . . . . 24
of a participant to a session . . . . . . . . . . . . 26 3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . 27
3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . . 29 3.4. Call scenarios with persistent RS between SRC and SRS . . 27
3.4. Call scenarios with persistent RS between SRC and SRS . . 29
3.4.1. Example 1: Metadata snapshot during CS disconnect 3.4.1. Example 1: Metadata snapshot during CS disconnect
with persistent RS between SRC and SRS . . . . . . . . 29 with persistent RS between SRC and SRS . . . . . . . 27
3.5. Turrent-Case: Multiple CS into single RS with mixed 3.5. Turrent-Case: Multiple CS into single RS with mixed
stream . . . . . . . . . . . . . . . . . . . . . . . . . . 30 stream . . . . . . . . . . . . . . . . . . . . . . . . . 28
4. Security Considerations . . . . . . . . . . . . . . . . . . . 33 4. Security Considerations . . . . . . . . . . . . . . . . . . . 31
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 33 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7. Informative References . . . . . . . . . . . . . . . . . . . 32
7.1. Normative References . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
7.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Overview 1. Overview
[I-D.ietf-siprec-metadata] document focuses on the Recording metadata [I-D.ietf-siprec-metadata] document focuses on the recording metadata
which describes the communication session. The document lists a few which describes the communication session(CS). This document lists
examples and shows the snapshots of metadata sent from SRC to SRS. few examples and shows the snapshots of metadata sent from a Session
For the sake of simplicity the entire SIP [RFC3261] messages are not Recording Client (SRC) to Session Recording Server (SRS). For the
shown at various points, instead only a snippets of the SIP/SDP sake of simplicity the entire Session Initiation Protocol (SIP)
[RFC3261] messages are not shown at various points, instead only
snippets of the SIP and Session Description Protocol (SDP)[RFC4566]
messages and the XML snapshot of metadata is shown. messages and the XML snapshot of metadata is shown.
2. Terminology 2. Terminology
The terms using in this defined are defined in The terms using in this document are defined in
[I-D.ietf-siprec-metadata]. No new terms/definitions are introduced [I-D.ietf-siprec-metadata] and [RFC6341]. No new definitions are
in this document. introduced in this document.
3. Metadata XML schema Instances 3. Metadata XML Instances
This section describes the metadata model XML instances for different The following sub-sections has examples showing the metadata snapshot
use cases of SIPREC. For the sake of simplicity the complete SIP/SDP sent from SRC to SRS. In all these use-cases, the SRC is a B2BUA.
snippets are NOT shown here.
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 towards the SRS. The SRC in this example could be Recording Session(RS) towards the SRS. The SRC in this example could
part of any one of the architectures described in section 3 of be part of any one of the architectures described in section 3 of
[RFC7245]. [RFC7245].
SRC SRS SRC SRS
| | | |
|(1) INVITE (metadata snapshot) F1 | |(1) INVITE (metadata snapshot) F1 |
|---------------------------------------------------->| |---------------------------------------------------->|
| 200 OK | | 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
|(3) ACK | |(3) ACK |
|---------------------------------------------------->| |---------------------------------------------------->|
skipping to change at page 4, line 34 skipping to change at page 4, line 7
| | | |
|====================================================>| |====================================================>|
|====================================================>| |====================================================>|
|(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 describes the snapshot of metadata shown. The subsequent sections describes the snapshot of metadata
sent from SRC to SRS for each of the above transactions (F1 ... sent from SRC to SRS for each of the above transactions (F1 ... Fn-
Fn-1). There may be multiple UPDATES/RE-INVITES mid call to 1). There may be multiple UPDATES/RE-INVITES mid call to indicates
indicates snapshots of different CS changes. Depending on the snapshots of different CS changes. Depending on the architecture
architecture described in section 3 of [RFC7245] an SRC may be a described in section 3 of [RFC7245] an SRC may be a endpoint or B2BUA
endpoint or B2BUA or as part of MEDIACTRL or Conference Focus. The or as part of MEDIACTRL or Conference Focus. The subsequent sections
subsequent sections in this document tries to list some example in this document tries to list some example metadata snapshots for
metadata snapshots for three major categories. three major categories.
o SRC recording streams unmixed to SRS. This includes cases where o SRC recording streams unmixed to SRS. This includes cases where
SRC is SIP UA or B2BUA. SRC is SIP UA or B2BUA.
o SRC recording mixed streams to SRS. This includes cases where SRC o SRC recording mixed streams to SRS. This includes cases where SRC
is part of SIP conference model explained in [RFC4353]. is part of SIP conference model explained in [RFC4353].
o SRC having a persistent RS with SRS. o SRC having a persistent RS with SRS.
o Special flows like Turrent flows. o Special flows like Turrent flows.
Note that only those examples for which metadata changes are listed Note that only those examples for which metadata changes are listed
in each category. For some of the call flows the snapshots may be in each category. For some of the call flows the snapshots may be
same (like in case of endpoint or B2BUA acting as SRC) and the same 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 with out mixing 3.2. Call Scenarios with SRC recording streams with out mixing
The section covers the models mentioned in the architecture document This section describes few example flows where SRC can be a SIP-UA or
in section 3 of [RFC7245] where an SRC may be a SIP-UA or B2BUA. The B2BUA as described in section 3 of [RFC7245]. The SRS here can be a
SRS here could be a SIP-UA or an entity part of MEDIACTRL SIP-UA or an entity part of MEDIACTRL architecture described in
architecture described in [RFC6230]. [RFC6230].
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 one Basic call between two participants Alice and Bob who are part of the
CS. In this use case each participant sends two Media Streams. same CS. In this use case each participant sends two media
Media Streams sent by each participant are received all other streams(audio and video). Media streams sent by each participant are
participants in this use-case. In this example the SRC is a B2BUA in received by the other participant in this use-case. In this example
the path between Alice and Bob as described in section 3.1.1 of the SRC is a B2BUA in the path between Alice and Bob as described in
[RFC7245]. Below is the initial snapshot sent by SRC in the INVITE section 3.1.1 of [RFC7245]. Below is the initial snapshot sent by
to SRS that has complete metadata. For the sake of simplicity only SRC in the INVITE to SRS. This snapshot has the complete metadata.
snippets of SIP/SDP are shown. The SRCs records the streams of each For the sake of simplicity only snippets of SIP/SDP are shown. The
participant to SRS with out mixing in this example. SRCs records the streams of each participant to SRS with out mixing
in this example.
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: ab30317f1a784dc48ff824d0d3715d86 Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000 ;remote=00000000000000000000000000000000
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
Require: siprec Require: siprec
skipping to change at page 8, line 24 skipping to change at page 7, line 45
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
Assume a call between two Participants Alice and Bob is established A call between two participants Alice and Bob is established and a RS
and a RS is created for recording as in example1. This is the is created for recording as in example1. One of the participants Bob
continuation of above use-case. One of the participants Bob puts puts Alice hold and then resumes as part of the same CS. The send
Alice hold and then resumes as part of the same session. The send and recv XML elements of a participantstreamassoc XML element is used
and recv XML elements of a participant is used to indicate whether a to indicate whether a participant is contributing to a media stream
participant is sending not sending a particular media stream whose or not. SRC sends a snapshot with only the changed XML elements.
properties are represented by stream element. SRC sends a snapshot
with only the changed XML elements.
During hold During hold
F2 mid call RE-INVITE SRC-------------------->SRS F2 mid call 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 11, line 38 skipping to change at page 11, line 8
<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 Basic call between two Participants Alice and Bob is connected and
SRC(B2BUA as per section 3.1.1 of [RFC7245]) has sent a snapshot as SRC(B2BUA acting as SRC as per section 3.1.1 of [RFC7245]) has sent a
in example 1. Transfer is initiated by one of the snapshot as described in example 1. Transfer is initiated by one of
participants(Alice). After the transfer is completed, SRC sends a the participants(Alice). After the transfer is completed, SRC sends
snapshot of the participant changes to SRS. In this transfer a snapshot of the participant changes to SRS. In this transfer
scenario, Alice drops out after transfer is completed and Bob and scenario, Alice drops out after transfer is completed and Bob and
Carol gets connected and recording of media between Bob and Carol is Carol gets connected and recording of media between Bob and Carol is
done by SRC. There may be two cases here as described below. done by SRC. There are two flows that can happen here as described
below.
Transfer with in the same session - (.e.g. RE-INVITE based Transfer with in the same session - (.e.g. RE-INVITE based
transfer). Participant Alice drops out and Carol is added to the transfer). Participant Alice drops out and Carol is added to the
same session. No change to session/group element. A same session. No change to session/group element. A
participantsessassoc element indicating that Alice has disassociated participantsessassoc element indicating that Alice has disassociated
from the CS will be present in the snapshot. A new participant XML from the CS will be present in the snapshot. A new participant XML
element representing Carol with mapping to the same RS SDP stream element representing Carol with mapping to the same RS SDP stream
used for mapping earlier Alice's stream is sent in the snapshot. A used for mapping earlier Alice's stream is sent in the snapshot. A
new sipSessionID XML element that has UUID tuples which corresponds new sipSessionID XML element that has UUID tuples which corresponds
to Bob and Carol is sent in the snapshot from SRC to SRS. Note that to Bob and Carol is sent in the snapshot from SRC to SRS. Note that
skipping to change at page 14, line 11 skipping to change at page 13, line 26
</recording> </recording>
Transfer with new session - (.e.g. REFER based transfer). In this Transfer with new session - (.e.g. REFER based transfer). In this
case a new session (CS) is created and shall be part of same CS-group case a new session (CS) is created and shall be part of same CS-group
(done by SRC). (done by SRC).
SRC first sends an optional snapshot indicating disassociation of SRC first sends an optional snapshot indicating disassociation of
participant from the old CS. Please note this is a optional message. participant from the old CS. Please note this is a optional message.
An SRC may choose to just send a INVITE with a new session element to An SRC may choose to just send a INVITE with a new session element to
implicitly indicate that the participants are now part of a different implicitly indicate that the participants are now part of a different
CS with out sending disassociation from the old CS. Also note that CS with out sending disassociation from the old CS. The SRC in this
the SRC in this example uses the same RS. In case it decides to use example uses the same RS. In case the SRC wishes to use a new RS, it
a new RS, it will tear down the current RS using normal SIP will tear down the current RS using normal SIP procedures (BYE) with
procedures (BYE) with metadata as in example 4. metadata as in example 4.
mid call RE-INVITE SRC-------------------->SRS mid call 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: ab30317f1a784dc48ff824d0d3715d86 Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
skipping to change at page 15, line 35 skipping to change at page 15, line 5
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>
<participantsessionassoc <participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disasociate-time>2010-12-16T23:41:07Z</disassociate-time> <disasociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc> </participantsessionassoc>
</recording> </recording>
Note in the above snapshot the participantsessionassoc element is In the above snapshot, the participantsessionassoc element is
optional as indicating session XML element with a stop-time optional as indicating session XML element with a stop-time
implicitly means that all the participants associated with that implicitly means that all the participants associated with that
session have been disassociated. session have been disassociated.
SRC sends another snapshot to indicate the participant change (due to SRC sends another snapshot to indicate the participant change (due to
REFER) and new session information after transfer. In this example REFER) and new session information after transfer. In this example
it is assumed SRC uses the same Recording Session to continue it is assumed SRC uses the same RS to continue recording the call.
recording the call. Also note that the sipSessionID XML element in The sipSessionID XML element in metadata snapshot now indicates Alice
metadata snapshot now indicates Alice and Carol in the (local, and Carol in the (local, remote) uuid pair.
remote) uuid pair.
mid call RE-INVITE SRC-------------------->SRS mid call 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: ab30317f1a784dc48ff824d0d3715d86 Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
Require: siprec Require: siprec
skipping to change at page 18, line 11 skipping to change at page 17, line 28
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 an SRC at CS This example shows a snapshot of metadata sent by the SRC to SRS when
disconnect where the participants of CS are Alice and Bob 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 |
|<----------------------------------------------------| |<----------------------------------------------------|
F1 BYE SRC -----------> SRS F1 BYE SRC -----------> SRS
BYE sip:2001@example.com SIP/2.0 BYE sip:2001@example.com SIP/2.0
skipping to change at page 20, line 7 skipping to change at page 18, line 36
<participantsessionassoc <participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disasociate-time>2010-12-16T23:41:07Z</disassociate-time> <disasociate-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
The section covers the models mentioned in the architecture document The section describes a few example call flows where SRC may be part
in section 3 of [RFC7245] where an SRC may be part of Conference of conference model either as Focus or a participant in conference as
model either as Focus or a participant in Conference. The SRS here explained in section 3.1.5 of [RFC7245]. The SRS here can be a SIP
could be a SIP UA or an entity part of MEDIACTRL architecture. Note UA or an entity part of MEDIACTRL architecture. Note that the
that the disconnect case is not shown since the metadata snapshot disconnect case is not shown since the metadata snapshot will be same
will be same as for a non-mixing case. 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 Basic call between two participants Alice and Bob who are part of one
CS. In this use case each participant call into a conference server CS. In this use case each participant call into a conference server
(say, an MCU) to attend one of many conferences hosted on or managed (say, an MCU) to attend one of many conferences hosted on or managed
by that servers. Media Streams sent by each participant is received by that servers. Media streams sent by each participant is received
by the other participant. Below is the initial snapshot sent by SRC by all the other participants in the conference. Below is the
in the INVITE to SRS that has complete metadata. For the sake of initial snapshot sent by SRC in the INVITE to SRS that has the
simplicity only snippets of SIP/SDP are shown. The SRCs records the complete metadata. For the sake of simplicity only snippets of SIP/
streams of each participant to SRS by mixing in this example. The SDP are shown. The SRC records the streams of each participant to
SRC here is part of conference model described in section 3 of SRS by mixing in this example. The SRC here is part of conference
[RFC7245] as a Focus and does mixing. The SRC here is not a model described in section 3 of [RFC7245] as a Focus and does mixing.
participant by itself and hence it does not contribute to streams. The SRC here is not a participant by itself and hence it does not
contribute to media.
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 17 skipping to change at page 20, line 49
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 the
conference. Among other things, SRC sends Session-ID in the metadata conference. Among other things, SRC sends Session-ID in the metadata
snapshot. There are two Session-ID's here, one that corresponds to snapshot. There are two Session-ID's here, one that corresponds to
the SIP session between Alice and Conference Focus and the other for the SIP session between Alice and conference focus and the other for
the SIP session between Bob and Conference Focus. In this use-case, the SIP session between Bob and conference focus. In this use-case,
since Alice and Bob calls into the conference these Session-ID's are since Alice and Bob calls into the conference these Session-ID's are
different. 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
Assume a call between two Participants Alice and Bob is established Assume a call between two participants Alice and Bob is established
and a RS is created for recording as in example 5. This is the and a RS is created for recording as in example 5. This is the
continuation of above use-case. One of the participants Bob puts continuation of above use-case. One of the participants Bob puts
Alice hold and then resumes as part of the same session. The send Alice hold and then resumes as part of the same CS. The send and
and recv XML elements of a participant is used to indicate whether a recv XML elements of a participant is used to indicate whether a
participant is sending not sending a particular media stream whose participant is contributing or not to a media stream. The metadata
properties are represented by stream element. The metadata snapshot snapshot looks as below:
looks as below:
During hold During hold
mid call hold RE-INVITE SRC --------------> SRS mid call hold 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
skipping to change at page 24, line 5 skipping to change at page 23, line 5
<participantstreamassoc <participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="> participant_id="srfBElmCRp2QB23b7Mpk0w==">
<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>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
During resume a snapshot shown below will be sent from SRC to SRS During resume a snapshot shown below will be sent from SRC to SRS.
mid call resume RE-INVITE SRC --------------> SRS mid call resume 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
skipping to change at page 29, line 16 skipping to change at page 27, line 16
When a CS is disconnected, SRC sends BYE with a snapshot of metadata When a CS is disconnected, SRC sends BYE with a snapshot of metadata
having session stop-time and participant dis-associate times. The having session stop-time and participant dis-associate times. The
snapshot looks same as listed in section 3.2.4 snapshot looks 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
The section shows the snapshots of metadata for the cases there a The section shows the snapshots of metadata for the cases there a
persistent RS exists between SRC and SRS. An SRC here may be SIP UA persistent RS exists between SRC and SRS. An SRC here may be SIP UA
or a B2BUA or may be part of Conference model either as Focus or a or a B2BUA or may be part of Conference model either as Focus or a
participant in Conference. The SRS here could be a SIP UA or an participant in a conference. The SRS here could be a SIP UA or an
entity part of MEDIACTRL architecture. Except disconnect case, the entity part of MEDIACTRL architecture. Except disconnect case, the
snapshot remains same as one of the examples mentioned in previous snapshot remains same as mentioned in previous sections.
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
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>
skipping to change at page 30, line 49 skipping to change at page 28, line 49
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disasociate-time>2010-12-16T23:41:07Z</disassociate-time> <disasociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc> </participantsessionassoc>
</recording> </recording>
3.5. Turrent-Case: Multiple CS into single RS with mixed stream 3.5. Turrent-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 (Communication Sessions) on different handsets/ concurrent calls (each call is one CS) on different handsets/
speakers on the same turret into a single recording session. This speakers on the same turret into a single RS. This would means media
would means media in each CS is mixed and recorded as part of single in each CS is mixed and recorded as part of single media stream and
media stream and multiple such CSs are recording in one Recording multiple such CSs are recording in one RSfrom a SRC to SRS.
Session from a SRC to SRS.
Lets take a example where there are two CS[CS1 and CS2]. Assume Lets take a example where there are two CS[CS1 and CS2]. Assume
mixing is done in each of these CS and both these CS are recorded as mixing is done in each of these CS and both these CS are recorded as
part of single RS from a single SRC which is part of both the CS. part of single RS from a single SRC which is part of both the CS.
There are three possibilities here: There are three possibilities here:
o CS1 and CS2 uses the same Focus for fixing and that Focus is also o CS1 and CS2 uses the same Focus for fixing and that Focus is also
acting as SRC in each of the CS. acting as SRC in each of the CS.
o In of the CS(say CS1), SRC is Focus and in the other CS(say CS2), o In of the CS(say CS1), SRC is Focus and in the other CS(say CS2),
SRC is just one of the participant of the conference. SRC is just one of the participant of the conference.
o In both CS1 and CS2, SRC is just a participant of Conference.
o In both CS1 and CS2, SRC is just a participant of conference.
The following example shows the first possibility where CS1 and CS2 The following example shows the first possibility where CS1 and CS2
uses the same Focus for fixing and that Focus is also acting as SRC uses the same Focus for fixing and that Focus is also acting as SRC
in each of the CS. in each of the CS.
snapshot of metadata INVITE SRC --------------> SRS snapshot of metadata 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 33, line 34 skipping to change at page 31, line 34
</participantstreamassoc> </participantstreamassoc>
<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
There is no security consideration as it is informational callflow Security considerations mentioned in [I-D.ietf-siprec-metadata] and
document. [I-D.ietf-siprec-protocol] has to be followed by SRC and SRS for
setting up RS SIP dialog and sending metadata.
5. IANA Considerations 5. IANA Considerations
This document has no IANA considerations This document has no IANA considerations
6. Acknowledgement 6. Acknowledgement
Thanks to Ofir Rath, Charles Eckel and Yaron Pdut for their review Thanks to Ofir Rath, Charles Eckel and Yaron Pdut for their review
comments. comments.
7. References 7. Informative References
7.1. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
7.2. Informative References
[I-D.ietf-siprec-metadata] [I-D.ietf-siprec-metadata]
R, R., Ravindran, P., and P. Kyzivat, "Session Initiation R, R., Ravindran, P., and P. Kyzivat, "Session Initiation
Protocol (SIP) Recording Metadata", Protocol (SIP) Recording Metadata", draft-ietf-siprec-
draft-ietf-siprec-metadata-17 (work in progress), metadata-18 (work in progress), August 2015.
February 2015.
[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, Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May
May 2014, <http://www.rfc-editor.org/info/rfc7245>. 2014, <http://www.rfc-editor.org/info/rfc7245>.
[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, Conference State", RFC 4575, DOI 10.17487/RFC4575, August
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>.
[RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework", RFC 6230, DOI 10.17487/ Control Channel Framework", RFC 6230,
RFC6230, May 2011, DOI 10.17487/RFC6230, May 2011,
<http://www.rfc-editor.org/info/rfc6230>. <http://www.rfc-editor.org/info/rfc6230>.
[RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain,
"Use Cases and Requirements for SIP-Based Media Recording
(SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011,
<http://www.rfc-editor.org/info/rfc6341>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[I-D.ietf-siprec-protocol]
Portman, L., Lum, H., Eckel, C., Johnston, A., and A.
Hutton, "Session Recording Protocol", draft-ietf-siprec-
protocol-18 (work in progress), September 2015.
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
 End of changes. 50 change blocks. 
151 lines changed or deleted 164 lines changed or added

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