The key problem of the existing distributed multimedia systems is interoperability of audio and video streams establishment mechanisms and negotiation of QoS parameters. IETF proposed Session Initation Protocol (SIP) [1] as a standard protocol used for session initiation and its parameters negotiation in Internet. On the other side, OMG, IMTC and other organizations promote various standards for audio and video streams control, transmission, processing and visualization. The most important document in this field developed up-to-date by OMG is Control and Management of Audio/Video Streams (AVSC) [2] specification. IMTC committee proposed H.323 standard almost at the same time. Both standardization efforts have a potential to create basis for many multimedia applications, but they also introduce diversity of system architectures and control protocols. It raises questions about the mechanisms which provide interoperability between such applications.

Interoperability of many multimedia applications constructed over different system platforms can be practically achieved using SIP controlled gateway construction. SIP protocol is used for the session establishment and parameters negotiation. The gateway is responsible for translation of either a control mechanism or a media stream representation. The first one based on translation of SIP control command into proper AVSC action gives possibilities for open communication with AVSC Multimedia Devices. The second kind is represented by SIP controlled communication software module, which provides media stream conversion between IP telephony applications and PSTN. This gateway is based on the first scenario, where SIP plays a crucial role as common protocol used for the gateway activity control.

The gateway was designed to achieve interoperability between two different procedures of media streams initiating: one based on AVSC specification and the other compatible with SIP protocol.

The Session Initiation Protocol is an application-layer protocol used for establishing and tearing down multimedia sessions, both unicast and multicast. It has been standardized within the Internet Engineering Task Force for the invitation to multicast conferences and Internet telephone calls [3]. The basic scenario of SIP usage is very well described in the paper [4]. Entities in SIP are user agents, proxy servers and redirect servers. User is addressed using email-like address ‘user@host’, where ‘user’ may be user name or phone number and ‘host’ is a domain name or numerical address of user’s machine.

The AVSC represents platform independent approach to the problem of multimedia streams management with CORBA. It means that the abstraction of stream does not exists as IDL type and multimedia streams are transported rather by application specific protocols than using Internet Inter ORB Protocol (IIOP), which is based on TCP. CORBA mechanisms are used only to perform control functions. Multimedia streams transport protocols and QoS parameters are orthogonal to the control architecture. It is possible to use the transport protocols such as RTP, UDP, AAL5 or any other protocol developed to transfer multimedia streams. This approach opens the possibilities to implement multimedia client and server applications over two different platforms, still having the ability to exchange multimedia data. This scenario requires however interoperability of the session establishment and control protocols on both: client and server sides respectively.

The SIP-AVSC gateway files this gap providing mechanisms of SIP calls translation into AVSC stream control process activity. The structure of the gateway has been shown in Figure 1.

It consists of three basic parts, which are dedicated to SIP massages handling, active call processing and AVSC activity respectively. The first one is implemented by the SIPNet module. It provides mechanisms for sending and receiving of SIP messages, as well as functions usefull for creating new packets and extracting information from those already received. The second part consists of CallManager object, which is responsible for taking proper actions concerned with every packet which is received or should be send and collection of SIPCall objects, which are dedicated to perform actions on the specific call. There is one entity for every currently active call. This part is also responsible for contacting with an external location service and communicating with the third AVSC part of the gateway via StreamCtrl CORBA server interfaces. The last part consists of objects which are seen as AVSC environment components representing the gateway. These are: one SIP Multimedia Device and collection of SIPEndPoint and SIPVDev pairs.

Calls can be initiated both from SIP side and from AVSC side. In both cases users shouldn’t be aware of the gateway presence.

When new incoming SIP request is received by SIPNet module it is handled by CallManager class. Called user must be found using location service, which returns its MMDev. Then SIPMMDev is asked to create new pair of SIPEndPoint and SIPVDev objects. Also new SIPCall and StreamCtrl are created. After the SDP parameters are successfully parsed the connection between SIPMMDev and located user’s MMDev is estabilished and session parameters are negotiated. If this succeed OK packet is send back to the caller and media streams flows are started. In this scenario SIP caller is not aware that callee is reached via the SIP-AVSC gateway. The behaviour is the same as with ordinary SIP user agent.

UML sequence diagram with SIP INVITE request processing is presented at the end of this paper.

AVSC user can also initiate a connection to the specified SIP user. However he does it by requesting connection between his own MMDev and SIPMMDev specifing as additional argument user’s SIP address. That is the normal way of estabilishing connections in AVSC environment, so all the SIP world is represented via a SIPMMDev. There is almost no difference for the AVSC user except that he has to specify users name. SIPMMDev, which is asked for such a connection, is responsible for sending OPTIONS and INVITE packets with the right session attributes inside. If the session request is accepted media streams flows are starting their transmission.

Every call can be terminated either by issueing BYE request from a SIP user agent or by invoking destroy operation on the StreamCtrl object, which handles specific session. Both scenarios result in inactivating the call.

The SIP-AVSC gateway has been written in C++. The SIP part is based on Vovida SIP package and the AVSC part is built over OmniORB which is CORBA 2.2 compliant implementation. The Vovida package was choosen from available libraries because of its clarity, open source character and fast progress on library improvements. The OmniORB has been chosen because its portability, reliability and performance. Selected components made possible to run the SIP-AVSC gateway on Linux. The system is integrated with CORBA NameService [5], where the multimedia devices available in the AVSC domain are registered.

Application source code is divided into several parts – libraries. Such a construction gives gateway necessary flexibility and openess for further development.

The SAGA application can be downloaded from ACC Meccano web site under the link: