draft-ietf-siprec-protocol-08.txt   draft-ietf-siprec-protocol-09.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 25, 2013 Genesys Expires: June 11, 2013 Genesys
C. Eckel C. Eckel
Cisco Cisco
A. Johnston A. Johnston
Avaya Avaya
A. Hutton A. Hutton
Siemens Enterprise Siemens Enterprise
Communications Communications
October 22, 2012 December 8, 2012
Session Recording Protocol Session Recording Protocol
draft-ietf-siprec-protocol-08 draft-ietf-siprec-protocol-09
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 April 25, 2013. This Internet-Draft will expire on June 11, 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 3, line 19 skipping to change at page 3, line 19
8.1.7.3. Temporary Maximum Media Stream Bit Rate Request . 22 8.1.7.3. Temporary Maximum Media Stream Bit Rate Request . 22
8.1.8. Symmetric RTP/RTCP for Sending and Receiving . . . . . 23 8.1.8. Symmetric RTP/RTCP for Sending and Receiving . . . . . 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 . . . . . . . . . . . . . . 25 8.2.1.1. Forwarding Translator . . . . . . . . . . . . . . 25
8.2.1.2. Transcoding Translator . . . . . . . . . . . . . . 25 8.2.1.2. Transcoding Translator . . . . . . . . . . . . . . 25
8.2.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . 27 8.3. RTP Session Usage by SRC . . . . . . . . . . . . . . . . . 27
8.3.1. SRC Using Multiple m-lines . . . . . . . . . . . . . . 27 8.3.1. SRC Using Multiple m-lines . . . . . . . . . . . . . . 27
8.3.2. SRC Using SSRC Multiplexing . . . . . . . . . . . . . 28 8.3.2. SRC Using Mixing . . . . . . . . . . . . . . . . . . . 28
8.3.3. SRC Using Mixing . . . . . . . . . . . . . . . . . . . 29 8.4. RTP Session Usage by SRS . . . . . . . . . . . . . . . . . 29
9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 30 9.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 29
9.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 32 9.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 31
9.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 34 9.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 33
10. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 34 10. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11.1. Registration of Option Tags . . . . . . . . . . . . . . . 34 11.1. Registration of Option Tags . . . . . . . . . . . . . . . 33
11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 35 11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 34
11.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 35 11.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 34
11.2. Registration of media feature tags . . . . . . . . . . . . 35 11.2. Registration of media feature tags . . . . . . . . . . . . 34
11.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 35 11.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 34
11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 36 11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 35
11.3. New Content-Disposition Parameter Registrations . . . . . 36 11.3. New Content-Disposition Parameter Registrations . . . . . 35
11.4. Media Type Registration . . . . . . . . . . . . . . . . . 36 11.4. Media Type Registration . . . . . . . . . . . . . . . . . 35
11.4.1. Registration of MIME Type application/rs-metadata . . 36 11.4.1. Registration of MIME Type application/rs-metadata . . 35
11.4.2. Registration of MIME Type 11.4.2. Registration of MIME Type
application/rs-metadata-request . . . . . . . . . . . 37 application/rs-metadata-request . . . . . . . . . . . 36
11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 37 11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 36
11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 37 11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 36
11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 37 11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 36
12. Security Considerations . . . . . . . . . . . . . . . . . . . 38 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
12.1. Authentication and Authorization . . . . . . . . . . . . . 38 12.1. Authentication and Authorization . . . . . . . . . . . . . 37
12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . . 39 12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . . 38
12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . 39 12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.4. Storage and playback . . . . . . . . . . . . . . . . . . . 40 12.4. Storage and playback . . . . . . . . . . . . . . . . . . . 39
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.1. Normative References . . . . . . . . . . . . . . . . . . . 40 14.1. Normative References . . . . . . . . . . . . . . . . . . . 39
14.2. Informative References . . . . . . . . . . . . . . . . . . 41 14.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 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
skipping to change at page 18, line 10 skipping to change at page 18, line 10
call is being recorded. This attribute is also not used as an call is being recorded. This attribute is also not used as an
indication to negotiate which SRC in the call path will perform indication to negotiate which SRC in the call path will perform
recording and is not used as a request to start/stop recording if recording and is not used as a request to start/stop recording if
there are multiple SRCs in the call path. 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 atrribute 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
can learn the recording indication through the a=record SDP attribute can learn the recording indication through the a=record SDP attribute
as described in the above section. as described in the above section.
The SDP a=recordpref attribute can appear at the media level or 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 session level and can appear in an SDP offer or answer. When the
attribute is applied at the session level, the recording preference attribute is applied at the session level, the recording preference
applies to all media stream in the SDP. When the attribute is applies to all media stream in the SDP. When the attribute is
skipping to change at page 28, line 22 skipping to change at page 28, line 22
| | | | | | | |
| | | | | | | |
+---------+ +----------+ +---------+ +---------+ +----------+ +---------+
| |---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 SSRC Multiplexing 8.3.2. SRC Using Mixing
When using SSRC multiplexing, an SRC multiplexes RTP packets of the
same media type from multiple RTP sessions into a single RTP session
with multiple SSRC values. 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 m-lines, with any rejected m-lines indicated with the
zero port, per [RFC3264]. Having received the answer, the SRC starts
sending media to the SRS as indicated in the answer.
In order to preserve the mapping of media to participant within the
CSs in the RS, the SRC SHOULD map each unique combination of CNAME/
SSRC within the CSs to a unique SSRC within the RS. The CNAMEs used
in the CSs are not preserved within the RS. The SRS relies on the
SIPREC metadata to determine the participants included within each
multiplexed stream. The SRC MUST avoid SSRC collisions, rewriting
SSRCs if necessary. In doing to, the SRC acts as an RTP endpoint.
In the event the SRS does not support SSRC multiplexing, the SRC
becomes aware of this when it receives RTCP receiver reports from the
SRS indicating the absence of any packets for one or more of the
multiplexed SSRC values. If the SRC deems the level of support
indicated in the RTCP receiver report to be unacceptable, it may
initiate another SDP offer/answer exchange in which an alternative
RTP session usage is negotiated.
The following figure illustrates a case in which each UA represents a
participant contributing two RTP sessions (e.g. one for audio and
another for video), each with a single SSRC. The SRC delivers the
media to the SRS using two RTP sessions, multiplexing one stream with
the same media type from each participant into a single RTP session
containing two SSRCs. The SRC uses its own CNAME and SSRC values,
but it preserves the mapping of unique CNAME/SSRC used by the UAs
within their media streams in the media streams from the SRC to the
SRS.
+---------+
| |
+-----SSRC SAa,SBa--->| |
| +-SSRC SAv,SBv--->| SRS |
| | | |
| | +---------+
| |
| |
+---------+ +----------+ +---------+
| |---SSRC Aa-->| SRC |<--SSRC Ba---| |
| UA-A | |(CNAME-S) | | UA-B |
|(CNAME-A)|---SSRC Av-->| |<--SSRC Bv---|(CNAME-B)|
+---------+ +----------+ +---------+
Figure 10: SRC Using SSRC Multiplexing
8.3.3. 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
m-lines, with any rejected m-lines indicated with the zero port, per m-lines, with any rejected m-lines indicated with the zero port, per
[RFC3264]. Having received the answer, the SRC starts sending media [RFC3264]. Having received the answer, the SRC starts sending media
to the SRS as indicated in the answer. to the SRS as indicated in the answer.
skipping to change at page 30, line 24 skipping to change at page 29, line 19
| +---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 11: SRC Using Mixing Figure 10: SRC Using Mixing
8.4. RTP Session Usage by SRS
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
that supports recording an video CS MUST support SRC usage of
separate video m-lines in SDP, one per CS media direction.
Therefore, for an SRS supporting a typical audio call, the SRS has to
support receiving at least two audio m-lines. For an SRS supporting
a typical audio and video call, the SRS has to support receiving at
least four total m-lines in the SDP, two audio m-lines and two video
m-lines.
Note that these requirements allow an SRS to be implemented that
supports video only, without requiring support for audio recording.
They also allow an SRS to be implemented that supports recording only
one direction of one stream in a CS; for example, an SRS designed to
record security monitoring cameras that only send (not receive) video
without any audio. These requirements were not written to prevent
other modes being implemented and used, such as using a single m-line
and mixing the separate audio streams together. Rather, the
requirements were written to provide a common base mode to implement
to the sake of interoperability. SRS implementations may support
other modes as well, but have to at least support the ones above such
that they interoperate in the common base mode.
9. Metadata 9. Metadata
9.1. Procedures at the SRC 9.1. Procedures at the SRC
The SRC MUST deliver metadata to the SRS in a recording session; the The SRC MUST deliver metadata to the SRS in a recording session; the
timing of which SRC sends the metadata depends on when the metadata timing of which SRC sends the metadata depends on when the metadata
becomes available. Metadata SHOULD be provided by the SRC in the becomes available. Metadata SHOULD be provided by the SRC in the
initial INVITE request when establishing the recording session, and initial INVITE request when establishing the recording session, and
subsequent metadata updates can be provided by the SRC in reINVITE subsequent metadata updates can be provided by the SRC in reINVITE
skipping to change at page 32, line 37 skipping to change at page 31, line 37
m=audio 12240 RTP/AVP 0 4 8 m=audio 12240 RTP/AVP 0 4 8
a=sendonly a=sendonly
a=label:1 a=label:1
--foobar --foobar
Content-Type: application/rs-metadata Content-Type: application/rs-metadata
Content-Disposition: recording-session Content-Disposition: recording-session
[metadata content] [metadata content]
Figure 12: Sample INVITE request for the recording session Figure 11: Sample INVITE request for the recording session
9.2. Procedures at the SRS 9.2. Procedures at the SRS
The SRS receives metadata updates from the SRC in INVITE and UPDATE The SRS receives metadata updates from the SRC in INVITE and UPDATE
requests. Since the SRC can send partial updates based on the requests. Since the SRC can send partial updates based on the
previous update, the SRS needs to keep track of the sequence of previous update, the SRS needs to keep track of the sequence of
updates from the SRC. updates from the SRC.
In the case of an internal failure at the SRS, the SRS may fail to In the case of an internal failure at the SRS, the SRS may fail to
recognize a partial update from the SRC. The SRS may be able to recognize a partial update from the SRC. The SRS may be able to
skipping to change at page 33, line 35 skipping to change at page 32, line 35
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
Accept: application/sdp, application/rs-metadata Accept: application/sdp, application/rs-metadata
Content-Disposition: recording-session Content-Disposition: recording-session
Content-Type: application/rs-metadata-request Content-Type: application/rs-metadata-request
Content-Length: [length] Content-Length: [length]
SRS internal error SRS internal error
Figure 13: Metadata Request Figure 12: Metadata Request
The SRS MAY include the reason why a metadata snapshot request is The SRS MAY include the reason why a metadata snapshot request is
being made to the SRC in the reason line. This reason line is free being made to the SRC in the reason line. This reason line is free
form text, mainly designed for logging purposes on the SRC side. The form text, mainly designed for logging purposes on the SRC side. The
processing of the content by the SRC is entirely optional since the processing of the content by the SRC is entirely optional since the
content is for logging only, and the snapshot request itself is content is for logging only, and the snapshot request itself is
indicated by the use of the application/rs-metadata-request content indicated by the use of the application/rs-metadata-request content
type. type.
When the SRC receives the request for a metadata snapshot, the SRC When the SRC receives the request for a metadata snapshot, the SRC
skipping to change at page 38, line 13 skipping to change at page 37, line 13
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
12. 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 session existing SIP security mechanisms available for securing the session
signaling, the recorded media as well as the metadata. The use cases signaling, the recorded media, and the metadata. The use cases and
and requirements document [RFC6341] outlines the general security requirements document [RFC6341] outlines the general security
considerations, and the following describe specific security considerations, and this document describes specific security
recommendations. recommendations.
The SRC and SRS MUST support SIP with TLS and MAY support SIPS with The SRC and SRS MUST support SIP with TLS and MAY support SIPS with
TLS as per [RFC5630]. The Recording Session SHOULD be at least as TLS as per [RFC5630]. The Recording Session SHOULD be at least as
secure as the Communication Session, meaning using at least the same secure as the Communication Session, meaning using at least the same
strength of cipher suite as the CS if the CS is secured. For strength of cipher suite as the CS if the CS is secured. For
example, if the CS uses SIPS for signalling and RTP/SAVP for media, example, if the CS uses SIPS for signaling and RTP/SAVP for media,
then the RS does not downgrade the level of security in the RS to SIP then the RS should not downgrade the level of security in the RS to
or plain RTP since doing so will mean an automatic security downgrade SIP or plain RTP since doing so will mean an automatic security
for the CS. In deployments where the SRC and the SRS are in the same downgrade for the CS. In deployments where the SRC and the SRS are
administrative domain and the same physical switch that prevents in the same administrative domain and the same physical switch that
outside user access, some SRC may choose lower the level of security prevents outside user access, some SRCs may choose to lower the level
when establishing the recording session. While physically securing of security when establishing a recording session. While physically
the SRC and SRS may prevent an outside attacker from accessing securing the SRC and SRS may prevent an outside attacker from
important call recordings, this still does not prevent an inside accessing important call recordings, this still does not prevent an
attacker from accessing the internal network to gain access to the inside attacker from accessing the internal network to gain access to
call recordings. the call recordings.
12.1. Authentication and Authorization 12.1. Authentication and Authorization
The recording session reuses the SIP mechanism to challenge requests
that are based on HTTP authentication. The mechanism relies on 401
and 407 SIP responses as well as other SIP header fields for carrying
challenges and credentials.
At the transport level, the recording session uses TLS authentication At the transport level, the recording session uses TLS authentication
to validate the authenticity of the SRC and SRS. The SRC and SRS to validate the authenticity of the SRC and SRS. The SRC and SRS
MUST implement TLS mutual authentication for establishing the MUST implement TLS mutual authentication for establishing the
recording session, and whether the SRC/SRS chooses to use recording session. Whether the SRC/SRS chooses to use TLS mutual
authentication is a deployment decision. In deployments where the authentication is a deployment decision. In deployments where the
SRC and the SRS are in the same administrative domain, the deployment SRC and the SRS are in the same administrative domain, the SRC and
may choose not to authenticate each other or only to have SRC SRS may choose not to authenticate each other, or to have the SRC
authenticate the SRS as there is an inherent trust relation between authenticate the SRS only, as there is an inherent trust relation
the SRC and the SRS when they are hosted in the same administrative between the SRC and the SRS when they are hosted in the same
domain. In deployments where the SRS can be hosted on a different administrative domain. In deployments where the SRS can be hosted on
administrative domain, then it is important to perform mutual a different administrative domain, it is important to perform mutual
authentication to ensure the authenticity of both the SRC and the SRS authentication to ensure the authenticity of both the SRC and the SRS
before transmitting any recorded media. The risk of not before transmitting any recorded media. The risk of not
authenticating the SRS is that the recording may be sent to a authenticating the SRS is that the recording may be sent to a
compromised SRS and that sensitive call recording will be obtained by compromised SRS and that a sensitive call recording will be obtained
an attacker. On the other hand, the risk of not authenticating the by an attacker. On the other hand, the risk of not authenticating
SRC is that an SRS will accept calls from an unknown SRC and allow the SRC is that an SRS will accept calls from an unknown SRC and
potential forgery of call recordings. allow potential forgery of call recordings.
There may be scenarios in which the signaling between the SRC and SRS
is not direct, e.g. a SIP proxy exists between the SRC and the SRS.
In such scenarios, each hop is subject to the TLS mutual
authentication constraint and transitive trust at each hop is
utilized. Additionally, an SRC or SRS may use other existing SIP
mechanisms available, including but not limited to, Digest
Authentication [RFC3261], Asserted Identity [RFC3325], and Connected
Identity [RFC4916].
The SRS may have its own set of recording policies to authorize The SRS may have its own set of recording policies to authorize
recording requests from the SRC. The use of recording policies is recording requests from the SRC. The use of recording policies is
outside the scope of the Session Recording Protocol. outside the scope of the Session Recording Protocol.
12.2. RTP handling 12.2. RTP handling
In many scenarios it will be critical that the media transported In many scenarios it will be critical for the media transported
between the SRC and SRS to be protected. Media encryption is an between the SRC and the SRS to be protected. Media encryption is an
important element in the overall SIPREC solution; therefore SRC and important element in the overall SIPREC solution; therefore the SRC
SRS MUST support RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124]. RTP/ and the SRS MUST support RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124].
SAVP and RTP/SAVPF provide media encryption, integrity protection, RTP/SAVP and RTP/SAVPF provide media encryption, integrity
replay protection, and a limited form of source authentication. They protection, replay protection, and a limited form of source
do not contain or require a specific keying mechanism. authentication. They do not contain or require a specific keying
mechanism. At a minimum, the SRC and SRS MUST support the SDP
Security Descriptions (SDES) key negotiation mechanism [RFC4568].
For cases in which DTLS-SRTP is used to encrypt a CS media stream, an
SRC may use SRTP Encrypted Key Transport (EKT)
[I-D.ietf-avt-srtp-ekt] in order to use SRTP-SDES in the RS without
needing to re-encrypt the media.
When RTP/SAVP or RTP/SAVPF is used, RS can choose to use the same or When RTP/SAVP or RTP/SAVPF is used, an SRC can choose to use the same
different security keys than the ones used in the CS. Some SRCs are or different keys in the RS than the ones used in the CS. Some SRCs
designed to simply replicate RTP packets from the CS media stream to are designed to simply replicate RTP packets from a CS media stream
the SRS, and the SRC will be reusing the same keys as the CS. In to the SRS, in which case the SRC will use the same key in the RS as
this case, the SRC MUST secure the SDP with SDP Security Descriptions used in the CS. In this case, the SRC MUST secure the SDP containing
(SDES) [RFC4568] in the RS with at least the same level of security the keying material in the RS with at least the same level of
as the CS. The risk of lowering the level of security in the RS for security as in the CS. The risk of lowering the level of security in
this case is that it will effectively become a downgrade attack on the RS is that it will effectively become a downgrade attack on the
the CS since the same key is used for both CS and RS. CS since the same key is used for both CS and RS.
For SRCs that perform transcoding or mixing of media before sending SRCs that decrypt an encrypted CS media stream and re-encrypt it when
to the SRS, the SRC MUST negotiate a different security key than the sending it to the SRS SHOULD use a different key for the RS media
one being used in the CS, to ensure that the security in the CS is stream than what is used for the CS media stream, to ensure that it
not compromised by the SRC when reusing the same security key. is not possible for someone who has the key for the CS media stream
to access recorded data they are not authorized to access.
12.3. Metadata 12.3. Metadata
Metadata contains sensitive information such as the address of record Metadata contains sensitive information such as the address of record
of the participants and other extension data placed by the SRC. It of the participants and other extension data placed by the SRC. It
is essential to protect the content of the metadata in the RS. Since is essential to protect the content of the metadata in the RS. Since
metadata is a content type transmitted in SIP signalling, metadata metadata is a content type transmitted in SIP signaling, metadata
SHOULD be protected at the transport level by SIPS/TLS. SHOULD be protected at the transport level by SIPS/TLS.
12.4. Storage and playback 12.4. Storage and playback
While storage and playback of the call recording is beyond the scope While storage and playback of the call recording is beyond the scope
of this document, it is worthwhile to mention here that it is also of this document, it is worthwhile to mention here that it is also
important for the recording storage and playback to provide a level important for the recording storage and playback to provide a level
of security that is comparable to the communication session. It of security that is comparable to the communication session. It
would defeat the purpose of securing both the communication session would defeat the purpose of securing both the communication session
and the recording session mentioned in the previous sections if the and the recording session mentioned in the previous sections if the
skipping to change at page 40, line 30 skipping to change at page 39, line 39
Muthu Perumal, Dan Wing, and Magnus Westerlund for their valuable Muthu Perumal, Dan Wing, and Magnus Westerlund for their valuable
comments and inputs to this document. comments and inputs to this document.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-siprec-metadata] [I-D.ietf-siprec-metadata]
R, R., Ravindran, P., and P. Kyzivat, "Session Initiation R, R., Ravindran, P., and P. Kyzivat, "Session Initiation
Protocol (SIP) Recording Metadata", Protocol (SIP) Recording Metadata",
draft-ietf-siprec-metadata-08 (work in progress), draft-ietf-siprec-metadata-10 (work in progress),
October 2012. November 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999. Registration Procedure", BCP 31, RFC 2506, March 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
skipping to change at page 41, line 13 skipping to change at page 40, line 24
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.
14.2. Informative References 14.2. Informative References
[I-D.ietf-avt-srtp-ekt]
Wing, D., McGrew, D., and K. Fischer, "Encrypted Key
Transport for Secure RTP", draft-ietf-avt-srtp-ekt-03
(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-06 Initiation Protocol", draft-ietf-siprec-architecture-07
(work in progress), September 2012. (work in progress), November 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.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 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)",
skipping to change at page 41, line 43 skipping to change at page 41, line 15
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007. BCP 131, RFC 4961, July 2007.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
[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.
 End of changes. 28 change blocks. 
146 lines changed or deleted 144 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/