Internet Engineering Task Force Audio/Video Transport Working Group INTERNET DRAFT Balabanian-Nortel draft-balabanian-rtsp-mpeg4-dmif-00.txt Sept. 22,1998 Expires: March 26,1999 The Role of DMIF with RTSP and MPEG-4 STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. ABSTRACT This draft technical proposal describes how MPEG DMIF (Delivery Multimedia Integration Framework) can be used with RTSP for setting MPEG-4 service sessions and subsequently detaching the service. DMIF creates an instance of DMIF RTSP augmented with QoS appropriate for each MPEG-4 stream and also makes use of the FlexMux to carry multiple streams on a single UDP or TCP IP flow. The stream control play/pause etc. using RTSP is executed directly by the MPEG-4 Systems Sync Layer. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. 1 Introduction MPEG-4 is a recent standard from ISO/IEC for the coding of natural and synthetic audio-visual data in the form of audiovisual objects that are arranged into an audiovisual scene by means of a scene description [1] [2][3][4]. This draft proposal specifies how DMIF is used with RTSP [5] and RTP MPEG-4 payloads over Internet[6][7][8]. This draft proposal provides a solution for discussion in IETF MMUSIC and ISO/IEC MPEG technical communities in order to identify issues in using MPEG-4/DMIF with RTSP and will incorporate the results in the MPEG-4specifications and issue this proposal as an RFC draft. Balabanian [Page 1]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 The MPEG-4 standards are versioned. Each version beyond V1 represents a backward compatible extension. MPEG-4 V1 is targeted to become ISO International Standard on December 1998 and each subsequent version will be displaced approximately by a year. MPEG-4 V2 is targeted for February 2000. DMIF is part 6 of the MPEG-4 standard. This technical proposal will impact on MPEG V2 International Standard targeted for February 2000. The content of this draft technical proposal is intentionally kept at a tutorial level in order to facilitate the discussion among the interested participants. 1.1 Overview of MPEG-4 End-System Architecture Figure 1 below shows the general architecture of MPEG-4 terminals. The Compression Layer processes individual audio-visual media streams without regard to delivery technologies. The compression schemes in MPEG-4 achieve efficient encoding over a wide range from few Kbps to multiple Mbps. The MPEG-4 compression schemes are defined in the ISO/IEC specifications 14496-2 and -3 [2][3]. The media content at this layer is organized in Elementary Streams. The MPEG-4 Systems specification, ISO/IEC 14496-1 [1], defines the concepts needed to describe the relations between Elementary Streams in a way that allows the creation of distributed, yet integrated, content presentations and to synchronize the streams. This part of the specification is both media unaware and delivery technology unaware. The Delivery Layer in MPEG-4 consists of the Delivery Multimedia Integration Framework defined in ISO/IEC 14496-6 [4]. This layer is media unaware but delivery technology aware. It provides transparent access to and delivery of content irrespective of the technologies used. The interface between the Sync Layer and DMIF is called DMIF Application Interface (DAI). It offers content location independent procedures for establishing MPEG-4 sessions and access to transport channels. DMIF is primarily an integration framework. It provides a default DMIF signaling (DS) protocol which corresponding to DMIF Network Interface (DNI), see Figure 2. DS is used to complement the lack functionality in underlying control protocols in order to keep the integrity of the DMIF framework. Balabanian [Page 2]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 media aware +-----------------------------------------+ delivery unaware | COMPRESSION LAYER | 14496-2 Visual |streams from as low as Kbps to multi-Mbps| 14496-3 Audio +-----------------------------------------+ Elementary Stream =============================================================Interface (ESI) +-------------------------------------------+ media and | SYSTEMS SYNC LAYER | delivery unaware | manages elementary streams, their synch- | 14496-1 Systems | ronization and hierarchical relations | +-------------------------------------------+ DMIF Application ==============================================================Interface (DAI) +-------------------------------------------+ delivery aware | DELIVERY LAYER | media unaware |provides transparent access to and delivery| 14496-6 DMIF | of content irrespective of delivery | | technology | +-------------------------------------------+ Figure 1: General MPEG-4 terminal architecture 1.2 The DMIF Model DMIF as an integration framework uses a uniform procedure at the DAI interface to access the MPEG-4 content irrespective whether the content is broadcast, stored on a local file or obtained through interaction with a remote end-system. The model is shown in Figure 2 below. The specific instance of interest in this memorandum is the interaction with a remote end-system. For this case DMIF uses internal (informative) DMIF-Network Interface(DNI)to map the controls obtained from the application through DAI into the various signaling appropriate to the various networks. The default end-to-end DMIF signaling (DS) protocol which corresponds to DNI is specified in DMIF V1 [4]. Balabanian [Page 3]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 ! +---+ +-----------+ +-----------+ +-----------+ ! | | |Local DMIF | |Remote DMIF| |Remote App.| +-----+ ! | D | |for Brd'cst| |(locally | |(locally | Brd'cst | | ! | M | | | | emulated) | | emulated) |<-----source |Local| ! | I | +-----------+ +-----------+ +-----------+ | | ! | F | +-----------+ +-----------+ +-----------+ |App | ! | | |Local DMIF | |Remote DMIF| |Remote App.| File | | ! | F | |for Local | |(locally | |(locally |<-----source | | ! | i | | Files | | emulated) | | emulated) | | | ! | l | +-----------+ +-----------+ +-----------+ | | ! | t | +-----------+ ! +---+ / ---- \ | | ! | e | |Local DMIF | ! |Sig| | --- ---- | +-----+ ! | r | |for Remote | ! |map|<->( Network ) |Outside the ! | | | Service | ! | | | ---- ----- |scope of DMIF ! +---+ +-----------+ ! +---+ | ----- | DAI DNI | ^ | \_____|_________/ | | | +---+!+------+!+------+ | |Sig|!|Remote|!|Remote| +>|map|!| DMIF |!| App. | | |!|(real)|!|(real)| +---+!+------+!+------+ DNI DAI Figure 2: The DMIF model covers broadcast, local file storage and remote service with a uniform procedure for application transparency Balabanian [Page 4]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 2 Placing RTSP within the MPEG-4 architecture In order to make use of the functions enabled by RTSP, DMIF RTSP Client and Server modules are created as shown in Figure 3 below. These modules interface with DAI and interwork with the MPEG-4 Sync Layer. It is an internal implementation decision not affecting interoperability whether to combine the DRTSP client and server functions with the Sync Layer or keep them separate. It is noted that DAI allows the establishment of an MPEG-4 service session e.g., RTSP Video on Demand session, the request of channels to carry MPEG-4 Elementary Streams for that service are executed by the DMIF-RTSP (DRTSP) module instantiated by DMIF as a response to the DRTSP-URL in the MPEG-4 service session request. This module as described here only carries out RTSP SETUP and TEARDOWN functions while the stream control functions are carried out through the interactions of the DRTSP servers with the Sync layer. The signaling between the two instances of the DRTSP at the originating and destination DMIFs can initially use the default DMIF signaling and wrap the RTSP related fields in a DMIF-to-DMIF Data fields. Later versions may extend the RTSP to include the DMIF functionality, in that case the proper RTSP signaling will be used. Backward compatibility is assured by the way of a common set of DMIF Network Interface (DNI) primitives, see Figure 2 which are used to generate the DMIF signaling messages or their RTSP extensions. DAI DAI +-----+ I I +-----+ / DRTSP \ I+-----+ DMIF Signaling +-----+I / DRTSP \ | Client |<--->|Orig.|<-------------->|Dest.|<--->| Server | \ / I|DRTSP| |DRTSP|I \ / +-----+ I+-----+ +-----+I +-----+ ^ I I ^ | I I | | I I | v I I v +-----------+I I +-----------+ | MPEG-4 |I I | MPEG-4 | |Systems |<==============================> |Systems | |Sync Layer |I I |Sync Layer | +-----------+I I +-----------+ Figure 3: RTSP within the MPEG-4 architecture Balabanian [Page 5]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 3 DMIF RTSP Message Sequences 3.1 Setting up MPEG-4 RTSP service session MPEG-4 is an object based encoding with Scenes described in Binary Information Formatted Streams (BIFS)and objects placed within a scene described with Object Descriptor (OD) streams [1]. In order to be able to begin viewing MPEG-4, both the BIFS and the OD decoders must be set for parsing at the receiver end in order to be able to decode the BIFS and OD streams[1]. This information is obtained from the Initial Object Descriptor (IOD)file. The location of IOD can be expressed in a DRTSP-URL which can be obtained by any means. The DRTSP URL indicates that the MPEG-4 play control functions use the RTSP controls as defined in RFC 2326 [5]. As a result of this action DMIF instantiates DRTSP instances at both the originating and destination DMIF locations and engages the DRTSP client with the DRTSP server. The signaling between the two DRTSP instances can be initially carried in DMIF Signaling with RTSP information wrapped in the DMIF-to-DMIF data field. At a later date when RTSP extensions for DMIF are adopted, DRTSP DMIF DMIF DRTSP Client DRTSP DRTSP Server DAI (Orig) DNI DNI (Dest) DAI I I I I I I I I DA_ServiceAttach I DN_SessionSetup I I -1-------->0-2---------------------------> I (IN:RTSP-URL, I I (IN:nsId, I I uuData) I I calledAddr, I I I I callingAddr, I I I I capDescr) I I I I I I I I (OUT:rsp, I I I I capDescr) I I I <--------------------------3- I I I I I I I DN_ServiceAttach I DA_ServiceAttach I -4------------------------->0-5--------> I I(IN:nsId,serviceId,I (IN:nsId,serviceName, I I serviceName, I uuData) I I ddData) I I (OUT:rsp, I I I I ssId,uuData(IOD)) I (OUT:rsp,ddData) I (OUT:rsp,uuData(IOD)) <-----------8-0<------------------------7-0<-------6- I I I I Figure 4: Command sequence for the establishment of MPEG-4 Service Session Balabanian [Page 6]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 RTSP signaling could be used instead. Figure 4 avoids this format issue by showing the DMIF-NetworkInterface (DNI) primitives instead. This in turn could be mapped into DMIF signaling or to RTSP DMIF extensions. Step 1 The application in the originating DMIF passes DA_ServiceAttach() indicating the DRTSP-URL and additional User-to-User data "uuData()" e.g., indicating client credentials. DMIF parses the DRTSP-URL and instantiates the originating DRTSP module. The "D" in DRTSP indicates that RTSP is complemented with DMIF signaling. Step 2 DRTSP strips the <serviceName> from the DRTSP-URL for later use. For the application it assigns a locally significant unique serviceSessionId "ssId". For the network it assigns a globally unique networkSessionId "nsId". It extracts the capabiliyDescriptor "capDescr" which indicates an MPEG-4 service using the DRTSP protocol and contains the identification of the FlexMux [1][6] and any standard protection stacks. Step 3 When the destination DRTSP receives the the DN_SessionSetup(), both the originating and destination DRTSP peers have knowledge of the same networkSessionId. The compatibility is verified and the appropriate reply is returned identifying the common set in the preferred order of choice. Step 4 The originating DRTSP assigns a serviceId which is unique for the particular networkSessionId and passes the DN_ServiceAttach() to the destination DMIF indicating the serviceName it has previously stripped from the DRTSP-URL, and additional data ddData which contains the uuData provided by the application. Step 5 The destination DRTSP when it receives the DN_ServiceAttach(), it determines the Executive process managing the services, assigns a locally unique serviceSessionId and then sends a DA_ServiceAttach() to it containing the serviceSessionId along with the serviceName and the uuData from the receiver application. The mechanism used in the destination DRTSP to identify the process running the service and to deliver the message to it is outside the scope of the DMIF specifcation [4]. Step 6 The DRTSP Server interprets the uuData and potentially performs tests on client credentials. Then it replies with uuData (which in the case of MPEG-4 contains the Initial OD) and a response code. The destination DRTSP maintains a table associating the locally Balabanian [Page 7]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 meaningful <serviceSessionId> and the network wide meaningful tuple <networkSessionId, serviceId> Step 7 The destination DRTSP replies to the DN_ServiceAttach() through the DNI, providing a response code and ddData that contains the uuData provided by the Remote Application. Step 8 The originating DRTSP uses the locally significant unique serviceSessionId and then replies to the DA_ServiceAttach() with the serviceSessionId, a response code and the uuData originally set by the DRTSP Server. The Local DMIF Layer maintains a table associating the locally meaningful <serviceSessionId> and the network wide meaningful tuple <networkSessionId, serviceId> 3.2 Establishment of channels This follows MPEG-4 service session establishment shown in section 3.1 during which the compatibilty of the transport stacks are ensured and the Initial Object Descriptor (IOD) information is obtained. From the IOD information different MPEG-4 streams can be requested with their associated traffic load and QoS descriptor. For example in order to establish a reliable channel for stream control, reliable two way channels are requested and in order to carry a stream, be it BIFS or OD stream or a content stream, the specific traffic load and QoS are obtained through the ES_Descriptors sent in the IOD file or the OD stream [1]. DRTSP DMIF DMIF DRTSP Client DRTSP DRTSP Server DAI (Orig) DNI DNI (Dest) DAI I I I I I I I I DA_ChannelAdd I DN_ChannelAdd I DA_ChannelAdd -1-------->0-2--------------------------->0-3--------> (IN:ssId, I I (IN:nsId, I (IN:ssId, DRTSP URL, I I serviceId, I DRTSP URL,loop(chId, loop(qos,dir,I I loop(CAT,sAdd, I qos,dir,sAdd,rAdd, uuData( I I rAdd,qos, I uuData( RTSPvx.x, I I ddData) I RTSPvx.x, Cseq))) I I I Cseq))) I I I I (OUT:ssId, I I I (OUT:ssId, loop(chId,rspI I I loop(rsp, uuData( I I I uuData( RTSPvx.x, I I I RTSPvx.x, SC,Cseq, I I (OUT: loop( I SC,Cseq, Date, Ssn))) I I rsp,ddData)) I Date, Ssn))) <-----------6-0<--------------------------5-0<--------4- I I I I Figure 5: Command sequence for establishment of channels Balabanian [Page 8]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 This function corresponds to the RTSP SETUP with the difference that it is complemented with traffic load and QoS descriptors required for the streams. Step 1 The DRTSP Client passes a DA_ChannelAdd() indicating the channels it requires. The primitive contains the DRTSP-URL, the serviceSessionId "ssId" for which the Channels are requested. Each channel is characterized by a QoS parameter, a direction parameter "dir" (DOWNSTREAM in this case) for the stream and by uuData. containing the RTSP SETUP parameters Step 2 The originating DRTSP assigns a channelAssociationTag for each requested channel. It then forwards the request to the peer by passing the DN_ChannelAdd() through the DNI, containing the network-wide unique tuple <networkSessionId, serviceId> corresponding to the serviceSessionId, and for each requested channel its CAT, see Annex A1, the (optional) senderAddress "sAdd" extracted from the DRTSP-URL, the (optional) receiverAddress "rAdd", the (optional) qosDescriptor and associated ddData (which conveys the original uuData). Step 3 The destination DRTSP receives the DN_ChannelAdd() from the DNI; assigns a locally unique channelHandle "chId" for each requested channel and then issues a DA_ChannelAdd() to the destination Application, containing the locally unique serviceSessionId corresponding to the tuple <networkSessionId, serviceId>, and for each requested channel its locally unique channelHandle, the QoS parameter, the direction parameter (DOWNSTREAM in this case), senderAddress , receiverAddress and associated uuData (which conveys the original uuData). At this point the receiver DMIF is able to associate the locally unique channelHandle to the end-to-end significant, networkSession unique CAT. Step 4 The DRTSP Server interprets the uuData to determine what stream is actually being requested and checks the availability of such a stream. It then replies with a response code for each requested channel, along with uuData containing the RTSP SETUP return parameters. Step 5 The destination DRTSP replies to the original DN_ChannelAdd() providing for each channel TAT see Annex A1, and further ddData that characterize it, along with a response code. In particular ddData would contain in this case further information on how a particular channel is flexmultiplexed in the TAT, that is in the case of MPEG-4 FlexMux, it provides the FlexMux Channel Number. At this point the destination DRTSP is able to associate the CAT to networkSessionId, serviceId, TAT and further flexmultiplexing configuration. ddData may also contain uuData returned by the sender application. Balabanian [Page 9]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 Step 6 The originating DRTSP receives the reply to the DN_ChannelAdd(), assigns a locally unique channelHandle "chId" for each requested channel, and replies to the original DA_ChannelAdd() by providing for each requested channel its channelHandle, uuData and a response code. At this point the originating DRTSP is able to associate the locally unique channelHandle to the end-to-end significant, networkSession unique CAT and to associate the CAT to networkSessionId, serviceId, TAT and further flexmultiplexing configuration. 3.3 Controlling of MPEG-4 Streams The control of streams is carried out over reliable channels established to transport the RTSP Play and pause commands extended for MPEG-4. This function is carried out in the MPEG-4 Systems Sync Layer [1] and is outside the scope of this memorandum. 3.4 Deletion of channels Application may request through DAI the deletion of channels for streams that are no longer required. This function corresponds to RTSP TEARDOWN with the difference that the deletion of all channels through DAI does not by itself result in the termination of the MPEG-4 service session. For this to happen the session detachment is required as shown in section 3.5 DRTSP DMIF DMIF DRTSP Client DRTSP DRTSP Server DAI (Orig) DNI DNI (Dest) DAI I I I I I I I I DA_ChannelDelete I DN_ChannelDelete I DA_ChannelDelete -1-------->0-2--------------------------->0-3--------> (IN: loop( I I (IN:nsId, I (IN:ssId, chId,reason I I loop(CAT,reason,I chId,reason uuData( I I ddData) I uuData( RTSPvx.x, I I I RTSPvx.x, Cseq,Ssn))) I I I Cseq,Ssn))) I I I I I I I I I I I I (OUT: I I I (OUT: loop(rsp, I I I loop(rsp, uuData( I I I uuData( RTSPvx.x, I I (OUT: loop( I RTSPvx.x, SC,Cseq))) I I rsp,ddData)) I SC,Cseq))) <----------6--0<-------------------------5--0<--------4- I I I I Figure 6: Command sequence for the deletion of channels Balabanian [Page 10]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 Step 1 The DRTSP Client passes a DA_ChannelDelete() indicating the channels it wants to delete. The primitive contains the channelHandle(s) along with reason codes. Step 2 The originating DRTSP stops the actual delivery of data on the indicated Channel(s). The Local DMIF Layer forwards the request to the peer by passing the DN_ChannelDelete() containing the network-wide unique networkSessionId, and for each requested channel its CAT and the reason code. Step 3 The destination DRTSP receives the DN_ChannelDelete() and issues a DA_ChannelDelete() to the DRTSP Server, containing for each requested channel its locally unique channelHandle and the reason code. Step 4 The DRTSP Server stops the actual delivery of data on the indicated Channel(s), and replies with response codes. At this point channelHandle(s) are invalidated at the DRTSP Server. Step 5 The destination DRTSP replies to the original DN_ChannelDelete() providing for each channel a response code. At this point channelHandle(s) and CAT(s) are invalidated at the destination DRTSP. Step 6 The destination DRTSP replies to the original DA_ChannelDelete() by providing for each channel a response code. At this point channelHandle(s) and CAT(s) are invalidated at the originating DRTSP. The DRTSP Client receives the reply and invalidates the channelHandle(s). 3.5 Detaching the MPEG-4 Service Session Following the steps for the release of channels the end-user may decide to detach the MPEG-4 service session. The sequence of steps shown in Figure 7 below are followed in order to release the MPEG-4 service session. Balabanian [Page 11]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 DRTSP DMIF DMIF DRTSP Client DRTSP DRTSP Server DAI (Orig) DNI DNI (Dest) DAI I I I I I I I I DA_ServiceDetach I DN_ServiceDetach I DA_ServiceDetach -1-------->0-2--------------------------->0-3--------> (IN:ssId, I I(IN:nsId,serviceId,I (IN:ssId, reason) I I reason) I reason) I I I I I I I I (OUT:rsp) I I (OUT:rsp) I (OUT:rsp) <-----------6-0<-----------------------5--0<-------4- I I I I Figure 7: Command sequence for detaching the MPEG-4 Service Session Step 1 The DRTSP Client passes a DA_ServiceDetach() indicating the service it wants to terminate. The primitive contains the serviceSessionId along with a reason code. Step 2 The originating DRTSP Layer passes a DN_ServiceDetach() indicating the service it wants to terminate (which is now identified by the tuple <networkSessionId "nsId", serviceId> along with a reason code. Step 3 The destination DRTSP receives the DN_ServiceDetach() and passes a DA_ServiceDetach() to the DRTSP Server indicating the service that must be terminated (which is now identified by the locally meaningful serviceSessionId) along with a reason code. Step 4 The DRTSP Server stops the provision of the service, and frees all resources used for it. It then replies to the DA_ServiceDetach() providing a response code. At this point the locally meaningful serviceSessionId is no longer valid. Step 5 The destination DRTSP replies to the DN_ServiceDetach() along with the response code. At this point the network session unique serviceId is no longer valid. Step 6 The originating DRTSP replies to the DA_ServiceDetach() along with the response code. At this point the locally meaningful serviceSessionId is no longer valid. Balabanian [Page 12]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 4 Open Issues This section contains the issues that require resolution in this memorandum. 1- This draft technical proposal has only included SETUP and TEARDOWN functions. Do these represent a sufficient set for initial session implementations notwithstanding commands such as Play/Pause etc.? 2- What impact is foreseen from the separation of the RTSP session/connection control commands from the stream control commands? 3- Have the RTSP SETUP and TEARDOWN been properly represented in this draft technical proposal? . 4- Is there an equivalent for establishing MPEG-4 Service Session in RTSP? What is it? 5- Does RTSP plan to add traffic load and QoS descriptors for the streams in a generic fashion expressed through parameters? A DMIF Definitions and Symbols A.1 Definition(s) Association Tag: In the context of this specification an Association Tag is used to identify elements within a network session with unique end-to-end significant values. Channel: Is the entity over which a DMIF User sends or receives data. DMIF-Application Interface: Is the interface between an application (DMIF User) and the DMIF Layer. DMIF Instance: Is a component in the DMIF layer which deals with a specific delivery technology. It ensures interoperability between DMIF terminals situated on this delivery technology. DMIF-Network Interface: Is the logical interface at which the DMIF Signalling primitives are identified and mapped into various Signalling messages used on Networks. DMIF Terminal: Is a terminal where a DMIF Layer is present DMIF Layer: Is the layer between an Application and the delivery technology that provides the DMIF functions. DMIF User: Is the applications that exploits the functions offered by the DMIF Layer through the DAI. Balabanian [Page 13]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 Heterogeneous Network: A Network composed of different transport technologies which are connected in tandem through InterWorking Units. Homogeneous Network: A Network composed of one transport technology only. Network Session: An association between two DMIF peers providing the capability to group together the resources needed for an instance of a service. The Network Session is identified by a network-wide unique ID. A Network Session could group one or more Service Sessions. Service: Is an entity identified by a Service Name (opaque to DMIF) which responds to DAI primitives Service Session: A local association between the local DMIF Layer and a particular service. A.2 Symbols (and abbreviations) CAT: Channel Association Tag DAI: DMIF-Application Interface DS: DMIF Signalling DNI: DMIF-Network Interface QoS: Quality of Service TAT: Transmux Association Tag B Authors' Addresses Vahe Balabanian Nortel P.O.Box 3511, St. C Ottawa, Ontario Canada K1Y 4H7 Phone: (613) 763-4721 Email: balabani@nortel.ca C Bibliography [1] ISO/IEC 14496-1 FCD "MPEG-4 Systems" Oct 1998, obtained from the MPEG Home Page http://drogo.cselt.it/mpeg/ [2] ISO/IEC 14496-2 FCD "MPEG-4 Visual" Oct 1998, obtained from the MPEG Home Page http://drogo.cselt.it/mpeg/ Balabanian [Page 14]
Internet Draft The Role of DMIF with RTSP and MPEG-4 Sept. 22,1998 [3] ISO/IEC 14496-3 FCD "MPEG-4 Audio" Oct 1998, obtained from the MPEG Home Page http://drogo.cselt.it/mpeg/ [4] ISO/IEC 14496-6 CD "DMIF" Oct 1998, obtained from the MPEG Home Page http://drogo.cselt.it/mpeg/ [5] Schulzrinne, Lanphier 'Real Time Streaming Protocol (RTSP)' RFC 2326, Internet Engineering Task Force, April 1998. [6] Carsten, Balabanian, Basso, Civanlar, hoffman, Speer, Schulzrinne, 'RTP payload format for MPEG-4 Elementary Streams' ietf-avt-rtp-mpeg4-00, Internet Engineering Task Force, March 1998. [7] Balabanian, " The Role of DMIF in Support of RTP MPEG-4 Payloads", draft-balabanian-rtp-mpeg4-dmif-00, Sptember 1998. [8] Balabanian, ' The Use of MPEG-4/DMIF and RSVP with Integrated Services' draft-balabanian-intserv-mpeg-dmif-00.txt, Internet Engineering Task Force, Sptember 1998. Internet Engineering Task Force Audio/Video Transport Working Group INTERNET DRAFT Balabanian-Nortel draft-balabanian-rtsp-mpeg4-dmif-00.txt Sept. 22,1998 Expires: March 26,1999 Balabanian [Page 15]