SIPREC Ram Mohan. Ravindranath
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track Parthasarathi. Ravindran
Expires: August 29, 2013 Nokia Siemens Networks
Paul. Kyzivat
Huawei
February 25, 2013
Session Initiation Protocol (SIP) Recording Call Flows
draft-ram-siprec-callflows-03
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, the metadata format for which is
described in [I-D.ietf-siprec-metadata] . 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 August 29, 2013.
Copyright Notice
Copyright (c) 2013 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
Ravindranath, et al. Expires August 29, 2013 [Page 1]
Internet-Draft SIP Recording Callflows February 2013
Provisions Relating to IETF Documents
(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. Example 1: Basic Call . . . . . . . . . . . . . . . . . . 5
3.3. Example 2: Hold/resume . . . . . . . . . . . . . . . . . . 7
3.4. Example 3: Basic Call with transfer . . . . . . . . . . . 10
3.5. Example 4: Call disconnect . . . . . . . . . . . . . . . . 14
3.6. Example 5: Multiple CS into single RS with mixed stream . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Ravindranath, et al. Expires August 29, 2013 [Page 2]
Internet-Draft SIP Recording Callflows February 2013
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 snip of the SIP/SDP message
and the XML snapshot of metadata is shown. This document is
informational and is not normative on any aspect of SIPREC.
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
messages 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 call flow is essentially
identical when the SRC is a B2BUA or as the endpoint itself. Note
that the SRC can choose when to establish the Recording Session
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.
Ravindranath, et al. Expires August 29, 2013 [Page 3]
Internet-Draft SIP Recording Callflows February 2013
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.
Ravindranath, et al. Expires August 29, 2013 [Page 4]
Internet-Draft SIP Recording Callflows February 2013
3.2. Example 1: Basic Call
SRC SRS
| |
|(1) INVITE (metadata snapshot) F1 |
|---------------------------------------------------->|
| 200 OK F2 |
|<----------------------------------------------------|
|(3) ACK F3 |
|---------------------------------------------------->|
|(4) RTP |
|====================================================>|
|====================================================>|
|====================================================>|
|====================================================>|
|(5) UPDATE/RE-INVITE (metadata update 1) F4 |
|---------------------------------------------------->|
| 200 OK F5 |
|<----------------------------------------------------|
|====================================================>|
|====================================================>|
|(7) UPDATE/RE-INVITE (metadata update 2) F6 |
|---------------------------------------------------->|
| 200 OK F7 |
|<----------------------------------------------------|
Basic call between two Participants Ram and Partha who are part of
one session. In this use case each participant sends two Media
Streams. Media Streams sent by each participant are received all
other participants of that CS 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 snippets of SDP are shown. Here the RS
stream is unmixed.
F1 INVITE SRC --------------> SRS
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
Ravindranath, et al. Expires August 29, 2013 [Page 5]
Internet-Draft SIP Recording Callflows February 2013
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
....
<?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:ram@example.com>
<name xml:lang="it">RamMohan R</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>
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor=sip:partha@example.com>
<name xml:lang="it">Parthasarathi R</name>
</nameID>
</participant>
<participantsessionassoc
participant="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
Ravindranath, et al. Expires August 29, 2013 [Page 6]
Internet-Draft SIP Recording Callflows February 2013
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</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>
3.3. Example 2: Hold/resume
Basic call between two Participants Ram and Partha. This is the
continuation of above use-case. One of the participants(say Ram)
goes on hold and then resumes as part of the same session. The
metadata snapshot looks as below
During hold
F4 RE-INVITE SRC-------------------->SRS
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=inactive
Ravindranath, et al. Expires August 29, 2013 [Page 7]
Internet-Draft SIP Recording Callflows February 2013
...
m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=inactive
...
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
....
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording'>
<datamode>partial</datamode>
<participantstreamassoc
participant="srfBElmCRp2QB23b7Mpk0w==">
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<participantstreamassoc
participant="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
</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>
Ravindranath, et al. Expires August 29, 2013 [Page 8]
Internet-Draft SIP Recording Callflows February 2013
During resume
The snapshot will look pretty much same as above with just the SDP
dir change.
F5 RE-INVITE SRC-------------------->SRS
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
....
<?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>
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<participantstreamassoc
participant="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
Ravindranath, et al. Expires August 29, 2013 [Page 9]
Internet-Draft SIP Recording Callflows February 2013
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</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>
3.4. Example 3: Basic Call with transfer
Basic call between two Participants Ram and Partha is connected as in
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
transfer). Participant Ram drops out and Paul is added to the same
session. No change to session/group element. Paul will have new
stream element which maps to RS SDP using the same labels in this
instance.
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
Ravindranath, et al. Expires August 29, 2013 [Page 10]
Internet-Draft SIP Recording Callflows February 2013
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
....
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording'>
<datamode>partial</datamode>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
<recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
</participantstreamassoc>
<participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameIDaor=sip:paul@example.com>
<name xml:lang="it">Paul Kyzivat</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsession>
<participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>60JAJm9UTvik0Ltlih/Gzw==</send>
<send>AcR5FUd3Edi8cACQJy/3JQ==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantstreamassoc>
<stream stream_id="60JAJm9UTvik0Ltlih/Gzw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<stream stream_id="AcR5FUd3Edi8cACQJy/3JQ=="
Ravindranath, et al. Expires August 29, 2013 [Page 11]
Internet-Draft SIP Recording Callflows February 2013
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>97</label>
</stream>
<stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
session_id="zSfPoSvdSDCmU3A3TRDxAw==">
<label>98</label>
</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
case new session is part of same grouping (done by SRC).
SRC may send an optional snapshot indicating stop for the old
session.
<?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>
SRC sends a snapshot to indicate the participant change and new
session information after transfer. In this example the same RS is
used.
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
Ravindranath, et al. Expires August 29, 2013 [Page 12]
Internet-Draft SIP Recording Callflows February 2013
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
....
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording'>
<datamode>partial</datamode>
<session session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<start-time>2010-12-16T23:41:07Z</start-time>
</session>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor=sip:partha@example.com/>
</participant>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<associate-time>2010-12-16T23:32:03Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
<recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
</participantstreamassoc>
<participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameID aor=sip:paul@example.com/>
</participant>
<participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
Ravindranath, et al. Expires August 29, 2013 [Page 13]
Internet-Draft SIP Recording Callflows February 2013
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>60JAJm9UTvik0Ltlih/Gzw==</send>
<send>AcR5FUd3Edi8cACQJy/3JQ==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<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>
</recording>
3.5. Example 4: Call disconnect
This example shows a snapshot of metadata sent by an SRC at CS
disconnect where the participants of CS are Ram and Partha
Ravindranath, et al. Expires August 29, 2013 [Page 14]
Internet-Draft SIP Recording Callflows February 2013
SRC SRS
| |
|(1) BYE (metadata snapshot) F1 |
|---------------------------------------------------->|
| 200 OK F2 |
|<----------------------------------------------------|
F1 BYE SRC -----------> SRS
<?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.6. Example 5: Multiple CS into single RS with mixed stream
In trading turret, audio mixing is done locally before forwarding to
the recording server. Sender and receiver audio is mixed for each
communication session. The audio from multiple communication
sessions is also mixed, or multiplexed, in a single RTP session to
the recording server.
F1 INVITE SRC --------------> SRS
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
Ravindranath, et al. Expires August 29, 2013 [Page 15]
Internet-Draft SIP Recording Callflows February 2013
a=sendonly
...
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording'>
<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>
</session>
<session session_id="zzlafnvvjlCHllaHF6mn8kkSS==">
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<start-time>2010-12-16T23:43:07Z</start-time>
</session>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor=sip:ram@example.com>
<name xml:lang="it">RamMohan R</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>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor=sip:partha@example.com>
<name xml:lang="it">Parthasarathi R</name>
</nameID>
</participant>
<participantsessionassoc
participant="zSfPoSvdSDCmU3A3TRDxAw=="
session="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant="zSfPoSvdSDCmU3A3TRDxAw=="
session="zzlafnvvjlCHllaHF6mn8kkSS==">
<associate-time>2010-12-16T23:43:07Z</associate-time>
</participantsessionassoc>
Ravindranath, et al. Expires August 29, 2013 [Page 16]
Internet-Draft SIP Recording Callflows February 2013
<participantstreamassoc
participant="zSfPoSvdSDCmU3A3TRDxAw==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
<participant
participant_id="EiXGlc+4TruqqoDaNE76ag==">
<nameID aor=sip:paul@example.com>
<name xml:lang="it">Paul</name>
</nameID>
</participant>
<participantsessionassoc
participant="EiXGlc+4TruqqoDaNE76ag=="
session="zzlafnvvjlCHllaHF6mn8kkSS==">
<associate-time>2010-12-16T23:43:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant="EiXGlc+4TruqqoDaNE76ag==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
<stream id="UAAMm5GRQKSCMVvLyl4rFw=="
session="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
</recording>
4. Security Considerations
There is no security consideration as it is informatioal callflow
document.
5. IANA Considerations
This document has no IANA considerations
6. Acknowledgement
Thanks to Ofir Rath, Charles Eckel for their review comments.
7. References
Ravindranath, et al. Expires August 29, 2013 [Page 17]
Internet-Draft SIP Recording Callflows February 2013
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,
June 2002.
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-11 (work in progress),
January 2013.
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 Siemens Networks
Bangalore, Karnataka
India
Email: partha@parthasarathi.co.in
Paul Kyzivat
Huawei
Hudson, MA
USA
Email: pkyzivat@alum.mit.edu
Ravindranath, et al. Expires August 29, 2013 [Page 18]