draft-ietf-siprec-callflows-03.txt   draft-ietf-siprec-callflows-04.txt 
SIPREC Ram Mohan. Ravindranath SIPREC Ram Mohan. Ravindranath
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track Parthasarathi. Ravindran Intended status: Standards Track Parthasarathi. Ravindran
Expires: January 22, 2015 Nokia Networks Expires: September 1, 2015 Nokia Networks
Paul. Kyzivat Paul. Kyzivat
Huawei Huawei
July 21, 2014 February 28, 2015
Session Initiation Protocol (SIP) Recording Call Flows Session Initiation Protocol (SIP) Recording Call Flows
draft-ietf-siprec-callflows-03 draft-ietf-siprec-callflows-04
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, the metadata format for which is of metadata sent from SRC to SRS. This is purely an informational
described in [I-D.ietf-siprec-metadata] . This is purely an document that is written to support the model defined in the metadata
informational document that is written to support the model defined draft.
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 22, 2015. This Internet-Draft will expire on September 1, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 23 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Metadata XML schema Instances . . . . . . . . . . . . . . . . 3 3. Metadata XML schema 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 7 3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . . 7
3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 10 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 . . . . . . . . . . . . . . 17
3.3. Call Scenarios with SRC recording streams by mixing . . . 19 3.3. Call Scenarios with SRC recording streams by mixing . . . 19
3.3.1. Example 1: Basic call with SRC mixing streams . . . . 19 3.3.1. Example 1: Basic call with SRC mixing streams . . . . 19
3.3.2. Example 2: Hold/resume with SRC recording by 3.3.2. Example 2: Hold/resume with SRC recording by
mixing streams . . . . . . . . . . . . . . . . . . . . 21 mixing streams . . . . . . . . . . . . . . . . . . . . 21
3.3.3. Example 3: Metadata snapshot of joining/dropping 3.3.3. Example 3: Metadata snapshot of joining/dropping
of a participant to a session . . . . . . . . . . . . 24 of a participant to a session . . . . . . . . . . . . 25
3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . . 27 3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . . 28
3.4. Call scenarios with persistent RS between SRC and SRS . . 27 3.4. Call scenarios with persistent RS between SRC and SRS . . 28
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 . . . . . . . . 27 with persistent RS between SRC and SRS . . . . . . . . 28
3.5. Turrent-Case: Multiple CS into single RS with mixed 3.5. Turrent-Case: Multiple CS into single RS with mixed
stream . . . . . . . . . . . . . . . . . . . . . . . . . . 28 stream . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4. Security Considerations . . . . . . . . . . . . . . . . . . . 30 4. Security Considerations . . . . . . . . . . . . . . . . . . . 32
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 31 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 32
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Normative References . . . . . . . . . . . . . . . . . . . 31 7.1. Normative References . . . . . . . . . . . . . . . . . . . 33
7.2. Informative References . . . . . . . . . . . . . . . . . . 31 7.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
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. The document lists a few
examples and shows the snapshots of metadata sent from SRC to SRS. examples and shows the snapshots of metadata sent from SRC to SRS.
For the sake of simplicity the entire SIP [RFC3261] messages are not For the sake of simplicity the entire SIP [RFC3261] messages are not
shown at various points, instead only a snippets of the SIP/SDP shown at various points, instead only a snippets of the SIP/SDP
messages and the XML snapshot of metadata is shown. messages and the XML snapshot of metadata is shown.
skipping to change at page 4, line 27 skipping to change at page 4, line 27
|====================================================>| |====================================================>|
|(5) UPDATE/RE-INVITE (metadata update 1) F2 | |(5) UPDATE/RE-INVITE (metadata update 1) F2 |
|---------------------------------------------------->| |---------------------------------------------------->|
| 200 OK | | 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
| ................................................... | | ................................................... |
| ................................................... | | ................................................... |
| | | |
|====================================================>| |====================================================>|
|====================================================>| |====================================================>|
|(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-1). There may be multiple UPDATES/RE-INVITES mid call to Fn-1). There may be multiple UPDATES/RE-INVITES mid call to
indicates snapshots of different CS changes. Depending on the indicates snapshots of different CS changes. Depending on the
architecture described in section 3 of [RFC7245] an SRC may be a architecture described in section 3 of [RFC7245] an SRC may be a
endpoint or B2BUA or as part of MEDIACTRL or Conference Focus. The endpoint or B2BUA or as part of MEDIACTRL or Conference Focus. The
subsequent sections in this document tries to list some example subsequent sections in this document tries to list some example
metadata snapshots for three major categories. metadata snapshots for 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 The section covers the models mentioned in the architecture document
in section 3 of [RFC7245] where an SRC may be a SIP-UA or B2BUA. The in section 3 of [RFC7245] where an SRC may be a SIP-UA or B2BUA. The
SRS here could be a SIP-UA or an entity part of MEDIACTRL SRS here could be a SIP-UA or an entity part of MEDIACTRL
architecture described in [RFC6230]. architecture described in [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 one
CS. In this use case each participant sends two Media Streams. CS. In this use case each participant sends two Media Streams.
Media Streams sent by each participant are received all other Media Streams sent by each participant are received all other
participants in this use-case. Below is the initial snapshot sent by participants in this use-case. In this example the SRC is a B2BUA in
SRC in the INVITE to SRS that has complete metadata. For the sake of the path between Alice and Bob as described in section 3.1.1 of
simplicity only snippets of SIP/SDP are shown. The SRCs records the [RFC7245]. Below is the initial snapshot sent by SRC in the INVITE
streams of each participant to SRS with out mixing in this example. to SRS that has complete metadata. For the sake of simplicity only
snippets of SIP/SDP are shown. The SRCs records the streams of each
participant to SRS 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
;remote=00000000000000000000000000000000
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 --foobar
skipping to change at page 6, line 26 skipping to change at page 6, line 30
a=sendonly a=sendonly
.... ....
--foobar --foobar
Content-Type: application/rs-metadata Content-Type: application/rs-metadata
Content-Disposition: recording-session 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'> <recording xmlns='urn:ietf:params:xml:ns:recording'>
<datamode>complete</datamode> <datamode>complete</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ=="> <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<start-time>2010-12-16T23:41:07Z</start-time> <start-time>2010-12-16T23:41:07Z</start-time>
<sipSessionID>47755a9de7794ba387653f2099600ef2
;remote=3363127f0d084c10876dddd4f8e5eeb9</sipSessionID>
</session> </session>
<participant <participant
participant_id="srfBElmCRp2QB23b7Mpk0w=="> participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor=sip:alice@atlanta.com> <nameID aor=sip:alice@atlanta.com>
<name xml:lang="it">Alice</name> <name xml:lang="it">Alice</name>
</nameID> </nameID>
</participant> </participant>
<participantsessionassoc <participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==" participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
skipping to change at page 7, line 41 skipping to change at page 7, line 47
</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 Assume a call between two Participants Alice and Bob is established
and a RS is created for recording as in example1. This is the and a RS is created for recording as in example1. 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 session. The send
and recv XML elements of a participant is used to indicate whether a and recv XML elements of a participant is used to indicate whether a
participant is sending not sending a particular media stream whose participant is sending not sending a particular media stream whose
properties are represented by stream element. The metadata snapshot properties are represented by stream element. SRC sends a snapshot
looks as below 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
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;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 --foobar
skipping to change at page 9, line 13 skipping to change at page 9, line 17
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv> <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<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>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
In the above snippet during Alice with participant_id In the above snippet, Alice with participant_id
srfBElmCRp2QB23b7Mpk0w== only receives media streams since Alice is srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not
put on hold and does not send any media. The same is indicated by send any media. The same is indicated by the absence of send XML
the absence of send XML element. Bob(participant_id element. Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other
zSfPoSvdSDCmU3A3TRDxAw==) on the other hand would be sending media hand would be sending media but does not receive any media from Alice
but does not receive any media from Alice and so recv XML element is and so recv XML element is absent in this instance.
absent in this instance.
During resume During resume
The snapshot now has send and recv XML elements for both Alice and The snapshot now has send and recv XML elements for both Alice and
Bob indicating that both are receiving and sending media. Bob indicating that both are receiving and sending media.
F3 mid call RE-INVITE SRC-------------------->SRS F3 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
;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 --foobar
skipping to change at page 10, line 47 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 has sent a snapshot as in example 1. Transfer is initiated by SRC(B2BUA as per section 3.1.1 of [RFC7245]) has sent a snapshot as
one of the participants(Alice). After the transfer is completed, SRC in example 1. Transfer is initiated by one of the
sends a snapshot of the participant changes to SRS. In this transfer participants(Alice). After the transfer is completed, SRC sends 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 may be two cases 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. used for mapping earlier Alice's stream is sent in the snapshot. A
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
one half of the session ID that corresponds to Bob remains same.
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
;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 --foobar
skipping to change at page 12, line 17 skipping to change at page 12, line 29
a=label:99 a=label:99
a=sendonly a=sendonly
.... ....
--foobar --foobar
Content-Type: application/rs-metadata Content-Type: application/rs-metadata
Content-Disposition: recording-session 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'> <recording xmlns='urn:ietf:params:xml:ns:recording'>
<datamode>partial</datamode> <datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>3363127f0d084c10876dddd4f8e5eeb9
;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID>
</session>
<participantsessionassoc <participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==" participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2013-12-16T23:41:07Z</disassociate-time> <disassociate-time>2013-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc> </participantsessionassoc>
<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>60JAJm9UTvik0Ltlih/Gzw==</recv> <recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
skipping to change at page 13, line 16 skipping to change at page 13, line 31
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. Also note that
the SRC in this example uses the same RS. In case it decides to use the SRC in this example uses the same RS. In case it decides to use
a new RS, it will tear down the current RS using normal SIP a new RS, it will tear down the current RS using normal SIP
procedures (BYE) with metadata as in example 4. procedures (BYE) with 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
;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 --foobar
Content-Type: application/SDP Content-Type: application/SDP
... ...
m=audio 49180 RTP/AVP 0 m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=label:96 a=label:96
a=sendonly a=sendonly
... ...
m=video 49182 RTP/AVPF 96 m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000 a=rtpmap:96 H.264/90000
skipping to change at page 14, line 41 skipping to change at page 15, line 10
</participantsessionassoc> </participantsessionassoc>
</recording> </recording>
Note in the above snapshot the participantsessionassoc element is Note 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. it is assumed SRC uses the same Recording Session to continue
recording the call. Also note that the sipSessionID XML element in
metadata snapshot now indicates Alice and Carol in the (local,
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
;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 --foobar
skipping to change at page 15, line 48 skipping to change at page 16, line 21
.... ....
--foobar --foobar
Content-Type: application/rs-metadata Content-Type: application/rs-metadata
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording'> <recording xmlns='urn:ietf:params:xml:ns:recording'>
<datamode>complete</datamode> <datamode>complete</datamode>
<session session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> <session session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<start-time>2010-12-16T23:41:07Z</start-time> <start-time>2010-12-16T23:41:07Z</start-time>
<sipSessionID>3363127f0d084c10876dddd4f8e5eeb9
;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID>
</session> </session>
<participant <participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor=sip:Bob@biloxy.com/> <nameID aor=sip:Bob@biloxy.com/>
</participant> </participant>
<participantsessionassoc <participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<associate-time>2010-12-16T23:32:03Z</associate-time> <associate-time>2010-12-16T23:32:03Z</associate-time>
</participantsessionassoc> </participantsessionassoc>
<participantstreamassoc <participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send> <send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send> <send>EiXGlc+4TruqqoDaNE76ag==</send>
skipping to change at page 18, line 13 skipping to change at page 18, line 13
disconnect where the participants of CS are Alice and Bob disconnect where the participants of CS are Alice and Bob
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@8.3.2.12:5060 SIP/2.0 BYE sip:2001@example.com SIP/2.0
Via: SIP/2.0/UDP 8.3.2.34:5060;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
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 102 BYE CSeq: 102 BYE
Max-Forwards: 70 Max-Forwards: 70
Require: siprec Require: siprec
Accept: application/rs-metadata, Accept: 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 --foobar
skipping to change at page 19, line 22 skipping to change at page 19, line 22
will be same as for a non-mixing case. 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 Basic call between two Participants Alice and Bob who are part of one
CS. In this use case each participant sends one Media Streams. CS. In this use case each participant sends one Media Streams.
Media Streams sent by each participant is received by the other Media Streams sent by each participant is received by the other
participant. Below is the initial snapshot sent by SRC in the INVITE participant. Below is the initial snapshot sent by SRC in the INVITE
to SRS that has complete metadata. For the sake of simplicity only to SRS that has complete metadata. For the sake of simplicity only
snippets of SIP/SDP are shown. The SRCs records the streams of each snippets of SIP/SDP are shown. The SRCs records the streams of each
participant to SRS by mixing in this example. The SRC here could be participant to SRS by mixing in this example. The SRC here is part
part of conference Focus model described in section 3 of [RFC7245]. of conference model described in section 3 of [RFC7245] as a Focus
and does mixing. The SRC here is not a participant by itself and
hence it does not contribute to streams.
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
;remote=00000000000000000000000000000000
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 --foobar
skipping to change at page 20, line 11 skipping to change at page 20, line 15
.... ....
--foobar --foobar
Content-Type: application/rs-metadata Content-Type: application/rs-metadata
Content-Disposition: recording-session 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'> <recording xmlns='urn:ietf:params:xml:ns:recording'>
<datamode>complete</datamode> <datamode>complete</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ=="> <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<start-time>2010-12-16T23:41:07Z</start-time> <start-time>2010-12-16T23:41:07Z</start-time>
<sipSessionID>fa3b60f27e91441e84c55a9a0095f075
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
</session> </session>
<participant <participant
participant_id="srfBElmCRp2QB23b7Mpk0w=="> participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor=sip:alice@atlanta.com> <nameID aor=sip:alice@atlanta.com>
<name xml:lang="it">Alice</name> <name xml:lang="it">Alice</name>
</nameID> </nameID>
</participant> </participant>
<participantsessionassoc <participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==" participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
skipping to change at page 21, line 5 skipping to change at page 21, line 10
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send> <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc> </participantstreamassoc>
<stream id="i1Pz3to5hGk8fuXl+PbwCw==" <stream id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label> <label>96</label>
</stream> </stream>
</recording> </recording>
In the above example there are two participants Alice and Bob in the
conference. Among other things, SRC sends Session-ID in the metadata
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 Bob and Conference Focus. One half of both
these Session-ID's will have the same value (which is added by the
Focus).
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 session. The send
and recv XML elements of a participant is used to indicate whether a and recv XML elements of a participant is used to indicate whether a
participant is sending not sending a particular media stream whose participant is sending not sending a particular media stream whose
properties are represented by stream element. The metadata snapshot properties are represented by stream element. The metadata 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
;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 --foobar
skipping to change at page 23, line 4 skipping to change at page 24, line 4
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send> <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
</participantstreamassoc> </participantstreamassoc>
<stream id="i1Pz3to5hGk8fuXl+PbwCw==" <stream id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label> <label>96</label>
</stream> </stream>
</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
;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 --foobar
skipping to change at page 25, line 5 skipping to change at page 25, line 17
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. The below shows a snapshot sent from SRC to time during the session. The below shows a snapshot sent from SRC to
SRC in these case. Note the SRC here can be a focus or a participant SRC in these case. Note the SRC here can be a focus or a participant
in the conference. In case where the SRC is a participant it may in the conference. In case where the SRC is a participant it may
learn the information required for metadata by subscribing to learn the information required for metadata by subscribing to
conference event package [RFC4575]. Assume Alice and Bob were in the conference event package [RFC4575]. Assume Alice and Bob were in the
conference and a third participant Carol joins, then SRC sends the conference and a third participant Carol joins, then SRC sends the
below snapshot with the indication of new participant. below snapshot with the indication of new participant.
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
;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 --foobar
skipping to change at page 25, line 36 skipping to change at page 25, line 50
a=label:96 a=label:96
a=sendonly a=sendonly
.... ....
--foobar --foobar
Content-Type: application/rs-metadata Content-Type: application/rs-metadata
Content-Disposition: recording-session 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'> <recording xmlns='urn:ietf:params:xml:ns:recording'>
<datamode>partial</datamode> <datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>fa3b60f27e91441e84c55a9a0095f075
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
</session>
<participant <participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameIDaor=sip:carol@example.com> <nameIDaor=sip:carol@example.com>
<name xml:lang="it">Carol</name> <name xml:lang="it">Carol</name>
</nameID> </nameID>
</participant> </participant>
<participantsessionassoc <participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==" participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2013-12-16T23:41:07Z</associate-time> <associate-time>2013-12-16T23:41:07Z</associate-time>
skipping to change at page 26, line 8 skipping to change at page 27, line 4
<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>
Assume Alice drops after some time from the conference. SRC Assume Alice drops after some time from the conference. SRC
generates a new snapshot showing Alice disassociating from the generates a new snapshot showing Alice disassociating from the
session session
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
;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 --foobar
skipping to change at page 26, line 40 skipping to change at page 27, line 37
a=label:96 a=label:96
a=sendonly a=sendonly
.... ....
--foobar --foobar
Content-Type: application/rs-metadata Content-Type: application/rs-metadata
Content-Disposition: recording-session 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'> <recording xmlns='urn:ietf:params:xml:ns:recording'>
<datamode>partial</datamode> <datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
</session>
<participantsessionassoc <participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==" participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time> <associate-time>2010-12-16T23:41:07Z</associate-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, SRC sends BYE with a snapshot of metadata
skipping to change at page 28, line 7 skipping to change at page 29, line 7
participant in Conference. The SRS here could be a SIP UA or an participant in 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 one of the examples 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@8.3.2.12:5060 SIP/2.0 INVITE sip:2001@example.com SIP/2.0
Via: SIP/2.0/UDP 8.3.2.34:5060;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
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
Require: siprec Require: siprec
Accept: application/rs-metadata, Accept: 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 --foobar
skipping to change at page 28, line 45 skipping to change at page 29, line 47
<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.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 turret, audio mixing is done locally before forwarding to In trading floor environments, in order to minimize storage and
the recording server. Sender and receiver audio is mixed for each recording system resources, it may be preferable to mix multiple
communication session. The audio from multiple communication concurrent calls (Communication Sessions) on different handsets/
sessions is also mixed, or multiplexed, in a single RTP session to speakers on the same turret into a single recording session. This
the recording server. would means media in each CS is mixed and recorded as part of single
media stream and multiple such CSs are recording in one Recording
Session from a SRC to SRS.
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
part of single RS from a single SRC which is part of both the CS.
There are three possibilities here:
o CS1 and CS2 uses the same Focus for fixing and that Focus is also
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),
SRC is just one of the participant of the 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
uses the same Focus for fixing and that Focus is also acting as SRC
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
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=00000000000000000000000000000000
Content-Type: application/SDP Content-Type: application/SDP
... ...
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=label:96 a=label:96
a=sendonly a=sendonly
... ...
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording'> <recording xmlns='urn:ietf:params:xml:ns:recording'>
<datamode>complete</datamode> <datamode>complete</datamode>
<group group_id="7+OTCyoxTmqmqyA/1weDAg=="> <group group_id="7+OTCyoxTmqmqyA/1weDAg==">
<associate-time>2010-12-16T23:41:07Z</associate-time> <associate-time>2010-12-16T23:41:07Z</associate-time>
</group> </group>
<session session_id="hVpd7YQgRW2nD22h7q60JQ=="> <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref> <group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<start-time>2010-12-16T23:41:07Z</start-time> <start-time>2010-12-16T23:41:07Z</start-time>
<sipSessionID>fa3b60f27e91441e84c55a9a0095f075
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
</session> </session>
<session session_id="zzlafnvvjlCHllaHF6mn8kkSS=="> <session session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref> <group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<start-time>2010-12-16T23:43:07Z</start-time> <start-time>2010-12-16T23:43:07Z</start-time>
<sipSessionID>ae10731ca50343a5aaae2dd0904a65de
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSession>33c77aac7deb414cbc8c10f363fccb71
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>fd6932e9e5fc489fae2d5b3779723b7e
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
</session> </session>
<participant <participant
participant_id="srfBElmCRp2QB23b7Mpk0w=="> participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor=sip:ram@example.com> <nameID aor=sip:alice@atlanta.com>
<name xml:lang="it">RamMohan R</name> <name xml:lang="it">Alice</name>
</nameID> </nameID>
</participant> </participant>
<participantsessionassoc <participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==" participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time> <associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc> </participantsessionassoc>
<participantstreamassoc <participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="> participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send> <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc> </participantstreamassoc>
<participant <participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor=sip:partha@example.com> <nameID aor=sip:Bob@biloxy.com>
<name xml:lang="it">Parthasarathi R</name> <name xml:lang="it">Bob</name>
</nameID> </nameID>
</participant> </participant>
<participantsessionassoc <participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time> <associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc> </participantsessionassoc>
<participantsessionassoc <participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="zzlafnvvjlCHllaHF6mn8kkSS=="> session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
<associate-time>2010-12-16T23:43:07Z</associate-time> <associate-time>2010-12-16T23:43:07Z</associate-time>
</participantsessionassoc> </participantsessionassoc>
<participantstreamassoc <participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send> <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
skipping to change at page 30, line 19 skipping to change at page 32, line 11
session_id="zzlafnvvjlCHllaHF6mn8kkSS=="> session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
<associate-time>2010-12-16T23:43:07Z</associate-time> <associate-time>2010-12-16T23:43:07Z</associate-time>
</participantsessionassoc> </participantsessionassoc>
<participantstreamassoc <participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send> <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc> </participantstreamassoc>
<participant <participant
participant_id="EiXGlc+4TruqqoDaNE76ag=="> participant_id="EiXGlc+4TruqqoDaNE76ag==">
<nameID aor=sip:paul@example.com> <nameID aor=sip:Carol@example.com>
<name xml:lang="it">Paul</name> <name xml:lang="it">Carol</name>
</nameID> </nameID>
</participant> </participant>
<participantsessionassoc <participantsessionassoc
participant_id="EiXGlc+4TruqqoDaNE76ag==" participant_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="zzlafnvvjlCHllaHF6mn8kkSS=="> session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
<associate-time>2010-12-16T23:43:07Z</associate-time> <associate-time>2010-12-16T23:43:07Z</associate-time>
</participantsessionassoc> </participantsessionassoc>
<participantstreamassoc <participantstreamassoc
participant_id="EiXGlc+4TruqqoDaNE76ag=="> participant_id="EiXGlc+4TruqqoDaNE76ag==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send> <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc> </participantstreamassoc>
<stream id="UAAMm5GRQKSCMVvLyl4rFw==" <stream id="UAAMm5GRQKSCMVvLyl4rFw=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label> <label>96</label>
</stream> </stream>
skipping to change at page 30, line 42 skipping to change at page 32, line 35
</participantstreamassoc> </participantstreamassoc>
<stream id="UAAMm5GRQKSCMVvLyl4rFw==" <stream id="UAAMm5GRQKSCMVvLyl4rFw=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label> <label>96</label>
</stream> </stream>
</recording> </recording>
4. Security Considerations 4. Security Considerations
There is no security consideration as it is informatioal callflow There is no security consideration as it is informational callflow
document. document.
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 for their review comments. Thanks to Ofir Rath, Charles Eckel for their review comments.
skipping to change at page 31, line 23 skipping to change at page 33, line 16
[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,
June 2002. June 2002.
7.2. Informative References 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-metadata-15 (work in progress), draft-ietf-siprec-metadata-17 (work in progress),
February 2014. February 2015.
[RFC7245] Hutton, A., Portman, L., Jain, R., and K. Rehor, "An [RFC7245] Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
Architecture for Media Recording Using the Session Architecture for Media Recording Using the Session
Initiation Protocol", RFC 7245, May 2014. Initiation Protocol", RFC 7245, May 2014.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006. State", RFC 4575, August 2006.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
 End of changes. 62 change blocks. 
75 lines changed or deleted 178 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/