idnits 2.17.1 draft-ietf-avt-rapid-rtp-sync-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2009) is 5411 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 (-19) exists of draft-ietf-avt-rtcpssm-18 ** Obsolete normative reference: RFC 5285 (ref. '6') (Obsoleted by RFC 8285) ** Obsolete normative reference: RFC 1305 (ref. '7') (Obsoleted by RFC 5905) == Outdated reference: A later version (-27) exists of draft-ietf-avt-rtp-svc-18 == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-05 == Outdated reference: A later version (-22) exists of draft-zimmermann-avt-zrtp-13 -- Obsolete informational reference (is this intentional?): RFC 5117 (ref. '15') (Obsoleted by RFC 7667) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Perkins 3 Internet-Draft University of Glasgow 4 Updates: RFC3550 T. Schierl 5 (if approved) Fraunhofer HHI 6 Intended status: Standards Track July 3, 2009 7 Expires: January 4, 2010 9 Rapid Synchronisation of RTP Flows 10 draft-ietf-avt-rapid-rtp-sync-04.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 4, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This memo outlines how RTP sessions are synchronised, and discusses 49 how rapidly such synchronisation can occur. We show that most RTP 50 sessions can be synchronised immediately, but that the use of video 51 switching multipoint conference units (MCUs) or large source specific 52 multicast (SSM) groups can greatly increase the synchronisation 53 delay. This increase in delay can be unacceptable to some 54 applications that use layered and/or multi-description codecs. 56 This memo introduces three mechanisms to reduce the synchronisation 57 delay for such sessions. First, it updates the RTP Control Protocol 58 (RTCP) timing rules to reduce the initial synchronisation delay for 59 SSM sessions. Second, a new feedback packet is defined for use with 60 the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), allowing 61 video switching MCUs to rapidly request resynchronisation. Finally, 62 new RTP header extensions are defined to allow rapid synchronisation 63 of late joiners, and guarantee correct timestamp based decoding order 64 recovery for layered codecs in the presence of clock skew. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Synchronisation of RTP Flows . . . . . . . . . . . . . . . . . 5 70 2.1. Initial Synchronisation Delay . . . . . . . . . . . . . . 6 71 2.1.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . 6 72 2.1.2. Source Specific Multicast (SSM) Sessions . . . . . . . 7 73 2.1.3. Any Source Multicast (ASM) Sessions . . . . . . . . . 8 74 2.1.4. Discussion . . . . . . . . . . . . . . . . . . . . . . 9 75 2.2. Synchronisation for Late Joiners . . . . . . . . . . . . . 10 76 3. Reducing RTP Synchronisation Delays . . . . . . . . . . . . . 10 77 3.1. Reduced Initial RTCP Interval for SSM Senders . . . . . . 11 78 3.2. Rapid Resynchronisation Request . . . . . . . . . . . . . 11 79 3.3. In-band Delivery of Synchronisation Metadata . . . . . . . 12 80 4. Application to Decoding Order Recovery in Layered Codecs . . . 14 81 4.1. Problem description . . . . . . . . . . . . . . . . . . . 14 82 4.2. In-band Synchronisation for Decoding Order Recovery . . . 15 83 4.3. Timestamp based decoding order recovery . . . . . . . . . 16 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 89 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 When using RTP to deliver multimedia content it's often necessary to 95 synchronise playout of audio and video components of a presentation. 96 This is achieved using information contained in RTP Control Protocol 97 (RTCP) Sender Report (SR) packets [1]. These are sent periodically, 98 and the components of a multimedia session cannot be synchronised 99 until sufficient RTCP SR packets have been received for each RTP flow 100 to allow the receiver to establish mappings between the media clock 101 used for each RTP flow, and the common (NTP-format) reference clock 102 used to establish synchronisation. 104 Recently, concern has been expressed that this synchronisation delay 105 is problematic for some applications, for example those using layered 106 or multi-description video coding. This memo reviews the operations 107 of RTP synchronisation, and describes the synchronisation delay that 108 can be expected. Three backwards compatible extensions to the basic 109 RTP synchronisation mechanism are proposed: 111 o The RTCP transmission timing rules are relaxed for SSM senders, to 112 reduce the initial synchronisation latency for large SSM groups. 113 See Section 3.1. 115 o An enhancement to the Extended RTP Profile for RTCP-based Feedback 116 (RTP/AVPF) [2] is defined to allow receivers to request additional 117 RTCP SR packets, providing the metadata needed to synchronise RTP 118 flows. This can reduce the synchronisation delay when joining 119 sessions with large RTCP reporting intervals, in the presence of 120 packet loss, or when video switching MCUs are employed. See 121 Section 3.2. 123 o Two RTP header extensions are defined, to deliver synchronisation 124 metadata in-band with RTP data packets. These extensions provide 125 synchronisation metadata that is aligned with RTP data packets, 126 and so eliminate the need to estimate clock-skew between flows 127 before synchronisation. They can also reduce the need to receive 128 RTCP SR packets before flows can be synchronising, although it 129 does not eliminate the need for RTCP. See Section 3.3. 131 The immediate use-case for these extensions is to reduce the delay 132 due to synchronisation when joining a layered video session (e.g. an 133 H.264/SVC session in NI-T mode [9]). The extensions are not specific 134 to layered coding, however, and can be used in any environment when 135 synchronisation latency is an issue. 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [3]. 141 2. Synchronisation of RTP Flows 143 RTP flows are synchronised by receivers based on information that is 144 contained in RTCP SR packets generated by senders (specifically, the 145 NTP-format timestamp and the RTP timestamp). Synchronisation 146 requires that a common reference clock MUST be used to generate the 147 NTP-format timestamps in a set of flows that are to be synchronised. 148 Furthermore, to achieve more rapid and accurate synchronisation, it 149 is RECOMMENDED that senders and receivers use a common reference 150 clock with common properties, especially timebase, where possible 151 (recognising that this is often not possible when RTP is used outside 152 of controlled environments); the means by which that common reference 153 clock and its properties are signalled and distributed is outside the 154 scope of this memo. 156 For multimedia sessions, each type of media (e.g. audio or video) is 157 sent in a separate RTP session, and the receiver associates RTP flows 158 to be synchronised by means of the canonical end-point identifier 159 (CNAME) item included in the RTCP Source Description (SDES) packets 160 generated by the sender or signalled out of band [10]. For layered 161 media, different layers can be sent in different RTP sessions, or 162 using different SSRC values within a single RTP session; in both 163 cases, the CNAME is used to identify flows to be synchronised. To 164 ensure synchronisation, an RTP sender MUST therefore send periodic 165 compound RTCP packets following Section 6 of RFC 3550 [1]. 167 The timing of these periodic compound RTCP packets will depend on the 168 number of members in each RTP session, the fraction of those that are 169 sending data, the session bandwidth, the configured RTCP bandwidth 170 fraction, and whether the session is multicast or unicast (see RFC 171 3550 Section 6.2 for details). In summary, RTCP control traffic is 172 allocated a small fraction, generally 5%, of the session bandwidth, 173 and of that fraction, one quarter is allocated to active RTP senders, 174 while receivers use the remaining three quarters (these fractions can 175 be configured via SDP [11]). Each member of an RTP session derives 176 an RTCP reporting interval based on these fractions, whether the 177 session is multicast or unicast, the number of members it has 178 observed, and whether it is actively sending data or not. It then 179 sends a compound RTCP packet on average once per reporting interval 180 (the actual packet transmission time is randomised in the range [0.5 181 ... 1.5] times the reporting interval to avoid synchronisation of 182 reports). 184 A minimum reporting interval of 5 seconds is RECOMMENDED, except that 185 the delay before sending the initial report "MAY be set to half the 186 minimum interval to allow quicker notification that the new 187 participant is present" [1]. Also, for unicast sessions, "the delay 188 before sending the initial compound RTCP packet MAY be zero" [1]. In 189 addition, for unicast sessions, and for active senders in a multicast 190 session, the fixed minimum reporting interval MAY be scaled to "360 191 divided by the session bandwidth in kilobits/second. This minimum is 192 smaller than 5 seconds for bandwidths greater than 72 kb/s." [1] 194 2.1. Initial Synchronisation Delay 196 A multimedia session comprises a set of concurrent RTP sessions among 197 a common group of participants, using one RTP session for each media 198 type. For example, a videoconference (which is a multimedia session) 199 might contain an audio RTP session and a video RTP session. To allow 200 a receiver to synchronise the components of a multimedia session, a 201 compound RTCP packet containing an RTCP SR packet and an RTCP SDES 202 packet with a CNAME item MUST be sent to each of the RTP sessions in 203 the multimedia session. A receiver cannot synchronise playout across 204 the multimedia session until such RTCP packets have been received on 205 all of the component RTP sessions. If there is no packet loss, this 206 gives an expected initial synchronisation delay equal to the average 207 time taken to receive the first RTCP packet in the RTP session with 208 the longest RTCP reporting interval. This will vary between unicast 209 and multicast RTP sessions. 211 The initial synchronisation delay for layered sessions is similar to 212 that for multimedia sessions. The layers cannot be synchronised 213 until the RTCP SR and CNAME information has been received for each 214 layer in the session. 216 2.1.1. Unicast Sessions 218 For unicast multimedia or layered sessions, senders SHOULD transmit 219 an initial compound RTCP packet (containing an RTCP SR packet and an 220 RTCP SDES packet with a CNAME item) immediately on joining each RTP 221 session in the multimedia session. The individual RTP sessions are 222 considered to be joined once any in-band signalling for NAT traversal 223 (e.g. [12]) and/or security keying (e.g. [13],[14]) has concluded, 224 and the media path is open. This implies that the initial RTCP 225 packet is sent in parallel with the first data packet following the 226 guidance in RFC 3550 that "the delay before sending the initial 227 compound RTCP packet MAY be zero" and, in the absence of any packet 228 loss, flows can be synchronised immediately. 230 Note that NAT pinholes, firewall holes, quality-of-service, and media 231 security keys should have been negotiated as part of the signalling, 232 whether in-band or out-of-band, before the first RTCP packet is sent. 233 This should ensure that any middleboxes are ready to accept traffic, 234 and reduce the likelihood that the initial RTCP packet will be lost. 236 2.1.2. Source Specific Multicast (SSM) Sessions 238 For multicast sessions, the delay before sending the initial RTCP 239 packet, and hence the synchronisation delay, varies with the session 240 bandwidth and the number of members in the session. For a multicast 241 multimedia or layered session, the average synchronisation delay will 242 depend on the slowest of the component RTP sessions; this will 243 generally be the session with the lowest bandwidth (assuming all the 244 RTP sessions have the same number of members). 246 When sending to a multicast group, the reduced minimum RTCP reporting 247 interval of 360 seconds divided by the session bandwidth in kilobits 248 per second [1] should be used when synchronisation latency is likely 249 to be an issue. Also, as usual, the reporting interval is halved for 250 the first RTCP packet. Depending on the session bandwidth and the 251 number of members, this gives the average synchronisation delays 252 shown in Figure 1. 254 Session| Number of receivers: 255 Bandwidth| 2 3 4 5 10 100 1000 10000 256 --+------------------------------------------------ 257 8 kbps| 2.73 4.10 5.47 5.47 5.47 5.47 5.47 5.47 258 16 kbps| 2.50 2.50 2.73 2.73 2.73 2.73 2.73 2.73 259 32 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50 260 64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50 261 128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41 262 256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70 263 512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35 264 1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18 265 2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09 266 4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 268 Figure 1: Average RTCP reporting interval in seconds for an RTP 269 Session with 1 sender. 271 These numbers assume a source specific multicast channel with a 272 single active sender, which the rules in RFC 3550 section 6.3 give a 273 fixed fraction of the RTCP bandwidth irrespective of the number of 274 receivers. It can be seen that they are sufficient for lip- 275 synchronisation without excessive delay, but might be viewed as 276 having too much latency for synchronising parts of a layered video 277 stream. 279 The RTCP interval is randomised in the usual manner, so the minimum 280 synchronisation delay will be half these intervals, and the maximum 281 delay will be 1.5 times these intervals. Note also that these RTCP 282 intervals are calculated assuming perfect knowledge of the number of 283 members in the session. 285 2.1.3. Any Source Multicast (ASM) Sessions 287 For ASM sessions, the fraction of members that are senders plays an 288 important role, and causes more variation in average RTCP reporting 289 interval. This is illustrated in Figure 2 and Figure 3, which show 290 the RTCP reporting interval for the same session bandwidths and 291 receiver populations as the SSM session described in Figure 1, but 292 for sessions with 2 and 10 senders respectively. It can be seen that 293 the initial synchronisation delay scales with the number of senders 294 (this is to ensure that the total RTCP traffic from all group members 295 does not grow without bound) and can be significantly larger than for 296 single source groups. Despite this, the initial synchronisation time 297 remains acceptable for lip-synchronisation in typical small-to-medium 298 sized group conferencing scenarios. 300 Session| Number of receivers: 301 Bandwidth| 2 3 4 5 10 100 1000 10000 302 --+------------------------------------------------ 303 8 kbps| 2.73 4.10 5.47 6.84 10.94 10.94 10.94 10.94 304 16 kbps| 2.50 2.50 2.73 3.42 5.47 5.47 5.47 5.47 305 32 kbps| 2.50 2.50 2.50 2.50 2.73 2.73 2.73 2.73 306 64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50 307 128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41 308 256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70 309 512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35 310 1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18 311 2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09 312 4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 314 Figure 2: Average RTCP reporting interval in seconds for an RTP 315 Session with 2 senders. 317 Session| Number of receivers: 318 Bandwidth| 2 3 4 5 10 100 1000 10000 319 --+------------------------------------------------ 320 8 kbps| 2.73 4.10 5.47 6.84 13.67 54.69 54.69 54.69 321 16 kbps| 2.50 2.50 2.73 3.42 6.84 27.34 27.34 27.34 322 32 kbps| 2.50 2.50 2.50 2.50 3.42 13.67 13.67 13.67 323 64 kbps| 2.50 2.50 2.50 2.50 2.50 6.84 6.84 6.84 324 128 kbps| 1.41 1.41 1.41 1.41 1.41 3.42 3.42 3.42 325 256 kbps| 0.70 0.70 0.70 0.70 0.70 1.71 1.71 1.71 326 512 kbps| 0.35 0.35 0.35 0.35 0.35 0.85 0.85 0.85 327 1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.43 0.43 0.43 328 2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.21 0.21 0.21 329 4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.11 0.11 0.11 331 Figure 3: Average RTCP reporting interval in seconds for an RTP 332 Session with 10 senders. 334 Note that multi-sender groups implemented using multi-unicast with a 335 central RTP translator (Topo-Translator in the terminology of [15]) 336 or mixer (Topo-Mixer), or some forms of video switching MCU (Topo- 337 Video-switch-MCU) distribute RTCP packets to all members of the 338 group, and so scale in the same way as an ASM group with regards to 339 initial synchronisation latency. 341 2.1.4. Discussion 343 For unicast sessions, the existing RTCP SR-based mechanism allows for 344 immediate synchronisation, provided the initial RTCP packet is not 345 lost. 347 For SSM sessions, the initial synchronisation delay is sufficient for 348 lip-synchronisation, but may be larger than desired for some layered 349 codecs. The rationale for not sending immediate RTCP packets for 350 multicast groups is to avoid implosion of requests when large numbers 351 of members simultaneously join the group ("flash crowd"). This is 352 not an issue for SSM senders, since there can be at most one sender, 353 so it is desirable to allow SSM senders to send an immediate RTCP SR 354 on joining a session (as is currently allowed for unicast sessions, 355 which also don't suffer from the implosion problem). SSM receivers 356 using unicast feedback would not be allowed to send immediate RTCP. 357 For ASM sessions, implosion of responses is a concern, so no change 358 is proposed to the RTCP timing rules. 360 In all cases, it is possible that the initial RTCP SR packet is lost. 361 In this case, the receiver will not be able to synchronise the media 362 until the reporting interval has passed, and the next RTCP SR packet 363 is sent. This is undesirable. Section 3.2 defines a new RTP/AVPF 364 transport layer feedback message to request an RTCP SR be generated, 365 allowing rapid resynchronisation in the case of packet loss. 367 2.2. Synchronisation for Late Joiners 369 Synchronisation between RTP sessions is potentially slower for late 370 joiners than for participants present at the start of the session. 371 The reasons for this are two-fold: 373 1. Many of the optimisations that allow rapid transmission of RTCP 374 SR packets apply only at the start of a session. This implies 375 that a new participant may have to wait a complete RTCP reporting 376 interval for each session before receiving the necessary data to 377 synchronise media streams. This might potentially take several 378 seconds, depending on the configured session bandwidth and the 379 number of participants. 381 2. Additional synchronisation delay comes from the nature of the 382 RTCP timing rules. Packets are generated on average once per 383 reporting interval, but with the exact transmission times being 384 randomised +/- 50% to avoid synchronisation of reports. This is 385 important to avoid network congestion in multicast sessions, but 386 does mean that the timing of RTCP SR reports for different RTP 387 sessions isn't synchronised. Accordingly, a receiver must 388 estimate the skew on the NTP-format clock in order to align RTP 389 timestamps across sessions. This estimation is an essential part 390 of an RTP synchronisation implementation, and can be done with 391 high accuracy given sufficient reports. Collecting sufficient 392 RTCP SR data to perform this estimation, however, may require 393 reception of several RTCP reports, further increasing the 394 synchronisation delay. 396 3. Many media codecs have the notion of periodic access points, such 397 that a newly joined receiver often cannot start decoding a media 398 stream until the packets corresponding to the access point have 399 been received. These access points may be sent less often than 400 RTCP SR packets, and so may be the limiting factor in starting 401 synchronised media playout for late joiners. 403 These delays are likely an issue for tuning in to an ongoing 404 multicast RTP session, or for video switching MCUs. 406 3. Reducing RTP Synchronisation Delays 408 Three backwards compatible RTP extensions are defined to reduce the 409 possible synchronisation delay: a reduced initial RTCP interval for 410 SSM senders, a rapid resynchronisation request message, and RTP 411 header extensions that can convey synchronisation metadata in-band. 413 3.1. Reduced Initial RTCP Interval for SSM Senders 415 In SSM sessions where the initial synchronisation delay is important, 416 the RTP sender MAY set the delay before sending the initial compound 417 RTCP packet to zero, and send its first RTCP packet immediately upon 418 joining the SSM session. RTP receivers in an SSM session, sending 419 unicast RTCP feedback, MUST NOT send RTCP packets with zero initial 420 delay; the timing rules defined in [4] apply unchanged to receivers. 422 3.2. Rapid Resynchronisation Request 424 The general format of an RTP/AVPF transport layer feedback message is 425 shown in Figure 4 (see [2] for details). 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 |V=2|P| FMT | PT=RTPFB=205 | length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | SSRC of packet sender | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | SSRC of media source | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 : Feedback Control Information (FCI) : 437 : : 439 Figure 4: RTP/AVP Transport Layer Feedback Message 441 A new feedback message type, RTCP-SR-REQ, is defined with FMT = 5. 442 The Feedback Control Information (FCI) part of the feedback message 443 MUST be empty. The SSRC of packet sender indicates the member that 444 is unable to synchronise media streams, while the SSRC of media 445 source indicates the sender of the media it is unable to synchronise. 446 The length MUST equal 2. 448 This feedback message MAY be sent by a receiver to indicate that it's 449 unable to synchronise some media streams, and desires that the media 450 source transmit an RTCP SR packet as soon as possible (within the 451 constraints of the RTCP timing rules for early feedback). When it 452 receives such an indication, the media source SHOULD generate an RTCP 453 SR packet as soon as possible within the RTCP early feedback rules. 454 If the use of non-compound RTCP [5] was previously negotiated, both 455 the feedback request and the RTCP SR response may be sent as non- 456 compound RTCP packets. The RTCP-SR-REQ packet MAY be repeated once 457 per RTCP reporting interval if no RTCP SR packet is forthcoming. 459 When using SSM sessions with unicast feedback, is possible that the 460 feedback target and media source are not co-located. If a feedback 461 target receives an RTCP-SR-REQ feedback message in such a case, the 462 request should be forwarded to the media source. The mechanism to be 463 used for forwarding such requests is not defined here. 465 3.3. In-band Delivery of Synchronisation Metadata 467 The RTP header extension mechanism defined in [6] can be adopted to 468 carry an OPTIONAL NTP format timestamp in RTP data packets. If such 469 a timestamp is included, it MUST correspond to the same time instant 470 as the RTP timestamp in the packet's header, and MUST be derived from 471 the same clock used to generate the NTP format timestamps included in 472 RTCP SR packets. Provided it has knowledge of the SSRC to CNAME 473 mapping, either from prior receipt of an RTCP CNAME packet or via 474 out-of-band signalling [10], the receiver can use the information 475 provided as input to the synchronisation algorithm, in exactly the 476 same way as if an additional RTCP SR packet was been received for the 477 flow. 479 Two variants are defined for this header extension. The first 480 variant extends the RTP header with a 64 bit NTP timestamp format 481 timestamp as defined in [7]. The second variant carries the lower 24 482 bit part of the Seconds of a NTP timestamp format timestamp and the 483 32 bit of the Fraction of a NTP timestamp format timestamp. The 484 formats of the two variants are shown below. 486 Variant A/64-bit NTP RTP header extension (length: 16 bytes): 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 |V=2|P|1| CC |M| PT | sequence number | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R 493 | timestamp |T 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P 495 | synchronization source (SSRC) identifier | 496 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 497 | 0xBE | 0xDE | length=3 | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E 499 | ID-A | L=7 | NTP timestamp format - Seconds (bit 0-23) |x 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t 501 |NTP Sec.(24-31)| NTP timestamp format - Fraction(bit 0-23) |n 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 |NTP Frc.(24-31)| 0 (pad) | 0 (pad) | 0 (pad) | 504 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 505 | payload data | 506 | .... | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Variant B/56-bit NTP RTP header extension (length: 12 bytes): 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 |V=2|P|1| CC |M| PT | sequence number | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R 516 | timestamp |T 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P 518 | synchronization source (SSRC) identifier | 519 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 520 | 0xBE | 0xDE | length=2 | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E 522 | ID-B | L=6 | NTP timestamp format - Seconds (bit 8-31) |x 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t 524 | NTP timestamp format - Fraction (bit 0-31) |n 525 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 526 | payload data | 527 | .... | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 An NTP timestamp format timestamp MAY be included on any RTP packets 531 the sender chooses, but it is RECOMMENDED when performing timestamp 532 based decoding order recovery for layered codecs transported in 533 multiple RTP flows, as further specified in Section 4.2. This header 534 extension SHOULD be also sent on the RTP packets corresponding to a 535 video random access point, and on the associated audio packets, to 536 allow rapid synchronisation for late joiners in multimedia sessions, 537 and in video switching scenarios. 539 Note: The inclusion of an RTP header extension will reduce the 540 efficiency of RTP header compression, if it is used. Furthermore, 541 middle boxes which do not understand the header extensions may remove 542 them or may not update the content according to this memo. 544 In all cases, irrespective of whether in-band NTP timestamp format 545 timestamps are included or not, regular RTCP SR packets MUST be sent 546 to provide backwards compatibility with receivers that synchronize 547 RTP flows according to [1], and robustness in the face of middleboxes 548 (RTP translators) that might strip RTP header extensions. The sender 549 reports are also required to receive the upper 8 bit of the Seconds 550 of the NTP timestamp format timestamp not included in the Variant 551 B/56-bit NTP RTP header extension (although this may generally be 552 inferred from context). 554 When the SDP is used, the use of the RTP header extensions defined 555 above MUST be indicated as specified in [6]. Therefore the following 556 URIs MUST be used: 558 o The URI used for signaling the use of Variant A/64-bit NTP RTP 559 header extension in SDP is "urn:ietf:params:rtp-hdrext:ntp-64". 561 o The URI used for signaling the use of Variant B/56-bit NTP RTP 562 header extension in SDP is "urn:ietf:params:rtp-hdrext:ntp-56". 564 4. Application to Decoding Order Recovery in Layered Codecs 566 Based on the timestamp contained in each RTP data packet, and the 567 mapping to an NTP format timestamp, a decoding order recovery process 568 may be applied if a media as result of a layered coding process is 569 transported in multiple RTP flows. This recovers the decoding order 570 of media frames or samples at the receiver. Especially when 571 transporting layered video, the decoding order recovery process is 572 not straight forward. In this section, we provide guidance on how to 573 use RTP/NTP timing information for decoding order recovery. 575 4.1. Problem description 577 One option for decoding order recovery in layered codecs is to use 578 the NTP/sample presentation timestamps to reorder data of the same 579 layered media transported in multiple RTP flows. For a timestamp- 580 based decoding order recovery process, it is crucial to allow exact 581 alignment of media frames respectively samples using the NTP timing 582 information. 584 In the presence of clock skew in NTP-format clock, it may not be 585 possible to derive exact matching NTP timestamps using the NTP format 586 clock in each RTP flow's RTCP sender reports. This is due to the 587 fact that RTCP sender reports are not sent at the same point of time 588 in the multiple RTP flows transporting data of the same layered 589 media, while having a skew between those samples in the RTP flows 590 RTCP sender reports. If the RTCP SR packets are not send 591 synchronously in the multiple RTP flows, they therefore do not 592 contain the same NTP-format timestamp. If there is a skew present in 593 the clock used for NTP-format timestamp generation, using different 594 NTP-format timestamps for the same sampling instance in the RTP flow 595 inevitably leads to non-matching NTP timestamps generated from RTP 596 timestamps and NTP-format timestamps in the multiple RTP flows. In 597 order to allow a common and straight forward timestamp-based decoding 598 order recovery process, it is important to guarantee exact matching 599 of NTP timestamps. Thus in the presence of non-perfect clocks, which 600 should be the normal case, an additional mechanism SHALL be used. An 601 exact inter-flow alignment of NTP timestamps can be guaranteed, if an 602 RTP header extension containing an NTP timestamp is always inserted 603 at the same timing position in all the RTP flows in question, and if 604 those NTP header extensions are used to update the NTP-RTP relation 605 in all RTP flows at the same point of time. This is called 606 synchronous insertion of RTP header extensions in the following. 608 4.2. In-band Synchronisation for Decoding Order Recovery 610 The RTP header extension to convey an NTP timestamp SHOULD be used 611 with a layered, multi-description, or multi-view codec, to provide 612 exact matching of NTP timestamps between layers, descriptions, or 613 views transported in different RTP flows to allow timestamp-based 614 decoding order recovery. If this header extension is inserted for 615 RTP flows transporting samples or parts of samples of the same 616 layered media, it SHALL be included at least once in each of the RTP 617 flows of the same media for the sampling time instance of an 618 insertion of an RTP header extension. Such synchronously inserted 619 RTP header extensions SHALL contain the same NTP format timestamp. 620 The frequency of inserting the header extensions in the RTP flows is 621 up to the sender, but it should be noticed that higher insertion 622 frequencies obviously lead to higher synchronization frequencies. 623 For use cases where the same clock source has been used to generate 624 the RTP timestamps in the multiple RTP flows, an application MAY rely 625 on the RTP timestamps only for decoding order recovery starting from 626 the point of synchronous insertion of the RTP header extensions 627 containing NTP timestamps. 629 Note: If the decoding order of RTP flows is given by any means (as 630 e.g., for RTP session by mechanism defined in [8]), the NTP timestamp 631 provided by the header extension allows to collect data of the same 632 sample from the RTP flows, forming the sample decoding order. There 633 may be future mechanism to allow indication of dependencies of RTP 634 flows transported as RTP streams using SSRC multiplexing 636 It is RECOMMENDED that the receiver uses for timestamp-based decoding 637 order recovery the NTP timestamps provided in the RTP header 638 extensions only, if such extensions are present for the RTP flows. 639 Section 4.3 gives further details about the timestamp-based decoding 640 order recovery. 642 Note: Using the RTP header extensions described above allows the 643 receiver to find the corresponding sample of the layered media, or 644 parts thereof, in all RTP flows at the instant the RTP header 645 extension is inserted into the flows. This guarantees that any clock 646 skew present in the NTP timestamp generation process based on RTCP 647 sender reports is avoided, and so allows direct comparison of NTP 648 timestamps across multiple RTP flows. Furthermore, this approach 649 solves the possible problem of clock skews identified for the NI-T 650 mode as defined in [9]. To ensure the absence of clock skew, a 651 header extension containing the NTP timestamp MUST be inserted into 652 the RTP flows comprising a layered media stream at the same instant 653 in each RTP flow. This may require the insertion of extra packets in 654 some of the RTP flows, since in layered video codecs not all sampling 655 instances may be present in all the flows. If such a header 656 extension is included in all flows at a sampling time instance, the 657 NTP timestamps for samples following in decoding order the RTP header 658 insertion point can be constructed using the RTP timestamps and 659 identical reference NTP timestamps in the NTP header extension in all 660 RTP flows. It should be noted that the frequency of inserting the 661 RTP header extension containing the NTP timestamp is crucial in 662 presence of clock skew, since the points of insertion may be the only 663 points for a receiver to start the decoding order recovery. 665 4.3. Timestamp based decoding order recovery 667 If parts or complete samples as result of a layered coding process 668 are transported as different RTP flows, i.e. as different RTP 669 streams, and/or as different RTP sessions, a decoding order recovery 670 process is required to reorder the samples or parts of samples 671 received. Such mechanism may be based on the NTP presentation 672 timestamp which can be derived from the RTP timestamp using the NTP- 673 format timestamp provided in the RTCP sender report packets. 675 In order to guarantee the exact alignment of those derived NTP 676 presentation timestamps, the RTP header extension as defined in this 677 memo in Section 3.3 allows the receiver to start the decoding order 678 recovery before the reception of a RTCP sender report if the RTP 679 header extension is earlier provided in the RTP flow. Using the RTP 680 header extensions may be the only way to allow correct decoding order 681 recovery based on exact matching of NTP timestamps in the presence of 682 clock skew in the clock used for generating the NTP format clock. 684 Furthermore, some use cases may allow to use synchronously inserted 685 RTP header extensions containing NTP timestamps to align the RTP 686 timestamps of the multiple RTP flows, i.e. use cases where the RTP 687 timestamps of the multiple RTP flows are generated from the same 688 clock source. In such use cases, starting from a synchronous 689 insertion of the RTP header extensions, the application may use the 690 detected difference of RTP random offset values in the multiple 691 sessions to align the media samples of parts of samples. 693 Since typically for layered video codecs as, e.g. SVC [9], the 694 decoding order is not equal to the presentation order of the media 695 samples, media samples or parts of media samples cannot be simply 696 ordered according to the presentation timestamp order. For this 697 reason, if transporting media samples or parts of media samples of a 698 layered, multi-view or multi description codec in different RTP 699 flows, the following rules SHOULD be kept for sending such flows: 701 Note: The following rules are typically kept for layered audio 702 codecs, which allows using the same algorithm for decoding order 703 recovery of audio samples. 705 Terminology: Following the decoding order of RTP flows as described 706 above, an RTP flow containing sample data which is required to be 707 accessed and/or decoded before decoding a second sample data of 708 another RTP flow is called a lower RTP flow with respect to the 709 second RTP flow. A second RTP flow, which requires for the decoding 710 process accessing and/or decoding the sample data of the lower RTP 711 flow is called the higher RTP flow. The lowest RTP flow is the flow, 712 which does not require the presence of any other data. 714 o The decoding order of media samples or part of the media samples 715 transported in different RTP flows SHOULD be derivable by any 716 means. This can be accomplished, e.g. by using the mechanisms 717 defined in [8] if the sample data or parts of the sample data are 718 transported in different RTP sessions or by any other means. 720 o For each two RTP flows the following rules SHOULD be true in order 721 to allow decoding order recovery based on matching NTP timestamps 722 present in the different RTP flows: 724 1. The order of the RTP samples within an RTP flow is equal to 725 the decoding order. 727 2. A higher RTP flow contains all the same sampling instances of 728 the lower RTP flow. A higher RTP flow may contain additional 729 sampling instances. 731 Note: In some cases, it may be required to add packets in higher RTP 732 flows in order to satisfy the second rule above. This may be 733 achieved by placing empty RTP packets (containing padding data only) 734 or by other payload means as, e.g. the Empty NAL unit packet as 735 defined in [9]. 737 If a packet must be inserted for satisfying the above rule, the NTP 738 timestamp of such an inserted packet MUST be set equal to the NTP 739 timestamp of a packet of the same sample present in any lower RTP 740 flow and the lowest RTP flow. This is easy to accomplish if the 741 packet can be inserted at the time of the RTP flow generation, since 742 the NTP timestamp must be the same for the inserted packet and the 743 packet of the corresponding sample. 745 The above rules allow the receiver to process the data of the RTP 746 flows as follows: 748 o Go through all received RTP flows starting with the highest RTP 749 flow and aggregate the sample data or parts of the sample data 750 with the same NTP timestamp in the order of RTP flows, starting 751 from the lowest RTP flow up to the highest RTP flow received, to 752 the sample with the NTP timestamp present in the highest RTP flow. 753 The NTP timestamps MAY be derived using RTCP sender reports or MAY 754 be directly taken from the NTP timestamp provided in an RTP header 755 extension. The order of RTP flows may e.g. be indicated by 756 mechanisms as defined in [8] or any other implicit or explicit 757 means. Repeat the aforementioned process for each different NTP 758 timestamp present in the highest RTP flow. 760 Informative example: The example shown in Figure 3 refers to three 761 RTP flows A, B and C containing a layered, a multi-view or a multi- 762 description media stream. In the example, the dependency signalling 763 as defined in [8] indicates that flow A is the lowest RTP flow, B is 764 the first higher RTP flow and depends on A, and C is the second 765 higher RTP flow corresponding to flow A and depends on A and B. A 766 media coding structure is used that results in samples present in 767 higher flows but not present in all lower flows. Flow A has the 768 lowest frame rate and Flow B and C have the same but higher frame 769 rate. The figure shows the full video samples with their 770 corresponding RTP timestamps "(x)". The video samples are already 771 re-ordered according to their RTP sequence number order. The figure 772 indicates for the received sample in decoding order within each RTP 773 flow, as well as the associated NTP media timestamps ("TS[..]"). 774 These timestamps may be derived using the NTP format timestamp 775 provided in the RTCP sender reports or as shown in the figure 776 directly from the NTP timestamp contained in the RTP header 777 extensions as indicate by the timestamp in "". Note that the 778 timestamps are not in increasing order since, in this example, the 779 decoding order is different from the output/presentation order. 781 The process first proceeds to the sample parts associated with the 782 first available synchronous insertion of NTP timestamp into RTP 783 header extensions at NTP media timestamp TS=[8] and starts in the 784 highest RTP flow C and removes/ignores all preceding sample parts (in 785 decoding order) to sample parts with TS=[8] in each of the de- 786 jittering buffers of RTP flows A, B, and C. Then, starting from flow 787 C, the first media timestamp available in decoding order (TS=[8]) is 788 selected and sample parts starting from RTP flow A, and flow B and C 789 are placed in order of the RTP flow dependency as indicated by 790 mechanisms defined in [8] (in the example for TS[8]: first flow B and 791 then flow C into the video sample VS(TS[8]) associated with NTP media 792 timestamp TS=[8]. Then the next media timestamp TS=[6] (RTP 793 timestamp=(4)) in order of appearance in the highest RTP flow C is 794 processed and the process described above is repeated. Note that 795 there may be video samples with no sample parts present, e.g., in the 796 lowest RTP flow A (see, e.g., TS=[5]). The decoding order recovery 797 process could be also started after receiving all RTP sender reports 798 RTP timestamp to NTP-format timestamp mapping (indicated as 799 timestamps "(x){y}") assuming that there is no clock skew in the 800 source used for the NTP-format timestamp generation. 802 C:-(0)----(2)----(7)<8>--(5)----(4)----(6)-----(11)----(9){10}- 803 | | | | | | | | 804 B:-(3)----(5)---(10)<8>--(8)----(7)----(9){7}--(14)----(12)---- 805 | | | | 806 A:---------------(3)<8>--(1)-------------------(7){12}-(5)----- 808 ---------------------------------------decoding/transmission order-> 809 TS:[1] [3] [8]=<8> [6] [5] [7] [12] [10] 811 Key: 812 A, B, C - RTP flows 813 Integer values in "()"- video sample with its RTP timestamp as 814 indicated in its RTP packet. 815 "|" - indicates corresponding samples / parts of 816 sample of the same video sample VS(TS[..]) 817 in the RTP flows. 818 Integer values in "[]"- NTP media timestamp TS, sampling time 819 as derived from the NTP timestamp associated 820 with the video sample AU(TS[..]), consisting 821 of sample parts in the flows above. 822 Integer values in "<>"- NTP media timestamp TS as directly 823 taken from the NTP RTP header extensions. 824 Integer values in "{}"- NTP media timestamp TS as provided in the 825 RTCP sender reports. 827 5. Security Considerations 829 The security considerations of the RTP specification [1], the 830 Extended RTP profile for RTCP-Based Feedback [2], and the General 831 Mechanism for RTP Header Extensions [6] apply. The extensions we 832 define in this memo are not believed to introduce any additional 833 security considerations. 835 6. IANA Considerations 837 NOTE TO RFC EDITOR: Please replace "RFC XXXX" in the following with 838 the RFC number assigned to this memo, and delete this note. 840 The IANA is requested to register one new value in the table of FMT 841 Values for RTPFB Payload Types [2] as follows: 843 Name: RTCP-SR-REQ 844 Long name: RTCP Rapid Resynchronisation Request 845 Value: 5 846 Reference: RFC XXXX 848 The IANA is also requested to register two new RTP Compact Header 849 Extensions [6], according to the following: 851 Extension URI: urn:ietf:params:rtp-hdrext:ntp-64 852 Description: Synchronisation metadata: 64-bit timestamp format 853 Contact: Thomas Schierl 854 IETF Audio/Video Transport Working Group 855 Reference: RFC XXXX 857 Extension URI: urn:ietf:params:rtp-hdrext:ntp-56 858 Description: Synchronisation metadata: 56-bit timestamp format 859 Contact: Thomas Schierl 860 IETF Audio/Video Transport Working Group 861 Reference: RFC XXXX 863 7. Acknowledgements 865 This memo has benefitted from discussions with numerous members of 866 the IETF AVT working group, including Jonathan Lennox, Magnus 867 Westerlund, Randell Jesup, Gerard Babonneau, Ingemar Johansson, Ali 868 C. Begen, Ye-Kui Wang, Roni Even, Michael Dolan, and Art Allison. 869 The header extension format of Variant A in Section 3.3 was suggested 870 by Dave Singer, matching a similar mechanism specified by ISMA. 872 8. References 874 8.1. Normative References 876 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 877 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 878 RFC 3550, July 2003. 880 [2] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 881 "Extended RTP Profile for Real-time Transport Control Protocol 882 (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. 884 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 885 Levels", BCP 14, RFC 2119, March 1997. 887 [4] Schooler, E., Ott, J., and J. Chesterfield, "RTCP Extensions 888 for Single-Source Multicast Sessions with Unicast Feedback", 889 draft-ietf-avt-rtcpssm-18 (work in progress), March 2009. 891 [5] Johansson, I. and M. Westerlund, "Support for Reduced-Size 892 Real-Time Transport Control Protocol (RTCP): Opportunities and 893 Consequences", RFC 5506, April 2009. 895 [6] Singer, D. and H. Desineni, "A General Mechanism for RTP Header 896 Extensions", RFC 5285, July 2008. 898 [7] Mills, D., "Network Time Protocol (Version 3) Specification, 899 Implementation", RFC 1305, March 1992. 901 [8] Schierl, T. and S. Wenger, "Signaling media decoding dependency 902 in Session Description Protocol (SDP)", 903 draft-ietf-mmusic-decoding-dependency-08 (work in progress), 904 April 2009. 906 8.2. Informative References 908 [9] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP 909 Payload Format for SVC Video", draft-ietf-avt-rtp-svc-18 (work 910 in progress), March 2009. 912 [10] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media 913 Attributes in the Session Description Protocol (SDP)", 914 draft-ietf-mmusic-sdp-source-attributes-02 (work in progress), 915 October 2008. 917 [11] Casner, S., "Session Description Protocol (SDP) Bandwidth 918 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 919 July 2003. 921 [12] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 922 Protocol for Network Address Translator (NAT) Traversal for 923 Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in 924 progress), October 2007. 926 [13] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security 927 (DTLS) Extension to Establish Keys for Secure Real-time 928 Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-05 (work 929 in progress), September 2008. 931 [14] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path 932 Key Agreement for Secure RTP", draft-zimmermann-avt-zrtp-13 933 (work in progress), January 2009. 935 [15] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 936 January 2008. 938 Authors' Addresses 940 Colin Perkins 941 University of Glasgow 942 Department of Computing Science 943 Sir Alwyn Williams Building 944 Lilybank Gardens 945 Glasgow G12 8QQ 946 UK 948 Email: csp@csperkins.org 950 Thomas Schierl 951 Fraunhofer HHI 952 Einsteinufer 37 953 D-10587 Berlin 954 Germany 956 Phone: +49-30-31002-227 957 Email: Thomas.Schierl@hhi.fraunhofer.de