Session Initiation Protocol (SIP) Recording Call Flows
draft-ietf-siprec-callflows-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8068.
|
|
|---|---|---|---|
| Authors | Ram R , Parthasarathi Ravindran , Paul Kyzivat | ||
| Last updated | 2015-07-30 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-07)
by Dan Romascanu
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8068 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-siprec-callflows-05
SIPREC Ram Mohan. Ravindranath
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track Parthasarathi. Ravindran
Expires: January 31, 2016 Nokia Networks
Paul. Kyzivat
Huawei
July 30, 2015
Session Initiation Protocol (SIP) Recording Call Flows
draft-ietf-siprec-callflows-05
Abstract
Session recording is a critical requirement in many communications
environments such as call centers and financial trading. In some of
these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons. Recording of a session
is typically performed by sending a copy of a media stream to a
recording device. This document lists call flows that has snapshot
of metadata sent from SRC to SRS. This is purely an informational
document that is written to support the model defined in the metadata
draft.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Ravindranath, et al. Expires January 31, 2016 [Page 1]
Internet-Draft SIP Recording Callflows July 2015
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Metadata XML schema Instances . . . . . . . . . . . . . . . . 3
3.1. Sample Call flow . . . . . . . . . . . . . . . . . . . . . 3
3.2. Call Scenarios with SRC recording streams with out
mixing . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 5
3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . . 8
3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 11
3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . . 18
3.3. Call Scenarios with SRC recording streams by mixing . . . 20
3.3.1. Example 1: Basic call with SRC mixing streams . . . . 20
3.3.2. Example 2: Hold/resume with SRC recording by
mixing streams . . . . . . . . . . . . . . . . . . . . 22
3.3.3. Example 3: Metadata snapshot of joining/dropping
of a participant to a session . . . . . . . . . . . . 26
3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . . 29
3.4. Call scenarios with persistent RS between SRC and SRS . . 29
3.4.1. Example 1: Metadata snapshot during CS disconnect
with persistent RS between SRC and SRS . . . . . . . . 29
3.5. Turrent-Case: Multiple CS into single RS with mixed
stream . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4. Security Considerations . . . . . . . . . . . . . . . . . . . 33
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 33
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1. Normative References . . . . . . . . . . . . . . . . . . . 34
7.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Ravindranath, et al. Expires January 31, 2016 [Page 2]
Internet-Draft SIP Recording Callflows July 2015
1. Overview
[I-D.ietf-siprec-metadata] document focuses on the Recording metadata
which describes the communication session. The document lists a few
examples and shows the snapshots of metadata sent from SRC to SRS.
For the sake of simplicity the entire SIP [RFC3261] messages are not
shown at various points, instead only a snippets of the SIP/SDP
messages and the XML snapshot of metadata is shown.
2. Terminology
The terms using in this defined are defined in
[I-D.ietf-siprec-metadata]. No new terms/definitions are introduced
in this document.
3. Metadata XML schema Instances
This section describes the metadata model XML instances for different
use cases of SIPREC. For the sake of simplicity the complete SIP/SDP
snippets are NOT shown here.
3.1. Sample Call flow
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
part of any one of the architectures described in section 3 of
[RFC7245].
Ravindranath, et al. Expires January 31, 2016 [Page 3]
Internet-Draft SIP Recording Callflows July 2015
SRC SRS
| |
|(1) INVITE (metadata snapshot) F1 |
|---------------------------------------------------->|
| 200 OK |
|<----------------------------------------------------|
|(3) ACK |
|---------------------------------------------------->|
|(4) RTP |
|====================================================>|
|====================================================>|
|====================================================>|
|====================================================>|
|(5) UPDATE/RE-INVITE (metadata update 1) F2 |
|---------------------------------------------------->|
| 200 OK |
|<----------------------------------------------------|
| ................................................... |
| ................................................... |
| |
|====================================================>|
|====================================================>|
|(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 |
|---------------------------------------------------->|
| 200 OK |
|<----------------------------------------------------|
For the sake of simplicity, ACKs to RE-INVITES and BYEs are not
shown. The subsequent sections describes the snapshot of metadata
sent from SRC to SRS for each of the above transactions (F1 ...
Fn-1). There may be multiple UPDATES/RE-INVITES mid call to
indicates snapshots of different CS changes. Depending on the
architecture described in section 3 of [RFC7245] an SRC may be a
endpoint or B2BUA or as part of MEDIACTRL or Conference Focus. The
subsequent sections in this document tries to list some example
metadata snapshots for three major categories.
o SRC recording streams unmixed to SRS. This includes cases where
SRC is SIP UA or B2BUA.
o SRC recording mixed streams to SRS. This includes cases where SRC
is part of SIP conference model explained in [RFC4353].
o SRC having a persistent RS with SRS.
o Special flows like Turrent flows.
Note that only those examples for which metadata changes are listed
in each category. For some of the call flows the snapshots may be
Ravindranath, et al. Expires January 31, 2016 [Page 4]
Internet-Draft SIP Recording Callflows July 2015
same (like in case of endpoint or B2BUA acting as SRC) and the same
is mentioned in the text preceding the example.
3.2. Call Scenarios with SRC recording streams with out mixing
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
SRS here could be a SIP-UA or an entity part of MEDIACTRL
architecture described in [RFC6230].
3.2.1. Example 1: Basic Call
Basic call between two Participants Alice and Bob who are part of one
CS. In this use case each participant sends two Media Streams.
Media Streams sent by each participant are received all other
participants in this use-case. In this example the SRC is a B2BUA in
the path between Alice and Bob as described in section 3.1.1 of
[RFC7245]. Below is the initial snapshot sent by SRC in the INVITE
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
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Ravindranath, et al. Expires January 31, 2016 [Page 5]
Internet-Draft SIP Recording Callflows July 2015
a=label:96
a=sendonly
...
m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<group group_id="7+OTCyoxTmqmqyA/1weDAg==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
<!-- Standardized extension -->
<call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
<supervisor>sip:alice@atlanta.com</supervisor>
</call-center>
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</group>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>ab30317f1a784dc48ff824d0d3715d86;
remote=47755a9de7794ba387653f2099600ef2</sipSessionID>
<group-ref>7+OTCyoxTmqmqyA/1weDAg==
</group-ref>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</session>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
Ravindranath, et al. Expires January 31, 2016 [Page 6]
Internet-Draft SIP Recording Callflows July 2015
<nameID aor="sip:alice@atlanta.com">
<name xml:lang="it">Alice</name>
</nameID>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</participant>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:bob@biloxy.com">
<name xml:lang="it">Bob</name>
</nameID>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</participant>
<stream stream_id="UAAMm5GRQKSCMVvLyl4rFw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>97</label>
</stream>
<stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>98</label>
</stream>
<stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>99</label>
</stream>
<sessionrecordingassoc session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</sessionrecordingassoc>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
Ravindranath, et al. Expires January 31, 2016 [Page 7]
Internet-Draft SIP Recording Callflows July 2015
</participantsessionassoc>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
3.2.2. Example 2: Hold/resume
Assume a call between two Participants Alice and Bob is established
and a RS is created for recording as in example1. This is the
continuation of above use-case. One of the participants Bob puts
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
participant is sending not sending a particular media stream whose
properties are represented by stream element. SRC sends a snapshot
with only the changed XML elements.
During hold
F2 mid call RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Ravindranath, et al. Expires January 31, 2016 [Page 8]
Internet-Draft SIP Recording Callflows July 2015
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
</participantstreamassoc>
</recording>
Ravindranath, et al. Expires January 31, 2016 [Page 9]
Internet-Draft SIP Recording Callflows July 2015
In the above snippet, Alice with participant_id
srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not
send any media. The same is indicated by the absence of send XML
element. Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other
hand would be sending media but does not receive any media from Alice
and so recv XML element is absent in this instance.
During resume
The snapshot now has send and recv XML elements for both Alice and
Bob indicating that both are receiving and sending media.
F3 mid call RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Ravindranath, et al. Expires January 31, 2016 [Page 10]
Internet-Draft SIP Recording Callflows July 2015
a=label:98
a=sendonly
...
m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
</recording>
3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based)
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
in example 1. Transfer is initiated by one of the
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
Carol gets connected and recording of media between Bob and Carol is
done by SRC. There may be two cases here as described below.
Transfer with in the same session - (.e.g. RE-INVITE based
transfer). Participant Alice drops out and Carol is added to the
same session. No change to session/group element. A
participantsessassoc element indicating that Alice has disassociated
from the CS will be present in the snapshot. A new participant XML
Ravindranath, et al. Expires January 31, 2016 [Page 11]
Internet-Draft SIP Recording Callflows July 2015
element representing Carol with mapping to the same RS SDP stream
used for mapping earlier Alice's stream is sent in the snapshot. A
new sipSessionID XML element that has 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
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
Ravindranath, et al. Expires January 31, 2016 [Page 12]
Internet-Draft SIP Recording Callflows July 2015
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>3363127f0d084c10876dddd4f8e5eeb9
;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID>
</session>
<participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameIDaor="sip:carol@example.com">
<name xml:lang="it">Carol</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2013-12-16T23:41:07Z</associate-time>
</participantsession>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2013-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
<recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>60JAJm9UTvik0Ltlih/Gzw==</send>
<send>AcR5FUd3Edi8cACQJy/3JQ==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
<associate-time>2013-12-16T23:42:07Z</associate-time>
</participantstreamassoc>
</recording>
Transfer with new session - (.e.g. REFER based transfer). In this
Ravindranath, et al. Expires January 31, 2016 [Page 13]
Internet-Draft SIP Recording Callflows July 2015
case a new session (CS) is created and shall be part of same CS-group
(done by SRC).
SRC first sends an optional snapshot indicating disassociation of
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
implicitly indicate that the participants are now part of a different
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
a new RS, it will tear down the current RS using normal SIP
procedures (BYE) with metadata as in example 4.
mid call RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Ravindranath, et al. Expires January 31, 2016 [Page 14]
Internet-Draft SIP Recording Callflows July 2015
a=label:98
a=sendonly
...
m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>Partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<stop-time>2010-12-16T23:41:07Z</stop-time>
</session>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disasociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
Note in the above snapshot the participantsessionassoc element is
optional as indicating session XML element with a stop-time
implicitly means that all the participants associated with that
session have been disassociated.
SRC sends another snapshot to indicate the participant change (due to
REFER) and new session information after transfer. In this example
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
Ravindranath, et al. Expires January 31, 2016 [Page 15]
Internet-Draft SIP Recording Callflows July 2015
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<session session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<start-time>2010-12-16T23:41:07Z</start-time>
Ravindranath, et al. Expires January 31, 2016 [Page 16]
Internet-Draft SIP Recording Callflows July 2015
<sipSessionID>3363127f0d084c10876dddd4f8e5eeb9
;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID>
</session>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:Bob@biloxy.com"/>
</participant>
<participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameID aor="sip:carol@example.com"/>
</participant>
<stream stream_id="60JAJm9UTvik0Ltlih/Gzw=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>96</label>
</stream>
<stream stream_id="AcR5FUd3Edi8cACQJy/3JQ=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>97</label>
</stream>
<stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>98</label>
</stream>
<stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>99</label>
</stream>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<associate-time>2010-12-16T23:32:03Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
<recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>60JAJm9UTvik0Ltlih/Gzw==</send>
<send>AcR5FUd3Edi8cACQJy/3JQ==</send>
Ravindranath, et al. Expires January 31, 2016 [Page 17]
Internet-Draft SIP Recording Callflows July 2015
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
</recording>
3.2.4. Example 4: Call disconnect
This example shows a snapshot of metadata sent by an SRC at CS
disconnect where the participants of CS are Alice and Bob
Ravindranath, et al. Expires January 31, 2016 [Page 18]
Internet-Draft SIP Recording Callflows July 2015
SRC SRS
| |
|(1) BYE (metadata snapshot) F1 |
|---------------------------------------------------->|
| 200 OK F2 |
|<----------------------------------------------------|
F1 BYE SRC -----------> SRS
BYE sip:2001@example.com SIP/2.0
Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 102 BYE
Max-Forwards: 70
Require: siprec
Accept: application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/rs-metadata
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>Partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<stop-time>2010-12-16T23:41:07Z</stop-time>
</session>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disasociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
Ravindranath, et al. Expires January 31, 2016 [Page 19]
Internet-Draft SIP Recording Callflows July 2015
3.3. Call Scenarios with SRC recording streams by mixing
The section covers the models mentioned in the architecture document
in section 3 of [RFC7245] where an SRC may be part of Conference
model either as Focus or a participant in Conference. The SRS here
could be a SIP UA or an entity part of MEDIACTRL architecture. Note
that the disconnect case is not shown since the metadata snapshot
will be same as for a non-mixing case.
3.3.1. Example 1: Basic call with SRC mixing streams
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
(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 the other participant. Below is the initial snapshot sent by SRC
in the INVITE 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 by mixing in this example. The
SRC here is part 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
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=00000000000000000000000000000000
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Ravindranath, et al. Expires January 31, 2016 [Page 20]
Internet-Draft SIP Recording Callflows July 2015
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<start-time>2010-12-16T23:41:07Z</start-time>
<sipSessionID>fa3b60f27e91441e84c55a9a0095f075
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID>
</session>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:alice@atlanta.com">
<name xml:lang="it">Alice</name>
</nameID>
</participant>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:bob@biloxy.com">
<name xml:lang="it">Bob</name>
</nameID>
</participant>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
Ravindranath, et al. Expires January 31, 2016 [Page 21]
Internet-Draft SIP Recording Callflows July 2015
</participantsessionassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
In the above example there are two participants Alice and Bob in the
conference. Among other things, 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. In this use-case,
since Alice and Bob calls into the conference these Session-ID's are
different.
3.3.2. Example 2: Hold/resume with SRC recording by mixing streams
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
continuation of above use-case. One of the participants Bob puts
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
participant is sending not sending a particular media stream whose
properties are represented by stream element. The metadata snapshot
looks as below:
During hold
Ravindranath, et al. Expires January 31, 2016 [Page 22]
Internet-Draft SIP Recording Callflows July 2015
mid call hold RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
</participantstreamassoc>
</recording>
Ravindranath, et al. Expires January 31, 2016 [Page 23]
Internet-Draft SIP Recording Callflows July 2015
During resume a snapshot shown below will be sent from SRC to SRS
Ravindranath, et al. Expires January 31, 2016 [Page 24]
Internet-Draft SIP Recording Callflows July 2015
mid call resume RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
Ravindranath, et al. Expires January 31, 2016 [Page 25]
Internet-Draft SIP Recording Callflows July 2015
3.3.3. Example 3: Metadata snapshot of joining/dropping of a
participant to a session
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
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
learn the information required for metadata by subscribing to
conference event package [RFC4575]. Assume Alice and Bob were in the
conference and a third participant Carol joins, then SRC sends the
below snapshot with the indication of new participant.
mid call resume RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
Ravindranath, et al. Expires January 31, 2016 [Page 26]
Internet-Draft SIP Recording Callflows July 2015
<sipSessionID>fa3b60f27e91441e84c55a9a0095f075
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID>
<sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID>
</session>
<participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameID aor="sip:carol@example.com">
<name xml:lang="it">Carol</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2013-12-16T23:41:07Z</associate-time>
</participantsession>
<participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
Assume Alice drops after some time from the conference. SRC
generates a new snapshot showing Alice disassociating from the
session
Ravindranath, et al. Expires January 31, 2016 [Page 27]
Internet-Draft SIP Recording Callflows July 2015
mid call resume RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID>
<sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID>
</session>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
</recording>
Ravindranath, et al. Expires January 31, 2016 [Page 28]
Internet-Draft SIP Recording Callflows July 2015
3.3.4. Example 4: Call disconnect
When a CS is disconnected, SRC sends BYE with a snapshot of metadata
having session stop-time and participant dis-associate times. The
snapshot looks same as listed in section 3.2.4
3.4. Call scenarios with persistent RS between SRC and SRS
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
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
entity part of MEDIACTRL architecture. Except disconnect case, the
snapshot remains same as one of the examples mentioned in previous
sections.
3.4.1. Example 1: Metadata snapshot during CS disconnect with
persistent RS between SRC and SRS
Ravindranath, et al. Expires January 31, 2016 [Page 29]
Internet-Draft SIP Recording Callflows July 2015
RE-INVITE sent from SRC -----------> SRS
INVITE sip:2001@example.com SIP/2.0
Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/rs-metadata
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>Partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<stop-time>2010-12-16T23:41:07Z</stop-time>
</session>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disasociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
3.5. Turrent-Case: Multiple CS into single RS with mixed stream
In trading floor environments, in order to minimize storage and
recording system resources, it may be preferable to mix multiple
concurrent calls (Communication Sessions) on different handsets/
speakers on the same turret into a single recording session. This
Ravindranath, et al. Expires January 31, 2016 [Page 30]
Internet-Draft SIP Recording Callflows July 2015
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
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=00000000000000000000000000000000
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<group group_id="7+OTCyoxTmqmqyA/1weDAg==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</group>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<start-time>2010-12-16T23:41:07Z</start-time>
<sipSessionID>fa3b60f27e91441e84c55a9a0095f075
Ravindranath, et al. Expires January 31, 2016 [Page 31]
Internet-Draft SIP Recording Callflows July 2015
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
</session>
<session session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<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>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:alice@atlanta.com">
<name xml:lang="it">Alice</name>
</nameID>
</participant>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:Bob@biloxy.com">
<name xml:lang="it">Bob</name>
</nameID>
</participant>
<participant
participant_id="EiXGlc+4TruqqoDaNE76ag==">
<nameID aor="sip:Carol@example.com">
<name xml:lang="it">Carol</name>
</nameID>
</participant>
<stream stream_id="UAAMm5GRQKSCMVvLyl4rFw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
Ravindranath, et al. Expires January 31, 2016 [Page 32]
Internet-Draft SIP Recording Callflows July 2015
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
<associate-time>2010-12-16T23:43:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
<associate-time>2010-12-16T23:43:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="EiXGlc+4TruqqoDaNE76ag==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
</recording>
4. Security Considerations
There is no security consideration as it is informational callflow
document.
5. IANA Considerations
This document has no IANA considerations
6. Acknowledgement
Thanks to Ofir Rath, Charles Eckel and Yaron Pdut for their review
comments.
7. References
Ravindranath, et al. Expires January 31, 2016 [Page 33]
Internet-Draft SIP Recording Callflows July 2015
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]
R, R., Ravindran, P., and P. Kyzivat, "Session Initiation
Protocol (SIP) Recording Metadata",
draft-ietf-siprec-metadata-17 (work in progress),
February 2015.
[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
"An Architecture for Media Recording Using the Session
Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245,
May 2014, <http://www.rfc-editor.org/info/rfc7245>.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
Session Initiation Protocol (SIP) Event Package for
Conference State", RFC 4575, DOI 10.17487/RFC4575,
August 2006, <http://www.rfc-editor.org/info/rfc4575>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
DOI 10.17487/RFC4353, February 2006,
<http://www.rfc-editor.org/info/rfc4353>.
[RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework", RFC 6230, DOI 10.17487/
RFC6230, May 2011,
<http://www.rfc-editor.org/info/rfc6230>.
Ravindranath, et al. Expires January 31, 2016 [Page 34]
Internet-Draft SIP Recording Callflows July 2015
Authors' Addresses
Ram Mohan Ravindranath
Cisco Systems, Inc.
Cessna Business Park,
Kadabeesanahalli Village, Varthur Hobli,
Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: rmohanr@cisco.com
Parthasarathi Ravindran
Nokia Networks
Bangalore, Karnataka
India
Email: partha@parthasarathi.co.in
Paul Kyzivat
Huawei
Hudson, MA
USA
Email: pkyzivat@alum.mit.edu
Ravindranath, et al. Expires January 31, 2016 [Page 35]