[asterisk-users] How to turn on the H323 logging on Asterisk

[bilal ghayyad]

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 <20080611082011.GB23243 at xorcom.com>,
Tzafrir Cohen <tzafrir.cohen at xorcom.com> 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: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org -
http://tony.mountifield.org