draft-ietf-siprec-protocol-11.txt   draft-ietf-siprec-protocol-12.txt 
SIPREC L. Portman SIPREC L. Portman
Internet-Draft NICE Systems Internet-Draft NICE Systems
Intended status: Standards Track H. Lum, Ed. Intended status: Standards Track H. Lum, Ed.
Expires: April 20, 2014 Genesys Expires: August 18, 2014 Genesys
C. Eckel C. Eckel
Cisco Cisco
A. Johnston A. Johnston
Avaya Avaya
A. Hutton A. Hutton
Unify Unify
October 17, 2013 February 14, 2014
Session Recording Protocol Session Recording Protocol
draft-ietf-siprec-protocol-11 draft-ietf-siprec-protocol-12
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
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 April 20, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
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 recording 5.3. Receiving recording indications and providing 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 . . . . . . . . . . . . . . . . . . 10
6.1.1. Initiating a Recording Session . . . . . . . . . . . 9 6.1.1. Initiating a Recording Session . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . 10 6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 11
6.3. Procedures for Recording-aware User Agents . . . . . . . 11 6.3. Procedures for Recording-aware User Agents . . . . . . . 11
7. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . 11 7. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . 13 7.1.2. Recording indication in CS . . . . . . . . . . . . . 14
7.1.3. Recording preference in CS . . . . . . . . . . . . . 14 7.1.3. Recording preference in CS . . . . . . . . . . . . . 15
7.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 14 7.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 15
7.3. Procedures for Recording-aware User Agents . . . . . . . 16 7.3. Procedures for Recording-aware User Agents . . . . . . . 17
7.3.1. Recording indication . . . . . . . . . . . . . . . . 17 7.3.1. Recording indication . . . . . . . . . . . . . . . . 17
7.3.2. Recording preference . . . . . . . . . . . . . . . . 17 7.3.2. Recording preference . . . . . . . . . . . . . . . . 18
8. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . 18 8. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. RTP Mechanisms . . . . . . . . . . . . . . . . . . . . . 18 8.1. RTP Mechanisms . . . . . . . . . . . . . . . . . . . . . 19
8.1.1. RTCP . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1.1. RTCP . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1.2. RTP Profile . . . . . . . . . . . . . . . . . . . . . 19 8.1.2. RTP Profile . . . . . . . . . . . . . . . . . . . . . 20
8.1.3. SSRC . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1.3. SSRC . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1.4. CSRC . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1.4. CSRC . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1.5. SDES . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1.5. SDES . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1.5.1. CNAME . . . . . . . . . . . . . . . . . . . . . . 20 8.1.5.1. CNAME . . . . . . . . . . . . . . . . . . . . . . 21
8.1.6. Keepalive . . . . . . . . . . . . . . . . . . . . . . 20 8.1.6. Keepalive . . . . . . . . . . . . . . . . . . . . . . 21
8.1.7. RTCP Feedback Messages . . . . . . . . . . . . . . . 21 8.1.7. RTCP Feedback Messages . . . . . . . . . . . . . . . 22
8.1.7.1. Full Intra Request . . . . . . . . . . . . . . . 21 8.1.7.1. Full Intra Request . . . . . . . . . . . . . . . 22
8.1.7.2. Picture Loss Indicator . . . . . . . . . . . . . 21 8.1.7.2. Picture Loss Indicator . . . . . . . . . . . . . 22
8.1.7.3. Temporary Maximum Media Stream Bit Rate Request . 22 8.1.7.3. Temporary Maximum Media Stream Bit Rate Request . 23
8.1.8. Symmetric RTP/RTCP for Sending and Receiving . . . . 22 8.1.8. Symmetric RTP/RTCP for Sending and Receiving . . . . 23
8.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2.1. SRC acting as an RTP Translator . . . . . . . . . . . 24 8.2.1. SRC acting as an RTP Translator . . . . . . . . . . . 24
8.2.1.1. Forwarding Translator . . . . . . . . . . . . . . 24 8.2.1.1. Forwarding Translator . . . . . . . . . . . . . . 25
8.2.1.2. Transcoding Translator . . . . . . . . . . . . . 24 8.2.1.2. Transcoding Translator . . . . . . . . . . . . . 25
8.2.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . 25 8.2.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . 26
8.2.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 26 8.2.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 26
8.3. RTP Session Usage by SRC . . . . . . . . . . . . . . . . 26 8.3. RTP Session Usage by SRC . . . . . . . . . . . . . . . . 27
8.3.1. SRC Using Multiple m-lines . . . . . . . . . . . . . 26 8.3.1. SRC Using Multiple m-lines . . . . . . . . . . . . . 27
8.3.2. SRC Using Mixing . . . . . . . . . . . . . . . . . . 27 8.3.2. SRC Using Mixing . . . . . . . . . . . . . . . . . . 28
8.4. RTP Session Usage by SRS . . . . . . . . . . . . . . . . 28 8.4. RTP Session Usage by SRS . . . . . . . . . . . . . . . . 29
9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 29 9.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 30
9.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 31 9.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 32
9.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 32 9.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 33
10. Persistent Recording . . . . . . . . . . . . . . . . . . . . 32 10. Persistent Recording . . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11.1. Registration of Option Tags . . . . . . . . . . . . . . 33 11.1. Registration of Option Tags . . . . . . . . . . . . . . 34
11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . 33 11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . 34
11.1.2. record-aware Option Tag . . . . . . . . . . . . . . 33 11.1.2. record-aware Option Tag . . . . . . . . . . . . . . 34
11.2. Registration of media feature tags . . . . . . . . . . . 34 11.2. Registration of media feature tags . . . . . . . . . . . 34
11.2.1. src feature tag . . . . . . . . . . . . . . . . . . 34 11.2.1. src feature tag . . . . . . . . . . . . . . . . . . 34
11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . 34 11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . 35
11.3. New Content-Disposition Parameter Registrations . . . . 35 11.3. New Content-Disposition Parameter Registrations . . . . 35
11.4. Media Type Registration . . . . . . . . . . . . . . . . 35 11.4. Media Type Registration . . . . . . . . . . . . . . . . 36
11.4.1. Registration of MIME Type application/rs-metadata . 35 11.4.1. Registration of MIME Type application/rs-metadata . 36
11.4.2. Registration of MIME Type application/rs-metadata- 11.4.2. Registration of MIME Type application/rs-metadata-
request . . . . . . . . . . . . . . . . . . . . . . 35 request . . . . . . . . . . . . . . . . . . . . . . 36
11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 35 11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 36
11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . 35 11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . 36
11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . 36 11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . 37
12. Security Considerations . . . . . . . . . . . . . . . . . . . 36 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
12.1. Authentication and Authorization . . . . . . . . . . . . 37 12.1. Authentication and Authorization . . . . . . . . . . . . 38
12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . 37 12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . 38
12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 38 12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 39
12.4. Storage and playback . . . . . . . . . . . . . . . . . . 38 12.4. Storage and playback . . . . . . . . . . . . . . . . . . 39
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.1. Normative References . . . . . . . . . . . . . . . . . . 39 14.1. Normative References . . . . . . . . . . . . . . . . . . 40
14.2. Informative References . . . . . . . . . . . . . . . . . 39 14.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
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 5, line 43 skipping to change at page 5, line 47
recording metadata from the SRC to the SRS. recording metadata from the SRC to the SRS.
As mentioned in the architecture document As mentioned in the architecture document
[I-D.ietf-siprec-architecture], there are a number of types of call [I-D.ietf-siprec-architecture], there are a number of types of call
flows based on the location of the Session Recording Client. The flows based on the location of the Session Recording Client. The
following sample call flows provide a quick overview of the following sample call flows provide a quick overview of the
operations between the SRC and the SRS. operations between the SRC and the SRS.
5.1. Delivering recorded media 5.1. Delivering recorded media
When a SIP Back-to-back User Agent (B2BUA) with SRC functionality When a SIP Back-to-Back User Agent (B2BUA) with SRC functionality
routes a call from UA(A) to UA(B), the SRC has access to the media routes a call from UA(A) to UA(B), the SRC has access to the media
path between the user agents. When the SRC is aware that it should path between the user agents. When the SRC is aware that it should
be recording the conversation, the SRC can cause the B2BUA to bridge be recording the conversation, the SRC can cause the B2BUA to bridge
the media between UA(A) and UA(B). The SRC then establishes the the media between UA(A) and UA(B). The SRC then establishes the
Recording Session with the SRS and sends replicated media towards the Recording Session with the SRS and sends replicated media towards the
SRS. SRS.
An endpoint may also have SRC functionality, where the endpoint An endpoint may also have SRC functionality, where the endpoint
itself establishes the Recording Session to the SRS. Since the itself establishes the Recording Session to the SRS. Since the
endpoint has access to the media in the Communication Session, the endpoint has access to the media in the Communication Session, the
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 7, line 45 skipping to change at page 8, line 5
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 7 skipping to change at page 9, line 15
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 14, line 37 skipping to change at page 15, line 9
on Recording is in progress. on Recording is in progress.
off No recording is in progress. off No recording is in progress.
paused Recording is in progress but media is paused. paused Recording is in progress but media is paused.
7.1.3. Recording preference in CS 7.1.3. Recording preference in CS
When the SRC receives the a=recordpref SDP in an SDP offer or answer, When the SRC receives the a=recordpref SDP in an SDP offer or answer,
the SRC chooses to honor the preference to record based on local the SRC chooses to honor the preference to record based on local
policy at the SRC. If the SRC makes a change in recording state, policy at the SRC. If the SRC makes a change in recording state, the
then the SRC reports the recording state in the a=record attribute in SRC MUST report the new recording state in the a=record attribute in
the SDP answer or in a subsequent SDP offer/answer. the SDP answer or in a subsequent SDP offer.
7.2. Procedures at the SRS 7.2. Procedures at the SRS
Typically the SRS only receives RTP streams from the SRC; therefore, Typically the SRS only receives RTP streams from the SRC; therefore,
the SDP offer/answer from the SRS normally sets each media stream to the SDP offer/answer from the SRS normally sets each media stream to
receive media, by setting them with the a=recvonly attribute, receive media, by setting them with the a=recvonly attribute,
according to the procedures of [RFC3264]. When the SRS is not ready according to the procedures of [RFC3264]. When the SRS is not ready
to receive a recorded stream, the SRS sets the media stream as to receive a recorded stream, the SRS sets the media stream as
inactive in the SDP offer or answer by setting it with a=inactive inactive in the SDP offer or answer by setting it with a=inactive
attribute, according to the procedures of [RFC3264]. When the SRS is attribute, according to the procedures of [RFC3264]. When the SRS is
ready to receive recorded streams, the SRS sends a new SDP offer and ready to receive recorded streams, the SRS sends a new SDP offer and
sets the media streams with a=recvonly attribute. sets the media streams with a=recvonly attribute.
skipping to change at page 17, line 17 skipping to change at page 17, line 47
includes the a=record attribute, the UA MUST provide the recording includes the a=record attribute, the UA MUST provide the recording
indication to the end user whether the recording is on, off, or indication to the end user whether the recording is on, off, or
paused for each medium based on the most recently received a=record paused for each medium based on the most recently received a=record
SDP attribute for that medium. SDP attribute for that medium.
When a CS is traversed through multiple UAs such as a B2BUA or a When a CS is traversed through multiple UAs such as a B2BUA or a
conference focus, each UA involved in the CS that is aware that the conference focus, each UA involved in the CS that is aware that the
CS is being recorded MUST provide the recording indication through CS is being recorded MUST provide the recording indication through
the a=record attribute to all other parties in the CS. the a=record attribute to all other parties in the CS.
It is possible that more than one SRC can be in the call path It is possible that more than one SRC is in the call path of the same
recording the same CS, but the recording indication attribute does CS, but the recording indication attribute does not provide any hint
not provide any hint as to which SRC is actually performing the as to which SRC or how many SRCs are recording. An endpoint knows
recording. This means that an endpoint only knows that the call is only that the call is being recorded. Furthermore, this attribute is
being recorded through the recording indicator. This attribute is not used as a request for a specific SRC to start/stop recording.
also not used as an indication to negotiate which SRC in the call
path will perform recording and is not used as a request to start/
stop recording if there are multiple SRCs in the call path.
7.3.2. Recording preference 7.3.2. Recording preference
A participant in a CS MAY set the recording preference in the CS to A participant in a CS MAY set the recording preference in the CS to
be recorded or not recorded at session establishment or during the be recorded or not recorded at session establishment or during the
session. A new 'recordpref' SDP attribute is introduced, and the session. A new 'recordpref' SDP attribute is introduced, and the
participant in CS may set this recording preference attribute in any participant in CS may set this recording preference attribute in any
SDP offer/answer at session establishment time or during the session. SDP offer/answer at session establishment time or during the session.
The SRC is not required to honor the recording preference from a The SRC is not required to honor the recording preference from a
participant based on local policies at the SRC, and the participant participant based on local policies at the SRC, and the participant
skipping to change at page 23, line 14 skipping to change at page 24, line 5
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, including but There are numerous ways in which an SRC may do this, 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 24 skipping to change at page 28, line 8
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 one
for video), each with a single SSRC. The SRC acts as an RTP 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 24 skipping to change at page 29, line 7
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 one
for video), each with a single SSRC. The SRC acts as an RTP mixer for video), each with a single SSRC. The SRC acts as an RTP mixer
and delivers the media to the SRS using two RTP sessions, mixing and delivers the media to the SRS using two RTP sessions, mixing
media from each participant into a single RTP session containing a media from each participant into a single RTP session containing a
single SSRC and two CSRCs. 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 24 skipping to change at page 30, line 7
for the sake of interoperability. It is important to note that an for the sake of interoperability. It is important to note that an
SRS implementation supporting the common base may not record all SRS implementation supporting the common base may not record all
media streams in a CS if a participant supports more than one m-line 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. 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 SRS implementations may support other modes as well, but have to at
least support the ones above such that they interoperate in the least support the ones above such that they interoperate in the
common base mode for basic interoperability. common base mode for basic interoperability.
9. Metadata 9. Metadata
9.1. Procedures at the SRC Some metadata attributes are contained in SDP, and others are
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
becomes available. Metadata SHOULD be provided by the SRC in the
initial INVITE request when establishing the recording session, and
subsequent metadata updates can be provided by the SRC in reINVITE
and UPDATE requests ([RFC3311]) and responses in the recording
session. There are cases that metadata is not available in the
initial INVITE request sent by the SRC, for example, when a recording
session is established in the absence of a communication session, and
the SRC would update the recording session with metadata whenever
metadata becomes available.
Certain metadata attributes are contained in the SDP, and others are
contained in a new content type "application/rs-metadata". The contained in a new content type "application/rs-metadata". The
format of the metadata is described as part of the mechanism in format of the metadata is described as part of the mechanism in
[I-D.ietf-siprec-metadata]. A new "disposition-type" of Content- [I-D.ietf-siprec-metadata]. A new "disposition-type" of Content-
Disposition is defined for the purpose of carrying metadata and the Disposition is defined for the purpose of carrying metadata. The
value is "recording-session". The "recording-session" value value is "recording-session", which indicates the "application/rs-
indicates that the "application/rs-metadata" content contains metadata" content contains metadata to be handled by the SRS.
metadata to be handled by the SRS, and the disposition can be carried
in either INVITE or UPDATE requests or responses sent by the SRC.
Metadata sent by the SRC can be categorized as either a full metadata 9.1. Procedures at the SRC
snapshot or partial update. A full metadata snapshot describes all
the recorded streams and all metadata associated with the recording
session. The SRC MAY send a full metadata snapshot at any time. The
SRC MAY send a partial update if a full metadata snapshot has
previously been sent. If the SRC receives a snapshot request from
the SRS, then it MUST immediately send a full metadata snapshot.
The SRC MAY send metadata (either a full metadata shapshot or a The SRC MUST send metadata to the SRS in an RS. The SRC SHOULD send
partial update) in either an INVITE request, an UPDATE request metadata as soon as it becomes available and whenever it changes.
([RFC3311]), or in the final (200) response to an offerless INVITE Cases in which an SRC may be justified in waiting temporarily before
from the SRS. If any of the metadata being sent contains a reference sending metadata include:
to any SDP labels, then the request containing the metadata MUST also
contain an SDP offer that defines those labels.
When an INVITE or UPDATE request contains both an SDP offer and o waiting for previous metadata exchange to complete (i.e. cannot
metadata, then the request body has content type multipart/mixed, send another SDP offer until previous offer/answer completes, and
with one subordinate body part containing the SDP offer and another may prefer not to send an UPDATE during this time either).
containing the metadata. When an INVITE contains only an SDP offer
or metadata, then the multipart/mixed container is optional. o constraining the signaling rate on the RS.
o sending metadata when key events occur rather than for every event
that has any impact on metadata.
o desire to suppress certain metadata out of concern for privacy or
perceived lack of need for it to be included in the recording.
Metadata sent by the SRC is categorized as either a full metadata
snapshot or a partial update. A full metadata snapshot describes all
metadata associated with the RS. The SRC MAY send a full metadata
snapshot at any time. The SRC MAY send a partial update only if a
full metadata snapshot has been sent previously.
The SRC MAY send metadata (either a full metadata snapshot or a
partial update) in an INVITE request, an UPDATE request [RFC3311], or
an 200 response to an offerless INVITE from the SRS. If the metadata
contains a reference to any SDP labels, the request containing the
metadata MUST also contain an SDP offer that defines those labels.
When a SIP message contains both an SDP offer and metadata, the
request body MUST have content type "multipart/mixed", with one
subordinate body part containing the SDP offer and another containing
the metadata. When a SIP message contains only an SDP offer or
metadata, the "multipart/mixed" container is optional.
The SRC SHOULD include a full metadata snapshot in the initial INVITE
request establishing the RS. If metadata is not yet available (e.g
an RS established in absence of a CS), the SRC SHOULD send a full
metadata snapshot as soon as metadata becomes available.
If the SRC receives a snapshot request from the SRS, it MUST
immediately send a full metadata snapshot.
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-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
CSeq: 101 INVITE CSeq: 101 INVITE
skipping to change at page 31, line 28 skipping to change at page 32, line 24
recover from the internal failure by requesting for a full metadata recover from the internal failure by requesting for a full metadata
snapshot from the SRC. Certain errors, such as syntax errors or snapshot from the SRC. Certain errors, such as syntax errors or
semantic errors in the metadata information, are likely caused by an semantic errors in the metadata information, are likely caused by an
error on the SRC side, and it is likely the same error will occur error on the SRC side, and it is likely the same error will occur
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.
The SRS MAY explicitly request a full metadata snapshot by sending an The SRS MAY explicitly request a full metadata snapshot by sending an
UPDATE request. This request MUST contain a body with a content UPDATE request. This request MUST contain a body with content
disposition type "recording-session", and MUST NOT contain an SDP disposition type "recording-session", and MUST NOT contain an SDP
body part. Note that the SRS MAY generate an INVITE request without body. The SRS MUST NOT request a full metadata snapshot in an UPDATE
an SDP offer but this MUST NOT include a metadata snapshot request. response or in any other SIP transaction. The format of the content
The format of the content is "application/rs-metadata-request", and is "application/rs-metadata-request", and the body format is a simple
the body format is chosen to be a simple text-based format. The text-based format. The following shows an example:
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 32, line 35 skipping to change at page 33, line 32
elements to be received from different SRCs, for example, when each 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 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. 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]
; TEXT-UTF8-TRIM defined in RFC3261 ; TEXT-UTF8-TRIM defined in RFC3261
10. Persistent Recording 10. Persistent Recording
Persistent recording is a specific use case outlined in REQ-005 or Persistent recording is a specific use case outlined in REQ-005 or
Use Case 4 in [RFC6341], where a recording session can be established Use Case 4 in [RFC6341], where a recording session can be established
in the absence of a communication session. The SRC continuously in the absence of a communication session. The SRC continuously
records media in a recording session to the SRS even in the absence records media in a recording session to the SRS even in the absence
of a CS for all user agents that are part of persistent recording. of a CS for all user agents that are part of persistent recording.
By allocating recorded streams and continuously sending recorded By allocating recorded streams and continuously sending recorded
media to the SRS, the SRC does not have to prepare new recorded media to the SRS, the SRC does not have to prepare new recorded
skipping to change at page 39, line 14 skipping to change at page 40, line 12
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", draft-ietf-siprec- Protocol (SIP) Recording Metadata", draft-ietf-siprec-
metadata-12 (work in progress), May 2013. metadata-15 (work in progress), February 2014.
[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,
skipping to change at page 40, line 6 skipping to change at page 40, line 49
14.2. Informative References 14.2. Informative References
[I-D.ietf-avt-srtp-ekt] [I-D.ietf-avt-srtp-ekt]
Wing, D., McGrew, D., and K. Fischer, "Encrypted Key Wing, D., McGrew, D., and K. Fischer, "Encrypted Key
Transport for Secure RTP", draft-ietf-avt-srtp-ekt-03 Transport for Secure RTP", draft-ietf-avt-srtp-ekt-03
(work in progress), October 2011. (work in progress), October 2011.
[I-D.ietf-siprec-architecture] [I-D.ietf-siprec-architecture]
Hutton, A., Portman, L., Jain, R., and K. Rehor, "An Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
Architecture for Media Recording using the Session Architecture for Media Recording using the Session
Initiation Protocol", draft-ietf-siprec-architecture-08 Initiation Protocol", draft-ietf-siprec-architecture-11
(work in progress), May 2013. (work in progress), December 2013.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002. UPDATE Method", RFC 3311, October 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
 End of changes. 38 change blocks. 
256 lines changed or deleted 263 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/