idnits 2.17.1 draft-westerlund-avtext-rtcp-sdes-srcname-03.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 (October 21, 2013) is 3839 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) == Outdated reference: A later version (-03) exists of draft-even-mmusic-application-token-01 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 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: April 24, 2014 October 21, 2013 7 RTCP Source Description Item SRCNAME to Label Individual Media Sources 8 draft-westerlund-avtext-rtcp-sdes-srcname-03 10 Abstract 12 This document defines a new Source Description (SDES) item called 13 SRCNAME, which uniquely identifies a single media source, like a 14 camera or a microphone. It also enables identification of the 15 encoding to support when multiple ones are produced. That way anyone 16 receiving the SDES information from a set of interlinked RTP sessions 17 can determine which SSRCs are logically related to the same media 18 source and encoding. In addition the new SDES item is also defined 19 for usage with both a header extension and with the SDP source 20 specific media attribute ("a=ssrc"). Enabling an end-point to 21 receive the SRCNAME with the relevant RTP packets, as well as RTCP, 22 or learn the source bindings through signalling, ahead of receiving 23 RTP and RTCP packets. 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 April 24, 2014. 42 Copyright Notice 44 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. SRCNAME Format . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. SDES Item SRCNAME . . . . . . . . . . . . . . . . . . . . 7 67 4.3. SRCNAME in SDP . . . . . . . . . . . . . . . . . . . . . . 7 68 4.4. SRCNAME as RTP Header Extension . . . . . . . . . . . . . 8 69 5. Usage with the Offer/Answer Model . . . . . . . . . . . . . . 8 70 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9 71 7. Relation to Application Token . . . . . . . . . . . . . . . . 9 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 This specification defines a new RTP/RTCP [RFC3550] Source 82 Description (SDES) item called Source Name (SRCNAME). There exist 83 different use cases, including simulcast and scalable encoding, where 84 a sender transmit multiple RTP packet streams containing full or 85 partial encodings of the same media source. This include multiple 86 independent encodings, where it is desirable to identify the 87 different encodings. These different packet streams needs to be 88 correctly associated with media sources and encodings in an receiver 89 so that they correctly use the packet streams. 91 The proposed solution provides the RTP packet streams (SSRCs) with 92 identities for both the media source and the specific encoding. The 93 identification is done by creating a RTCP SDES item, SRCNAME, by 94 combing a media source identifier and an encoding identifier 95 separated by a full stop ("."). The SRCNAME can be sent periodically 96 in RTCP SDES packets to enable joiners to receive the information 97 within some time period from when they join. The SRCNAME is also 98 proposed to be sent in an RTP header extension for SDES items 99 [I-D.westerlund-avtext-sdes-hdr-ext] when it is desirable to speed up 100 reception. For example by transmitting the SRCNAME in the first N 101 RTP packets when a new SSRC joins an RTP session. Finally the 102 SRCNAME can be associated with the SSRC in signalling, and source 103 specific attribute is provided for this purpose. 105 2. Definitions 107 2.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2.2. Terminology 115 This document uses terminology defined in "A Taxonomy of Grouping 116 Semantics and Mechanisms for Real-Time Transport Protocol (RTP) 117 Sources" [I-D.lennox-raiarea-rtp-grouping-taxonomy] . In particular 118 the following definitions: 120 o Media Source 122 o Packet Stream 124 o Media Encoder 125 o Encoded Stream 127 o Dependent Stream 129 o Participant 131 o End point 133 3. Motivation 135 In RTP Applications where an end-point has more than one Media Source 136 in a particular RTP session there can exist need to provide these 137 media sources with an identifier. One reason is to be able to 138 explicitly track it across any SSRC collisions with resulting SSRC 139 changes. Another reason is when there exist multiple RTP Packet 140 Streams (SSRC) associated with that particular media source. 141 Especially in RTP sessions where multiple media sources are 142 simultaneously transmitted. This document focus on the cases that 143 results in multiple packet streams due to the encoding process. 145 Simulcast [I-D.westerlund-avtcore-rtp-simulcast] as referred to in 146 this document is the process when communication participant provides 147 a media source in multiple encodings using multiple media encoders 148 with different configurations. These different encoded streams are 149 then simultaneously transmitted using RTP to a receiver or a group of 150 receivers. The receiver(s) need two things; First to determine which 151 of the received packet streams (SSRCs) carries which media source, 152 and thus determining the different media sources and secondly what 153 alternative representations of each media source that exist. This 154 can be accomplished using an identifier to refer to a particular 155 encoding of a media source. 157 Scalable encoding is performed by some few media encoders, with the 158 prime example being H.264 Scalable Video Codec [RFC6190]. A scalable 159 media codec produces one or more base layers, i.e. an encoded stream, 160 and additionally one or more enhancement layers that are dependent on 161 the base layer as well as selected other enhancement layers, these 162 called dependent streams. The encoded and dependent streams can be 163 sent using multiple RTP packet streams, called multi-stream 164 transmission (MST). Thus explicit information are required for which 165 media source a particular packet stream (SSRC) are containing, 166 independent if it is the encoded or dependent stream. In cases where 167 one uses multiple base layers, the encoding identifier can be used to 168 provide RTP/RTCP level identification of the sub-groups of packet 169 streams that form an independent dependency tree. The detailed 170 dependency information between the encoded streams and dependent 171 streams are present in meta data information objects (SEI messages) 172 that are included inside the RTP payloads for SVC [RFC6190]. 174 By providing media source and encoding identity information on RTP 175 and RTCP level we enable or improve usages that prior has been 176 impractical or sub-optimal: 178 a. A multi-party sessions where the media sources dynamically join 179 and leave and the central media node is source projection mixer. 180 A large conference with some participant churn, in this case to 181 rely solely on a signalling based solution can be problematic, as 182 each signalling session between the conference and all the 183 participants needs to be updated, for example using SIP, each 184 time a participant joins or leaves. Thus enabling RTP/RTCP level 185 information enables the joining participant's flows to be 186 explicitly indicated as new media sources and alternative 187 representations on RTP/RTCP level and thus correctly handled. 189 b. Multicast or broadcast situations where session configuration 190 information is provided ahead of the session, and the exact set 191 of media sources and their identifies can't be determined and 192 assigned ahead of time. 194 c. To optimize the away the need for buffering or holding 195 transmission in centralized mixer cases when there is some delay 196 on the signalling channel. When a media source is added and the 197 information is provided using signalling only, then a receiver 198 that hasn't gotten the signalling yet, needs to either buffer or 199 discard received media until the signalling arrives, 200 alternatively, the sender needs to hold the transmission until 201 the receiver have confirmed reception of signalling. 203 d. By providing this information in the RTP/RTCP also enables third 204 party monitoring of the RTP/RTCP streams to work better as the 205 stream relations are made clear. 207 It is important to note that a particular RTP packet stream's role in 208 a communication application can be quite independent to which media 209 source and the particular encoding the packet stream is. Although 210 the media source and encoding is sufficient information in some use 211 cases, there are other cases where additional information about the 212 current role of packet stream or set of streams are required. 213 Further discussion of this in Section 7. 215 SRCNAME extends and complement the existing solutions using SDP Media 216 Description grouping [RFC5888], or SSRC grouping within a Media 217 Description in SDP [RFC5576] or implicit or heuristic based mapping 218 of packet streams between or within RTP sessions. SRCNAME enables 219 explicit identity information at RTP/RTCP level in a form that are 220 unique across the whole communication session, usable to create 221 relationships on RTP/RTCP level independent if one or more RTP 222 session is used, independent on how the packet streams are 223 distributed over those RTP sessions and how many media sources an 224 end-point have. 226 4. Solution 228 This section defines the SRCNAME identifier format and its usage as 229 RTCP SDES item [RFC3550], registers it as an SDES item possible to 230 use in the RTP header extension for SDES items 231 [I-D.westerlund-avtext-sdes-hdr-ext], and in a source specific SDP 232 attribute [RFC5576] as well. 234 4.1. SRCNAME Format 236 The SRCNAME MUST fulfill the requirements Section 6.5 in RTP 237 [RFC3550] puts on SDES item values in general. These requirements is 238 that it is a UTF-8 [RFC3629] text string that have a maximum length 239 of 255 bytes. 241 In addition, there are format restrictions to accommodate the 242 separation of the Media Source ID and the encoding ID part, as 243 described by the following ABNF [RFC5234]: 245 media-source-id = 1*(%x01-09 / %x0B-0C / %x0E-1F / %x21-2D / %x2F-FF) 246 encoding-id = media-source-id *(%x2E media-source-id) 247 ; Same as RFC 4566 "byte-string" 248 ; except for space and the "." separator 250 srcname-content = media-source %x2E encoding-id 252 Figure 1: SRCNAME Format ABNF 254 Note, the format do allow multiple "." separators, but only as part 255 of the encoding ID. 257 The media source identifier is identifying a media source (as defined 258 by section 2.1.4 of [I-D.lennox-raiarea-rtp-grouping-taxonomy]). 259 Each media source ID MUST be unique when combined with the CNAME. 260 Note that if one intended to byte compare the combination of CNAME 261 and media-source-id then one need to pad the CNAME to full 255 bytes 262 with a common pattern prior to concatenation and comparison. 264 The encoding-id identifies a particular media encoder (Section 2.1.6 265 in [I-D.lennox-raiarea-rtp-grouping-taxonomy]) and its set of 266 produced encoded or dependent streams (as defined per section 2.1.7 267 and 2.1.8 in [I-D.lennox-raiarea-rtp-grouping-taxonomy] 268 respectively). The encoding-id MUST be unique in the context of the 269 CNAME and the media source ID. 271 By require uniqueness scoped by CNAME we simplify the creation of 272 unique identifiers and reduce the overhead for the inclusion of 273 SRCNAME. As the CNAME defines the scope of a single synchronization 274 context, commonly a single host will be responsible for assigning 275 media source and encoding ID to media sources and their encodings. A 276 common case will be for having a single character media source ID 277 followed by stop and then another single character encoding ID, e.g. 278 "a.2". 280 4.2. SDES Item SRCNAME 282 Distributing the SRCNAME using a RTCP Source Descriptions (SDES) item 283 are a method that should work with all RTP topologies (assuming that 284 any intermediary node is supporting this item) and existing RTP 285 extensions. Thus, a new SDES item called SRCNAME are defined. That 286 way, anyone receiving the SDES information from a set of interlinked 287 RTP sessions or SSRCs in a single session can determine the SRCNAME 288 associated with each SSRC. 290 The SDES SRCNAME item follows the same format as the other SDES items 291 defined in RTP [RFC3550]: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | SRCNAME=TBA1 | length | source name ... 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 2: SDES SRCNAME Format 301 The source name field MUST follow the above (Section 4.1) srcname- 302 content definition. 304 When using the SRCNAME SDES item, it is of equally importance with 305 CNAME. Thus, SRCNAME is RECOMMENDED to be included in all full 306 compound RTCP packets being sent. It MAY also be included in non- 307 compound packets in cases where the implementation believes that 308 there might be new receivers needing the information. 310 4.3. SRCNAME in SDP 312 "Source-Specific Media Attributes in the Session Description Protocol 313 (SDP)" [RFC5576] defines a way of declaring attributes for SSRC in 314 each RTP session in SDP. With a new SDES item, it is possible to use 315 this framework to define how SRCNAME can also be provided in the SDP 316 for each SSRC in each RTP session, thus enabling an end-point to 317 declare and learn the source bindings ahead of receiving RTP/RTCP 318 packets. 320 Hence, we define a new SDP source attribute called srcname with the 321 following structure: 323 a=ssrc: srcname: 325 The srcname value MUST be identical to the SRCNAME value the media 326 sender will send in the SDES SRCNAME item in the SDES RTCP packets. 328 Formal ABNF syntax [RFC5234] for the "srcname" attribute: 330 srcname-attr = "srcname:" srcname 332 srcname = srcname-content 334 attribute =/ srcname-attr 335 ; The definition of "attribute" is in RFC 4566. 337 Figure 3: SRCNAME Attribute ABNF 339 When used in SDP, srcname-content MUST use ISO 10646 in UTF-8 340 encoding, and MUST be independent of any "a=charset". 342 4.4. SRCNAME as RTP Header Extension 344 In cases when timely deliver of the SRCNAME is required, for example 345 when adding a new SSRC to an RTP session, or when new receiver joins 346 a multiparty RTP session, then the SRCNAME can be included in the RTP 347 header extension for SDES items [I-D.westerlund-avtext-sdes-hdr-ext]. 349 The RTP header extension for SDES items 350 [I-D.westerlund-avtext-sdes-hdr-ext] is functioning for any SDES 351 item, but do require new SDES items to register its URN identifier. 352 This is done below in the IANA section (Section 8). 354 5. Usage with the Offer/Answer Model 356 The SDP offer/answer procedures for a=ssrc are specified in Source- 357 Specific Media Attributes in the Session Description Protocol (SDP) 358 [RFC5576]. The SDP offer/answer procedures for a=exthdr are 359 specified in A General Mechanism for RTP Header Extensions [RFC5285]. 361 6. Backward Compatibility 363 Clients not supporting SRCNAME will not have the possibility to bind 364 different streams to a specific media source, since they will not 365 understand the SRCNAME SDES item or the RTP header extension. 366 However, sending SRCNAME SDES items to a client not supporting it 367 should not impose any problems since all clients should be prepared 368 that new SDES items may be specified according to RTP [RFC3550]. 370 According to the definition of SDP attributes in SDP: Session 371 Description Protocol [RFC4566], if an attribute is received that is 372 not understood, it MUST be ignored by the receiver. So a receiver 373 not supporting the a=ssrc attribute will simply ignore it. 375 Source-Specific Media Attributes in the Session Description Protocol 376 (SDP) [RFC5576] defines rules of how new source attributes should be 377 registered, which means that a receiver supporting RFC 5576 should be 378 prepared that new source attributes may be defined. This means that 379 a user supporting some of the source attributes should not have any 380 problems when the user receives an SDP with unknown source 381 attributes. 383 RTP header extension will only be used when successfully negotiated 384 in SDP, which requires support in both sender and receiver. 386 7. Relation to Application Token 388 There exists a proposal for an application token SDES item 389 [I-D.even-mmusic-application-token], who's purpose is to map SSRCs to 390 application purposes or usages of the RTP packet stream. In this 391 section the similarities and differences are discussed to arrive at 392 the conclusion that for a number of cases both will be required to 393 enable powerful applications. 395 The APPID is flexible in that it allows applications or specific 396 usage of RTP to define how they map the APPID tokens to particular 397 purpose or usages of the streams. This is clearly intended to 398 provide flexibility. For example one APPID tokens can have meanings 399 such as Presentation stream, main talker, video thumbnail number 3, 400 FEC stream for Audio etc. Such roles can be transient in their 401 behavior. For example main talker is a role that moves around in a 402 multiparty communication session based on who is the current speaker, 403 based on voice activity, or a conference management interface. Thus, 404 the APPID token for this role will be moved between different SSRCs. 405 This is in strong contrast with SRCNAME which identifies a particular 406 media source and encoding. That is not expected to move around, 407 other than in cases of SSRC collisions, when they enable tracking 408 across this event. RTP Mixers that perform mixes or switching 409 between input sources, are them selves having conceptual media 410 sources, which will have stable identities. 412 A case that makes it clear that SRCNAME identification may benefit 413 from having additional role tokens is the case of having a source 414 projection mixer using simulcast from clients to mixers. From the 415 perspective of a receiver, there will be multiple SSRCs visible for a 416 particular media source, but the source projection mixer will select 417 a sub-set of all potential streams to deliver. A given sub-setting 418 is to only deliver one representation of each media source to the 419 receiver. During a multiparty conference where a main speaker is 420 shown larger at the receiver, and other participants are shown 421 smaller, the mixer may due to congestion be forced to switch 422 representation of the main speaker. If the role would be strictly 423 associated with the encoding representation then main speakers video 424 may for example be reduced in display size. If instead it is 425 explicitly indicated using APPID the receiving application would 426 continue to show the main speaker as a larger display area, despite 427 the reduced quality to ensure the user continuous to understand that 428 this is still the main talker. 430 Where SRCNAME provides stable identification that a SSRC is 431 associated with a media source and particular encoding of that media 432 source, the APPID can function as a complement when needed to provide 433 explicit indication of the current role and intended of application 434 usage of a SSRC. 436 8. IANA Considerations 438 Following the guidelines in SDP [RFC4566], in The Session Description 439 Protocol (SDP) Grouping Framework [RFC5888], and in RTP [RFC3550], 440 the IANA is requested to register: 442 1. A new SDES item named SRCNAME, as defined in Section 4.2. This 443 item needs to be assigned an identifier TBA1. 445 2. A new SDP source attribute named srcname, as defined in 446 Section 4.3. 448 3. New RTP header extension URN identifiers for SRCNAME, as defined 449 in Section 4.4. 451 9. Security Considerations 453 The SDES item or header extension SRCNAMEs being close to opaque 454 identifiers could potentially carry additional meanings or function 455 as overt channel. If the SRCNAME would be permanent between 456 sessions, they have the potential for compromising the users' privacy 457 as they can be tracked between sessions. See Guidelines for Choosing 458 RTP Control Protocol (RTCP) Canonical Names (CNAMEs) [RFC7022] for 459 more discussion. 461 A third party modification of the srcname labels either in the RTCP 462 SDES items, in the SDP a=ssrc attribute, or in the RTP header 463 extension can cause service disruption. By modifying labels the 464 wrong streams could be associated, with potentially serious effects 465 including media disruptions. If streams that are to be associated 466 aren't associated, then another type of failures occur. To prevent 467 modification, insertion or deletion of the srcname labels, the 468 carrying channel needs to be protected by integrity protection and 469 source authentication. For RTCP and RTP header extension, various 470 solutions exist, such as SRTP [RFC3711], DTLS [RFC6347], or IPsec 471 [RFC4301]. For protecting the SDP, the signalling channel needs to 472 provide protection. For SIP S/MIME [RFC3261] are the ideal, and hop 473 by hop TLS [RFC5246] provides at least some protection, although not 474 perfect. For SDPs retrieved using RTSP DESCRIBE [RFC2326], TLS would 475 be the RECOMMENDED solution. 477 10. References 479 10.1. Normative References 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 485 Jacobson, "RTP: A Transport Protocol for Real-Time 486 Applications", STD 64, RFC 3550, July 2003. 488 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 489 10646", STD 63, RFC 3629, November 2003. 491 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 492 Specifications: ABNF", STD 68, RFC 5234, January 2008. 494 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 495 Media Attributes in the Session Description Protocol 496 (SDP)", RFC 5576, June 2009. 498 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 499 "Guidelines for Choosing RTP Control Protocol (RTCP) 500 Canonical Names (CNAMEs)", RFC 7022, September 2013. 502 10.2. Informative References 504 [I-D.even-mmusic-application-token] 505 Even, R., Lennox, J., and Q. Wu, "The Session Description 506 Protocol (SDP) Application Token Attribute", 507 draft-even-mmusic-application-token-01 (work in progress), 508 September 2013. 510 [I-D.lennox-raiarea-rtp-grouping-taxonomy] 511 Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 512 B. Burman, "A Taxonomy of Grouping Semantics and 513 Mechanisms for Real-Time Transport Protocol (RTP) 514 Sources", draft-lennox-raiarea-rtp-grouping-taxonomy (work 515 in progress), October 2013. 517 [I-D.westerlund-avtcore-rtp-simulcast] 518 Westerlund, M. and B. Burman, "Using Simulcast in RTP 519 sessions", draft-westerlund-avtcore-rtp-simulcast (work in 520 progress), October 2013. 522 [I-D.westerlund-avtext-sdes-hdr-ext] 523 Westerlund, M., Burman, B., and R. Even, "RTP Header 524 Extension for RTCP Source Description Items", 525 draft-westerlund-avtext-sdes-hdr-ext (work in progress), 526 October 2013. 528 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 529 Streaming Protocol (RTSP)", RFC 2326, April 1998. 531 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 532 A., Peterson, J., Sparks, R., Handley, M., and E. 533 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 534 June 2002. 536 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 537 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 538 RFC 3711, March 2004. 540 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 541 Internet Protocol", RFC 4301, December 2005. 543 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 544 Description Protocol", RFC 4566, July 2006. 546 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 547 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 549 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 550 Header Extensions", RFC 5285, July 2008. 552 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 553 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 555 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 556 "RTP Payload Format for Scalable Video Coding", RFC 6190, 557 May 2011. 559 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 560 Security Version 1.2", RFC 6347, January 2012. 562 Authors' Addresses 564 Magnus Westerlund 565 Ericsson 566 Farogatan 6 567 SE-164 80 Kista 568 Sweden 570 Phone: +46 10 714 82 87 571 Email: magnus.westerlund@ericsson.com 573 Bo Burman 574 Ericsson 575 Farogatan 6 576 SE-164 80 Kista 577 Sweden 579 Phone: +46 10 714 13 11 580 Email: bo.burman@ericsson.com