[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Draft                                                  T.Ahmed
Document: draft-ahmed-dmif-sip-00.txt                         A.Mehaoua
Expires: March 2002                                      PRiSM Lab UVSQ
                                                              R.Boutaba
                                                 University of Waterloo
                                                         September 2001


                 Interworking Between SIP and MPEG-4 DMIF
                        draft-ahmed-dmif-sip-00.txt



Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.


   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 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."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


Abstract

   This draft proposal discusses technical issues related to delivery
   and control of IP multimedia services, such as video-conferencing,
   involving heterogeneous end terminals. In particular, it describes
   the design and implementation of an experimental system for
   interworking between IETF SIP (Session Initiation Protocol) and ISO
   MPEG-4 DMIF (Delivery Multimedia Integration Framework) session and
   call control signaling protocols. This IP videoconferencing
   interworking system is composed of two core units for supporting
   delivery of audio-video streams from a DMIF domain to a SIP domain
   (i.e. DMIF2SIP unit) and from a SIP domain to a DMIF domain (i.e.
   SIP2DMIF unit). These units perform various translation functions
   for transparent establishment and control of multimedia sessions
   across IP networking environment, including, session protocol
   conversion, service gateway conversion and address translation.








Toufik et al.                Expire March 2002                  [Page 1]


Internet Draft            draft-ahmed-dmif-sip-00.txt      September 2001


   Table of Contents

   Status of this Memo................................................1
    .................................................................1
   Abstract...........................................................1
   1 Introduction.....................................................2
   2 Universal IP connectivity........................................3
   3 MPEG-4 DMIF Overview.............................................4
   3.1 DMIF Communication Model.......................................5
   3.2 MIF Layer......................................................5
   3.2.1 DMIF Application Interface...................................6
   3.2.2 DMIF Network Interface.......................................6
   4 SIP (Session Initiation Protocol) Overview.......................7
   4.1 SIP Components.................................................7
   4.2 SIP Communication Model........................................8
   5 Interworking between MPEG-4 DMIF and SIP.........................8
   6 Mapping between SIP addresses and DMIF URL......................14
   7 Security Considerations.........................................15
   8 Conclusion......................................................15
   References........................................................16
   Author's Addresses................................................16

1 Introduction

   Internet video conferencing and IP telephony has grown rapidly in
   the last few years. This rapid expansion and potential underlies the
   importance of an enabling and unifying standard. Actually, it
   appears likely that both IETF SIP (Session Initiation Protocol)[1]
   with SDP (Session Description Protocol) [2] and the ITU-T
   recommendation H.323 [3] will be used for setting up Internet
   multimedia conferences and telephone calls. While the two protocols
   are comparable in their features, SIP provides a higher flexibility
   to add new features; a relatively easier implementation; and a
   better integration with other IP related protocols.

   In the other hand, the recent ISO MPEG-4 standards target a broad
   range of low-bit rates multimedia applications: from classical
   streaming video and TV broadcasting to highly interactive
   applications with dynamic audio-visual scene customisation (e.g. e-
   learning, videoconferencing).  In order to reach this objective,
   advanced coding and formatting tools have been specified in the
   different parts of the standard (i.e. Audio, Visual, and Systems),
   which can be configured according to profiles and levels to meet
   various application requirements. A core component of the MPEG-4
   multimedia framework is the  Delivery Multimedia Integration
   Framework. DMIF [3] offers content location independent procedures
   for establishing and controlling MPEG-4 sessions and access to
   transport channels such as RTP/UDP/IP.







Toufik et al.                Expire March 2002                  [Page 2]


Internet Draft            draft-ahmed-dmif-sip-00.txt      September 2001


2 Universal IP connectivity

   iN order to achieve universal IP connectivity and seamless IP
   multimedia services, interworking between MPEG-4 and SIP terminals
   is required.

   Several points of heterogeneity should be addressed for permitting
   IP multimedia Interworking Service:

   1. Video and audio formats: digital audio formats will be
     characterized by many factors such as sampling rates or
     compression algorithms. Video formats may differ in spatial and
     temporal resolutions, color depth or compression schemes. This
     format adaptation issue is addressed by multimedia gateways.

   2. Synchronizing and system encoding: each elementary (video, audio,
     data) stream should be merged to form a single bit-stream for
     transmission, and they should be synchronized. In Internet, the
     Real-time Transport Protocol provides temporal and encapsulation
     functions.

   3. Application control: users should be able to control the received
     stream to simulate interactive VCR-like function(e.g. play, pause,
     fast rewinding, ). IETF Real-Time Streaming Protocol (RTSP),
     DAVIC-S3 and ISO MPEG DSM-CC are examples of signaling protocols
     developed for that purpose and require interoperability.

   4. Connection control/QoS control: in next generation Internet, QoS
     could be negotiated by way of different signaling (e.eg. RSVP,
     MPLS LDP,), while some domains will not provide any QoS guarantee
     and still perform in best effort. Thus, there should be a function
     that translates QoS requests to other.

   5. Call/session control: different IP network domains may adopt
     different method for reserving resources and maintaining session
     information. There should be a way of managing two independent
     sessions to form a composite session (e.g. a SIP compliant phone
     call and an MPEG-4 DMIF compliant video call).

   This drat addresses the later point of service heterogeneity (i.e.
   call and session control). It describes the design and
   implementation of an experimental system for IP videoconferencing
   interworking between ISO MPEG-4 DMIF and IETF SIP signaling
   protocols. This interworking system is composed of two core units
   for supporting delivery of audio-video streams from a DMIF domain to
   a SIP domain (i.e. DMIF2SIP unit), and from a SIP domain to a DMIF
   domain (i.e. SIP2DMIF unit). These two components perform various
   translation functions for transparent establishment and control of
   multimedia conferencing sessions across IP networking environment.
   Including, session protocol conversion, service gateway conversion,
   and address translation.




Toufik et al.                Expire March 2002                  [Page 3]


Internet Draft            draft-ahmed-dmif-sip-00.txt      September 2001


3 MPEG-4 DMIF Overview

   MPEG-4 DMIF is control plane of MPEG-4 Delivery layer, which allows
   applications to transparently access and view multimedia streams
   whether the source of the stream is located on an interactive remote
   end-system, the stream is available on broadcast media or is located
   on stored media [3].


   media aware        +-----------------------------------------+
   delivery unaware   |           COMPRESSION LAYER             |
   14496-2 Visual     |   streams from few 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

   The generic MPEG-4 terminal architecture is composed of three basic
   Layers (Figure 1): Compression Layer, Sync Layer and Delivery Layer.

   The Compression Layer does MPEG-4 media encoding and decoding into
   Elementary Streams, the Sync Layer manages Elementary Streams and
   their synchronization. Delivery Layer is a term used to refer to a
   transport network technology (e.g. Internet or ATM), as well as to a
   broadcast technology or local storage technology.
   The boundary between the Compression Layer and the Sync Layer is
   named Elementary Stream Interface (ESI).
   The delivery layer is media unaware but delivery technology aware.
   It provides transparent access to the delivery of content
   irrespective of the technologies used  (IP, ATM...). The boundary
   between the Sync Layer and the Delivery Layer is named DMIF
   Application Interface (DAI). It offers content location independent
   procedures for establishing MPEG-4 sessions and access to transport



Toufik et al.                Expire March 2002                  [Page 4]


Internet Draft            draft-ahmed-dmif-sip-00.txt      September 2001


   channels. Also it provides default DMIF signaling protocol which
   corresponding to DMIF network Interface (DNI).

3.1  DMIF Communication Model

   DMIF framework covers three major technologies: interactive network
   technology, broadcast technology and the disk technology. An
   application accesses data through the DAI irrespectively whether
   such data comes from a broadcast source, from local storage or from
   remote server. In all scenarios the Local Application only interacts
   through DAI primitives. The Figure 2 clarifies the DMIF aim.



           ! +---+ +-----------+  +-----------+  +-----------+
           ! |   | |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 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

3.2  MIF Layer

   DMIF allows each delivery technology to be used for its unique
   characteristics in a way transparent to application developers.
   Figure 3 shows the composition of DMIF stack in the case of IP
   network.






Toufik et al.                Expire March 2002                  [Page 5]


Internet Draft            draft-ahmed-dmif-sip-00.txt      September 2001


                          +--------------------+
                          | MPEG-4 Application |
                          +--------------------+
                          |   DAI Primitives   |    DMIF
                          +--------------------+    Layer
                          |   DNI Primitives   |
                          +--------------------+
                          |      TCP/UDP       |
                          +--------------------+
                          |        IP          |
                          +--------------------+

   Figure 3: DMIF Stack Protocol for IP Network

   DMIF contains functionality needed to establish sessions and
   connections between an application running at server side and an
   application running at client side over transport networks.
   In general, DMIF provides this functionality:
   It assigns a value (network session Identifier) to one session. This
   identifier encodes a unique session instance for network application
   and for the management of real time, QoS sensitive streams.

   - It allows interoperation between the client and the server.
   - It hides the delivery technology details from the DMIF User
   - It ensures interoperability between end-systems (in the control
     plane)

3.2.1   DMIF Application Interface

   The DMIF application Interface (DAI) allows the development of
   applications to support delivery technologies, regardless of network
   topology.
   The DAI defines the functions offered by the DMIF layer, and
   comprised the following classes of primitives:

   - Service primitives, which deal with the Control Plane, and allow
     the management of service session (attach and detach).
   - Channel primitives, which deal with the control Plane, and allow
     the management of channels (add and delete).
   - Data primitives, which deal with the User Plane, and serve the
     purpose of transferring data through channels.

3.2.2   DMIF Network Interface

   The DMIF Network Interface abstracts the signaling between DMIF
   peers irrespectively of the supported delivery technologies. The
   parameters conveyed through the DNI are then normatively mapped onto
   network dependent native signaling when possible otherwise they are
   carried opaque to the native signaling.
   The DMIF Network Interface comprises the following of classes of
   primitives:




Toufik et al.                Expire March 2002                  [Page 6]


Internet Draft            draft-ahmed-dmif-sip-00.txt      September 2001



   - Session primitives, which allow the management of sessions (setup
     and release)
   - Service primitives, which allow the management of services (attach
     and detach)
   - Transmux primitives, which allow the management of a transmux
     (setup, release and config)
   - Channel primitives, which allow the management of channels (add
     and delete)

4  SIP (Session Initiation Protocol) Overview

   The Session Initiation Protocol (SIP) is an application-layer
   control and signaling protocol for creating, modifying and
   terminating sessions with one or more participants. These sessions
   include Internet multimedia conferences, Internet telephone calls
   and multimedia distribution[1]. SIP has been approval in early 1999
   as an official standard by the IETF for signaling communications
   services on the Internet.

   SIP can be used to initiate sessions as well as invite members to
   sessions. The SIP architecture includes:

   - Real-Time Transport Protocol (RTP) for transporting real time
     audio, video and data.
   - Real-Time Streaming Protocol (RTSP) for setting up and controlling
     on-demand media streams,
   - Media Gateway Control Protocol  (MGCP) and Megaco for controlling
     media gateways,
   - Session Description Protocol (SDP) for describing multimedia
     sessions,
   - Session Announcement Protocol (SAP) for announcing multicast
     session,
   - Telephony Routing over IP (TRIP) for locating the best gateway
     between the Internet and the Public Switched Telephone Network
     (PSTP),
   - Suite of resources management and multicast address allocation
     protocols.

4.1 SIP Components

   SIP is composed essentially of four entities: user agent, registrar,
   proxy server and redirect server.

   - User agent client (UAC): caller application that initiates and
     sends SIP requests.
   - User agent server (UAS): receives and responds to SIP requests on
     behalf of clients; accepts, redirects or refuses calls.
   - SIP Terminal: supports real-time, 2-way communication with another
     SIP entity. Supports both signaling and media, similar to H.323
     terminal. It contains UA.
   - Proxy: contacts one or more clients or next-hop servers and passes
     the call requests further. It contains UAC and UAS.


Toufik et al.                Expire March 2002                  [Page 7]


Internet Draft            draft-ahmed-dmif-sip-00.txt      September 2001


   - Redirect Server: accepts SIP requests, maps the address into zero
     or more new addresses and returns those addresses to the client.
     Location Server: provides information about a caller's possible
     locations to redirect and proxy servers. May be co-located with a
     SIP server.

4.2 SIP Communication Model

   SIP is based on the request-response paradigm. To initiate a
   session, the UAC sends a request (called an INVITE) addressed to the
   person the caller want to talk to. The addresses are similar to
   mailto URL (sip:user@server). The message is no send directly to the
   called party but rather to the proxy. Then, the proxy delivers the
   message to the called party. The called party sends a response,
   accepting or rejecting the invitation, which is forwarded back to
   the caller in reverse order like undelivered mail in Internet.
   Bellow is an example of SIP scenario:

   1. User A (a@caller.com) calls user B (b@example.com). A send INVITE
      message to the proxy of example.com (INVITE sip: b@example.com),
      then the proxy of example.com tell A, that it is trying to
      connect to b@example.com.

   2. The proxy locates in which PC the user B is logged currently.
      This task is performed by a REGITER message send by B when he
      turned on his SIP user agent client. This would allow that B is
      actually at foo.example.com (sip: b@foo.example.com). The
      bindings registered are periodically refreshed.

   3. The proxy send INVITE message to UAC of B (INVITE
      sip:b@foo.example.com), this later replay the proxy with  ringing
      informational message. The proxy inform the caller that is
      ringing at B.

   4. When B accept the invitation an acknowledgement message (ACK) is
      sent, and the session is established, Media can then flow between
      A and B.

5  Interworking between MPEG-4 DMIF and SIP

   In this section, we propose a functional architecture of logical
   entity, that performs interworking between MPEG-4 DMIF and SIP. This
   entity is called DMIF-SIP IWF (DMIF-SIP Interworking Function). The
   Figure 4 illustrates our purpose. The DMIF-SIP IWF is a server
   composed of two sides: SIP side and DMIF side performing two-ways
   signaling translation between SIP and DMIF.









Toufik et al.                Expire March 2002                  [Page 8]


Internet Draft            draft-ahmed-dmif-sip-00.txt     September 2001


      +-------+            ^^^^^^^
      | SIP   |          (    SIP  )
      | User  |<------->(  Network  )
      | Agent-|          (  _____  )
      +-------+             ^^|^^
                              |
                              |
                              |         ______
                        +===========+  /
                        |  SIP-DMIF | /  SIP2DMIF Unit
                        | IW Server | \  DMIF2DIF Unit
                        +===========+  \______
                              |
                              |
                              |
                              |
                           ^^^^^^^             +---------+
                         (   DMIF  )           | MPEG-4  |
                        (  Network  )<-------->| DMIF    |
                         (  _____  )           | Terminal|
                            ^^^^^              +---------+

   Figure 4 : Interworking between SIP and DMIF


   A. SIP side

   The SIP side of DMIF-SIP IWF is part of the IWF that terminates and
   originates SIP signaling from and to SIP network respectively. We
   call this function SIP2DMIF (SIP to DMIF) signaling. The SIP2DMIF
   signaling allows a SIP UAC to call MPEG-4 DMIF Terminal. SIP UAC
   talks to DMIF-SIP IWF with SIP specification. When SIP2DMIF IWF
   receives an INVITE message from SIP UAC, it sends DMIF Signaling
   Message (DS_Message) to DNI of MPEG-4 Server.  When the session and
   the service are done, the SIP2DMIF IWF sends 200 OK message back
   to SIP UAC. An Acknowledgment Message sends by SIP UAC confirms the
   connection of SIP UAC to the MPEG-4 Server. The Figure 5 illustrates
   the messages exchanged between SIP UAC, DMIF-SIP IWF and DNI of
   MPEG-4 Terminal.
















Toufik et al.                Expire March 2002                  [Page 9]


Internet Draft            draft-ahmed-dmif-sip-00.txt     September 2001


   SIP UA         SIP2DMIF IWF                 DNI      DAI    MPEG-4
     |   (1)INVITE    |                          |        :        |
     +--------------->|                          |        :        |
     |                |(2)DS_SessionSetupRequest |        :        |
     |                +------------------------->|        :        |
     |  (3) TRYING    |                          |        :        |
     |<---------------+                          |        :        |
     |                |(4)DS_SessionSetupConfirm |        :        |
     |                |<-------------------------+        :        |
     |                |                          |        :        |
     |                |(5)DS_SessionSetupRequest |        :        |
     |                +------------------------->|        :        |
     |                |                          +-----------------+
     |                |                          |connect to the   |
     |                |                          |application      |
     |                |                          |runing   the     |(6)
     |                |                          |service          |
     |                |(7)DS_ServiceAttachConfirm+-----------------+
     |                |<-------------------------+        :        |
     |   (8) 200 OK   |                          |        :        |
     |<---------------+                          |        :        |
     |  (9)ACK        |                          |        :        |
     +--------------->|                          |        :        |
     |                |(10) DS_ChannelAddRequest |        :        |
     |                +------------------------->|        :        |
     |                |                          +-----------------+
     |                |                          |   Addition of   |
     |                |                          |   channels      (11)
     |                |                          +-----------------+
     |                | (12) Media Channel (RTP) |        :        |
     |<===========================================================>|
     |                |                          |        :        |
   User                                                          User
     A                                                             B

   Figure 5: SIP2DMIF Interworking


   The Steps of the call between User A (SIP Terminal) and User B
   MPEG-4 DMIF Terminal) is described in what bellow:

   Step 1: SIP User A sends an INVITE request to User B. the INVITE
   request is an invitation to User B to participate to
   videoconferencing. The INVITE request contains:

        a). The identifier (mail address, phone number) of User B is
        inserted in the Request-URI field in the form of SIP URL
        b). SIP User A identifier is recognized as the call session
        initiator in the From field.
        c). A unique numeric identifier is assigned to the call and is
        inserted in the Call-ID field.
        d). The transaction number within a single call leg is
        identified in the CSeq filed.


Toufik et al.                Expire March 2002                 [Page 10]


Internet Draft            draft-ahmed-dmif-sip-00.txt      September 2001


        e). The Media capability User A is ready to receive is
        specified via SDP.

   Step 2:  SIP2DMIF IWF receives INVITE request from User A. it
   translate the identifier of User B in form of DMIF URL which was
   obtained when the MPEG-4 DMIF Terminal was turned-on. We suppose
   that the User B addressee match the DMIF URL.  The mapping between
   SIP addresses and DMIF URL is described later. SIP2DMIF IWF passes
   DS_SessionSetupRequest message to the remote DMIF peer in order to
   activate a network session. This message contains SIP User A
   capability of handling media. The MPEG-4 Capability Descriptor is
   defined in ISO/IEC 13818-6 MPEG DSM-CC.

   Step 3: DMIF2SIP IWF sends a 100 TRYING message to SIP User A.

   Step 4: DMIF-SIP IWF receives a DS_SessionSetupConfirm message. Both
   peers (SIP UAC and DMIF Terminal) have knowledge of the others. The
   received message contains also a common set of User B compatibility
   in preferred order of choice.

   Step 5: SIP2DMIF IWF sends DS_ServiceAttachRequest which contains
   DMIF URL

   Step 6: DNI Layer Informs the MPEG-4 Terminal that User A would to
   establish a video conferencing with User B.

   Step 7: DMIF-SIP IWF receives a DS_ServiceAttachConfirm message
   indicating that User B is apt to handling videoconferencing.

   Step 8: SIP2DMIF IWF sends a 200 OK message back to SIP User A. The
   200 OK Response notifies SIP User A that the connection has been
   made. This message contains also the intersection of the two
   terminals capabilities. If there is no support media between the two
   terminals a 400 Bad Request response with 304 Warning header field
   is sent.

   Step 9: SIP User A sends an ACK to DMIF-SIP IWF

   Step 10: By receiving the ACK Media channel must be done. For this
   fact, a DS_ChannelAddRequest is sent to DNI of MPEG-4 Terminal.

   Step 11: The MPEG-4 Terminal notifies the creation of the requested
   channels.

   Step 12: When RTP channel is opened between SIP User A and DMIF User
   B, media can flows and videoconferencing can begin.


   B. DMIF side

   The DMIF side of the DMIF-SIP IWF is the part of the IWF that
   terminates and originates DMIF signalling from and to DMIF network
   respectively. We call this function DMIF2SIP (DMIF to SIP)


Toufik et al.                Expire March 2002                 [Page 11]


Internet Draft            draft-ahmed-dmif-sip-00.txt      September 2001


   signaling. The DMIF2SIP signaling allows a MPEG-4 DMIF Terminal to
   call SIP UAC. Processing steps for establishing connection between
   an MPEG-4 DMIF terminal and a SIP Terminal are illustrated in 6 and
   explained in the following:


   MPEG-4   DAI      DNI                       DMIF2SIP IWF    SIP UAC
     |       :        |                          |                |
     +----------------+                          |                |
     |The application |                          |                |
     |initiates the   |(1)                       |                |
     |service         |                          |                |
     +----------------+ (2)DS_SessionSetupRequest|                |
     |       :        +------------------------->|  (3)INVITE     |
     |       :        |                          +--------------->|
     |       :        |                          |  (4) 200 OK    |
     |       :        |                          |<---------------+
     |       :        |(5)DS_SessionSetupConfirm |                |
     |       :        |<-------------------------|                |
     |       :        |(6)DS_SessionAttachRequest|                |
     |       :        +------------------------->|                |
     |       :        |(7)DS_SessionAttachConfirm|                |
     |       :        |<-------------------------|                |
     +----------------+                          |                |
     |The application |                          |                |
     |request a new   |(8)                       |                |
     |channel         |                          |                |
     +----------------+ (9)DS_ChannelAddRequest  |                |
     |       :        +------------------------->|  (10)  ACK     |
     |       :        |                          +--------------->|
     |       :        | (11) Media Channel (RTP) |                |
     |<==========================================================>|
     |       :        |                          |                |
    User                                                         User
     A                                                            B

   Figure 6: DMIF2SIP Interworking


   Step 1: The MPEG-4 Terminal passes a DA_ServiceAttach() primitive
   indicating the User B address (email address, phone number, etc.).
   DNI layer assigns a local session to this request.

   Step 2: DNI Layer sends a DS_SessionSetupRequest to DMIF2SIP IWF to
   establish a network session with SIP terminal.

   Step 3:  Upon receiving the Session establishment request, the
   DMIF2SIP IWF sends an INVITE message to SIP Terminal to participate
   in videoconferencing. The INVITE request contains:

        a). The address of User B is inserted in the Request-URI field
        in the form of SIP URL



Toufik et al.                Expire March 2002                 [Page 12]


Internet Draft            draft-ahmed-dmif-sip-00.txt      September 2001


        b). User A address is recognised as the call session initiator
        in the From field.
        c). DMIF2SIP checks whether its own address is contained in the
        Via field (to prevent loops), otherwise, it copies it own
        address in Via filed.
        d). DMIF2SIP IWF create a unique numeric identifier which is
        assigned to the call and is inserted in the Call-ID field.
        e). The transaction number within a single call leg is
        identified in the CSeq filed.
        f). The Media capability User A (DMIF terminal) is ready to
        receive is transformed to form a SDP message.

   Step 4: After sending TRYING and RINGING message, User B (SIP
   terminal) sends 200 OK Message which notifies DMIF2SIP IWF that the
   connection has been done. If SIP User B supports the media
   capability advertised in the INVITE message send by DMIF2SIP IWF, it
   advertises the intersection of its own and User  AÆs capability in
   the 200 OK response. If SIP User B does not support the media
   capability advertised by DMIF2SIP IWF, it sends back a 400 Bad
   Request response with a 304 Warning h3eader field.

   Step 5: Upon receiving 200 OK response, the DMIF2SIP IWF sends a
   DS_SessionSetupConfirm message back to MPEG-4 DMIF Terminal and
   specifies the common set of capability advertised by 200 OK
   response.

   Step 6: The MPEG-4 DMIF terminal now is suitable to assign a local
   significance of the network session and must request a service
   within the network session. This task is performed by sending
   DS_ServiceAttachRequest message.

   Step 7: DMIF2SIP IWF receives DS_ServiceAttachRequest message which
   idenfies the services at the DMIF2SIP side.

   Step 8: The MPEG-4 DMIF Terminal request the establishment of a new
   media channel.

   Step 9:  The DS_ChannelAddRequest message sends by MPEG-4 DMIF
   Terminal requests the establishment of new media channel.

   Step 10: DMIF2SIP IWF sends ACK message to SIP User B and it
   confirms that the two peers are capable of sending a receiving
   media.

   Step 11:  Media channels are now done, media can flows between the
   MPEG-4 DMIF Terminal and SIP terminal.









Toufik et al.                Expire March 2002                 [Page 13]


Internet Draft            draft-ahmed-dmif-sip-00.txt      September 2001


   C. Finding common subset of capabilities between terminals

   The capability set of a terminal or a user agent refers to the set
   of algorithms for audio, video and data that it can support. It also
   conveys information about constraints in the selection of algorithms
   it may have. For example, due to limited bandwidth, a terminal may
   indicate that it can use either G.711 without video or G.723.1 with
   H.261 video.

   Terminal Capability matching is required to check the ability of two
   peer end-systems to setup connections between them, and select the
   possible protocol stack supported. In case of DMIF and SIP, this
   stage is performing at session setup.

   SIP defines SDP as a protocol to describe SIP terminal capability.
   When SIP UAC initiates the session with DMIF Terminal, it sends an
   INVITE request to DMIF. The capability descriptor is carried in this
   INVITE request throw SDP message. When DMIF Terminal initiates the
   session, it sends a DS_SessionSetupRequest to SIP terminal at this
   stage the capability descriptor is carried in the
   comptabilityDescriptor field part of DS_SessionSetupRequest message.
   The algorithm to find the common subset of capability descriptor
   maximal intersection of any two-capability sets C1 and C2 is
   described in [5] and is given here:

   1. Set the result C to the empty set.

   2. For each pair of capability descriptors (d1, d2), where d1 is
   from C1 and d2 is from C2, derive the permutations of alternative
   sets, s1 and s2.  For each such permutation, where s1 is from d1 and
   s2 is from d2, intersect s1 and s2 (written as s=s1 ^ s2) and add s
   to C.

   3.   Remove duplicate entries from C.


6  Mapping between SIP addresses and DMIF URL

   6.1 MPEG-4 DMIF URL definition

   DMIF URLs allow the DMIF layer at the originating DMIF to parse the
   network address in order to establish a session with the designated
   target DMIF and subsequently locate a service entity to enable it.
   Optionally the DMIF URLs can be used to locate the source of an
   Elementary Stream in MPEG-4. The DMIF URL follows the generic syntax
   for new URL schemes defined in RFC1738.

   The DMIF URL on IP network consists of the following:
   xdmif://<user>:<password>@<target dmif>:<dmif port>/<service-entity-
   path> or <stream-source-path>





Toufik et al.                Expire March 2002                 [Page 14]


Internet Draft            draft-ahmed-dmif-sip-00.txt      September 2001


   6.2IETF SIP Address Format

   A SIP address can be either a SIP URL or any URI. The BNF of a SIP
   address is given below for reference:

   SIP-Address  = (name-addr | addr-spec)
   name-addr    = [display-name] '<' addr-spec '>'
   addr-spec    = SIP-URL
   SIP-URL      = 'sip:' [ userinfo '@' ] hostport url parameters
   [headers]
   userinfo     = user [ ':' password ]
   hostport     = host [ ':' port ]
   host                 = hostname | IPv4address
   url-parameters       = *(';' url-parameter)
   url-parameter        = user-param | ...

   C. Converting SIP address to DMIF URL

   SIP address can be converted to DMIF URL facially. SIP-URL is copied
   verbatim to DMIF URL without any additional or supplement
   information.

7  Security Considerations

   Security issues are not discussed in this memo.

8  Conclusion

   Diversity and heterogeneity of multimedia terminals and services
   characterize today IP networking environment. Consequently,
   interworking becomes a critical issue for resolving the differences
   in these elements and enabling seamless provision of audiovisual
   applications across networks. Interworking is a way of making
   different communicating systems cooperate to perform a particular
   service. Thus, this draft proposal emphasizes technical issues on
   call control and session establishment interworking between an ISO
   DMIF-compliant terminal and IETF SIP-compliant.

   We describe, in this DRAFT, the design of an experimental
   interworking system that performs various translation functions
   between the two signaling protocols, including session protocol
   conversion, service gateway conversion, and address translation.
   Multimedia Internet designers may then transparently combine MPEG-4
   multimedia content and IP telephony for advance videoconferencing
   services such as e-learning, e-commerce or collaborative
   conferencing.

   Internet users might well have the impression that it is an
   integrated multimedia service offered by a single Internet site.
   This is what we call a ôseamless IP videoconferencing service
   interworkingö. Current implementation supports both translation
   modes



Toufik et al.                Expire March 2002                 [Page 15]


Internet Draft            draft-ahmed-dmif-sip-00.txt     September 2001


References

[1]     M. Handley H. Schulzrinne, E. Schooler J. Rosenberg 'RFC 2543:
Session Initiation Protocol (SIP)', March 1999.
[2]     M. Handley, V. Jacobson, 'RFC 2327 SDP: Session Description
Protocol' April 1998.
[3]     IUT-T Recommendation H.323 Draft v4û 'Packet-based multimedia
communications systems', November 2000.
[4]     'Coding of audio-visual objects -- Part 6: Delivery Multimedia
Integration Framework (DMIF) final committee draft.', may 1998
[5]     H.Agrawal,R.R Roy, V.Palawat, A.Johnston, C.Agboh, D.Wang,
H.Schulzrinne, K.Singh, J.Maeng, 'SIP-H.323 Interworking' Internet
Draft. Work in progress.

Author's Addresses

   Toufik AHMED
   PRiSM Lab, UVSQ.
   University of Versailles     Phone:  +33 1 39 25 40 92
   45, av. Des Etats Unis       Email:  tad@prism.uvsq.fr
   78035 Versailles - France


   Ahmed MEHAOUA
   PRiSM Lab, UVSQ.
   University of Versailles     Phone:  +33 1 39 25 40 45
   45, av. Des Etats Unis       Email:  mea@prism.uvsq.fr
   78035 Versailles - France


   Raouf BOUTABA
   University of Waterloo,
   Dept. of Computer Science
   200 University Avenue West,
   Waterloo,Ont.                Phone: ++1 (519) 888 4567 ext.4820
   N2L 3G1 - Canada             Email: rboutaba@bbcr.uwaterloo.ca



















Toufik et al.                Expire March 2002                 [Page 16]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/