idnits 2.17.1 draft-eckel-siprec-rtp-rec-02.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-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 (September 22, 2011) is 4600 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 (-18) exists of draft-ietf-siprec-protocol-00 -- Obsolete informational reference (is this intentional?): RFC 6222 (Obsoleted by RFC 7022) Summary: 1 error (**), 0 flaws (~~), 3 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 September 22, 2011 5 Expires: March 25, 2012 7 Real-time Transport Protocol (RTP) Recommendations for SIPREC 8 draft-eckel-siprec-rtp-rec-02 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.ietf-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 March 25, 2012. 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.1.1. Forwarding Translator . . . . . . . . . . . . . . . . 4 59 4.1.2. Transcoding Translator . . . . . . . . . . . . . . . . 4 60 4.2. SRC acting as an RTP Mixer . . . . . . . . . . . . . . . . 5 61 4.3. SRC acting as an RTP Endpoint . . . . . . . . . . . . . . 5 62 5. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8. CSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 9. SDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 9.1. CNAME . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10. Keepalive . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 11. RTCP Feedback Messages . . . . . . . . . . . . . . . . . . . . 8 70 11.1. Full Intra Request . . . . . . . . . . . . . . . . . . . . 8 71 11.1.1. SIP INFO for FIR . . . . . . . . . . . . . . . . . . . 9 72 11.2. Picture Loss Indicator . . . . . . . . . . . . . . . . . . 9 73 11.3. Temporary Maximum Media Stream Bit Rate Request . . . . . 9 74 11.3.1. Renegotiation of SDP bandwidth attribute . . . . . . . 9 75 12. Symmetric RTP/RTCP for Sending and Receiving . . . . . . . . . 9 76 13. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 79 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 16.1. Normative References . . . . . . . . . . . . . . . . . . . 10 81 16.2. Informative References . . . . . . . . . . . . . . . . . . 10 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 This document provides recommendations and guidelines for RTP and 87 RTCP in the context of SIPREC. In order to communicate most 88 effectively, the Session Recording Client (SRC) and the Session 89 Recording (SRS) SHOULD utilize the mechanisms provided by RTP in a 90 well defined and predicable manner. It is the goal of this document 91 to make the reader aware of these mechanisms and provide 92 recommendations and guidelines. 94 This document exists as a standalone document to facilitate 95 discussion of the RTP recommendations, and it is anticipated that 96 portions of this document will be incorporated into 97 [I-D.ietf-siprec-protocol] rather than this document itself being 98 adopted as a working group document. This document makes use of 99 normative language as it is expected to exist within the working 100 group document into which it is eventually incorporated. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. Definitions 110 This document uses the definitions provided in 111 [I-D.ietf-siprec-architecture] for all SIPREC modules. A Session 112 Recording Client (SRC), as defined within SIPREC, is expected to 113 implement one or more of a variety of RTP roles within the context of 114 various SIPREC use cases. These roles include, but are not limited 115 to, acting as an end system, a mixer, or a translator. This document 116 uses the definitions provided in "RTP: A Transport Protocol for Real- 117 Time Application" [RFC3550]. 119 4. Roles 121 An SRC has the task of gathering media from the various UAs in a CS 122 and forwarding the information to the SRS within the context of an 123 RS. There are numerous ways in which an SRC may do this is, 124 including appearing as one of the UAs within a CS, or as a B2BUA 125 between UAs within a CS. 127 UA <-- CS --> SRC <-- RS --> SRS 129 Figure 1: UA as SRC 131 SRS 132 ^ 133 | 134 RS 135 | 136 v 137 UA1 <-- CS --> SRC <-- CS --> UA2 139 Figure 2: B2BUA as SRC 141 The following subsections define a set of roles an SRC may choose to 142 play based on its position with respect to a UA within a CS, and an 143 SRS within an RS. 145 4.1. SRC acting as an RTP Translator 147 The SRC may act as a translator, as defined in [RFC3550]. A defining 148 characteristic of a translator is that it forwards RTP packets with 149 their SSRC identifier intact. There are two types of translators, 150 one that simply forward, and another that performs transcoding (e.g., 151 from one codec to another) in addition to forwarding. 153 4.1.1. Forwarding Translator 155 When acting as a forwarding translator, RTP received as separate 156 streams from different sources (e.g., from different UAs with 157 different SSRCs) cannot be mixed by the SRC and MUST be sent 158 separately to the SRS. All RTCP reports MUST be passed by the SRC 159 between the UAs and the SRS, such that the UAs and SRS are able to 160 detect any SSRC collisions. 162 RTCP Sender Reports generated by a UA sending a stream MUST be 163 forwarded to the SRS. RTCP Receiver Reports generated by the SRS 164 MUST be forwarded to the relevant UA. 166 If SRTP is used on both the CS and the RS, decryption and/or re- 167 encryption may occur. For example, if different keys are used, it 168 will occur. If the same keys are used, it need not occur. 170 4.1.2. Transcoding Translator 172 When acting as a transcoding translator, an SRC MAY perform 173 transcoding (e.g., from one codec to another), and this may result in 174 a different rate of packets between what the SRC receives and what 175 the sends. As when acting as a forwarding translator, RTP received 176 as separate streams from different sources (e.g., from different UAs 177 with different SSRCs) cannot be mixed by the SRC and MUST be sent 178 separately to the SRS. All RTCP reports MUST passed by the SRC 179 between the UAs and the SRS, such the UAs and SRS they are able to 180 detect any SSRC collisions. 182 RTCP Sender Reports generated by a UA sending a stream MUST be 183 forwarded to the SRS. RTCP Receiver Reports generated by the SRS 184 MUST be forwarded to the relevant UA. The SRC may need to manipulate 185 the RTCP Receiver Reports to take account of any transcoding that has 186 taken place. 188 If SRTP is used on both the CS and the RS, decryption and/or re- 189 encryption may occur. For example, if different keys are used, it 190 will occur. If the same keys are used, it need not occur. 192 4.2. SRC acting as an RTP Mixer 194 In the case of the SRC acting as a RTP mixer, as defined in 195 [RFC3550], the SRC combines RTP streams from different UA and sends 196 them towards the SRS using its own SSRC. The SSRCs from the 197 contributing UA SHOULD be conveyed as CSRCs identifiers within this 198 stream. The SRC may make timing adjustments among the received 199 streams and generate its own timing on the stream sent to the SRS. 200 Optionally an SRC acting as a mixer can perform transcoding, and can 201 even cope with different codings received from different UAs. RTCP 202 Sender Reports and Receiver Reports are not forwarded by an SRC 203 acting as mixer, but there are requirements for forwarding RTCP 204 Source Description (SDES) packets. The SRC generates its own RTCP 205 Sender and Receiver reports toward the associated UAs and SRS. The 206 use of SRTP between the SRC and the SRS for the RS is independent of 207 the use of SRTP between the UAs and SRC for the CS. 209 4.3. SRC acting as an RTP Endpoint 211 The case of the SRC acting as an RTP endpoint, as defined in 212 [RFC3550], is similar to the mixer case, except that the RTP session 213 between the SRC and the SRS is considered completely independent from 214 the RTP session that is part of the CS. The SRC can, but need not, 215 mix RTP streams from different participants prior to sending to the 216 SRS. RTCP between the SRC and the SRS is completely independent of 217 RTCP on the CS. The use of SRTP between the SRC and the SRS is 218 independent of the use of SRTP on the CS. 220 5. RTCP 222 The RTP data transport is augmented by a control protocol (RTCP) to 223 allow monitoring of the data delivery. RTCP, as defined in 224 [RFC3550], is based on the periodic transmission of control packets 225 to all participants in the RTP session, using the same distribution 226 mechanism as the data packets. Support for RTCP is REQUIRED, per 227 [RFC3550], and it provides, among other things, the following 228 important functionality in relation to SIPREC: 230 1) Feedback on the quality of the data distribution. This feedback 231 is important for flow and congestion control functions, and to get 232 feedback from the receivers to diagnose faults in the distribution. 233 As such, RTCP is a well defined and efficient mechanism for the SRS 234 to inform the SRC or any issues that arise in the reception of media 235 that is to be recorded. 237 2) Carries a persistent transport-level identifier for an RTP source 238 called the canonical name or CNAME. The SSRC identifier may change 239 if a conflict is discovered or a program is restarted; in which case 240 receivers can use the CNAME to keep track of each participant. 241 Receivers may also use the CNAME to associate multiple data streams 242 from a given participant in a set of related RTP sessions, for 243 example to synchronize audio and video. Synchronization of media 244 streams is also facilitated by the NTP and RTP timestamps included in 245 RTCP packets by data senders. 247 6. RTP Profile 249 The RECOMMENDED RTP profiles for both the SRC and SRS are "Extended 250 Secure RTP Profile for Real-time Transport Control Protocol (RTCP)- 251 Based Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP 252 streams, and "Extended RTP Profile for Real-time Transport Control 253 Protocol (RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non 254 encrypted media streams. However, as this is not a requirement, some 255 implementations may use "The Secure Real-time Transport Protocol 256 (SRTP)", [RFC3711] and "RTP Profile for Audio and Video Conferences 257 with Minimal Control", AVP [RFC3551]. Therefore, it is RECOMMENDED 258 that the SRC and SRS not rely entirely on SAVPF or AVPF for core 259 functionality that may be at least partially achievable using SAVP 260 and AVP. 262 AVPF and SAVPF provide an improved RTCP timer model that allows more 263 flexible transmission of RTCP packets as response to events, rather 264 than strictly according to bandwidth. AVPF based codec control 265 messages provide efficient mechanisms for an SRC and SRS to handle 266 events such as scene changes, error recovery, and dynamic bandwidth 267 adjustments. These messages are discussed in more detail later in 268 this document. 270 SAVP and SAVPF provide media encryption, integrity protection, replay 271 protection, and a limited form of source authentication. They do not 272 contain or require a specific keying mechanism. 274 7. SSRC 276 The synchronization source (SSRC), as defined in [RFC3550], is 277 carried in the RTP header and in various fields of RTCP packets. It 278 is a random 32-bit number that is required to be globally unique 279 within an RTP session. It is crucial that the number be chosen with 280 care in order that participants on the same network or starting at 281 the same time are not likely to choose the same number. Guidelines 282 regarding SSRC value selection and conflict resolution are provided 283 in [RFC3550]. 285 The SSRC may also be used to separate different sources of media 286 within a single RTP session. For this reason as well as for conflict 287 resolution, it is important that the SRC and SRS handle changes in 288 SSRC values and properly identify the reason of the change. The 289 CNAME values carried in RTCP facilitate this identification. 291 8. CSRC 293 The contributing source (CSRC), as defined in [RFC3550], identifies 294 the source of a stream of RTP packets that has contributed to the 295 combined stream produced by an RTP mixer. The mixer inserts a list 296 of the SSRC identifiers of the sources that contributed to the 297 generation of a particular packet into the RTP header of that packet. 298 This list is called the CSRC list. It is RECOMMENDED that a SRC, 299 when acting a mixer, sets the CSRC list accordingly, and that the SRS 300 interprets the CSRC list appropriately when received. 302 9. SDES 304 The Source Description (SDES), as defined in [RFC3550], contains an 305 SSRC/CSRC identifier followed by a list of zero or more items, which 306 carry information about the SSRC/CSRC. End systems send one SDES 307 packet containing their own source identifier (the same as the SSRC 308 in the fixed RTP header). A mixer sends one SDES packet containing a 309 chunk for each contributing source from which it is receiving SDES 310 information, or multiple complete SDES packets if there are more than 311 31 such sources. 313 9.1. CNAME 315 The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], 316 provides the binding from the SSRC identifier to an identifier for 317 the source (sender or receiver) that remains constant. It is 318 important the an SRC and SRS generate CNAMEs appropriately and use 319 them for this purpose. Guidelines for generating CNAME values are 320 provided in "Guidelines for Choosing RTP Control Protocol (RTCP) 321 Canonical Names (CNAMEs)" [RFC6222]. 323 10. Keepalive 325 It is anticipated that media streams in SIPREC may exist in inactive 326 states for extended periods of times for an of a number of valid 327 reasons. In order for the bindings and any pinholes in NATs/ 328 firewalls to remain active during such intervals, it is RECOMMENDED 329 to follow the keep-alive procedure recommended in "Application 330 Mechanism for Keeping Alive the NAT Mappings Associated to RTP/RTP 331 Control Protocol (RTCP) Flows" [RFC6263] for all RTP media streams. 333 11. RTCP Feedback Messages 335 "Codec Control Messages in the RTP Audio-Visual Profile with Feedback 336 (AVPF)" [RFC5104] specifies extensions to the messages defined in 337 AVPF [RFC4585]. Support for and proper usage of these messages is 338 important to SRC and SRS implementations. Note that these messages 339 are applicable only when using the AVFP or SAVPF RTP profiles. 341 11.1. Full Intra Request 343 A Full Intra Request (FIR) Command, when received by the designate 344 media sender, requires that the media sender sends a Decoder Refresh 345 Point at the earliest opportunity. Using a decoder refresh point 346 implies refraining from using any picture sent prior to that point as 347 a reference for the encoding process of any subsequent picture sent 348 in the stream. 350 Decoder refresh points, especially Intra or IDR pictures for H.264 351 video codecs, are in general several times larger in size than 352 predicted pictures. Thus, in scenarios in which the available bit 353 rate is small, the use of a decoder refresh point implies a delay 354 that is significantly longer than the typical picture duration. 356 11.1.1. SIP INFO for FIR 358 "XML Schema for Media Control" [RFC5168] defines an Extensible Markup 359 Language (XML) Schema for video fast update. Implementations are 360 discouraged from using the method described except for backward 361 compatibility purposes. Implementations SHOULD use FIR messages 362 instead. 364 11.2. Picture Loss Indicator 366 Picture Loss Indication (PLI), as defined in [RFC4585], informs the 367 encoder of the loss of an undefined amount of coded video data 368 belonging to one or more pictures. Using the FIR command to recover 369 from errors is explicitly disallowed, and instead the PLI message 370 SHOULD be used. FIR SHOULD be used only in situations where not 371 sending a decoder refresh point would render the video usable for the 372 users. Examples where sending FIR is appropriate include a 373 multipoint conference when a new user joins the conference and no 374 regular decoder refresh point interval is established, and a video 375 switching MCU that changes streams. 377 11.3. Temporary Maximum Media Stream Bit Rate Request 379 A receiver, translator, or mixer uses the Temporary Maximum Media 380 Stream Bit Rate Request (TMMBR) to request a sender to limit the 381 maximum bit rate for a media stream to the provided value. 382 Appropriate use of TMMBR facilitates rapid adaptation to changes in 383 available bandwidth. 385 11.3.1. Renegotiation of SDP bandwidth attribute 387 If it is likely that the new value indicated by TMMBR will be valid 388 for the remainder of the session, the TMMBR sender is expected to 389 perform a renegotiation of the session upper limit using the session 390 signaling protocol. Therefore for SIPREC, implementations are 391 RECOMMENDED to use TMMBR for temporary changes, and renegotiation of 392 bandwidth via SDP offer/answer of more permanent changes. 394 12. Symmetric RTP/RTCP for Sending and Receiving 396 Within an SDP offer/answer exchange, RTP entities choose the RTP and 397 RTCP transport addresses (i.e., IP addresses and port numbers) on 398 which to receive packets. When sending packets, the RTP entities may 399 use the same source port or a different source port as those signaled 400 for receiving packets. When the transport address used to send and 401 receive RTP is the same, it is termed "symmetric RTP" [RFC4961]. 402 Likewise, when the transport address used to send and receive RTCP is 403 the same, it is termed "symmetric RTCP" [RFC4961]. 405 When sending RTP, it is REQUIRED to use symmetric RTP. When sending 406 RTCP, it is REQUIRED to use symmetric RTCP. Although an SRS will not 407 normally send RTP, it will send RTCP as well as receive RTP and RTCP. 408 Likewise, although an SRC will not normally receive RTP, it will 409 receive RTCP as well as send RTP and RTCP. 411 Note: Symmetric RTP and symmetric RTCP are different from RTP/RTCP 412 multiplexing [RFC5761]. 414 13. Security Considerations 416 In many scenarios it will be critical that the media transported 417 between the SRC and SRS using RTP/RTCP be protected. Media 418 encryption is an important element of the overall SIPREC solution. 419 The details regarding the encryption of the RTP/RTCP media will be 420 addressed in [I-D.ietf-siprec-protocol]. 422 14. IANA Considerations 424 None. 426 15. Acknowledgements 428 Thank you to Andrew Hutton, Ram Mohan, and Muthu Perumal, John 429 Elwell, and Dan Wing for their valuable contributions. 431 16. References 433 16.1. Normative References 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 16.2. Informative References 440 [I-D.ietf-siprec-architecture] 441 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 442 Architecture for Media Recording using the Session 443 Initiation Protocol", draft-ietf-siprec-architecture-02 444 (work in progress), April 2011. 446 [I-D.ietf-siprec-protocol] 447 Portman, L., Lum, H., Johnston, A., and A. Hutton, 448 "Session Recording Protocol", 449 draft-ietf-siprec-protocol-00 (work in progress), 450 August 2011. 452 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 453 Jacobson, "RTP: A Transport Protocol for Real-Time 454 Applications", STD 64, RFC 3550, July 2003. 456 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 457 Video Conferences with Minimal Control", STD 65, RFC 3551, 458 July 2003. 460 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 461 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 462 RFC 3711, March 2004. 464 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 465 "Extended RTP Profile for Real-time Transport Control 466 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 467 July 2006. 469 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 470 BCP 131, RFC 4961, July 2007. 472 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 473 "Codec Control Messages in the RTP Audio-Visual Profile 474 with Feedback (AVPF)", RFC 5104, February 2008. 476 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 477 Real-time Transport Control Protocol (RTCP)-Based Feedback 478 (RTP/SAVPF)", RFC 5124, February 2008. 480 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 481 Media Control", RFC 5168, March 2008. 483 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 484 Control Packets on a Single Port", RFC 5761, April 2010. 486 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 487 Choosing RTP Control Protocol (RTCP) Canonical Names 488 (CNAMEs)", RFC 6222, April 2011. 490 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 491 Keeping Alive the NAT Mappings Associated with RTP / RTP 492 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 494 Author's Address 496 Charles Eckel 497 Cisco 498 170 West Tasman Drive 499 San Jose, CA 95134 500 United States 502 Email: eckelcu@cisco.com