SIPREC Working Group C. Eckel
Internet-Draft Cisco
Intended status: Informational September 22, 2011
Expires: March 25, 2012
Real-time Transport Protocol (RTP) Recommendations for SIPREC
draft-eckel-siprec-rtp-rec-02
Abstract
This document provides recommendations and guidelines for RTP and
RTCP in the context of SIPREC. This document exists as a standalone
document to facilitate discussion of the RTP recommendations, and it
is anticipated that portions of this document will be incorporated
into [I-D.ietf-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 March 25, 2012.
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 March 25, 2012 [Page 1]
Internet-Draft RTP-for-SIPREC September 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.1.1. Forwarding Translator . . . . . . . . . . . . . . . . 4
4.1.2. Transcoding Translator . . . . . . . . . . . . . . . . 4
4.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . . . . 5
4.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . . . 5
5. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. CSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. SDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. CNAME . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Keepalive . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11. RTCP Feedback Messages . . . . . . . . . . . . . . . . . . . . 8
11.1. Full Intra Request . . . . . . . . . . . . . . . . . . . . 8
11.1.1. SIP INFO for FIR . . . . . . . . . . . . . . . . . . . 9
11.2. Picture Loss Indicator . . . . . . . . . . . . . . . . . . 9
11.3. Temporary Maximum Media Stream Bit Rate Request . . . . . 9
11.3.1. Renegotiation of SDP bandwidth attribute . . . . . . . 9
12. Symmetric RTP/RTCP for Sending and Receiving . . . . . . . . . 9
13. Security Considerations . . . . . . . . . . . . . . . . . . . 10
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
16.1. Normative References . . . . . . . . . . . . . . . . . . . 10
16.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Eckel Expires March 25, 2012 [Page 2]
Internet-Draft RTP-for-SIPREC September 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 exists as a standalone document to facilitate
discussion of the RTP recommendations, and it is anticipated that
portions of this document will be incorporated into
[I-D.ietf-siprec-protocol] rather than this document itself being
adopted as a working group document. This document makes use of
normative language as it is expected to exist within the working
group document into which it is eventually incorporated.
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 within the context of an
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.
Eckel Expires March 25, 2012 [Page 3]
Internet-Draft RTP-for-SIPREC September 2011
UA <-- CS --> SRC <-- RS --> SRS
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.
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. There are two types of translators,
one that simply forward, and another that performs transcoding (e.g.,
from one codec to another) in addition to forwarding.
4.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.
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.
4.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
Eckel Expires March 25, 2012 [Page 4]
Internet-Draft RTP-for-SIPREC September 2011
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.
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.
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.
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.
Eckel Expires March 25, 2012 [Page 5]
Internet-Draft RTP-for-SIPREC September 2011
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, 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
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
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
Eckel Expires March 25, 2012 [Page 6]
Internet-Draft RTP-for-SIPREC September 2011
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 SRS 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.
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 if there are more than
31 such sources.
Eckel Expires March 25, 2012 [Page 7]
Internet-Draft RTP-for-SIPREC September 2011
9.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].
10. 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.
11. 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.
11.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.
Eckel Expires March 25, 2012 [Page 8]
Internet-Draft RTP-for-SIPREC September 2011
11.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.
11.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.
11.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.
11.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.
12. 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
Eckel Expires March 25, 2012 [Page 9]
Internet-Draft RTP-for-SIPREC September 2011
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, it will
receive RTCP as well as send RTP and RTCP.
Note: Symmetric RTP and symmetric RTCP are different from RTP/RTCP
multiplexing [RFC5761].
13. 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 element of the overall SIPREC solution.
The details regarding the encryption of the RTP/RTCP media will be
addressed in [I-D.ietf-siprec-protocol].
14. IANA Considerations
None.
15. Acknowledgements
Thank you to Andrew Hutton, Ram Mohan, and Muthu Perumal, John
Elwell, and Dan Wing for their valuable contributions.
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
16.2. Informative References
[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.
[I-D.ietf-siprec-protocol]
Eckel Expires March 25, 2012 [Page 10]
Internet-Draft RTP-for-SIPREC September 2011
Portman, L., Lum, H., Johnston, A., and A. Hutton,
"Session Recording Protocol",
draft-ietf-siprec-protocol-00 (work in progress),
August 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.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011.
Eckel Expires March 25, 2012 [Page 11]
Internet-Draft RTP-for-SIPREC September 2011
Author's Address
Charles Eckel
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States
Email: eckelcu@cisco.com
Eckel Expires March 25, 2012 [Page 12]