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://:@:/ or 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]