draft-ietf-siprec-callflows-00.txt   draft-ietf-siprec-callflows-01.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: September 26, 2013 Nokia Siemens Networks Expires: January 14, 2014 Nokia Siemens Networks
Paul. Kyzivat Paul. Kyzivat
Huawei Huawei
March 25, 2013 July 13, 2013
Session Initiation Protocol (SIP) Recording Call Flows Session Initiation Protocol (SIP) Recording Call Flows
draft-ietf-siprec-callflows-00 draft-ietf-siprec-callflows-01
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, the metadata format for which is
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 September 26, 2013. This Internet-Draft will expire on January 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Example 1: Basic Call . . . . . . . . . . . . . . . . . . 5 3.2. Call Scenarios with SRC recording streams with out
3.3. Example 2: Hold/resume . . . . . . . . . . . . . . . . . . 7 mixing . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Example 3: Basic Call with transfer . . . . . . . . . . . 10 3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 5
3.5. Example 4: Call disconnect . . . . . . . . . . . . . . . . 14 3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . . 7
3.6. Example 5: Multiple CS into single RS with mixed stream . 15 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 3.3. Call Scenarios with SRC recording streams by mixing . . . 18
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.1. Example 1: Basic call with SRC mixing streams . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3.2. Example 2: Hold/resume with SRC recording by
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 mixing streams . . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 18 3.3.3. Example 3: Metadata snapshot of joining/dropping
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 of a participant to a session . . . . . . . . . . . . 23
3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . . 26
3.4. Call scenarios with persistent RS between SRC and SRS . . 26
3.4.1. Example 1: Metadata snapshot during CS disconnect
with persistent RS between SRC and SRS . . . . . . . . 26
3.5. Turrent-Case: Multiple CS into single RS with mixed
stream . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4. Security Considerations . . . . . . . . . . . . . . . . . . . 29
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Normative References . . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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 snip of the SIP/SDP message shown at various points, instead only a snippets of the SIP/SDP
and the XML snapshot of metadata is shown. This document is messages and the XML snapshot of metadata is shown.
informational and is not normative on any aspect of SIPREC.
2. Terminology 2. Terminology
The terms using in this defined are defined in The terms using in this defined are defined in
[I-D.ietf-siprec-metadata]. No new terms/definitions are introduced [I-D.ietf-siprec-metadata]. No new terms/definitions are introduced
in this document. in this document.
3. Metadata XML schema Instances 3. Metadata XML schema Instances
This section describes the metadata model XML instances for different This section describes the metadata model XML instances for different
use cases of SIPREC. For the sake of simplicity the complete SIP use cases of SIPREC. For the sake of simplicity the complete SIP/SDP
messages are NOT shown here. snippets are NOT shown here.
3.1. Sample Call flow 3.1. Sample Call flow
The following is a sample call flow that shows the SRC establishing a The following is a sample call flow that shows the SRC establishing a
recording session towards the SRS. The call flow is essentially recording session towards the SRS. The SRC in this example could be
identical when the SRC is a B2BUA or as the endpoint itself. Note part of any one of the architectures described in section 3 of
that the SRC can choose when to establish the Recording Session [I-D.ietf-siprec-architecture].
independent of the Communication Session, even though the following
call flow suggests that the SRC is establishing the Recording Session
(message #5) after the Communication Session is established.
UA A SRC UA B SRS
|(1)CS INVITE | | |
|------------->| | |
| |(2)CS INVITE | |
| |---------------------->| |
| | (3) 200 OK | |
| |<----------------------| |
| (4) 200 OK | | |
|<-------------| | |
| |(5)RS INVITE with SDP | |
| |--------------------------------------------->|
| | | (6) 200 OK with SDP |
| |<---------------------------------------------|
|(7)CS RTP | | |
|=============>|======================>| |
|<=============|<======================| |
| |(8)RS RTP | |
| |=============================================>|
| |=============================================>|
| | | |
| Mid call updates(hold/resume/re-invite(new offer) |
| | | |
|(9)CS BYE | | |
|------------->| | |
| |(10)CS BYE | |
| |---------------------->| |
| |(11)RS BYE | |
| |--------------------------------------------->|
| | | |
The above call flow can also apply to the case of a centralized
conference with a mixer. For clarity, ACKs to INVITEs and 200 OKs to
BYEs are not shown. The conference focus can provide the SRC
functionality since the conference focus has access to all the media
from each conference participant. When a recording is requested, the
SRC delivers the metadata and the media streams to the SRS. Since
the conference focus has access to a mixer, the SRC may choose to mix
the media streams from all participants as a single mixed media
stream towards the SRS.
An SRC can use a single recording session to record multiple
communication sessions. Every time the SRC wants to record a new
call, the SRC updates the recording session with a new SDP offer to
add new recorded streams to the recording session, and
correspondingly also update the metadata for the new call.
3.2. Example 1: Basic Call
SRC SRS SRC SRS
| | | |
|(1) INVITE (metadata snapshot) F1 | |(1) INVITE (metadata snapshot) F1 |
|---------------------------------------------------->| |---------------------------------------------------->|
| 200 OK F2 | | 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
|(3) ACK F3 | |(3) ACK |
|---------------------------------------------------->| |---------------------------------------------------->|
|(4) RTP | |(4) RTP |
|====================================================>| |====================================================>|
|====================================================>| |====================================================>|
|====================================================>| |====================================================>|
|====================================================>| |====================================================>|
|(5) UPDATE/RE-INVITE (metadata update 1) F4 | |(5) UPDATE/RE-INVITE (metadata update 1) F2 |
|---------------------------------------------------->| |---------------------------------------------------->|
| 200 OK F5 | | 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
| ................................................... |
| ................................................... |
| |
|====================================================>| |====================================================>|
|====================================================>| |====================================================>|
|(7) UPDATE/RE-INVITE (metadata update 2) F6 | |(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 |
|---------------------------------------------------->| |---------------------------------------------------->|
| 200 OK F7 | | 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
Basic call between two Participants Ram and Partha who are part of For the sake of simplicity, ACKs to RE-INVITES and BYEs are not
one session. In this use case each participant sends two Media shown. The subsequent sections describes the snapshot of metadata
Streams. Media Streams sent by each participant are received all sent from SRC to SRS for each of the above transactions (F1 ...
other participants of that CS in this use-case. Below is the initial Fn-1). There may be multiple UPDATES/RE-INVITES mid call to
snapshot sent by SRC in the INVITE to SRS that has complete metadata. indicates snapshots of different CS changes. Depending on the
For the sake of simplicity snippets of SDP are shown. Here the RS architecture described in section 3 of [I-D.ietf-siprec-architecture]
stream is unmixed. 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
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 [I-D.ietf-siprec-architecture] 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. 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 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
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 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
... ...
m=video 49174 RTP/AVPF 96 m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000 a=rtpmap:96 H.264/90000
a=label:97 a=label:97
a=sendonly a=sendonly
... ...
m=audio 51372 RTP/AVP 0 m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=label:98 a=label:98
a=sendonly a=sendonly
... ...
skipping to change at page 6, line 20 skipping to change at page 6, line 17
m=audio 51372 RTP/AVP 0 m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=label:98 a=label:98
a=sendonly a=sendonly
... ...
m=video 49176 RTP/AVPF 96 m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000 a=rtpmap:96 H.264/90000
a=label:99 a=label:99
a=sendonly a=sendonly
.... ....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording'> <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>
</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>i1Pz3to5hGk8fuXl+PbwCw==</send> <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<send>UAAMm5GRQKSCMVvLyl4rFw==</send> <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv> <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv> <recv>EiXGlc+4TruqqoDaNE76ag==</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="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>
<participantstreamassoc <participantstreamassoc
participant="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send> <send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send> <send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc> </participantstreamassoc>
<stream id="UAAMm5GRQKSCMVvLyl4rFw==" <stream id="UAAMm5GRQKSCMVvLyl4rFw=="
session="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label> <label>96</label>
</stream> </stream>
<stream id="i1Pz3to5hGk8fuXl+PbwCw==" <stream id="i1Pz3to5hGk8fuXl+PbwCw=="
session="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>97</label> <label>97</label>
</stream> </stream>
<stream id="8zc6e0lYTlWIINA6GR+3ag==" <stream id="8zc6e0lYTlWIINA6GR+3ag=="
session="zSfPoSvdSDCmU3A3TRDxAw=="> session_id="zSfPoSvdSDCmU3A3TRDxAw==">
<label>98</label> <label>98</label>
</stream> </stream>
<stream id="EiXGlc+4TruqqoDaNE76ag==" <stream id="EiXGlc+4TruqqoDaNE76ag=="
session="zSfPoSvdSDCmU3A3TRDxAw=="> session_id="zSfPoSvdSDCmU3A3TRDxAw==">
<label>99</label> <label>99</label>
</stream> </stream>
</recording> </recording>
3.3. Example 2: Hold/resume 3.2.2. Example 2: Hold/resume
Basic call between two Participants Ram and Partha. This is the Assume a call between two Participants Alice and Bob is established
continuation of above use-case. One of the participants(say Ram) and a RS is created for recording as in example1. This is the
goes on hold and then resumes as part of the same session. The continuation of above use-case. One of the participants Bob puts
metadata snapshot looks as below 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 During hold
F4 RE-INVITE SRC-------------------->SRS 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
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 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=inactive a=sendonly
... ...
m=video 49174 RTP/AVPF 96 m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000 a=rtpmap:96 H.264/90000
a=label:97 a=label:97
a=inactive a=sendonly
... ...
m=audio 51372 RTP/AVP 0 m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=label:98 a=label:98
a=sendonly a=sendonly
... ...
m=video 49176 RTP/AVPF 96 m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000 a=rtpmap:96 H.264/90000
a=label:99 a=label:99
a=sendonly a=sendonly
.... ....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording'> <recording xmlns='urn:ietf:params:xml:ns:recording'>
<datamode>partial</datamode> <datamode>partial</datamode>
<participantstreamassoc <participantstreamassoc
participant="srfBElmCRp2QB23b7Mpk0w=="> participant_id="srfBElmCRp2QB23b7Mpk0w==">
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv> <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv> <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc> </participantstreamassoc>
<participantstreamassoc <participantstreamassoc
participant="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send> <send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send> <send>EiXGlc+4TruqqoDaNE76ag==</send>
</participantstreamassoc> </participantstreamassoc>
<stream id="UAAMm5GRQKSCMVvLyl4rFw=="
session="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<stream id="i1Pz3to5hGk8fuXl+PbwCw=="
session="hVpd7YQgRW2nD22h7q60JQ==">
<label>97</label>
</stream>
<stream id="8zc6e0lYTlWIINA6GR+3ag=="
session="zSfPoSvdSDCmU3A3TRDxAw==">
<label>98</label>
</stream>
<stream id="EiXGlc+4TruqqoDaNE76ag=="
session="zSfPoSvdSDCmU3A3TRDxAw==">
<label>99</label>
</stream>
</recording> </recording>
In the above snippet during Alice with participant_id
srfBElmCRp2QB23b7Mpk0w== only receives media streams since Alice is
put on hold 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 During resume
The snapshot will look pretty much same as above with just the SDP The snapshot now has send and recv XML elements for both Alice and
dir change. Bob indicating that both are receiving and sending media.
F5 RE-INVITE SRC-------------------->SRS 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
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 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
... ...
m=video 49174 RTP/AVPF 96 m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000 a=rtpmap:96 H.264/90000
a=label:97 a=label:97
skipping to change at page 9, line 34 skipping to change at page 10, line 18
m=audio 51372 RTP/AVP 0 m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=label:98 a=label:98
a=sendonly a=sendonly
... ...
m=video 49176 RTP/AVPF 96 m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000 a=rtpmap:96 H.264/90000
a=label:99 a=label:99
a=sendonly a=sendonly
.... ....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording'> <recording xmlns='urn:ietf:params:xml:ns:recording'>
<datamode>partial</datamode> <datamode>partial</datamode>
<participantstreamassoc <participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="> participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv> <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv> <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc> <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<participantstreamassoc <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
participant="zSfPoSvdSDCmU3A3TRDxAw=="> </participantstreamassoc>
<send>8zc6e0lYTlWIINA6GR+3ag==</send> <participantstreamassoc
<send>EiXGlc+4TruqqoDaNE76ag==</send> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> <send>8zc6e0lYTlWIINA6GR+3ag==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <send>EiXGlc+4TruqqoDaNE76ag==</send>
</participantstreamassoc> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
</recording>
<stream id="UAAMm5GRQKSCMVvLyl4rFw==" 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based)
session="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<stream id="i1Pz3to5hGk8fuXl+PbwCw=="
session="hVpd7YQgRW2nD22h7q60JQ==">
<label>97</label>
</stream>
<stream id="8zc6e0lYTlWIINA6GR+3ag=="
session="zSfPoSvdSDCmU3A3TRDxAw==">
<label>98</label>
</stream>
<stream id="EiXGlc+4TruqqoDaNE76ag=="
session="zSfPoSvdSDCmU3A3TRDxAw==">
<label>99</label>
</stream>
</recording> Basic call between two Participants Alice and Bob is connected and
SRC 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.
3.4. Example 3: Basic Call with transfer 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
element representing Carol with mapping to the same RS SDP stream
used for mapping earlier Alice's stream is sent in the snapshot.
Basic call between two Participants Ram and Partha is connected as in mid call RE-INVITE SRC-------------------->SRS
Use-case 1. Transfer is initiated by one of the participants or by
other entity(3PCC case). SRC sends a snapshot of the participant
changes to SRS. In this instance participant Ram drops out during
the transfer and Participant Paul joins the session. There can be
two cases here, same session continues after transfer or a new
session (e.g. REFER based transfer) is created
Transfer with same session retained - (.e.g. RE-INVITE based INVITE sip:recorder@example.com SIP/2.0
transfer). Participant Ram drops out and Paul is added to the same Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
session. No change to session/group element. Paul will have new From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
stream element which maps to RS SDP using the same labels in this To: <sip:recorder@example.com>
instance. Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
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]
Content-Type: application/SDP --foobar
... Content-Type: application/SDP
m=audio 49170 RTP/AVP 0 ...
a=rtpmap:0 PCMU/8000 m=audio 49180 RTP/AVP 0
a=label:96 a=rtpmap:0 PCMU/8000
a=sendonly a=label:96
... a=sendonly
m=video 49174 RTP/AVPF 96 ...
a=rtpmap:96 H.264/90000 m=video 49182 RTP/AVPF 96
a=label:97 a=rtpmap:96 H.264/90000
a=sendonly a=label:97
... a=sendonly
m=audio 51372 RTP/AVP 0 ...
a=rtpmap:0 PCMU/8000 m=audio 51374 RTP/AVP 0
a=label:98 a=rtpmap:0 PCMU/8000
a=sendonly a=label:98
... a=sendonly
m=video 49176 RTP/AVPF 96 ...
a=rtpmap:96 H.264/90000 m=video 49178 RTP/AVPF 96
a=label:99 a=rtpmap:96 H.264/90000
a=sendonly a=label:99
.... a=sendonly
<?xml version="1.0" encoding="UTF-8"?> ....
<recording xmlns='urn:ietf:params:xml:ns:recording'> --foobar
<datamode>partial</datamode> Content-Type: application/rs-metadata
<participantstreamassoc Content-Disposition: recording-session
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send> <?xml version="1.0" encoding="UTF-8"?>
<send>EiXGlc+4TruqqoDaNE76ag==</send> <recording xmlns='urn:ietf:params:xml:ns:recording'>
<recv>60JAJm9UTvik0Ltlih/Gzw==</recv> <datamode>partial</datamode>
<recv>AcR5FUd3Edi8cACQJy/3JQ==</recv> <participantsessionassoc
</participantstreamassoc> participant_id="srfBElmCRp2QB23b7Mpk0w=="
<participant session_id="hVpd7YQgRW2nD22h7q60JQ==">
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> <disassociate-time>2013-12-16T23:41:07Z</disassociate-time>
<nameIDaor=sip:paul@example.com> </participantsessionassoc>
<name xml:lang="it">Paul Kyzivat</name> <participantstreamassoc
</nameID> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
</participant> <send>8zc6e0lYTlWIINA6GR+3ag==</send>
<participantsessionassoc <send>EiXGlc+4TruqqoDaNE76ag==</send>
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==" <recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
session_id="hVpd7YQgRW2nD22h7q60JQ=="> <recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
<associate-time>2010-12-16T23:41:07Z</associate-time> </participantstreamassoc>
</participantsession> <participant
<participantstreamassoc participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> <nameIDaor=sip:carol@example.com>
<send>60JAJm9UTvik0Ltlih/Gzw==</send> <name xml:lang="it">Carol</name>
<send>AcR5FUd3Edi8cACQJy/3JQ==</send> </nameID>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv> </participant>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv> <participantsessionassoc
<associate-time>2010-12-16T23:41:07Z</associate-time> participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
</participantstreamassoc> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<stream stream_id="60JAJm9UTvik0Ltlih/Gzw==" <associate-time>2013-12-16T23:41:07Z</associate-time>
session_id="hVpd7YQgRW2nD22h7q60JQ=="> </participantsession>
<label>96</label> <participantstreamassoc
</stream> participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<stream stream_id="AcR5FUd3Edi8cACQJy/3JQ==" <send>60JAJm9UTvik0Ltlih/Gzw==</send>
session_id="hVpd7YQgRW2nD22h7q60JQ=="> <send>AcR5FUd3Edi8cACQJy/3JQ==</send>
<label>97</label> <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
</stream> <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
<stream stream_id="8zc6e0lYTlWIINA6GR+3ag==" <associate-time>2013-12-16T23:42:07Z</associate-time>
session_id="zSfPoSvdSDCmU3A3TRDxAw=="> </participantstreamassoc>
<label>98</label> </recording>
</stream>
<stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="zSfPoSvdSDCmU3A3TRDxAw==">
<label>99</label>
</stream>
</recording>
Transfer with new session - (.e.g. REFER based transfer). In this Transfer with new session - (.e.g. REFER based transfer). In this
case new session is part of same grouping (done by SRC). case a new session (CS) is created and shall be part of same CS-group
(done by SRC).
SRC may send an optional snapshot indicating stop for the old SRC first sends an optional snapshot indicating disassociation of
session. 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
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
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=="> <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<stop-time>2010-12-16T23:41:07Z</stop-time> <stop-time>2010-12-16T23:41:07Z</stop-time>
</session> </session>
<participantsessionassoc <participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==" participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time> <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc> </participantsessionassoc>
<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>
SRC sends a snapshot to indicate the participant change and new Note in the above snapshot the participantsessionassoc element is
session information after transfer. In this example the same RS is optional as indicating session XML element with a stop-time
used. implicitly means that all the participants associated with that
session have been disassociated.
Content-Type: application/SDP 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.
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
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 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 49174 RTP/AVPF 96 m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000 a=rtpmap:96 H.264/90000
a=label:97 a=label:97
a=sendonly a=sendonly
... ...
m=audio 51372 RTP/AVP 0 m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=label:98 a=label:98
a=sendonly a=sendonly
... ...
m=video 49176 RTP/AVPF 96 m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000 a=rtpmap:96 H.264/90000
a=label:99 a=label:99
a=sendonly a=sendonly
.... ....
--foobar
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>partial</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>
</session> </session>
<participant <participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor=sip:partha@example.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>
<recv>60JAJm9UTvik0Ltlih/Gzw==</recv> <recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
<recv>AcR5FUd3Edi8cACQJy/3JQ==</recv> <recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
</participantstreamassoc> </participantstreamassoc>
<participant <participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameID aor=sip:paul@example.com/> <nameID aor=sip:carol@example.com/>
</participant> </participant>
<participantsessionassoc <participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==" participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<associate-time>2010-12-16T23:41:07Z</associate-time> <associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc> </participantsessionassoc>
<participantstreamassoc <participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>60JAJm9UTvik0Ltlih/Gzw==</send> <send>60JAJm9UTvik0Ltlih/Gzw==</send>
<send>AcR5FUd3Edi8cACQJy/3JQ==</send> <send>AcR5FUd3Edi8cACQJy/3JQ==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv> <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv> <recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc> </participantstreamassoc>
<stream stream_id="60JAJm9UTvik0Ltlih/Gzw==" <stream stream_id="60JAJm9UTvik0Ltlih/Gzw=="
skipping to change at page 14, line 32 skipping to change at page 16, line 46
<stream stream_id="8zc6e0lYTlWIINA6GR+3ag==" <stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>98</label> <label>98</label>
</stream> </stream>
<stream stream_id="EiXGlc+4TruqqoDaNE76ag==" <stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>99</label> <label>99</label>
</stream> </stream>
</recording> </recording>
3.5. Example 4: Call disconnect 3.2.4. Example 4: Call disconnect
This example shows a snapshot of metadata sent by an SRC at CS This example shows a snapshot of metadata sent by an SRC at CS
disconnect where the participants of CS are Ram and Partha 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
Via: SIP/2.0/UDP 8.3.2.34:5060;branch=z9hG4bK47c8eb30
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
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"?> <?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=="> <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<stop-time>2010-12-16T23:41:07Z</stop-time> <stop-time>2010-12-16T23:41:07Z</stop-time>
</session> </session>
<participantsessionassoc <participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==" participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ=="> session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time> <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc> </participantsessionassoc>
<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.6. Example 5: Multiple CS into single RS with mixed stream 3.3. Call Scenarios with SRC recording streams by mixing
The section covers the models mentioned in the architecture document
in section 3 of [I-D.ietf-siprec-architecture] 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 sends one Media Streams.
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 could be
part of conference Focus model described in section 3 of
[I-D.ietf-siprec-architecture].
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
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'>
<datamode>complete</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<start-time>2010-12-16T23:41:07Z</start-time>
</session>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor=sip:alice@atlanta.com>
<name xml:lang="it">Alice</name>
</nameID>
</participant>
<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>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor=sip:bob@biloxy.com>
<name xml:lang="it">Bob</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
<stream id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
</recording>
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
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
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'>
<datamode>partial</datamode>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
</participantstreamassoc>
<stream id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
</recording>
During resume a snapshot shown below will be sent from SRC to SRS
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
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'>
<datamode>partial</datamode>
<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>
<stream id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
</recording>
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
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'>
<datamode>partial</datamode>
<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>
<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
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
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'>
<datamode>partial</datamode>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
</recording>
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
RE-INVITE sent from SRC -----------> SRS
INVITE sip:2001@8.3.2.12:5060 SIP/2.0
Via: SIP/2.0/UDP 8.3.2.34:5060;branch=z9hG4bK47c8eb30
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
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'>
<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 turret, audio mixing is done locally before forwarding to In trading turret, audio mixing is done locally before forwarding to
the recording server. Sender and receiver audio is mixed for each the recording server. Sender and receiver audio is mixed for each
communication session. The audio from multiple communication communication session. The audio from multiple communication
sessions is also mixed, or multiplexed, in a single RTP session to sessions is also mixed, or multiplexed, in a single RTP session to
the recording server. the recording server.
F1 INVITE SRC --------------> SRS snapshot of metadata INVITE SRC --------------> SRS
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'>
skipping to change at page 16, line 43 skipping to change at page 28, line 51
<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:partha@example.com>
<name xml:lang="it">Parthasarathi R</name> <name xml:lang="it">Parthasarathi R</name>
</nameID> </nameID>
</participant> </participant>
<participantsessionassoc <participantsessionassoc
participant="zSfPoSvdSDCmU3A3TRDxAw==" participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session="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="zSfPoSvdSDCmU3A3TRDxAw==" participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session="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="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:paul@example.com>
<name xml:lang="it">Paul</name> <name xml:lang="it">Paul</name>
</nameID> </nameID>
</participant> </participant>
<participantsessionassoc <participantsessionassoc
participant="EiXGlc+4TruqqoDaNE76ag==" participant_id="EiXGlc+4TruqqoDaNE76ag=="
session="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="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="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 informatioal callflow
document. document.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 18, line 16 skipping to change at page 30, line 23
[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-11 (work in progress), draft-ietf-siprec-metadata-12 (work in progress),
January 2013. May 2013.
[I-D.ietf-siprec-architecture]
Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
Architecture for Media Recording using the Session
Initiation Protocol", draft-ietf-siprec-architecture-08
(work in progress), May 2013.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
[RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework", RFC 6230, May 2011.
Authors' Addresses Authors' Addresses
Ram Mohan Ravindranath Ram Mohan Ravindranath
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Cessna Business Park,
Kadabeesanahalli Village, Varthur Hobli, Kadabeesanahalli Village, Varthur Hobli,
Sarjapur-Marathahalli Outer Ring Road Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
 End of changes. 78 change blocks. 
269 lines changed or deleted 776 lines changed or added

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