H323 To SIP Signalling Proxy
Line 2: | Line 2: | ||
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. | 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. | ||
− | [[File: | + | [[File:yate_h323toSIP.png]] |
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. The endpoints in this case can be phones or softphones. | 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. The endpoints in this case can be phones or softphones. |
Revision as of 17:08, 7 January 2013
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. The endpoints in this case can be phones or softphones.
Some of the Yate modules - namely h323chan and ysipchan - have the ability to negotiate RTP Forwarding during the routing stage.
Below you can find the steps to follow to configure Yate as a H323 to SIP signalling Proxy.
We recommand OpenH323 library which is a stable version to use with Yate.
Contents |
Compiling H323 library
There are two libraries that can be used:
- It is recommended OpenH323 library which is the stable version to use with Yate.
Take a look to learn how to compile OpenH323.
- Yate works with H323plus support but it is not stable.
Here is how to compile Yate with H323plus.
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.
Configuring H323 Channel module
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] ; Use an external RTP module instead of the native OpenH323 RTP stack, which is ; very cpu intensive. If no external RTP can be found it will fallback to the ; native stack. The only external RTP now is yrtp (see the yrtpchan module). ; external_rtp: bool: default: yes external_rtp=yes [codecs] ; This section allows to individually enable or disable the codecs default=no ; mulaw: bool: Companded-only G711 mu-law (G.711-uLaw-64k) mulaw=yes ; alaw: bool: Companded-only G711 a-law (G.711-ALaw-64k) alaw=yes ; g723: bool: ITU G.723 all variations (G.723) g723=on ; g729: bool: ITU G.729 all variations (G.729) g729=on [ep] ; Control the endpoint operation of the module ; faststart: bool: Enable Fast Start mode (offer media channels early) ; This setting is required when doing direct RTP forwarding between endpoints faststart=on
We must enable fast start mode as it will provide the media network address early enough to send it to SIP.
Configuring SIP Channel module
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.
Configuring routing module
Now we have to establish routes and to activate RTP 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 ;numbers starting with 00 are sent to a H.323 gateway at address 10.0.0.3 ^00.*=h323/\0@10.0.0.3 ;all numbers are routed to a SIP agent at address 10.1.0.5 .*=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
Another routing example
This is another example that routes everything from protocol SIP to IP 10.0.0.3 on protocol H323 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
Troubleshooting
When testing this configuration if you will find this error:
<WARN> libh323_linux_x86_.so.1.23.0: cannot open shared object file: No such file or directory;
To solve it, you must add in file /etc/ld.so.conf this line: /usr/local/lib. And then run ldconfig as root.
Handling simultaneous calls
Here are some ideas for configuring the system for handling many simultaneous calls. The RTP section will probably not apply.
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.
See also