idnits 2.17.1 draft-balabanian-rtp-mpeg4-dmif-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-balabanian-rtp-mpeg4-dmif-00', but the file name used is 'draft-balabanian-rtp-mpeg4-dmif-01' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 15) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 12 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 31 has weird spacing: '...roposal descr...' == Line 57 has weird spacing: '...chnical propo...' == Line 70 has weird spacing: '...chnical propo...' == Line 81 has weird spacing: '...achieve effic...' == Line 124 has weird spacing: '...media unaware...' == (2 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 689 looks like a reference -- Missing reference section? '2' on line 692 looks like a reference -- Missing reference section? '3' on line 695 looks like a reference -- Missing reference section? '4' on line 698 looks like a reference -- Missing reference section? '5' on line 701 looks like a reference -- Missing reference section? '6' on line 705 looks like a reference -- Missing reference section? '8' on line 714 looks like a reference -- Missing reference section? '9' on line 718 looks like a reference -- Missing reference section? '10' on line 723 looks like a reference -- Missing reference section? '7' on line 710 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Audio/Video Transport Working Group 2 INTERNET DRAFT Balabanian-Nortel 3 draft-balabanian-rtp-mpeg4-dmif-00.txt 4 September 16,1998 5 Expires: March 20,1999 7 The Role of DMIF in Support of RTP MPEG-4 Payloads 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or made obsolete by other documents at 18 any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 ABSTRACT 31 This draft technical proposal describes how RTP carrying MPEG-4 32 payloads interacts with the MPEG-4 Sync layer through the MPEG 33 (Delivery Multimedia Integration Framework) DMIF. Single or multiple 34 MPEG-4 streams can be carried over one RTP session. MPEG-4 information 35 essential for the efficient packing and unpacking of MPEG-4 streams 36 into/from RTP is identified. 38 The DMIF end-to-end signaling protocol is applied to identify the MPEG-4 39 RTP payload types and ensure stack compatibility at both sender and 40 receiver locations. DMIF also interprets the RTCP reports by comparing 41 its statistics to the requested MPEG-4 media based QoS. If the 42 statistics fail to meet the requested QoS then action is taken to either 43 continue with the impaired performance, upgrade the network service 44 class, scale down the stream or delete the stream. This action is apart 45 from scalability using the stream back-channel flow control which may 46 be present between an encoder and its decoder. 48 This is an update of the draft-ietf-avt-rtp-mpeg4-dmif-00. It reflects 49 the latest MPEG-4 specs. In addition some clarifications are included 50 and an open issues section is established based on feedback received. 52 1 Introduction 54 MPEG-4 is a recent standard from ISO/IEC for the coding of natural and 55 synthetic audio-visual data in the form of audiovisual objects that are 56 arranged into an audiovisual scene by means of a scene description [1] 57 [2][3][4]. This draft technical proposal specifies how DMIF is used to 58 facilitate the generation and consumption of the RTP MPEG-4 59 payloads [5][6]. 61 The MPEG-4 standards are versioned. Each version beyond V1 represents a 62 backward compatible extension. MPEG-4 V1 is targeted to become ISO 63 International Standard on December 1998 and each subsequent version 64 will be displaced approximately by a year. MPEG-4 V2 is targeted for 65 February 2000. DMIF is the part 6 of the MPEG-4 standard. 67 Where indicated, parts of this draft technical proposal will impact on 68 MPEG V2 International Standard targeted for February 2000. 70 This draft technical proposal provides a solution for discussion in 71 IETF AVT and ISO/IEC MPEG technical communities in order to identify 72 issues in using of MPEG-4/DMIF with RTP and incorporate the results. 73 This would lead to the finalization of the specification on RTP use of 74 MPEG-4 with DMIF. 76 1.1 Overview of MPEG-4 End-System Architecture 78 Figure 1 below shows the general architecture of MPEG-4 terminals. The 79 Compression Layer processes individual audio-visual media streams 80 without regard to delivery technologies. The compression schemes in 81 MPEG-4 achieve efficient encoding over a wide range from few Kbps to 82 multiple Mbps. The MPEG-4 compression schemes are defined in the 83 ISO/IEC specifications 14496-2 and -3 [2][3]. The media content at this 84 layer is organized in Elementary Streams. 86 The MPEG-4 Systems specification, ISO/IEC 14496-1 [1], defines the 87 concepts needed to describe the relations between Elementary Streams in 88 a way that allows to create distributed, yet integrated, content 89 presentations and to synchronize the streams. This part of the 90 specification is both media unaware and delivery technology unaware. 92 The Delivery Layer in MPEG-4 consists of the Delivery Multimedia 93 Integration Framework defined in ISO/IEC 14496-6 [4]. This layer is 94 media unaware but delivery technology aware. It provides transparent 95 access to and delivery of content irrespective of the technologies 96 used. The interface between the Sync Layer and DMIF is called DMIF 97 Application Interface (DAI). It offers content location independent 98 procedures for establishing MPEG-4 sessions and access to transport 99 channels. DMIF is primarily an integration framework. It provides a 100 default DMIF signaling (DS) protocol which corresponds to DMIF Network 101 Interface (DNI)primitives, see Figure 2. DS is used to complement the 102 lack functionality in underlying control protocols in order to keep the 103 integrity of the DMIF framework. 105 media aware +-----------------------------------------+ 106 delivery unaware | COMPRESSION LAYER | 107 14496-2 Visual | streams from few Kbps to multi-Mbps | 108 14496-3 Audio +-----------------------------------------+ 109 Elementary 110 Stream 111 =============================================================Interface 112 (ESI) 113 +-------------------------------------------+ 114 media and | SYSTEMS SYNC LAYER | 115 delivery unaware | manages elementary streams, their synch- | 116 14496-1 Systems | ronization and hierarchical relations | 117 +-------------------------------------------+ 118 DMIF 119 Application 120 ==============================================================Interface 121 (DAI) 122 +-------------------------------------------+ 123 delivery aware | DELIVERY LAYER | 124 media unaware |provides transparent access to and delivery| 125 14496-6 DMIF | of content irrespective of delivery | 126 | technology | 127 +-------------------------------------------+ 128 Figure 1: General MPEG-4 terminal architecture 130 1.2 The DMIF Model 132 DMIF as an integration framework uses a uniform procedure at the DAI 133 interface to access the MPEG-4 content irrespective whether the content 134 is broadcast, stored on a local file or obtained through interaction 135 with a remote end-system. The model is shown in Figure 2 below. 137 The specific instance of interest in this memorandum is the interaction 138 with a remote end-system. For this case DMIF uses internal (informative) 139 DMIF-Network Interface(DNI)primitives to map the controls obtained 140 from the application through DAI into the various signaling systems 141 appropriate to the various networks. The default end-to-end DMIF 142 signaling (DS)which corresponds to DNI is specified in DMIF V1 [4]. 144 ! +---+ +-----------+ +-----------+ +-----------+ 145 ! | | |Local DMIF | |Remote DMIF| |Remote App.| 146 +-----+ ! | D | |for Brd'cst| |(locally | |(locally | Brd'cst 147 | | ! | M | | | | emulated) | | emulated) |<-----source 148 |Local| ! | I | +-----------+ +-----------+ +-----------+ 149 | | ! | F | +-----------+ +-----------+ +-----------+ 150 |App | ! | | |Local DMIF | |Remote DMIF| |Remote App.| File 151 | | ! | F | |for Local | |(locally | |(locally |<-----source 152 | | ! | i | | Files | | emulated) | | emulated) | 153 | | ! | l | +-----------+ +-----------+ +-----------+ 154 | | ! | t | +-----------+ ! +---+ / ---- \ 155 | | ! | e | |Local DMIF | ! |Sig| | --- ---- | 156 +-----+ ! | r | |for Remote | ! |map|<->( Network ) |Outside the 157 ! | | | Service | ! | | | ---- ----- |scope of DMIF 158 ! +---+ +-----------+ ! +---+ | ----- | 159 DAI DNI | ^ | 160 \_____|_________/ 161 | 162 | 163 | +---+!+------+!+------+ 164 | |Sig|!|Remote|!|Remote| 165 +>|map|!| DMIF |!| App. | 166 | |!|(real)|!|(real)| 167 +---+!+------+!+------+ 168 DNI DAI 170 Figure 2: The DMIF model covers broadcast, local file storage 171 and remote service with a uniform procedure for 172 application transparency 174 1.3 Mapping between MPEG-4/DMIF and RTP 176 Figure 3 below draws the correspondence between RTP and MPEG-4/DMIF. It 177 is noted that DAI signaling allows the establishment of an MPEG-4 178 Service e.g., Video on Demand, the request of channels to carry MPEG-4 179 Elementary Streams for that service and the reading of Elementary 180 Stream data when received. The control flows for various scenarios 181 are defined in [4] 182 RTP MPEG-4/DMIF 183 +-----------------------------+ +---------------------------+ 184 / DATA TRANSPORT CONTROL \ / DATA TRANSPORT \ 185 (RTP) (RTCP) | (Elementary Stream) 186 Audio, Video SR, RR, SDES . Audio, Video 187 Simulated Data BYE, APP | Simulated Data 188 . 189 ^ ^ | ^ CONTROL (Scene, Object 190 I | . I Descriptor(OD), Play/ 191 I | | I Pause, Intellectual 192 I v . I Property Management) 193 I Corresponds to | I ^ 194 I DAI SIGNALING . I | 195 I | I | 196 I . I / 197 I | I / 198 I . I / 199 | I / 200 In addition to . I / SIGNALING 201 Audio, Video | I/ (Service, Channel, 202 Simulated Data . I Data) 203 to include Scene | I ^ 204 and OD streams . ====I==========|=== DAI 205 | I | 206 . I v 207 | Elementary Streams 208 . in SL-PDU fragments 210 Figure 3: Drawing some correspondence between MPEG-4/DMIF and RTP 212 The MPEG-4 stream packets passed across the DAI are formatted in Sync 213 Layer PDUs (SL-PDU). 215 The SL-PDUs can be mapped to RTP-PDUs as follows [6]: 216 RTP-PDU 1:1 SL-PDU 217 RTP-PDU 1:N SL-PDU 218 RTP-PDU N:1 SL-PDU 220 The selection for a particular MPEG-4 stream from the above choices is 221 based on a number of factors including the size of the SL-PDU compared 222 to the RTP-PDU MTU size[6]. The first choice uses MPEG-4 single stream 223 RTP payload type. The second case uses MPEG-4 RTP FlexMux payload type. 224 The last choice also uses MPEG-4 FlexMux RTP payload type. It occurs 225 when MPEG-4 Sync Layer is not able to adjust the MPEG-4 SL-PDU lengths 226 to be within the path MTU. 228 Since MPEG-4 FlexMux is optional, any other equivalent scheme could 229 be used. Some muxing schemes under consideration now for RTP are 230 provided in [8][9][10]. 232 2 Operation of the RTP MPEG-4 payloads with DMIF 234 This section covers the conceptual operation of the MPEG-4/DMIF with 235 RTP. The DAI primitives shall be used to set up the MPEG-4 session[4]. 236 When the RTP is used an originating (or a destination) DMIF entity could 237 be used to start the RTP session with its corresponding RTP data 238 transport (carrying one or more MPEG-4 Elementary Streams) and RTCP for 239 control. RTCP packets use the same transport media over which the RTP 240 data packets are sent. 242 2.1 Using MPEG-4 single stream mapping into RTP session 243 The AVT WG encourages the initial experimentaion on MPEG-4 payloads 244 using a single MPEG_4 stream per RTP session. This is in contrast to the 245 mode of multiple streams per RTP session specified in section 2.2. 247 | 248 | 249 v 250 +---+ SIGNALING 251 |SL | (MTU + SLConfigDescriptor) 252 +---+ 253 | ^ 254 MPEG ------- MPEG -------- 255 | | 256 ===================|=================================|===DAI=== 257 v v 258 +------------------------------------+ +---------------+ 259 | Regenerate SL-PDUs |<------| DMIF | 260 +------------------------------------+ . | instance | 261 MPEG-4 | Time | Sequence| . +---------------+ 262 Payloads | Stamps | Numbers| ALConfig ^ ^ 263 v v v Descriptor | | 264 +-----------------------+ v | 265 | RTP Coder | +-----------+| 266 +-----------------------+ |RTCP Codec || 267 I +-----------+| 268 I ^ | 269 I | | 270 I +-----------------------+ v 271 I | ~~~~~~~~DNI 272 IETF ------ (DMIF Signaling 273 V v Protocol) 274 | 275 MPEG ------ 276 | 277 v 278 Figure 4: Conceptual view of the sender operating with MPEG-4 279 single stream RTP Payload type 280 Figures 4 and 5 show the operation at the sender and receiver ends 281 respectively. In case of a single MPEG-4 stream payload type, the 282 SLConfigDescriptor is being received at the sender side and being used 283 both at the sender and the receiver for efficient packing and unpacking 284 of the streams into and from the RTP transport [6]. 286 The horizontal lines across the flows indicate the standard 287 to which the flow conforms to. It is noted that while the streams 288 above the DAI conform to MPEG, the network streams consist of a 289 combination of IETF RTP/RTCP and MPEG Default DMIF signaling protocol. 291 ^ 292 | 293 | 294 +---+ SIGNALING 295 |SL | (MTU + ALConfigDescriptor) 296 +---+ 297 ^ ^ 298 | | 299 MPEG ------- MPEG -------- 300 | | 301 ===================|=================================|===DAI=== 302 | v 303 +------------------------------------+ +---------------+ 304 | Regenerate SL-PDUs |<------| DMIF | 305 +------------------------------------+ . | | 306 MPEG-4 ^ Time ^ Sequence^ . +---------------+ 307 Payloads | Stamps | Numbers| SLConfig ^ ^ 308 | | | Descriptor | | 309 +-----------------------+ v | 310 | RTP Parser | +-----------+| 311 +-----------------------+ |RTCP Parser|| 312 ^ +-----------+| 313 I ^ | 314 I | | 315 I +-----------------------+ | 316 I | | 317 IETF ------ | 318 I | ~~~~~~~~DNI 319 I v (Default DMIF Signaling 320 Protocol) 321 | 322 MPEG ------ 323 | 324 v 325 Figure 5: Conceptual view of the receiver operating with MPEG-4 326 single stream RTP Payload type 327 2.2 Using MPEG-4 multiple stream mapping into RTP session 328 Although using the method of MPEG-4 FlexMux to carry multiple MPEG-4 329 streams over an RTP session is technically sound, the AVT WG is in the 330 process of examining methods of generic muxing of RTP streams which 331 in effect will achieve the same end of MPEG-4 FlexMux but without 332 unpredictable side effects on RTP[8][9][10]. 334 Figure 6 (sender) and 7 (receiver) show that in the case of MPEG-4 335 FlexMux RTP payload type, information for the MTU and SLConfig is not 336 required. The FlexMux decoder however needs the MuxCode information 337 which is generated at the sending end by the FlexMux muxing code and 338 passed to the receiver through the DMIF signaling (DS). DS is an out of 339 band point-to-point protocol to MPEG-4 media streams. It complements 340 RTCP. Multicast DMIF signaling is for DMIF V2 or later consideration. 342 Audio, Video, Simulated Data, Scene, ODs 344 | | | | 345 | | | | 346 v v v v 347 +---+ +---+ +---+ +---+ 348 |SL | |SL | |SL |. . . . . . |SL | 349 +---+ +---+ +---+ +---+ SIGNALING 350 | | | | ^ 351 | | | | | 352 ==|=====|=====|=====================|====================|===DAI=== 353 v v v v v 354 +--------------------------------------+ +---------------+ 355 | FlexMux |------>| DMIF | 356 +--------------------------------------+ . | instance | 357 MPEG-4 | . +---------------+ 358 Payloads | . ^ ^ 359 v MuxCode | | 360 +-----------------------+ Descriptor v | 361 | RTP Coder | +-----------+| 362 +-----------------------+ |RTCP Codec || 363 I +-----------+| 364 I ^ | 365 I | | 366 I +----------------------------+ | 367 I | ~~~~~~~~DNI 368 IETF ------ (Default DMIF Signaling 369 I | Protocol) 370 V v | 371 MPEG ------ 372 | 373 v 375 Figure 6: Conceptual view of the sender operating with MPEG-4 FlexMux 376 RTP Payload type 377 Audio, Video, Simulated Data, Scene, ODs 379 ^ ^ ^ ^ 380 | | | | 381 | | | | 382 +---+ +---+ +---+ +---+ 383 |SL | |SL | |SL |. . . . . . |SL | SIGNALING 384 +---+ +---+ +---+ +---+ ^ 385 | | | | | 386 ---------------------- MPEG ----------- MPEG ------ 387 ==|=====|=====|=====================|====================|===DAI=== 388 | | | | v 389 +--------------------------------------+ +---------------+ 390 | FlexDemux |<------| DMIF | 391 +--------------------------------------+ . | instance | 392 MPEG-4 | . +---------------+ 393 Payloads | . ^ ^ 394 v MuxCode | | 395 +-----------------------+ Descriptor v | 396 | RTP Coder | +-----------+| 397 +-----------------------+ |RTCP Codec || 398 ^ +-----------+| 399 I ^ | 400 I | | 401 I +----------------------------+ | 402 I | ~~~~~~~~DNI 403 IETF ------ (Default DMIF Signaling 404 I | Protocol) 405 I v | 406 MPEG ------ 407 | 408 v 410 Figure 7: Conceptual view of the receiver operating with MPEG-4 FlexMux 411 RTP Payload type 413 3 RTCP Sender and Receiver Reports 414 RTP receivers provide reception quality feedback using RTCP report 415 packets which may take one of two forms depending upon whether or not 416 the receiver is also a sender. 418 These reports shall be used by DMIF in the case of MPEG-4/DMIF-RTP 419 to readjust the demand put on the network based on a predefined policy 420 which may involve a decision to be made by the user. 422 The sender report packet consists of three sections, possibly followed 423 by a fourth profile-specific extension section if defined (none has 424 been specified so far for MPEG-4 RTP payloads). 426 The third section contains zero or more reception report blocks 427 depending on the number of other sources heard by this sender since the 428 last report. Each reception report block conveys statistics on the 429 reception of RTP packets from a single synchronization source. 431 Annex A provides the DMIF per channel (MPEG-4 elementary stream) "media 432 based" QoS. This is adjusted for the RTP stream in both single and 433 multiple stream MPEG-4 mappings. The remainder of this section 434 attempts to match the "delivered" RTP stream performance as measured by 435 the receiver reports to the expected performance calculated using the 436 "media based" QoS. 438 SSRC_n (source identifier): 439 -------------------------- 440 The SSRC identifier of the source to which the information in this 441 reception report block pertains. This SSRC may either relate to an 442 MPEG-4 single or FlexMux RTP payload session. 444 fraction lost: 445 ------------- 446 The fraction of RTP data packets from source SSRC_n lost since the 447 previous SR or RR packet was sent, expressed as a fixed point number. 448 This type of loss is normally compensated by the decoder through 449 mechanisms such as concealment. 451 The fraction lost is compared to the LOSS_PROB in Annex A. It is 452 important that the duration over which this metric is measured is 1 453 sec to correspond to the same duration used to express the LOSS_PROB. 454 If the statistics consistently exceeds the LOSS_PROB then the policy 455 enforcer is brought into action. As a result the load on the RTP 456 stream is reduced. 458 interarrival jitter: 459 ------------------- 460 An estimate of the statistical variance of the RTP data packet 461 interarrival time, measured in timestamp units and expressed as an 462 unsigned integer. 464 The jitter calculation in RTCP is based on the variation of 465 consecutive interarrival times: 467 If Si is the RTP timestamp from packet i, and Ri is the time of 468 arrival in RTP timestamp units for packet i, then for two packets i 469 and j, D may be expressed as 471 D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si) 473 The interarrival jitter is calculated continuously as each data 474 packet i is received from source SSRC_n, using this difference D for 475 that packet and the previous packet i-1 in order of arrival (not 476 necessarily in sequence), according to the formula 478 J=J+(|D(i-1,i)|-J)/16 480 Whenever a reception report is issued, the current value of J is 481 sampled. 483 The synchronization between streams in MPEG-4 does not rely on the 484 jitter value e.g., for lip sync. This function is carried out at the 485 level of the Sync layer based on composition time stamps of the 486 respective streams. 488 In MPEG-4/DMIF V2 the jitter is used to ensure that the receive 489 decoder buffers are not exceeded. 491 It is noted that the RTCP interarrival jitter is intended as a 492 comparison measure between streams or at different times rather than 493 as an absolute measure. therefore the formula below is based on a 494 specific method of managing the dejitter buffer. 496 Assuming that the operation adjusts so that the pointer for decoding 497 the stream is in the middle of the Dejitter_Buffer. The Buffer can 498 accept an amount of burst or deficiency not exceeding twice the value 499 of J x Maximum Rate where: 500 Maximum Rate = MAX_RTP_SIZE* MAX_RTP_RATE 502 Therefore, 504 J must be <= to .5*Dejitter_Buffer/( MAX_RTP_SIZE* MAX_RTP_RATE) 506 If this value is exceeded consistently for some time then the QoS 507 policy enforcer is brought into action. As a result the load on the 508 RTP stream is reduced. 510 Round trip Delay: 511 ---------------- 512 This delay is calculated by measuring the time sending a sender 513 report and receiving the associated receiver report and subtracting 514 the delay it took to send the receiver report at the receiver. 516 Delay must be <= 2*MAX_DELAY converted to seconds from microseconds 518 Average Delay over 1 minute <= 2*AVG_DELAY converted to seconds from 519 microseconds 521 If either of the above values is exceeded consistently for some time 522 then the QoS policy enforcer is brought into action. As a result the 523 load on the RTP stream is reduced. 525 4. SDES 527 When a DA_ChannelAdd() is requested by the application, DMIF decides 528 whether to initiate a new RTP stream or use one of the existing ones 529 with a FlexMuxed payload type. Only in the case if a new RTP stream 530 is decided the SDES RTCP packet will be sent. This will coincide with 531 the DS_TransMuxSetup() sent on DMIF Signaling [7]. 533 5. BYE: Goodbye RTCP packet 534 When a single stream is used in the case of the MPEG-4 single stream RTP 535 payload, a BYE packet is sent along with the DS_ChannelDelete using 536 DMIF-DMIF signaling[4]. At the receiver either a BYE packet or 537 DS_ChannelDelete signal will cause DAI to pass DA_ChannelDelete to the 538 application. When a FlexMux stream is used, the BYE packet is generated 539 when no longer any MPEG-4 streams are carried on the RTP session. This 540 means that DS_ChannelDeletes have already been sent for all the channels 541 carried on the RTP session and the application has been notified by 542 DA_ChannelDelete(s) across the DAI. A BYE message is followed by a 543 DS_TransMuxDelete which at the reception will allow both the sending 544 and receiving DMIF sides to reuse the RTP/IP ports[4]. 546 6. Open Issues: 548 1- Multicast operation and the inclusion of RTP mixers i.e., 549 aggregation of the streams and adjustment of their QoSs 550 from receivers up to the senders. 551 2- The inclusion of RTP Payload Format for User Multiplexing [8][9][10] 552 A Derivation of the RTP QoS using MPEG-4/DMIF Media Based QoS 554 The media based QoS and associated priority are important 555 considerations in MPEG-4 [1][4] since they are used as a base for 556 decision making on how to transport the streams over a network. The 557 following table provides the media QoS specified by the content 558 provider irrespective of the network used for the transport of the 559 media. No QoS values will be available in DMIF V2 The only parameters 560 being specified in V1 are for characterizing the traffic load of the 561 stream (the last 3 rows in the table below). 563 The values expressed in the table below relate to the MPEG-4 Access 564 Units (AU), these are the smallest data entities to which timing 565 information can be attributed. The AUs form the payload of the 566 SL-PDUs and may undergo segmentation by the Sync Layer. For example 567 the maximum SL-PDU size of an MPEG-4 stream can never be larger than 568 the one that corresponds to the maximum AU size. 570 +=====================+=====================================+ 571 | Media | Meaning of the | 572 | QoS_QualifierTag | ES Media QoS | 573 +=====================+=====================================+ 574 | MAX_DELAY |Maximum delay per AU (microseconds) | 575 | (DMIF V2) |measured over 1 sec. | 576 +---------------------+-------------------------------------+ 577 | AVG_DELAY |Average delay per AU allowed | 578 | (DMIF V2) |(microseconds) measured over 1 min | 579 +---------------------+-------------------------------------+ 580 | Dejitter Buffer | Bytes reserved for the removal of | 581 | (DMIF V2) | transport jitter from the steam | 582 +---------------------+-------------------------------------+ 583 | LOSS_PROB |Probability of loss of any single AU | 584 | (DMIF V2) |(Fraction (0.00 - 1.00) over 1 sec. | 585 +===========================================================+ 586 | MAX_AU_SIZE |Maximum size of an AU (Bytes) | 587 | (DMIF V1) | | 588 +---------------------+-------------------------------------+ 589 | MAX_AU_RATE |Maximum arrival rate of an AUs | 590 | (DMIF V1) |(AU-PDU/second) | 591 +---------------------+-------------------------------------+ 592 | AVG_RTP_SIZE |Average size of AUs (Bytes) | 593 | (DMIF V1) | | 594 +---------------------+-------------------------------------+ 595 A.1 The case RTP-PDU 1:1 (or N:1) SL-PDU 597 The table below shows the stream QoS for the case when 598 a single ES is mapped into the RTP PDU. Only the traffic 599 load parameters (the last 3 rows in the table below) are 600 specified in DMIF V1 targeted to be an ISO/IEC International 601 Standard in December 1998. 603 Normally an RTP-PDU would carry an SL-PDU with a complete AU. 604 In rare cases the SL-PDU would segment the AU in order to 605 for its size to correspond the the RTP-PDU MTU (IP size) as 606 dictated by the underlying network. 608 +=====================+=====================================+ 609 | RTP Stream | Derivation from the | 610 | QoS_QualifierTag | ES Media transport-QoS | 611 +=====================+=====================================+ 612 | MAX_DELAY of RTP PDU|Maximum delay per AU (microseconds) | 613 | (DMIF V2) |measured over 1 sec. | 614 +---------------------+-------------------------------------+ 615 | AVG_DELAY of RTP PDU|Average delay per AU allowed | 616 | (DMIF V2) |(microseconds) measured over 1 min | 617 +---------------------+-------------------------------------+ 618 | Dejitter Buffer | Adjusted for the overhead of the | 619 | for the RTP stream | RTP PDU | 620 | (DMIF V2) | | 621 +---------------------+-------------------------------------+ 622 | LOSS_PROB of RTP PDU|Probability of loss of any single AU | 623 | (DMIF V2) |(Fraction (0.00 - 1.00) over 1 sec. | 624 +===========================================================+ 625 | MAX_RTP_SIZE |Maximum size of an AU (Bytes) | 626 | (DMIF V1) |Plus AL-PDU and RTP overhead | 627 +---------------------+-------------------------------------+ 628 | MAX_RTP_RATE |Maximum arrival rate of AUs | 629 | (DMIF V1) |(RTP-PDU/second) | 630 +---------------------+-------------------------------------+ 631 | AVG_RTP_SIZE |Average size of AUs (Bytes) | 632 | (DMIF V1) |Plus AL-PDU and RTP overhead | 633 +---------------------+-------------------------------------+ 634 A.2 The case RTP-PDU 1:N SL-PDU 636 The table below shows the stream QoS for the case when multiple ES are 637 aggregated into the RTP PDU. Only the traffic load parameters (the last 638 3 rows in the table below) are specified in DMIF V1 targeted to be an 639 ISO/IEC International Standard in December 1998. 641 In most cases this method will be used when the AU is <<256 bytes. 642 Each SL-PDU therefore will carry a complete AU. 644 +=====================+=====================================+ 645 | RTP Stream | Derivation from the | 646 | QoS_QualifierTag | ES Media QoS | 647 +=====================+=====================================+ 648 | MAX_DELAY of RTP PDU|Least Maximum delay per AU from | 649 | (DMIF V2) |among the N AL-PDUs(microseconds) | 650 | |measured over 1 sec. | 651 +---------------------+-------------------------------------+ 652 | AVG_DELAY of RTP PDU|Average delay per AU allowed | 653 | (DMIF V2) |(microseconds) measured over 1 min. | 654 +---------------------+-------------------------------------+ 655 | Dejitter Buffer | Total of dejitter buffers adjusted | 656 | for the RTP stream | for the overhead of the RTP PDU | 657 | (DMIF V2) | | 658 +---------------------+-------------------------------------+ 659 | LOSS_PROB of RTP PDU|Least Probability of loss of any | 660 | (DMIF V2) |single AU from the N AL-PDUs | 661 | |(Fraction (0.00 - 1.00) over 1 sec. | 662 +===========================================================+ 663 | MAX_RTP_SIZE |Sum of the MAX_AU_SIZEs of from | 664 | (DMIF V1) |each of the N AL-PDUs Plus AL-PDU | 665 | |and RTP overhead | 666 +---------------------+-------------------------------------+ 667 | MAX_RTP_RATE |Highest MAX_AU_RATE of AUs from each | 668 | (DMIF V1) |of the N AL-PDUs (RTP-PDU/second) | 669 +---------------------+-------------------------------------+ 670 | AVG_RTP_SIZE |Sum of Average size of AUs from | 671 | (DMIF V1) |each of the N AL-PDUs Plus | 672 | |AL-PDU and RTP overhead (Bytes) | 673 +---------------------+-------------------------------------+ 675 Note all the MPEG-4 streams chosen for aggregation over an RTP 676 stream belong to the same stream priority level identified by 677 the Sync Layer. 679 B Authors' Addresses 681 Vahe Balabanian 682 Nortel 683 P.O.Box 3511, St. C 684 Ottawa, Ontario 685 Canada K1Y 4H7 686 Email: balabani@nortel.ca 687 B Bibliography 689 [1] ISO/IEC 14496-1 FCD "MPEG-4 Systems" Oct. 1998, obtained from 690 the MPEG Home Page http://drogo.cselt.it/mpeg/ 692 [2] ISO/IEC 14496-2 FCD "MPEG-4 Visual" Oct. 1998, obtained from 693 the MPEG Home Page http://drogo.cselt.it/mpeg/ 695 [3] ISO/IEC 14496-3 FCD "MPEG-4 Audio" Oct. 1998, obtained from 696 the MPEG Home Page http://drogo.cselt.it/mpeg/ 698 [4] ISO/IEC 14496-6 CD "DMIF" Oct. 1998, obtained from 699 the MPEG Home Page http://drogo.cselt.it/mpeg/ 701 [5] Schulzrinne, Casner, Frederick, Jacobson 'RTP: A 702 Transport Protocol for Real Time Applications' RFC 703 1889,Internet Engineering Task Force, Jan. 1996. 705 [6] Carsten, Balabanian, Basso, Civanlar, Hoffman, Speer, 706 Schulzrinne, 'RTP payload format for MPEG-4 Elementary 707 Streams' draft-ietf-avt-rtp-mpeg4, Internet 708 Engineering Task Force, March 1998. 710 [7] Balabanian, 'The Use of MPEG-4/DMIF and RSVP with Integrated 711 Services' draft-balabanian-intserv-dmif, Internet 712 Engineering Task Force, August 1998. 714 [8] J.Rosenberg, H.Schulzrinne 'An RTP Payload Format for User 715 Multiplexing' draft-ietf-avt-aggregation, Internet 716 Engineering Task Force, May 1998. 718 [9] Keiko Tanigawa, Tohru Hoshi, Koji Tsukada 'An RTP Simple 719 Multiplexing Transfer Method for Internet Telephony Gateway' 720 draft-tanigawa-rtp-multiplex-00, Internet 721 Engineering Task Force, June 16, 1998. 723 [10] B. Subbiah, S. Sengodan 'User Multiplexing in RTP payload between 724 IP Telephony Gateways' draft-ietf-avt-mux-rtp-00, Internet 725 Engineering Task Force, Aug 31, 1998. 727 Internet Engineering Task Force Audio/Video Transport Working Group 728 September 16, 1998 729 Expires: March 20, 1999