draft-ietf-siprec-callflows-07.txt   draft-ietf-siprec-callflows-08.txt 
SIPREC Ram. Ravindranath SIPREC Ram. Ravindranath
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Informational Parthasarathi. Ravindran Intended status: Informational Parthasarathi. Ravindran
Expires: December 17, 2016 Nokia Networks Expires: June 22, 2017 Nokia Networks
Paul. Kyzivat Paul. Kyzivat
Huawei Huawei
June 15, 2016 December 19, 2016
Session Initiation Protocol (SIP) Recording Call Flows Session Initiation Protocol (SIP) Recording Call Flows
draft-ietf-siprec-callflows-07 draft-ietf-siprec-callflows-08
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 environments, such as call centers and financial trading
organizations. In some of these environments, all calls must be organizations. In some of these environments, all calls must be
recorded for regulatory, compliance, and consumer protection reasons. recorded for regulatory, compliance, and consumer protection reasons.
The recording of a session is typically performed by sending a copy The recording of a session is typically performed by sending a copy
of a media stream to a recording device. This document lists call of a media stream to a recording device. This document lists call
flows with metadata snapshots sent from a Session Recording flows with metadata snapshots sent from a Session Recording
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 December 17, 2016. This Internet-Draft will expire on June 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Metadata XML Instances . . . . . . . . . . . . . . . . . . . 3 3. Metadata XML Instances . . . . . . . . . . . . . . . . . . . 3
3.1. Sample Call flow . . . . . . . . . . . . . . . . . . . . 3 3.1. Sample Call flow . . . . . . . . . . . . . . . . . . . . 3
3.2. Call Scenarios with SRC recording streams without mixing 5 3.2. Call Scenarios with SRC recording streams without mixing 5
3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 5 3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 5
3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . 8 3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . 8
3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 11 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 12
3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . 18 3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . 18
3.3. Call Scenarios with SRC recording streams by mixing . . . 19 3.3. Call Scenarios with SRC recording streams by mixing . . . 19
3.3.1. Example 1: Basic call with SRC mixing streams . . . . 19 3.3.1. Example 1: Basic call with SRC mixing streams . . . . 20
3.3.2. Example 2: Hold/resume with SRC recording by mixing 3.3.2. Example 2: Hold/resume with SRC recording by mixing
streams . . . . . . . . . . . . . . . . . . . . . . . 21 streams . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.3. Example 3: Metadata snapshot of joining/dropping of a 3.3.3. Example 3: Metadata snapshot of joining/dropping of a
participant to a session . . . . . . . . . . . . . . 24 participant to a session . . . . . . . . . . . . . . 24
3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . 27 3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . 27
3.4. Call scenarios with persistent RS between SRC and SRS . . 27 3.4. Call scenarios with persistent RS between SRC and SRS . . 27
3.4.1. Example 1: Metadata snapshot during CS disconnect 3.4.1. Example 1: Metadata snapshot during CS disconnect
with persistent RS between SRC and SRS . . . . . . . 27 with persistent RS between SRC and SRS . . . . . . . 27
3.5. Turret-Case: Multiple CS into single RS with mixed stream 28 3.5. Turret-Case: Multiple CS into single RS with mixed stream 29
4. Security Considerations . . . . . . . . . . . . . . . . . . . 31 4. Security Considerations . . . . . . . . . . . . . . . . . . . 31
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 31 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 32
7. Informative References . . . . . . . . . . . . . . . . . . . 32 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Normative References . . . . . . . . . . . . . . . . . . 32
7.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Overview 1. Overview
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 environments, such as call centers and financial trading
organizations. In some of these environments, all calls must be organizations. In some of these environments, all calls must be
recorded for regulatory, compliance, and consumer protection reasons. recorded for regulatory, compliance, and consumer protection reasons.
The recording of a session is typically performed by sending a copy The recording of a session is typically performed by sending a copy
of a media stream to a recording device. [RFC7865] focuses on the of a media stream to a recording device. [RFC7865] focuses on the
recording metadata which describes the Communication Session(CS). recording metadata which describes the Communication Session(CS).
This document lists few examples and shows the snapshots of metadata This document lists few examples and shows the snapshots of metadata
sent from a Session Recording Client(SRC) to Session Recording Server sent from a Session Recording Client(SRC) to Session Recording Server
(SRS). For the sake of simplicity the entire Session Initiation (SRS). For the sake of simplicity the entire Session Initiation
Protocol (SIP) [RFC3261] messages are not shown, instead only Protocol (SIP) [RFC3261] messages are not shown, instead only
snippets of the SIP and Session Description Protocol (SDP)[RFC4566] snippets of the SIP and Session Description Protocol (SDP)[RFC4566]
messages and the XML snapshot of metadata is shown. messages and the XML snapshot of metadata is shown.
2. Terminology 2. Terminology
The terms using in this document are defined in [RFC7865] and The terms used in this document are defined in [RFC7865] and
[RFC6341]. No new definitions are introduced in this document. [RFC6341]. No new definitions are introduced in this document.
3. Metadata XML Instances 3. Metadata XML Instances
The following sub-sections has examples showing the metadata snapshot The following sub-sections have examples that contain the metadata
sent from SRC to SRS. In all these use-cases, the SRC is a B2BUA. snapshot sent from SRC to SRS.
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(RS) towards the SRS. The SRC in this example could Recording Session(RS) towards the SRS. The SRC in this example could
be part of any one of the architectures described in section 3 of be part of any one of the architectures described in section 3 of
[RFC7245]. [RFC7245].
Figure 1: Sample call flow between SRC and SRS
SRC SRS SRC SRS
| | | |
|(1) INVITE (metadata snapshot) F1 | |(1) INVITE (metadata snapshot) F1 |
|---------------------------------------------------->| |---------------------------------------------------->|
| 200 OK | | 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
|(3) ACK | |(3) ACK |
|---------------------------------------------------->| |---------------------------------------------------->|
|(4) RTP | |(4) RTP |
|====================================================>| |====================================================>|
skipping to change at page 4, line 37 skipping to change at page 4, line 39
|(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 | |(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 |
|---------------------------------------------------->| |---------------------------------------------------->|
| 200 OK | | 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
For the sake of simplicity, ACKs to RE-INVITES and BYEs are not For the sake of simplicity, ACKs to RE-INVITES and BYEs are not
shown. The subsequent sections describe the snapshot of metadata shown. The subsequent sections describe the snapshot of metadata
sent from SRC to SRS for each of the above transactions (F1 ... Fn- sent from SRC to SRS for each of the above transactions (F1 ... Fn-
1). There may be multiple UPDATES/RE-INVITES mid call to indicate 1). There may be multiple UPDATES/RE-INVITES mid call to indicate
snapshots of different CS changes. Depending on the architecture snapshots of different CS changes. Depending on the architecture
described in section 3 of [RFC7245] an SRC may be a endpoint or B2BUA described in section 3 of [RFC7245] an SRC may be an endpoint or
or as part of MEDIACTRL or Conference focus. The subsequent sections Back-to-Back User Agent(B2BUA) or as part of MEDIACTRL or Conference
in this document try to list some example metadata snapshots for focus. The subsequent sections in this document try to list some
three major categories. example metadata snapshots for three major categories.
o SRC recording streams unmixed to SRS. This includes cases where o SRC recording streams unmixed to SRS. This includes cases where
SRC is SIP UA or B2BUA. SRC is SIP UA or B2BUA.
o SRC recording mixed streams to SRS. This includes cases where SRC o SRC recording mixed streams to SRS. This includes cases where SRC
is part of SIP conference model explained in [RFC4353]. is part of SIP conference model explained in [RFC4353].
o SRC having a persistent RS with SRS. o SRC having a persistent RS with SRS.
o Special flows like Turret flows. o Special flows like Turret flows (used on financial trading floors
to manage call activity). A trading turret is a specialized
telephony key system that has a highly distributed switching
architecture enabling parallel processing of calls. Figure 6 in
Section 4 of [RFC6341] has the turret use-case.
Note that only those examples for which metadata changes are listed Note that only those examples for which metadata changes are listed
in each category. For some of the call flows the snapshots may be in each category. For some of the call flows the snapshots may be
same (like in case of endpoint or B2BUA acting as SRC) and the same same (like in case of endpoint or B2BUA acting as SRC) and the same
is mentioned in the text preceding the example. is mentioned in the text preceding the example.
3.2. Call Scenarios with SRC recording streams without mixing 3.2. Call Scenarios with SRC recording streams without mixing
This section describes example flows where SRC can be a SIP-UA or This section describes example flows where SRC can be a SIP-UA or
B2BUA as described in section 3 of [RFC7245]. The SRS here can be a B2BUA as described in section 3 of [RFC7245]. The SRS here can be a
skipping to change at page 5, line 30 skipping to change at page 5, line 36
same CS. In this use case each participant sends two media same CS. In this use case each participant sends two media
streams(audio and video). Media streams sent by each participant are streams(audio and video). Media streams sent by each participant are
received by the other participant in this use-case. In this example received by the other participant in this use-case. In this example
the SRC is a B2BUA in the path between Alice and Bob as described in 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 section 3.1.1 of [RFC7245]. Below is the initial snapshot sent by
SRC in the INVITE to SRS. This snapshot has the complete metadata. SRC in the INVITE to SRS. This snapshot has the complete metadata.
For the sake of simplicity only snippets of SIP/SDP are shown. In For the sake of simplicity only snippets of SIP/SDP are shown. In
this example the SRCs records the streams of each participant to SRS this example the SRCs records the streams of each participant to SRS
without mixing. without mixing.
F1 INVITE SRC --------------> SRS Metadata snapshot for CS setup:
INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86 Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000 ;remote=00000000000000000000000000000000
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 8, line 28 skipping to change at page 8, line 36
<send>EiXGlc+4TruqqoDaNE76ag==</send> <send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
3.2.2. Example 2: Hold/resume 3.2.2. Example 2: Hold/resume
A call between two participants Alice and Bob is established and a RS A call between two participants Alice and Bob is established and a RS
is created for recording as in example 1. One of the participants is created for recording as in example 1. One of the participants
Bob puts Alice hold and then resumes as part of the same CS. The Bob puts Alice on hold and then resumes as part of the same CS. The
'send' and 'recv' XML elements of a 'participantstreamassoc' XML 'send' and 'recv' XML elements of a 'participantstreamassoc' XML
element is used to indicate whether a participant is contributing to element is used to indicate whether a participant is contributing to
a media stream or not. SRC sends a snapshot with only the changed a media stream or not. SRC sends a snapshot with only the changed
XML elements. XML elements.
During hold During hold
F2 mid call RE-INVITE SRC-------------------->SRS Metadata snapshot for CS hold:
RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86 Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 10, line 17 skipping to change at page 10, line 26
send any media. The same is indicated by the absence of 'send' XML send any media. The same is indicated by the absence of 'send' XML
element. Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other element. Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other
hand would be sending media but does not receive any media from Alice hand would be sending media but does not receive any media from Alice
and so 'recv' XML element is absent in this instance. and so 'recv' XML element is absent in this instance.
During resume During resume
The snapshot now has 'send' and 'recv' XML elements for both Alice The snapshot now has 'send' and 'recv' XML elements for both Alice
and Bob indicating that both are receiving and sending media. and Bob indicating that both are receiving and sending media.
F3 mid call RE-INVITE SRC-------------------->SRS Metadata snapshot for CS resume:
RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86 Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 12, line 11 skipping to change at page 12, line 29
same session. No change to session/group element. A same session. No change to session/group element. A
'participantsessassoc' XML element indicating that Alice has 'participantsessassoc' XML element indicating that Alice has
disassociated from the CS will be present in the snapshot. A new disassociated from the CS will be present in the snapshot. A new
'participant' XML element representing Carol with mapping to the same 'participant' XML element representing Carol with mapping to the same
RS SDP stream used for mapping earlier Alice's stream is sent in the RS SDP stream used for mapping earlier Alice's stream is sent in the
snapshot. A new 'sipSessionID' XML element that has UUID tuples snapshot. A new 'sipSessionID' XML element that has UUID tuples
which corresponds to Bob and Carol is sent in the snapshot from SRC 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 to SRS. Note that one half of the session ID that corresponds to Bob
remains same. remains same.
mid call RE-INVITE SRC-------------------->SRS Metadata snapshot for INVITE based transfer in CS:
RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86 Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 14, line 18 skipping to change at page 14, line 33
SRC first sends an optional snapshot indicating disassociation of SRC first sends an optional snapshot indicating disassociation of
participant from the old CS. Please note this is an optional participant from the old CS. Please note this is an optional
message. An SRC may choose to just send an INVITE with a new message. An SRC may choose to just send an INVITE with a new
'session' XML element to implicitly indicate that the participants 'session' XML element to implicitly indicate that the participants
are now part of a different CS without sending disassociation from are now part of a different CS without sending disassociation from
the old CS. The SRC in this example uses the same RS. In case the the old CS. The SRC in this example uses the same RS. In case the
SRC wishes to use a new RS, it will tear down the current RS using SRC wishes to use a new RS, it will tear down the current RS using
normal SIP procedures (BYE) with metadata as in example 4. normal SIP procedures (BYE) with metadata as in example 4.
mid call RE-INVITE SRC-------------------->SRS Metadata snapshot for REFER based transfer in CS:
RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86 Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 15, line 46 skipping to change at page 16, line 16
optional as indicating 'session' XML element with a 'stop-time' optional as indicating 'session' XML element with a 'stop-time'
implicitly means that all the participants associated with that implicitly means that all the participants associated with that
session have been disassociated. session have been disassociated.
SRC sends another snapshot to indicate the participant change (due to SRC sends another snapshot to indicate the participant change (due to
REFER) and new session information after transfer. In this example REFER) and new session information after transfer. In this example
it is assumed SRC uses the same RS to continue recording the call. it is assumed SRC uses the same RS to continue recording the call.
The 'sipSessionID' XML element in metadata snapshot now indicates Bob The 'sipSessionID' XML element in metadata snapshot now indicates Bob
and Carol in the (local, remote) uuid pair. and Carol in the (local, remote) uuid pair.
mid call RE-INVITE SRC-------------------->SRS Metadata snapshot for REFER based transfer in CS:
RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86 Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
Require: siprec Require: siprec
skipping to change at page 18, line 21 skipping to change at page 18, line 39
This example shows a snapshot of metadata sent by the SRC to SRS when This example shows a snapshot of metadata sent by the SRC to SRS when
a CS with Alice and Bob as participants is disconnected. a CS with Alice and Bob as participants is disconnected.
SRC SRS SRC SRS
| | | |
|(1) BYE (metadata snapshot) F1 | |(1) BYE (metadata snapshot) F1 |
|---------------------------------------------------->| |---------------------------------------------------->|
| 200 OK F2 | | 200 OK F2 |
|<----------------------------------------------------| |<----------------------------------------------------|
Metadata snapshot for a CS disconnect:
F1 BYE SRC -----------> SRS F1 BYE SRC -----------> SRS
BYE sip:2001@example.com SIP/2.0 BYE sip:2001@example.com SIP/2.0
Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86 Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 102 BYE CSeq: 102 BYE
skipping to change at page 19, line 21 skipping to change at page 19, line 39
<participantsessionassoc <participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
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>
</recording> </recording>
3.3. Call Scenarios with SRC recording streams by mixing 3.3. Call Scenarios with SRC recording streams by mixing
The section describes a few example call flows where SRC may be part This section describes a few example call flows where SRC may be part
of conference model either as focus or a participant in conference as of conference model either as focus or a participant in conference as
explained in section 3.1.5 of [RFC7245]. The SRS here can be a SIP explained in section 3.1.5 of [RFC7245]. The SRS here can be a SIP
UA or an entity part of MEDIACTRL architecture. Note that the UA or an entity part of MEDIACTRL architecture. Note that the
disconnect case is not shown since the metadata snapshot will be same disconnect case is not shown since the metadata snapshot will be same
as for a non-mixing case. as for a non-mixing case.
3.3.1. Example 1: Basic call with SRC mixing streams 3.3.1. Example 1: Basic call with SRC mixing streams
Basic call between two participants Alice and Bob who are part of one Basic call between two participants Alice and Bob who are part of one
CS. In this use case each participant calls into a conference server CS. In this use case each participant calls into a conference server
skipping to change at page 19, line 43 skipping to change at page 20, line 20
by that server. Media streams sent by each participant are received by that server. Media streams sent by each participant are received
by all the other participants in the conference. Below is the by all the other participants in the conference. Below is the
initial snapshot sent by SRC in the INVITE to SRS that has the initial snapshot sent by SRC in the INVITE to SRS that has the
complete metadata. For the sake of simplicity only snippets of SIP/ complete metadata. For the sake of simplicity only snippets of SIP/
SDP are shown. The SRC records the streams of each participant to SDP are shown. The SRC records the streams of each participant to
SRS by mixing in this example. The SRC here is part of conference 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. 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 The SRC here is not a participant by itself and hence it does not
contribute to media. contribute to media.
F1 INVITE SRC --------------> SRS Metadata snapshot with SRC mixing streams to SRS:
F1 INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7 Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=00000000000000000000000000000000 ;remote=00000000000000000000000000000000
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 21, line 43 skipping to change at page 22, line 20
the SIP session between Alice and conference focus and the other for the SIP session between Alice and conference focus and the other for
the SIP session between Bob and conference focus. In this use-case, the SIP session between Bob and conference focus. In this use-case,
since Alice and Bob calls into the conference these Session-ID's are since Alice and Bob calls into the conference these Session-ID's are
different. different.
3.3.2. Example 2: Hold/resume with SRC recording by mixing streams 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams
This is the continuation of Example 1: Basic call with SRC mixing This is the continuation of Example 1: Basic call with SRC mixing
streams. Given a call between two participants Alice and Bob is streams. Given a call between two participants Alice and Bob is
established and a RS is created for recording as in example 5. One established and a RS is created for recording as in example 5. One
of the participants, Bob puts Alice hold and then resumes as part of of the participants, Bob puts Alice on hold and then resumes as part
the same CS. The 'send' and 'recv' XML elements of a 'participant' of the same CS. The 'send' and 'recv' XML elements of a
XML element are used to indicate whether a participant is 'participant' XML element are used to indicate whether a participant
contributing or not to a media stream. The metadata snapshot looks is contributing or not to a media stream. The metadata snapshot
as below: looks as below:
During hold During hold
mid call hold RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 Metadata snapshot when a CS participant goes hold and SRC mixing streams:
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 RE-INVITE SRC --------------> SRS
Content-Type: application/SDP
... INVITE sip:recorder@example.com SIP/2.0
m=audio 49170 RTP/AVP 0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
a=rtpmap:0 PCMU/8000 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
a=label:96 To: <sip:recorder@example.com>
a=sendonly 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 --foobar
Content-Type: application/rs-metadata Content-Type: application/SDP
Content-Disposition: recording-session ...
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'> --foobar
<datamode>partial</datamode> Content-Type: application/rs-metadata
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw==" Content-Disposition: recording-session
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label> <?xml version="1.0" encoding="UTF-8"?>
</stream> <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<participantstreamassoc <datamode>partial</datamode>
participant_id="srfBElmCRp2QB23b7Mpk0w=="> <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> session_id="hVpd7YQgRW2nD22h7q60JQ==">
</participantstreamassoc> <label>96</label>
<participantstreamassoc </stream>
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> <participantstreamassoc
<send>i1Pz3to5hGk8fuXl+PbwCw==</send> participant_id="srfBElmCRp2QB23b7Mpk0w==">
</participantstreamassoc> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</recording> </participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
</participantstreamassoc>
</recording>
During resume a snapshot shown below will be sent from SRC to SRS. During resume a snapshot shown below will be sent from SRC to SRS.
mid call resume RE-INVITE SRC --------------> SRS Metadata snapshot when a CS participant resumes and SRC mixing streams:
INVITE sip:recorder@example.com SIP/2.0 RE-INVITE SRC --------------> SRS
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 INVITE sip:recorder@example.com SIP/2.0
Content-Type: application/SDP Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
... From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
m=audio 49170 RTP/AVP 0 To: <sip:recorder@example.com>
a=rtpmap:0 PCMU/8000 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
a=label:96 Session-ID: a358d2b81a444a8c8fb05950cef331e7
a=sendonly ;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 --foobar
Content-Type: application/rs-metadata Content-Type: application/SDP
Content-Disposition: recording-session ...
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'> --foobar
<datamode>partial</datamode> Content-Type: application/rs-metadata
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw==" Content-Disposition: recording-session
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> <?xml version="1.0" encoding="UTF-8"?>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
</participantstreamassoc> <datamode>partial</datamode>
</recording> <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>
3.3.3. Example 3: Metadata snapshot of joining/dropping of a 3.3.3. Example 3: Metadata snapshot of joining/dropping of a
participant to a session participant to a session
In a conference model, participants can join and drop a session any In a conference model, participants can join and drop a session any
time during the session. Below is a snapshot sent from SRC to SRC in time during the session. Below is a snapshot sent from SRC to SRS in
this case. Note the SRC here can be a focus or a participant in the this case. Note the SRC here can be a focus or a participant in the
conference. In the case where the SRC is a participant it may learn conference. In the case where the SRC is a participant it may learn
the information required for metadata by subscribing to conference the information required for metadata by subscribing to conference
event package [RFC4575]. Assume Alice and Bob were in the conference event package [RFC4575]. Assume Alice and Bob were in the conference
and a third participant Carol joins, then SRC sends the below and a third participant Carol joins, then SRC sends the below
snapshot with the indication of new participant. snapshot with the indication of new participant.
mid call resume RE-INVITE SRC --------------> SRS Metadata snapshot for a new participant joining CS:
RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7 Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 26, line 5 skipping to change at page 26, line 22
<participantstreamassoc <participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send> <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
Given Alice drops after some time from the conference. SRC generates Given Alice drops after some time from the conference. SRC generates
a new snapshot showing Alice disassociating from the session. a new snapshot showing Alice disassociating from the session.
mid call resume RE-INVITE SRC --------------> SRS Metadata snapshot for a participant dropping from CS:
RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7 Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 27, line 13 skipping to change at page 27, line 33
</recording> </recording>
3.3.4. Example 4: Call disconnect 3.3.4. Example 4: Call disconnect
When a CS is disconnected, SRC sends BYE with a snapshot of metadata When a CS is disconnected, SRC sends BYE with a snapshot of metadata
having session stop time and participant dis-associate times. The having session stop time and participant dis-associate times. The
snapshot looks same as listed in section 3.2.4 snapshot looks same as listed in section 3.2.4
3.4. Call scenarios with persistent RS between SRC and SRS 3.4. Call scenarios with persistent RS between SRC and SRS
The section shows the snapshots of metadata for the cases where a This section shows the snapshots of metadata for the cases where a
persistent RS exists between SRC and SRS. An SRC here may be SIP UA persistent RS exists between SRC and SRS. An SRC here may be SIP UA
or a B2BUA or may be part of Conference model either as focus or a or a B2BUA or may be part of Conference model either as focus or a
participant in a conference. The SRS here could be a SIP UA or an participant in a conference. The SRS here could be a SIP UA or an
entity part of MEDIACTRL architecture. Except in the disconnect entity part of MEDIACTRL architecture. Except in the disconnect
case, the snapshot remains same as mentioned in previous sections. case, the snapshot remains same as mentioned in previous sections.
3.4.1. Example 1: Metadata snapshot during CS disconnect with 3.4.1. Example 1: Metadata snapshot during CS disconnect with
persistent RS between SRC and SRS persistent RS between SRC and SRS
Metadata snapshot for a CS disconnect with a persistent RS:
RE-INVITE sent from SRC -----------> SRS RE-INVITE sent from SRC -----------> SRS
INVITE sip:2001@example.com SIP/2.0 INVITE sip:2001@example.com SIP/2.0
Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86 Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE CSeq: 101 INVITE
skipping to change at page 29, line 12 skipping to change at page 29, line 19
concurrent calls (each call is one CS) on different handsets/ concurrent calls (each call is one CS) on different handsets/
speakers on the same turret into a single RS. This would means media speakers on the same turret into a single RS. This would means media
in each CS is mixed and recorded as part of single media stream and in each CS is mixed and recorded as part of single media stream and
multiple such CSs are recording in one RSfrom a SRC to SRS. multiple such CSs are recording in one RSfrom a SRC to SRS.
Taking an example where there are two CS [CS1 and CS2]. Assume Taking an example where there are two CS [CS1 and CS2]. Assume
mixing is done in each of these CS and both these CS are recorded as mixing is done in each of these CS and both these CS are recorded as
part of single RS from a single SRC which is part of both the CS. part of single RS from a single SRC which is part of both the CS.
There are three possibilities here: There are three possibilities here:
o CS1 and CS2 uses the same focus for fixing and that focus is also o CS1 and CS2 uses the same focus for mixing and that focus is also
acting as SRC in each of the CS. acting as SRC in each of the CS.
o One of the CS (e.g. CS1), SRC is Focus and the other CS (e.g. o One of the CS (e.g. CS1), SRC is Focus and the other CS (e.g.
CS2), SRC is just one of the participant of the conference. CS2), SRC is just one of the participant of the conference.
o In both CS1 and CS2, SRC is just a participant of conference. o In both CS1 and CS2, SRC is just a participant of conference.
The following example shows the first possibility where CS1 and CS2 The following example shows the first possibility where CS1 and CS2
uses the same focus for fixing and that focus is also acting as SRC uses the same focus for mixing and that focus is also acting as SRC
in each of the CS. in each of the CS.
snapshot of metadata INVITE SRC --------------> SRS Metadata snapshot with two CS recorded as part of same RS:
INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7 Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=00000000000000000000000000000000 ;remote=00000000000000000000000000000000
Content-Type: application/SDP Content-Type: application/SDP
... ...
skipping to change at page 31, line 34 skipping to change at page 31, line 42
</participantstreamassoc> </participantstreamassoc>
<participantstreamassoc <participantstreamassoc
participant_id="EiXGlc+4TruqqoDaNE76ag=="> participant_id="EiXGlc+4TruqqoDaNE76ag==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send> <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc> </participantstreamassoc>
</recording> </recording>
4. Security Considerations 4. Security Considerations
Security considerations mentioned in [RFC7865] and [RFC7866] has to Security and privacy considerations mentioned in [RFC7865] and
be followed by SRC and SRS for setting up RS SIP dialog and sending [RFC7866] has to be followed by SRC and SRS for setting up RS SIP
metadata. dialog and sending metadata.
5. IANA Considerations 5. IANA Considerations
This document has no IANA considerations This document has no IANA considerations
6. Acknowledgement 6. Acknowledgement
Thanks to Ofir Rath, Charles Eckel, Yaron Pdut, Dmitry Andreyev and Thanks to Ofir Rath, Charles Eckel, Yaron Pdut, Dmitry Andreyev and
Charles Armitage for their review comments. Charles Armitage for their review comments.
7. Informative References Thanks to Alissa Cooper, Stephen Farrell, Kathleen Moriarty, Suresh
Krishnan, Benoit Claise, Carlos Pignataro, Dan Romascanu and Derek
Atkins for their feedback and comments during IESG reviews.
7. References
7.1. Normative References
[RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain,
"Use Cases and Requirements for SIP-Based Media Recording
(SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011,
<http://www.rfc-editor.org/info/rfc6341>.
[RFC7865] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session [RFC7865] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session
Initiation Protocol (SIP) Recording Metadata", RFC 7865, Initiation Protocol (SIP) Recording Metadata", RFC 7865,
DOI 10.17487/RFC7865, May 2016, DOI 10.17487/RFC7865, May 2016,
<http://www.rfc-editor.org/info/rfc7865>. <http://www.rfc-editor.org/info/rfc7865>.
[RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A. [RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A.
Hutton, "Session Recording Protocol", RFC 7866, Hutton, "Session Recording Protocol", RFC 7866,
DOI 10.17487/RFC7866, May 2016, DOI 10.17487/RFC7866, May 2016,
<http://www.rfc-editor.org/info/rfc7866>. <http://www.rfc-editor.org/info/rfc7866>.
[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
"An Architecture for Media Recording Using the Session "An Architecture for Media Recording Using the Session
Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May
2014, <http://www.rfc-editor.org/info/rfc7245>. 2014, <http://www.rfc-editor.org/info/rfc7245>.
7.2. Informative References
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
Session Initiation Protocol (SIP) Event Package for Session Initiation Protocol (SIP) Event Package for
Conference State", RFC 4575, DOI 10.17487/RFC4575, August Conference State", RFC 4575, DOI 10.17487/RFC4575, August
2006, <http://www.rfc-editor.org/info/rfc4575>. 2006, <http://www.rfc-editor.org/info/rfc4575>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353, Session Initiation Protocol (SIP)", RFC 4353,
DOI 10.17487/RFC4353, February 2006, DOI 10.17487/RFC4353, February 2006,
<http://www.rfc-editor.org/info/rfc4353>. <http://www.rfc-editor.org/info/rfc4353>.
[RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework", RFC 6230,
DOI 10.17487/RFC6230, May 2011,
<http://www.rfc-editor.org/info/rfc6230>.
[RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain,
"Use Cases and Requirements for SIP-Based Media Recording
(SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011,
<http://www.rfc-editor.org/info/rfc6341>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [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,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
 End of changes. 50 change blocks. 
139 lines changed or deleted 179 lines changed or added

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