idnits 2.17.1 draft-westerlund-avt-rtp-static-media-01.txt: -(417): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 264: '...e payload format SHOULD be generic eno...' RFC 2119 keyword, line 269: '...e payload format SHOULD support packet...' RFC 2119 keyword, line 276: '... It SHOULD be possible for client ap...' RFC 2119 keyword, line 285: '...ad specification SHOULD support the em...' RFC 2119 keyword, line 287: '... SHOULD also be possible to use the ...' (37 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2, 2002) is 8150 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) -- Looks like a reference, but probably isn't: 'TBW' on line 708 -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 793 (ref. '2') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1889 (ref. '3') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2733 (ref. '7') (Obsoleted by RFC 5109) -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-09) exists of draft-ietf-avt-srtp-02 == Outdated reference: A later version (-11) exists of draft-ietf-avt-rtcp-feedback-01 == Outdated reference: A later version (-05) exists of draft-ietf-avt-rtp-selret-03 -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2035 (ref. '13') (Obsoleted by RFC 2435) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Magnus Westerlund 3 INTERNET-DRAFT Kristofer Dovstam 4 Expires: July 2002 Ericsson, Sweden 5 Frank Hartung 6 Uwe Horn 7 Ericsson, Germany 8 January 2, 2002 10 Generic RTP Payload Format for Time-lined Static Media 11 13 Status of this memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-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 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/lid-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This document is an individual submission to the IETF. Comments 34 should be directed to the authors. 36 Abstract 38 This Internet Draft discusses an RTP payload format for time-lined 39 static media. "Time-lined static media" means static media objects 40 like pictures and text extended by timing information. Applications 41 that would benefit from such a payload format are for instance 42 slideshow streaming and streaming of subtitled video and audio. We 43 discuss the important requirements for a payload format and propose a 44 specification that suits those requirements. 46 TABLE OF CONTENTS 48 1. Introduction........................................................2 49 2. Usage scenarios.....................................................3 50 2.1. Image slideshow...................................................3 51 2.2. Subtitled video and audio streams.................................4 52 3. Problems of existing approach.......................................5 53 4. Requirements........................................................6 54 5. Proposal for an RTP Payload Format for time-lined static media......7 55 5.1. RTP Header Usage..................................................7 56 5.2. Header Formats....................................................8 57 5.2.1. Object Identifier Header........................................8 58 5.2.2. Duration Header.................................................9 59 5.2.3. Data Header.....................................................9 60 5.2.4. Offset Headers (ByteOffset).....................................9 61 5.3. Compound payload.................................................10 62 6. Media Profiles.....................................................11 63 6.1. JPEG.............................................................11 64 6.1.1. Resilient transport............................................11 65 6.1.2. Profile specific headers.......................................12 66 6.1.3. Payload format header usage:...................................12 67 6.2. TEXT.............................................................13 68 6.2.1. Resilient transport............................................13 69 6.2.2. Profile Specific Headers.......................................13 70 6.2.3. Payload format header usage:...................................14 71 7. Congestion Control.................................................14 72 8. Security Consideration.............................................15 73 8.1. Confidentiality..................................................15 74 8.2. Authentication...................................................15 75 9. IANA Considerations................................................15 76 10. MIME type registration............................................15 77 11. Author's Addresses................................................16 78 12. References........................................................16 80 1. Introduction 82 Today, content creators have various options to specify complex 83 multimedia presentations composed of different media types and 84 synchronized along a global timeline. 86 SMIL [1] for instance is a powerful tool that allows one to define 87 the spatial and temporal layout of multimedia presentations that 88 contain video, audio, still images, text, and other media elements. 89 In addition to SMIL, there are a couple of file format specifications 90 that also allow one to create synchronized multimedia presentations, 91 composed of a mix of different media types. 93 Media types are usually classified into static and continuous media. 94 Continuous media types are characterized by an intrinsic time line 95 resulting from taking media samples at regular time intervals. Video 96 and audio are typical examples for continuous media types. Static 97 media types differ from continuous media types in the sense that they 98 do not possess an intrinsic time line. Examples of static media types 99 are still images and plain text. 101 In addition to static and continuous media one can identify a third 102 media type, which we call "time-lined static media". With time-lined 103 static media we mean static media objects like pictures and text with 104 added timing information such that the presentation of a series of 105 static media objects can be synchronized with a global timeline. 106 Application scenarios that would benefit from such an RTP [3] payload 107 format are for instance slideshow streaming and subtitled video and 108 audio streams. 110 Today, there exist various RTP payload formats that can be used to 111 packetize data belonging to continuous media elements. Static media 112 types, like an image in an HTML page, are usually transferred via 113 HTTP. However, as we will see later, using TCP [2] based HTTP for 114 time-lined static media has many drawbacks, especially if 115 synchronization with a continuous media streams is required. 116 Therefore, streaming of time-lined static media objects should be 117 done based on RTP over UDP similar to streaming of continuous media. 119 In the following, we will first discuss in more detail some usage 120 scenarios that would benefit from an RTP payload format for time- 121 lined static media. After that, we will list some important 122 requirements of such a payload format. Finally, we propose a 123 specification of a payload format for time-lined static media that 124 takes the identified requirements into account. 126 2. Usage scenarios 128 This section discusses in more detail two use cases that would 129 benefit from a payload format for time-lined static media objects, 130 namely slideshow streaming and video and audio streaming with 131 subtitles. 133 2.1. Image slideshow 135 A slideshow in its simplest form is characterized by a series of 136 images with a defined presentation start time and duration for each 137 image. Usually the time-lined images are accompanied by a 138 synchronized audio track. 140 / \ 141 Media | 142 Elements| 143 | 144 Image 1 | #### 145 Image 2 | ######### 146 Image 3 | ##### 147 Image 4 | ########## 148 Audio | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 149 --------------------------------------------> 150 time 152 Figure 1 154 Figure 1 gives an example for a series of images synchronized with 155 audio. The vertical axis denotes the different media elements; the 156 horizontal axis represents the time line. In the shown example audio 157 starts first. After three time units the first image appears and 158 stays visible for 4 time units, followed by the second image which 159 stays visible for 9 time units and so on. 161 2.2. Subtitled video and audio streams 163 Subtitling is characterized by combining continuous media types like 164 video with audio or audio only with time-lined static text elements. 166 Fig. 2 gives an example that starts with video and audio. The first 167 subtitle appears after three time units and remains visible for four 168 time units. After a short period where no subtitle at all is shown, 169 subtitle 2 is shown over a period of 5 time units and so on. 171 / \ 172 Media | 173 Elements| 174 | 175 ST 1 | #### 176 ST 2 | ##### 177 ST 3 | ##### 178 ST 4 | ### 179 Audio | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 180 Video | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 181 --------------------------------------------> 182 time 184 Figure 2 186 3. Problems of existing approach 188 As mentioned in the introduction, there is currently no RTP payload 189 specification that could be used for time-lined static media 190 elements. 192 The workaround today is to transfer each of the static media objects 193 in separate files via TCP or HTTP to the client, where the timing 194 information is added. For instance, a slideshow application defined 195 in SMIL would use HTTP/TCP for the images, with timing information 196 coming from the SMIL file, and if audio is present as well, use 197 RTP/UDP for streaming the audio. 199 However, this "hybrid" approach has a couple of drawbacks, which are 200 listed in the following: 202 - TCP is not suited for real-time transmission scenarios 204 TCP guarantees error-free delivery of data between a sender and a 205 receiver over best effort networks by employing a specific 206 retransmission mechanism. However, the requirements of real-time 207 streaming applications are not addressed by TCP. For streaming timely 208 delivery of data is more important than error-free delivery of data. 209 This is a well-known fact and has lead to the development of RTP [3]. 211 - TCP is not suited for multicast scenarios 213 In a multicast distributed multimedia session it is not recommended 214 that the receivers use TCP to fetch static media. If the group were 215 large, this would create an enormous load on the server holding the 216 static media. Instead a method that can take advantage of multicast 217 network is needed. In the past, plenty of work has been done on 218 achieving reliable transport over multicast, e.g. SRM [5]. There is 219 today ongoing work on standardizing solutions in the IETF Reliable 220 Multicast Transportation (RMT) working group. 222 Note that this payload format is not intended to replace such 223 mechanisms, instead it can be used to achieve simple unreliable 224 transport of static media that can tolerate some losses. 226 - Protocol mix prevents unified congestion control 228 The need for congestion control in the context of real-time media 229 delivery becomes more and more important. In this context a unified 230 congestion control approach on session level is more appropriate 231 compared to using different congestion control mechanisms for time- 232 lined static (TCP) and continuous (RTP/UDP) media elements. 234 - Protocol mix prevents unified bandwidth adaptation 236 The division of responsibility for transport of media between a 237 server and a client also complicates bandwidth adaptation. Audio and 238 video will be streamed down from the server to the client. The client 239 fetches static media from the server. If also the static media are 240 streamed to the client, the server can more easily ensure an optimal 241 quality of the overall presentation under the presence of a bandwidth 242 constraint. 244 We therefore propose to introduce a new RTP payload type suitable for 245 static media types. In the following section we will discuss some 246 important requirements of such a payload format before we are going 247 to describe our specification proposal for such a payload format. 249 4. Requirements 251 A payload format for time-lined static media types should fulfill the 252 following requirements: 254 - Timing information 256 The availability of timing information in the media packet(s) is 257 crucial. It can be used for many transmission related purposes, like 258 optimal scheduling of RTP packets at the application server. Timing 259 information also tells the client application when and for how long a 260 specific static media object should be presented to the user. 262 - Applicable to any kind of static media 264 The payload format SHOULD be generic enough to be applicable to any 265 kind of static media. 267 - Support for Application Level Framing (ALF) 269 The payload format SHOULD support packetization of data according to 270 the needs of the application [6]. An application might for instance 271 want to packetize the data belonging to one static object in a way 272 that is most resilient against packet losses. 274 - Support for object identifiers 276 It SHOULD be possible for client applications to reference each 277 object in a series of time-lined media objects by a unique 278 identifier. For instance in a layout specification file one might 279 want to specify different spatial locations for each of the time- 280 lined objects. How this can be done for instance within SMIL [1] is 281 however out of the scope of this document. 283 - Error resilience 285 The payload specification SHOULD support the employment of forward 286 error correction (FEC) mechanisms as described in RFC 2733 [7]. It 287 SHOULD also be possible to use the RTP retransmission methods that 288 are currently under discussion within IETF [10][11]. Also the 289 employment of application-level error concealment methods for lost 290 packets SHOULD NOT be prevented. 292 - Multicast capabilities 294 The payload format specification MUST allow streaming of time-lined 295 static media objects using multicasting. 297 5. Proposal for an RTP Payload Format for time-lined static media 299 This RTP payload format is supposed to be applicable to all kind of 300 static media types. We therefore use a header format that is 301 specified by a payload "framework" together with several payload 302 profiles. 304 The payload framework is independent of the media type and defines a 305 number of basic headers that can be used. Payload profiles are media 306 type dependent and define how to use the framework. Typically, a 307 payload profile defines which headers of the payload framework are 308 used, and MAY also specify new headers. A payload profile also 309 specifies and MAY give recommendations on how to packetize data of 310 the specific media type according to the ALF [6] principle. It may 311 also propose error recovery mechanisms for improved error resilience 312 against packet losses. 314 5.1. RTP Header Usage 316 The first part of an RTP packet is the fixed RTP header. The three 317 fields set by the application in the fixed RTP header, timestamp, 318 marker bit and payload type are explained here. For this payload 319 format these fields should be interpreted and defined as following: 321 Timestamp: The timestamp is used for identifying the time 322 when the object shall be used by the receiver(s). 323 The timestamp MUST be identical for all packets 324 being part of the same object, i.e. the timestamp 325 is used for binding packets to the correct 326 object. If two different objects are going to be 327 used at the same time, they MUST have different 328 timestamps. To minimize the effect of this rule, 329 the timestamp difference between these objects is 330 RECOMMENDED to be a single timestamp unit. The 331 timestamp rate is either defined, dynamically 332 during session setup, e.g. in SDP [4], or by a 333 profile. 335 Marker bit (M bit): The marker bit is used to indicate the last 336 packet of an object. 338 Payload Type (PT): The payload type is set dynamically and out of 339 band in accordance with current practice. 340 Different payload types SHALL be established for 341 each media profile that is used in a multimedia 342 session. 344 5.2. Header Formats 346 This section defines a number of general headers that can be used by 347 any profile. 349 All headers start with an eight-bit identifier. These identifiers are 350 taken from two different number spaces. The numbers 0-127 are used a 351 common number space, identifying general headers and must be 352 registered with IANA. Numbers 128-255 represent the profile specific 353 range. Each profile is responsible for assigning the header numbers 354 uniquely within this space. 356 A Header SHALL only be present a single time in the each packet, 357 unless the interpretation of multiple instances is defined in the 358 header format or a profile. 360 Some headers may contain information that is essential for the whole 361 object and not only for the actual packet. To reduce the probability 362 that this essential information is lost due to a single packet loss, 363 it is recommended to employ appropriate FEC mechanisms. In the 364 simplest case, important headers should be repeated in multiple 365 packets belonging to the same object. 367 5.2.1. Object Identifier Header 369 The object identifier header (OID) is used by applications to name 370 different objects within a stream. The exact meaning of the OID is 371 profile and/or application dependent. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Hd.type (1) | Len | Object Identifier | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 378 : (Variable len. 0-255) : 379 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | 381 +-+-+-+-+-+-+-+-+ 382 Len: Number of bytes that the object identifier consists of. Valid 383 lengths are 0-255, where 0 is allowed but lacks purpose. 385 Object Identifier: Byte stream used for identifying the object that 386 this packet is part of. The interpretation of the content of 387 this field is profile or/and application specific. 389 5.2.2. Duration Header 391 This header is used to express the duration for which the object is 392 to be used at the receiver, in timestamp units. 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Hd.type (2) | Duration | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | | 400 +-+-+-+-+-+-+-+-+ 402 Duration: The length of the time this object is to be used, expressed 403 in RTP Timestamp units. 405 5.2.3. Data Header 407 This header is used to carry object data. It MUST be the last header 408 used in the packet, since it lacks a length field. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Hd.type (0) | Data (until end of payload) ... | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Data: A byte stream of object data, which MUST be byte aligned. If 417 the object�s data prior to packetization in this header is not 418 byte aligned, the profile is responsible for defining how to 419 do it. 421 5.2.4. Offset Headers (ByteOffset) 423 A Fragmented byte stream needs indicators for where the data in each 424 packet belongs in the stream. This header gives an offset from the 425 start of the byte stream. The offset is of the first byte in the 426 fragmented data present in the packet. 428 16-bit offset field 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Hd.type (3) | Offset (16 bits) | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 32-bit offset field 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Hd.type (4) | Offset (32 bits) | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | | 444 +-+-+-+-+-+-+-+-+ 446 Offset: The offset in bytes from the start of the object that the 447 first byte in the data block shall be located. 449 5.3. Compound payload 451 A complete payload consists of one or more headers and their content. 452 Which headers that are used is profile and application dependent. The 453 order of the headers have no importance, except for the data header 454 and its data block, that MUST be located last in the payload. 456 If a receiver encounters an unknown payload header the 457 depacketization SHOULD be halted. Valid headers positioned before the 458 unknown MAY be used. The reason it cannot simply be ignored is that 459 the size is unknown. 461 An example packet could look like this. 463 -------------- 464 | RTP header | 465 -------------- <- RTP payload begins 466 | OID header | 467 -------------- 468 | ByteOffset | 469 -------------- 470 | Data head. | 471 -------------- 472 | Data | 473 -------------- 474 This example starts with the RTP header, which gives information 475 about which payload format and profile that is used in the PT field. 476 The timestamp gives information about when this object is to be 477 presented. The marker bit tells when the last packet in an object has 478 been received. 480 Looking at the start of the payload the header type field gives that 481 it is an Object Identifier. The length field of the OID gives how 482 long to read before the next payload header begins. The byte offset 483 header is of fixed length and after it is the data header. Directly 484 after the header the data begins and runs to the end of the payload. 486 6. Media Profiles 488 For each media type that is going to use this payload format, a 489 profile MUST be defined. A profile SHALL consists of the following: 491 - Definition of which of the general headers that are required, or 492 optional. Any unlisted header is prohibited 493 - Any definitions and numbering of profile specific headers. 494 - How to fragment an object to large for a single packet. 495 - Requirements and recommendations on how to improve the error 496 resilience of the media objects. 497 - A security consideration 498 - MIME Registration of the profile 500 In the following we give examples for appropriate media profiles for 501 JPEG images and text. 503 6.1. JPEG 505 Images, and especially JPEG, are widely used in multimedia 506 presentations. This profile describes how to transport image objects 507 in the form of JPEG coded images. The purpose of this profile is 508 different than the RTP payload format defined for motion JPEG in RFC 509 2035 [13] 511 The JPEG file should conform to the JPEG standard defined in ITU-T 512 Rec. T.81 | ISO/IEC 10918-1:1992 and the JPEG File Interchange 513 Format, JFIF. 515 The images are transported in the data and the JPEG file should end 516 with an End-Of-Image, EOI, marker segment signaled as 0xFFD9 [12]. 518 6.1.1. Resilient transport 520 A JPEG image might not be possible to fragment into sizes suitable 521 for transport over IP networks without converting the bit stream. 523 To achieve images that can be fragmented according to the ALF 524 principle the image MUST be created using restart markers. This 525 marker makes it possible for the decoder to restart the decoding even 526 if previous segments were lost. Also Restart Interval Definition 527 (DRI), see B.2.4.4 in [12], SHOULD be used in a way that allows a 528 decoder to compute the spatial area that is affected by a lost 529 fragment. 531 The JPEG file header contains information that is absolutely 532 necessary for the decoding process. To ensure that this vital 533 information reaches the receiver, it SHOULD be repeated in each 534 packet. The relevant JPEG header information that needs to be 535 duplicated is labeled "Tables/Misc." and "Frame Header" (see B.2.4 536 and B.2.2 in [12]). 538 6.1.2. Profile specific headers 540 JPEG image header (JPEGhdr) 542 This header is used for repeating the header information in packets 543 that do not carry the header information in their data section. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Hd.type (128) | Length | JPEG Header Data | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 550 | (Variable length) | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Length: The length in bytes of the JPEG Header Data. 555 JPEG Header Data: The data that MUST be copied into this header is: 556 Any information belonging to those parts of the bit stream 557 labeled "Tables/Misc." mentioned in section B.2.4, and "Frame 558 Header" in section B.2.2 in [12]. This means that the JPEG 559 header data includes all bytes starting with the first byte 560 after the SOI (start of image marker) until the scan starts. 562 6.1.3. Payload format header usage: 564 Any application using this profile MUST follow the table below 565 defining the usage of headers. 567 Headers Required Optional 568 ---------------------------------------------- 569 Data x 570 OID x 571 Duration x 572 ByteOffset x 573 JPEGhdr x 575 Each image is an object and fragmented if needed. The fragmentation 576 SHOULD be done at a restart marker. The ByteOffset header is used to 577 indicate where in each byte stream a fragment belongs. A JPEG image 578 header SHOULD be added to all packets to ensure that this essential 579 header information reaches the receiver. 581 6.2. TEXT 583 Time-lined text is typically used in subtitling, presentations, 584 advertisements, etc. Text streamed separate from other media will 585 give a greater flexibility in terms of language as well as spatial 586 and temporal control. 588 This profile describes how to transport text objects in the form of 589 strings. Each string consists of one or more lines. The text strings 590 are transported in the data part and SHALL also be NULL terminated. 591 The encoding of text shall be ISO 10 646-1 code with UTF-8 592 transformation. 594 6.2.1. Resilient transport 596 To make transport of text objects resilient against transport errors 597 the following measures can be taken. 599 The use of code based FEC, e.g. RFC 2733 [7] is RECOMMENDED to be 600 calculated over a single object. This will reduce the extra delay 601 that any recovery packet will result in. The use of FEC over an 602 object consisting of a single packet MAY give no advantage at all, 603 compared to repeating the packet one or several times. 605 It is RECOMMENDED to use retransmission [10]Error! Reference source 606 not found.[11] whenever it is possible. 608 6.2.2. Profile Specific Headers 610 Text Fragmentation header 612 This header is used to fragment text objects that are larger then one 613 packet (which is not the case for e.g. subtitling as mentioned 614 earlier, but can be the case for other applications). It has a row 615 and column offset used to place it in the correct position. A row is 616 equal to a text line and ends by a new line marker. The column number 617 is equal to which characters in order it is on the line, since the 618 last new line marker. A Text object MAY be fragmented at any 619 character, but it is RECOMMENDED to do fragmentation between 620 sentences or even more preferably between paragraphs. 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Hd.type (128) | Row Offset | Col. Offset | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Row Offset: 14 bits used to give a row offset into the text object, 629 i.e. the line in the text object which this packet's data 630 start on. 631 Column Offset: 10 bits giving which character on the line that the 632 text in the data part shall start on. 634 6.2.3. Payload format header usage: 636 Any application using this profile MUST follow the table below 637 defining the usage of headers. 639 Headers Required Optional Prohibited 640 ---------------------------------------------------------- 641 Data x 642 OID x 643 Duration x 644 ByteOffset x 645 TextFrag x 647 When fragmenting text objects it MUST be done using the TextFrag 648 header and not the ByteOffset header that would be a possibility. The 649 reason is that in the event of packet loss the fragment can be placed 650 on the correct row and character. Thus maintaining correct layout for 651 all received fragments. 653 7. Congestion Control 655 The need of congestion control for data transported with RTP has to 656 be considered. Some of the static media that can be transported by 657 this payload format have the possibility to adapt the size of each 658 object by trading size against quality. For example, an image can be 659 compressed to different sizes and corresponding qualities, and the 660 different versions can be sent alternatively. Attempting to use more 661 than the available bandwidth SHOULD be avoided. If FEC is used, there 662 is a need to regulate the amount, so that the FEC itself does not 663 worsen the problem. Therefore, it is RECOMMENDED that applications 664 using this payload also implement congestion control. The actual 665 mechanism for congestion control is not specified but should be 666 suitable for real-time flows, e.g. "Equation-Based Congestion Control 667 for Unicast Applications" [8]. For a more unified congestion control 668 between streams the congestion manager [14] can be used. 670 8. Security Consideration 672 RTP packets using the payload format defined in this specification 673 are subject to the security considerations discussed in the RTP 674 specification [3]. This implies that confidentiality of the media 675 streams is achieved by encryption. Because the payload format is 676 arranged end-to-end, encryption MAY be performed after encapsulation 677 so there is no conflict between the two operations. 679 This payload type and the profiles specified within this document 680 does not exhibit any significant non-uniformity in the receiver side 681 computational complexity for packet processing to cause a potential 682 denial-of-service threat. This MUST be considered and stated for all 683 new profiles created. Otherwise the main security issues are 684 confidentiality and authentication of the media itself. The payload 685 format itself does not have any support for security. These issues 686 have to be solved by a payload external mechanism, e.g. SRTP [9]. 688 8.1. Confidentiality 690 When confidentiality of the transported media is desired, all RTP 691 payload bits MUST be encrypted. 693 8.2. Authentication 695 To authenticate the sender of the media an external mechanism has to 696 be added. It is RECOMMENDED that such a mechanism protect all the 697 payload bits. To prevent a man in the middle from tampering with the 698 packetization of the media data, also the RTP header SHOULD be 699 protected. Tampering with the RTP header could result in erroneous 700 depacketization/decoding that will lower media quality. 702 9. IANA Considerations 704 [TBW] 706 10. MIME type registration 708 [TBW] 710 11. Author's Addresses 712 Magnus Westerlund Tel: +46 8 4048287 713 Ericsson Research Email: Magnus.Westerlund@ericsson.com 714 Ericsson Radio Systems AB 715 Torshamnsgatan 23 716 SE-164 80 Stockholm, SWEDEN 718 Kristofer Dovstam Tel: +46 8 7641788 719 Ericsson Research Email: Kristofer.Dovstam@era.ericsson.se 720 Ericsson Radio Systems AB 721 Torshamnsgatan 23 722 SE-164 80 Stockholm, SWEDEN 724 Frank Hartung Tel: +49 2407 575389 725 Ericsson Research Email: Frank.Hartung@eed.ericsson.se 726 Ericsson Eurolab Deutschland GmbH 727 Ericsson Allee 1 728 D-52134 Herzogenrath, GERMANY 730 Uwe Horn Tel: +49 2407 5757834 731 Ericsson Research Email: Uwe.Horn@eed.ericsson.se 732 Ericsson Eurolab Deutschland GmbH 733 Ericsson Allee 1 734 D-52134 Herzogenrath, GERMANY 736 12. References 738 [1] Synchronized Multimedia Integration Language(SMIL 2.0) 739 Specification, http://www.w3.org/TR/smil20, January 2001 740 [2] Postel, J., "Transmission Control Protocol � DARPA Internet 741 Program Protocol Specification", RFC 793, DARPA, September 742 1981. 743 [3] IETF RFC1889, "RTP: A Transport Protocol for Real-Time 744 Applications". 745 [4] IETF RFC 2327, "Session Description Protocol (SDP)". 746 [5] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang, L., "A 747 Reliable Multicast Framework for Light-weight Sessions and 748 Application Level Framing", IEEE/ACM Transactions on Networking, 749 December 1997, Volume 5, Number 6, pp. 784-803. 750 [6] D. Clark, D. Tennenhouse, "Architectural Considerations for a 751 New Generation of Protocols", Proc. ACM SIGCOMM�90, 1990. 752 [7] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for Generic 753 Forward Error Correction", RFC 2733, IETF, December 1999. 755 [8] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-Based 756 Congestion Control for Unicast Applications", ACM SIGCOMM 2000, 757 Stockholm, Sweden. 758 [9] R. Blom, et al., "The Secure Real Time Transport Protocol", IETF 759 WG draft, draft-ietf-avt-srtp-02.txt, November 2001, Work in 760 progress. 761 [10] Stephan Wenger and Joerg Ott, "RTCP-based Feedback: Concepts and 762 Message Timing Rules", draft-ietf-avt-rtcp-feedback-01.txt, 763 IETF, 21 November 2001, Work in progress. 764 [11] Miyazaki et al., "RTP Retransmission Payload Format", IETF WG 765 draft, draft-ietf-avt-rtp-selret-03.txt, November 2001, Work in 766 progress. 767 [12] ISO/IEC 10918-1, Information technology - Digital compression 768 and coding of continuous-tone still images requirements and 769 guidelines. 770 [13] L. Berc, et al., "RTP Payload Format for JPEG-compressed Video", 771 RFC 2035, IETF, October 1996. 772 [14] H. Balakrishnan and S. Seshan, "The Congestion Manager", RFC 773 3124, IETF, June 2001. 775 This Internet-Draft expires in July 2002.