draft-ietf-siprec-protocol-09.txt   draft-ietf-siprec-protocol-10.txt 
SIPREC L. Portman SIPREC L.P. Portman
Internet-Draft NICE Systems Internet-Draft NICE Systems
Intended status: Standards Track H. Lum, Ed. Intended status: Standards Track H. Lum, Ed.
Expires: June 11, 2013 Genesys Expires: November 18, 2013 Genesys
C. Eckel C. Eckel
Cisco Cisco
A. Johnston A. Johnston
Avaya Avaya
A. Hutton A. Hutton
Siemens Enterprise Siemens Enterprise Communications
Communications May 17, 2013
December 8, 2012
Session Recording Protocol Session Recording Protocol
draft-ietf-siprec-protocol-09 draft-ietf-siprec-protocol-10
Abstract Abstract
This document specifies the use of the Session Initiation Protocol This document specifies the use of the Session Initiation Protocol
(SIP), the Session Description Protocol (SDP), and the Real Time (SIP), the Session Description Protocol (SDP), and the Real Time
Protocol (RTP) for delivering real-time media and metadata from a Protocol (RTP) for delivering real-time media and metadata from a
Communication Session (CS) to a recording device. The Session Communication Session (CS) to a recording device. The Session
Recording Protocol specifies the use of SIP, SDP, and RTP to Recording Protocol specifies the use of SIP, SDP, and RTP to
establish a Recording Session (RS) between the Session Recording establish a Recording Session (RS) between the Session Recording
Client (SRC), which is on the path of the CS, and a Session Recording Client (SRC), which is on the path of the CS, and a Session Recording
Server (SRS) at the recording device. Server (SRS) at the recording device.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 11, 2013. This Internet-Draft will expire on November 18, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Overview of operations . . . . . . . . . . . . . . . . . . . . 5 5. Overview of operations . . . . . . . . . . . . . . . . . . . 5
5.1. Delivering recorded media . . . . . . . . . . . . . . . . 5 5.1. Delivering recorded media . . . . . . . . . . . . . . . . 5
5.2. Delivering recording metadata . . . . . . . . . . . . . . 7 5.2. Delivering recording metadata . . . . . . . . . . . . . . 7
5.3. Receiving recording indications and providing 5.3. Receiving recording indications and providing recording
recording preferences . . . . . . . . . . . . . . . . . . 8 preferences . . . . . . . . . . . . . . . . . . . . . . . 8
6. SIP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. SIP Handling . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 9 6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 9
6.1.1. Initiating a Recording Session . . . . . . . . . . . . 10 6.1.1. Initiating a Recording Session . . . . . . . . . . . 9
6.1.2. SIP extensions for recording indication and 6.1.2. SIP extensions for recording indication and
preference . . . . . . . . . . . . . . . . . . . . . . 10 preference . . . . . . . . . . . . . . . . . . . . . 10
6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 11 6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 10
6.3. Procedures for Recording-aware User Agents . . . . . . . . 11 6.3. Procedures for Recording-aware User Agents . . . . . . . 11
7. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 12 7.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 12
7.1.1. SDP handling in RS . . . . . . . . . . . . . . . . . . 12 7.1.1. SDP handling in RS . . . . . . . . . . . . . . . . . 12
7.1.1.1. Handling media stream updates . . . . . . . . . . 13 7.1.1.1. Handling media stream updates . . . . . . . . . . 13
7.1.2. Recording indication in CS . . . . . . . . . . . . . . 14 7.1.2. Recording indication in CS . . . . . . . . . . . . . 13
7.1.3. Recording preference in CS . . . . . . . . . . . . . . 15 7.1.3. Recording preference in CS . . . . . . . . . . . . . 14
7.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 15 7.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 14
7.3. Procedures for Recording-aware User Agents . . . . . . . . 17 7.3. Procedures for Recording-aware User Agents . . . . . . . 16
7.3.1. Recording indication . . . . . . . . . . . . . . . . . 17 7.3.1. Recording indication . . . . . . . . . . . . . . . . 16
7.3.2. Recording preference . . . . . . . . . . . . . . . . . 18 7.3.2. Recording preference . . . . . . . . . . . . . . . . 17
8. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. RTP Mechanisms . . . . . . . . . . . . . . . . . . . . . . 19 8.1. RTP Mechanisms . . . . . . . . . . . . . . . . . . . . . 18
8.1.1. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1.1. RTCP . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1.2. RTP Profile . . . . . . . . . . . . . . . . . . . . . 19 8.1.2. RTP Profile . . . . . . . . . . . . . . . . . . . . . 19
8.1.3. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1.3. SSRC . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1.4. CSRC . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1.4. CSRC . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1.5. SDES . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1.5. SDES . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1.5.1. CNAME . . . . . . . . . . . . . . . . . . . . . . 21 8.1.5.1. CNAME . . . . . . . . . . . . . . . . . . . . . . 20
8.1.6. Keepalive . . . . . . . . . . . . . . . . . . . . . . 21 8.1.6. Keepalive . . . . . . . . . . . . . . . . . . . . . . 20
8.1.7. RTCP Feedback Messages . . . . . . . . . . . . . . . . 21 8.1.7. RTCP Feedback Messages . . . . . . . . . . . . . . . 20
8.1.7.1. Full Intra Request . . . . . . . . . . . . . . . . 22 8.1.7.1. Full Intra Request . . . . . . . . . . . . . . . 21
8.1.7.2. Picture Loss Indicator . . . . . . . . . . . . . . 22 8.1.7.2. Picture Loss Indicator . . . . . . . . . . . . . 21
8.1.7.3. Temporary Maximum Media Stream Bit Rate Request . 22 8.1.7.3. Temporary Maximum Media Stream Bit Rate Request . 22
8.1.8. Symmetric RTP/RTCP for Sending and Receiving . . . . . 23 8.1.8. Symmetric RTP/RTCP for Sending and Receiving . . . . 22
8.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2.1. SRC acting as an RTP Translator . . . . . . . . . . . 24 8.2.1. SRC acting as an RTP Translator . . . . . . . . . . . 23
8.2.1.1. Forwarding Translator . . . . . . . . . . . . . . 25 8.2.1.1. Forwarding Translator . . . . . . . . . . . . . . 23
8.2.1.2. Transcoding Translator . . . . . . . . . . . . . . 25 8.2.1.2. Transcoding Translator . . . . . . . . . . . . . 24
8.2.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . . 26 8.2.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . 25
8.2.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 26 8.2.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 25
8.3. RTP Session Usage by SRC . . . . . . . . . . . . . . . . . 27 8.3. RTP Session Usage by SRC . . . . . . . . . . . . . . . . 26
8.3.1. SRC Using Multiple m-lines . . . . . . . . . . . . . . 27 8.3.1. SRC Using Multiple m-lines . . . . . . . . . . . . . 26
8.3.2. SRC Using Mixing . . . . . . . . . . . . . . . . . . . 28 8.3.2. SRC Using Mixing . . . . . . . . . . . . . . . . . . 27
8.4. RTP Session Usage by SRS . . . . . . . . . . . . . . . . . 29 8.4. RTP Session Usage by SRS . . . . . . . . . . . . . . . . 28
9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 29 9.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 29
9.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 31 9.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 30
9.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 33 9.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 32
10. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 33 10. Persistent Recording . . . . . . . . . . . . . . . . . . . . 32
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
11.1. Registration of Option Tags . . . . . . . . . . . . . . . 33 11.1. Registration of Option Tags . . . . . . . . . . . . . . 32
11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 34 11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . 32
11.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 34 11.1.2. record-aware Option Tag . . . . . . . . . . . . . . 33
11.2. Registration of media feature tags . . . . . . . . . . . . 34 11.2. Registration of media feature tags . . . . . . . . . . . 33
11.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 34 11.2.1. src feature tag . . . . . . . . . . . . . . . . . . 33
11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 35 11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . 33
11.3. New Content-Disposition Parameter Registrations . . . . . 35 11.3. New Content-Disposition Parameter Registrations . . . . 34
11.4. Media Type Registration . . . . . . . . . . . . . . . . . 35 11.4. Media Type Registration . . . . . . . . . . . . . . . . 34
11.4.1. Registration of MIME Type application/rs-metadata . . 35 11.4.1. Registration of MIME Type application/rs-metadata . 34
11.4.2. Registration of MIME Type 11.4.2. Registration of MIME Type application/rs-metadata-
application/rs-metadata-request . . . . . . . . . . . 36 request . . . . . . . . . . . . . . . . . . . . . . 34
11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 36 11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 35
11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 36 11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . 35
11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 36 11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . 35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 37 12. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12.1. Authentication and Authorization . . . . . . . . . . . . . 37 12.1. Authentication and Authorization . . . . . . . . . . . . 36
12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . . 38 12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . 37
12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . 39 12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 37
12.4. Storage and playback . . . . . . . . . . . . . . . . . . . 39 12.4. Storage and playback . . . . . . . . . . . . . . . . . . 38
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
14.1. Normative References . . . . . . . . . . . . . . . . . . . 39 14.1. Normative References . . . . . . . . . . . . . . . . . . 38
14.2. Informative References . . . . . . . . . . . . . . . . . . 40 14.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document specifies the mechanism to record a Communication This document specifies the mechanism to record a Communication
Session (CS) by delivering real-time media and metadata from the CS Session (CS) by delivering real-time media and metadata from the CS
to a recording device. In accordance to the architecture to a recording device. In accordance to the architecture
[I-D.ietf-siprec-architecture], the Session Recording Protocol [I-D.ietf-siprec-architecture], the Session Recording Protocol
specifies the use of SIP, SDP, and RTP to establish a Recording specifies the use of SIP, SDP, and RTP to establish a Recording
Session (RS) between the Session Recording Client (SRC), which is on Session (RS) between the Session Recording Client (SRC), which is on
the path of the CS, and a Session Recording Server (SRS) at the the path of the CS, and a Session Recording Server (SRS) at the
recording device. recording device.
SIP is also used to deliver metadata to the recording device, as SIP is also used to deliver metadata to the recording device, as
skipping to change at page 6, line 20 skipping to change at page 6, line 15
endpoint can send replicated media towards the SRS. endpoint can send replicated media towards the SRS.
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 call flow is essentially
identical when the SRC is a B2BUA or as the endpoint itself. Note identical when the SRC is a B2BUA or as the endpoint itself. Note
that the SRC can choose when to establish the Recording Session that the SRC can choose when to establish the Recording Session
independent of the Communication Session, even though the following independent of the Communication Session, even though the following
call flow suggests that the SRC is establishing the Recording Session call flow suggests that the SRC is establishing the Recording Session
(message #5) after the Communication Session is established. (message #5) after the Communication Session is established.
UA A SRC UA B SRS UA A SRC UA B SRS
|(1)CS INVITE | | | |(1)CS INVITE | | |
|------------->| | | |------------->| | |
| |(2)CS INVITE | | | |(2)CS INVITE | |
| |---------------------->| | | |---------------------->| |
| | (3) 200 OK | | | | (3) 200 OK | |
| |<----------------------| | | |<----------------------| |
| (4) 200 OK | | | | (4) 200 OK | | |
|<-------------| | | |<-------------| | |
| |(5)RS INVITE with SDP | | | |(5)RS INVITE with SDP | |
| |--------------------------------------------->| | |--------------------------------------------->|
| | | (6) 200 OK with SDP | | | | (6) 200 OK with SDP |
| |<---------------------------------------------| | |<---------------------------------------------|
|(7)CS RTP | | | |(7)CS RTP | | |
|=============>|======================>| | |=============>|======================>| |
|<=============|<======================| | |<=============|<======================| |
| |(8)RS RTP | | | |(8)RS RTP | |
| |=============================================>| | |=============================================>|
| |=============================================>| | |=============================================>|
|(9)CS BYE | | | |(9)CS BYE | | |
|------------->| | | |------------->| | |
| |(10)CS BYE | | | |(10)CS BYE | |
| |---------------------->| | | |---------------------->| |
| |(11)RS BYE | | | |(11)RS BYE | |
| |--------------------------------------------->| | |--------------------------------------------->|
| | | | | | | |
Figure 1: Basic recording call flow Figure 1: Basic recording call flow
The above call flow can also apply to the case of a centralized 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 conference with a mixer. For clarity, ACKs to INVITEs and 200 OKs to
BYEs are not shown. The conference focus can provide the SRC BYEs are not shown. The conference focus can provide the SRC
functionality since the conference focus has access to all the media functionality since the conference focus has access to all the media
from each conference participant. When a recording is requested, the from each conference participant. When a recording is requested, the
SRC delivers the metadata and the media streams to the SRS. Since 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 conference focus has access to a mixer, the SRC may choose to mix
skipping to change at page 8, line 5 skipping to change at page 7, line 45
SRS fails to understand the current stream of incremental updates for SRS fails to understand the current stream of incremental updates for
whatever reason, for example, when SRS loses the current state due to whatever reason, for example, when SRS loses the current state due to
internal failure. The SRS may optionally attach a reason along with internal failure. The SRS may optionally attach a reason along with
the snapshot request. This request allows both SRC and SRS to the snapshot request. This request allows both SRC and SRS to
synchronize the states with a new metadata snapshot so that further synchronize the states with a new metadata snapshot so that further
metadata incremental updates will be based on the latest metadata metadata incremental updates will be based on the latest metadata
snapshot. Similar to the metadata content, the metadata snapshot snapshot. Similar to the metadata content, the metadata snapshot
request is transported as content in UPDATE or INVITE sent by the SRS request is transported as content in UPDATE or INVITE sent by the SRS
in the recording session. in the recording session.
SRC SRS SRC SRS
| | | |
|(1) INVITE (metadata snapshot) | |(1) INVITE (metadata snapshot) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (2)200 OK | | (2)200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
|(3) ACK | |(3) ACK |
|---------------------------------------------------->| |---------------------------------------------------->|
|(4) RTP | |(4) RTP |
|====================================================>| |====================================================>|
|====================================================>| |====================================================>|
|(5) UPDATE (metadata update 1) | |(5) UPDATE (metadata update 1) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (6) 200 OK | | (6) 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
|(7) UPDATE (metadata update 2) | |(7) UPDATE (metadata update 2) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (8) 200 OK | | (8) 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
| (9) UPDATE (metadata snapshot request) | | (9) UPDATE (metadata snapshot request) |
|<----------------------------------------------------| |<----------------------------------------------------|
| (10) 200 OK | | (10) 200 OK |
|---------------------------------------------------->| |---------------------------------------------------->|
| (11) INVITE (metadata snapshot 2 + SDP offer) | | (11) INVITE (metadata snapshot 2 + SDP offer) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (12) 200 OK (SDP answer) | | (12) 200 OK (SDP answer) |
|<----------------------------------------------------| |<----------------------------------------------------|
| (13) UPDATE (metadata update 1 based on snapshot 2) | | (13) UPDATE (metadata update 1 based on snapshot 2) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (14) 200 OK | | (14) 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
Figure 2: Delivering metadata via SIP UPDATE Figure 2: Delivering metadata via SIP UPDATE
5.3. Receiving recording indications and providing recording 5.3. Receiving recording indications and providing recording
preferences preferences
The SRC is responsible to provide recording indications to the The SRC is responsible to provide recording indications to the
participants in the CS. A recording-aware UA supports receiving participants in the CS. A recording-aware UA supports receiving
recording indications via the SDP attribute a=record, and it can recording indications via the SDP attribute a=record, and it can
specify a recording preference in the CS by including the SDP specify a recording preference in the CS by including the SDP
skipping to change at page 9, line 13 skipping to change at page 9, line 7
To illustrate how the attributes are used, if a UA (A) is initiating To illustrate how the attributes are used, if a UA (A) is initiating
a call to UA (B) and UA (A) is also an SRC that is performing the a call to UA (B) and UA (A) is also an SRC that is performing the
recording, then UA (A) provides the recording indication in the SDP recording, then UA (A) provides the recording indication in the SDP
offer with a=record:on. Since UA (A) is the SRC, UA (A) receives the offer with a=record:on. Since UA (A) is the SRC, UA (A) receives the
recording indication from the SRC directly. When UA (B) receives the recording indication from the SRC directly. When UA (B) receives the
SDP offer, UA (B) will see that recording is happening on the other SDP offer, UA (B) will see that recording is happening on the other
endpoint of this session. Since UA (B) is not an SRC and does not endpoint of this session. Since UA (B) is not an SRC and does not
provide any recording preference, the SDP answer does not contain provide any recording preference, the SDP answer does not contain
a=record nor a=recordpref. a=record nor a=recordpref.
UA A UA B UA A UA B
(SRC) | (SRC) |
| | | |
| [SRC recording starts] | | [SRC recording starts] |
|(1) INVITE (SDP offer + a=record:on) | |(1) INVITE (SDP offer + a=record:on) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (2) 200 OK (SDP answer) | | (2) 200 OK (SDP answer) |
|<----------------------------------------------------| |<----------------------------------------------------|
|(3) ACK | |(3) ACK |
|---------------------------------------------------->| |---------------------------------------------------->|
|(4) RTP | |(4) RTP |
|<===================================================>| |<===================================================>|
| | | |
| [UA B wants to set preference to no recording] | | [UA B wants to set preference to no recording] |
| (5) INVITE (SDP offer + a=recordpref:off) | | (5) INVITE (SDP offer + a=recordpref:off) |
|<----------------------------------------------------| |<----------------------------------------------------|
| [SRC honors the preference and stops recording] | | [SRC honors the preference and stops recording] |
|(6) 200 OK (SDP answer + a=record:off) | |(6) 200 OK (SDP answer + a=record:off) |
|---------------------------------------------------->| |---------------------------------------------------->|
| (7) ACK | | (7) ACK |
|<----------------------------------------------------| |<----------------------------------------------------|
Figure 3: Recording indication and recording preference Figure 3: Recording indication and recording preference
After the call is established and recording is in progress, UA (B) After the call is established and recording is in progress, UA (B)
later decides to change the recording preference to no recording and later decides to change the recording preference to no recording and
sends a reINVITE with the a=recordpref attribute. It is up to the sends a reINVITE with the a=recordpref attribute. It is up to the
SRC to honor the preference, and in this case SRC decides to stop the SRC to honor the preference, and in this case SRC decides to stop the
recording and updates the recording indication in the SDP answer. recording and updates the recording indication in the SDP answer.
6. SIP Handling 6. SIP Handling
skipping to change at page 10, line 49 skipping to change at page 10, line 42
6.1.2. SIP extensions for recording indication and preference 6.1.2. SIP extensions for recording indication and preference
For the communication session, the SRC MUST provide recording For the communication session, the SRC MUST provide recording
indication to all participants in the CS. A participant UA in a CS indication to all participants in the CS. A participant UA in a CS
can indicate that it is recording-aware by providing the "record- can indicate that it is recording-aware by providing the "record-
aware" option tag, and the SRC MUST provide recording indications in aware" option tag, and the SRC MUST provide recording indications in
the new SDP a=record attribute described in the SDP Handling section. the new SDP a=record attribute described in the SDP Handling section.
In the absence of the "record-aware" option tag, meaning that the In the absence of the "record-aware" option tag, meaning that the
participant UA is not recording-aware, an SRC MUST provide recording participant UA is not recording-aware, an SRC MUST provide recording
indications through other means such as playing a tone inband, if the indications through other means such as playing a tone inband, if the
SRC is required to do so (e.g. based on policies). SRC is required to do so (e.g. based on policies).
An SRC in the CS may also indicate itself as a session recording An SRC in the CS may also indicate itself as a session recording
client by including the '+sip.src' feature tag. A recording-aware client by including the '+sip.src' feature tag. A recording-aware
participant can learn that a SRC is in the CS, and can set the participant can learn that a SRC is in the CS, and can set the
recording preference for the CS with the new SDP a=recordpref recording preference for the CS with the new SDP a=recordpref
attribute described in the SDP Handling section below. attribute described in the SDP Handling section below.
6.2. Procedures at the SRS 6.2. Procedures at the SRS
When an SRS receives a new INVITE, the SRS MUST only consider the SIP When an SRS receives a new INVITE, the SRS MUST only consider the SIP
session as a recording session when both the '+sip.src' feature tag session as a recording session when both the '+sip.src' feature tag
and 'siprec' option tag are included in the INVITE request. and 'siprec' option tag are included in the INVITE request.
The SRS can initiate a recording session by sending a SIP INVITE The SRS can initiate a recording session by sending a SIP INVITE
request to the SRC. The SRS and the SRC are identified in the From request to the SRC. The SRS and the SRC are identified in the From
and To headers, respectively. and To headers, respectively.
The SRS MUST include the '+sip.srs' feature tag in the Contact URI, The SRS MUST include the '+sip.srs' feature tag in the Contact URI,
as per [RFC3840], for all recording sessions. An SRC uses the as per [RFC3840], for all recording sessions. An SRC uses the
skipping to change at page 13, line 50 skipping to change at page 13, line 32
CS is created or terminated if a recording session handles multiple CS is created or terminated if a recording session handles multiple
CSes. To remove a recorded stream from the recording session, the CSes. To remove a recorded stream from the recording session, the
SRC sends a new SDP offer where the port of the media stream to be SRC sends a new SDP offer where the port of the media stream to be
removed is set to zero, according to the procedures in [RFC3264]. To removed is set to zero, according to the procedures in [RFC3264]. To
add a recorded stream to the recording session, the SRC sends a new add a recorded stream to the recording session, the SRC sends a new
SDP offer by adding a new media stream description or by reusing an SDP offer by adding a new media stream description or by reusing an
old media stream which had been previously disabled, according to the old media stream which had been previously disabled, according to the
procedures in [RFC3264]. procedures in [RFC3264].
The SRC can temporarily discontinue streaming and collection of The SRC can temporarily discontinue streaming and collection of
recorded media from the SRC to the SRS for reason such as masking the recorded media from the SRC to the SRS for reasons such as masking
recording. In this case, the SRC sends a new SDP offer and sets the the recording. In this case, the SRC sends a new SDP offer and sets
media stream to inactive (a=inactive) for each recorded stream to be the media stream to inactive (a=inactive) for each recorded stream to
paused, as per the procedures in [RFC3264]. To resume streaming and be paused, as per the procedures in [RFC3264]. To resume streaming
collection of recorded media, the SRC sends a new SDP offer and sets and collection of recorded media, the SRC sends a new SDP offer and
the media streams with a=sendonly attribute. Note that when a CS sets the media stream to sendonly (a=sendonly). Note that a CS
stream is muted/unmuted, this information is conveyed in the metadata itself may change the media stream direction by updating the SDP, for
by the SRC. The SRC SHOULD NOT modify the media stream with example, by setting a=inactive for SDP hold. Media stream direction
a=inactive for mute since this operation is reserved for pausing the changes in CS are conveyed in the metadata by the SRC. The SRC MUST
RS media. NOT modify the media stream with a=inactive for SDP hold on the CS
since this operation is reserved for pausing the RS media, however,
an SRC can have a local policy to pause the RS media when the CS is
placed on hold.
7.1.2. Recording indication in CS 7.1.2. Recording indication in CS
While there are existing mechanisms for providing an indication that While there are existing mechanisms for providing an indication that
a CS is being recorded, these mechanisms are usually delivered on the a CS is being recorded, these mechanisms are usually delivered on the
CS media streams such as playing an in-band tone or an announcement CS media streams such as playing an in-band tone or an announcement
to the participants. A new 'record' SDP attribute is introduced to to the participants. A new 'record' SDP attribute is introduced to
allow the SRC to indicate recording state to a recording-aware UA in allow the SRC to indicate recording state to a recording-aware UA in
CS. CS.
skipping to change at page 24, line 5 skipping to change at page 22, line 51
8.2. Roles 8.2. Roles
An SRC has the task of gathering media from the various UAs in one or An SRC has the task of gathering media from the various UAs in one or
more Communication Sessions (CSs) and forwarding the information to more Communication Sessions (CSs) and forwarding the information to
the SRS within the context of a corresponding Recording Session (RS). the SRS within the context of a corresponding Recording Session (RS).
There are numerous ways in which an SRC may do this is, including but There are numerous ways in which an SRC may do this is, including but
not limited to, appearing as a UA within a CS, or as a B2BUA between not limited to, appearing as a UA within a CS, or as a B2BUA between
UAs within a CS. UAs within a CS.
(Recording Session) +---------+ (Recording Session) +---------+
+------------SIP------->| | +------------SIP------->| |
| +------RTP/RTCP----->| SRS | | +------RTP/RTCP----->| SRS |
| | +-- Metadata -->| | | | +-- Metadata -->| |
| | | +---------+ | | | +---------+
v v | v v |
+---------+ +---------+
| SRC | | SRC |
|---------| (Communication Session) +---------+ |---------| (Communication Session) +---------+
| |<----------SIP---------->| | | |<----------SIP---------->| |
| UA-A | | UA-B | | UA-A | | UA-B |
| |<-------RTP/RTCP-------->| | | |<-------RTP/RTCP-------->| |
+---------+ +---------+ +---------+ +---------+
Figure 7: UA as SRC Figure 7: UA as SRC
(Recording Session) +---------+ (Recording Session) +---------+
+------------SIP------->| | +------------SIP------->| |
| +------RTP/RTCP----->| SRS | | +------RTP/RTCP----->| SRS |
| | +-- Metadata -->| | | | +-- Metadata -->| |
| | | +---------+ | | | +---------+
v v | v v |
+---------+ +---------+
| SRC | | SRC |
+---------+ |---------| +---------+ +---------+ |---------| +---------+
| |<----SIP----->| |<----SIP----->| | | |<----SIP----->| |<----SIP----->| |
| UA-A | | B2BUA | | UA-B | | UA-A | | B2BUA | | UA-B |
| |<--RTP/RTCP-->| |<--RTP/RTCP-->| | | |<--RTP/RTCP-->| |<--RTP/RTCP-->| |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
|_______________________________________________| |_______________________________________________|
(Communication Session) (Communication Session)
Figure 8: B2BUA as SRC Figure 8: B2BUA as SRC
The following subsections define a set of roles an SRC may choose to The following subsections define a set of roles an SRC may choose to
play based on its position with respect to a UA within a CS, and an play based on its position with respect to a UA within a CS, and an
SRS within an RS. A CS and a corresponding RS are independent SRS within an RS. A CS and a corresponding RS are independent
sessions; therefore, an SRC may play a different role within a CS sessions; therefore, an SRC may play a different role within a CS
than it does within the corresponding RS. than it does within the corresponding RS.
8.2.1. SRC acting as an RTP Translator 8.2.1. SRC acting as an RTP Translator
skipping to change at page 27, line 25 skipping to change at page 26, line 23
8.3. RTP Session Usage by SRC 8.3. RTP Session Usage by SRC
There are multiple ways that an SRC may choose to deliver recorded There are multiple ways that an SRC may choose to deliver recorded
media to an SRS. In some cases, it may use a single RTP session for media to an SRS. In some cases, it may use a single RTP session for
all media within the RS, whereas in others it may use multiple RTP all media within the RS, whereas in others it may use multiple RTP
sessions. The following subsections provide examples of basic RTP sessions. The following subsections provide examples of basic RTP
session usage by the SRC, including a discussion of how the RTP session usage by the SRC, including a discussion of how the RTP
constructs and mechanisms covered previously are used. An SRC may constructs and mechanisms covered previously are used. An SRC may
choose to use one or more of the RTP session usages within a single choose to use one or more of the RTP session usages within a single
RS. The set of RTP session usages described is not meant to be RS. For the purpose of base interoperability between SRC and SRS, an
SRC MUST support separate m-lines in SDP, one per CS media direction.
The set of RTP session usages described is not meant to be
exhaustive. exhaustive.
8.3.1. SRC Using Multiple m-lines 8.3.1. SRC Using Multiple m-lines
When using multiple m-lines, an SRC includes each m-line in an SDP When using multiple m-lines, an SRC includes each m-line in an SDP
offer to the SRS. The SDP answer from the SRS MUST include all offer to the SRS. The SDP answer from the SRS MUST include all
m-lines, with any rejected m-lines indicated with a zero port, per m-lines, with any rejected m-lines indicated with a zero port, per
[RFC3264]. Having received the answer, the SRC starts sending media [RFC3264]. Having received the answer, the SRC starts sending media
to the SRS as indicated in the answer. Alternatively, if the SRC to the SRS as indicated in the answer. Alternatively, if the SRC
deems the level of support indicated in the answer to be deems the level of support indicated in the answer to be
skipping to change at page 27, line 47 skipping to change at page 26, line 47
which an alternative RTP session usage is negotiated. which an alternative RTP session usage is negotiated.
In order to preserve the mapping of media to participant within the In order to preserve the mapping of media to participant within the
CSs in the RS, the SRC SHOULD map each unique CNAME within the CSs to CSs in the RS, the SRC SHOULD map each unique CNAME within the CSs to
a unique CNAME within the RS. Additionally, the SRC SHOULD map each a unique CNAME within the RS. Additionally, the SRC SHOULD map each
unique combination of CNAME/SSRC within the CSs to a unique CNAME/ unique combination of CNAME/SSRC within the CSs to a unique CNAME/
SSRC within the RS. In doing to, the SRC may act as an RTP SSRC within the RS. In doing to, the SRC may act as an RTP
translator or as an RTP endpoint. translator or as an RTP endpoint.
The following figure illustrates a case in which each UA represents a The following figure illustrates a case in which each UA represents a
participant contributing two RTP sessions (e.g. one for audio and one participant contributing two RTP sessions (e.g. one for audio and
for video), each with a single SSRC. The SRC acts as an RTP one for video), each with a single SSRC. The SRC acts as an RTP
translator and delivers the media to the SRS using four RTP sessions, translator and delivers the media to the SRS using four RTP sessions,
each with a single SSRC. The CNAME and SSRC values used by the UAs each with a single SSRC. The CNAME and SSRC values used by the UAs
within their media streams are preserved in the media streams from within their media streams are preserved in the media streams from
the SRC to the SRS. the SRC to the SRS.
+---------+ +---------+
+------------SSRC Aa--->| | +------------SSRC Aa--->| |
| + --------SSRC Av--->| | | + --------SSRC Av--->| |
| | +------SSRC Ba--->| SRS | | | +------SSRC Ba--->| SRS |
| | | +---SSRC Bv--->| | | | | +---SSRC Bv--->| |
| | | | +---------+ | | | | +---------+
| | | | | | | |
| | | | | | | |
+---------+ +----------+ +---------+ +---------+ +----------+ +---------+
| |---SSRC Aa-->| SRC |<--SSRC Ba---| | | |---SSRC Aa-->| SRC |<--SSRC Ba---| |
| UA-A | |(CNAME-A, | | UA-B | | UA-A | |(CNAME-A, | | UA-B |
|(CNAME-A)|---SSRC Av-->| CNAME-B) |<--SSRC Bv---|(CNAME-B)| |(CNAME-A)|---SSRC Av-->| CNAME-B) |<--SSRC Bv---|(CNAME-B)|
+---------+ +----------+ +---------+ +---------+ +----------+ +---------+
Figure 9: SRC Using Multiple m-lines Figure 9: SRC Using Multiple m-lines
8.3.2. SRC Using Mixing 8.3.2. SRC Using Mixing
When using mixing, the SRC combines RTP streams from different When using mixing, the SRC combines RTP streams from different
participants and sends them towards the SRS using its own SSRC. The participants and sends them towards the SRS using its own SSRC. The
SSRCs from the contributing participants SHOULD be conveyed as CSRCs SSRCs from the contributing participants SHOULD be conveyed as CSRCs
identifiers. The SRC includes one m-line for each RTP session in an identifiers. The SRC includes one m-line for each RTP session in an
SDP offer to the SRS. The SDP answer from the SRS MUST include all SDP offer to the SRS. The SDP answer from the SRS MUST include all
skipping to change at page 28, line 46 skipping to change at page 27, line 45
unique combination of CNAME/SSRC within the CSs to a unique CNAME/ unique combination of CNAME/SSRC within the CSs to a unique CNAME/
SSRC within the RS. The SRC MUST avoid SSRC collisions, rewriting SSRC within the RS. The SRC MUST avoid SSRC collisions, rewriting
SSRCs if necessary when used as CSRCs in the RS. In doing to, the SSRCs if necessary when used as CSRCs in the RS. In doing to, the
SRC acts as an RTP mixer. SRC acts as an RTP mixer.
In the event the SRS does not support this usage of CSRC values, it In the event the SRS does not support this usage of CSRC values, it
relies entirely on the SIPREC metadata to determine the participants relies entirely on the SIPREC metadata to determine the participants
included within each mixed stream. included within each mixed stream.
The following figure illustrates a case in which each UA represents a The following figure illustrates a case in which each UA represents a
participant contributing two RTP sessions (e.g. one for audio and one participant contributing two RTP sessions (e.g. one for audio and
for video), each with a single SSRC. The SRC acts as an RTP mixer one for video), each with a single SSRC. The SRC acts as an RTP
and delivers the media to the SRS using two RTP sessions, mixing mixer and delivers the media to the SRS using two RTP sessions,
media from each participant into a single RTP session containing a mixing media from each participant into a single RTP session
single SSRC and two CSRCs. containing a single SSRC and two CSRCs.
SSRC Sa +---------+ SSRC Sa +---------+
+-------CSRC Aa,Ba--->| | +-------CSRC Aa,Ba--->| |
| | | | | |
| SSRC Sa | SRS | | SSRC Sa | SRS |
| +---CSRC Av,Bv--->| | | +---CSRC Av,Bv--->| |
| | +---------+ | | +---------+
| | | |
+----------+ +----------+
+---------+ | SRC | +---------+ +---------+ | SRC | +---------+
| |---SSRC Aa-->|(CNAME-S, |<--SSRC Ba---| | | |---SSRC Aa-->|(CNAME-S, |<--SSRC Ba---| |
| UA-A | | CNAME-A, | | UA-B | | UA-A | | CNAME-A, | | UA-B |
|(CNAME-A)|---SSRC Aa-->| CNAME-B) |<--SSRC Bv---|(CNAME-B)| |(CNAME-A)|---SSRC Aa-->| CNAME-B) |<--SSRC Bv---|(CNAME-B)|
+---------+ +----------+ +---------+ +---------+ +----------+ +---------+
Figure 10: SRC Using Mixing Figure 10: SRC Using Mixing
8.4. RTP Session Usage by SRS 8.4. RTP Session Usage by SRS
An SRS that supports recording an audio CS MUST support SRC usage of An SRS that supports recording an audio CS MUST support SRC usage of
separate audio m-lines in SDP, one per CS media direction. An SRS separate audio m-lines in SDP, one per CS media direction. An SRS
that supports recording an video CS MUST support SRC usage of that supports recording an video CS MUST support SRC usage of
separate video m-lines in SDP, one per CS media direction. separate video m-lines in SDP, one per CS media direction.
Therefore, for an SRS supporting a typical audio call, the SRS has to Therefore, for an SRS supporting a typical audio call, the SRS has to
skipping to change at page 29, line 42 skipping to change at page 28, line 39
Note that these requirements allow an SRS to be implemented that Note that these requirements allow an SRS to be implemented that
supports video only, without requiring support for audio recording. supports video only, without requiring support for audio recording.
They also allow an SRS to be implemented that supports recording only They also allow an SRS to be implemented that supports recording only
one direction of one stream in a CS; for example, an SRS designed to one direction of one stream in a CS; for example, an SRS designed to
record security monitoring cameras that only send (not receive) video record security monitoring cameras that only send (not receive) video
without any audio. These requirements were not written to prevent without any audio. These requirements were not written to prevent
other modes being implemented and used, such as using a single m-line other modes being implemented and used, such as using a single m-line
and mixing the separate audio streams together. Rather, the and mixing the separate audio streams together. Rather, the
requirements were written to provide a common base mode to implement requirements were written to provide a common base mode to implement
to the sake of interoperability. SRS implementations may support for the sake of interoperability. It is important to note that an
other modes as well, but have to at least support the ones above such SRS implementation supporting the common base may not record all
that they interoperate in the common base mode. media streams in a CS if a participant supports more than one m-line
in a video call, such as one for camera and one for presentation.
SRS implementations may support other modes as well, but have to at
least support the ones above such that they interoperate in the
common base mode for basic interoperability.
9. Metadata 9. Metadata
9.1. Procedures at the SRC 9.1. Procedures at the SRC
The SRC MUST deliver metadata to the SRS in a recording session; the The SRC MUST deliver metadata to the SRS in a recording session; the
timing of which SRC sends the metadata depends on when the metadata timing of which SRC sends the metadata depends on when the metadata
becomes available. Metadata SHOULD be provided by the SRC in the becomes available. Metadata SHOULD be provided by the SRC in the
initial INVITE request when establishing the recording session, and initial INVITE request when establishing the recording session, and
subsequent metadata updates can be provided by the SRC in reINVITE subsequent metadata updates can be provided by the SRC in reINVITE
skipping to change at page 31, line 5 skipping to change at page 29, line 46
the "recording-session" disposition. A partial update represents an the "recording-session" disposition. A partial update represents an
incremental update since the last metadata update sent by the SRC. A incremental update since the last metadata update sent by the SRC. A
partial update sent by the SRC can be an INVITE request or response partial update sent by the SRC can be an INVITE request or response
with an SDP offer, or an INVITE/UPDATE request or response containing with an SDP offer, or an INVITE/UPDATE request or response containing
a "recording-session" disposition, or an INVITE request containing a "recording-session" disposition, or an INVITE request containing
both an SDP offer and the "recording-session" disposition. both an SDP offer and the "recording-session" disposition.
The following is an example of a full metadata snapshot sent by the The following is an example of a full metadata snapshot sent by the
SRC in the initial INVITE request: SRC in the initial INVITE request:
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-098392474 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
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
Require: siprec Require: siprec
Accept: application/sdp, application/rs-metadata, Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length] Content-Length: [length]
--foobar --foobar
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=SRS 2890844526 2890844526 IN IP4 198.51.100.1 o=SRS 2890844526 2890844526 IN IP4 198.51.100.1
s=- s=-
c=IN IP4 198.51.100.1 c=IN IP4 198.51.100.1
t=0 0 t=0 0
m=audio 12240 RTP/AVP 0 4 8 m=audio 12240 RTP/AVP 0 4 8
a=sendonly a=sendonly
a=label:1 a=label:1
--foobar --foobar
Content-Type: application/rs-metadata Content-Type: application/rs-metadata
Content-Disposition: recording-session Content-Disposition: recording-session
[metadata content] [metadata content]
Figure 11: Sample INVITE request for the recording session Figure 11: Sample INVITE request for the recording session
9.2. Procedures at the SRS 9.2. Procedures at the SRS
The SRS receives metadata updates from the SRC in INVITE and UPDATE The SRS receives metadata updates from the SRC in INVITE and UPDATE
requests. Since the SRC can send partial updates based on the requests. Since the SRC can send partial updates based on the
previous update, the SRS needs to keep track of the sequence of previous update, the SRS needs to keep track of the sequence of
updates from the SRC. updates from the SRC.
skipping to change at page 32, line 15 skipping to change at page 31, line 10
again even when a full metadata snapshot is requested. In order to again even when a full metadata snapshot is requested. In order to
avoid repeating the same error, the SRS can simply terminate the avoid repeating the same error, the SRS can simply terminate the
recording session when a syntax error or semantic error is detected recording session when a syntax error or semantic error is detected
in the metadata. in the metadata.
When the SRS explicitly requests for a full metadata snapshot, the When the SRS explicitly requests for a full metadata snapshot, the
SRS MUST send an UPDATE request without an SDP offer. A metadata SRS MUST send an UPDATE request without an SDP offer. A metadata
snapshot request contains a content with the content disposition type snapshot request contains a content with the content disposition type
"recording-session". Note that the SRS MAY generate an INVITE "recording-session". Note that the SRS MAY generate an INVITE
request without an SDP offer but this MUST NOT include a metadata request without an SDP offer but this MUST NOT include a metadata
snapshot request. The format of the content is "application/ snapshot request. The format of the content is "application/rs-
rs-metadata-request", and the body format is chosen to be a simple metadata-request", and the body format is chosen to be a simple text-
text-based format. The following shows an example: based format. The following shows an example:
UPDATE sip:2000@src.exmaple.com SIP/2.0 UPDATE sip:2000@src.exmaple.com SIP/2.0
Via: SIP/2.0/UDP srs.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/UDP srs.example.com;branch=z9hG4bKdf6b622b648d9
To: <sip:2000@exmaple.com>;tag=35e195d2-947d-4585-946f-098392474 To: <sip:2000@exmaple.com>;tag=35e195d2-947d-4585-946f-098392474
From: <sip:recorder@example.com>;tag=1234567890 From: <sip:recorder@example.com>;tag=1234567890
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
CSeq: 1 UPDATE CSeq: 1 UPDATE
Max-Forwards: 70 Max-Forwards: 70
Require: siprec Require: siprec
Contact: <sip:recorder@srs.example.com>;+sip.srs Contact: <sip:recorder@srs.example.com>;+sip.srs
skipping to change at page 33, line 5 skipping to change at page 31, line 45
processing of the content by the SRC is entirely optional since the processing of the content by the SRC is entirely optional since the
content is for logging only, and the snapshot request itself is content is for logging only, and the snapshot request itself is
indicated by the use of the application/rs-metadata-request content indicated by the use of the application/rs-metadata-request content
type. type.
When the SRC receives the request for a metadata snapshot, the SRC When the SRC receives the request for a metadata snapshot, the SRC
MUST provide a full metadata snapshot in a separate INVITE or UPDATE MUST provide a full metadata snapshot in a separate INVITE or UPDATE
transaction, along with an SDP offer. All subsequent metadata transaction, along with an SDP offer. All subsequent metadata
updates sent by the SRC MUST be based on the new metadata snapshot. updates sent by the SRC MUST be based on the new metadata snapshot.
The metadata received by the SRS can contain ID elements used to
cross reference one element to another. An element containing the
definition of an ID, and an element containing a reference to that ID
will often be received from the same SRC. It is also valid for those
elements to be received from different SRCs, for example, when each
endpoint in the same CS act as an SRC to record the call and a common
ID refers to the same CS. The SRS MUST NOT consider this an error.
9.2.1. Formal Syntax 9.2.1. Formal Syntax
The formal syntax for the application/rs-metadata-request MIME is The formal syntax for the application/rs-metadata-request MIME is
described below using the augmented Backus-Naur Form (BNF) as described below using the augmented Backus-Naur Form (BNF) as
described in [RFC5234]. described in [RFC5234].
snapshot-request = srs-reason-line CRLF snapshot-request = srs-reason-line CRLF
srs-reason-line = [TEXT-UTF8-TRIM] srs-reason-line = [TEXT-UTF8-TRIM]
skipping to change at page 38, line 10 skipping to change at page 37, line 6
a different administrative domain, it is important to perform mutual a different administrative domain, it is important to perform mutual
authentication to ensure the authenticity of both the SRC and the SRS authentication to ensure the authenticity of both the SRC and the SRS
before transmitting any recorded media. The risk of not before transmitting any recorded media. The risk of not
authenticating the SRS is that the recording may be sent to a authenticating the SRS is that the recording may be sent to a
compromised SRS and that a sensitive call recording will be obtained compromised SRS and that a sensitive call recording will be obtained
by an attacker. On the other hand, the risk of not authenticating by an attacker. On the other hand, the risk of not authenticating
the SRC is that an SRS will accept calls from an unknown SRC and the SRC is that an SRS will accept calls from an unknown SRC and
allow potential forgery of call recordings. allow potential forgery of call recordings.
There may be scenarios in which the signaling between the SRC and SRS There may be scenarios in which the signaling between the SRC and SRS
is not direct, e.g. a SIP proxy exists between the SRC and the SRS. is not direct, e.g. a SIP proxy exists between the SRC and the SRS.
In such scenarios, each hop is subject to the TLS mutual In such scenarios, each hop is subject to the TLS mutual
authentication constraint and transitive trust at each hop is authentication constraint and transitive trust at each hop is
utilized. Additionally, an SRC or SRS may use other existing SIP utilized. Additionally, an SRC or SRS may use other existing SIP
mechanisms available, including but not limited to, Digest mechanisms available, including but not limited to, Digest
Authentication [RFC3261], Asserted Identity [RFC3325], and Connected Authentication [RFC3261], Asserted Identity [RFC3325], and Connected
Identity [RFC4916]. Identity [RFC4916].
The SRS may have its own set of recording policies to authorize The SRS may have its own set of recording policies to authorize
recording requests from the SRC. The use of recording policies is recording requests from the SRC. The use of recording policies is
outside the scope of the Session Recording Protocol. outside the scope of the Session Recording Protocol.
skipping to change at page 38, line 49 skipping to change at page 37, line 45
or different keys in the RS than the ones used in the CS. Some SRCs or different keys in the RS than the ones used in the CS. Some SRCs
are designed to simply replicate RTP packets from a CS media stream are designed to simply replicate RTP packets from a CS media stream
to the SRS, in which case the SRC will use the same key in the RS as to the SRS, in which case the SRC will use the same key in the RS as
used in the CS. In this case, the SRC MUST secure the SDP containing used in the CS. In this case, the SRC MUST secure the SDP containing
the keying material in the RS with at least the same level of the keying material in the RS with at least the same level of
security as in the CS. The risk of lowering the level of security in security as in the CS. The risk of lowering the level of security in
the RS is that it will effectively become a downgrade attack on the the RS is that it will effectively become a downgrade attack on the
CS since the same key is used for both CS and RS. CS since the same key is used for both CS and RS.
SRCs that decrypt an encrypted CS media stream and re-encrypt it when SRCs that decrypt an encrypted CS media stream and re-encrypt it when
sending it to the SRS SHOULD use a different key for the RS media sending it to the SRS MUST use a different key for the RS media
stream than what is used for the CS media stream, to ensure that it stream than what is used for the CS media stream, to ensure that it
is not possible for someone who has the key for the CS media stream is not possible for someone who has the key for the CS media stream
to access recorded data they are not authorized to access. to access recorded data they are not authorized to access.
12.3. Metadata 12.3. Metadata
Metadata contains sensitive information such as the address of record Metadata contains sensitive information such as the address of record
of the participants and other extension data placed by the SRC. It of the participants and other extension data placed by the SRC. It
is essential to protect the content of the metadata in the RS. Since is essential to protect the content of the metadata in the RS. Since
metadata is a content type transmitted in SIP signaling, metadata metadata is a content type transmitted in SIP signaling, metadata
SHOULD be protected at the transport level by SIPS/TLS. SHOULD be protected at the transport level by SIPS/TLS.
12.4. Storage and playback 12.4. Storage and playback
While storage and playback of the call recording is beyond the scope While storage and playback of the call recording is beyond the scope
of this document, it is worthwhile to mention here that it is also of this document, it is worthwhile to mention here that it is also
skipping to change at page 39, line 38 skipping to change at page 38, line 34
Mohan R, Hadriel Kaplan, Adam Roach, Miguel Garcia, Thomas Stach, Mohan R, Hadriel Kaplan, Adam Roach, Miguel Garcia, Thomas Stach,
Muthu Perumal, Dan Wing, and Magnus Westerlund for their valuable Muthu Perumal, Dan Wing, and Magnus Westerlund for their valuable
comments and inputs to this document. comments and inputs to this document.
14. References 14. References
14.1. Normative References 14.1. Normative 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-
draft-ietf-siprec-metadata-10 (work in progress), metadata-11 (work in progress), January 2013.
November 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999. Registration Procedure", BCP 31, RFC 2506, March 1999.
[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.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264, June
June 2002. 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description [RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006. Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 41, line 12 skipping to change at page 40, line 7
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
July 2006. 2006.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007. Protocol (SIP)", RFC 4916, June 2007.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007. BCP 131, RFC 4961, July 2007.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
 End of changes. 38 change blocks. 
285 lines changed or deleted 296 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/