SIPREC Working Group C. Eckel
Internet-Draft Cisco
Intended status: Informational June 13, 2011
Expires: December 15, 2011
Real-time Transport Protocol (RTP) Recommendations for SIPREC
draft-eckel-siprec-rtp-rec-00
Abstract
This document provides recommendations and guidelines for RTP and
RTCP in the context of SIPREC. This document exists as a standalone
document to faciliate dicussion of the RTP recommendations, and it is
anticipated that portions of this document will be incorporated into
[I-D.portman-siprec-protocol] rather than this document itself being
adopted as a working group document.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 15, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Eckel Expires December 15, 2011 [Page 1]
Internet-Draft RTP-for-SIPREC June 2011
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. SRC acting as an RTP Translator . . . . . . . . . . . . . 4
4.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . . . . 4
4.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . . . 5
5. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. CSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. SDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. CNAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
11. Keepalive . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12. RTCP Feedback Messages . . . . . . . . . . . . . . . . . . . . 7
12.1. Full Intra Request . . . . . . . . . . . . . . . . . . . . 7
12.1.1. SIP INFO for FIR . . . . . . . . . . . . . . . . . . 8
12.2. Picture Loss Indicator . . . . . . . . . . . . . . . . . . 8
12.3. Temporary Maximum Media Stream Bit Rate Request . . . . . 8
12.3.1. Renegotiation of SDP bandwidth attribute . . . . . . 8
13. Symmetric RTP/RTCP for Sending and Receiving . . . . . . . . . 8
14. Security Considerations . . . . . . . . . . . . . . . . . . . 9
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
17.1. Normative References . . . . . . . . . . . . . . . . . . . 9
17.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Eckel Expires December 15, 2011 [Page 2]
Internet-Draft RTP-for-SIPREC June 2011
1. Introduction
This document provides recommendations and guidelines for RTP and
RTCP in the context of SIPREC. In order to communicate most
effectively, the Session Recording Client (SRC) and the Session
Recording (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. This document is completely
informational. It includes no requirements and no normative
language. This document exists as a standalone document to faciliate
dicussion of the RTP recommendations, and it is anticipated that
portions of this document will be incorporated into
[I-D.portman-siprec-protocol] rather than this document itself being
adopted as a working group document.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Definitions
This document uses the definitions provided in
[I-D.ietf-siprec-architecture] for all SIPREC modules. A Session
Recording Client (SRC), as defined within SIPREC, is expected to
implement one or more of a variety of RTP roles within the context of
various SIPREC use cases. These roles include, but are not limited
to, acting as an end system, a mixer, or a translator. This document
uses the definitions provided in "RTP: A Transport Protocol for Real-
Time Application" [RFC3550].
4. Roles
An SRC has the task of gathering media from the various UAs in a CS
and forwarding the information to the SRS in the context of the RS.
For a given media stream, the SRC has a number of ways of doing this
and may choose different ways for different media streams. The
following subsections define a set of roles an SRC may choose to play
from the perspective of its position between a UA within a CS, and an
SRS within an RS.
Eckel Expires December 15, 2011 [Page 3]
Internet-Draft RTP-for-SIPREC June 2011
UA <-- CS --> SRC <-- RS --> SRS
Figure 1: SRC Positioning
4.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. Optionally, an SRC acting as a
translator can perform transcoding (e.g., from one codec to another),
and this can result in a different rate of packets. With this
approach, 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. More sepcifically,
the SRC cannot multiple RTP streams with different SSRCs into a
single RTP stream multiplexed by SSRC and/or CSRC. All RTCP reports
are passed by the SRC between the UAs and the SRS, such that 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
need to be forwarded to the relevant UA. This implies that the SRC
cannot take multiplex RTP packets with different SSRC values into a
single SSRC stream unless it was The SRC in the case may need to
manipulate the RTCP Receiver Reports to take account of any
transcoding that has taken place.
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
must occur. If the same keys are used, it need not occur.
4.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.
Eckel Expires December 15, 2011 [Page 4]
Internet-Draft RTP-for-SIPREC June 2011
4.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.
5. 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 by
[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
is important for flow and congestion control functions, and to get
feedback from the receivers to diagnose faults in the distribution.
As such, RTCP is a well defined and efficient mechanism for the SRS
to inform the SRC or any issues that arise in the 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.
6. 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
strgams, 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
Eckel Expires December 15, 2011 [Page 5]
Internet-Draft RTP-for-SIPREC June 2011
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. 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 SRC handle changes in
SSRC values and properly identify the reason of the change. The
CNAME values carried in RTCP facilitate this identification.
8. 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.
Eckel Expires December 15, 2011 [Page 6]
Internet-Draft RTP-for-SIPREC June 2011
9. 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.
10. 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].
11. 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 to the bindings and any pinholes in NATs/firewalls
to remain active during such intervals, it is recommended to follow
the keep-alive procedures in "Application Mechanism for keeping alive
the Network Address Translator (NAT) mappings associated to RTP/RTCP
flows" [I-D.ietf-avt-app-rtp-keepalive] for all RTP media streams.
12. 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.
12.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
Eckel Expires December 15, 2011 [Page 7]
Internet-Draft RTP-for-SIPREC June 2011
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.
12.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.
12.2. Picture Loss Indicator
Using the FIR command to recover from errors is explicitly
disallowed, and instead the PLI message defined in AVPF [RFC4585]
should be used. The PLI message reports lost pictures and has been
included in AVPF for precisely that purpose.
12.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.
12.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.
13. Symmetric RTP/RTCP for Sending and Receiving
Within the SDP offer/answer, RTP entities choose the RTP and RTCP
transport addresses (i.e., IP addresses and port numbers) on which to
receive packets. When sending RTP packets; however, they may use a
different IP address or port number for RTP, RTCP, or both.
Symmetric RTP/RTCP requires that the IP address and port number for
Eckel Expires December 15, 2011 [Page 8]
Internet-Draft RTP-for-SIPREC June 2011
sending and receiving RTP/RTCP packets are identical. Using
Symmetric RTP and RTCP, as defined in "Symmetric RTP / RTP Control
Protocol (RTCP)" [RFC4961] is recommended. It should not be confused
with, or used in place of, "Multiplexing RTP Data and Control Packets
on a Single Port" [RFC5761].
14. Security Considerations
In many scenarios it will be critical that the media transported
between the SRC and SRS using RTP/RTCP be protected. Media
encryption is an important elelement of the overall SIPREC solution.
The details regarding the encrption of the RTP/RTCP media will be
addressed in [I-D.portman-siprec-protocol].
15. IANA Considerations
None.
16. Acknowledgements
Thank you to Andrew Hutton, Ram Mohan, and Muthu Perumal for their
valuable contributions.
17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
17.2. Informative References
[I-D.ietf-avt-app-rtp-keepalive]
Marjou, X. and A. Sollaud, "Application Mechanism for
keeping alive the Network Address Translator (NAT)
mappings associated to RTP/RTCP flows.",
draft-ietf-avt-app-rtp-keepalive-10 (work in progress),
March 2011.
[I-D.ietf-siprec-architecture]
Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
Architecture for Media Recording using the Session
Initiation Protocol", draft-ietf-siprec-architecture-02
(work in progress), April 2011.
Eckel Expires December 15, 2011 [Page 9]
Internet-Draft RTP-for-SIPREC June 2011
[I-D.portman-siprec-protocol]
Portman, L., Lum, H., Johnston, A., and A. Hutton,
"Session Recording Protocol",
draft-portman-siprec-protocol-04 (work in progress),
May 2011.
[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.
[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.
Eckel Expires December 15, 2011 [Page 10]
Internet-Draft RTP-for-SIPREC June 2011
Author's Address
Charles Eckel
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States
Email: eckelcu@cisco.com
Eckel Expires December 15, 2011 [Page 11]