H323 To SIP Signalling Proxy

H323 - SIP signalling proxy

One of the most common features requested for Yate is proxying between the H.323 and SIP protocols. This allows equipment that only knows one of the protocols to make calls to equipment that knows only the other protocol.

An extra bonus is that both H.323 and SIP use the RTP protocol to transport the actual voice data. The proxy is configured to tell both ends to forward the RTP packets directly to the other end. This way the proxy machine doesn't need to handle the voice traffic, unpack the RTP packets, or understand the data format. Formats for which Yate has no codec can still be proxied provided they are supported by both endpoints.

Some of the Yate modules - namely h323chan and ysipchan - have the ability to negotiate RTP Forwarding during the routing stage.

Compiling H323plus

Yate with [H323plus compiling]

NOTE !!! OpenH323 has been deprecated by H323plus.

Compiling OpenH323

Take a look to learn how to [compile OpenH323].

Creating a H.323 to SIP proxy

Here's how to create the desired application: a H.323 to SIP proxy using the G.711u or G.711a or G.723 audio formats. Note that we have no codec for G.723 but we still can pass it directly between clients.

First we have to set up the H.323 channel to use RTP pass-through mode. In this channel the RTP mode must be configured globally, not per call.

In the file h323chan.conf we put:

[general] external_rtp=yes passtrough_rtp=yes  ; note the incorrect spelling [codecs] default=no mulaw=yes alaw=yes g723=on g729=on [ep] faststart=on

We must enable fast start mode as it will provide the media network address early enough to send it to SIP.

In the ysipchan.conf file we put:

[codecs] default=off mulaw=yes alaw=yes g723=yes

There is no special setting for RTP pass-through as the SIP module can use the routing time decision.

Now we have to establish routes and to activate RTP pass-trough for them. We will use the Regular expression routing module for that.

In the regexroute.conf file we put:

[default] ${rtp_forward}possible=;rtp_forward=yes ${formats}^\([^,]*\)=;formats=\1 ^00.*=h323/\0@10.0.0.3 .*=sip/sip:\0@10.1.0.5

We accept RTP Forwarding for all modules that declare that capability. If the data formats list holds more than one we will only keep the first one. This is required so that we know in advance which codec will be used. While SIP sends a list of formats and accepts data in any of them, H.323 requires negotiating a specific format. Since that would require re-INVITE in SIP, we are better off deciding early what format we like.

In the sample routing rules above, numbers starting with 00 are sent to a H.323 gateway at address 10.0.0.3 while all others are routed to a SIP agent at address 10.1.0.5

This is another example that routes everything from protocol sip to ip 10.0.0.3 on protocol h.323 and everything that comes from h323 goes to 10.1.0.5 on protocol SIP:

[default] ${rtp_forward}possible=;rtp_forward=yes ${formats}^\([^,]*\)=;formats=\1 ${module}^sip$=h323/${called}@10.0.0.3 ${module}^h323$=sip/sip:${called}@10.1.0.5 .*=-;error=forbidden;reason=Protocol not allowed

Here are some ideas for configuring the system for handling many simultaneous calls. The RTP section will probably not apply.

As a final note, there is nothing wrong in proxying the signalling between two endpoints that use the same protocol! It may be less optimal than a native protocol proxy but it works and preserves the uniformity of configurations.