draft-ietf-siprec-protocol-17.txt   draft-ietf-siprec-protocol-18.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 3, 2016 Genesys Expires: March 28, 2016 Genesys
C. Eckel C. Eckel
Cisco Cisco
A. Johnston A. Johnston
Avaya Avaya
A. Hutton A. Hutton
Unify Unify
July 2, 2015 September 25, 2015
Session Recording Protocol Session Recording Protocol
draft-ietf-siprec-protocol-17 draft-ietf-siprec-protocol-18
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 2, line 4 skipping to change at page 2, line 4
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 3, 2016. This Internet-Draft will expire on March 28, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 28 skipping to change at page 3, line 28
8.2.1.2. Transcoding Translator . . . . . . . . . . . . . 26 8.2.1.2. Transcoding Translator . . . . . . . . . . . . . 26
8.2.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . 27 8.2.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . 27
8.2.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 28 8.2.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 28
8.3. RTP Session Usage by SRC . . . . . . . . . . . . . . . . 28 8.3. RTP Session Usage by SRC . . . . . . . . . . . . . . . . 28
8.3.1. SRC Using Multiple m-lines . . . . . . . . . . . . . 28 8.3.1. SRC Using Multiple m-lines . . . . . . . . . . . . . 28
8.3.2. SRC Using Mixing . . . . . . . . . . . . . . . . . . 29 8.3.2. SRC Using Mixing . . . . . . . . . . . . . . . . . . 29
8.4. RTP Session Usage by SRS . . . . . . . . . . . . . . . . 30 8.4. RTP Session Usage by SRS . . . . . . . . . . . . . . . . 30
9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 31 9.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 31
9.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 33 9.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 33
9.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 35
10. Persistent Recording . . . . . . . . . . . . . . . . . . . . 35 10. Persistent Recording . . . . . . . . . . . . . . . . . . . . 35
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11.1. Registration of Option Tags . . . . . . . . . . . . . . 35 11.1. Registration of Option Tags . . . . . . . . . . . . . . 35
11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . 36 11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . 35
11.1.2. record-aware Option Tag . . . . . . . . . . . . . . 36 11.1.2. record-aware Option Tag . . . . . . . . . . . . . . 36
11.2. Registration of media feature tags . . . . . . . . . . . 36 11.2. Registration of media feature tags . . . . . . . . . . . 36
11.2.1. src feature tag . . . . . . . . . . . . . . . . . . 36 11.2.1. src feature tag . . . . . . . . . . . . . . . . . . 36
11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . 37 11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . 36
11.3. New Content-Disposition Parameter Registrations . . . . 37 11.3. New Content-Disposition Parameter Registrations . . . . 37
11.4. Media Type Registration . . . . . . . . . . . . . . . . 37 11.4. Media Type Registration . . . . . . . . . . . . . . . . 37
11.4.1. Registration of MIME Type application/rs-metadata- 11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 37
request . . . . . . . . . . . . . . . . . . . . . . 37 11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . 37
11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 38
11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . 38
11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . 38 11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . 38
12. Security Considerations . . . . . . . . . . . . . . . . . . . 38 12. Security Considerations . . . . . . . . . . . . . . . . . . . 38
12.1. Authentication and Authorization . . . . . . . . . . . . 39 12.1. Authentication and Authorization . . . . . . . . . . . . 39
12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . 40 12.2. RTP handling . . . . . . . . . . . . . . . . . . . . . . 39
12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 40 12.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 40
12.4. Storage and playback . . . . . . . . . . . . . . . . . . 41 12.4. Storage and playback . . . . . . . . . . . . . . . . . . 40
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
14.1. Normative References . . . . . . . . . . . . . . . . . . 41 14.1. Normative References . . . . . . . . . . . . . . . . . . 41
14.2. Informative References . . . . . . . . . . . . . . . . . 42 14.2. Informative References . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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 with the architecture to a recording device. In accordance with the architecture
[RFC7245], the Session Recording Protocol specifies the use of SIP, [RFC7245], the Session Recording Protocol specifies the use of SIP,
SDP, and RTP to establish a Recording Session (RS) between the SDP, and RTP to establish a Recording Session (RS) between the
Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Client (SRC), which is on the path of the CS, and a
Session Recording Server (SRS) at the recording device. SIP is also Session Recording Server (SRS) at the recording device. SIP is also
skipping to change at page 33, line 13 skipping to change at page 33, line 13
SRC in the initial INVITE request: SRC in the initial INVITE request:
INVITE sip:recorder@example.com SIP/2.0 INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
CSeq: 101 INVITE CSeq: 101 INVITE
Max-Forwards: 70 Max-Forwards: 70
Require: siprec Require: siprec
Accept: application/sdp, application/rs-metadata-request Accept: application/sdp, application/rs-metadata
Contact: <sip:2000@src.example.com>;+sip.src Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length] Content-Length: [length]
--foobar --foobar
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=SRS 2890844526 2890844526 IN IP4 198.51.100.1 o=SRS 2890844526 2890844526 IN IP4 198.51.100.1
s=- s=-
skipping to change at page 34, line 14 skipping to change at page 34, line 14
again even when a full metadata snapshot is requested. In order to again even when a full metadata snapshot is requested. In order to
avoid repeating the same error, the SRS can simply terminate the avoid repeating the same error, the SRS can simply terminate the
recording session when a syntax error or semantic error is detected recording session when a syntax error or semantic error is detected
in the metadata. in the metadata.
The SRS MAY explicitly request a full metadata snapshot by sending an The SRS MAY explicitly request a full metadata snapshot by sending an
UPDATE request. This request MUST contain a body with content UPDATE request. This request MUST contain a body with content
disposition type "recording-session", and MUST NOT contain an SDP disposition type "recording-session", and MUST NOT contain an SDP
body. The SRS MUST NOT request a full metadata snapshot in an UPDATE body. The SRS MUST NOT request a full metadata snapshot in an UPDATE
response or in any other SIP transaction. The format of the content response or in any other SIP transaction. The format of the content
is "application/rs-metadata-request", and the body format is a simple is "application/rs-metadata", and the body is an XML document, the
text-based format. The following shows an example: format of which is defined in [I-D.ietf-siprec-metadata]. The
following shows an example:
UPDATE sip:2000@src.exmaple.com SIP/2.0 UPDATE sip:2000@src.exmaple.com SIP/2.0
Via: SIP/2.0/UDP srs.example.com;branch=z9hG4bKdf6b622b648d9 Via: SIP/2.0/UDP srs.example.com;branch=z9hG4bKdf6b622b648d9
To: <sip:2000@exmaple.com>;tag=35e195d2-947d-4585-946f-098392474 To: <sip:2000@exmaple.com>;tag=35e195d2-947d-4585-946f-098392474
From: <sip:recorder@example.com>;tag=1234567890 From: <sip:recorder@example.com>;tag=1234567890
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
CSeq: 1 UPDATE CSeq: 1 UPDATE
Max-Forwards: 70 Max-Forwards: 70
Require: siprec Require: siprec
Contact: <sip:recorder@srs.example.com>;+sip.srs Contact: <sip:recorder@srs.example.com>;+sip.srs
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
Content-Length: [length] Content-Length: [length]
SRS internal error <?xml version="1.0" encoding="UTF-8"?>
<requestsnapshot xmlns='urn:ietf:params:xml:ns:recording:1'>
<requestreason xml:lang="it">SRS internal error</requestreason>
</requestsnapshot>
Figure 13: Metadata Request Figure 13: Metadata Request
Note that UPDATE was chosen for the SRS to request metadata snapshot Note that UPDATE was chosen for the SRS to request metadata snapshot
because it can be sent regardless of the state of the dialog. This because it can be sent regardless of the state of the dialog. This
was seen as better than requiring support for both UPDATE and re- was seen as better than requiring support for both UPDATE and re-
INVITE for this operation. INVITE for this operation.
When the SRC receives a request for a metadata snapshot, it MUST When the SRC receives a request for a metadata snapshot, it MUST
immediately provide a full metadata snapshot in a separate INVITE or immediately provide a full metadata snapshot in a separate INVITE or
skipping to change at page 35, line 8 skipping to change at page 35, line 13
dependent on any metadata sent prior to this full metadata snapshot. dependent on any metadata sent prior to this full metadata snapshot.
The metadata received by the SRS can contain ID elements used to The metadata received by the SRS can contain ID elements used to
cross reference one element to another. An element containing the cross reference one element to another. An element containing the
definition of an ID, and an element containing a reference to that ID definition of an ID, and an element containing a reference to that ID
will often be received from the same SRC. It is also valid for those will often be received from the same SRC. It is also valid for those
elements to be received from different SRCs, for example, when each elements to be received from different SRCs, for example, when each
endpoint in the same CS act as an SRC to record the call and a common endpoint in the same CS act as an SRC to record the call and a common
ID refers to the same CS. The SRS MUST NOT consider this an error. ID refers to the same CS. The SRS MUST NOT consider this an error.
9.2.1. Formal Syntax
The formal syntax for the application/rs-metadata-request MIME is
described below using the Augmented Backus-Naur Form (ABNF) as
described in [RFC5234].
snapshot-request = srs-reason-line CRLF
srs-reason-line = [TEXT-UTF8-TRIM]
; TEXT-UTF8-TRIM defined in RFC 3261
10. Persistent Recording 10. Persistent Recording
Persistent recording is a specific use case outlined in REQ-005 or Persistent recording is a specific use case outlined in REQ-005 or
Use Case 4 in [RFC6341], where a recording session can be established Use Case 4 in [RFC6341], where a recording session can be established
in the absence of a communication session. The SRC continuously in the absence of a communication session. The SRC continuously
records media in a recording session to the SRS even in the absence records media in a recording session to the SRS even in the absence
of a CS for all user agents that are part of persistent recording. of a CS for all user agents that are part of persistent recording.
By allocating recorded streams and continuously sending recorded By allocating recorded streams and continuously sending recorded
media to the SRS, the SRC does not have to prepare new recorded media to the SRS, the SRC does not have to prepare new recorded
streams with a new SDP offer when a new communication session is streams with a new SDP offer when a new communication session is
skipping to change at page 37, line 42 skipping to change at page 37, line 35
recording-session: The body describes either: recording-session: The body describes either:
* metadata about the recording session * metadata about the recording session
* reason for metadata snapshot request * reason for metadata snapshot request
as determined by the MIME value indicated in the Content-Type. as determined by the MIME value indicated in the Content-Type.
11.4. Media Type Registration 11.4. Media Type Registration
11.4.1. Registration of MIME Type application/rs-metadata-request
This document registers the application/rs-metadata-request MIME
media type in order to describe a recording session metadata snapshot
request. This media type is defined by the following information:
Media type name: application
Media subtype name: rs-metadata-request
Required parameters: none
Options parameters: none
11.5. SDP Attributes 11.5. SDP Attributes
This document registers the following new SDP attributes. This document registers the following new SDP attributes.
11.5.1. 'record' SDP Attribute 11.5.1. 'record' SDP Attribute
Contact names: Leon Portman leon.portman@gmail.com, Henry Lum Contact names: Leon Portman leon.portman@gmail.com, Henry Lum
henry.lum@genesyslab.com henry.lum@genesyslab.com
Attribute name: record Attribute name: record
skipping to change at page 39, line 10 skipping to change at page 38, line 39
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 mechanisms available for securing the session existing SIP security mechanisms available for securing the session
signaling, the recorded media, and the metadata. The use cases and signaling, the recorded media, and the metadata. The use cases and
requirements document [RFC6341] outlines the general security requirements document [RFC6341] outlines the general security
considerations, and this document describes specific security considerations, and this document describes specific security
recommendations. recommendations.
The SRC and SRS MUST support SIP with TLS version 1.2, SHOULD follow The SRC and SRS MUST support SIP with TLS version 1.2, SHOULD follow
the best practices when using TLS as per [RFC7525], and MAY use SIPS the best practices when using TLS as per [RFC7525], and MAY use SIPS
with TLS as per [RFC5630]. The Recording Session SHOULD be at least with TLS as per [RFC5630]. The Recording Session MUST be at least as
as secure as the Communication Session, meaning using at least the secure as the Communication Session, meaning using at least the same
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 signaling and RTP/SAVP for media, example, if the CS uses SIPS for signaling and RTP/SAVP for media,
then the RS SHOULD NOT downgrade the level of security in the RS to then the RS may not use SIP or plain RTP unless other equivalent
SIP or plain RTP since doing so will mean an effective security security measures are in effect, since doing so would mean an
downgrade for the CS. In deployments where the SRC and the SRS are effective security downgrade. Examples of other potentially
in the same administrative domain and the same physical switch that equivalent security mechanisms include mutually-authenticated TLS for
prevents outside user access, some SRCs may choose to lower the level the RS signaling channel or an appropriately protected network path
of security when establishing a recording session. While physically for the RS media component.
securing the SRC and SRS may prevent an outside attacker from
accessing important call recordings, this still does not prevent an
inside attacker from accessing the internal network to gain access to
the call recordings.
12.1. Authentication and Authorization 12.1. Authentication and Authorization
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. Whether the SRC/SRS chooses to use TLS mutual recording session. Whether the SRC/SRS chooses to use TLS mutual
authentication is a deployment decision. In deployments where a UA authentication is a deployment decision. In deployments where a UA
acts as its own SRC, this requires the UA have its own certificate as acts as its own SRC, this requires the UA have its own certificate as
needed for TLS mutual authentication. In deployments where the SRC needed for TLS mutual authentication. In deployments where the SRC
skipping to change at page 40, line 25 skipping to change at page 40, line 4
between the SRC and the 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 the SRC important element in the overall SIPREC solution; therefore the SRC
and the SRS MUST support RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124]. and the SRS MUST support RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124].
RTP/SAVP and RTP/SAVPF provide media encryption, integrity RTP/SAVP and RTP/SAVPF provide media encryption, integrity
protection, replay protection, and a limited form of source protection, replay protection, and a limited form of source
authentication. They do not contain or require a specific keying authentication. They do not contain or require a specific keying
mechanism. At a minimum, the SRC and SRS MUST support the SDP mechanism. At a minimum, the SRC and SRS MUST support the SDP
Security Descriptions (SDES) key negotiation mechanism [RFC4568]. Security Descriptions (SDES) key negotiation mechanism [RFC4568].
For cases in which DTLS-SRTP is used to encrypt a CS media stream, an For cases in which DTLS-SRTP is used to encrypt a CS media stream, an
SRC may use SRTP Encrypted Key Transport (EKT) SRC may use SRTP Encrypted Key Transport (EKT)
[I-D.ietf-avtcore-srtp-ekt] in order to use SRTP-SDES in the RS [I-D.ietf-avtcore-srtp-ekt] in order to use SRTP-SDES in the RS
without needing to re-encrypt the media. without needing to re-encrypt the media.
Note: When using EKT in this manner, it is possible for
participants in the CS to send traffic that appears to be from
other participants and have this forwarded by the SRC to the SRS
within the RS. If this is a concern (e.g. the RS is intended for
audit or compliance purposes), EKT is not an appropriate choice.
When RTP/SAVP or RTP/SAVPF is used, an SRC can choose to use the same When RTP/SAVP or RTP/SAVPF is used, an SRC can choose to use the same
or different keys in the RS than the ones used in the CS. Some SRCs or different keys in the RS than the ones used in the CS. Some SRCs
are designed to simply replicate RTP packets from a CS media stream are designed to simply replicate RTP packets from a CS media stream
to the SRS, in which case the SRC will use the same key in the RS as to the SRS, in which case the SRC will use the same key in the RS as
used in the CS. In this case, the SRC MUST secure the SDP containing used in the CS. In this case, the SRC MUST secure the SDP containing
the keying material in the RS with at least the same level of the keying material in the RS with at least the same level of
security as in the CS. The risk of lowering the level of security in security as in the CS. The risk of lowering the level of security in
the RS is that it will effectively become a downgrade attack on the the RS is that it will effectively become a downgrade attack on the
CS since the same key is used for both CS and RS. CS since the same key is used for both CS and RS.
skipping to change at page 41, line 32 skipping to change at page 41, line 19
Muthu Perumal, Dan Wing, and Magnus Westerlund for their valuable Muthu Perumal, Dan Wing, and Magnus Westerlund for their valuable
comments and inputs to this document. comments and inputs to this document.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-siprec-metadata] [I-D.ietf-siprec-metadata]
R, R., Ravindran, P., and P. Kyzivat, "Session Initiation R, R., Ravindran, P., and P. Kyzivat, "Session Initiation
Protocol (SIP) Recording Metadata", draft-ietf-siprec- Protocol (SIP) Recording Metadata", draft-ietf-siprec-
metadata-17 (work in progress), February 2015. metadata-18 (work in progress), August 2015.
[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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
DOI 10.17487/RFC2506, March 1999,
<http://www.rfc-editor.org/info/rfc2506>.
[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. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[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, June with Session Description Protocol (SDP)", RFC 3264,
2002. DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[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, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[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,
DOI 10.17487/RFC3840, August 2004,
<http://www.rfc-editor.org/info/rfc3840>.
[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,
DOI 10.17487/RFC4574, August 2006,
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax <http://www.rfc-editor.org/info/rfc4574>.
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC7245] Hutton, A., Portman, L., Jain, R., and K. Rehor, "An [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
Architecture for Media Recording Using the Session "An Architecture for Media Recording Using the Session
Initiation Protocol", RFC 7245, May 2014. Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May
2014, <http://www.rfc-editor.org/info/rfc7245>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-avtcore-srtp-ekt] [I-D.ietf-avtcore-srtp-ekt]
Mattsson, J., McGrew, D., and D. Wing, "Encrypted Key Mattsson, J., McGrew, D., and D. Wing, "Encrypted Key
Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-03 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-03
(work in progress), October 2014. (work in progress), October 2014.
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May [RFC2804] IAB and , "IETF Policy on Wiretapping", RFC 2804,
2000. DOI 10.17487/RFC2804, May 2000,
<http://www.rfc-editor.org/info/rfc2804>.
[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, DOI 10.17487/RFC3311, October
2002, <http://www.rfc-editor.org/info/rfc3311>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. DOI 10.17487/RFC3325, November 2002,
<http://www.rfc-editor.org/info/rfc3325>.
[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. DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>.
[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, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[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, DOI 10.17487/RFC4568, July 2006,
<http://www.rfc-editor.org/info/rfc4568>.
[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, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
2006. DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007. Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
2007, <http://www.rfc-editor.org/info/rfc4916>.
[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, DOI 10.17487/RFC4961, July 2007,
<http://www.rfc-editor.org/info/rfc4961>.
[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, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[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, DOI 10.17487/RFC5124, February
2008, <http://www.rfc-editor.org/info/rfc5124>.
[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, DOI 10.17487/RFC5168, March
2008, <http://www.rfc-editor.org/info/rfc5168>.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, October 2009. Initiation Protocol (SIP)", RFC 5630,
DOI 10.17487/RFC5630, October 2009,
<http://www.rfc-editor.org/info/rfc5630>.
[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,
DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>.
[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,
DOI 10.17487/RFC6263, June 2011,
<http://www.rfc-editor.org/info/rfc6263>.
[RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use [RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain,
Cases and Requirements for SIP-Based Media Recording "Use Cases and Requirements for SIP-Based Media Recording
(SIPREC)", RFC 6341, August 2011. (SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011,
<http://www.rfc-editor.org/info/rfc6341>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013. Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015. (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
Authors' Addresses Authors' Addresses
Leon Portman Leon Portman
NICE Systems NICE Systems
22 Zarhin Street 22 Zarhin Street
P.O. Box 690 P.O. Box 690
Ra'anana 4310602 Ra'anana 4310602
Israel Israel
Email: leon.portman@gmail.com Email: leon.portman@gmail.com
Henry Lum (editor) Henry Lum (editor)
 End of changes. 49 change blocks. 
104 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/