draft-ietf-siprec-protocol-03.txt   draft-ietf-siprec-protocol-04.txt 
SIPREC L. Portman, Ed. 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: September 8, 2012 Genesys Expires: November 9, 2012 Genesys
C. Eckel
Cisco
A. Johnston A. Johnston
Avaya Avaya
A. Hutton A. Hutton
Siemens Enterprise Siemens Enterprise
Communications Communications
March 07, 2012 May 08, 2012
Session Recording Protocol Session Recording Protocol
draft-ietf-siprec-protocol-03 draft-ietf-siprec-protocol-04
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 43 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 September 8, 2012. This Internet-Draft will expire on November 9, 2012.
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 31 skipping to change at page 2, line 32
4.1. Delivering recorded media . . . . . . . . . . . . . . . . 5 4.1. Delivering recorded media . . . . . . . . . . . . . . . . 5
4.2. Delivering recording metadata . . . . . . . . . . . . . . 7 4.2. Delivering recording metadata . . . . . . . . . . . . . . 7
5. Initiating a Recording Session . . . . . . . . . . . . . . . . 8 5. Initiating a Recording Session . . . . . . . . . . . . . . . . 8
5.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 8 5.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 8
5.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 9 5.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 9
6. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. SDP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 9 6.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 9
6.1.1. Handling media stream updates . . . . . . . . . . . . 11 6.1.1. Handling media stream updates . . . . . . . . . . . . 11
6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 11 6.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 11
7. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. RTP Handling . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 12 7.1.1. SRC acting as an RTP Translator . . . . . . . . . . . 13
8.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 14 7.1.1.1. Forwarding Translator . . . . . . . . . . . . . . 13
8.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 16 7.1.1.2. Transcoding Translator . . . . . . . . . . . . . . 14
9. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 16 7.1.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . . 15
10. Extensions for Recording-aware User Agents . . . . . . . . . . 16 7.1.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . 15
10.1. Procedures at the record-aware user agent . . . . . . . . 17 7.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1.1. Recording preference . . . . . . . . . . . . . . . . . 17 7.3. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . 16
10.2. Procedures at the SRC . . . . . . . . . . . . . . . . . . 18 7.4. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2.1. Recording indication . . . . . . . . . . . . . . . . . 18 7.5. CSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2.2. Recording preference . . . . . . . . . . . . . . . . . 20 7.6. SDES . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7.6.1. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Registration of Option Tags . . . . . . . . . . . . . . . 20 7.7. Keepalive . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 20 7.8. RTCP Feedback Messages . . . . . . . . . . . . . . . . . . 18
11.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 20 7.8.1. Full Intra Request . . . . . . . . . . . . . . . . . . 18
11.2. Registration of media feature tags . . . . . . . . . . . . 20 7.8.1.1. SIP INFO for FIR . . . . . . . . . . . . . . . . . 18
11.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 21 7.8.2. Picture Loss Indicator . . . . . . . . . . . . . . . . 18
11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 21 7.8.3. Temporary Maximum Media Stream Bit Rate Request . . . 19
11.3. New Content-Disposition Parameter Registrations . . . . . 22 7.8.3.1. Renegotiation of SDP bandwidth attribute . . . . . 19
11.4. Media Type Registration . . . . . . . . . . . . . . . . . 22
11.4.1. Registration of MIME Type application/rs-metadata . . 22 7.9. Symmetric RTP/RTCP for Sending and Receiving . . . . . . . 19
8. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Procedures at the SRC . . . . . . . . . . . . . . . . . . 20
8.2. Procedures at the SRS . . . . . . . . . . . . . . . . . . 21
8.2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . 23
9. Persistent Recording . . . . . . . . . . . . . . . . . . . . . 23
10. Extensions for Recording-aware User Agents . . . . . . . . . . 23
10.1. Procedures at the record-aware user agent . . . . . . . . 24
10.1.1. Recording preference . . . . . . . . . . . . . . . . . 24
10.2. Procedures at the SRC . . . . . . . . . . . . . . . . . . 25
10.2.1. Recording indication . . . . . . . . . . . . . . . . . 25
10.2.2. Recording preference . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11.1. Registration of Option Tags . . . . . . . . . . . . . . . 27
11.1.1. siprec Option Tag . . . . . . . . . . . . . . . . . . 27
11.1.2. record-aware Option Tag . . . . . . . . . . . . . . . 27
11.2. Registration of media feature tags . . . . . . . . . . . . 27
11.2.1. src feature tag . . . . . . . . . . . . . . . . . . . 28
11.2.2. srs feature tag . . . . . . . . . . . . . . . . . . . 28
11.3. New Content-Disposition Parameter Registrations . . . . . 29
11.4. Media Type Registration . . . . . . . . . . . . . . . . . 29
11.4.1. Registration of MIME Type application/rs-metadata . . 29
11.4.2. Registration of MIME Type 11.4.2. Registration of MIME Type
application/rs-metadata-request . . . . . . . . . . . 22 application/rs-metadata-request . . . . . . . . . . . 29
11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 22 11.5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 29
11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 22 11.5.1. 'record' SDP Attribute . . . . . . . . . . . . . . . . 29
11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 23 11.5.2. 'recordpref' SDP Attribute . . . . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12.1. Authentication and Authorization . . . . . . . . . . . . . 23 12.1. RTP handling . . . . . . . . . . . . . . . . . . . . . . . 30
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 12.2. Authentication and Authorization . . . . . . . . . . . . . 31
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14.2. Informative References . . . . . . . . . . . . . . . . . . 25 14.1. Normative References . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This document specifies the mechanism to record a Communication This document specifies the mechanism to record a Communication
Session (CS) by delivering real-time media and metadata from the CS Session (CS) by delivering real-time media and metadata from the CS
to a recording device. In accordance to the architecture to a recording device. In accordance to the architecture
[I-D.ietf-siprec-architecture], the Session Recording Protocol [I-D.ietf-siprec-architecture], the Session Recording Protocol
specifies the use of SIP, SDP, and RTP to establish a Recording specifies the use of SIP, SDP, and RTP to establish a Recording
Session (RS) between the Session Recording Client (SRC), which is on Session (RS) between the Session Recording Client (SRC), which is on
the path of the CS, and a Session Recording Server (SRS) at the the path of the CS, and a Session Recording Server (SRS) at the
skipping to change at page 4, line 28 skipping to change at page 4, line 28
that describes recorded media and the CS to which they relate. that describes recorded media and the CS to which they relate.
The Session Recording Protocol intends to satisfy the SIP-based Media The Session Recording Protocol intends to satisfy the SIP-based Media
Recording requirements listed in [RFC6341]. Recording requirements listed in [RFC6341].
2. Definitions 2. Definitions
This document refers to the core definitions provided in the This document refers to the core definitions provided in the
architecture document [I-D.ietf-siprec-architecture]. architecture document [I-D.ietf-siprec-architecture].
The RTP Handling section uses the definitions provided in "RTP: A
Transport Protocol for Real-Time Application" [RFC3550].
3. Scope 3. Scope
The scope of the Session Recording Protocol includes the The scope of the Session Recording Protocol includes the
establishment of the recording sessions and the reporting of the establishment of the recording sessions and the reporting of the
metadata. The scope also includes extensions supported by User metadata. The scope also includes extensions supported by User
Agents participating in the CS such as indication of recording. The Agents participating in the CS such as indication of recording. The
user agents need not be recording-aware in order to participate in a user agents need not be recording-aware in order to participate in a
CS being recorded. CS being recorded.
The following items, which are not an exhaustive list, do not The following items, which are not an exhaustive list, do not
skipping to change at page 12, line 34 skipping to change at page 12, line 34
| ... | | ... |
|(8) BYE | |(8) BYE |
|---------------------------------------------------->| |---------------------------------------------------->|
| (9) OK | | (9) OK |
|<----------------------------------------------------| |<----------------------------------------------------|
Figure 5: SRS responding to offer with a=inactive Figure 5: SRS responding to offer with a=inactive
7. RTP Handling 7. RTP Handling
This is a placeholder section to specify any protocol impacts or This section provides recommendations and guidelines for RTP and RTCP
recommendations for RTP usage in the session recording protocol. The in the context of SIPREC. In order to communicate most effectively,
details are listed in [I-D.eckel-siprec-rtp-rec] the Session Recording Client (SRC) and the Session Recording Server
(SRS) SHOULD utilize the mechanisms provided by RTP in a well defined
and predicable manner. It is the goal of this document to make the
reader aware of these mechanisms and provide recommendations and
guidelines.
8. Metadata 7.1. Roles
An SRC has the task of gathering media from the various UAs in a
Communication Session (CS) and forwarding the information to the SRS
within the context of a Recording Session (RS). There are numerous
ways in which an SRC may do this is, including appearing as one of
the UAs within a CS, or as a B2BUA between UAs within a CS.
SRS
^
|
RS
|
v
UA <-- CS --> SRC
Figure 1: UA as SRC
SRS
^
|
RS
|
v
UA1 <-- CS --> SRC <-- CS --> UA2
Figure 2: B2BUA as SRC
The following subsections define a set of roles an SRC may choose to
play based on its position with respect to a UA within a CS, and an
SRS within an RS.
7.1.1. SRC acting as an RTP Translator
The SRC may act as a translator, as defined in [RFC3550]. A defining
characteristic of a translator is that it forwards RTP packets with
their SSRC identifier intact. There are two types of translators,
one that simply forwards, and another that performs transcoding
(e.g., from one codec to another) in addition to forwarding.
7.1.1.1. Forwarding Translator
When acting as a forwarding translator, RTP received as separate
streams from different sources (e.g., from different UAs with
different SSRCs) cannot be mixed by the SRC and MUST be sent
separately to the SRS. All RTCP reports MUST be passed by the SRC
between the UAs and the SRS, such that the UAs and SRS are able to
detect any SSRC collisions.
RTCP Sender Reports generated by a UA sending a stream MUST be
forwarded to the SRS. RTCP Receiver Reports generated by the SRS
MUST be forwarded to the relevant UA.
UAs may receive multiple sets of RTCP Receiver Reports, one or more
from other UAs participating in the CS, and one from the SRS
participating in the RS. A SIPREC aware UA SHOULD be prepared to
process the RTCP Receiver Reports from the SRS, whereas a SIPREC
unaware UA may discard such RTCP packets as not of relevance.
If SRTP is used on both the CS and the RS, decryption and/or re-
encryption may occur. For example, if different keys are used, it
will occur. If the same keys are used, it need not occur.
If packet loss occurs, either from the UA to the SRC or from the SRC
to the SRS, the SRS SHOULD detect and attempt to recover from the
loss. The SRC does not play a role in this other than forwarding the
associated RTP and RTCP packets.
7.1.1.2. Transcoding Translator
When acting as a transcoding translator, an SRC MAY perform
transcoding (e.g., from one codec to another), and this may result in
a different rate of packets between what the SRC receives and what
the sends. As when acting as a forwarding translator, RTP received
as separate streams from different sources (e.g., from different UAs
with different SSRCs) cannot be mixed by the SRC and MUST be sent
separately to the SRS. All RTCP reports MUST passed by the SRC
between the UAs and the SRS, such the UAs and SRS they are able to
detect any SSRC collisions.
RTCP Sender Reports generated by a UA sending a stream MUST be
forwarded to the SRS. RTCP Receiver Reports generated by the SRS
MUST be forwarded to the relevant UA. The SRC may need to manipulate
the RTCP Receiver Reports to take account of any transcoding that has
taken place.
UAs may receive multiple sets of RTCP Receiver Reports, one or more
from other UAs participating in the CS, and one from the SRS
participating in the RS. A SIPREC aware UA SHOULD be prepared to
process the RTCP Receiver Reports from the SRS, whereas a SIPREC
unaware UA may discard such RTCP packets as not of relevance.
If SRTP is used on both the CS and the RS, decryption and/or re-
encryption may occur. For example, if different keys are used, it
will occur. If the same keys are used, it need not occur.
If packet loss occurs, either from the UA to the SRC or from the SRC
to the SRS, the SRS SHOULD detect and attempt to recover from the
loss. The SRC does not play a role in this other than forwarding the
associated RTP and RTCP packets.
7.1.2. SRC acting as an RTP Mixer
In the case of the SRC acting as a RTP mixer, as defined in
[RFC3550], the SRC combines RTP streams from different UA and sends
them towards the SRS using its own SSRC. The SSRCs from the
contributing UA SHOULD be conveyed as CSRCs identifiers within this
stream. The SRC may make timing adjustments among the received
streams and generate its own timing on the stream sent to the SRS.
Optionally an SRC acting as a mixer can perform transcoding, and can
even cope with different codings received from different UAs. RTCP
Sender Reports and Receiver Reports are not forwarded by an SRC
acting as mixer, but there are requirements for forwarding RTCP
Source Description (SDES) packets. The SRC generates its own RTCP
Sender and Receiver reports toward the associated UAs and SRS. The
use of SRTP between the SRC and the SRS for the RS is independent of
the use of SRTP between the UAs and SRC for the CS.
If packet loss occurs from the UA to the SRC, the SRC SHOULD detect
and attempt to recover from the loss. If packet loss occurs from the
SRC to the SRS, the SRS SHOULD detect and attempt to recover from the
loss.
7.1.3. SRC acting as an RTP Endpoint
The case of the SRC acting as an RTP endpoint, as defined in
[RFC3550], is similar to the mixer case, except that the RTP session
between the SRC and the SRS is considered completely independent from
the RTP session that is part of the CS. The SRC can, but need not,
mix RTP streams from different participants prior to sending to the
SRS. RTCP between the SRC and the SRS is completely independent of
RTCP on the CS. The use of SRTP between the SRC and the SRS is
independent of the use of SRTP on the CS.
If packet loss occurs from the UA to the SRC, the SRC SHOULD detect
and attempt to recover from the loss. If packet loss occurs from the
SRC to the SRS, the SRS SHOULD detect and attempt to recover from the
loss.
7.2. RTCP
The RTP data transport is augmented by a control protocol (RTCP) to
allow monitoring of the data delivery. RTCP, as defined in
[RFC3550], is based on the periodic transmission of control packets
to all participants in the RTP session, using the same distribution
mechanism as the data packets. Support for RTCP is REQUIRED, per
[RFC3550], and it provides, among other things, the following
important functionality in relation to SIPREC:
1) Feedback on the quality of the data distribution
This feedback from the receivers may be used to diagnose faults in
the distribution. As such, RTCP is a well defined and efficient
mechanism for the SRS to inform the SRC of issues that arise with
respect to its reception of media that is to be recorded.
2) Carries a persistent transport-level identifier for an RTP source
called the canonical name or CNAME
The SSRC identifier may change if a conflict is discovered or a
program is restarted; in which case receivers can use the CNAME to
keep track of each participant. Receivers may also use the CNAME to
associate multiple data streams from a given participant in a set of
related RTP sessions, for example to synchronize audio and video.
Synchronization of media streams is also facilitated by the NTP and
RTP timestamps included in RTCP packets by data senders.
7.3. RTP Profile
The RECOMMENDED RTP profiles for both the SRC and SRS are "Extended
Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-
Based Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP
streams, and "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non
encrypted media streams. However, as this is not a requirement, some
implementations may use "The Secure Real-time Transport Protocol
(SRTP)", [RFC3711] and "RTP Profile for Audio and Video Conferences
with Minimal Control", AVP [RFC3551]. Therefore, it is RECOMMENDED
that the SRC and SRS not rely entirely on SAVPF or AVPF for core
functionality that may be at least partially achievable using SAVP
and AVP.
AVPF and SAVPF provide an improved RTCP timer model that allows more
flexible transmission of RTCP packets as response to events, rather
than strictly according to bandwidth. AVPF based codec control
messages provide efficient mechanisms for an SRC and SRS to handle
events such as scene changes, error recovery, and dynamic bandwidth
adjustments. These messages are discussed in more detail later in
this document.
SAVP and SAVPF provide media encryption, integrity protection, replay
protection, and a limited form of source authentication. They do not
contain or require a specific keying mechanism.
7.4. SSRC
The synchronization source (SSRC), as defined in [RFC3550], is
carried in the RTP header and in various fields of RTCP packets. It
is a random 32-bit number that is required to be globally unique
within an RTP session. It is crucial that the number be chosen with
care in order that participants on the same network or starting at
the same time are not likely to choose the same number. Guidelines
regarding SSRC value selection and conflict resolution are provided
in [RFC3550].
The SSRC may also be used to separate different sources of media
within a single RTP session. For this reason as well as for conflict
resolution, it is important that the SRC and SRS handle changes in
SSRC values and properly identify the reason of the change. The
CNAME values carried in RTCP facilitate this identification.
7.5. CSRC
The contributing source (CSRC), as defined in [RFC3550], identifies
the source of a stream of RTP packets that has contributed to the
combined stream produced by an RTP mixer. The mixer inserts a list
of the SSRC identifiers of the sources that contributed to the
generation of a particular packet into the RTP header of that packet.
This list is called the CSRC list. It is RECOMMENDED that a SRC,
when acting a mixer, sets the CSRC list accordingly, and that the SRS
interprets the CSRC list appropriately when received.
7.6. SDES
The Source Description (SDES), as defined in [RFC3550], contains an
SSRC/CSRC identifier followed by a list of zero or more items, which
carry information about the SSRC/CSRC. End systems send one SDES
packet containing their own source identifier (the same as the SSRC
in the fixed RTP header). A mixer sends one SDES packet containing a
chunk for each contributing source from which it is receiving SDES
information, or multiple complete SDES packets if there are more than
31 such sources.
7.6.1. CNAME
The Canonical End-Point Identifier (CNAME), as defined in [RFC3550],
provides the binding from the SSRC identifier to an identifier for
the source (sender or receiver) that remains constant. It is
important the an SRC and SRS generate CNAMEs appropriately and use
them for this purpose. Guidelines for generating CNAME values are
provided in "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)" [RFC6222].
7.7. Keepalive
It is anticipated that media streams in SIPREC may exist in inactive
states for extended periods of times for an of a number of valid
reasons. In order for the bindings and any pinholes in NATs/
firewalls to remain active during such intervals, it is RECOMMENDED
to follow the keep-alive procedure recommended in "Application
Mechanism for Keeping Alive the NAT Mappings Associated to RTP/RTP
Control Protocol (RTCP) Flows" [RFC6263] for all RTP media streams.
7.8. RTCP Feedback Messages
"Codec Control Messages in the RTP Audio-Visual Profile with Feedback
(AVPF)" [RFC5104] specifies extensions to the messages defined in
AVPF [RFC4585]. Support for and proper usage of these messages is
important to SRC and SRS implementations. Note that these messages
are applicable only when using the AVFP or SAVPF RTP profiles.
7.8.1. Full Intra Request
A Full Intra Request (FIR) Command, when received by the designate
media sender, requires that the media sender sends a Decoder Refresh
Point at the earliest opportunity. Using a decoder refresh point
implies refraining from using any picture sent prior to that point as
a reference for the encoding process of any subsequent picture sent
in the stream.
Decoder refresh points, especially Intra or IDR pictures for H.264
video codecs, are in general several times larger in size than
predicted pictures. Thus, in scenarios in which the available bit
rate is small, the use of a decoder refresh point implies a delay
that is significantly longer than the typical picture duration.
7.8.1.1. SIP INFO for FIR
"XML Schema for Media Control" [RFC5168] defines an Extensible Markup
Language (XML) Schema for video fast update. Implementations are
discouraged from using the method described except for backward
compatibility purposes. Implementations SHOULD use FIR messages
instead.
7.8.2. Picture Loss Indicator
Picture Loss Indication (PLI), as defined in [RFC4585], informs the
encoder of the loss of an undefined amount of coded video data
belonging to one or more pictures. Using the FIR command to recover
from errors is explicitly disallowed, and instead the PLI message
SHOULD be used. FIR SHOULD be used only in situations where not
sending a decoder refresh point would render the video usable for the
users. Examples where sending FIR is appropriate include a
multipoint conference when a new user joins the conference and no
regular decoder refresh point interval is established, and a video
switching MCU that changes streams.
7.8.3. Temporary Maximum Media Stream Bit Rate Request
A receiver, translator, or mixer uses the Temporary Maximum Media
Stream Bit Rate Request (TMMBR) to request a sender to limit the
maximum bit rate for a media stream to the provided value.
Appropriate use of TMMBR facilitates rapid adaptation to changes in
available bandwidth.
7.8.3.1. Renegotiation of SDP bandwidth attribute
If it is likely that the new value indicated by TMMBR will be valid
for the remainder of the session, the TMMBR sender is expected to
perform a renegotiation of the session upper limit using the session
signaling protocol. Therefore for SIPREC, implementations are
RECOMMENDED to use TMMBR for temporary changes, and renegotiation of
bandwidth via SDP offer/answer of more permanent changes.
7.9. Symmetric RTP/RTCP for Sending and Receiving
Within an SDP offer/answer exchange, RTP entities choose the RTP and
RTCP transport addresses (i.e., IP addresses and port numbers) on
which to receive packets. When sending packets, the RTP entities may
use the same source port or a different source port as those signaled
for receiving packets. When the transport address used to send and
receive RTP is the same, it is termed "symmetric RTP" [RFC4961].
Likewise, when the transport address used to send and receive RTCP is
the same, it is termed "symmetric RTCP" [RFC4961].
When sending RTP, it is REQUIRED to use symmetric RTP. When sending
RTCP, it is REQUIRED to use symmetric RTCP. Although an SRS will not
normally send RTP, it will send RTCP as well as receive RTP and RTCP.
Likewise, although an SRC will not normally receive RTP from the SRS,
it will receive RTCP as well as send RTP and RTCP.
Note: Symmetric RTP and symmetric RTCP are different from RTP/RTCP
multiplexing [RFC5761].
8. Metadata
8.1. Procedures at the SRC 8.1. Procedures at the SRC
The SRC is responsible to deliver metadata to the SRS in a recording The SRC is responsible to deliver metadata to the SRS in a recording
session. Metadata can be provided by the SRC in the initial INVITE session. Metadata can be provided by the SRC in the initial INVITE
request when establishing the recording session, and subsequent request when establishing the recording session, and subsequent
metadata updates can be provided by the SRC in reINVITE and UPDATE metadata updates can be provided by the SRC in reINVITE and UPDATE
requests and responses in the recording session. requests and responses in the recording session.
Certain metadata attributes are contained in the SDP, and others are Certain metadata attributes are contained in the SDP, and others are
contained in a new content type "application/rs-metadata". The contained in a new content type "application/rs-metadata". The
skipping to change at page 23, line 41 skipping to change at page 30, line 41
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 recorded existing SIP security mechanism available for securing the recorded
media as well as metadata. Other security considerations are media as well as metadata. Other security considerations are
outlined in the use cases and requirements document [RFC6341]. outlined in the use cases and requirements document [RFC6341].
12.1. Authentication and Authorization 12.1. RTP handling
In many scenarios it will be critical that the media transported
between the SRC and SRS to be protected. Media encryption is an
important element in the overall SIPREC solution, therefore, it is
RECOMMENDED that SRC and SRS support RTP/SAVP [RFC3711] and RTP/SAVPF
[RFC5124]. RTP/SAVP and RTP/SAVPF provide media encryption,
integrity protection, replay protection, and a limited form of source
authentication. They do not contain or require a specific keying
mechanism.
12.2. Authentication and Authorization
The recording session reuses the SIP mechanism to challenge requests The recording session reuses the SIP mechanism to challenge requests
that is based on HTTP authentication. The mechanism relies on 401 that is based on HTTP authentication. The mechanism relies on 401
and 407 SIP responses as well as other SIP header fields for carrying and 407 SIP responses as well as other SIP header fields for carrying
challenges and credentials. challenges and credentials.
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.
13. Acknowledgements 13. Acknowledgements
We want to thank John Elwell, Paul Kyzivat, Partharsarathi R, Ram We want to thank John Elwell, Paul Kyzivat, Partharsarathi R, Ram
Mohan R, Charles Eckel, Hadriel Kaplan, Adam Roach, Miguel Garcia for Mohan R, Charles Eckel, Hadriel Kaplan, Adam Roach, Miguel Garcia for
their valuable comments and inputs to this document. their valuable comments and inputs to this document.
We also want to thank Andrew Hutton, Ram Mohan, Muthu Perumal, John
Elwell, Dan Wing, Hadriel Kaplan, Paul Kyzivat, and Magnus Westerlund
for their valuable contributions to the RTP Handling portion.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-siprec-metadata] [I-D.ietf-siprec-metadata]
Ravindran, P. and P. Kyzivat, "Session Initiation Protocol R, R., Ravindran, P., and P. Kyzivat, "Session Initiation
(SIP) Recording Metadata", draft-ietf-siprec-metadata-05 Protocol (SIP) Recording Metadata",
(work in progress), October 2011. draft-ietf-siprec-metadata-06 (work in progress),
March 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.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 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.
skipping to change at page 25, line 11 skipping to change at page 32, line 27
[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.
[RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use
Cases and Requirements for SIP-Based Media Recording Cases and Requirements for SIP-Based Media Recording
(SIPREC)", RFC 6341, August 2011. (SIPREC)", RFC 6341, August 2011.
14.2. Informative References 14.2. Informative References
[I-D.eckel-siprec-rtp-rec]
Eckel, C., "Real-time Transport Protocol (RTP)
Recommendations for SIPREC", draft-eckel-siprec-rtp-rec-03
(work in progress), October 2011.
[I-D.ietf-siprec-architecture] [I-D.ietf-siprec-architecture]
Portman, L., Rehor, K., Jain, R., and A. Hutton, "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-03 Initiation Protocol", draft-ietf-siprec-architecture-04
(work in progress), October 2011. (work in progress), March 2012.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags with [RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags with
the Session Initiation Protocol (SIP) REFER Method", the Session Initiation Protocol (SIP) REFER Method",
RFC 4508, May 2006. RFC 4508, May 2006.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents", (SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006. BCP 119, RFC 4579, August 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008.
[RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for
Media Control", RFC 5168, March 2008.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", RFC 6222, April 2011.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011. Control Protocol (RTCP) Flows", RFC 6263, June 2011.
Authors' Addresses Authors' Addresses
Leon Portman (editor) Leon Portman
NICE Systems NICE Systems
8 Hapnina 8 Hapnina
Ra'anana 43017 Ra'anana 43017
Israel Israel
Email: leon.portman@nice.com Email: leon.portman@nice.com
Henry Lum (editor) Henry Lum (editor)
Genesys Genesys
1380 Rodick Road, Suite 200 1380 Rodick Road, Suite 200
Markham, Ontario L3R4G5 Markham, Ontario L3R4G5
Canada Canada
Email: henry.lum@genesyslab.com Email: henry.lum@genesyslab.com
Charles Eckel
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States
Email: eckelcu@cisco.com
Alan Johnston Alan Johnston
Avaya Avaya
St. Louis, MO 63124 St. Louis, MO 63124
Email: alan.b.johnston@gmail.com Email: alan.b.johnston@gmail.com
Andrew Hutton Andrew Hutton
Siemens Enterprise Communications Siemens Enterprise Communications
Brickhill Street Brickhill Street
Milton Keynes MK15 0DJ Milton Keynes MK15 0DJ
 End of changes. 20 change blocks. 
54 lines changed or deleted 475 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/