Abstract: Now a days, multimedia communication has been improved rapidly to allow people to communicate via the Internet. However, users cannot communicate with each other unless they use the same chatting applications since each chatting application has its own control protocol to make the call. The mapping between different protocols is a very critical issue since it solves the communication problems between any two protocols as well as it enables people around the world to talk with each other at anywhere and anytime even they use different chatting applications. Providing interoperability between different signaling protocols and multimedia applications will take the advantages of more than one protocol. This study surveys the existing mapping architectures between different signaling protocols, discusses the problems with these architectures and suggests an efficient mapping architecture by solving the problems faced in the existing ones.
INTRODUCTION
Over the last decade, multimedia techniques has been developed rapidly to enable users to communicate between each other over the Internet using all types of chatting services such as instant messages, audio and video. However, Internet users can phonetically communicate only and only if they use the same chatting applications since each chatting application uses specific signaling protocol to handle the call setup, the real time media transmission and the call teardown sessions (Saravanan and Ramadass, 2000).
Due to the appearance of VoIP technologies (Montoro and Casilari, 2009; Goode, 2002; Rittenhouse and Zheng, 2005) and many signaling protocols, such as Inter-Asterisk eXchange Protocol (IAX) (Spencer, 2004), Session Initiation Protocol (SIP) (Ingo, 2011) and H.323 protocol (Glasmann et al., 2003), media conferencing systems and IP applications, the interoperability has become very necessary to provide full end-to-end connectivity and to give users the flexibility to select their preferred applications as long as there is a method or mechanism that allows bridging the gap between the heterogeneous signaling protocols.
Furthermore, the multimedia communication service providers understand that users want to communicate with each other regardless of the service provider and protocol used on their IP network. The only way to enable the users to communicate phonetically using different chatting applications is to design a new mapping architecture for any two control protocols used by different chatting applications (Oishi and Inouchi, 2007). This study covers only the audio/video conferencing, instant messaging is out of this survey.
EXISTING MAPPING ARCHITECTURES BETWEEN TWO DIFFERENT PROTOCOLS
In this study, audio/video mapping architectures will be presented and discussed. All the existing architectures show that it is possible to use more than one protocol within the same network to make a voice/video call.
SIP-ISUP interworking: The architecture and the aspects of the interworking when an application uses SIP as a control protocol is connected with Public Switched Telephone Network (PSTN) have been presented (Zhang, 2002). The corresponding signaling protocol used in PSTN is the ISDN User Part (ISUP) of SS7.
| Fig. 1: | PSTN-IP call flow (Zhang, 2002) |
The researchers have first discussed the interworking problems related to the building an interworking architecture as well as the differences in the format of signaling and media messages interworking and how to overcome the common inter-operability problems between the PBX and the translation gateway by proposed the steps of solution to make this interworking as a vital issue (Singh et al., 2002). The proposed SIP-PSTN interworking architecture consists of SIP domain, PSTN domain and SIP-PSTN main gateway. As it is difficult to implement signaling and media transformation processing in a single monolithic structure, the SIP-ISUP main gateway is decomposed into three functional components, firstly, the Signaling Gateway (SG) which is responsible for receiving and routing all ISUP messages for the media gateway, secondly, the Media Gateway (MG) which is responsible for the mapping between the media in PSTN and IP domains and thirdly, the Media Gateway Controller (MGC) which is responsible for accepting signaling from the PSTN in native format and converting it to the message format that the IP network uses. The media data in this architecture is carried over RTP during the media session. During call flow, SIP and ISUP operate in separate administrative domains during signaling session and work within the same administrative domain during media transmission session. Figure 1 shows SIP-PSTN the architecture.
SIP-DMIF interworking: The functional architecture of logical entity that performs interworking between IETF SIP (Session Initiation Protocol) and ISO MPEG-4 DMIF (Delivery Multimedia Integration Framework) session has been proposed (Ahmed et al., 2002). This IP interworking system is called DMIF-SIP IWF (DMIF-SIP InterWorking Function). The DMIF-SIP IWF is a server composed of two sides: SIP side and DMIF side performing two ways translation between SIP and DMIF domains. The IWF 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).
| Fig. 2: | Interworking between SIP and DMIF (Ahmed et al., 2002) |
| Fig. 3: | Configurations of interworking between SIP and H.323 (Wang et al., 2004) |
The translation architecture showed that SIP works within the same administrative domain and DMIF operates in separate administrative domain during signaling session only.
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. The researchers have proposed an algorithm to convert the format of signals and media from one protocol to the other one as well as they have found a procedure for the conversion between SIP Address and DMIF URL. Figure 2 clarifies the interworking between SIP domain and MPEG-4 domain.
SIP-H.323 interworking: The SIP-H.323 Interworking Function (IWF) has been integrated into the SIP server and H.323 gatekeeper (RADvision, 2002; Schulzrinne and Agboh, 2005). This IWF is independent components and doesn’t require any optional components such as SIP or H.323 network. Four SIP-H.323 architectures have been designed (Wang et al., 2004) as shown in Fig. 3. Five main components in this system have been modeled using system description language and message sequence chart which are H.323 endpoint, H.323 gatekeeper, SIP-H.323 Interworking facility, SIP server, SIP endpoint. The four architectures have been established for simulating and verifying interworking between SIP and H.323. The four configurations showed that either one or both protocols work within the same administrative domain and either one or both protocols operates in separate administrative domains. All series of configurations has been used to show that the proposed model meets the functional specifications outlined in the SIP-H323 interworking specification documents.
The main reason of the existence of SIP server/H.323 gatekeeper is to store the data sent to/received from either the client or the translation gateway, this will reduce the task of the translation gateway to be only a translator.
| Fig. 4(a-b): | Configurations of SIP-H.323 interworking (Singh, 2006) |
In the case of SIP-H.323 configuration without existence of its own servers, both SIP and H.323 clients will deal with the translation server as their own server during the signaling session, so the task of the translation server is to store the SIP and H.323 data and to translate the signaling messages.
Another two SIP-H.323 configurations has been proposed by Singh (2006) related to user registration and address resolution. User registration servers are the entities in the network which store user registration information. The SIP registrars and H.323 gatekeepers are user registration servers. It simplifies locating users independent of the signaling protocol if the IWF has direct access to user registration servers. The user registration server forwards the registration information from one network, to which it belongs, to the other. In the first configuration, the function of the translation gateway is not only SIP-H.323 messages converter but also SIP proxy/registrar, whereas in the second configuration, the translation gateway acts as SIP-H.323 messages converter and H.323 gatekeeper (Singh, 2006) as shown in Fig. 4.
Chang et al. (2007) have followed another way to simplify the media conferencing VoIP protocols in general by dividing the messages between two clients into two types; originating messages which sent from initiator to responder, such originating messages are setup and disconnect messages, the terminating messages sent from responder to initiator and such terminating messages are answer and disconnect messages (Gurbani et al., 2005). As a result, to build SIP-H.323 interworking module based on the originating and terminating messages, H.323_O Basic Call State Model (BCSM) which is the initiator and SIP_T BCSM which is the responder basic call state model has been proposed. The O_BCSM represents the states associated with the call originating party and the T_BCSM represents the states associated with the call terminating party (Chang et al., 2007). The call control functions are performed through the exchange of events between the O_BCSMs and T_BCSMs. These events include setup, alert, answer, disconnect, busy, no-answer and abandon as shown in Fig. 5.
| Fig. 5: | SIP-H.323 interworking call flow (Chang et al., 2007) |
The SIP-H.323 IWF defines many new concepts, such as mapping of the call setup and teardown sequences, registering H.323 and SIP endpoints with SIP registrars and H.323 gatekeepers, resolving H.323 and SIP addresses, maintaining the H.323 and SIP state machines, negotiating terminal capabilities, opening and closing media channels, mapping media coding algorithms for H.323 and SIP networks, reserving and releasing call-related resources, processing of mid-call signaling messages, handling of services and features (Wang, 2002).
H.323-MGCP interworking: The interworking of the heterogeneous-VoIP has become a trend. Besides, the VoIP users are classified into many groups; the most common are H.323 protocol and Media Gateway Control Protocol (MGCP) (Dagiuklas et al., 2005). Therefore, to communicate both groups of users, H.323 and MGCP, a connection system of the heterogeneous-VoIP with a man-in-the-middle mechanism has been provided and practiced in this study.
This study has presented the main architecture of H.323-MGCP interworking module which consists of H.323 terminal, H.323 gatekeeper, call agent (translator), MGCP terminal and MGCP server.
| Fig. 6: | End-to-end H.323-MGCP platform architecture (Dagiuklas et al., 2005) |
Each protocol sends-receives the signaling and media messages via its own server which in turn send to-receive from to the translator, so both H.323 and MGCP protocols operate in separate administrative domains. The H.323-MGCP translator defines many new features to ease the interworking module function, such as mapping the call setup and teardown sequences, resolving H.323 and MGCP URI addresses and negotiating terminal capabilities. Figure 6 clarifies end to end H.323-MGCP platform architecture.
SIP-RSW interworking: A communication translation protocol to bridge the RSW control protocol and SIP control protocol has been proposed by Abouabdalla and Sureswaran (2006). The proposed system has been discussed without existence of SIP server for all sessions, whereas RSW uses its own server during the call setup and teardown only. The translation of RSW-SIP is provided by a server which is called the translation server or the translator (R2SP). Architecture is given to the translation server (R2SP) which allows interworking between the SIP and the MCS networks. The proposed module consists of MCS server, MCS client, translation server (R2SP) and SIP user agent (UA). The MCS side of the R2SP is the part of R2SP that originate and terminate MCS signaling messages from and to the MCS network, respectively. The SIP side of the R2SP is the part of R2SP that register, originate and terminate SIP signaling messages from and to the SIP network, respectively. There are many signaling differences related to SIP and RSW. However, the real time media between the two protocols can be exchanged without facing any problems as both protocols use RTP to carry the media packets.
The goal of interworking between SIP and RSW is to ease the exchanging of both media and signaling messages description between MCS and SIP entities (Abouabdalla and Sureswaran, 2006). An example of the connection establishment and call ending from SIP to MCS is shown in Fig. 7.
| Fig. 7: | SIP to MCS session setup example (Abouabdalla and Sureswaran, 2006) |
SIP-Skype interworking: In order to communicate both groups of users, SIP and Skype, an interoperability system between the two heterogeneous-VoIP protocols has been provided in this study. Skype uses closed protocol, so only the authorized cooperation vendors can develop value-added service owned by Skype. Besides, Skype does not support the open protocols such as SIP. Thus, users installing Skype cannot communicate with the SIP users. Therefore, this study has presented SIP-Skype architecture which contains SIP phone, Skype phone and translator.
The translator includes many modules which are Skype packet forwarding module (Skype-PF), SIP Packet Forwarding module (SIP-PF), voice capturing module (VoCP) and User Mapping (UM) module.
| Fig. 8: | SIP-Skype call flow (Shen et al., 2007) |
The major functions of Skype-PF module is to build a connection with the Skype phone, receive the voice data from the Skype phone, forward the voice data from the SIP phone to the Skype phone, receive the instant chat messages from the Skype phone and forward them to the SIP-PF and forward the instant chat messages from the SIP phone to the Skype phone. The SIP-PF module is responsible for forward the call setup messages, voice packets and instant message packets. The functions of VoCP module are to save voice data from the SIP phone as well as forward to the Skype phone and save the voice data from the Skype phone as well as forward to the SIP phone. The main functions of UM module are to design a mapping relationship of accounts between the SIP-PF as well as the Skype-PF and the SIP phone as well as the Skype phone and generate accounts of SIP as well as Skype (Shen et al., 2007).
If both users, on the Skype-end and SIP-end respectively, wish to communicate each other, they should manually key in the opposite side’s URL in the heterogeneous-VoIP system. Then the connection and voice packet forwarding can be built through the "SIP-PF" and the "Skype-PF". Finally, users on both sides of SIP and Skype can directly communicate via aforementioned modules. Figure 8 shows the process of SIP-Skype call flow.
H.323-H.320 interworking: In order to provide a video conferencing services for PSTN and H.323 users, a video Interworking module between H.323 and H.320 has been proposed (Cisco, 2009). The H.320 is an umbrella recommendation by the ITU-T for running multimedia (Audio/Video/Data) over ISDN based networks. The ITU H.320 is known as the standard for public switched telephone networks (PSTN) or videoconferencing over integrated services digital networks.
The proposed architecture consists of many components which are H.323 endpoint, H.323 gatekeeper, Multipoint Control Units (MCUs), video gateway (translator) which provides the interoperability between H.323 element and an installed base of H.320 unit and ISDN/PSTN. The most fundamental function of a gatekeeper is to provide address resolution, thus allowing terminals, gateways and Multipoint Control Units (MCUs) to be addressed using the international E.164 address standard and/or an H.323 alias. The E.164 defines a general format for international telephone numbers for the world-wide Public Switched Telephone Network (PSTN) and some other data networks. Each endpoint that is registered to a gatekeeper must be assigned a unique E.164 address (numeric identifier). As a result, zone prefixes are used in the H.323 video network to identify zones, similar to the use of area codes in telephony systems. Figure 9 shows H.323-H.320 platform architecture.
IAX-RSW interworking: The interworking between IAX and RSW protocols has been designed and the IAX-RSW experimental system with two Interworking architectures has been proposed by Kolhar et al. (2008a) and Kolhar (2010) as shown in Fig. 10 and 11.
| Fig. 9: | H.323-H.320 platform architecture (Cisco, 2009) |
| Fig. 10: | IAX-RSW interworking environment with the existence of MCS server (Kolhar et al., 2008b) |
| Fig. 11: | IAX-RSW interworking environment without the existence of IAX and MCS server (Kolhar, 2010) |
The IAX version 2 which is called IAX2 and MCS version 6 are considered to be the basis of the translation between IAX and RSW.
| Fig. 12: | SIP-JINGLE architecture with one gateway (Saint-Andre, 2013) |
The major goal of interworking is to solve the problems of the dissimilarities between the two protocols, such as registration messages, signaling messages, real time media transport, audio codec’s and many other differences. The second goal is to maintain continuous support between media and signaling sessions.
The first interworking architecture has been performed using the RAIS (RSW InterAsterisk Server), hence currently IAX client can be communicated with any Multimedia Conferencing System (MCS) client and vice versa (Kolhar et al., 2009). The IAX-RSW architecture consists of MCS server, MCS client, IAX client and the translation server (RAIS). The RSW side of the RAIS is part of the RSW, originates and terminates RSW calls from and to RSW network. This function is called RSW_TO_IAX which allows a RSW to call IAX client. The IAX side of the RAIS is called IAX_TO_RSW, which handles the registration process for IAX client as well as signaling from the IAX to IAX_TO_RSW which allows an IAX client to call the RSW client.
The second IAX-RSW architecture has been proposed using the CG (Conference Gateway) without the existence of IAX and MCS servers, so the IAX and RSW clients can deal directly with the CG for registrations of both protocols and exchanging the signaling and media messages (Kolhar et al., 2011).
SIP-JINGLE interworking: Jingle has been designed to easily map XMPP to SIP for communication through gateways or other transformation mechanisms. This work has described a bi-directional protocol mapping for use by gateway that enable the exchange of media and signaling messages between systems that implement SIP and those that implement the XMPP Jingle extensions as declared in Fig. 12.
| Fig. 13: | SIP-JINGLE architecture with two gateways (Saint-Andre et al., 2015) |
The main differences between XMPP and SIP lie in many aspects (Saint-Andre, 2008) which can be summarized in two points, firstly SIP messages and headers use a plaintext format similar in some ways to the hypertext transport protocol (HTTP), whereas Jingle messages are pure XML. Secondly, the SIP payloads defining session semantics use the Session Description Protocol (SDP), whereas the equivalent Jingle payloads are defined as XML child elements of the Jingle <content/> element (Saint-Andre, 2013).
The SIP-Jingle mapping has been presented with two architectures. The first architecture has been built by creating an SIP domain which contains SIP client without existence of SIP server, Jingle domain which contains Jingle client without existence of Jingle server and a translation gateway. The second architecture has been designed by creating an SIP domain which contains SIP client and SIP server, Jingle domain which contains Jingle client and Jingle server, SIP-to-Jingle translation gateway and Jingle-to-SIP gateway (Saint-Andre et al., 2015) as shown in Fig. 13. Each translation gateway in both architectures is considered as a converter of URI address and signaling messages syntax. The translation gateway has also the ability to replace the transport method or the codec used during the conference.
PROBLEMS WITH THE EXISTING STUDIES AND SUGGESTIONS
This study summarizes all the mapping architectures of the existing studies with the problems of each study in Table 1 and suggests a new mapping architecture by overcoming the problems in the previous studies.
By suggesting a new mapping architecture between two different protocols with two translation gateways and without the existence of protocol 1 and 2 client’s servers (both protocol 1 and 2 client’s servers are existed only during registration session).
| Table 1: | A Summary of the Problems of the existing mapping architectures |
The privileges of the suggested architecture compared to the existing studies are as follows:
| • | By distributing the function of translation gateway into two gateways (Protocol 1-2 and 2-1), so each gateway receives only from one party and sends only to the other party, this makes the function of each gateway is more simple and lead to less delay time compared to use one translation gateway |
| • | With the existence of protocol 1 and 2 client’s servers during registration session is more reliable and secure |
| • | Without the existence of protocol 1 and 2 client’s servers during signaling and media sessions, the translation gateways can deal directly with the clients. Thus, no need to obtain permission from the server for each signaling message sent to or received from the client as the gateways maintain a look-up table to provide address resolution and signaling and media messages translation |
CONCLUSION
This study provided brief explanation of the existing mapping architectures between two different signaling protocols with the problems of each one. The paper also suggests an new mapping architecture by solving the problems in the existing architectures.