Research on SIP and H.323 Protocol Conversion Si Haiyang1, 2, Dong Liyan3, Liu Zhaojun3 Graduate School of the Chinese Academy of Sciences, Beijing, China 2 Shenyang Institute of Computing Technology, the Chinese Academy of Sciences, Shenyang, China E-mail: [email protected] 3 College of Computer Science and Technology, Jilin University, Changchun, China E-mail: [email protected] 1

Abstract Both of SIP and H.323 are widely used in VoIP. H.323 has wonderful structure. With H.323, it is easy to establish and control a call. SIP is a text based protocol. Although it is simpler than H.323 in structure, its power is as great as H.323. These two protocols offer the same services and functions with different mechanism. So, it is important and significant to achieve their conversion.

the Response of the INVITE. When a SIP UA starts a dialog to a H.323 Terminal, it sends an INVITE to the IWF. The INVITE has the media capability description of the SIP UA. The IWF records UA’s media description and then translates INVITE as SETUP. After that, instead of UA, the IWF arranges with Terminal for H.245 ability. The result will be included in 200OK and sent to the UA. The details are as follows:

1. Introduction H.323[1], which is advanced by ITU-T and SIP[2], which is advanced by IETF[3] are two main standards used in VoIP field. Because of their different instructions, we need an environment to support IP multimedia services. In this environment, H.323 and SIP can be connected smoothly. In another word, these two protocols should be converted freely.

2.

Key of the protocol conversion

Both H.323 and SIP use RTP as their transform way. So, only the signals need to be converted[4]. Usually, there is a gateway between isomeric systems. It is “IWF”. Figure 1.Signal Control – Start from SIP UA

2.2. Signal conversion We make a model. In which, there are only SIP UA, IWF and H.323 Terminal. When peer1 wants to communicate with peer2, it should know peer2’s net address, media capability and transport layer address[5]. In H.323, this information can be collected with different protocols signal at different steps. SIP is much simpler. Peer1 can communicate with peer2 only with the INVITE and

1. 2. 3. 4.

UA wants to make a collection with Terminal. It sends an INVITE request to IWF. IWF translates INVITE to SETUP and tells Terminal. Terminal gets the request and arranges with IWF. Instead of UA, the IWF arranges with Terminal to get a translation address, a media format for the following dialogs.

5. 6. 7. 8.

Terminal and UA communicate with media channel. UA informs IWF to finish the dialog. IWF finishes the dialog, and informs Terminal to disconnect the link with H.425 Terminal stops the dialog.

7.

IWF runs the dialog stop program which is defined in H.323 and informs UA stop with SIP BYE.

2.2. Media capability description Media capability arrangement is one of the crucial preconditions. It is an important part of the protocol conversation. It is composed of two parts: mapping of signal arrangement and translation of descriptive message. Each system has a special protocol to preside the work. In SIP, it is SDP which is based on ISO 10646 character set. In H.323, it is H.245[6]. H.323 defines a series of formats and the message syntax is based ASN.1. Beside the differences of coding format conversations, the semantic meanings of SDP and H.245 are different, too.

2.3. Addressing and architecture

Figure 2.Signal Control – Start from H.323 Terminal

When a Terminal invites a SIP UA, firstly, it will send SETUP to IWF. IWF translates it to be INVITE without media capability description. That is because the Terminal’s media capability is not recognized by IWF. SIP media adopt Offer/Answer model. It means UA’s media capability can only be advanced in INVITE or the Response of INVITE. So, UA tells IWF its media capability in the Response of INVITE. IWF records it and arranges with Terminal. Then, it tells the result to UA in 200OK’s ACK. The details are as follows: 1. 2. 3.

4. 5. 6.

Terminal sends a SETUP to IWF and makes a connection between Terminal and SIP UA. IWF translates SETUP into INVITE and then informs SIP UA with this INVITE. SIP UA accepts the request and sends response to IWF. The response which includes UA’s media capability is an OFFER. IWF arranges with Terminal about transport layer address and media format. Establishing the dialog. Terminal and UA can communicate each other with media channels. Terminal informs IWF to release control connection with H.245 and finish the dialog.

Figure 3.IWF with SIP Register

If peer1 wants to start a dialog with peer2, it needs to know peer2’s network address. In the net which is composed of SIP and H.323, IWF takes the responsibility for the communication of SIP and H.323. There are three types. The first one (Figure 3), IWF can be both SIP Register server and H.323 Terminal[7]. In SIP net, as the Register server, it accepts SIP UA’s registered information. Then IWF translates this UA’s address to be a virtual H.323 byname address. After that, IWF

associates its net address with H.323 byname address and registers to H.323 Gatekeeper. So, H.323 can find SIP UA via IWF very easy. When SIP UA wants to dialog with H323 terminal, it sends requests to IWF. Then IWF sends LRW to H.323 Gatekeeper to find the aim. The second one (Figure 4), as the H.323 Gatekeeper and a SIP UA, the IWF accepts register information. Then IWF translates it into virtual SIP URI. After that, the IWF associates the SIP URI with its net address and sends it to SIP Register server. SIP net can get the information of H.323. UA can find H.323 Terminal. When H.323 calls SIP UA, it sends ARQ request to its Gatekeeper firstly. This Gatekeeper broadcasts LRQ to all other Gatekeepers. IWF gets the request and sends INVITE to SIP. If it gets effective answer, it would send a LCF to Terminal.

message to UA. If it can get the 200OK from the IWF in time, the record of the H.323 Terminal would be added into the location server. If timeout, Not Found message would be sent to UA.

Figure 5.IWF is set as an absolute entity between SIP and H.323

3. Experiment Conversion of SIP and H.323 is a complex problem. Because the real web topology is very complex, here we make a simple model. It will be easy for future research.

3.1. Experiment environment

Figure 4.IWF with Gatekeeper

The third one (Figure 5), IWF is set as an absolute entity between SIP and H.323. In this way, the old architecture could be kept. But it will increase the load of network. The improvement is that a function entity: SHIF (SIP-H.323-Interworking-Funcation) is put between SIP UA and SIP proxy. SHIF is responsible for sending the requests of H.323 terminals to IWF. All of the requests from UA can be sent to SIP Proxy via SHIF. Also, all of the requests from SIP Proxy can be sent to UA via SHIF. But when SHIF gets a Not Found or Timeout message from the SIP Proxy, it will not transmit the message but make a 302 Moved message with IWF’s net address and send this

In this experiment, we use 5 computers. The SIP terminal, H.323 terminal, SIP server, H.323 Gatekeeper and IWF, each of them runs on one computer. We use Windows 2000 as operating system. The computer is equipped with PIV 1.6G CPU, 512M memory, 80G hard disk. Figure 6 shows the testing environment:     

SIP UA IP:192.168.139.105 SIP server IP: 192.168.139.108 H.323 terminal IP: 192.168.16.44 H.323 gatekeeper IP:192.168.16.48 IWF IP:192.168.139.140

1.

2.

3.

Video Meeting. There are a lot of terminals in a video meeting. If some of them belong to SIP, the other ones belong to H.323, it is hard to keep so many peers communicate smoothly with simple IWF-SIP-H.323 architecture. Security. The architecture has many security problems. If the IWF is attacked, the whole system would be down. Efficiency. How to improve the efficiency of the system is important. There will be faster communication with higher efficiency.

5. Conclusion With the development of SIP technology, H.323 and SIP communication will be more and more important. The IWF-SIP-H.323 architecture can solve most conversation of these two protocols. Although there are still many problems in this project, we believe it would be a valuable component for existing communication system.

Figure 6. Testing Environment

3.2. Testing process 1. SIP UA starts the dialog, H.323 terminal releases first 2. SIP UA starts the dialog, SIP UA releases first. 3. H.323 terminal starts the dialog, SIP UA releases first. 4. H.323 terminal starts the dialog, H.323 terminal releases first.

3.3. Testing result and analysis Caller

Aim

Successful Rate

Caller Release

Aim Release

Delay

SIP

H.32 3 SIP

93

OK

OK

<400ns

95

OK

OK

<400ns

H.323

Table 1.Testing Result

From the result in table 1, we find that IWF can parse the information from SIP UA and H.323 terminal successfully. Also it can realize the translation between SIP UA and H.323 terminal. Although there are still many problems, but the flow is right. So, this project is doable.

4. Future work Based on the experience mentioned in Section 2, we would like to improve in the following areas:

6

.References

[1]. H.323 ITU Recommendation [2]. RFC3261-SIP: Session Initiation Protocol [3]. J. Rosenberg, H. Schulzrinne, and G. Camarillo, SIP: session initiation protocol, RFC3261, IETF, June 2002 [4]. R. Ackermann, V. Darlagiannis, M. Gortz and M. Karsten, An Open Source H. 323-SIP Gateway as Basis for Supplementary Service Interworking, Proceedings of the 2nd IP Telephony Workshop, New York, 2001 [5]. W. Wu, A. Uyar and H. Bulut, Integration of SIP VoIP and Messaging Systems with AccessGrid and H.323, Proceedings of The 2003 International Conference on Web Service, Las Vegas, NV, USA, 2003 [6]. G.A. Thom, H.323: the multimedia communications standard for local area networks, Communications Magazine, IEEE, Delta Inf. Syst. Inc, USA, Dec 1996, Volume: 34, Issue:12. [7]. K.Singh, H. Schulzrinne, Interworking between SIP/SDP and H.323. Internet Draft, Internet Engineering Task Force [Z]. Jan.2000.