idnits 2.17.1 draft-balabanian-rtsp-mpeg4-dmif-00.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-04-26) 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. == 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 12) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 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 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 73 has weird spacing: '...achieve effic...' == Line 116 has weird spacing: '...media unaware...' == Line 279 has weird spacing: '...service using...' == Line 303 has weird spacing: '...ify the proce...' -- 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 655 looks like a reference -- Missing reference section? '2' on line 658 looks like a reference -- Missing reference section? '3' on line 661 looks like a reference -- Missing reference section? '4' on line 664 looks like a reference -- Missing reference section? '5' on line 667 looks like a reference -- Missing reference section? '6' on line 671 looks like a reference -- Missing reference section? '7' on line 676 looks like a reference -- Missing reference section? '8' on line 679 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 10 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-rtsp-mpeg4-dmif-00.txt 4 Sept. 22,1998 5 Expires: March 26,1999 7 The Role of DMIF with RTSP and MPEG-4 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 MPEG DMIF (Delivery 32 Multimedia Integration Framework) can be used with RTSP for setting 33 MPEG-4 service sessions and subsequently detaching the service. DMIF 34 creates an instance of DMIF RTSP augmented with QoS appropriate for 35 each MPEG-4 stream and also makes use of the FlexMux to carry multiple 36 streams on a single UDP or TCP IP flow. The stream control play/pause 37 etc. using RTSP is executed directly by the MPEG-4 Systems Sync Layer. 39 Comments are solicited and should be addressed to the working group's 40 mailing list at confctrl@isi.edu and/or the authors. 42 1 Introduction 44 MPEG-4 is a recent standard from ISO/IEC for the coding of natural and 45 synthetic audio-visual data in the form of audiovisual objects that are 46 arranged into an audiovisual scene by means of a scene description [1] 47 [2][3][4]. This draft proposal specifies how DMIF is used with RTSP [5] 48 and RTP MPEG-4 payloads over Internet[6][7][8]. 50 This draft proposal provides a solution for discussion in IETF MMUSIC 51 and ISO/IEC MPEG technical communities in order to identify issues in 52 using MPEG-4/DMIF with RTSP and will incorporate the results in the 53 MPEG-4specifications and issue this proposal as an RFC draft. 55 The MPEG-4 standards are versioned. Each version beyond V1 represents a 56 backward compatible extension. MPEG-4 V1 is targeted to become ISO 57 International Standard on December 1998 and each subsequent version will 58 be displaced approximately by a year. MPEG-4 V2 is targeted for February 59 2000. DMIF is part 6 of the MPEG-4 standard. 61 This technical proposal will impact on MPEG V2 International Standard 62 targeted for February 2000. 64 The content of this draft technical proposal is intentionally kept at 65 a tutorial level in order to facilitate the discussion among the 66 interested participants. 68 1.1 Overview of MPEG-4 End-System Architecture 70 Figure 1 below shows the general architecture of MPEG-4 terminals. The 71 Compression Layer processes individual audio-visual media streams 72 without regard to delivery technologies. The compression schemes in 73 MPEG-4 achieve efficient encoding over a wide range from few Kbps to 74 multiple Mbps. The MPEG-4 compression schemes are defined in the 75 ISO/IEC specifications 14496-2 and -3 [2][3]. The media content at this 76 layer is organized in Elementary Streams. 78 The MPEG-4 Systems specification, ISO/IEC 14496-1 [1], defines the 79 concepts needed to describe the relations between Elementary Streams in 80 a way that allows the creation of distributed, yet integrated, content 81 presentations and to synchronize the streams. This part of the 82 specification is both media unaware and delivery technology unaware. 84 The Delivery Layer in MPEG-4 consists of the Delivery Multimedia 85 Integration Framework defined in ISO/IEC 14496-6 [4]. This layer is 86 media unaware but delivery technology aware. It provides transparent 87 access to and delivery of content irrespective of the technologies 88 used. The interface between the Sync Layer and DMIF is called DMIF 89 Application Interface (DAI). It offers content location independent 90 procedures for establishing MPEG-4 sessions and access to transport 91 channels. DMIF is primarily an integration framework. It provides a 92 default DMIF signaling (DS) protocol which corresponding to DMIF Network 93 Interface (DNI), see Figure 2. DS is used to complement the lack 94 functionality in underlying control protocols in order to keep the 95 integrity of the DMIF framework. 97 media aware +-----------------------------------------+ 98 delivery unaware | COMPRESSION LAYER | 99 14496-2 Visual |streams from as low as Kbps to multi-Mbps| 100 14496-3 Audio +-----------------------------------------+ 101 Elementary 102 Stream 103 =============================================================Interface 104 (ESI) 105 +-------------------------------------------+ 106 media and | SYSTEMS SYNC LAYER | 107 delivery unaware | manages elementary streams, their synch- | 108 14496-1 Systems | ronization and hierarchical relations | 109 +-------------------------------------------+ 110 DMIF 111 Application 112 ==============================================================Interface 113 (DAI) 114 +-------------------------------------------+ 115 delivery aware | DELIVERY LAYER | 116 media unaware |provides transparent access to and delivery| 117 14496-6 DMIF | of content irrespective of delivery | 118 | technology | 119 +-------------------------------------------+ 120 Figure 1: General MPEG-4 terminal architecture 122 1.2 The DMIF Model 124 DMIF as an integration framework uses a uniform procedure at the DAI 125 interface to access the MPEG-4 content irrespective whether the content 126 is broadcast, stored on a local file or obtained through interaction 127 with a remote end-system. The model is shown in Figure 2 below. 129 The specific instance of interest in this memorandum is the interaction 130 with a remote end-system. For this case DMIF uses internal 131 (informative) DMIF-Network Interface(DNI)to map the controls obtained 132 from the application through DAI into the various signaling appropriate 133 to the various networks. The default end-to-end DMIF signaling (DS) 134 protocol which corresponds to DNI is specified in DMIF V1 [4]. 136 ! +---+ +-----------+ +-----------+ +-----------+ 137 ! | | |Local DMIF | |Remote DMIF| |Remote App.| 138 +-----+ ! | D | |for Brd'cst| |(locally | |(locally | Brd'cst 139 | | ! | M | | | | emulated) | | emulated) |<-----source 140 |Local| ! | I | +-----------+ +-----------+ +-----------+ 141 | | ! | F | +-----------+ +-----------+ +-----------+ 142 |App | ! | | |Local DMIF | |Remote DMIF| |Remote App.| File 143 | | ! | F | |for Local | |(locally | |(locally |<-----source 144 | | ! | i | | Files | | emulated) | | emulated) | 145 | | ! | l | +-----------+ +-----------+ +-----------+ 146 | | ! | t | +-----------+ ! +---+ / ---- \ 147 | | ! | e | |Local DMIF | ! |Sig| | --- ---- | 148 +-----+ ! | r | |for Remote | ! |map|<->( Network ) |Outside the 149 ! | | | Service | ! | | | ---- ----- |scope of DMIF 150 ! +---+ +-----------+ ! +---+ | ----- | 151 DAI DNI | ^ | 152 \_____|_________/ 153 | 154 | 155 | +---+!+------+!+------+ 156 | |Sig|!|Remote|!|Remote| 157 +>|map|!| DMIF |!| App. | 158 | |!|(real)|!|(real)| 159 +---+!+------+!+------+ 160 DNI DAI 162 Figure 2: The DMIF model covers broadcast, local file storage 163 and remote service with a uniform procedure for 164 application transparency 166 2 Placing RTSP within the MPEG-4 architecture 168 In order to make use of the functions enabled by RTSP, 169 DMIF RTSP Client and Server modules are created as shown in 170 Figure 3 below. These modules interface with DAI and interwork with 171 the MPEG-4 Sync Layer. It is an internal implementation decision 172 not affecting interoperability whether to combine the DRTSP client and 173 server functions with the Sync Layer or keep them separate. It is noted 174 that DAI allows the establishment of an MPEG-4 service session e.g., 175 RTSP Video on Demand session, the request of channels to carry MPEG-4 176 Elementary Streams for that service are executed by the DMIF-RTSP 177 (DRTSP) module instantiated by DMIF as a response to the DRTSP-URL in 178 the MPEG-4 service session request. This module as described here only 179 carries out RTSP SETUP and TEARDOWN functions while the stream control 180 functions are carried out through the interactions of the DRTSP servers 181 with the Sync layer. 183 The signaling between the two instances of the DRTSP at the 184 originating and destination DMIFs can initially use the default DMIF 185 signaling and wrap the RTSP related fields in a DMIF-to-DMIF Data 186 fields. Later versions may extend the RTSP to include the DMIF 187 functionality, in that case the proper RTSP signaling will be used. 188 Backward compatibility is assured by the way of a common set of DMIF 189 Network Interface (DNI) primitives, see Figure 2 which are used to 190 generate the DMIF signaling messages or their RTSP extensions. 192 DAI DAI 193 +-----+ I I +-----+ 194 / DRTSP \ I+-----+ DMIF Signaling +-----+I / DRTSP \ 195 | Client |<--->|Orig.|<-------------->|Dest.|<--->| Server | 196 \ / I|DRTSP| |DRTSP|I \ / 197 +-----+ I+-----+ +-----+I +-----+ 198 ^ I I ^ 199 | I I | 200 | I I | 201 v I I v 202 +-----------+I I +-----------+ 203 | MPEG-4 |I I | MPEG-4 | 204 |Systems |<==============================> |Systems | 205 |Sync Layer |I I |Sync Layer | 206 +-----------+I I +-----------+ 208 Figure 3: RTSP within the MPEG-4 architecture 210 3 DMIF RTSP Message Sequences 212 3.1 Setting up MPEG-4 RTSP service session 214 MPEG-4 is an object based encoding with Scenes described 215 in Binary Information Formatted Streams (BIFS)and objects 216 placed within a scene described with Object Descriptor (OD) 217 streams [1]. In order to be able to begin viewing MPEG-4, 218 both the BIFS and the OD decoders must be set for parsing at the 219 receiver end in order to be able to decode the BIFS and OD 220 streams[1]. This information is obtained from the Initial 221 Object Descriptor (IOD)file. The location of IOD can be expressed 222 in a DRTSP-URL which can be obtained by any means. The DRTSP URL 223 indicates that the MPEG-4 play control functions use the RTSP 224 controls as defined in RFC 2326 [5]. 226 As a result of this action DMIF instantiates DRTSP instances 227 at both the originating and destination DMIF locations and 228 engages the DRTSP client with the DRTSP server. The signaling 229 between the two DRTSP instances can be initially carried in DMIF 230 Signaling with RTSP information wrapped in the DMIF-to-DMIF data 231 field. At a later date when RTSP extensions for DMIF are adopted, 233 DRTSP DMIF DMIF DRTSP 234 Client DRTSP DRTSP Server 235 DAI (Orig) DNI DNI (Dest) DAI 236 I I I I 237 I I I I 238 DA_ServiceAttach I DN_SessionSetup I I 239 -1-------->0-2---------------------------> I 240 (IN:RTSP-URL, I I (IN:nsId, I I 241 uuData) I I calledAddr, I I 242 I I callingAddr, I I 243 I I capDescr) I I 244 I I I I 245 I I (OUT:rsp, I I 246 I I capDescr) I I 247 I <--------------------------3- I 248 I I I I 249 I I DN_ServiceAttach I DA_ServiceAttach 250 I -4------------------------->0-5--------> 251 I I(IN:nsId,serviceId,I (IN:nsId,serviceName, 252 I I serviceName, I uuData) 253 I I ddData) I I 254 (OUT:rsp, I I I I 255 ssId,uuData(IOD)) I (OUT:rsp,ddData) I (OUT:rsp,uuData(IOD)) 256 <-----------8-0<------------------------7-0<-------6- 257 I I I I 259 Figure 4: Command sequence for the establishment of MPEG-4 260 Service Session 262 RTSP signaling could be used instead. Figure 4 avoids this 263 format issue by showing the DMIF-NetworkInterface (DNI) 264 primitives instead. This in turn could be mapped into DMIF 265 signaling or to RTSP DMIF extensions. 267 Step 1 268 The application in the originating DMIF passes DA_ServiceAttach() 269 indicating the DRTSP-URL and additional User-to-User data "uuData()" 270 e.g., indicating client credentials. DMIF parses the DRTSP-URL and 271 instantiates the originating DRTSP module. The "D" in DRTSP 272 indicates that RTSP is complemented with DMIF signaling. 274 Step 2 275 DRTSP strips the from the DRTSP-URL for later use. 276 For the application it assigns a locally significant unique 277 serviceSessionId "ssId". For the network it assigns a globally 278 unique networkSessionId "nsId". It extracts the capabiliyDescriptor 279 "capDescr" which indicates an MPEG-4 service using the DRTSP protocol 280 and contains the identification of the FlexMux [1][6] 281 and any standard protection stacks. 283 Step 3 284 When the destination DRTSP receives the the DN_SessionSetup(), both 285 the originating and destination DRTSP peers have knowledge of the same 286 networkSessionId. The compatibility is verified and the appropriate 287 reply is returned identifying the common set in the preferred order of 288 choice. 290 Step 4 291 The originating DRTSP assigns a serviceId which is unique for the 292 particular networkSessionId and passes the DN_ServiceAttach() to the 293 destination DMIF indicating the serviceName it has previously stripped 294 from the DRTSP-URL, and additional data ddData which contains the uuData 295 provided by the application. 297 Step 5 298 The destination DRTSP when it receives the DN_ServiceAttach(), it 299 determines the Executive process managing the services, assigns a 300 locally unique serviceSessionId and then sends a DA_ServiceAttach() to 301 it containing the serviceSessionId along with the serviceName and the 302 uuData from the receiver application. The mechanism used in the 303 destination DRTSP to identify the process running the service and to 304 deliver the message to it is outside the scope of the DMIF 305 specifcation [4]. 307 Step 6 308 The DRTSP Server interprets the uuData and potentially performs tests 309 on client credentials. Then it replies with uuData (which in the case 310 of MPEG-4 contains the Initial OD) and a response code. 312 The destination DRTSP maintains a table associating the locally 313 meaningful and the network wide meaningful 314 tuple 316 Step 7 317 The destination DRTSP replies to the DN_ServiceAttach() through the 318 DNI, providing a response code and ddData that contains the uuData 319 provided by the Remote Application. 321 Step 8 322 The originating DRTSP uses the locally significant unique 323 serviceSessionId and then replies to the DA_ServiceAttach() with the 324 serviceSessionId, a response code and the uuData originally set by the 325 DRTSP Server. The Local DMIF Layer maintains a table associating the 326 locally meaningful and the network wide meaningful 327 tuple 329 3.2 Establishment of channels 331 This follows MPEG-4 service session establishment shown in section 3.1 332 during which the compatibilty of the transport stacks are ensured and 333 the Initial Object Descriptor (IOD) information is obtained. From the 334 IOD information different MPEG-4 streams can be requested with their 335 associated traffic load and QoS descriptor. For example in order to 336 establish a reliable channel for stream control, reliable two way 337 channels are requested and in order to carry a stream, be it BIFS or OD 338 stream or a content stream, the specific traffic load and QoS are 339 obtained through the ES_Descriptors sent in the IOD file or the OD 340 stream [1]. 342 DRTSP DMIF DMIF DRTSP 343 Client DRTSP DRTSP Server 344 DAI (Orig) DNI DNI (Dest) DAI 345 I I I I 346 I I I I 347 DA_ChannelAdd I DN_ChannelAdd I DA_ChannelAdd 348 -1-------->0-2--------------------------->0-3--------> 349 (IN:ssId, I I (IN:nsId, I (IN:ssId, 350 DRTSP URL, I I serviceId, I DRTSP URL,loop(chId, 351 loop(qos,dir,I I loop(CAT,sAdd, I qos,dir,sAdd,rAdd, 352 uuData( I I rAdd,qos, I uuData( 353 RTSPvx.x, I I ddData) I RTSPvx.x, 354 Cseq))) I I I Cseq))) 355 I I I I 356 (OUT:ssId, I I I (OUT:ssId, 357 loop(chId,rspI I I loop(rsp, 358 uuData( I I I uuData( 359 RTSPvx.x, I I I RTSPvx.x, 360 SC,Cseq, I I (OUT: loop( I SC,Cseq, 361 Date, Ssn))) I I rsp,ddData)) I Date, Ssn))) 362 <-----------6-0<--------------------------5-0<--------4- 363 I I I I 364 Figure 5: Command sequence for establishment of channels 365 This function corresponds to the RTSP SETUP with the difference that it 366 is complemented with traffic load and QoS descriptors required for 367 the streams. 369 Step 1 370 The DRTSP Client passes a DA_ChannelAdd() indicating the channels 371 it requires. The primitive contains the DRTSP-URL, the 372 serviceSessionId "ssId" for which the Channels are requested. Each 373 channel is characterized by a QoS parameter, a direction parameter "dir" 374 (DOWNSTREAM in this case) for the stream and by uuData. containing 375 the RTSP SETUP parameters 377 Step 2 378 The originating DRTSP assigns a channelAssociationTag for each 379 requested channel. It then forwards the request to the peer by 380 passing the DN_ChannelAdd() through the DNI, containing 381 the network-wide unique tuple 382 corresponding to the serviceSessionId, and for each requested 383 channel its CAT, see Annex A1, the (optional) senderAddress "sAdd" 384 extracted from the DRTSP-URL, the (optional) receiverAddress "rAdd", 385 the (optional) qosDescriptor and associated ddData (which conveys 386 the original uuData). 388 Step 3 389 The destination DRTSP receives the DN_ChannelAdd() from the DNI; 390 assigns a locally unique channelHandle "chId" for each requested 391 channel and then issues a DA_ChannelAdd() to the destination 392 Application, containing the locally unique serviceSessionId 393 corresponding to the tuple , and for 394 each requested channel its locally unique channelHandle, the QoS 395 parameter, the direction parameter (DOWNSTREAM in this case), 396 senderAddress , receiverAddress and associated uuData (which conveys 397 the original uuData). At this point the receiver DMIF is able to 398 associate the locally unique channelHandle to the end-to-end 399 significant, networkSession unique CAT. 401 Step 4 402 The DRTSP Server interprets the uuData to determine what stream 403 is actually being requested and checks the availability of such a 404 stream. It then replies with a response code for each requested channel, 405 along with uuData containing the RTSP SETUP return parameters. 407 Step 5 408 The destination DRTSP replies to the original DN_ChannelAdd() providing 409 for each channel TAT see Annex A1, and further ddData that characterize 410 it, along with a response code. In particular ddData would contain in 411 this case further information on how a particular channel is 412 flexmultiplexed in the TAT, that is in the case of MPEG-4 FlexMux, it 413 provides the FlexMux Channel Number. At this point the destination DRTSP 414 is able to associate the CAT to networkSessionId, serviceId, TAT and 415 further flexmultiplexing configuration. ddData may also contain uuData 416 returned by the sender application. 418 Step 6 419 The originating DRTSP receives the reply to the DN_ChannelAdd(), 420 assigns a locally unique channelHandle "chId" for each requested 421 channel, and replies to the original DA_ChannelAdd() by providing for 422 each requested channel its channelHandle, uuData and a response code. At 423 this point the originating DRTSP is able to associate the locally unique 424 channelHandle to the end-to-end significant, networkSession unique CAT 425 and to associate the CAT to networkSessionId, serviceId, TAT and further 426 flexmultiplexing configuration. 428 3.3 Controlling of MPEG-4 Streams 430 The control of streams is carried out over reliable channels established 431 to transport the RTSP Play and pause commands extended for MPEG-4. This 432 function is carried out in the MPEG-4 Systems Sync Layer [1] and is 433 outside the scope of this memorandum. 435 3.4 Deletion of channels 437 Application may request through DAI the deletion of channels for streams 438 that are no longer required. This function corresponds to RTSP TEARDOWN 439 with the difference that the deletion of all channels through DAI does 440 not by itself result in the termination of the MPEG-4 service session. 441 For this to happen the session detachment is required as shown in 442 section 3.5 444 DRTSP DMIF DMIF DRTSP 445 Client DRTSP DRTSP Server 446 DAI (Orig) DNI DNI (Dest) DAI 447 I I I I 448 I I I I 449 DA_ChannelDelete I DN_ChannelDelete I DA_ChannelDelete 450 -1-------->0-2--------------------------->0-3--------> 451 (IN: loop( I I (IN:nsId, I (IN:ssId, 452 chId,reason I I loop(CAT,reason,I chId,reason 453 uuData( I I ddData) I uuData( 454 RTSPvx.x, I I I RTSPvx.x, 455 Cseq,Ssn))) I I I Cseq,Ssn))) 456 I I I I 457 I I I I 458 I I I I 459 (OUT: I I I (OUT: 460 loop(rsp, I I I loop(rsp, 461 uuData( I I I uuData( 462 RTSPvx.x, I I (OUT: loop( I RTSPvx.x, 463 SC,Cseq))) I I rsp,ddData)) I SC,Cseq))) 464 <----------6--0<-------------------------5--0<--------4- 465 I I I I 466 Figure 6: Command sequence for the deletion of channels 467 Step 1 468 The DRTSP Client passes a DA_ChannelDelete() indicating the 469 channels it wants to delete. The primitive contains the 470 channelHandle(s) along with reason codes. 472 Step 2 473 The originating DRTSP stops the actual delivery of data on the 474 indicated Channel(s). The Local DMIF Layer forwards the request 475 to the peer by passing the DN_ChannelDelete() containing the 476 network-wide unique networkSessionId, and for each requested 477 channel its CAT and the reason code. 479 Step 3 480 The destination DRTSP receives the DN_ChannelDelete() and issues 481 a DA_ChannelDelete() to the DRTSP Server, containing for each requested 482 channel its locally unique channelHandle and the reason code. 484 Step 4 485 The DRTSP Server stops the actual delivery of data on 486 the indicated Channel(s), and replies with response codes. At 487 this point channelHandle(s) are invalidated at the DRTSP 488 Server. 490 Step 5 491 The destination DRTSP replies to the original DN_ChannelDelete() 492 providing for each channel a response code. At this point 493 channelHandle(s) and CAT(s) are invalidated at the destination 494 DRTSP. 496 Step 6 497 The destination DRTSP replies to the original DA_ChannelDelete() 498 by providing for each channel a response code. At this point 499 channelHandle(s) and CAT(s) are invalidated at the originating DRTSP. 500 The DRTSP Client receives the reply and invalidates the 501 channelHandle(s). 503 3.5 Detaching the MPEG-4 Service Session 505 Following the steps for the release of channels the end-user may 506 decide to detach the MPEG-4 service session. The sequence of steps 507 shown in Figure 7 below are followed in order to release the MPEG-4 508 service session. 510 DRTSP DMIF DMIF DRTSP 511 Client DRTSP DRTSP Server 512 DAI (Orig) DNI DNI (Dest) DAI 513 I I I I 514 I I I I 515 DA_ServiceDetach I DN_ServiceDetach I DA_ServiceDetach 516 -1-------->0-2--------------------------->0-3--------> 517 (IN:ssId, I I(IN:nsId,serviceId,I (IN:ssId, 518 reason) I I reason) I reason) 519 I I I I 520 I I I I 521 (OUT:rsp) I I (OUT:rsp) I (OUT:rsp) 522 <-----------6-0<-----------------------5--0<-------4- 523 I I I I 525 Figure 7: Command sequence for detaching the MPEG-4 526 Service Session 528 Step 1 529 The DRTSP Client passes a DA_ServiceDetach() indicating 530 the service it wants to terminate. The primitive 531 contains the serviceSessionId along with a reason code. 533 Step 2 534 The originating DRTSP Layer passes a DN_ServiceDetach() indicating the 535 service it wants to terminate (which is now identified by the tuple 536 along with a reason code. 538 Step 3 539 The destination DRTSP receives the DN_ServiceDetach() and passes a 540 DA_ServiceDetach() to the DRTSP Server indicating the service that 541 must be terminated (which is now identified by the locally meaningful 542 serviceSessionId) along with a reason code. 544 Step 4 545 The DRTSP Server stops the provision of the service, and 546 frees all resources used for it. It then replies to the 547 DA_ServiceDetach() providing a response code. At this point 548 the locally meaningful serviceSessionId is no longer valid. 550 Step 5 551 The destination DRTSP replies to the DN_ServiceDetach() along with the 552 response code. At this point the network session unique serviceId is no 553 longer valid. 555 Step 6 556 The originating DRTSP replies to the DA_ServiceDetach() along with 557 the response code. At this point the locally meaningful 558 serviceSessionId is no longer valid. 560 4 Open Issues 562 This section contains the issues that require resolution in this 563 memorandum. 565 1- This draft technical proposal has only included SETUP and 566 TEARDOWN functions. Do these represent a sufficient set for 567 initial session implementations notwithstanding commands 568 such as Play/Pause etc.? 570 2- What impact is foreseen from the separation of the RTSP 571 session/connection control commands from the stream control 572 commands? 574 3- Have the RTSP SETUP and TEARDOWN been properly represented in 575 this draft technical proposal? 576 . 577 4- Is there an equivalent for establishing MPEG-4 Service Session 578 in RTSP? What is it? 580 5- Does RTSP plan to add traffic load and QoS descriptors for the 581 streams in a generic fashion expressed through parameters? 583 A DMIF Definitions and Symbols 585 A.1 Definition(s) 587 Association Tag: In the context of this specification an Association 588 Tag is used to identify elements within a network session with unique 589 end-to-end significant values. 591 Channel: Is the entity over which a DMIF User sends or receives data. 593 DMIF-Application Interface: Is the interface between an application 594 (DMIF User) and the DMIF Layer. 596 DMIF Instance: Is a component in the DMIF layer which deals with a 597 specific delivery technology. It ensures interoperability between DMIF 598 terminals situated on this delivery technology. 600 DMIF-Network Interface: Is the logical interface at which the DMIF 601 Signalling primitives are identified and mapped into various Signalling 602 messages used on Networks. 604 DMIF Terminal: Is a terminal where a DMIF Layer is present 606 DMIF Layer: Is the layer between an Application and the delivery 607 technology that provides the DMIF functions. 609 DMIF User: Is the applications that exploits the functions offered by 610 the DMIF Layer through the DAI. 612 Heterogeneous Network: A Network composed of different transport 613 technologies which are connected in tandem through InterWorking Units. 615 Homogeneous Network: A Network composed of one transport technology 616 only. 618 Network Session: An association between two DMIF peers providing the 619 capability to group together the resources needed for an instance of a 620 service. The Network Session is identified by a network-wide unique ID. 621 A Network Session could group one or more Service Sessions. 623 Service: Is an entity identified by a Service Name (opaque to DMIF) 624 which responds to DAI primitives 626 Service Session: A local association between the local DMIF Layer and a 627 particular service. 629 A.2 Symbols (and abbreviations) 631 CAT: Channel Association Tag 633 DAI: DMIF-Application Interface 635 DS: DMIF Signalling 637 DNI: DMIF-Network Interface 639 QoS: Quality of Service 641 TAT: Transmux Association Tag 643 B Authors' Addresses 645 Vahe Balabanian 646 Nortel 647 P.O.Box 3511, St. C 648 Ottawa, Ontario 649 Canada K1Y 4H7 650 Phone: (613) 763-4721 651 Email: balabani@nortel.ca 653 C Bibliography 655 [1] ISO/IEC 14496-1 FCD "MPEG-4 Systems" Oct 1998, obtained from 656 the MPEG Home Page http://drogo.cselt.it/mpeg/ 658 [2] ISO/IEC 14496-2 FCD "MPEG-4 Visual" Oct 1998, obtained from 659 the MPEG Home Page http://drogo.cselt.it/mpeg/ 661 [3] ISO/IEC 14496-3 FCD "MPEG-4 Audio" Oct 1998, obtained from 662 the MPEG Home Page http://drogo.cselt.it/mpeg/ 664 [4] ISO/IEC 14496-6 CD "DMIF" Oct 1998, obtained from 665 the MPEG Home Page http://drogo.cselt.it/mpeg/ 667 [5] Schulzrinne, Lanphier 'Real Time Streaming Protocol 668 (RTSP)' RFC 2326, Internet Engineering 669 Task Force, April 1998. 671 [6] Carsten, Balabanian, Basso, Civanlar, hoffman, Speer, 672 Schulzrinne, 'RTP payload format for MPEG-4 Elementary 673 Streams' ietf-avt-rtp-mpeg4-00, 674 Internet Engineering Task Force, March 1998. 676 [7] Balabanian, " The Role of DMIF in Support of RTP MPEG-4 677 Payloads", draft-balabanian-rtp-mpeg4-dmif-00, Sptember 1998. 679 [8] Balabanian, ' The Use of MPEG-4/DMIF and RSVP with 680 Integrated Services' draft-balabanian-intserv-mpeg-dmif-00.txt, 681 Internet Engineering Task Force, Sptember 1998. 683 Internet Engineering Task Force Audio/Video Transport Working Group 684 Sept. 22,1998 685 Expires: March 26,1999