idnits 2.17.1 draft-spittka-silk-payload-format-00.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.ii 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 : ---------------------------------------------------------------------------- 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 (July 6, 2009) is 5400 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2326 (Obsoleted by RFC 7826) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Spittka 3 Internet-Draft H. Astrom 4 Intended status: Informational K. Vos 5 Expires: January 7, 2010 Skype Technologies S.A. 6 July 6, 2009 8 RTP Payload Format and File Storage Format for SILK Speech and Audio 9 Codec 10 draft-spittka-silk-payload-format-00.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 7, 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 document defines the Real-time Transport Protocol (RTP) payload 49 format and file storage format for packetization of SILK encoded 50 speech and audio data that is essential to implement SILK in the most 51 compatible way. Further, media type registrations are described for 52 the RTP payload format and the file storage format. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions, Definitions and Acronyms used in this document . 4 58 3. SILK Codec . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Adaptive Network Bit Rate . . . . . . . . . . . . . . . . 6 60 3.2. Discontinuous Transmission (DTX) . . . . . . . . . . . . . 6 61 3.3. Forward Error Correction (FEC) . . . . . . . . . . . . . . 7 62 4. SILK RTP Payload Format . . . . . . . . . . . . . . . . . . . 8 63 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 8 64 4.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 8 65 5. SILK Storage Format . . . . . . . . . . . . . . . . . . . . . 9 66 5.1. Storage Header Structure . . . . . . . . . . . . . . . . . 9 67 5.2. Storage Block Structure . . . . . . . . . . . . . . . . . 9 68 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 11 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 7.1. SILK Media Type Registration . . . . . . . . . . . . . . . 12 71 7.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 14 72 7.2.1. Offer-Answer Model Considerations for SILK . . . . . . 15 73 7.2.2. Declarative SDP Considerations for SILK . . . . . . . 16 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 76 10. Normative References . . . . . . . . . . . . . . . . . . . . . 19 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 79 1. Introduction 81 SILK is a speech and audio codec developed internally at Skype which 82 is used as the new default codec for all Skype to Skype calls. It is 83 highly scalable in terms of audio bandwidth, network bit rate, and 84 complexity, making it the codec of choice for multiple modes and 85 applications. 87 Skype encourages 3rd party partners to adopt SILK for applications 88 that may or may not be able to inter-operate with the Skype network. 89 Therefore, this document defines the Real-time Transport Protocol 90 (RTP) [RFC3550] payload format and file storage format for 91 packetization of SILK encoded speech and audio data that is essential 92 to implement SILK in the most compatible way. Further, media type 93 registrations are described for the RTP payload format and the file 94 storage format. More information about SILK can be obtained at 95 https://developer.skype.com/silk. 97 2. Conventions, Definitions and Acronyms used in this document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 CPU: Central Processing Unit 104 IP: Internet Protocol 105 PSTN: Public Switched Telephone Network 106 Samples: Speech or audio samples 107 SDP: Session Description Protocol 109 3. SILK Codec 111 The SILK speech and audio codec is highly scalable in terms of audio 112 bandwidth, network bit rate, and complexity. 114 SILK supports four different audio bandwidths, narrowband at 8000 Hz 115 sampling frequency, mediumband at 12000 Hz sampling frequency, 116 wideband at 16000 Hz sampling frequency, and super wideband at 24000 117 Hz sampling frequency. Narrowband mode SHOULD only be used to 118 interface to PSTN networks or on low end devices that do not support 119 greater than 8000 Hz sampling frequency. Mediumband mode SHOULD be 120 used for lower end devices that do not support greater than 12000 Hz 121 sampling frequency or are under severe network bandwidth constrains 122 (e.g. wireless devices). Wideband mode SHOULD be used for all-IP 123 platforms that do not support greater than 16000 Hz sampling 124 frequency. Super wideband mode SHOULD be used on all platforms that 125 support 24000 Hz and greater sampling frequency. 127 The network bit rate is adaptive within the range specified in 128 Table 1 for corresponding audio bandwidths. The average network bit 129 rate can be defined and modified in real-time while the actual bit 130 rate will be dependent on the input signal and change over time. 132 +----------------+---------+-----------+ 133 | | fs (Hz) | BR (kbps) | 134 +----------------+---------+-----------+ 135 | Narrowband | 8000 | 6 - 20 | 136 | | | | 137 | Mediumband | 12000 | 7 - 25 | 138 | | | | 139 | Wideband | 16000 | 8 - 30 | 140 | | | | 141 | Super Wideband | 24000 | 12 - 40 | 142 +----------------+---------+-----------+ 144 fs specifies the audio sampling frequency in Hertz (Hz); BR specifies 145 the adaptive bit rate range in kilobits per second (kbps). 147 Table 1 149 Complexity can be scaled to optimize for CPU resources in real-time, 150 mostly in trade-off to network bit rate. 152 The internal frame size of SILK is 20 ms. The SILK Encoder can be 153 set to bundle up to five internal frames into a single frame output, 154 allowing for 20, 40, 60, 80, or 100 ms frames of encoded speech or 155 audio data. 157 Table 2 below shows the number of samples contained in one frame of 158 speech or audio, for the various frame sizes and sampling rates. 160 +------------------------+------+------+------+------+-------+ 161 | Frame size | 20ms | 40ms | 60ms | 80ms | 100ms | 162 +------------------------+------+------+------+------+-------+ 163 | Narrowband samples | 160 | 320 | 480 | 640 | 800 | 164 | | | | | | | 165 | Mediumband samples | 240 | 480 | 720 | 960 | 1200 | 166 | | | | | | | 167 | Wideband samples | 320 | 640 | 960 | 1280 | 1600 | 168 | | | | | | | 169 | Super Wideband samples | 480 | 960 | 1440 | 1920 | 2400 | 170 +------------------------+------+------+------+------+-------+ 172 Samples contained in one frame, for different frame sizes and 173 sampling rates. 175 Table 2 177 SILK operates at a very low algorithmic delay, consisting of 178 packetization delay, i.e. 20, 40, 60, 80, or 100ms, plus 5ms look- 179 ahead delay. 181 3.1. Adaptive Network Bit Rate 183 The SILK Encoder can be set to output encoded speech or audio data at 184 a defined average bit rate. Since the achieved bit rate for each 185 frame varies with the complexity and perceptual importance of the 186 input audio or speech signal, the specified average bit rate is for 187 an active, i.e. non-silent, signal. The average bit rate can be 188 adjusted on a per frame basis. This allows support for congestion 189 control and network load management. To do this efficiently, 190 information about the capacity of a channel or storage device has to 191 be available. There are various methods to obtain this information 192 that are outside the scope of this document. 194 3.2. Discontinuous Transmission (DTX) 196 The SILK codec is, as described in Section 3.1 of this document, a 197 codec with adaptive bit rate. The bit rate will automatically be 198 reduced for certain input signals like periods of silence. During 199 continuous transmission mode the bit rate will be reduced, when the 200 input signal allows to do so, but the transmission to the receiver 201 itself is not interrupted. Therefore, the received signal will 202 maintain the same high level of quality over the full duration of a 203 transmission while minimizing the average bit rate over time. 205 In cases where the average bit rate of SILK needs to be reduced even 206 further, the SILK encoder may be set to use a discontinuous 207 transmission mode (DTX), where parts of the encoded signal that 208 correspond to periods of silence in the input speech or audio signal 209 are not transmitted to the receiver. 211 On the receiving side, the non-transmitted parts will be handled by a 212 frame loss concealment unit in the SILK decoder which generates a 213 comfort noise signal to replace the non transmitted parts of the 214 speech or audio signal. 216 The DTX mode of SILK will have a slightly lower speech or audio 217 quality than the continuous mode. Therefore, it is RECOMMENDED to 218 use SILK in the continuous mode unless restraints of network 219 bandwidth are severe. 221 3.3. Forward Error Correction (FEC) 223 TBD 225 4. SILK RTP Payload Format 227 The payload format for SILK consists of the RTP header and SILK 228 payload data. 230 4.1. RTP Header Usage 232 The format of the RTP header is specified in [RFC3550]. The SILK 233 payload format uses the fields of the RTP header consistent with this 234 specification. 236 The payload length of SILK is a multiple number of octets and 237 therefore no padding is required. The payload MAY be padded by an 238 integer number of octets according to [RFC3550]. 240 The marker bit (M) of the RTP header has no function in combination 241 with SILK and MAY be ignored. 243 The RTP payload type for SILK has not been assigned statically and is 244 expected to be assigned dynamically. 246 The receiving side MUST be prepared to receive duplicates of RTP 247 packets. Only one of those payloads MUST be provided to the SILK 248 decoder for decoding and others MUST be discarded. 250 Depending on what mode of sampling frequency is used for SILK, 8000, 251 12000, 16000, or 24000 Hz, the RTP timestamp clock frequency has to 252 be adjusted accordingly and is the same as the sampling frequency. 253 The unit for the timestamp is samples. The RTP timestamp corresponds 254 to the sample time of the first encoded sample in the encoded frame. 255 Therefore, the timestamp is increased by the number of samples 256 provided in Table 2, depending on the sampling frequency and frame 257 size. 259 4.2. Payload Structure 261 The SILK encoder can be set to output encoded frames representing 20, 262 40, 60, 80, or 100 ms of speech or audio data. Only one frame output 263 from the encoder MUST be used as the payload. Figure 1 shows the 264 structure combined with the RTP header. 266 +----------+--------------+ 267 |RTP Header| SILK Payload | 268 +----------+--------------+ 270 Figure 1: Payload Structure with RTP header 272 5. SILK Storage Format 274 The SILK storage format allows to store SILK encoded data into e.g. a 275 file or an email attachment. The storage format consists of a header 276 and a series of blocks containing encoded speech or audio frames. 277 The storage format closely mimics the real-time payload format. 279 Figure 2 shows an example of a SILK encoded file. Note that due to 280 the adaptive bit rate and therefore variable frame length of SILK no 281 fixed block size can be defined for blocks containing encoded data. 283 +------------------+ 284 | Header | 285 +-----------+------+ 286 | block 1 | 287 +-----------+--+ 288 | block 2 | 289 +--------------+--+ 290 : ... : 291 +--------------+--+ 292 | block n | 293 +-----------------+ 295 Figure 2: Example of SILK file storage format showing different block 296 lengths due to adaptive bit rate of SILK 298 5.1. Storage Header Structure 300 A SILK storage header contains the following ASCII character string 301 as a magic number: 303 "#!SILK\n" (hexadecimal: 0x23 0x21 0x53 0x49 0x4C 0x4B 0x0A) 305 5.2. Storage Block Structure 307 Following the storage header, blocks of encoded data are stored in 308 consecutive order in time according to Figure 2. Each block contains 309 a block header followed by a payload according to Figure 3. 311 The block header contains information that, for an RTP-based session, 312 can be derived from the IP and RTP headers: SILK sample rate, the 313 number of octets contained in the subsequent payload and the RTP time 314 stamp. 316 The sample rate is specified by three bits with the following bit 317 convention: 319 000: SILK Narrowband 8000 Hz 320 001: SILK Mediumband 12000 Hz 321 010: SILK Wideband 16000 Hz 322 011: SILK Super Wideband 24000 Hz 324 Other values are reserved for future use and blocks where these 325 appear MUST be discarded. 327 Further, the number of octets in the payload is represented by 13 328 bits and the timestamp is specified by 32 bits. For the first block, 329 the timestamp MAY be a random number. For the following blocks, the 330 timestamp MUST be incremented according to the way timestamps are 331 incremented when SILK payloads are transmitted over RTP. 333 0 3 16 48 334 +----+--------------+----------------------------+----------------- 335 |Mode| # of octets | Timestamp | Payload 336 +----+--------------+----------------------------+----------------- 338 Figure 3: Storage block header structure 340 The payload of each block in Figure 2 represents one frame of SILK 341 encoded data representing 20, 40, 60, 80, or 100 ms speech or audio 342 data. 344 During the usage of DTX no blocks are stored when the channel is 345 inactive. Timestamps MUST be used to reassemble the decoded signal 346 in a time-aligned way. 348 6. Congestion Control 350 The adaptive nature of the SILK codec allows for an efficient 351 congestion control. 353 The average bit rate of SILK is dependent on the input signal and 354 will especially decrease during silent periods. The average bit rate 355 can be controlled on a per frame basis and therefore the amount of 356 payload data can be controlled. 358 Furthermore, 20, 40, 60, 80, or 100 ms of speech or audio data can be 359 combined in a single RTP payload, and the transmission rate is 360 inversely proportional to these frame sizes. A lower packet 361 transmission rate reduces the amount of header overhead but at the 362 same time increases latency and error sensitivity and should be done 363 with care. 365 It is RECOMMENDED that congestion control is applied during the 366 transmission of SILK encoded data. 368 7. IANA Considerations 370 One media subtype (audio/SILK) has been defined and registered as 371 described in the following section. 373 7.1. SILK Media Type Registration 375 Media type registration is done according to [RFC4288] and [RFC4855]. 377 Type name: audio 379 Subtype name: SILK 381 Required parameters: 383 rate: RTP timestamp clock rate that is equal to the sampling 384 frequency in Hertz (Hz) of the represented media in a packet. 385 Possible values are 8000, 12000, 16000, and 24000. 387 Optional parameters: 389 maxptime: the decoder's maximum length of time in milliseconds (ms) 390 represented by the media in a packet that can be encapsulated in a 391 received packet according to Section 6 of [RFC4566]. Possible 392 values are 20, 40, 60, 80, and 100 as defined in Section 4 and 393 Section 5 of this document. If no value is specified, 100 is 394 assumed as default. 396 ptime: the decoder's recommended length of time in milliseconds (ms) 397 represented by the media in a packet according to Section 6 of 398 [RFC4566]. Possible values are 20, 40, 60, 80, or 100 as defined 399 in Section 4 and Section 5 of this document. If no value is 400 specified, 20 is assumed as default. If ptime is greater than 401 maxptime, ptime MUST be ignored. This parameter MAY be changed 402 during a session. 404 minptime: the decoder's minimum length of time in milliseconds (ms) 405 represented by the media in a packet that SHOULD be encapsulated 406 in a received packet according to Section 6 of [RFC4566]. 407 Possible values are 20, 40, 60, 80, and 100 as defined in 408 Section 4 and Section 5 of this document. If no value is 409 specified, 20 is assumed as default. 411 maxaveragebitrate: specifies the maximum average receive bit rate of 412 a session in bits per second (bps). The actual value of the bit 413 rate may vary as it is dependent on the characteristics of the 414 media in a packet. Note that the maximum average bit rate MAY be 415 modified dynamically during a session. Any positive integer is 416 allowed but values outside the range specified in Table 1 of this 417 document will be ignored. If no value is specified, the maximum 418 value specified in Table 1 for the corresponding clock rate will 419 be the default. 421 usedtx: specifies if the decoder prefers the use of DTX. Possible 422 values are 1 and 0. If no value is specified, usedtx is assumed 423 to be 0. 425 Encoding considerations: 427 SILK media type is framed and consists of binary data according to 428 Section 4.8 in [RFC4288]. 430 Security considerations: 432 See Section 8 of this document. 434 Interoperability considerations: none 436 Published specification: none 438 Applications that use this media type: 440 Any application that requires the transport or storage of speech 441 or audio data may use this media type. Some examples are, but not 442 limited to, audio and video conferencing, Voice over IP, voice 443 recording, media streaming, voice messaging. 445 Additional information: 447 For storage transfer methods the following applies: 449 Magic number:"#!SILK\n" (hexadecimal: 0x23 0x21 0x53 0x49 0x4C 450 0x4B 0x0A) 451 File extension(s): sil, SIL 453 Macintosh file type code(s): "silk" 455 Person & email address to contact for further information: 457 SILK Support silksupport@skype.net 459 Intended usage: COMMON 461 Restrictions on usage: 463 For transfer over RTP, the RTP payload format (Section 4 of this 464 document) SHALL be used. For storage usage, the storage format 465 (Section 5 of this document) SHALL be used. 467 Author: 469 Julian Spittka julian.spittka@skype.net 471 Henrik Astrom henrik.astrom@skype.net 473 Koen Vos koen.vos@skype.net 475 Change controller: Skype 477 7.2. Mapping to SDP Parameters 479 The information described in the media type specification has a 480 specific mapping to fields in the Session Description Protocol (SDP) 481 [RFC4566], which is commonly used to describe RTP sessions. When SDP 482 is used to specify sessions employing the SILK codec, the mapping is 483 as follows: 485 o The media type ("audio") goes in SDP "m=" as the media name. 486 o The media subtype ("SILK") goes in SDP "a=rtpmap" as the encoding 487 name. The RTP clock rate in "a=rtpmap" MUST be mapped to the 488 required media type parameter "rate". 489 o The optional media type parameters "ptime" and "maxptime" are 490 mapped to "a=ptime" and "a=maxptime" attributes, respectively, in 491 the SDP. 492 o All remaining media type parameters are mapped to the "a=fmtp" 493 attribute in the SDP by copying them directly from the media type 494 parameter string as a semicolon-separated list of parameter=value 495 pairs (e.g. maxaveragebitrate=20000). 497 Below are some examples of SDP session descriptions for SILK: 499 Example 1: Standard session with 12000 Hz clock rate 501 m=audio 54312 RTP/AVP 101 502 a=rtpmap:101 SILK/12000 504 Example 2: 16000 Hz clock rate, maximum packet size of 40 ms, 505 recommended packet size of 40 ms, maximum average bit rate of 20000 506 bps, DTX is not allowed 508 m=audio 54312 RTP/AVP 101 509 a=rtpmap:101 SILK/16000 510 a=fmtp:101 maxaveragebitrate=20000; usedtx=0 511 a=ptime:40 512 a=maxptime:40 514 7.2.1. Offer-Answer Model Considerations for SILK 516 When using the offer-answer procedure described in [RFC3264] to 517 negotiate the use of SILK, the following considerations apply: 519 o SILK supports several clock rates. Every supported clock rate 520 MUST be announced separately in the "m=audi o" line. It is 521 RECOMMENDED to list the highest clock rate with highest priority 522 and lower clock rates with lower priority in decreasing order. 523 The answer will only keep the payload types that are supported by 524 the answerer and the conversation will be performed with the 525 payload type of the first, and, thus, highest common clock rate. 526 An example is shown below: 528 m=audio 54312 RTP/AVP 100 101 102 103 529 a=rtpmap:100 SILK/24000 530 a=rtpmap:101 SILK/16000 531 a=rtpmap:102 SILK/12000 532 a=rtpmap:103 SILK/8000 534 o The parameters "ptime" and "maxptime" are unidirectional receive- 535 only parameters and typically will not compromise 536 interoperability; however, dependent on the set values of the 537 parameters the performance of the application may suffer. 538 [RFC3264] defines the SDP offer-answer handling of the "ptime" 539 parameter. The "maxptime" parameter MUST be handled in the same 540 way. 541 o The parameter "maxaveragebitrate" is a unidirectional receive-only 542 parameter that reflects limitations of the local receiver. The 543 sender of the other side MUST NOT send with an average bit rate 544 higher than "maxaveragebitrate" as it might overload the network 545 and/or receiver. The parameter "maxaveragebitrate" typically will 546 not compromise interoperability; however, dependent on the set 547 value of the parameter the performance of the application may 548 suffer and should be set with care. 549 o If the parameter "maxaveragebitrate" is below the range specified 550 in Table 1 the session MUST be rejected. 551 o The parameter "usedtx" is a unidirectional receive-only parameter. 552 o Any unknown parameter in an offer MUST be ignored by the receiver 553 and MUST be removed from the answer. 555 7.2.2. Declarative SDP Considerations for SILK 557 For declarative use of SDP such as in Session Announcement Protocol 558 (SAP), [RFC2974], and RTSP, [RFC2326], for SILK, the following needs 559 to be considered: 561 o The values for "maxptime", "ptime", and "maxaveragebitrate" should 562 be selected carefully to ensure that a reasonable performance can 563 be achieved for the participants of a session. 564 o All parameters of the payload format configuration are declarative 565 and a participant MUST use the configurations that are provided 566 for the session. More than one configuration may be provided if 567 necessary by declaring multiple RTP payload types; however, the 568 number of types should be kept small. 570 8. Security Considerations 572 All RTP packets using the payload format defined in this 573 specification are subject to the general security considerations 574 discussed in the RTP specification [RFC3550] and any profile from 575 e.g. [RFC3711] or [RFC3551]. 577 This payload format transports SILK encoded speech or audio data, 578 hence, security issues include confidentiality, integrity protection, 579 and authentication of the speech or audio itself. The SILK payload 580 format does not have any built-in security mechanisms. Any suitable 581 external mechanisms, such as SRTP [RFC3711], MAY be used. 583 This payload format and the SILK encoding do not exhibit any 584 significant non-uniformity in the receiver-end computational load and 585 thus are unlikely to pose a denial-of-service threat due to the 586 receipt of pathological datagrams. 588 9. Acknowledgements 590 The authors like to thank Soren Skak Jensen and Jason Fischl for 591 their invaluable input. 593 10. Normative References 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, March 1997. 598 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 599 Streaming Protocol (RTSP)", RFC 2326, April 1998. 601 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 602 Announcement Protocol", RFC 2974, October 2000. 604 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 605 with Session Description Protocol (SDP)", RFC 3264, 606 June 2002. 608 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 609 Jacobson, "RTP: A Transport Protocol for Real-Time 610 Applications", STD 64, RFC 3550, July 2003. 612 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 613 Video Conferences with Minimal Control", STD 65, RFC 3551, 614 July 2003. 616 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 617 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 618 RFC 3711, March 2004. 620 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 621 Registration Procedures", BCP 13, RFC 4288, December 2005. 623 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 624 Description Protocol", RFC 4566, July 2006. 626 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 627 Formats", RFC 4855, February 2007. 629 Authors' Addresses 631 Julian Spittka 632 Skype Technologies S.A. 633 2145 Hamilton Ave. 634 San Jose, CA 95125 635 US 637 Email: julian.spittka@skype.net 639 Henrik Astrom 640 Skype Technologies S.A. 641 2145 Hamilton Ave. 642 San Jose, CA 95125 643 US 645 Email: henrik.astrom@skype.net 647 Koen Vos 648 Skype Technologies S.A. 649 2145 Hamilton Ave. 650 San Jose, CA 95125 651 US 653 Email: koen.vos@skype.net