draft-ietf-siprec-protocol-06.txt   draft-ietf-siprec-protocol-07.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: January 14, 2013 Genesys Expires: April 5, 2013 Genesys
C. Eckel C. Eckel
Cisco Cisco
A. Johnston A. Johnston
Avaya Avaya
A. Hutton A. Hutton
Siemens Enterprise Siemens Enterprise
Communications Communications
July 13, 2012 October 2, 2012
Session Recording Protocol Session Recording Protocol
draft-ietf-siprec-protocol-06 draft-ietf-siprec-protocol-07
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 45 skipping to change at page 1, line 45
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 January 14, 2013. This Internet-Draft will expire on April 5, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 5.3. Receiving recording indications and providing
recording preferences . . . . . . . . . . . . . . . . . . 8 recording preferences . . . . . . . . . . . . . . . . . . 8
6. Initiating a Recording Session . . . . . . . . . . . . . . . . 9 6. SIP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 10 6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 10
6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 10 6.1.1. Initiating a Recording Session . . . . . . . . . . . . 10
7. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1.2. SIP extensions for recording indication and
7.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 11 preference . . . . . . . . . . . . . . . . . . . . . . 10
7.1.1. Handling media stream updates . . . . . . . . . . . . 12 6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 11
7.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 13 6.3. Procedures for Recording-aware User Agents . . . . . . . . 11
8. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. RTP Mechanisms . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 12
8.1.1. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1.1. SDP handling in RS . . . . . . . . . . . . . . . . . . 12
8.1.2. RTP Profile . . . . . . . . . . . . . . . . . . . . . 16 7.1.1.1. Handling media stream updates . . . . . . . . . . 13
8.1.3. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1.2. Recording indication in CS . . . . . . . . . . . . . . 14
8.1.4. CSRC . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1.3. Recording preference in CS . . . . . . . . . . . . . . 15
8.1.5. SDES . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 15
8.1.5.1. CNAME . . . . . . . . . . . . . . . . . . . . . . 18 7.3. Procedures for Recording-aware User Agents . . . . . . . . 17
8.1.6. Keepalive . . . . . . . . . . . . . . . . . . . . . . 18 7.3.1. Recording indication . . . . . . . . . . . . . . . . . 17
8.1.7. RTCP Feedback Messages . . . . . . . . . . . . . . . . 18 7.3.2. Recording preference . . . . . . . . . . . . . . . . . 18
8.1.7.1. Full Intra Request . . . . . . . . . . . . . . . . 18 8. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1.7.2. Picture Loss Indicator . . . . . . . . . . . . . . 19 8.1. RTP Mechanisms . . . . . . . . . . . . . . . . . . . . . . 19
8.1.7.3. Temporary Maximum Media Stream Bit Rate Request . 19 8.1.1. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1.8. Symmetric RTP/RTCP for Sending and Receiving . . . . . 19 8.1.2. RTP Profile . . . . . . . . . . . . . . . . . . . . . 19
8.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1.3. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2.1. SRC acting as an RTP Translator . . . . . . . . . . . 21 8.1.4. CSRC . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2.1.1. Forwarding Translator . . . . . . . . . . . . . . 21 8.1.5. SDES . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2.1.2. Transcoding Translator . . . . . . . . . . . . . . 22 8.1.5.1. CNAME . . . . . . . . . . . . . . . . . . . . . . 21
8.2.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . . 23 8.1.6. Keepalive . . . . . . . . . . . . . . . . . . . . . . 21
8.2.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 23 8.1.7. RTCP Feedback Messages . . . . . . . . . . . . . . . . 21
8.3. RTP Session Usage by SRC . . . . . . . . . . . . . . . . . 23 8.1.7.1. Full Intra Request . . . . . . . . . . . . . . . . 22
8.3.1. SRC Using Multiple m-lines . . . . . . . . . . . . . . 24 8.1.7.2. Picture Loss Indicator . . . . . . . . . . . . . . 22
8.3.2. SRC Using SSRC Multiplexing . . . . . . . . . . . . . 25 8.1.7.3. Temporary Maximum Media Stream Bit Rate Request . 22
8.3.3. SRC Using Mixing . . . . . . . . . . . . . . . . . . . 26 8.1.8. Symmetric RTP/RTCP for Sending and Receiving . . . . . 23
9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 27 8.2.1. SRC acting as an RTP Translator . . . . . . . . . . . 24
9.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 29 8.2.1.1. Forwarding Translator . . . . . . . . . . . . . . 25
9.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 30 8.2.1.2. Transcoding Translator . . . . . . . . . . . . . . 25
10. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 30 8.2.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . . 26
11. Extensions for Recording-aware User Agents . . . . . . . . . . 31 8.2.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 26
11.1. Procedures at the record-aware user agent . . . . . . . . 31 8.3. RTP Session Usage by SRC . . . . . . . . . . . . . . . . . 27
11.1.1. Recording preference . . . . . . . . . . . . . . . . . 31 8.3.1. SRC Using Multiple m-lines . . . . . . . . . . . . . . 27
11.2. Procedures at the SRC . . . . . . . . . . . . . . . . . . 32 8.3.2. SRC Using SSRC Multiplexing . . . . . . . . . . . . . 28
11.2.1. Recording indication . . . . . . . . . . . . . . . . . 32 8.3.3. SRC Using Mixing . . . . . . . . . . . . . . . . . . . 29
11.2.2. Recording preference . . . . . . . . . . . . . . . . . 33 9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 30
12.1. Registration of Option Tags . . . . . . . . . . . . . . . 34 9.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 32
12.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 34 9.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 34
12.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 34 10. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 34
12.2. Registration of media feature tags . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 34 11.1. Registration of Option Tags . . . . . . . . . . . . . . . 34
12.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 35 11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 35
12.3. New Content-Disposition Parameter Registrations . . . . . 35 11.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 35
12.4. Media Type Registration . . . . . . . . . . . . . . . . . 35 11.2. Registration of media feature tags . . . . . . . . . . . . 35
12.4.1. Registration of MIME Type application/rs-metadata . . 35 11.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 35
12.4.2. Registration of MIME Type 11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 36
application/rs-metadata-request . . . . . . . . . . . 36 11.3. New Content-Disposition Parameter Registrations . . . . . 36
12.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 36 11.4. Media Type Registration . . . . . . . . . . . . . . . . . 36
12.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 36 11.4.1. Registration of MIME Type application/rs-metadata . . 36
12.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 36 11.4.2. Registration of MIME Type
13. Security Considerations . . . . . . . . . . . . . . . . . . . 37 application/rs-metadata-request . . . . . . . . . . . 37
13.1. RTP handling . . . . . . . . . . . . . . . . . . . . . . . 37 11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 37
13.2. Authentication and Authorization . . . . . . . . . . . . . 37 11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 37
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 37
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 12. Security Considerations . . . . . . . . . . . . . . . . . . . 38
15.1. Normative References . . . . . . . . . . . . . . . . . . . 38 12.1. Authentication and Authorization . . . . . . . . . . . . . 38
15.2. Informative References . . . . . . . . . . . . . . . . . . 38 12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.4. Storage and playback . . . . . . . . . . . . . . . . . . . 40
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.1. Normative References . . . . . . . . . . . . . . . . . . . 40
14.2. Informative References . . . . . . . . . . . . . . . . . . 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
skipping to change at page 9, line 45 skipping to change at page 9, line 45
|<----------------------------------------------------| |<----------------------------------------------------|
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. Initiating a Recording Session 6. SIP Handling
6.1. Procedures at the SRC
A recording session is a SIP session with specific extensions 6.1.1. Initiating a Recording Session
applied, and these extensions are listed in the procedures below.
When an SRC or an SRS receives a SIP session that is not a recording
session, it is up to the SRC or the SRS to determine what to do with
the SIP session.
6.1. Procedures at the SRC A recording session is a SIP session with specific extensions
applied, and these extensions are listed in the procedures for SRC
and SRS below. When an SRC or an SRS receives a SIP session that is
not a recording session, it is up to the SRC or the SRS to determine
what to do with the SIP session.
The SRC can initiate a recording session by sending a SIP INVITE The SRC can initiate a recording session by sending a SIP INVITE
request to the SRS. The SRC and the SRS are identified in the From request to the SRS. The SRC and the SRS are identified in the From
and To headers, respectively. and To headers, respectively.
The SRC MUST include the '+sip.src' feature tag in the Contact URI, The SRC MUST include the '+sip.src' feature tag in the Contact URI,
defined in this specification as an extension to [RFC3840], for all defined in this specification as an extension to [RFC3840], for all
recording sessions. An SRS uses the presence of the '+sip.src' recording sessions. An SRS uses the presence of the '+sip.src'
feature tag in dialog creating and modifying requests and responses feature tag in dialog creating and modifying requests and responses
to confirm that the dialog being created is for the purpose of a to confirm that the dialog being created is for the purpose of a
skipping to change at page 10, line 36 skipping to change at page 10, line 41
option tag in a recording session. An SRC MUST include the "siprec" option tag in a recording session. An SRC MUST include the "siprec"
option tag in the Require header when initiating a Recording Session option tag in the Require header when initiating a Recording Session
so that UA's which do not support the session recording protocol so that UA's which do not support the session recording protocol
extensions will simply reject the INVITE request with a 420 Bad extensions will simply reject the INVITE request with a 420 Bad
Extension. Extension.
When an SRC receives a new INVITE, the SRC MUST only consider the SIP When an SRC receives a new INVITE, the SRC MUST only consider the SIP
session as a recording session when both the '+sip.srs' feature tag session as a recording session when both the '+sip.srs' feature tag
and 'siprec' option tag are included in the INVITE request. and 'siprec' option tag are included in the INVITE request.
6.1.2. SIP extensions for recording indication and preference
For the communication session, the SRC MUST provide recording
indication to all participants in the CS. A participant UA in a CS
can indicate that it is recording-aware by providing the "record-
aware" option tag, and the SRC MUST provide recording indications in
the new SDP a=record attribute described in the SDP Handling section.
In the absence of the "record-aware" option tag, meaning that the
participant UA is not recording-aware, an SRC MUST provide recording
indications through other means such as playing a tone inband, if the
SRC is required to do so (e.g. based on policies).
An SRC in the CS may also indicate itself as a session recording
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
recording preference for the CS with the new SDP a=recordpref
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.
skipping to change at page 11, line 11 skipping to change at page 11, line 34
requests and responses to confirm that the dialog being created is requests and responses to confirm that the dialog being created is
for the purpose of a Recording Session (REQ-30). In addition, when for the purpose of a Recording Session (REQ-30). In addition, when
an SRS sends a REGISTER request to a registrar, the SRS MUST include an SRS sends a REGISTER request to a registrar, the SRS MUST include
the '+sip.srs' feature tag to indicate that it is a SRS. the '+sip.srs' feature tag to indicate that it is a SRS.
An SRS MUST include the "siprec" option tag in the Require header as An SRS MUST include the "siprec" option tag in the Require header as
per [RFC3261] when initiating a Recording Session so that UA's which per [RFC3261] when initiating a Recording Session so that UA's which
do not support the session recording protocol extensions will simply do not support the session recording protocol extensions will simply
reject the INVITE request with a 420 Bad Extension. reject the INVITE request with a 420 Bad Extension.
6.3. Procedures for Recording-aware User Agents
A recording-aware user agent is a participant in the CS that supports
the SIP and SDP extensions for receiving recording indication and for
requesting recording preferences for the call. A recording-aware UA
MUST indicate that it can accept reporting of recording indication
provided by the SRC with a new option tag "record-aware" when
initiating or establishing a CS, meaning including the "record-aware"
tag in the Supported header in the initial INVITE request or
response.
A recording-aware UA MUST be prepared to provide recording indication
to the end user through an appropriate user interface an indication
whether recording is on, off, or paused for each medium. Some user
agents that are automatons (e.g. IVR, media server, PSTN gateway)
may not have a user interface to render recording indication. When
such user agent indicates recording awareness, the UA SHOULD render
recording indication through other means, such as passing an inband
tone on the PSTN gateway, putting the recording indication in a log
file, or raising an application event in a VoiceXML dialog. These
user agents MAY also choose not to indicate recording awareness,
thereby relying on whatever mechanism an SRC chooses to indicate
recording, such as playing a tone inband.
7. SDP Handling 7. SDP Handling
7.1. Procedures at the SRC
The SRC and SRS follows the SDP offer/answer model in [RFC3264]. The The SRC and SRS follows the SDP offer/answer model in [RFC3264]. The
rest of this section describes conventions used in a recording procedures for SRC and SRS describe the conventions used in a
session. recording session.
7.1. Procedures at the SRC 7.1.1. SDP handling in RS
Since the SRC does not expect to receive media from the SRS, the SRC Since the SRC does not expect to receive media from the SRS, the SRC
typically sets each media stream of the SDP offer to only send media, typically sets each media stream of the SDP offer to only send media,
by qualifying them with the a=sendonly attribute, according to the by qualifying them with the a=sendonly attribute, according to the
procedures in [RFC3264]. procedures in [RFC3264].
The SRC sends recorded streams of participants to the SRS, and the The SRC sends recorded streams of participants to the SRS, and the
SRC MUST provide a label attribute (a=label), as per [RFC4574], on SRC MUST provide a label attribute (a=label), as per [RFC4574], on
each media stream in order to identify the recorded stream with the each media stream in order to identify the recorded stream with the
rest of the metadata. The a=label attribute identifies each recorded rest of the metadata. The a=label attribute identifies each recorded
media stream, and the label name is mapped to the Media Stream media stream, and the label name is mapped to the Media Stream
Reference in the metadata as per [I-D.ietf-siprec-metadata]. The Reference in the metadata as per [I-D.ietf-siprec-metadata]. The
scope of the label name only applies to the same SIP message as the scope of the a=label attribute only applies to the SDP and Metadata
SDP, meaning that the label name can be reused by another media conveyed in the bodies of the SIP request or response that the label
stream within the same recording session. Note that a recorded appeared in. Note that a recorded stream is distinct from a CS
stream is distinct from a CS stream; the metadata provides a list of stream; the metadata provides a list of participants that contributes
participants that contributes to each recorded stream. to each recorded stream.
The following is an example of SDP offer from SRC with both audio and The following is an example of SDP offer from SRC with both audio and
video recorded streams. Note that the following example contain video recorded streams. Note that the following example contain
unfolded lines longer than 72 characters. These are captured between unfolded lines longer than 72 characters. These are captured between
<allOneLine> tags. <allOneLine> tags.
v=0 v=0
o=SRC 2890844526 2890844526 IN IP4 198.51.100.1 o=SRC 2890844526 2890844526 IN IP4 198.51.100.1
s=- s=-
c=IN IP4 198.51.100.1 c=IN IP4 198.51.100.1
skipping to change at page 12, line 35 skipping to change at page 13, line 35
a=rtpmap:98 H264/90000 a=rtpmap:98 H264/90000
<allOneLine> <allOneLine>
a=fmtp:98 profile-level-id=42A01E; a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine> </allOneLine>
a=sendonly a=sendonly
a=label:4 a=label:4
Figure 4: Sample SDP offer from SRC with audio and video streams Figure 4: Sample SDP offer from SRC with audio and video streams
7.1.1. Handling media stream updates 7.1.1.1. Handling media stream updates
Over the lifetime of a recording session, the SRC can add and remove Over the lifetime of a recording session, the SRC can add and remove
recorded streams from the recording session for various reasons. For recorded streams from the recording session for various reasons. For
example, when a CS stream is added or removed from the CS, or when a example, when a CS stream is added or removed from the CS, or when a
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
skipping to change at page 13, line 14 skipping to change at page 14, line 14
recording. In this case, the SRC sends a new SDP offer and sets the recording. In this case, the SRC sends a new SDP offer and sets the
media stream to inactive (a=inactive) for each recorded stream to be media stream to inactive (a=inactive) for each recorded stream to be
paused, as per the procedures in [RFC3264]. To resume streaming and paused, as per the procedures in [RFC3264]. To resume streaming and
collection of recorded media, the SRC sends a new SDP offer and sets collection of recorded media, the SRC sends a new SDP offer and sets
the media streams with a=sendonly attribute. Note that when a CS the media streams with a=sendonly attribute. Note that when a CS
stream is muted/unmuted, this information is conveyed in the metadata stream is muted/unmuted, this information is conveyed in the metadata
by the SRC. The SRC SHOULD NOT modify the media stream with by the SRC. The SRC SHOULD NOT modify the media stream with
a=inactive for mute since this operation is reserved for pausing the a=inactive for mute since this operation is reserved for pausing the
RS media. RS media.
7.1.2. Recording indication in CS
While there are existing mechanisms for providing an indication that
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
to the participants. A new 'record' SDP attribute is introduced to
allow the SRC to indicate recording state to a recording-aware UA in
CS.
The 'record' SDP attribute appears at the media level or session
level in either SDP offer or answer. When the attribute is applied
at the session level, the indication applies to all media streams in
the SDP. When the attribute is applied at the media level, the
indication applies to the media stream only, and that overrides the
indication if also set at the session level. Whenever the recording
indication needs to change, such as termination of recording, then
the SRC MUST initiate a reINVITE or UPDATE to update the SDP a=record
attribute.
The following is the ABNF of the 'record' attribute:
attribute /= record-attr
; attribute defined in RFC 4566
record-attr = "record:" indication
indication = "on" / "off" / "paused"
on Recording is in progress.
off No recording is in progress.
paused Recording is in progress by media is paused.
7.1.3. Recording preference in CS
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
policy at the SRC. Whether or not the SRC honors the recording
preference, the SRC MUST update the a=record attribute to indicate
the current state of the recording (on/off/paused).
7.2. Procedures at the SRS 7.2. Procedures at the SRS
The SRS only receives RTP streams from the SRC, the SDP answer The SRS only receives RTP streams from the SRC, the SDP answer
normally sets each media stream to receive media, by setting them normally sets each media stream to receive media, by setting them
with the a=recvonly attribute, according to the procedures of with the a=recvonly attribute, according to the procedures of
[RFC3264]. When the SRS is not ready to receive a recorded stream, [RFC3264]. When the SRS is not ready to receive a recorded stream,
the SRS sets the media stream as inactive in the SDP offer or answer the SRS sets the media stream as inactive in the SDP offer or answer
by setting it with a=inactive attribute, according to the procedures by setting it with a=inactive attribute, according to the procedures
of [RFC3264]. When the SRS is ready to receive recorded streams, the of [RFC3264]. When the SRS is ready to receive recorded streams, the
SRS sends a new SDP offer and sets the media streams with a=recvonly SRS sends a new SDP offer and sets the media streams with a=recvonly
skipping to change at page 15, line 32 skipping to change at page 17, line 32
|(7) RTP | |(7) RTP |
|====================================================>| |====================================================>|
| ... | | ... |
|(8) BYE | |(8) BYE |
|---------------------------------------------------->| |---------------------------------------------------->|
| (9) OK | | (9) OK |
|<----------------------------------------------------| |<----------------------------------------------------|
Figure 6: SRS responding to offer with a=inactive Figure 6: SRS responding to offer with a=inactive
7.3. Procedures for Recording-aware User Agents
7.3.1. Recording indication
When a recording-aware UA receives an SDP offer or answer that
includes the a=record attribute, the UA MUST provide the recording
indication to the end user whether the recording is on, off, or
paused for each medium based on the most recently received a=record
SDP attribute for that medium.
If a call is traversed through one or more SIP B2BUA, and it happens
that there are more than one SRC in the call path, the recording
indication attribute does not provide any hint as to which SRC is
performing the recording, meaning the endpoint only knows that the
call is being recorded. This attribute is 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
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
session. A new 'recordpref' SDP attribute is introduced, and the
participant in CS may set this recording preference atrribute in any
SDP offer/answer at session establishment time or during the session.
The SRC is not required to honor the recording preference from a
participant based on local policies at the SRC, and the participant
can learn the recording indication through the a=record SDP attribute
as described in the above section.
The SDP a=recordpref attribute can appear at the media level or
session level and can appear in an SDP offer or answer. When the
attribute is applied at the session level, the recording preference
applies to all media stream in the SDP. When the attribute is
applied at the media level, the recording preference applies to the
media stream only, and that overrides the recording preference if
also set at the session level. The user agent can change the
recording preference by changing the a=recordpref attribute in
subsequent SDP offer or answer. The absence of the a=recordpref
attribute in the SDP indicates that the UA has no recording
preference.
The following is the ABNF of the recordpref attribute:
attribute /= recordpref-attr
; attribute defined in RFC 4566
recordpref-attr = "a=recordpref:" pref
pref = "on" / "off" / "pause" / "nopreference"
on Sets the preference to record if it has not already been started.
If the recording is currently paused, the preference is to resume
recording.
off Sets the preference for no recording. If recording has already
been started, then the preference is to stop the recording.
pause If the recording is currently in progress, sets the preference
to pause the recording.
nopreference To indicate that the UA has no preference on recording.
8. RTP Handling 8. RTP Handling
This section provides recommendations and guidelines for RTP and RTCP This section provides recommendations and guidelines for RTP and RTCP
in the context of SIPREC. In order to communicate most effectively, in the context of SIPREC. In order to communicate most effectively,
the Session Recording Client (SRC), the Session Recording Server the Session Recording Client (SRC), the Session Recording Server
(SRS), and any Recording aware User Agents (UAs) SHOULD utilize the (SRS), and any Recording aware User Agents (UAs) SHOULD utilize the
mechanisms provided by RTP in a well-defined and predicable manner. mechanisms provided by RTP in a well-defined and predicable manner.
It is the goal of this document to make the reader aware of these It is the goal of this document to make the reader aware of these
mechanisms and provide recommendations and guidelines. mechanisms and provide recommendations and guidelines.
skipping to change at page 22, line 10 skipping to change at page 25, line 27
UAs may receive multiple sets of RTCP Receiver Reports, one or more UAs may receive multiple sets of RTCP Receiver Reports, one or more
from other UAs participating in the CS, and one from the SRS from other UAs participating in the CS, and one from the SRS
participating in the RS. A Recording aware UA SHOULD be prepared to participating in the RS. A Recording aware UA SHOULD be prepared to
process the RTCP Receiver Reports from the SRS, whereas a recording process the RTCP Receiver Reports from the SRS, whereas a recording
unaware UA may discard such RTCP packets as not of relevance. unaware UA may discard such RTCP packets as not of relevance.
If SRTP is used on both the CS and the RS, decryption and/or re- If SRTP is used on both the CS and the RS, decryption and/or re-
encryption may occur. For example, if different keys are used, it encryption may occur. For example, if different keys are used, it
will occur. If the same keys are used, it need not occur. will occur. If the same keys are used, it need not occur.
Section 13 provides additional information on SRTP and keying Section 12 provides additional information on SRTP and keying
mechanisms. mechanisms.
If packet loss occurs, either from the UA to the SRC or from the SRC If packet loss occurs, either from the UA to the SRC or from the SRC
to the SRS, the SRS SHOULD detect and attempt to recover from the to the SRS, the SRS SHOULD detect and attempt to recover from the
loss. The SRC does not play a role in this other than forwarding the loss. The SRC does not play a role in this other than forwarding the
associated RTP and RTCP packets. associated RTP and RTCP packets.
8.2.1.2. Transcoding Translator 8.2.1.2. Transcoding Translator
When acting as a transcoding translator, an SRC MAY perform When acting as a transcoding translator, an SRC MAY perform
skipping to change at page 22, line 45 skipping to change at page 26, line 14
UAs may receive multiple sets of RTCP Receiver Reports, one or more UAs may receive multiple sets of RTCP Receiver Reports, one or more
from other UAs participating in the CS, and one from the SRS from other UAs participating in the CS, and one from the SRS
participating in the RS. A Recording aware UA SHOULD be prepared to participating in the RS. A Recording aware UA SHOULD be prepared to
process the RTCP Receiver Reports from the SRS, whereas a recording process the RTCP Receiver Reports from the SRS, whereas a recording
unaware UA may discard such RTCP packets as not of relevance. unaware UA may discard such RTCP packets as not of relevance.
If SRTP is used on both the CS and the RS, decryption and/or re- If SRTP is used on both the CS and the RS, decryption and/or re-
encryption may occur. For example, if different keys are used, it encryption may occur. For example, if different keys are used, it
will occur. If the same keys are used, it need not occur. will occur. If the same keys are used, it need not occur.
Section 13 provides additional information on SRTP and keying Section 12 provides additional information on SRTP and keying
mechanisms. mechanisms.
If packet loss occurs, either from the UA to the SRC or from the SRC If packet loss occurs, either from the UA to the SRC or from the SRC
to the SRS, the SRS SHOULD detect and attempt to recover from the to the SRS, the SRS SHOULD detect and attempt to recover from the
loss. The SRC does not play a role in this other than forwarding the loss. The SRC does not play a role in this other than forwarding the
associated RTP and RTCP packets. associated RTP and RTCP packets.
8.2.2. SRC acting as an RTP Mixer 8.2.2. SRC acting as an RTP Mixer
In the case of the SRC acting as a RTP mixer, as defined in In the case of the SRC acting as a RTP mixer, as defined in
skipping to change at page 23, line 21 skipping to change at page 26, line 38
stream. The SRC may make timing adjustments among the received stream. The SRC may make timing adjustments among the received
streams and generate its own timing on the stream sent to the SRS. streams and generate its own timing on the stream sent to the SRS.
Optionally an SRC acting as a mixer can perform transcoding, and can Optionally an SRC acting as a mixer can perform transcoding, and can
even cope with different codings received from different UAs. RTCP even cope with different codings received from different UAs. RTCP
Sender Reports and Receiver Reports are not forwarded by an SRC Sender Reports and Receiver Reports are not forwarded by an SRC
acting as mixer, but there are requirements for forwarding RTCP acting as mixer, but there are requirements for forwarding RTCP
Source Description (SDES) packets. The SRC generates its own RTCP Source Description (SDES) packets. The SRC generates its own RTCP
Sender and Receiver reports toward the associated UAs and SRS. Sender and Receiver reports toward the associated UAs and SRS.
The use of SRTP between the SRC and the SRS for the RS is independent The use of SRTP between the SRC and the SRS for the RS is independent
of the use of SRTP between the UAs and SRC for the CS. Section 13 of the use of SRTP between the UAs and SRC for the CS. Section 12
provides additional information on SRTP and keying mechanisms. provides additional information on SRTP and keying mechanisms.
If packet loss occurs from the UA to the SRC, the SRC SHOULD detect If packet loss occurs from the UA to the SRC, the SRC SHOULD detect
and attempt to recover from the loss. If packet loss occurs from the and attempt to recover from the loss. If packet loss occurs from the
SRC to the SRS, the SRS SHOULD detect and attempt to recover from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the
loss. loss.
8.2.3. SRC acting as an RTP Endpoint 8.2.3. SRC acting as an RTP Endpoint
The case of the SRC acting as an RTP endpoint, as defined in The case of the SRC acting as an RTP endpoint, as defined in
[RFC3550], is similar to the mixer case, except that the RTP session [RFC3550], is similar to the mixer case, except that the RTP session
between the SRC and the SRS is considered completely independent from between the SRC and the SRS is considered completely independent from
the RTP session that is part of the CS. The SRC can, but need not, the RTP session that is part of the CS. The SRC can, but need not,
mix RTP streams from different participants prior to sending to the mix RTP streams from different participants prior to sending to the
SRS. RTCP between the SRC and the SRS is completely independent of SRS. RTCP between the SRC and the SRS is completely independent of
RTCP on the CS. RTCP on the CS.
The use of SRTP between the SRC and the SRS for the RS is independent The use of SRTP between the SRC and the SRS for the RS is independent
of the use of SRTP between the UAs and SRC for the CS. Section 13 of the use of SRTP between the UAs and SRC for the CS. Section 12
provides additional information on SRTP and keying mechanisms. provides additional information on SRTP and keying mechanisms.
If packet loss occurs from the UA to the SRC, the SRC SHOULD detect If packet loss occurs from the UA to the SRC, the SRC SHOULD detect
and attempt to recover from the loss. If packet loss occurs from the and attempt to recover from the loss. If packet loss occurs from the
SRC to the SRS, the SRS SHOULD detect and attempt to recover from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the
loss. loss.
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
skipping to change at page 31, line 5 skipping to change at page 34, line 40
persistent recording, there is no recorded media to stream from the persistent recording, there is no recorded media to stream from the
SRC to the SRS. In certain environments where Network Address SRC to the SRS. In certain environments where Network Address
Translator (NAT) is used, typically a minimum of flow activity is Translator (NAT) is used, typically a minimum of flow activity is
required to maintain the NAT binding for each port opened. Agents required to maintain the NAT binding for each port opened. Agents
that support Interactive Connectivity Establishment (ICE) solves this that support Interactive Connectivity Establishment (ICE) solves this
problem. For non-ICE agents, in order not to lose the NAT bindings problem. For non-ICE agents, in order not to lose the NAT bindings
for the RTP/RTCP ports opened for the recorded streams, the SRC and for the RTP/RTCP ports opened for the recorded streams, the SRC and
SRS SHOULD follow the recommendations provided in [RFC6263] to SRS SHOULD follow the recommendations provided in [RFC6263] to
maintain the NAT bindings. maintain the NAT bindings.
11. Extensions for Recording-aware User Agents 11. IANA Considerations
The following sections describe the SIP and SDP extensions for
recording-aware user agents. A recording-aware user agent is a
participant in the CS that supports the SIP and SDP extensions for
receiving recording indication and for requesting recording
preferences for the call.
11.1. Procedures at the record-aware user agent
A recording-aware UA MUST indicate that it can accept reporting of
recording indication provided by the SRC with a new option tag
"record-aware" when initiating or establishing a CS, meaning
including the "record-aware" tag in the Supported header in the
initial INVITE request or response. A recording-aware UA that has
indicated recording awareness MUST provide at recording indication to
the end user through an appropriate user interface an indication
whether recording is on or off for a given medium based on the most
recently received a=record SDP attribute for that medium.
Some user agents that are automatons (e.g. IVR, media server, PSTN
gateway) may not have a user interface to render recording
indication. When such user agent indicates recording awareness, the
UA SHOULD render recording indication through other means, such as
passing an inband tone on the PSTN gateway, putting the recording
indication in a log file, or raising an application event in a
VoiceXML dialog. These user agents MAY also choose not to indicate
recording awareness, thereby relying on whatever mechanism an SRC
chooses to indicate recording, such as playing a tone inband.
11.1.1. Recording preference
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
session. The recording-aware UA sets the indication of recording
preference in a new SDP attribute a=recordpref in the CS in any SDP
offer/answer. This indication of recording preference can be sent at
session establishment time or during the session. The SRC is not
required to honor the recording preference from a participant based
on local policies at the SRC; the participant gets the recording
indication through the a=record SDP attribute described in the next
section.
The SDP a=recordpref attribute can appear at the media level or
session level and can appear in an SDP offer or answer. When the
attribute is applied at the session level, the recording preference
applies to all media stream in the SDP. When the attribute is
applied at the media level, the recording preference applies to the
media stream only, and that overrides the recording preference if
also set at the session level. The user agent can change the
recording preference by changing the a=recordpref attribute in
subsequent SDP offer or answer. If the a=recordpref attribute is
omitted, then the recording preference would be assumed to be the
recording preference set in a previous SDP offer or answer.
The following is the ABNF of the recordpref attribute:
attribute /= recordpref-attr
; attribute defined in RFC 4566
recordpref-attr = "a=recordpref:" pref
pref = "on" / "off" / "pause" / "nopreference"
on Sets the preference to record if it has not already been started.
If the recording is currently paused, the preference is to resume
recording.
off Sets the preference for no recording. If recording has already
been started, then the preference is to stop the recording.
pause If the recording is currently in progress, sets the preference
to pause the recording.
nopreference To indicate that the UA has no preference on recording.
11.2. Procedures at the SRC
The SRC MUST provide recording indication to all participants in the
CS. When a UA has indicated that it is recording-aware through the
"record-aware" option tag, the SRC MUST provide recording indications
in the new SDP a=record attribute described in the following section.
In the absence of the "record-aware" option tag, meaning that the UA
is not recording-aware, an SRC MUST provide recording indications
through other means such as playing a tone inband, if the SRC is
required to do so (e.g. based on policies).
11.2.1. Recording indication
While there are existing mechanisms for providing an indication that
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
to the participants. A new SDP attribute is introduced to allow a
recording-aware UA to render recording indication at the user
interface.
The 'record' SDP attribute appears at the media level or session
level in either SDP offer or answer. When the attribute is applied
at the session level, the indication applies to all media streams in
the SDP. When the attribute is applied at the media level, the
indication applies to the media stream only, and that overrides the
indication if also set at the session level. Whenever the recording
indication needs to change, such as termination of recording, then
the SRC MUST initiate a reINVITE or UPDATE to update the SDP a=record
attribute.
The following is the ABNF of the 'record' attribute:
attribute /= record-attr
; attribute defined in RFC 4566
record-attr = "record:" indication
indication = "on" / "off" / "paused"
on Recording is in progress.
off No recording is in progress.
paused Recording is in progress by media is paused.
If a call is traversed through one or more SIP B2BUA, and it happens
that there are more than one SRC in the call path, the recording
indication attribute does not provide any hint as to which SRC is
performing the recording, meaning the endpoint only knows that the
call is being recorded. This attribute is 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.
11.2.2. Recording preference
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
policy at the SRC. When the SRC honors the preference, the SRC MUST
also update the a=record attribute to indicate the current state of
the recording (on/off/paused).
12. IANA Considerations 11.1. Registration of Option Tags
12.1. Registration of Option Tags
This specification registers two option tags. The required This specification registers two option tags. The required
information for this registration, as specified in [RFC3261], is as information for this registration, as specified in [RFC3261], is as
follows. follows.
12.1.1. siprec Option Tag 11.1.1. siprec Option Tag
Name: siprec Name: siprec
Description: This option tag is for identifying the SIP session Description: This option tag is for identifying the SIP session
for the purpose of recording session only. This is typically not for the purpose of recording session only. This is typically not
used in a Supported header. When present in a Require header in a used in a Supported header. When present in a Require header in a
request, it indicates that the UAS MUST be either a SRC or SRS request, it indicates that the UAS MUST be either a SRC or SRS
capable of handling the contexts of a recording session. capable of handling the contexts of a recording session.
12.1.2. record-aware Option Tag 11.1.2. record-aware Option Tag
Name: record-aware Name: record-aware
Description: This option tag is to indicate the ability for the Description: This option tag is to indicate the ability for the
user agent to receive recording indicators in media level or user agent to receive recording indicators in media level or
session level SDP. When present in a Supported header, it session level SDP. When present in a Supported header, it
indicates that the UA can receive recording indicators in media indicates that the UA can receive recording indicators in media
level or session level SDP. level or session level SDP.
12.2. Registration of media feature tags 11.2. Registration of media feature tags
This document registers two new media feature tags in the SIP tree This document registers two new media feature tags in the SIP tree
per the process defined in [RFC2506] and [RFC3840] per the process defined in [RFC2506] and [RFC3840]
12.2.1. src feature tag 11.2.1. src feature tag
Media feature tag name: sip.src Media feature tag name: sip.src
ASN.1 Identifier: 25 ASN.1 Identifier: 25
Summary of the media feature indicated by this tag: This feature Summary of the media feature indicated by this tag: This feature
tag indicates that the user agent is a Session Recording Client tag indicates that the user agent is a Session Recording Client
for the purpose for Recording Session. for the purpose for Recording Session.
Values appropriate for use with this feature tag: boolean Values appropriate for use with this feature tag: boolean
skipping to change at page 35, line 11 skipping to change at page 36, line 5
The feature tag is intended primarily for use in the following The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This applications, protocols, services, or negotiation mechanisms: This
feature tag is only useful for a Recording Session. feature tag is only useful for a Recording Session.
Examples of typical use: Routing the request to a Session Examples of typical use: Routing the request to a Session
Recording Server. Recording Server.
Security Considerations: Security considerations for this media Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840. feature tag are discussed in Section 11.1 of RFC 3840.
12.2.2. srs feature tag 11.2.2. srs feature tag
Media feature tag name: sip.srs Media feature tag name: sip.srs
ASN.1 Identifier: 26 ASN.1 Identifier: 26
Summary of the media feature indicated by this tag: This feature Summary of the media feature indicated by this tag: This feature
tag indicates that the user agent is a Session Recording Server tag indicates that the user agent is a Session Recording Server
for the purpose for Recording Session. for the purpose for Recording Session.
Values appropriate for use with this feature tag: boolean Values appropriate for use with this feature tag: boolean
skipping to change at page 35, line 33 skipping to change at page 36, line 27
The feature tag is intended primarily for use in the following The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This applications, protocols, services, or negotiation mechanisms: This
feature tag is only useful for a Recording Session. feature tag is only useful for a Recording Session.
Examples of typical use: Routing the request to a Session Examples of typical use: Routing the request to a Session
Recording Client. Recording Client.
Security Considerations: Security considerations for this media Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC 3840. feature tag are discussed in Section 11.1 of RFC 3840.
12.3. New Content-Disposition Parameter Registrations 11.3. New Content-Disposition Parameter Registrations
This document registers a new "disposition-type" value in Content- This document registers a new "disposition-type" value in Content-
Disposition header: recording-session. Disposition header: recording-session.
recording-session the body describes the metadata information about recording-session the body describes the metadata information about
the recording session the recording session
12.4. Media Type Registration 11.4. Media Type Registration
12.4.1. Registration of MIME Type application/rs-metadata 11.4.1. Registration of MIME Type application/rs-metadata
This document registers the application/rs-metadata MIME media type This document registers the application/rs-metadata MIME media type
in order to describe the recording session metadata. This media type in order to describe the recording session metadata. This media type
is defined by the following information: is defined by the following information:
Media type name: application Media type name: application
Media subtype name: rs-metadata Media subtype name: rs-metadata
Required parameters: none Required parameters: none
Options parameters: none Options parameters: none
12.4.2. Registration of MIME Type application/rs-metadata-request 11.4.2. Registration of MIME Type application/rs-metadata-request
This document registers the application/rs-metadata-request MIME This document registers the application/rs-metadata-request MIME
media type in order to describe a recording session metadata snapshot media type in order to describe a recording session metadata snapshot
request. This media type is defined by the following information: request. This media type is defined by the following information:
Media type name: application Media type name: application
Media subtype name: rs-metadata-request Media subtype name: rs-metadata-request
Required parameters: none Required parameters: none
Options parameters: none Options parameters: none
12.5. SDP Attributes 11.5. SDP Attributes
This document registers the following new SDP attributes. This document registers the following new SDP attributes.
12.5.1. 'record' SDP Attribute 11.5.1. 'record' SDP Attribute
Contact names: Leon Portman leon.portman@nice.com, Henry Lum Contact names: Leon Portman leon.portman@nice.com, Henry Lum
henry.lum@genesyslab.com henry.lum@genesyslab.com
Attribute name: record Attribute name: record
Long form attribute name: Recording Indication Long form attribute name: Recording Indication
Type of attribute: session or media level Type of attribute: session or media level
Subject to charset: no Subject to charset: no
This attribute provides the recording indication for the session or This attribute provides the recording indication for the session or
media stream. media stream.
Allowed attribute values: on, off, paused Allowed attribute values: on, off, paused
12.5.2. 'recordpref' SDP Attribute 11.5.2. 'recordpref' SDP Attribute
Contact names: Leon Portman leon.portman@nice.com, Henry Lum Contact names: Leon Portman leon.portman@nice.com, Henry Lum
henry.lum@genesyslab.com henry.lum@genesyslab.com
Attribute name: recordpref Attribute name: recordpref
Long form attribute name: Recording Preference Long form attribute name: Recording Preference
Type of attribute: session or media level Type of attribute: session or media level
Subject to charset: no Subject to charset: no
This attribute provides the recording preference for the session or This attribute provides the recording preference for the session or
media stream. media stream.
Allowed attribute values: on, off, pause, nopreference Allowed attribute values: on, off, pause, nopreference
13. Security Considerations 12. Security Considerations
The recording session is fundamentally a standard SIP dialog The recording session is fundamentally a standard SIP dialog
[RFC3261], therefore, the recording session can reuse any of the [RFC3261], therefore, the recording session can reuse any of the
existing SIP security mechanism available for securing the recorded existing SIP security mechanism available for securing, session
media as well as metadata. Other security considerations are signaling, the recorded media as well as metadata. The use cases and
outlined in the use cases and requirements document [RFC6341]. requirements document [RFC6341] outlines the general security
considerations, and the following describe specific security
13.1. RTP handling recommendations.
In many scenarios it will be critical that the media transported The SRC and SRS MUST support SIPS and TLS as per [RFC5630]. The
between the SRC and SRS to be protected. Media encryption is an Recording Session SHOULD be at least as secure as the Communication
important element in the overall SIPREC solution, therefore, it is Session, meaning using at least the same strength of cipher suite as
RECOMMENDED that SRC and SRS support RTP/SAVP [RFC3711] and RTP/SAVPF the CS if the CS is secured. For example, if the CS uses SIPS for
[RFC5124]. RTP/SAVP and RTP/SAVPF provide media encryption, signalling and RTP/SAVP for media, then the RS does not downgrade the
integrity protection, replay protection, and a limited form of source level of security in the RS to SIP or plain RTP since doing so will
authentication. They do not contain or require a specific keying mean an automatic security downgrade for the CS. In deployments
mechanism. where the SRC and the SRS are in the same administrative domain and
the same physical switch that prevents outside user access, some SRC
may choose lower the level of security when establishing the
recording session. While physically securing the SRC and SRS may
prevent an outside attacker from accessing important call recordings,
this still does not prevent from an inside attacker from accessing
the internal network to gain access to the call recordings.
13.2. Authentication and Authorization 12.1. Authentication and Authorization
The recording session reuses the SIP mechanism to challenge requests The recording session reuses the SIP mechanism to challenge requests
that is based on HTTP authentication. The mechanism relies on 401 that is based on HTTP authentication. The mechanism relies on 401
and 407 SIP responses as well as other SIP header fields for carrying and 407 SIP responses as well as other SIP header fields for carrying
challenges and credentials. challenges and credentials.
At the transport level, the recording session uses TLS authentication
to validate the authenticity of the SRC and SRS. The SRC and SRS
MUST implement TLS mutual authentication for establishing the
recording session, and whether the SRC/SRS chooses to use
authentication is a deployment decision. In deployments where the
SRC and the SRS are in the same administrative domain, the deployment
may choose not to authenticate each other or only to have SRC
authenticate the SRS as there is an inherent trust relation between
the SRC and the SRS when they are hosted in the same administrative
domain. In deployments where the SRS can be hosted on a different
administrative domain, then it is important to perform mutual
authentication to ensure the authenticity of both the SRC and the SRS
before transmitting any recorded media. The risk of not
authenticating the SRS is that the recording may be sent to a
compromised SRS and that sensitive call recording will be obtained by
an attacker. On the other hand, the risk of not authenticating the
SRC is that an SRS will be willingly accept any call recording from
an unknown SRC and allow potential forgery of call recordings.
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.
14. Acknowledgements 12.2. RTP handling
In many scenarios it will be critical that the media transported
between the SRC and SRS to be protected. Media encryption is an
important element in the overall SIPREC solution; therefore SRC and
SRS MUST support RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124]. RTP/
SAVP and RTP/SAVPF provide media encryption, integrity protection,
replay protection, and a limited form of source authentication. They
do not contain or require a specific keying mechanism.
When RTP/SAVP or RTP/SAVPF is used, RS can choose to use the same or
different security keys than the ones used in the CS. Some SRCs are
designed to simply replicate RTP packets from the CS media stream to
the SRS, and the SRC will be reusing the same keys as the CS. In
this case, the SRC MUST secure the SDP with SDP Security Descriptions
(SDES) [RFC4568] in the RS with at least the same level of security
as the CS. The risk of lowering the level of security in the RS for
this case is that it will effectively become a downgrade attack on
the CS since the same key is used for both CS and RS.
For SRCs that perform transcoding or mixing of media before sending
to the SRS, the SRC MUST negotiate a different security key than the
one being used in the CS, to ensure that the security in the CS is
not compromised by the SRC when reusing the same security key.
12.3. Metadata
Metadata contains sensitive information such as the address of record
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
metadata is a content type transmitted in SIP signalling, metadata
SHOULD be protected at the transport level by SIPS/TLS.
12.4. Storage and playback
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
important for the recording storage and playback to provide a level
of security that is comparable to the communication session. It
would defeat the purpose of securing both the communication session
and the recording session mentioned in the previous sections if the
recording can be easily played back with a simple unsecured HTTP
interface without any form of authentication or authorization.
13. Acknowledgements
We want to thank John Elwell, Paul Kyzivat, Partharsarathi R, Ram We want to thank John Elwell, Paul Kyzivat, Partharsarathi R, Ram
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.
15. References 14. References
15.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-metadata-07 (work in progress), draft-ietf-siprec-metadata-07 (work in progress),
July 2012. July 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.
skipping to change at page 38, line 40 skipping to change at page 41, line 11
[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.
15.2. Informative References 14.2. Informative References
[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-05 Initiation Protocol", draft-ietf-siprec-architecture-06
(work in progress), May 2012. (work in progress), September 2012.
[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.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[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
Description Protocol (SDP) Security Descriptions for Media
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 2006. July 2006.
[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.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for
Media Control", RFC 5168, March 2008. Media Control", RFC 5168, March 2008.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", RFC 6222, April 2011. (CNAMEs)", RFC 6222, April 2011.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011. Control Protocol (RTCP) Flows", RFC 6263, June 2011.
 End of changes. 51 change blocks. 
263 lines changed or deleted 360 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/