draft-ietf-siprec-protocol-07.txt   draft-ietf-siprec-protocol-08.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 5, 2013 Genesys Expires: April 25, 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 2, 2012 October 22, 2012
Session Recording Protocol Session Recording Protocol
draft-ietf-siprec-protocol-07 draft-ietf-siprec-protocol-08
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 5, 2013. This Internet-Draft will expire on April 25, 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 28 skipping to change at page 2, line 28
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. SIP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. SIP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 10 6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 9
6.1.1. Initiating a Recording Session . . . . . . . . . . . . 10 6.1.1. Initiating a Recording Session . . . . . . . . . . . . 10
6.1.2. SIP extensions for recording indication and 6.1.2. SIP extensions for recording indication and
preference . . . . . . . . . . . . . . . . . . . . . . 10 preference . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 11 6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 11
6.3. Procedures for Recording-aware User Agents . . . . . . . . 11 6.3. Procedures for Recording-aware User Agents . . . . . . . . 11
7. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 12 7.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 12
7.1.1. SDP handling in RS . . . . . . . . . . . . . . . . . . 12 7.1.1. SDP handling in RS . . . . . . . . . . . . . . . . . . 12
7.1.1.1. Handling media stream updates . . . . . . . . . . 13 7.1.1.1. Handling media stream updates . . . . . . . . . . 13
7.1.2. Recording indication in CS . . . . . . . . . . . . . . 14 7.1.2. Recording indication in CS . . . . . . . . . . . . . . 14
skipping to change at page 5, line 31 skipping to change at page 5, line 31
o Policies governing how CS users are made aware of recording o Policies governing how CS users are made aware of recording
o Delivering additional recording session metadata through non-SIP o Delivering additional recording session metadata through non-SIP
mechanism mechanism
5. Overview of operations 5. Overview of operations
This section is informative and provides a description of recording This section is informative and provides a description of recording
operations. operations.
Section 5 provides the procedures for establishing a recording Section 6 describes SIP the handling in a recording session between a
session between a SRC and a SRS. Section 6 describes the SDP in a SRC and a SRS, and the procedures for recording-aware user agents
recording session. Section 7 describes the RTP handling in a participating in a CS. Section 7 describes the SDP in a recording
recording session. Section 8 describes the mechanism to deliver session, and the procedures for recording indications and recording
recording metadata from the SRC to the SRS. preferences. Section 8 describes the RTP handling in a recording
session. Section 9 describes the mechanism to deliver recording
Section 10 describes the procedures for user agents participating in metadata from the SRC to the SRS.
a CS to receive recording indications and to provide preferences for
recording.
As mentioned in the architecture document As mentioned in the architecture document
[I-D.ietf-siprec-architecture], there are a number of types of call [I-D.ietf-siprec-architecture], there are a number of types of call
flows based on the location of the Session Recording Client. The flows based on the location of the Session Recording Client. The
following sample call flows provide a quick overview of the following sample call flows provide a quick overview of the
operations between the SRC and the SRS. operations between the SRC and the SRS.
5.1. Delivering recorded media 5.1. Delivering recorded media
When a SIP Back-to-back User Agent (B2BUA) with SRC functionality When a SIP Back-to-back User Agent (B2BUA) with SRC functionality
skipping to change at page 8, line 43 skipping to change at page 8, line 43
|---------------------------------------------------->| |---------------------------------------------------->|
| (14) 200 OK | | (14) 200 OK |
|<----------------------------------------------------| |<----------------------------------------------------|
Figure 2: Delivering metadata via SIP UPDATE Figure 2: Delivering metadata via SIP UPDATE
5.3. Receiving recording indications and providing recording 5.3. Receiving recording indications and providing recording
preferences preferences
The SRC is responsible to provide recording indications to the The SRC is responsible to provide recording indications to the
participants in the CS. User agents that are recording-aware participants in the CS. A recording-aware UA supports receiving
supports receiving recording indications with new SDP attribute recording indications via the SDP attribute a=record, and it can
a=record and the recording-aware UA can also set recording preference specify a recording preference in the CS by including the SDP
in the CS with a new SDP attribute a=recordpref. The recording attribute a=recordpref. The recording attribute is a declaration by
attribute is a declaration by the SRC in the CS to indicate whether the SRC in the CS to indicate whether recording is taking place. The
recording is taking place. The recording preference attribute is a recording preference attribute is a declaration by the recording-
declaration by the recording-aware UA in the CS to indicate the aware UA in the CS to indicate the recording preference.
recording preference.
To illustrate how the attributes are used, if a UA (A) is initiating To illustrate how the attributes are used, if a UA (A) is initiating
a call to UA (B) and UA (A) is also an SRC that is performing the a call to UA (B) and UA (A) is also an SRC that is performing the
recording, then UA (A) provides the recording indication in the SDP recording, then UA (A) provides the recording indication in the SDP
offer with a=record:on. Since UA (A) is the SRC, UA (A) receives the offer with a=record:on. Since UA (A) is the SRC, UA (A) receives the
recording indication from the SRC directly. When UA (B) receives the recording indication from the SRC directly. When UA (B) receives the
SDP offer, UA (B) will see that recording is happening on the other SDP offer, UA (B) will see that recording is happening on the other
endpoint of this session. Since UA (B) is not an SRC and does not endpoint of this session. Since UA (B) is not an SRC and does not
provide any recording preference, the SDP answer does not contain provide any recording preference, the SDP answer does not contain
a=record nor a=recordpref. a=record nor a=recordpref.
skipping to change at page 10, line 4 skipping to change at page 9, line 44
Figure 3: Recording indication and recording preference Figure 3: Recording indication and recording preference
After the call is established and recording is in progress, UA (B) After the call is established and recording is in progress, UA (B)
later decides to change the recording preference to no recording and later decides to change the recording preference to no recording and
sends a reINVITE with the a=recordpref attribute. It is up to the sends a reINVITE with the a=recordpref attribute. It is up to the
SRC to honor the preference, and in this case SRC decides to stop the SRC to honor the preference, and in this case SRC decides to stop the
recording and updates the recording indication in the SDP answer. recording and updates the recording indication in the SDP answer.
6. SIP Handling 6. SIP Handling
6.1. Procedures at the SRC
6.1. Procedures at the SRC
6.1.1. Initiating a Recording Session 6.1.1. Initiating a Recording Session
A recording session is a SIP session with specific extensions A recording session is a SIP session with specific extensions
applied, and these extensions are listed in the procedures for SRC 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 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 not a recording session, it is up to the SRC or the SRS to determine
what to do with the SIP session. 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
skipping to change at page 12, line 36 skipping to change at page 12, line 35
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 a=label attribute only applies to the SDP and Metadata scope of the a=label attribute only applies to the SDP and Metadata
conveyed in the bodies of the SIP request or response that the label conveyed in the bodies of the SIP request or response that the label
appeared in. Note that a recorded stream is distinct from a CS appeared in. Note that a recorded stream is distinct from a CS
stream; the metadata provides a list of participants that contributes stream; the metadata provides a list of 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 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 contains
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
t=0 0 t=0 0
m=audio 12240 RTP/AVP 0 4 8 m=audio 12240 RTP/AVP 0 4 8
a=sendonly a=sendonly
skipping to change at page 14, line 47 skipping to change at page 14, line 47
; attribute defined in RFC 4566 ; attribute defined in RFC 4566
record-attr = "record:" indication record-attr = "record:" indication
indication = "on" / "off" / "paused" indication = "on" / "off" / "paused"
on Recording is in progress. on Recording is in progress.
off No recording is in progress. off No recording is in progress.
paused Recording is in progress by media is paused. paused Recording is in progress but media is paused.
7.1.3. Recording preference in CS 7.1.3. Recording preference in CS
When the SRC receives the a=recordpref SDP in an SDP offer or answer, When the SRC receives the a=recordpref SDP in an SDP offer or answer,
the SRC chooses to honor the preference to record based on local the SRC chooses to honor the preference to record based on local
policy at the SRC. Whether or not the SRC honors the recording policy at the SRC. Whether or not the SRC honors the recording
preference, the SRC MUST update the a=record attribute to indicate preference, the SRC MUST update the a=record attribute to indicate
the current state of the recording (on/off/paused). 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 Typically the SRS only receives RTP streams from the SRC; therefore,
normally sets each media stream to receive media, by setting them the SDP offer/answer from the SRS normally sets each media stream to
with the a=recvonly attribute, according to the procedures of receive media, by setting them with the a=recvonly attribute,
[RFC3264]. When the SRS is not ready to receive a recorded stream, according to the procedures of [RFC3264]. When the SRS is not ready
the SRS sets the media stream as inactive in the SDP offer or answer to receive a recorded stream, the SRS sets the media stream as
by setting it with a=inactive attribute, according to the procedures inactive in the SDP offer or answer by setting it with a=inactive
of [RFC3264]. When the SRS is ready to receive recorded streams, the attribute, according to the procedures of [RFC3264]. When the SRS is
SRS sends a new SDP offer and sets the media streams with a=recvonly ready to receive recorded streams, the SRS sends a new SDP offer and
attribute. sets the media streams with a=recvonly attribute.
The following is an example of SDP answer from SRS for the SDP offer The following is an example of SDP answer from SRS for the SDP offer
from the above sample. Note that the following example contain from the above sample. 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=SRS 0 0 IN IP4 198.51.100.20 o=SRS 0 0 IN IP4 198.51.100.20
s=- s=-
c=IN IP4 198.51.100.20 c=IN IP4 198.51.100.20
t=0 0 t=0 0
m=audio 10000 RTP/AVP 0 4 8 m=audio 10000 RTP/AVP 0
a=recvonly a=recvonly
a=label:1 a=label:1
m=video 10002 RTP/AVP 98 m=video 10002 RTP/AVP 98
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=recvonly a=recvonly
a=label:2 a=label:2
m=audio 10004 RTP/AVP 0 4 8 m=audio 10004 RTP/AVP 0
a=recvonly a=recvonly
a=label:3 a=label:3
m=video 10006 RTP/AVP 98 m=video 10006 RTP/AVP 98
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=recvonly a=recvonly
a=label:4 a=label:4
skipping to change at page 38, line 13 skipping to change at page 38, 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, session existing SIP security mechanism available for securing the session
signaling, the recorded media as well as metadata. The use cases and signaling, the recorded media as well as the metadata. The use cases
requirements document [RFC6341] outlines the general security and requirements document [RFC6341] outlines the general security
considerations, and the following describe specific security considerations, and the following describe specific security
recommendations. recommendations.
The SRC and SRS MUST support SIPS and TLS as per [RFC5630]. The The SRC and SRS MUST support SIP with TLS and MAY support SIPS with
Recording Session SHOULD be at least as secure as the Communication TLS as per [RFC5630]. The Recording Session SHOULD be at least as
Session, meaning using at least the same strength of cipher suite as secure as the Communication Session, meaning using at least the same
the CS if the CS is secured. For example, if the CS uses SIPS for strength of cipher suite as the CS if the CS is secured. For
signalling and RTP/SAVP for media, then the RS does not downgrade the example, if the CS uses SIPS for signalling and RTP/SAVP for media,
level of security in the RS to SIP or plain RTP since doing so will then the RS does not downgrade the level of security in the RS to SIP
mean an automatic security downgrade for the CS. In deployments or plain RTP since doing so will mean an automatic security downgrade
where the SRC and the SRS are in the same administrative domain and for the CS. In deployments where the SRC and the SRS are in the same
the same physical switch that prevents outside user access, some SRC administrative domain and the same physical switch that prevents
may choose lower the level of security when establishing the outside user access, some SRC may choose lower the level of security
recording session. While physically securing the SRC and SRS may when establishing the recording session. While physically securing
prevent an outside attacker from accessing important call recordings, the SRC and SRS may prevent an outside attacker from accessing
this still does not prevent from an inside attacker from accessing important call recordings, this still does not prevent an inside
the internal network to gain access to the call recordings. attacker from accessing the internal network to gain access to the
call recordings.
12.1. 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 are 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 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, and whether the SRC/SRS chooses to use
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 deployment
may choose not to authenticate each other or only to have SRC may choose not to authenticate each other or only to have SRC
authenticate the SRS as there is an inherent trust relation between authenticate the SRS as there is an inherent trust relation between
the SRC and the SRS when they are hosted in the same administrative 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 domain. In deployments where the SRS can be hosted on a different
administrative domain, then it is important to perform mutual administrative domain, then 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 sensitive call recording will be obtained by
an attacker. On the other hand, the risk of not authenticating the 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 SRC is that an SRS will accept calls from an unknown SRC and allow
an unknown SRC and allow potential forgery of call recordings. 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.
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 that the media transported
between the SRC and SRS to be protected. Media encryption is an between the SRC and 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 SRC and
skipping to change at page 40, line 30 skipping to change at page 40, line 30
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-07 (work in progress), draft-ietf-siprec-metadata-08 (work in progress),
July 2012. October 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,
 End of changes. 19 change blocks. 
59 lines changed or deleted 57 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/