idnits 2.17.1 draft-ietf-avtext-sdes-hdr-ext-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2016) is 2977 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 542, but not defined ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-27 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft B. Burman 4 Intended status: Standards Track Ericsson 5 Expires: September 3, 2016 R. Even 6 Huawei Technologies 7 M. Zanaty 8 Cisco Systems 9 March 2, 2016 11 RTP Header Extension for RTCP Source Description Items 12 draft-ietf-avtext-sdes-hdr-ext-05 14 Abstract 16 Source Description (SDES) items are normally transported in RTP 17 control protocol (RTCP). In some cases it can be beneficial to speed 18 up the delivery of these items. Mainly when a new source (SSRC) 19 joins an RTP session and the receivers needs this source's identity, 20 relation to other sources, or its synchronization context, all of 21 which may be fully or partially identified using SDES items. To 22 enable this optimization, this document specifies a new RTP header 23 extension that can carry SDES items. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 3, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5 66 4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 5 67 4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 6 68 4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6 69 4.2.1. One or Two Byte Headers . . . . . . . . . . . . . . . 6 70 4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 7 71 4.2.3. Transmission Considerations . . . . . . . . . . . . . 7 72 4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 9 73 4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 9 74 4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 5.1. Registration of an SDES Base URN . . . . . . . . . . . . 11 77 5.2. Creation of an SDES Sub-Registry . . . . . . . . . . . . 11 78 5.3. Registration of SDES Items . . . . . . . . . . . . . . . 12 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 8.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 This specification defines an RTP header extension [RFC3550][RFC5285] 89 that can carry RTCP source description (SDES) items. By including 90 selected SDES items in a header extension the determination of 91 relationship and synchronization context for new RTP streams (SSRCs) 92 in an RTP session can be optimized. Which relationship and what 93 information depends on the SDES items carried. This becomes a 94 complement to using only RTCP for SDES Item delivery. 96 It is important to note that not all SDES items are appropriate to 97 transmit using RTP header extensions. Some SDES items performs 98 binding or identifies synchronization context with strict timeliness 99 requirements, while many other SDES items do not have such 100 requirements. In addition, security and privacy concerns for the 101 SDES item information need to be considered. For example, the Name 102 and Location SDES items are highly sensitive from a privacy 103 perspective and should not be transported over the network without 104 strong security. No use case has identified where this information 105 is required at the same time as the first RTP packets arrive. A few 106 seconds delay before such information is available to the receiver 107 appears acceptable. Therefore only appropriate SDES items will be 108 registered for use with this header extension, such as CNAME. 110 First, some requirements language and terminology are defined. The 111 following section motivates why this header extension is sometimes 112 required or at least provides a significant improvement compared to 113 waiting for regular RTCP packet transmissions of the information. 114 This is followed by a specification of the header extension and usage 115 recommendations. Next, a sub-space of the header-extension URN is 116 defined to be used for existing and future SDES items, and then the 117 appropriate existing SDES items are registered. 119 2. Definitions 121 2.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2.2. Terminology 129 This document uses terminology defined in "A Taxonomy of Semantics 130 and Mechanisms for Real-Time Transport Protocol (RTP) Sources" 131 [RFC7656]. In particular the following definitions: 133 Media Source 135 RTP Stream 137 Media Encoder 139 Participant 141 3. Motivation 143 Source Description (SDES) items are associated with a particular SSRC 144 and thus RTP stream. The source description items provide various 145 meta data associated with the SSRC. How important it is to have this 146 data no later than when receiving the first RTP packets depends on 147 the item itself. The CNAME item is one item that is commonly needed 148 either at reception of the first RTP packet for this SSRC, or at 149 least by the time the first media can be played out. If it is not 150 available, the synchronization context cannot be determined and thus 151 any related streams cannot be correctly synchronized. Thus, this is 152 a valuable example for having this information early when a new RTP 153 stream is received. 155 The main reason for new SSRCs in an RTP session is when media sources 156 are added. This can be either because an end-point is adding a new 157 actual media source, or additional participants in a multi-party 158 session are added to the session. Another reason for a new SSRC can 159 be an SSRC collision that forces both colliding parties to select new 160 SSRCs. 162 For the case of rapid media synchronization, one may use the RTP 163 header extension for Rapid Synchronization of RTP Flows [RFC6051]. 164 This header extension carries the clock information present in the 165 RTCP sender report (SR) packets. It however assumes that the CNAME 166 binding is known, which can be provided via signaling [RFC5576] in 167 some cases, but not all. Thus an RTP header extension for carrying 168 SDES items like CNAME is a powerful combination to enable rapid 169 synchronization in all cases. 171 The Rapid Synchronization of RTP Flows specification does provide an 172 analysis of the initial synchronization delay for different sessions 173 depending on number of receivers as well as on session bandwidth 174 (Section 2.1 of [RFC6051]). These results are applicable also for 175 other SDES items that have a similar time dependency until the 176 information can be sent using RTCP. These figures can be used to 177 determine the benefit of reducing the initial delay before 178 information is available for some use cases. 180 That document also discusses the case of late joiners, and defines an 181 RTCP Feedback format to request synchronization information, which is 182 another potential use case for SDES items in RTP header extension. 183 It would for example be natural to include CNAME SDES item with the 184 header extension containing the NTP formatted reference clock to 185 ensure synchronization. 187 There is an another SDES item that can benefit from timely delivery, 188 and an RTP header extension SDES item was therefore defined for it: 190 MID: This is a media description identifier that matches the value 191 of the Session Description Protocol (SDP) [RFC4566] a=mid 192 attribute, to associate RTP streams multiplexed on the same 193 transport with their respective SDP media description as described 194 in [I-D.ietf-mmusic-sdp-bundle-negotiation]. 196 4. Specification 198 This section first specifies the SDES item RTP header extension 199 format, followed by some usage considerations. 201 4.1. SDES Item Header Extension 203 An RTP header extension scheme allowing for multiple extensions is 204 defined in "A General Mechanism for RTP Header Extensions" [RFC5285]. 205 That specification defines both short and long item headers. The 206 short headers (One-byte) are restricted to 1 to 16 bytes of data, 207 while the long format (Two-byte) supports a data length of 0 to 255 208 bytes. Thus the RTP header extension formats are capable of 209 supporting any SDES item from a data length perspective. 211 The ID field, independent of short or long format, identifies both 212 the type of RTP header extension and, in the case of the SDES item 213 header extension, the type of SDES item. The mapping is done in 214 signaling by identifying the header extension and SDES item type 215 using a URN, which is defined in the IANA consideration (Section 5) 216 for the known SDES items appropriate to use. 218 4.1.1. One-Byte Format 220 The one-byte header format for an SDES item extension element 221 consists of the one-byte header (defined in Section 4.2 of 222 [RFC5285]), which consists of a 4-bit ID followed by a 4-bit length 223 field (len) that identifies the number of data bytes (len value +1) 224 following the header. The data part consists of len+1 bytes of UTF-8 225 text. The type of text and its mapping to the SDES item type is 226 determined by the ID field value. 228 0 1 2 3 229 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | ID | len | SDES Item text value ... | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 1 236 4.1.2. Two-Byte Format 238 The two-byte header format for an SDES item extension element 239 consists of the two-byte header (defined in Section 4.3 of 240 [RFC5285]), which consists of an 8-bit ID followed by an 8-bit length 241 field (len) that identifies the number of data bytes following the 242 header. The data part consists of len bytes of UTF-8 text. The type 243 of text and its mapping to the SDES item type is determined by the ID 244 field value. 246 0 1 2 3 247 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | ID | len | SDES Item text value ... | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 2 254 4.2. Usage of the SDES Item Header Extension 256 This section discusses various usage considerations; which form of 257 header extension to use, the packet expansion, and when to send SDES 258 items in header extension. 260 4.2.1. One or Two Byte Headers 262 The RTP header extensions for SDES items MAY use either the one-byte 263 or two-byte header formats, depending on the text value size for the 264 used SDES items and the requirement from any other header extensions 265 used. The one-byte header SHOULD be used when all non SDES item 266 header extensions supports the one-byte format and all SDES item text 267 values contain at most 16 bytes. Note that the RTP header extension 268 specification does not allow mixing one-byte and two-byte headers for 269 the same RTP stream (SSRC), so if the value size of any of the SDES 270 items value requires the two-byte header, then all other header 271 extensions MUST also use the two-byte header format. 273 For example using CNAMEs that are generated according to "Guidelines 274 for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" 275 [RFC7022], using short term persistent values, and if 96-bit random 276 values prior to base64 encoding are sufficient, then they will fit 277 into the one-byte header format. 279 An RTP middlebox needs to take care choosing between one-byte headers 280 and two-byte headers when creating the first packets for an outgoing 281 stream (SSRC) with header extensions. First of all it needs to 282 consider all the header extensions that may potentially be used. 283 Secondly, it needs to know the size of the SDES items that are going 284 to be included, and use two bytes headers if any are longer than 16 285 bytes. An RTP middlebox that forwards a stream, i.e. not mixing it 286 or combing it with other streams, may be able to base its choice on 287 the header size in incoming streams. This is assuming that the 288 middlebox does not modify the stream or add additional header 289 extensions to the stream it sends, in which case it needs to make its 290 own decision. 292 4.2.2. MTU and Packet Expansion 294 The RTP packet size will clearly increase when a header extension is 295 included. How much depends on the type of header extensions and 296 their data content. The SDES items can vary in size. There are also 297 some use-cases that require transmitting multiple SDES items in the 298 same packet to ensure that all relevant data reaches the receiver. 299 An example of that is when both CNAME, a MID, and the rapid time 300 synchronization extension from RFC 6051 are needed. Such a 301 combination is quite likely to result in at least 16+3+8 bytes of 302 data plus the headers, which will be another 7 bytes for one-byte 303 headers, plus two bytes of header padding to make the complete header 304 extension word aligned, thus in total 36 bytes. 306 If the packet expansion cannot be taken into account when producing 307 the RTP payload, it can cause an issue. An RTP payload that is 308 created to meet a particular IP level Maximum Transmission Unit 309 (MTU), taking the addition of IP/UDP/RTP headers but not RTP header 310 extensions into account, could exceed the MTU when the header 311 extensions are present, thus resulting in IP fragmentation. IP 312 fragmentation is known to negatively impact the loss rate due to 313 middleboxes unwilling or not capable of dealing with IP fragments, as 314 well as increasing the target surface for other types of packet 315 losses. 317 As this is a real issue, the media encoder and payload packetizer 318 should be flexible and be capable of handling dynamically varying 319 payload size restrictions to counter the packet expansion caused by 320 header extensions. If that is not possible, some reasonable worst 321 case packet expansion should be calculated and used to reduce the RTP 322 payload size of all RTP packets the sender transmits. 324 4.2.3. Transmission Considerations 326 The general recommendation is to only send header extensions when 327 needed. This is especially true for SDES items that can be sent in 328 periodic repetitions of RTCP throughout the whole session. Thus, the 329 different usages (Section 4.2.4) have different recommendations. 330 First some general considerations for getting the header extensions 331 delivered to the receiver: 333 1. The probability for packet loss and burst loss determine how many 334 repetitions of the header extensions will be required to reach a 335 targeted delivery probability, and if burst loss is likely, what 336 distribution would be needed to avoid getting all repetitions of 337 the header extensions lost in a single burst. 339 2. If a set of packets are all needed to enable decoding, there is 340 commonly no reason for including the header extension in all of 341 these packets, as they share fate. Instead, at most one instance 342 of the header extension per independently decodable set of media 343 data would be a more efficient use of the bandwidth. 345 3. How early the SDES item information is needed, from the first 346 received RTP data or only after some set of packets are received, 347 can guide if the header extension(s) should be in all of the 348 first N packets or be included only once per set of packets, for 349 example once per video frame. 351 4. The use of RTP level robustness mechanisms, such as RTP 352 retransmission [RFC4588], or Forward Error Correction, e.g., 353 [RFC5109] may treat packets differently from a robustness 354 perspective, and SDES header extensions should be added to 355 packets that get a treatment corresponding to the relative 356 importance of receiving the information. 358 As a summary, the number of header extension transmissions should be 359 tailored to a desired probability of delivery taking the receiver 360 population size into account. For the very basic case, N repetitions 361 of the header extensions should be sufficient, but may not be 362 optimal. N is selected so that the header extension target delivery 363 probability reaches 1-P^N, where P is the probability of packet loss. 364 For point to point or small receiver populations, it might also be 365 possible to use feedback, such as RTCP, to determine when the 366 information in the header extensions has reached all receivers and 367 stop further repetitions. Feedback that can be used includes the 368 RTCP XR Loss RLE report block [RFC3611], which will indicate 369 successful delivery of particular packets. If the RTP/AVPF Transport 370 Layer Feedback Messages for generic NACK [RFC4585] is used, it can 371 indicate the failure to deliver an RTP packet with the header 372 extension, thus indicating the need for further repetitions. The 373 normal RTCP report blocks can also provide an indicator of successful 374 delivery, if no losses are indicated for a reporting interval 375 covering the RTP packets with the header extension. Note that loss 376 of an RTCP packet reporting on an interval where RTP header extension 377 packets were sent, does not necessarily mean that the RTP header 378 extension packets themselves were lost. 380 4.2.4. Different Usages 382 4.2.4.1. New SSRC 384 A new SSRC joins an RTP session. As this SSRC is completely new for 385 everyone, the goal is to ensure, with high probability, that all RTP 386 session participants receives the information in the header 387 extension. Thus, header extension transmission strategies that allow 388 some margins in the delivery probability should be considered. 390 4.2.4.2. Late Joiner 392 In a multi-party RTP session where one or a small number of receivers 393 join a session where the majority of receivers already have all 394 necessary information, the use of header extensions to deliver 395 relevant information should be tailored to reach the new receivers. 396 The trigger to send header extensions can for example either be RTCP 397 from new receiver(s) or an explicit request like the Rapid 398 Resynchronization Request defined in [RFC6051]. In centralized 399 topologies where an RTP middlebox is present, it can be responsible 400 for transmitting the known information, possibly stored, to the new 401 session participant only, and not repeat it to all the session 402 participants. 404 4.2.4.3. Information Change 406 If the SDES information is tightly coupled with the RTP data, and the 407 SDES information needs to be updated, then the use of the RTP header 408 extension is superior to RTCP. Using the RTP header extension 409 ensures that the information is updated on reception of the related 410 RTP media, ensuring synchronization between the two. Continued use 411 of the old SDES information can lead to undesired effects in the 412 application. Thus, header extension transmission strategies with 413 high probability of delivery should be chosen. 415 4.2.5. SDES Items in RTCP 417 The RTP header extension information, i.e. SDES items, can and will 418 be sent also in RTCP. Therefore, it is worth making some reflections 419 on this interaction. As an alternative to the header extension, it 420 is possible to schedule a non-regular RTCP packet transmission 421 containing important SDES items, if one uses an RTP/AVPF-based RTP 422 profile. Depending on which mode one's RTCP feedback transmitter is 423 working on, extra RTCP packets may be sent as immediate or early 424 packets, enabling more timely SDES information delivery. 426 There are however two aspects that differ between using RTP header 427 extensions and any non-regular transmission of RTCP packets. First, 428 as the RTCP packet is a separate packet, there is no direct relation 429 and also no fate sharing between the relevant media data and the SDES 430 information. The order of arrival for the packets will matter. With 431 a header-extension, the SDES items can be ensured to arrive if the 432 media data to play out arrives. Secondly, it is difficult to 433 determine if an RTCP packet is actually delivered. This, as the RTCP 434 packets lack both sequence number and a mechanism providing feedback 435 on the RTCP packets themselves. 437 4.2.6. Update Flaps 439 The SDES item may arrive both in RTCP and in RTP header extensions, 440 potentially causing the value to flap back and forth at the time of 441 updating. There are at least two reasons for these flaps. The first 442 one is packet reordering, where a pre-update RTP or RTCP packet with 443 an SDES item is delivered to the receiver after the first RTP/RTCP 444 packet with the updated value. The second reason is the different 445 code-paths for RTP and RTCP in implementations. An update to the 446 sender's SDES item parameter can take a different time to propagate 447 to the receiver than the corresponding media data. For example, an 448 RTCP packet with the SDES item included that may have been generated 449 prior to the update can still reside in a buffer and be sent 450 unmodified. The update of the item's value can at the same time 451 cause RTP packets to be sent including the header extension, prior to 452 the RTCP packet being sent. 454 However, most of these issues can be avoided by the receiver 455 performing some checks before updating the receiver's stored value. 456 To handle flaps caused by reordering, only SDES items received in RTP 457 packets with a higher extended sequence number than the last change 458 shall be applied, i.e. discard items that can be determined to be 459 older than the current one. For compound RTCP packets, which will 460 contain an Sender Report (SR) packet (assuming an active RTP sender), 461 the receiver can use the RTCP SR Timestamp field to determine at what 462 approximate time it was transmitted. If the timestamp is earlier 463 than the last received RTP packet with a header extension carrying an 464 SDES item, and especially if carrying a previously used value, the 465 SDES item in the RTCP SDES packet can be ignored. Note that media 466 processing and transmission pacing can easily cause the RTP header 467 timestamp field as well as the RTCP SR timestamp field to not match 468 with the actual transmission time. 470 5. IANA Considerations 472 This section makes the following requests to IANA: 474 o Create a new sub-registry reserved for RTCP SDES items with the 475 URN sub-space "urn:ietf:params:rtp-hdrext:sdes:" in the RTP 476 Compact Header Extensions registry. 478 o Register the SDES items appropriate for use with the RTP header 479 extension defined in this document. 481 RFC-editor note: Please replace all occurrences of RFCXXXX with the 482 RFC number this specification receives when published. 484 5.1. Registration of an SDES Base URN 486 IANA is requested to register the below entry in the RTP Compact 487 Header Extensions registry: 489 Extension URI: urn:ietf:params:rtp-hdrext:sdes 490 Description: Reserved as base URN for RTCP SDES items that are also 491 defined as RTP Compact header extensions. 492 Contact: Authors of [RFCXXXX] 493 Reference: [RFCXXXX] 495 The reason to register a base URN for an SDES sub-space is that the 496 name represents an RTCP Source Description item, where a 497 specification is strongly recommended [RFC3550]. 499 5.2. Creation of an SDES Sub-Registry 501 IANA is requested to create a sub-registry to the RTP Compact Header 502 Extensions registry, with the same basic requirements, structure and 503 layout as the RTP Compact Header Extensions registry. 505 o Registry name: RTP SDES Compact Header Extensions 507 o Specification: RFCXXXX and RFCs updating RFCXXXX 509 o Information required: Same as for RTP Header Extensions [RFC5285] 510 registry 512 o Review process: Same as for RTP Header Extensions [RFC5285] 513 registry, with the following requirements added to the expert 514 review: 516 1. Any registration using an Extension URI that starts with 517 "urn:ietf:params:rtp-hdrext:sdes:" (Section 5.1) MUST also 518 have a registered Source Description item in the "RTP SDES 519 item types" registry. 521 2. A security and privacy consideration for the SDES item MUST be 522 provided with the registration. 524 3. Information MUST be provided on why this SDES item requires 525 timely delivery, motivating it to be transported in a header 526 extension rather than as RTCP only. 528 o Size and format of entries: Same as for RTP Header Extensions 529 [RFC5285] registry. 531 o Initial assignments: See Section 5.3 below. 533 5.3. Registration of SDES Items 535 It is requested that the following SDES item is registered in the 536 newly formed RTP SDES Compact Header Extensions registry: 538 Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname 539 Description: Source Description: Canonical End-Point Identifier 540 (SDES CNAME) 541 Contact: Authors of [RFCXXXX] 542 Reference: [RFCXXXX] 544 6. Security Considerations 546 Source Description items may contain data that are sensitive from a 547 security perspective. There are SDES items that are or may be 548 sensitive from a user privacy perspective, like CNAME, NAME, EMAIL, 549 PHONE, LOC and H323-CADDR. Some may contain sensitive information, 550 like NOTE and PRIV, while others may be sensitive from profiling 551 implementations for vulnerability or other reasons, like TOOL. The 552 CNAME sensitivity can vary depending on how it is generated and what 553 persistence it has. A short term CNAME identifier generated using a 554 random number generator [RFC7022] may have minimal security 555 implications, while a CNAME of the form user@host has privacy 556 concerns, and a CNAME generated from a MAC address has long term 557 tracking potentials. 559 In RTP sessions where any type of confidentiality protection is 560 enabled for RTCP, the SDES item header extensions MUST also be 561 protected. This implies that to provide confidentiality, users of 562 SRTP need to implement and use encrypted header extensions per 563 [RFC6904]. The security level that is applied to RTCP packets 564 carrying SDES items SHOULD also be applied to SDES items carried as 565 RTP header extensions. If the security level is chosen to be 566 different for an SDES item in RTCP and RTP header extension, it is 567 important to motivate the exception, and to consider the security 568 properties as the worst in each aspect for the different 569 configurations. 571 As the SDES items are used by the RTP based application to establish 572 relationships between RTP streams or between an RTP stream and 573 information about the originating participant, there SHOULD be strong 574 integrity protection and source authentication of the header 575 extensions. If not, an attacker can modify the SDES item value to 576 create erroneous relationship bindings in the receiving application. 578 7. Acknowledgements 580 The authors likes to thank the following individuals for feedback and 581 suggestions; Colin Perkins, Ben Campbell. 583 8. References 585 8.1. Normative References 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, 589 DOI 10.17487/RFC2119, March 1997, 590 . 592 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 593 Jacobson, "RTP: A Transport Protocol for Real-Time 594 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 595 July 2003, . 597 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 598 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 599 2008, . 601 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 602 Real-time Transport Protocol (SRTP)", RFC 6904, 603 DOI 10.17487/RFC6904, April 2013, 604 . 606 8.2. Informative References 608 [I-D.ietf-mmusic-sdp-bundle-negotiation] 609 Holmberg, C., Alvestrand, H., and C. Jennings, 610 "Negotiating Media Multiplexing Using the Session 611 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 612 negotiation-27 (work in progress), February 2016. 614 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 615 "RTP Control Protocol Extended Reports (RTCP XR)", 616 RFC 3611, DOI 10.17487/RFC3611, November 2003, 617 . 619 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 620 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 621 July 2006, . 623 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 624 "Extended RTP Profile for Real-time Transport Control 625 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 626 DOI 10.17487/RFC4585, July 2006, 627 . 629 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 630 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 631 DOI 10.17487/RFC4588, July 2006, 632 . 634 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 635 Correction", RFC 5109, DOI 10.17487/RFC5109, December 636 2007, . 638 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 639 Media Attributes in the Session Description Protocol 640 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 641 . 643 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 644 Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, 645 . 647 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 648 "Guidelines for Choosing RTP Control Protocol (RTCP) 649 Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, 650 September 2013, . 652 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 653 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 654 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 655 DOI 10.17487/RFC7656, November 2015, 656 . 658 Authors' Addresses 660 Magnus Westerlund 661 Ericsson 662 Farogatan 6 663 SE-164 80 Stockholm 664 Sweden 666 Phone: +46 10 714 82 87 667 Email: magnus.westerlund@ericsson.com 669 Bo Burman 670 Ericsson 671 Kistavagen 25 672 Stockholm 16480 673 Sweden 675 Email: bo.burman@ericsson.com 677 Roni Even 678 Huawei Technologies 679 Tel Aviv 680 Israel 682 Email: roni.even@mail01.huawei.com 684 Mo Zanaty 685 Cisco Systems 686 7100 Kit Creek 687 RTP, NC 27709 688 USA 690 Email: mzanaty@cisco.com