| SIPREC Working Group | C. Eckel |
| Internet-Draft | Cisco |
| Intended status: Informational | October 31, 2011 |
| Expires: May 03, 2012 |
Real-time Transport Protocol (RTP) Recommendations for SIPREC
draft-eckel-siprec-rtp-rec-03
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.
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 May 03, 2012.
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 described in the Simplified BSD License.
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 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.
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.
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].
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].
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
SRS
^
|
RS
|
v
UA1 <-- CS --> SRC <-- CS --> UA2
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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].
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.
"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.
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.
"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.
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.
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.
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.
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.
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].
None.
Thank you to Andrew Hutton, Ram Mohan, Muthu Perumal, John Elwell, Dan Wing, Hadriel Kaplan, Paul Kyzivat, and Magnus Westerlund for their valuable contributions.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |