idnits 2.17.1 draft-eckel-siprec-rtp-rec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.portman-siprec-protocol]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2011) is 4691 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-siprec-architecture-02 == Outdated reference: A later version (-05) exists of draft-portman-siprec-protocol-04 -- Obsolete informational reference (is this intentional?): RFC 6222 (Obsoleted by RFC 7022) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC Working Group C. Eckel 3 Internet-Draft Cisco 4 Intended status: Informational June 16, 2011 5 Expires: December 18, 2011 7 Real-time Transport Protocol (RTP) Recommendations for SIPREC 8 draft-eckel-siprec-rtp-rec-01 10 Abstract 12 This document provides recommendations and guidelines for RTP and 13 RTCP in the context of SIPREC. This document exists as a standalone 14 document to facilitate discussion of the RTP recommendations, and it 15 is anticipated that portions of this document will be incorporated 16 into [I-D.portman-siprec-protocol] rather than this document itself 17 being adopted as a working group document. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 18, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.1. SRC acting as an RTP Translator . . . . . . . . . . . . . 4 58 4.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . . . . 4 59 4.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . . . 5 60 5. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8. CSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 9. SDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 10. CNAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 11. Keepalive . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 12. RTCP Feedback Messages . . . . . . . . . . . . . . . . . . . . 7 68 12.1. Full Intra Request . . . . . . . . . . . . . . . . . . . . 7 69 12.1.1. SIP INFO for FIR . . . . . . . . . . . . . . . . . . 8 70 12.2. Picture Loss Indicator . . . . . . . . . . . . . . . . . . 8 71 12.3. Temporary Maximum Media Stream Bit Rate Request . . . . . 8 72 12.3.1. Renegotiation of SDP bandwidth attribute . . . . . . 8 73 13. Symmetric RTP/RTCP for Sending and Receiving . . . . . . . . . 8 74 14. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 77 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 17.1. Normative References . . . . . . . . . . . . . . . . . . . 9 79 17.2. Informative References . . . . . . . . . . . . . . . . . . 9 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 This document provides recommendations and guidelines for RTP and 85 RTCP in the context of SIPREC. In order to communicate most 86 effectively, the Session Recording Client (SRC) and the Session 87 Recording (SRS) SHOULD utilize the mechanisms provided by RTP in a 88 well defined and predicable manner. It is the goal of this document 89 to make the reader aware of these mechanisms and provide 90 recommendations and guidelines. This document is completely 91 informational. It includes no requirements and no normative 92 language. This document exists as a standalone document to 93 facilitate discussion of the RTP recommendations, and it is 94 anticipated that portions of this document will be incorporated into 95 [I-D.portman-siprec-protocol] rather than this document itself being 96 adopted as a working group document. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Definitions 106 This document uses the definitions provided in 107 [I-D.ietf-siprec-architecture] for all SIPREC modules. A Session 108 Recording Client (SRC), as defined within SIPREC, is expected to 109 implement one or more of a variety of RTP roles within the context of 110 various SIPREC use cases. These roles include, but are not limited 111 to, acting as an end system, a mixer, or a translator. This document 112 uses the definitions provided in "RTP: A Transport Protocol for Real- 113 Time Application" [RFC3550]. 115 4. Roles 117 An SRC has the task of gathering media from the various UAs in a CS 118 and forwarding the information to the SRS in the context of the RS. 119 For a given media stream, the SRC has a number of ways of doing this 120 and may choose different ways for different media streams. The 121 following subsections define a set of roles an SRC may choose to play 122 from the perspective of its position between a UA within a CS, and an 123 SRS within an RS. 125 UA <-- CS --> SRC <-- RS --> SRS 127 Figure 1: SRC Positioning 129 4.1. SRC acting as an RTP Translator 131 The SRC may act as a translator, as defined in [RFC3550]. A defining 132 characteristic of a translator is that it forwards RTP packets with 133 their SSRC identifier intact. Optionally, an SRC acting as a 134 translator can perform transcoding (e.g., from one codec to another), 135 and this can result in a different rate of packets. With this 136 approach, RTP received as separate streams from different sources 137 (e.g., from different UAs with different SSRCs) cannot be mixed by 138 the SRC and SHOULD be sent separately to the SRS. More specifically, 139 the SRC cannot multiple RTP streams with different SSRCs into a 140 single RTP stream multiplexed by SSRC and/or CSRC. All RTCP reports 141 are passed by the SRC between the UAs and the SRS, such that they are 142 able to detect any SSRC collisions. 144 RTCP Sender Reports generated by a UA sending a stream SHOULD be 145 forwarded to the SRS. RTCP Receiver Reports generated by the SRS 146 need to be forwarded to the relevant UA. This implies that the SRC 147 cannot take multiplex RTP packets with different SSRC values into a 148 single SSRC stream unless it was The SRC in the case may need to 149 manipulate the RTCP Receiver Reports to take account of any 150 transcoding that has taken place. 152 If SRTP is used on both the CS and the RS, decryption and/or re- 153 encryption may occur. For example, if different keys are used, it 154 must occur. If the same keys are used, it need not occur. 156 4.2. SRC acting as an RTP Mixer 158 In the case of the SRC acting as a RTP mixer, as defined in 159 [RFC3550], the SRC combines RTP streams from different UA and sends 160 them towards the SRS using its own SSRC. The SSRCs from the 161 contributing UA SHOULD be conveyed as CSRCs identifiers within this 162 stream. The SRC may make timing adjustments among the received 163 streams and generate its own timing on the stream sent to the SRS. 164 Optionally an SRC acting as a mixer can perform transcoding, and can 165 even cope with different codings received from different UAs. RTCP 166 Sender Reports and Receiver Reports are not forwarded by an SRC 167 acting as mixer, but there are requirements for forwarding RTCP 168 Source Description (SDES) packets. The SRC generates its own RTCP 169 Sender and Receiver reports toward the associated UAs and SRS. The 170 use of SRTP between the SRC and the SRS for the RS is independent of 171 the use of SRTP between the UAs and SRC for the CS. 173 4.3. SRC acting as an RTP Endpoint 175 The case of the SRC acting as an RTP endpoint, as defined in 176 [RFC3550], is similar to the mixer case, except that the RTP session 177 between the SRC and the SRS is considered completely independent from 178 the RTP session that is part of the CS. The SRC can, but need not, 179 mix RTP streams from different participants prior to sending to the 180 SRS. RTCP between the SRC and the SRS is completely independent of 181 RTCP on the CS. The use of SRTP between the SRC and the SRS is 182 independent of the use of SRTP on the CS. 184 5. RTCP 186 The RTP data transport is augmented by a control protocol (RTCP) to 187 allow monitoring of the data delivery. RTCP, as defined in 188 [RFC3550], is based on the periodic transmission of control packets 189 to all participants in the RTP session, using the same distribution 190 mechanism as the data packets. Support for RTCP is required by 191 [RFC3550], and it provides, among other things, the following 192 important functionality in relation to SIPREC: 194 1) Feedback on the quality of the data distribution. This feedback 195 is important for flow and congestion control functions, and to get 196 feedback from the receivers to diagnose faults in the distribution. 197 As such, RTCP is a well defined and efficient mechanism for the SRS 198 to inform the SRC or any issues that arise in the reception of media 199 that is to be recorded. 201 2) Carries a persistent transport-level identifier for an RTP source 202 called the canonical name or CNAME. The SSRC identifier may change 203 if a conflict is discovered or a program is restarted; in which case 204 receivers can use the CNAME to keep track of each participant. 205 Receivers may also use the CNAME to associate multiple data streams 206 from a given participant in a set of related RTP sessions, for 207 example to synchronize audio and video. Synchronization of media 208 streams is also facilitated by the NTP and RTP timestamps included in 209 RTCP packets by data senders. 211 6. RTP Profile 213 The RECOMMENDED RTP profiles for both the SRC and SRS are "Extended 214 Secure RTP Profile for Real-time Transport Control Protocol (RTCP)- 215 Based Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP 216 streams, and "Extended RTP Profile for Real-time Transport Control 217 Protocol (RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non 218 encrypted media streams. However, as this is not a requirement, some 219 implementations may use "The Secure Real-time Transport Protocol 220 (SRTP)", [RFC3711] and "RTP Profile for Audio and Video Conferences 221 with Minimal Control", AVP [RFC3551]. Therefore, it is RECOMMENDED 222 that the SRC and SRS not rely entirely on SAVPF or AVPF for core 223 functionality that may be at least partially achievable using SAVP 224 and AVP. 226 AVPF and SAVPF provide an improved RTCP timer model that allows more 227 flexible transmission of RTCP packets as response to events, rather 228 than strictly according to bandwidth. AVPF based codec control 229 messages provide efficient mechanisms for an SRC and SRS to handle 230 events such as scene changes, error recovery, and dynamic bandwidth 231 adjustments. These messages are discussed in more detail later in 232 this document. 234 SAVP and SAVPF provide media encryption, integrity protection, replay 235 protection, and a limited form of source authentication. They do not 236 contain or require a specific keying mechanism. 238 7. SSRC 240 The synchronization source (SSRC), as defined in [RFC3550], is 241 carried in the RTP header and in various fields of RTCP packets. It 242 is a random 32-bit number that is required to be globally unique 243 within an RTP session. It is crucial that the number be chosen with 244 care in order that participants on the same network or starting at 245 the same time are not likely to choose the same number. Guidelines 246 regarding SSRC value selection and conflict resolution are provided 247 in [RFC3550]. 249 The SSRC may also be used to separate different sources of media 250 within a single RTP session. For this reason as well as for conflict 251 resolution, it is important that the SRC and SRS handle changes in 252 SSRC values and properly identify the reason of the change. The 253 CNAME values carried in RTCP facilitate this identification. 255 8. CSRC 257 The contributing source (CSRC), as defined in [RFC3550], identifies 258 the source of a stream of RTP packets that has contributed to the 259 combined stream produced by an RTP mixer. The mixer inserts a list 260 of the SSRC identifiers of the sources that contributed to the 261 generation of a particular packet into the RTP header of that packet. 262 This list is called the CSRC list. It is RECOMMENDED that a SRC, 263 when acting a mixer, sets the CSRC list accordingly, and that the SRS 264 interprets the CSRC list appropriately when received. 266 9. SDES 268 The Source Description (SDES), as defined in [RFC3550], contains an 269 SSRC/CSRC identifier followed by a list of zero or more items, which 270 carry information about the SSRC/CSRC. End systems send one SDES 271 packet containing their own source identifier (the same as the SSRC 272 in the fixed RTP header). A mixer sends one SDES packet containing a 273 chunk for each contributing source from which it is receiving SDES 274 information, or multiple complete SDES packets. 276 10. CNAME 278 The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], 279 provides the binding from the SSRC identifier to an identifier for 280 the source (sender or receiver) that remains constant. It is 281 important the an SRC and SRS generate CNAMEs appropriately and use 282 them for this purpose. Guidelines for generating CNAME values are 283 provided in "Guidelines for Choosing RTP Control Protocol (RTCP) 284 Canonical Names (CNAMEs)" [RFC6222]. 286 11. Keepalive 288 It is anticipated that media streams in SIPREC may exist in inactive 289 states for extended periods of times for an of a number of valid 290 reasons. In order to the bindings and any pinholes in NATs/firewalls 291 to remain active during such intervals, it is RECOMMENDED to follow 292 the keep-alive procedures in "Application Mechanism for Keeping Alive 293 the NAT Mappings Associated to RTP/RTP Control Protocol (RTCP) Flows" 294 [RFC6263] for all RTP media streams. 296 12. RTCP Feedback Messages 298 "Codec Control Messages in the RTP Audio-Visual Profile with Feedback 299 (AVPF)" [RFC5104] specifies extensions to the messages defined in 300 AVPF [RFC4585]. Support for and proper usage of these messages is 301 important to SRC and SRS implementations. Note that these messages 302 are applicable only when using the AVFP or SAVPF RTP profiles. 304 12.1. Full Intra Request 306 A Full Intra Request (FIR) Command, when received by the designate 307 media sender, requires that the media sender sends a Decoder Refresh 308 Point at the earliest opportunity. Using a decoder refresh point 309 implies refraining from using any picture sent prior to that point as 310 a reference for the encoding process of any subsequent picture sent 311 in the stream. 313 Decoder refresh points, especially Intra or IDR pictures for H.264 314 video codecs, are in general several times larger in size than 315 predicted pictures. Thus, in scenarios in which the available bit 316 rate is small, the use of a decoder refresh point implies a delay 317 that is significantly longer than the typical picture duration. 319 12.1.1. SIP INFO for FIR 321 "XML Schema for Media Control" [RFC5168] defines an Extensible Markup 322 Language (XML) Schema for video fast update. Implementations are 323 discouraged from using the method described except for backward 324 compatibility purposes. Implementations SHOULD use FIR messages 325 instead. 327 12.2. Picture Loss Indicator 329 Using the FIR command to recover from errors is explicitly 330 disallowed, and instead the PLI message defined in AVPF [RFC4585] 331 SHOULD be used. The PLI message reports lost pictures and has been 332 included in AVPF for precisely that purpose. 334 12.3. Temporary Maximum Media Stream Bit Rate Request 336 A receiver, translator, or mixer uses the Temporary Maximum Media 337 Stream Bit Rate Request (TMMBR) to request a sender to limit the 338 maximum bit rate for a media stream to the provided value. 339 Appropriate use of TMMBR facilitates rapid adaptation to changes in 340 available bandwidth. 342 12.3.1. Renegotiation of SDP bandwidth attribute 344 If it is likely that the new value indicated by TMMBR will be valid 345 for the remainder of the session, the TMMBR sender is expected to 346 perform a renegotiation of the session upper limit using the session 347 signaling protocol. Therefore for SIPREC, implementations are 348 RECOMMENDED to use TMMBR for temporary changes, and renegotiation of 349 bandwidth via SDP offer/answer of more permanent changes. 351 13. Symmetric RTP/RTCP for Sending and Receiving 353 Within an SDP offer/answer exchange, RTP entities choose the RTP and 354 RTCP transport addresses (i.e., IP addresses and port numbers) on 355 which to receive packets. When sending packets; however, they may 356 use a different source IP address or port number for RTP, RTCP, or 357 both. When the IP address and port used to send and receive RTP is 358 the same, it is termed "symmetric RTP" [RFC4961]. Likewise, when the 359 IP address and port used to send and receive RTCP is the same, it is 360 termed "symmetric RTCP" [RFC4961]. 362 If an SRC or SRS is sending RTP, it is RECOMMENDED to use symmetric 363 RTP. If an SRC or SRS is sending RTCP, it is RECOMMENDED to use 364 symmetric RTCP. Note, symmetric RTP and symmetric RTCP are different 365 from RTP/RTCP multiplexing [RFC5761]. 367 14. Security Considerations 369 In many scenarios it will be critical that the media transported 370 between the SRC and SRS using RTP/RTCP be protected. Media 371 encryption is an important element of the overall SIPREC solution. 372 The details regarding the encryption of the RTP/RTCP media will be 373 addressed in [I-D.portman-siprec-protocol]. 375 15. IANA Considerations 377 None. 379 16. Acknowledgements 381 Thank you to Andrew Hutton, Ram Mohan, and Muthu Perumal, John 382 Elwell, and Dan Wing for their valuable contributions. 384 17. References 386 17.1. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 17.2. Informative References 393 [I-D.ietf-siprec-architecture] 394 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 395 Architecture for Media Recording using the Session 396 Initiation Protocol", draft-ietf-siprec-architecture-02 397 (work in progress), April 2011. 399 [I-D.portman-siprec-protocol] 400 Portman, L., Lum, H., Johnston, A., and A. Hutton, 401 "Session Recording Protocol", 402 draft-portman-siprec-protocol-04 (work in progress), 403 May 2011. 405 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 406 Jacobson, "RTP: A Transport Protocol for Real-Time 407 Applications", STD 64, RFC 3550, July 2003. 409 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 410 Video Conferences with Minimal Control", STD 65, RFC 3551, 411 July 2003. 413 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 414 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 415 RFC 3711, March 2004. 417 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 418 "Extended RTP Profile for Real-time Transport Control 419 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 420 July 2006. 422 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 423 BCP 131, RFC 4961, July 2007. 425 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 426 "Codec Control Messages in the RTP Audio-Visual Profile 427 with Feedback (AVPF)", RFC 5104, February 2008. 429 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 430 Real-time Transport Control Protocol (RTCP)-Based Feedback 431 (RTP/SAVPF)", RFC 5124, February 2008. 433 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 434 Media Control", RFC 5168, March 2008. 436 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 437 Control Packets on a Single Port", RFC 5761, April 2010. 439 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 440 Choosing RTP Control Protocol (RTCP) Canonical Names 441 (CNAMEs)", RFC 6222, April 2011. 443 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 444 Keeping Alive the NAT Mappings Associated with RTP / RTP 445 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 447 Author's Address 449 Charles Eckel 450 Cisco 451 170 West Tasman Drive 452 San Jose, CA 95134 453 United States 455 Email: eckelcu@cisco.com