1 2 3 4 5 6 7Network Working Group L. Barbato 8Request for Comments: 5215 Xiph 9Category: Standards Track August 2008 10 11 12 RTP Payload Format for Vorbis Encoded Audio 13 14Status of This Memo 15 16 This document specifies an Internet standards track protocol for the 17 Internet community, and requests discussion and suggestions for 18 improvements. Please refer to the current edition of the "Internet 19 Official Protocol Standards" (STD 1) for the standardization state 20 and status of this protocol. Distribution of this memo is unlimited. 21 22Abstract 23 24 This document describes an RTP payload format for transporting Vorbis 25 encoded audio. It details the RTP encapsulation mechanism for raw 26 Vorbis data and the delivery mechanisms for the decoder probability 27 model (referred to as a codebook), as well as other setup 28 information. 29 30 Also included within this memo are media type registrations and the 31 details necessary for the use of Vorbis with the Session Description 32 Protocol (SDP). 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58Barbato Standards Track [Page 1] 59 60RFC 5215 Vorbis RTP Payload Format August 2008 61 62 63Table of Contents 64 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Conformance and Document Conventions . . . . . . . . . . . 3 67 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5 70 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 8 72 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8 73 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9 74 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 10 75 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 12 76 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 12 77 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13 78 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13 79 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 14 80 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15 81 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 19 84 7. SDP Related Considerations . . . . . . . . . . . . . . . . . . 20 85 7.1. Mapping Media Type Parameters into SDP . . . . . . . . . . 20 86 7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 21 87 7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 22 88 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22 89 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22 91 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 23 93 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 94 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 96 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114Barbato Standards Track [Page 2] 115 116RFC 5215 Vorbis RTP Payload Format August 2008 117 118 1191. Introduction 120 121 Vorbis is a general purpose perceptual audio codec intended to allow 122 maximum encoder flexibility, thus allowing it to scale competitively 123 over an exceptionally wide range of bit rates. At the high quality/ 124 bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is 125 in the same league as MPEG-4 AAC. Vorbis is also intended for lower 126 and higher sample rates (from 8kHz telephony to 192kHz digital 127 masters) and a range of channel representations (monaural, 128 polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 129 discrete channels). 130 131 Vorbis encoded audio is generally encapsulated within an Ogg format 132 bitstream [RFC3533], which provides framing and synchronization. For 133 the purposes of RTP transport, this layer is unnecessary, and so raw 134 Vorbis packets are used in the payload. 135 1361.1. Conformance and Document Conventions 137 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in BCP 14, [RFC2119] and 141 indicate requirement levels for compliant implementations. 142 Requirements apply to all implementations unless otherwise stated. 143 144 An implementation is a software module that supports one of the media 145 types defined in this document. Software modules may support 146 multiple media types, but conformance is considered individually for 147 each type. 148 149 Implementations that fail to satisfy one or more "MUST" requirements 150 are considered non-compliant. Implementations that satisfy all 151 "MUST" requirements, but fail to satisfy one or more "SHOULD" 152 requirements, are said to be "conditionally compliant". All other 153 implementations are "unconditionally compliant". 154 1552. Payload Format 156 157 For RTP-based transport of Vorbis-encoded audio, the standard RTP 158 header is followed by a 4-octet payload header, and then the payload 159 data. The payload headers are used to associate the Vorbis data with 160 its associated decoding codebooks as well as indicate if the 161 following packet contains fragmented Vorbis data and/or the number of 162 whole Vorbis data frames. The payload data contains the raw Vorbis 163 bitstream information. There are 3 types of Vorbis data; an RTP 164 payload MUST contain just one of them at a time. 165 166 167 168 169 170Barbato Standards Track [Page 3] 171 172RFC 5215 Vorbis RTP Payload Format August 2008 173 174 1752.1. RTP Header 176 177 The format of the RTP header is specified in [RFC3550] and shown in 178 Figure 1. This payload format uses the fields of the header in a 179 manner consistent with that specification. 180 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 |V=2|P|X| CC |M| PT | sequence number | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | timestamp | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | synchronization source (SSRC) identifier | 189 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 190 | contributing source (CSRC) identifiers | 191 | ... | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 194 Figure 1: RTP Header 195 196 The RTP header begins with an octet of fields (V, P, X, and CC) to 197 support specialized RTP uses (see [RFC3550] and [RFC3551] for 198 details). For Vorbis RTP, the following values are used. 199 200 Version (V): 2 bits 201 202 This field identifies the version of RTP. The version used by this 203 specification is two (2). 204 205 Padding (P): 1 bit 206 207 Padding MAY be used with this payload format according to Section 5.1 208 of [RFC3550]. 209 210 Extension (X): 1 bit 211 212 The Extension bit is used in accordance with [RFC3550]. 213 214 CSRC count (CC): 4 bits 215 216 The CSRC count is used in accordance with [RFC3550]. 217 218 Marker (M): 1 bit 219 220 Set to zero. Audio silence suppression is not used. This conforms 221 to Section 4.1 of [VORBIS-SPEC-REF]. 222 223 224 225 226Barbato Standards Track [Page 4] 227 228RFC 5215 Vorbis RTP Payload Format August 2008 229 230 231 Payload Type (PT): 7 bits 232 233 An RTP profile for a class of applications is expected to assign a 234 payload type for this format, or a dynamically allocated payload type 235 SHOULD be chosen that designates the payload as Vorbis. 236 237 Sequence number: 16 bits 238 239 The sequence number increments by one for each RTP data packet sent, 240 and may be used by the receiver to detect packet loss and to restore 241 the packet sequence. This field is detailed further in [RFC3550]. 242 243 Timestamp: 32 bits 244 245 A timestamp representing the sampling time of the first sample of the 246 first Vorbis packet in the RTP payload. The clock frequency MUST be 247 set to the sample rate of the encoded audio data and is conveyed out- 248 of-band (e.g., as an SDP parameter). 249 250 SSRC/CSRC identifiers: 251 252 These two fields, 32 bits each with one SSRC field and a maximum of 253 16 CSRC fields, are as defined in [RFC3550]. 254 2552.2. Payload Header 256 257 The 4 octets following the RTP Header section are the Payload Header. 258 This header is split into a number of bit fields detailing the format 259 of the following payload data packets. 260 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Ident | F |VDT|# pkts.| 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 267 Figure 2: Payload Header 268 269 Ident: 24 bits 270 271 This 24-bit field is used to associate the Vorbis data to a decoding 272 Configuration. It is stored as a network byte order integer. 273 274 Fragment type (F): 2 bits 275 276 277 278 279 280 281 282Barbato Standards Track [Page 5] 283 284RFC 5215 Vorbis RTP Payload Format August 2008 285 286 287 This field is set according to the following list: 288 289 0 = Not Fragmented 290 291 1 = Start Fragment 292 293 2 = Continuation Fragment 294 295 3 = End Fragment 296 297 Vorbis Data Type (VDT): 2 bits 298 299 This field specifies the kind of Vorbis data stored in this RTP 300 packet. There are currently three different types of Vorbis 301 payloads. Each packet MUST contain only a single type of Vorbis 302 packet (e.g., you must not aggregate configuration and comment 303 packets in the same RTP payload). 304 305 0 = Raw Vorbis payload 306 307 1 = Vorbis Packed Configuration payload 308 309 2 = Legacy Vorbis Comment payload 310 311 3 = Reserved 312 313 The packets with a VDT of value 3 MUST be ignored. 314 315 The last 4 bits represent the number of complete packets in this 316 payload. This provides for a maximum number of 15 Vorbis packets in 317 the payload. If the payload contains fragmented data, the number of 318 packets MUST be set to 0. 319 3202.3. Payload Data 321 322 Raw Vorbis packets are currently unbounded in length; application 323 profiles will likely define a practical limit. Typical Vorbis packet 324 sizes range from very small (2-3 bytes) to quite large (8-12 325 kilobytes). The reference implementation [LIBVORBIS] typically 326 produces packets less than ~800 bytes, except for the setup header 327 packets, which are ~4-12 kilobytes. Within an RTP context, to avoid 328 fragmentation, the Vorbis data packet size SHOULD be kept 329 sufficiently small so that after adding the RTP and payload headers, 330 the complete RTP packet is smaller than the path MTU. 331 332 333 334 335 336 337 338Barbato Standards Track [Page 6] 339 340RFC 5215 Vorbis RTP Payload Format August 2008 341 342 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | length | vorbis packet data .. 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 349 Figure 3: Payload Data Header 350 351 Each Vorbis payload packet starts with a two octet length header, 352 which is used to represent the size in bytes of the following data 353 payload, and is followed by the raw Vorbis data padded to the nearest 354 byte boundary, as explained by the Vorbis I Specification 355 [VORBIS-SPEC-REF]. The length value is stored as a network byte 356 order integer. 357 358 For payloads that consist of multiple Vorbis packets, the payload 359 data consists of the packet length followed by the packet data for 360 each of the Vorbis packets in the payload. 361 362 The Vorbis packet length header is the length of the Vorbis data 363 block only and does not include the length field. 364 365 The payload packing of the Vorbis data packets MUST follow the 366 guidelines set out in [RFC3551], where the oldest Vorbis packet 367 occurs immediately after the RTP packet header. Subsequent Vorbis 368 packets, if any, MUST follow in temporal order. 369 370 Audio channel mapping is in accordance with the Vorbis I 371 Specification [VORBIS-SPEC-REF]. 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394Barbato Standards Track [Page 7] 395 396RFC 5215 Vorbis RTP Payload Format August 2008 397 398 3992.4. Example RTP Packet 400 401 Here is an example RTP payload containing two Vorbis packets. 402 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | 2 |0|0| 0 |0| PT | sequence number | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | timestamp (in sample rate units) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | synchronisation source (SSRC) identifier | 411 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 412 | contributing source (CSRC) identifiers | 413 | ... | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Ident | 0 | 0 | 2 pks | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | length | vorbis data .. 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 .. vorbis data | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | length | next vorbis packet data .. 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 .. vorbis data .. 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 .. vorbis data | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 429 Figure 4: Example Raw Vorbis Packet 430 431 The payload data section of the RTP packet begins with the 24-bit 432 Ident field followed by the one octet bit field header, which has the 433 number of Vorbis frames set to 2. Each of the Vorbis data frames is 434 prefixed by the two octets length field. The Packet Type and 435 Fragment Type are set to 0. The Configuration that will be used to 436 decode the packets is the one indexed by the ident value. 437 4383. Configuration Headers 439 440 Unlike other mainstream audio codecs, Vorbis has no statically 441 configured probability model. Instead, it packs all entropy decoding 442 configuration, Vector Quantization and Huffman models into a data 443 block that must be transmitted to the decoder with the compressed 444 data. A decoder also requires information detailing the number of 445 audio channels, bitrates, and similar information to configure itself 446 for a particular compressed data stream. These two blocks of 447 448 449 450Barbato Standards Track [Page 8] 451 452RFC 5215 Vorbis RTP Payload Format August 2008 453 454 455 information are often referred to collectively as the "codebooks" for 456 a Vorbis stream, and are included as special "header" packets at the 457 start of the compressed data. In addition, the Vorbis I 458 specification [VORBIS-SPEC-REF] requires the presence of a comment 459 header packet that gives simple metadata about the stream, but this 460 information is not required for decoding the frame sequence. 461 462 Thus, these two codebook header packets must be received by the 463 decoder before any audio data can be interpreted. These requirements 464 pose problems in RTP, which is often used over unreliable transports. 465 466 Since this information must be transmitted reliably and, as the RTP 467 stream may change certain configuration data mid-session, there are 468 different methods for delivering this configuration data to a client, 469 both in-band and out-of-band, which are detailed below. In order to 470 set up an initial state for the client application, the configuration 471 MUST be conveyed via the signalling channel used to set up the 472 session. One example of such signalling is SDP [RFC4566] with the 473 Offer/Answer Model [RFC3264]. Changes to the configuration MAY be 474 communicated via a re-invite, conveying a new SDP, or sent in-band in 475 the RTP channel. Implementations MUST support an in-band delivery of 476 updated codebooks, and SHOULD support out-of-band codebook update 477 using a new SDP file. The changes may be due to different codebooks 478 as well as different bitrates of the RTP stream. 479 480 For non-chained streams, the recommended Configuration delivery 481 method is inside the Packed Configuration (Section 3.1.1) in the SDP 482 as explained the Mapping Media Type Parameters into SDP 483 (Section 7.1). 484 485 The 24-bit Ident field is used to map which Configuration will be 486 used to decode a packet. When the Ident field changes, it indicates 487 that a change in the stream has taken place. The client application 488 MUST have in advance the correct configuration. If the client 489 detects a change in the Ident value and does not have this 490 information, it MUST NOT decode the raw associated Vorbis data until 491 it fetches the correct Configuration. 492 4933.1. In-band Header Transmission 494 495 The Packed Configuration (Section 3.1.1) Payload is sent in-band with 496 the packet type bits set to match the Vorbis Data Type. Clients MUST 497 be capable of dealing with fragmentation and periodic re-transmission 498 of [RFC4588] the configuration headers. The RTP timestamp value MUST 499 reflect the transmission time of the first data packet for which this 500 configuration applies. 501 502 503 504 505 506Barbato Standards Track [Page 9] 507 508RFC 5215 Vorbis RTP Payload Format August 2008 509 510 5113.1.1. Packed Configuration 512 513 A Vorbis Packed Configuration is indicated with the Vorbis Data Type 514 field set to 1. Of the three headers defined in the Vorbis I 515 specification [VORBIS-SPEC-REF], the Identification and the Setup 516 MUST be packed as they are, while the Comment header MAY be replaced 517 with a dummy one. 518 519 The packed configuration stores Xiph codec configurations in a 520 generic way: the first field stores the number of the following 521 packets minus one (count field), the next ones represent the size of 522 the headers (length fields), and the headers immediately follow the 523 list of length fields. The size of the last header is implicit. 524 525 The count and the length fields are encoded using the following 526 logic: the data is in network byte order; every byte has the most 527 significant bit used as a flag, and the following 7 bits are used to 528 store the value. The first 7 most significant bits are stored in the 529 first byte. If there are remaining bits, the flag bit is set to 1 530 and the subsequent 7 bits are stored in the following byte. If there 531 are remaining bits, set the flag to 1 and the same procedure is 532 repeated. The ending byte has the flag bit set to 0. To decode, 533 simply iterate over the bytes until the flag bit is set to 0. For 534 every byte, the data is added to the accumulated value multiplied by 535 128. 536 537 The headers are packed in the same order as they are present in Ogg 538 [VORBIS-SPEC-REF]: Identification, Comment, Setup. 539 540 The 2 byte length tag defines the length of the packed headers as the 541 sum of the Configuration, Comment, and Setup lengths. 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562Barbato Standards Track [Page 10] 563 564RFC 5215 Vorbis RTP Payload Format August 2008 565 566 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 |V=2|P|X| CC |M| PT | xxxx | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | xxxxx | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | synchronization source (SSRC) identifier | 575 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 576 | contributing source (CSRC) identifiers | 577 | ... | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Ident | 0 | 1 | 1| 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | length | n. of headers | length1 | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | length2 | Identification .. 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 .. Identification .. 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 .. Identification .. 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 .. Identification .. 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 .. Identification | Comment .. 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 .. Comment .. 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 .. Comment .. 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 .. Comment .. 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 .. Comment | Setup .. 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 .. Setup .. 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 .. Setup .. 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 607 Figure 5: Packed Configuration Figure 608 609 The Ident field is set with the value that will be used by the Raw 610 Payload Packets to address this Configuration. The Fragment type is 611 set to 0 because the packet bears the full Packed configuration. The 612 number of the packet is set to 1. 613 614 615 616 617 618Barbato Standards Track [Page 11] 619 620RFC 5215 Vorbis RTP Payload Format August 2008 621 622 6233.2. Out of Band Transmission 624 625 The following packet definition MUST be used when Configuration is 626 inside in the SDP. 627 6283.2.1. Packed Headers 629 630 As mentioned above, the RECOMMENDED delivery vector for Vorbis 631 configuration data is via a retrieval method that can be performed 632 using a reliable transport protocol. As the RTP headers are not 633 required for this method of delivery, the structure of the 634 configuration data is slightly different. The packed header starts 635 with a 32-bit (network-byte ordered) count field, which details the 636 number of packed headers that are contained in the bundle. The 637 following shows the Packed header payload for each chained Vorbis 638 stream. 639 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Number of packed headers | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Packed header | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Packed header | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 650 Figure 6: Packed Headers Overview 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674Barbato Standards Track [Page 12] 675 676RFC 5215 Vorbis RTP Payload Format August 2008 677 678 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Ident | length .. 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 .. | n. of headers | length1 | length2 .. 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 .. | Identification Header .. 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 ................................................................. 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 .. | Comment Header .. 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 ................................................................. 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 .. Comment Header | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Setup Header .. 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 ................................................................. 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 .. Setup Header | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 703 Figure 7: Packed Headers Detail 704 705 The key difference between the in-band format and this one is that 706 there is no need for the payload header octet. In this figure, the 707 comment has a size bigger than 127 bytes. 708 7093.3. Loss of Configuration Headers 710 711 Unlike the loss of raw Vorbis payload data, loss of a configuration 712 header leads to a situation where it will not be possible to 713 successfully decode the stream. Implementations MAY try to recover 714 from an error by requesting again the missing Configuration or, if 715 the delivery method is in-band, by buffering the payloads waiting for 716 the Configuration needed to decode them. The baseline reaction 717 SHOULD either be reset or end the RTP session. 718 7194. Comment Headers 720 721 Vorbis Data Type flag set to 2 indicates that the packet contains the 722 comment metadata, such as artist name, track title, and so on. These 723 metadata messages are not intended to be fully descriptive but rather 724 to offer basic track/song information. Clients MAY ignore it 725 completely. The details on the format of the comments can be found 726 in the Vorbis I Specification [VORBIS-SPEC-REF]. 727 728 729 730Barbato Standards Track [Page 13] 731 732RFC 5215 Vorbis RTP Payload Format August 2008 733 734 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 |V=2|P|X| CC |M| PT | xxxx | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | xxxxx | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | synchronization source (SSRC) identifier | 743 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 744 | contributing source (CSRC) identifiers | 745 | ... | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Ident | 0 | 2 | 1| 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | length | Comment .. 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 .. Comment .. 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 .. Comment | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 757 Figure 8: Comment Packet 758 759 The 2-byte length field is necessary since this packet could be 760 fragmented. 761 7625. Frame Packetization 763 764 Each RTP payload contains either one Vorbis packet fragment or an 765 integer number of complete Vorbis packets (up to a maximum of 15 766 packets, since the number of packets is defined by a 4-bit value). 767 768 Any Vorbis data packet that is less than path MTU SHOULD be bundled 769 in the RTP payload with as many Vorbis packets as will fit, up to a 770 maximum of 15, except when such bundling would exceed an 771 application's desired transmission latency. Path MTU is detailed in 772 [RFC1191] and [RFC1981]. 773 774 A fragmented packet has a zero in the last four bits of the payload 775 header. The first fragment will set the Fragment type to 1. Each 776 fragment after the first will set the Fragment type to 2 in the 777 payload header. The consecutive fragments MUST be sent without any 778 other payload being sent between the first and the last fragment. 779 The RTP payload containing the last fragment of the Vorbis packet 780 will have the Fragment type set to 3. To maintain the correct 781 sequence for fragmented packet reception, the timestamp field of 782 fragmented packets MUST be the same as the first packet sent, with 783 784 785 786Barbato Standards Track [Page 14] 787 788RFC 5215 Vorbis RTP Payload Format August 2008 789 790 791 the sequence number incremented as normal for the subsequent RTP 792 payloads; this will affect the RTCP jitter measurement. The length 793 field shows the fragment length. 794 7955.1. Example Fragmented Vorbis Packet 796 797 Here is an example of a fragmented Vorbis packet split over three RTP 798 payloads. Each of them contains the standard RTP headers as well as 799 the 4-octet Vorbis headers. 800 801 Packet 1: 802 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 |V=2|P|X| CC |M| PT | 1000 | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | 12345 | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | synchronization source (SSRC) identifier | 811 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 812 | contributing source (CSRC) identifiers | 813 | ... | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Ident | 1 | 0 | 0| 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | length | vorbis data .. 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 .. vorbis data | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 823 Figure 9: Example Fragmented Packet (Packet 1) 824 825 In this payload, the initial sequence number is 1000 and the 826 timestamp is 12345. The Fragment type is set to 1, the number of 827 packets field is set to 0, and as the payload is raw Vorbis data, the 828 VDT field is set to 0. 829 830 831 832 833 834 835 836 837 838 839 840 841 842Barbato Standards Track [Page 15] 843 844RFC 5215 Vorbis RTP Payload Format August 2008 845 846 847 Packet 2: 848 849 0 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 |V=2|P|X| CC |M| PT | 1001 | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | 12345 | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | synchronization source (SSRC) identifier | 857 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 858 | contributing source (CSRC) identifiers | 859 | ... | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Ident | 2 | 0 | 0| 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | length | vorbis data .. 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 .. vorbis data | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 869 Figure 10: Example Fragmented Packet (Packet 2) 870 871 The Fragment type field is set to 2, and the number of packets field 872 is set to 0. For large Vorbis fragments, there can be several of 873 these types of payloads. The maximum packet size SHOULD be no 874 greater than the path MTU, including all RTP and payload headers. 875 The sequence number has been incremented by one, but the timestamp 876 field remains the same as the initial payload. 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898Barbato Standards Track [Page 16] 899 900RFC 5215 Vorbis RTP Payload Format August 2008 901 902 903 Packet 3: 904 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 |V=2|P|X| CC |M| PT | 1002 | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | 12345 | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | synchronization source (SSRC) identifier | 913 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 914 | contributing source (CSRC) identifiers | 915 | ... | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Ident | 3 | 0 | 0| 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | length | vorbis data .. 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 .. vorbis data | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 925 Figure 11: Example Fragmented Packet (Packet 3) 926 927 This is the last Vorbis fragment payload. The Fragment type is set 928 to 3 and the packet count remains set to 0. As in the previous 929 payloads, the timestamp remains set to the first payload timestamp in 930 the sequence and the sequence number has been incremented. 931 9325.2. Packet Loss 933 934 As there is no error correction within the Vorbis stream, packet loss 935 will result in a loss of signal. Packet loss is more of an issue for 936 fragmented Vorbis packets as the client will have to cope with the 937 handling of the Fragment Type. In case of loss of fragments, the 938 client MUST discard all the remaining Vorbis fragments and decode the 939 incomplete packet. If we use the fragmented Vorbis packet example 940 above and the first RTP payload is lost, the client MUST detect that 941 the next RTP payload has the packet count field set to 0 and the 942 Fragment type 2 and MUST drop it. The next RTP payload, which is the 943 final fragmented packet, MUST be dropped in the same manner. If the 944 missing RTP payload is the last, the two fragments received will be 945 kept and the incomplete Vorbis packet decoded. 946 947 Loss of any of the Configuration fragment will result in the loss of 948 the full Configuration packet with the result detailed in the Loss of 949 Configuration Headers (Section 3.3) section. 950 951 952 953 954Barbato Standards Track [Page 17] 955 956RFC 5215 Vorbis RTP Payload Format August 2008 957 958 9596. IANA Considerations 960 961 Type name: audio 962 963 Subtype name: vorbis 964 965 Required parameters: 966 967 rate: indicates the RTP timestamp clock rate as described in RTP 968 Profile for Audio and Video Conferences with Minimal Control 969 [RFC3551]. 970 971 channels: indicates the number of audio channels as described in 972 RTP Profile for Audio and Video Conferences with Minimal 973 Control [RFC3551]. 974 975 configuration: the base64 [RFC4648] representation of the Packed 976 Headers (Section 3.2.1). 977 978 Encoding considerations: 979 980 This media type is framed and contains binary data. 981 982 Security considerations: 983 984 See Section 10 of RFC 5215. 985 986 Interoperability considerations: 987 988 None 989 990 Published specification: 991 992 RFC 5215 993 994 Ogg Vorbis I specification: Codec setup and packet decode. 995 Available from the Xiph website, http://xiph.org/ 996 997 Applications which use this media type: 998 999 Audio streaming and conferencing tools 1000 1001 Additional information: 1002 1003 None 1004 1005 1006 1007 1008 1009 1010Barbato Standards Track [Page 18] 1011 1012RFC 5215 Vorbis RTP Payload Format August 2008 1013 1014 1015 Person & email address to contact for further information: 1016 1017 Luca Barbato: <lu_zero@gentoo.org> 1018 IETF Audio/Video Transport Working Group 1019 1020 Intended usage: 1021 1022 COMMON 1023 1024 Restriction on usage: 1025 1026 This media type depends on RTP framing, hence is only defined for 1027 transfer via RTP [RFC3550]. 1028 1029 Author: 1030 1031 Luca Barbato 1032 1033 Change controller: 1034 1035 IETF AVT Working Group delegated from the IESG 1036 10376.1. Packed Headers IANA Considerations 1038 1039 The following IANA considerations refers to the split configuration 1040 Packed Headers (Section 3.2.1) used within RFC 5215. 1041 1042 Type name: audio 1043 1044 Subtype name: vorbis-config 1045 1046 Required parameters: 1047 1048 None 1049 1050 Optional parameters: 1051 1052 None 1053 1054 Encoding considerations: 1055 1056 This media type contains binary data. 1057 1058 Security considerations: 1059 1060 See Section 10 of RFC 5215. 1061 1062 1063 1064 1065 1066Barbato Standards Track [Page 19] 1067 1068RFC 5215 Vorbis RTP Payload Format August 2008 1069 1070 1071 Interoperability considerations: 1072 1073 None 1074 1075 Published specification: 1076 1077 RFC 5215 1078 1079 Applications which use this media type: 1080 1081 Vorbis encoded audio, configuration data 1082 1083 Additional information: 1084 1085 None 1086 1087 Person & email address to contact for further information: 1088 1089 Luca Barbato: <lu_zero@gentoo.org> 1090 IETF Audio/Video Transport Working Group 1091 1092 Intended usage: COMMON 1093 1094 Restriction on usage: 1095 1096 This media type doesn't depend on the transport. 1097 1098 Author: 1099 1100 Luca Barbato 1101 1102 Change controller: 1103 1104 IETF AVT Working Group delegated from the IESG 1105 11067. SDP Related Considerations 1107 1108 The following paragraphs define the mapping of the parameters 1109 described in the IANA considerations section and their usage in the 1110 Offer/Answer Model [RFC3264]. In order to be forward compatible, the 1111 implementation MUST ignore unknown parameters. 1112 11137.1. Mapping Media Type Parameters into SDP 1114 1115 The information carried in the Media Type specification has a 1116 specific mapping to fields in the Session Description Protocol (SDP) 1117 [RFC4566], which is commonly used to describe RTP sessions. When SDP 1118 is used to specify sessions, the mapping are as follows: 1119 1120 1121 1122Barbato Standards Track [Page 20] 1123 1124RFC 5215 Vorbis RTP Payload Format August 2008 1125 1126 1127 o The type name ("audio") goes in SDP "m=" as the media name. 1128 1129 o The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding 1130 name. 1131 1132 o The parameter "rate" also goes in "a=rtpmap" as the clock rate. 1133 1134 o The parameter "channels" also goes in "a=rtpmap" as the channel 1135 count. 1136 1137 o The mandated parameters "configuration" MUST be included in the 1138 SDP "a=fmtp" attribute. 1139 1140 If the stream comprises chained Vorbis files and all of them are 1141 known in advance, the Configuration Packet for each file SHOULD be 1142 passed to the client using the configuration attribute. 1143 1144 The port value is specified by the server application bound to the 1145 address specified in the c= line. The channel count value specified 1146 in the rtpmap attribute SHOULD match the current Vorbis stream or 1147 should be considered the maximum number of channels to be expected. 1148 The timestamp clock rate MUST be a multiple of the sample rate; a 1149 different payload number MUST be used if the clock rate changes. The 1150 Configuration payload delivers the exact information, thus the SDP 1151 information SHOULD be considered a hint. An example is found below. 1152 11537.1.1. SDP Example 1154 1155 The following example shows a basic SDP single stream. The first 1156 configuration packet is inside the SDP; other configurations could be 1157 fetched at any time from the URIs provided. The following base64 1158 [RFC4648] configuration string is folded in this example due to RFC 1159 line length limitations. 1160 1161 c=IN IP4 192.0.2.1 1162 1163 m=audio RTP/AVP 98 1164 1165 a=rtpmap:98 vorbis/44100/2 1166 1167 a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...; 1168 1169 Note that the payload format (encoding) names are commonly shown in 1170 uppercase. Media Type subtypes are commonly shown in lowercase. 1171 These names are case-insensitive in both places. Similarly, 1172 parameter names are case-insensitive both in Media Type types and in 1173 the default mapping to the SDP a=fmtp attribute. The a=fmtp line is 1174 1175 1176 1177 1178Barbato Standards Track [Page 21] 1179 1180RFC 5215 Vorbis RTP Payload Format August 2008 1181 1182 1183 a single line, even if it is shown as multiple lines in this document 1184 for clarity. 1185 11867.2. Usage with the SDP Offer/Answer Model 1187 1188 There are no negotiable parameters. All of them are declarative. 1189 11908. Congestion Control 1191 1192 The general congestion control considerations for transporting RTP 1193 data apply to Vorbis audio over RTP as well. See the RTP 1194 specification [RFC3550] and any applicable RTP profile (e.g., 1195 [RFC3551]). Audio data can be encoded using a range of different bit 1196 rates, so it is possible to adapt network bandwidth by adjusting the 1197 encoder bit rate in real time or by having multiple copies of content 1198 encoded at different bit rates. 1199 12009. Example 1201 1202 The following example shows a common usage pattern that MAY be 1203 applied in such a situation. The main scope of this section is to 1204 explain better usage of the transmission vectors. 1205 12069.1. Stream Radio 1207 1208 This is one of the most common situations: there is one single server 1209 streaming content in multicast, and the clients may start a session 1210 at a random time. The content itself could be a mix of a live stream 1211 (as the webjockey's voice) and stored streams (as the music she 1212 plays). 1213 1214 In this situation, we don't know in advance how many codebooks we 1215 will use. The clients can join anytime and users expect to start 1216 listening to the content in a short time. 1217 1218 Upon joining, the client will receive the current Configuration 1219 necessary to decode the current stream inside the SDP so that the 1220 decoding will start immediately after. 1221 1222 When the streamed content changes, the new Configuration is sent in- 1223 band before the actual stream, and the Configuration that has to be 1224 sent inside the SDP is updated. Since the in-band method is 1225 unreliable, an out-of-band fallback is provided. 1226 1227 The client may choose to fetch the Configuration from the alternate 1228 source as soon as it discovers a Configuration packet got lost in- 1229 band, or use selective retransmission [RFC3611] if the server 1230 supports this feature. 1231 1232 1233 1234Barbato Standards Track [Page 22] 1235 1236RFC 5215 Vorbis RTP Payload Format August 2008 1237 1238 1239 A server-side optimization would be to keep a hash list of the 1240 Configurations per session, which avoids packing all of them and 1241 sending the same Configuration with different Ident tags. 1242 1243 A client-side optimization would be to keep a tag list of the 1244 Configurations per session and not process configuration packets that 1245 are already known. 1246 124710. Security Considerations 1248 1249 RTP packets using this payload format are subject to the security 1250 considerations discussed in the RTP specification [RFC3550], the 1251 base64 specification [RFC4648], and the URI Generic syntax 1252 specification [RFC3986]. Among other considerations, this implies 1253 that the confidentiality of the media stream is achieved by using 1254 encryption. Because the data compression used with this payload 1255 format is applied end-to-end, encryption may be performed on the 1256 compressed data. 1257 125811. Copying Conditions 1259 1260 The authors agree to grant third parties the irrevocable right to 1261 copy, use, and distribute the work, with or without modification, in 1262 any medium, without royalty, provided that, unless separate 1263 permission is granted, redistributed modified works do not contain 1264 misleading author, version, name of work, or endorsement information. 1265 126612. Acknowledgments 1267 1268 This document is a continuation of the following documents: 1269 1270 Moffitt, J., "RTP Payload Format for Vorbis Encoded Audio", February 1271 2001. 1272 1273 Kerr, R., "RTP Payload Format for Vorbis Encoded Audio", December 1274 2004. 1275 1276 The Media Type declaration is a continuation of the following 1277 document: 1278 1279 Short, B., "The audio/rtp-vorbis MIME Type", January 2008. 1280 1281 Thanks to the AVT, Vorbis Communities / Xiph.Org Foundation including 1282 Steve Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, 1283 Pascal Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John 1284 Lazzaro, Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry 1285 Short, Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, 1286 David Barrett, Silvia Pfeiffer, Stefan Ehmann, Gianni Ceccarelli, and 1287 1288 1289 1290Barbato Standards Track [Page 23] 1291 1292RFC 5215 Vorbis RTP Payload Format August 2008 1293 1294 1295 Alessandro Salvatori. Thanks to the LScube Group, in particular 1296 Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Dario 1297 Gallucci, and Juan Carlos De Martin. 1298 129913. References 1300 130113.1. Normative References 1302 1303 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", 1304 RFC 1191, November 1990. 1305 1306 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU 1307 Discovery for IP version 6", RFC 1981, 1308 August 1996. 1309 1310 [RFC2119] Bradner, S., "Key words for use in RFCs to 1311 Indicate Requirement Levels", BCP 14, RFC 2119, 1312 March 1997. 1313 1314 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer 1315 Model with Session Description Protocol (SDP)", 1316 RFC 3264, June 2002. 1317 1318 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1319 Jacobson, "RTP: A Transport Protocol for Real-Time 1320 Applications", STD 64, RFC 3550, July 2003. 1321 1322 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for 1323 Audio and Video Conferences with Minimal Control", 1324 STD 65, RFC 3551, July 2003. 1325 1326 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 1327 "Uniform Resource Identifier (URI): Generic 1328 Syntax", STD 66, RFC 3986, January 2005. 1329 1330 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: 1331 Session Description Protocol", RFC 4566, 1332 July 2006. 1333 1334 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 1335 Data Encodings", RFC 4648, October 2006. 1336 1337 [VORBIS-SPEC-REF] "Ogg Vorbis I specification: Codec setup and 1338 packet decode. Available from the Xiph website, 1339 http://xiph.org/vorbis/doc/Vorbis_I_spec.html". 1340 1341 1342 1343 1344 1345 1346Barbato Standards Track [Page 24] 1347 1348RFC 5215 Vorbis RTP Payload Format August 2008 1349 1350 135113.2. Informative References 1352 1353 [LIBVORBIS] "libvorbis: Available from the dedicated website, 1354 http://vorbis.com/". 1355 1356 [RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format 1357 Version 0", RFC 3533, May 2003. 1358 1359 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP 1360 Control Protocol Extended Reports (RTCP XR)", 1361 RFC 3611, November 2003. 1362 1363 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1364 Hakenberg, "RTP Retransmission Payload Format", 1365 RFC 4588, July 2006. 1366 1367Author's Address 1368 1369 Luca Barbato 1370 Xiph.Org Foundation 1371 1372 EMail: lu_zero@gentoo.org 1373 URI: http://xiph.org/ 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402Barbato Standards Track [Page 25] 1403 1404RFC 5215 Vorbis RTP Payload Format August 2008 1405 1406 1407Full Copyright Statement 1408 1409 Copyright (C) The IETF Trust (2008). 1410 1411 This document is subject to the rights, licenses and restrictions 1412 contained in BCP 78, and except as set forth therein, the authors 1413 retain all their rights. 1414 1415 This document and the information contained herein are provided on an 1416 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1417 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1418 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1419 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1420 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1421 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1422 1423Intellectual Property 1424 1425 The IETF takes no position regarding the validity or scope of any 1426 Intellectual Property Rights or other rights that might be claimed to 1427 pertain to the implementation or use of the technology described in 1428 this document or the extent to which any license under such rights 1429 might or might not be available; nor does it represent that it has 1430 made any independent effort to identify any such rights. Information 1431 on the procedures with respect to rights in RFC documents can be 1432 found in BCP 78 and BCP 79. 1433 1434 Copies of IPR disclosures made to the IETF Secretariat and any 1435 assurances of licenses to be made available, or the result of an 1436 attempt made to obtain a general license or permission for the use of 1437 such proprietary rights by implementers or users of this 1438 specification can be obtained from the IETF on-line IPR repository at 1439 http://www.ietf.org/ipr. 1440 1441 The IETF invites any interested party to bring to its attention any 1442 copyrights, patents or patent applications, or other proprietary 1443 rights that may cover technology that may be required to implement 1444 this standard. Please address the information to the IETF at 1445 ietf-ipr@ietf.org. 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458Barbato Standards Track [Page 26] 1459 1460