Internet DRAFT - draft-ahmed-dmif-sip
draft-ahmed-dmif-sip
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]
