There is another H.323 channel implementation (in fact the first one for asterisk that came into existence), named Asterisk-oh323 which is actively developed by InAccess Networks and can be found at http://www.inaccessnetworks.com/projects/asterisk-oh323.
asterisk-ooh323c is a part of asterisk-addons package. It is yet another, new (as of June '05) channel driver based on open source H.323 stack (ooh323c) from Objective systems. This stack is developed in C and contains only the code necessary to set up H.323 signaling channels. All media processing is handled by Asterisk itself. This provides scalability for H.323 calls that will depend primarily on the capability of Asterisk to handle media streams. Users should see call volume handling that is similar in magnitude to what can be handled by SIP. Currently (30-Jun-2005) the channel driver is available on asterisk-addons cvs and also from Objective Systems website at http://www.obj-sys.com/open. Note: You need CVS-HEAD version of asterisk.
The Woomera protocol makes it possible to put your voice over ip system in one server/process and your pbx in another and connect them with a simple raw-linear-over-udp protocol. chan_woomera is an asterisk channel_driver designed to interface the Asterisk PBX with woomera. Currently (June '05) this code is working but considered beta. Woomera currently only supports H323 but it should soon support the OPAL VOIP abstraction layer which will allow it to speak many other protocols. The number of protocols supported by the Woomera server is irrelevant to chan_woomera which will support anything Woomera supports because of it's thin-client-like design.
With woomera you can connect asterisk to a H.323 server (openh323 code) which will do H.323 over IPv6. Apparently openh323 also has some SIP code in their CVS. If added to chan_woomera, you'd get SIP over IPv6 also. h323 performs better, but has no jitter buffer. This implementation uses the Asterisk RTP stack. oh323 driver uses the RTP/RTCP stack and the adaptive jitter buffer implementation of OpenH323. oh323 does not use the codecs of OpenH323 but those of Asterisk. Using OH323 makes all these (stability) problems (with h323) go away, however at a cost of approximately 10-15 times the CPU usage in my situation: a G729 call coming from a Sipura and being rerouted with G.729 over H323 to a Quintum call proxy Jeremy McNamara on performance and why he started chan_h323 Compilation in channels/h323 subdirectory fails with a lot of syntax errors - you need to use exactly the version of PWLib and OpenH.323 mentioned in README. While connecting with H.323 client you get no audio or garbled audio and messages like this on Asterisk console: rtp.c:489 ast_rtp_read: Unknown RTP codec 107 received. Try to disable Speex or some other codec on Asterisk or/and client side. Compiling openh323 can require substantial memory resources, so make sure you have either enough RAM or sufficient SWAP (user report: 380 MB required) MS Neetmeeting is available on most Windows machines and thus a common tool to run the first h.323 test. Be sure to manually select a preferred audio codec in Netmeeting that is well supported by Asterisk, e.g. do not use g723.1 (which is the default) but A-Law or u-Law. Where bandwidth is a concern, use the installable GSM codec for Netmeeting which is available here: Netmeeting-GSM. Just download and start the instcodec.exe, select the GSM codecs and return to Netmeeting.
There is also a Netmeeting plugin for the free Open Source codec Speex, but it is a bit hard to set up: (Netmeeting Speex).
The next step is to edit h323.conf so that your netmeeting callers get dtmfmode=inband.
If you'd like to dial different extensions on Asterisk then you'll probably want to enter the Asterisk server's hostname (or IP address) as Gateway (not Gatekeeper!) in Netmeeting. After that just dial the extension. Without this Gateway setup you will probably want to dial the IP address of your Asterisk box.
chan_ooh323 with Siemens optiPoint 400 : if the RTP stream is closed after 30 seconds, it means chan_ooh323 didn't get a H.245 terminalCapabilitySetAck from the phone and timed out. This happens because the phone expects the dtmf item in the message and doesn't send the acknowledgment if the item isn't present. To work around the problem, use dtmfmode = h245signal in ooh323.conf.
allow=all in ooh323.conf won't work with asterisk-addons-1.4.0 or ealier (calls hang up just after being answered, see http://www.mail-archive.com/ooh323c-devel@lists.sourceforge.net/msg00385.html and the subsequent posts). You must have disallow=all, followed by allow=
No comments:
Post a Comment