I am still looking to know if all of these h323's are able to work as gatekeeper, so endpoint can register?
About "chan_ooh323 and using It is clean the Asterisk RTP stack (and can therefore bridge properly), and doesn't creak under the bloat of OpenH323 like the first two do": The other two: how they use the RTP stack if they do not use Asterisk RTP? And what do u mean by bridge properly? (How?) Your kindly help is high appreciated. Regards Bilal ------------------- In article <[EMAIL PROTECTED]>, Tzafrir Cohen <[EMAIL PROTECTED]> wrote: > On Wed, Jun 11, 2008 at 10:40:41AM +0300, Sema Arca wrote: > > Hi, > > > > Does anybody know how I can turn on the logging for H323 in Asterisk? I have > > set the logging path and the file name in the ooh323.conf file however it > > did not help. The file is created but is empty. I want to, if possible, turn > > on the logging in DEBUG level. ooh323 does not have debug-to-file. You enable debugging with "ooh323 debug", and then the debug information is sent to the "verbose" channel, which normally goes to the console and may go to one of the general log files, according to the settings in logger.conf. ooh323 debugging is stopped by giving "ooh323 no debug". > The file name is ooh323c.conf (note the extra 'c'). No, ooh323.conf is correct. The 'c' is used in the name of the stack, but not in the name of the Asterisk channel or the conf file. > It is used by chan_ooh323c, rather than chan_h323. chan_ooh323c is > unmaintained and not recommended for new installations. This was because until recently, the most up-to-date chan_ooh323 driver and stack were the ones in the 1.2 branch of asterisk-addons. However, I recently ported the 1.2 version forward to 1.4, trunk and 1.6.0, and added a couple of bug fixes. Those changes were accepted into SVN, so that all those variants are now up to date. It should therefore now be easy to keep them maintained as far as Asterisk API changes are concerned. Having tried chan_h323, chan_oh323 and chan_ooh323, I *would* strongly recommend chan_ooh323 over the first two. It is clean and lightweight, uses the Asterisk RTP stack (and can therefore bridge properly), and doesn't creak under the bloat of OpenH323 like the first two do. I don't know whether Objective Systems have abandoned chan_ooh323 and the ooh323c stack, but it would be great to see them moved from -addons into the main Asterisk tree. Cheers Tony -- Tony Mountifield Work: [EMAIL PROTECTED] - http://www.softins.co.uk Play: [EMAIL PROTECTED] - http://tony.mountifield.org _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
