- h323plus - lists.packetizer.com

PTRACE
by Alex Katebi 17 Aug '10

17 Aug '10

Hello, How can I enable PTRACE in the ptlib ? Basically I want to enable all the tracing and levels in ptlib and h323. I have done the below initialization but I don't see all the traces. PTrace::Initialise( 5, NULL, PTrace::Blocks | PTrace::Timestamp | PTrace::Thread | PTrace::FileAndLine ); Thanks Alex Katebi

2 1

Strange library names due to change in PTLIB macros, proposed patch.
by Francisco Olarte (M) 12 Aug '10

12 Aug '10

I previously sent the message at the bottom to the list, proposing a change to sync the release/debug library names with those used in ptlib ( changing x_r/x_d to x/x_d, which presently are x_, x__d). I've decided to further investigate it and made a path. This let's me do a make both & make both install without problems. I've then used the patched release to compile gnugk 2.3.2-3 without problem. I've also compiled yate3, but this is anecdotic since it is patched. I'd propose the patch for inclusion, as I think these kind of details maters, and present names look ugly for me. My path is just two lines, very small, it is this: folarte@gkaps ~/src/h323plus-cvs $ diff -u openh323u.mak.in* --- openh323u.mak.in 2010-08-12 16:58:53.077428934 +0200 +++ openh323u.mak.in.~1.8.~ 2009-07-25 12:35:51.000000000 +0200 @@ -249,14 +249,14 @@ ifeq ($(NOTRACE), 1) STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN -OH323_SUFFIX = _n +OH323_SUFFIX = n else STDCCFLAGS += -DPTRACING RCFLAGS += -DPTRACING OH323_SUFFIX = $(OBJ_SUFFIX) endif # NOTRACE -OH323_BASE = h323_$(PLATFORM_TYPE)$(OH323_SUFFIX)$(LIB_TYPE) +OH323_BASE = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE) OH323_FILE = lib$(OH323_BASE).$(LIB_SUFFIX) LDFLAGS += -L$(OH323_LIBDIR) This makes nicer names, both for the compile-tree lib names: folarte@gkaps ~/src/h323plus-cvs $ ls -l lib total 183292 lrwxrwxrwx 1 folarte folarte 30 Aug 12 17:02 libh323_linux_x86_64.so -> libh323_linux_x86_64.so.1.22.0 -rwxr-xr-x 1 folarte folarte 10919080 Aug 12 17:02 libh323_linux_x86_64.so.1.22.0 lrwxrwxrwx 1 folarte folarte 32 Aug 12 17:06 libh323_linux_x86_64_d.so -> libh323_linux_x86_64_d.so.1.22.0 -rwxr-xr-x 1 folarte folarte 42136063 Aug 12 17:06 libh323_linux_x86_64_d.so.1.22.0 -rw-r--r-- 1 folarte folarte 85152810 Aug 12 17:02 libh323_linux_x86_64_d_s.a lrwxrwxrwx 1 folarte folarte 32 Aug 12 18:05 libh323_linux_x86_64_n.so -> libh323_linux_x86_64_n.so.1.22.0 -rwxr-xr-x 1 folarte folarte 8834968 Aug 12 18:05 libh323_linux_x86_64_n.so.1.22.0 -rw-r--r-- 1 folarte folarte 18061356 Aug 12 18:05 libh323_linux_x86_64_n_s.a -rw-r--r-- 1 folarte folarte 22564616 Aug 12 17:02 libh323_linux_x86_64_s.a drwxr-xr-x 2 folarte folarte 4096 Aug 12 17:02 obj drwxr-xr-x 2 folarte folarte 4096 Aug 12 17:02 obj_d drwxr-xr-x 2 folarte folarte 4096 Aug 12 18:05 objn and for the installed names folarte@gkaps ~/src/h323plus-cvs $ ls -l ~/lib/*h323* lrwxrwxrwx 1 folarte folarte 30 Aug 12 17:07 /home/folarte/lib/libh323_linux_x86_64.so -> libh323_linux_x86_64.so.1.22.0 lrwxrwxrwx 1 folarte folarte 30 Aug 12 17:07 /home/folarte/lib/libh323_linux_x86_64.so.1 -> libh323_linux_x86_64.so.1.22.0 lrwxrwxrwx 1 folarte folarte 30 Aug 12 17:07 /home/folarte/lib/libh323_linux_x86_64.so.1.22 -> libh323_linux_x86_64.so.1.22.0 -r--r--r-- 1 folarte folarte 10919080 Aug 12 17:07 /home/folarte/lib/libh323_linux_x86_64.so.1.22.0 lrwxrwxrwx 1 folarte folarte 32 Aug 12 18:09 /home/folarte/lib/libh323_linux_x86_64_n.so -> libh323_linux_x86_64_n.so.1.22.0 lrwxrwxrwx 1 folarte folarte 32 Aug 12 18:09 /home/folarte/lib/libh323_linux_x86_64_n.so.1 -> libh323_linux_x86_64_n.so.1.22.0 lrwxrwxrwx 1 folarte folarte 32 Aug 12 18:09 /home/folarte/lib/libh323_linux_x86_64_n.so.1.22 -> libh323_linux_x86_64_n.so.1.22.0 -r--r--r-- 1 folarte folarte 8834968 Aug 12 18:09 /home/folarte/lib/libh323_linux_x86_64_n.so.1.22.0 lrwxrwxrwx 1 folarte folarte 25 Aug 12 18:09 /home/folarte/lib/libopenh323.so -> libh323_linux_x86_64_n.so I made make both, make install, make NOTRACE=1 opt, make NOTRACE=1 install, so the installed link points to the last one, but verified in between and it pointed to the traced one. I've found more changes in cvs diff, which are due to having run configure in between, and getting collisions with the generated files included in the repository, the same which happened when I submitted a patch for aclocal auto running in configure.in cvs diff output: *** This is my change. Index: openh323u.mak.in =================================================================== RCS file: /cvsroot/h323plus/h323plus/openh323u.mak.in,v retrieving revision 1.8 diff -r1.8 openh323u.mak.in 252c252 < OH323_SUFFIX = n --- > OH323_SUFFIX = _n 259c259 < OH323_BASE = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE) --- > OH323_BASE = h323_$(PLATFORM_TYPE)$(OH323_SUFFIX)$(LIB_TYPE) *** I think this is due to having both the .h and the .h.in files in the source tree. Index: include/openh323buildopts.h =================================================================== RCS file: /cvsroot/h323plus/h323plus/include/openh323buildopts.h,v retrieving revision 1.5 diff -r1.5 openh323buildopts.h 0a1 > /* include/openh323buildopts.h. Generated from openh323buildopts.h.in by configure. */ 26,28c27,38 *** And this three Index: plugins/video/H.263-ffmpeg/Makefile Index: plugins/video/H.264/Makefile Index: plugins/video/H.264/gpl/Makefile are due to having Makefile.in and Makefile in the source tree, same problem. Regards. Francisco Olarte Francisco Olarte. Previous message for reference purposes. On Tue, Aug 10, 2010 at 5:39 PM, Francisco Olarte (M) <folarte(a)peoplecall.com> wrote: > Due to some configure scripts hacking I've been trying to do I've > noticed that both H323 plus and old openh323 generate library names > (OH323_BASE, OH323_FILE) using from OBJ_SUFFIX via OH323_SUFFIX: > >>>>H323plus, cvs 20100525, openh323u.mak.in > 248-endif # OH323_LIBDIR > 249- > 250-ifeq ($(NOTRACE), 1) > 251-STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN > 252:OH323_SUFFIX = n > 253-else > 254-STDCCFLAGS += -DPTRACING > 255-RCFLAGS += -DPTRACING > 256:OH323_SUFFIX = $(OBJ_SUFFIX) > 257-endif # NOTRACE > 258- > 259:OH323_BASE = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE) > 260-OH323_FILE = lib$(OH323_BASE).$(LIB_SUFFIX) > 261- > 262-LDFLAGS += -L$(OH323_LIBDIR) > 263-LDLIBS := -l$(OH323_BASE) $(LDLIBS) > <<< >>>>/openh323_v1_19_0_1/openh323u.mak.in > 212-endif # OH323_LIBDIR > 213- > 214-ifeq ($(NOTRACE), 1) > 215-STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN > 216:OH323_SUFFIX = n > 217-else > 218-STDCCFLAGS += -DPTRACING > 219-RCFLAGS += -DPTRACING > 220:OH323_SUFFIX = $(OBJ_SUFFIX) > 221-endif # NOTRACE > 222- > 223:OH323_BASE = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE) > 224-OH323_FILE = lib$(OH323_BASE).$(LIB_SUFFIX) > 225- > 226-LDFLAGS += -L$(OH323_LIBDIR) > 227-LDLIBS := -l$(OH323_BASE) $(LDLIBS) > <<< > > But the problem is while old pwlibs always had OBJ_SUFFIX as 'd' 'r' > ( for debug/release ): > >>>>pwlib_v1_11_0/make/unix.mak > 882- > 883:ifndef OBJ_SUFFIX > 884-ifdef DEBUG > 885:OBJ_SUFFIX := d > 886-else > 887:OBJ_SUFFIX := r > 888-endif # DEBUG > 889:endif # OBJ_SUFFIX > 890- > 891-ifndef OBJDIR_SUFFIX > 892:OBJDIR_SUFFIX = $(OBJ_SUFFIX) > 893-endif > <<< > > ptlib changed that in revision 20877 > > http://www.opalvoip.org/websvn/listing.php?repname=Opal&path=%2Fptlib%2Ftru… > > http://www.opalvoip.org/websvn/comp.php?repname=Opal&path=%2F&compare[]=%2F… > > from 'd'/'r' to '_d'/'' > > and ajusted it's paths acordingly, but h233plus did not, so the > current paths end up being > > > lrwxrwxrwx 1 gnugk gnugk 31 Aug 10 16:46 > libh323_linux_x86_64_.so -> libh323_linux_x86_64_.so.1.22.0 > lrwxrwxrwx 1 gnugk gnugk 31 Aug 10 16:46 > libh323_linux_x86_64_.so.1 -> libh323_linux_x86_64_.so.1.22.0 > lrwxrwxrwx 1 gnugk gnugk 31 Aug 10 16:46 > libh323_linux_x86_64_.so.1.22 -> libh323_linux_x86_64_.so.1.22.0 > -r--r--r-- 1 gnugk gnugk 10059909 Aug 10 16:46 libh323_linux_x86_64_.so.1.22.0 > lrwxrwxrwx 1 gnugk gnugk 24 Aug 10 16:46 libopenh323.so -> > libh323_linux_x86_64_.so > > This is only cosmetic ( it affects some makefiles I have which try to > locate the _r names, but that's another story ), but maybe changing > the names so the names are > > libh323_linux_x86_64.so / libh323_linux_x86_64_d.so > > instead of > > libh323_linux_x86_64_.so and libh323_linux_x86_64__d.so > > (double underscore in second ) is worthwile > > This could be done just by changing > > 259:OH323_BASE = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE) > > to > > 259:OH323_BASE = h323_$(PLATFORM_TYPE)$(OH323_SUFFIX)$(LIB_TYPE) > > ( underscore zapped between the two macros ) > > and will possibly need changing > > 250-ifeq ($(NOTRACE), 1) > 251-STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN > 252:OH323_SUFFIX = n > 253-else > > to > > 250-ifeq ($(NOTRACE), 1) > 251-STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN > 252:OH323_SUFFIX = _n > 253-else > > (underscore added @ 252 ) > > to keep the notrace suffix pretty. > > Regards. > > Francisco Olarte. >

1 0

Re: [h323plus] Incorrect include directive in h323caps.h
by Francisco Olarte (M) 11 Aug '10

11 Aug '10

Hi Jan. I'm copying to the list as it doesn't appear in my reply-to, maybe a gmail issue. On Wed, Aug 11, 2010 at 3:50 PM, Jan Willamowius <jan(a)willamowius.de> wrote: > Is there such a thing as an "installed H323Plus on Windows" ? I don't know, I abandoned it 8 years ago after having used it since win1.0 and left it for the smart people. Too complex for me, love the kernel, hate the ui. I assumed if one can install it in Linux, there must be a way to do it in windows too. > Re the other instances of codecs.h includes, it would be the easiest if > you would just post or mail me a "diff -u" and I'll put it into the CVS. Will do it, here is what I've found: folarte@gkaps ~/tmp/h323plus $ ack -C3 '#include.*"\.\./include/codecs.h"' . src/opalwavfile.cxx 70- 71-#include "opalwavfile.h" 72- 73:#include "../include/codecs.h" 74- 75- 76- src/opalvxml.cxx 138- 139-#endif 140- 141:#include "../include/codecs.h" 142- 143-#define G7231_SAMPLES_PER_BLOCK 240 144-#define G7231_BANDWIDTH (6300/100) src/codecs.cxx 395-#endif 396- 397-#ifdef _MSC_VER 398:#include "../include/codecs.h" 399-#else 400-#include "codecs.h" 401-#endif include/h323caps.h 293- 294- 295-#ifdef _MSC_VER 296:#include "../include/codecs.h" 297-#else 298-#include "codecs.h" 299-#endif And here are the diffs, emacs vc-diff, which seem like unified: *** opalvxml.cxx.~1.3.~ Fri Aug 21 06:35:47 2009 --- opalvxml.cxx Wed Aug 11 16:40:05 2010 *************** *** 138,144 **** --- 138,148 ---- #endif + #ifdef _MSC_VER #include "../include/codecs.h" + #else + #include "codecs.h" + #endif #define G7231_SAMPLES_PER_BLOCK 240 #define G7231_BANDWIDTH (6300/100) *** opalwavfile.cxx.~1.4.~ Thu Jul 9 17:11:12 2009 --- opalwavfile.cxx Wed Aug 11 16:40:05 2010 *************** *** 70,76 **** --- 70,80 ---- #include "opalwavfile.h" + #ifdef _MSC_VER #include "../include/codecs.h" + #else + #include "codecs.h" + #endif Did a quick test make and worked well. Hope this helps. Regards. Francisco Olarte.

2 1

aclocal path.
by Francisco Olarte (M) 11 Aug '10

11 Aug '10

I've made a little patch to plugins/configure from CVS: folarte@gkaps ~/tmp $ diff -u h323plus/plugins{/copia,}/configure --- h323plus/plugins/copia/configure 2010-05-23 19:38:35.000000000 +0200 +++ h323plus/plugins/configure 2010-08-11 16:14:19.757637819 +0200 @@ -1929,8 +1929,18 @@ if test \! -e ./aclocal.m4 ; then - echo "ERROR: you must first run 'aclocal' in $PWD" - exit + echo "aclocal.m4 not found in $PWD, running aclocal to make it." + if aclocal ; then + if test -e ./aclocal.m4 ; then + echo "aclocal.m4 generated." + else + echo "aclocal ran in $PWD but failed to generate aclocal.m4" + exit + fi + else + echo "ERROR running 'aclocal' in $PWD" + exit + fi fi This works ok for me, with or without configure.h ( although haven't manage to make aclocal fail ). Now configure does the right thing for me: === configuring in plugins (/home/folarte/tmp/h323plus/plugins) configure: running /bin/sh ./configure --disable-option-checking '--prefix=/usr/local' --cache-file=/dev/null --srcdir=. aclocal.m4 not found in /home/folarte/tmp/h323plus/plugins, running aclocal to make it. aclocal.m4 generated. checking for pkg-config... /usr/bin/pkg-config I tried to make it in configure.ac folarte@gkaps ~/tmp $ diff -u h323plus/plugins{/copia,}/configure.ac --- h323plus/plugins/copia/configure.ac 2010-05-24 00:28:58.000000000 +0200 +++ h323plus/plugins/configure.ac 2010-08-11 16:06:25.521660555 +0200 @@ -1,8 +1,18 @@ AC_INIT(configure.ac) if test \! -e ./aclocal.m4 ; then - echo "ERROR: you must first run 'aclocal' in $PWD" - exit + echo "aclocal.m4 not found in $PWD, running aclocal to make it." + if aclocal ; then + if test -e ./aclocal.m4 ; then + echo "aclocal.m4 generated." + else + echo "aclocal ran in $PWD but failed to generate aclocal.m4" + exit + fi + else + echo "ERROR running 'aclocal' in $PWD" + exit + fi fi PKG_PROG_PKG_CONFIG() But then If I run autoconf I get a vastly different configure folarte@gkaps ~/tmp/h323plus/plugins $ diff configure copia | wc 15890 73638 517210 Maybe because my autoconf is different? folarte@gkaps ~/tmp/h323plus/plugins $ head configure #! /bin/sh # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.65. # # # Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, # 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, # Inc. # # folarte@gkaps ~/tmp/h323plus/plugins $ head copia/configure #! /bin/sh # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.63. # # Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, # 2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. # This configure script is free software; the Free Software Foundation # gives unlimited permission to copy, distribute and modify it. ## --------------------- ## ## M4sh Initialization. ## These are my versions. folarte@gkaps ~/tmp/h323plus/plugins $ autoconf --version autoconf (GNU Autoconf) 2.65 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+/Autoconf: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David J. MacKenzie and Akim Demaille. folarte@gkaps ~/tmp/h323plus/plugins $ aclocal --version aclocal (GNU automake) 1.11.1 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Tom Tromey <tromey(a)redhat.com> and Alexandre Duret-Lutz <adl(a)gnu.org>. Hope this helps. Regards Francisco Olarte.

2 1

Configure problem?
by Francisco Olarte (M) 11 Aug '10

11 Aug '10

With a fresh CVS h323plus checkout configure emits ERROR: you must first run 'aclocal' in /home/folarte/tmp/h323plus/plugins It's trivial to solve, just '(cd plugins && aclocal)' solves it, but I wonder why I have this message. The log of what I did is at end. Regards. Francisco Olarte. --- LOG, PTlib 2.8.2 compiled & installed with prefix=$HOME, h323plus checked out from cvs ( OS is folarte@gkaps ~/tmp/h323plus $ export PTLIBDIR=~/src/ptlib-2.8.2 folarte@gkaps ~/tmp/h323plus $ export PWLIBDIR=$PTLIBDIR folarte@gkaps ~/tmp/h323plus $ ./configure --prefix=$HOME \ > --disable-h46018 \ > --disable-h46023 \ > --disable-mysql \ > --disable-pgsql \ > --disable-firebird \ > --disable-unixodbc \ > --disable-sqlite \ > --disable-radius checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes OpenH323 version is 1.22.0 checking for /home/folarte/src/ptlib-2.8.2/version.h... yes PTLib prefix set to.... /home/folarte/src/ptlib-2.8.2 checking Checking PTLib version 2.8.2... ok configure: Disabling H.350 configure: Disabling H.460.18/.19 configure: Disabling H.460.23/.24 configure: Enabling T.38 configure: Disabling GnuGk checking for a BSD-compatible install... /usr/bin/install -c configure: creating ./config.status config.status: creating openh323u.mak config.status: creating Makefile config.status: creating include/openh323buildopts.h === configuring in plugins (/home/folarte/tmp/h323plus/plugins) configure: running /bin/sh ./configure --disable-option-checking '--prefix=/home/folarte' '--disable-h46018' '--disable-h46023' '--disable-mysql' '--disable-pgsql' '--disable-firebird' '--disable-unixodbc' '--disable-sqlite' '--disable-radius' --cache-file=/dev/null --srcdir=. ERROR: you must first run 'aclocal' in /home/folarte/tmp/h323plus/plugins folarte@gkaps ~/tmp/h323plus $ uname -a Linux gkaps 2.6.34-gentoo-r1 #1 SMP Wed Jul 21 13:57:48 CEST 2010 x86_64 Intel(R) Xeon(R) CPU E5530 @ 2.40GHz GenuineIntel GNU/Linux folarte@gkaps ~/tmp/h323plus $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/python --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.3-r2 p1.2' Thread model: posix gcc version 4.4.3 (Gentoo 4.4.3-r2 p1.2)

2 2

Incorrect include directive in h323caps.h
by Francisco Olarte (M) 10 Aug '10

10 Aug '10

Trying to compile an app (yate3) with h323plus 2010-05-25 cvs ( from gnugk site ) I've got the following error: >>> In file included from /home/folarte/include/openh323/h323con.h:555, from /home/folarte/include/openh323/h323.h:492, from h323chan.cpp:32: /home/folarte/include/openh323/h323caps.h:289:31: error: ../include/codecs.h: No such file or directory <<< My setup is ptlib 2.8.2, 'configure --prefix=$HOME', make opt, make install. h323plus 2010-05-25 cvs, 'configure ..... --prefix=$HOME', make opt, make install. I end up having the following include directory: folarte@gkaps ~ $ ls -l ~/include total 44 drwxr-xr-x 8 folarte folarte 4096 Aug 10 18:12 openh323 -r--r--r-- 1 folarte folarte 23668 Aug 10 18:08 ptbuildopts.h drwxr-xr-x 2 folarte folarte 4096 Aug 10 18:08 ptclib drwxr-xr-x 3 folarte folarte 4096 Aug 10 18:08 ptlib -r--r--r-- 1 folarte folarte 4794 Aug 10 18:08 ptlib.h folarte@gkaps ~ $ find include -name h323caps.h -ls 1056359 104 -r--r--r-- 1 folarte folarte 105274 Aug 10 18:12 include/openh323/h323caps.h folarte@gkaps ~ $ find include -name codecs.h -ls 1056338 44 -r--r--r-- 1 folarte folarte 44804 Aug 10 18:12 include/openh323/codecs.h And the compilation command issued by yate seems correct: make[1]: Entering directory `/home/folarte/src/yate/modules' g++ -Wall -I.. -I.. -O2 -fno-check-new -fno-exceptions -fPIC -DHAVE_GCC_FORMAT_CHECK -finline -Winline -export-dynamic -shared -Wl,--unresolved-symbols=ignore-in-shared-libs -Wl,--retain-symbols-file,/dev/null -o h323chan.yate -DPHAS_TEMPLATES -D_REENTRANT -DP_HAS_SEMAPHORES -I/home/folarte/include/ptlib -I/home/folarte/include/openh323 h323chan.cpp -L/home/folarte/lib -lopenh323 -L/home/folarte/lib -lpt -L.. -lyate In file included from /home/folarte/include/openh323/h323con.h:555, from /home/folarte/include/openh323/h323.h:492, from h323chan.cpp:32: /home/folarte/include/openh323/h323caps.h:289:31: error: ../include/codecs.h: No such file or directory In file included from /home/folarte/include/openh323/channels.h:190, from /home/folarte/include/openh323/h323caps.h:290, from /home/folarte/include/openh323/h323con.h:555, from /home/folarte/include/openh323/h323.h:492, from h323chan.cpp:32: Browsing cvs for h323caps.c I've found: >>> Revision 1.15 - (view) (download) (as text) (annotate) - [select for diffs] Fri Aug 21 04:35:47 2009 UTC (11 months, 2 weeks ago) by shorne Branch: MAIN Changes since 1.14: +4 -1 lines Diff to previous 1.14 Expressly reference codecs.h to avoid problems with windows SDK codecs.h *** h323caps.h 2009/07/09 15:11:12 1.14 --- h323caps.h 2009/08/21 04:35:47 1.15 *************** *** 27,32 **** --- 27,35 ---- * Contributor(s): ______________________________________. * * $Log: h323caps.h,v $ + * Revision 1.15 2009/08/21 04:35:47 shorne + * Expressly reference codecs.h to avoid problems with windows SDK codecs.h + * * Revision 1.14 2009/07/09 15:11:12 shorne * Simplfied and standardised compiler directives * *************** *** 274,280 **** #endif ! #include "codecs.h" #include "channels.h" #include "mediafmt.h" --- 277,283 ---- #endif ! #include "../include/codecs.h" #include "channels.h" #include "mediafmt.h" <<<<<<<<< This may fix up problems in windows, but leads to a problem when using the installed version. During make phase in h323 headers are $BASE/h323plus/include, but they get installed to $PREFIX/include/openh323, and become incorrect. I don't know how to fix up these in windows, apart of renaming codecs.h to h323_codecs.h, but I thing reverting the fix should make it work again. Making a symbolic link: folarte@gkaps ~/include $ ln -s openh323 include folarte@gkaps ~/include $ ls -l include lrwxrwxrwx 1 folarte folarte 8 Aug 10 19:32 include -> openh323 Makes it work again ( note it includes properly, warns later on): make[1]: Entering directory `/home/folarte/src/yate/modules' g++ -Wall -I.. -I.. -O2 -fno-check-new -fno-exceptions -fPIC -DHAVE_GCC_FORMAT_CHECK -finline -Winline -export-dynamic -shared -Wl,--unresolved-symbols=ignore-in-shared-libs -Wl,--retain-symbols-file,/dev/null -o h323chan.yate -DPHAS_TEMPLATES -D_REENTRANT -DP_HAS_SEMAPHORES -I/home/folarte/include/ptlib -I/home/folarte/include/openh323 h323chan.cpp -L/home/folarte/lib -lopenh323 -L/home/folarte/lib -lpt -L.. -lyate In file included from /home/folarte/include/openh323/../include/codecs.h:345, from /home/folarte/include/openh323/h323caps.h:289, from /home/folarte/include/openh323/h323con.h:555, from /home/folarte/include/openh323/h323.h:492, from h323chan.cpp:32: /home/folarte/include/ptlib/ptlib/object.h: In member function 'virtual PBoolean<unnamed>::YateH323_ExternalRTPChannel::InternalIsDescendant(const char*) const': /home/folarte/include/ptlib/ptlib/object.h:1107: warning: inlining failed in call to 'virtual PBoolean PObject::InternalIsDescendant(const char*) const': call is unlikely and code size would grow /home/folarte/include/openh323/channels.h:248: warning: called from here but it's an horrible hack. Regards. Francisco Olarte.

3 3

Strange library names due to change in PTLIB macros.
by Francisco Olarte (M) 10 Aug '10

10 Aug '10

Due to some configure scripts hacking I've been trying to do I've noticed that both H323 plus and old openh323 generate library names (OH323_BASE, OH323_FILE) using from OBJ_SUFFIX via OH323_SUFFIX: >>>H323plus, cvs 20100525, openh323u.mak.in 248-endif # OH323_LIBDIR 249- 250-ifeq ($(NOTRACE), 1) 251-STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN 252:OH323_SUFFIX = n 253-else 254-STDCCFLAGS += -DPTRACING 255-RCFLAGS += -DPTRACING 256:OH323_SUFFIX = $(OBJ_SUFFIX) 257-endif # NOTRACE 258- 259:OH323_BASE = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE) 260-OH323_FILE = lib$(OH323_BASE).$(LIB_SUFFIX) 261- 262-LDFLAGS += -L$(OH323_LIBDIR) 263-LDLIBS := -l$(OH323_BASE) $(LDLIBS) <<< >>>/openh323_v1_19_0_1/openh323u.mak.in 212-endif # OH323_LIBDIR 213- 214-ifeq ($(NOTRACE), 1) 215-STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN 216:OH323_SUFFIX = n 217-else 218-STDCCFLAGS += -DPTRACING 219-RCFLAGS += -DPTRACING 220:OH323_SUFFIX = $(OBJ_SUFFIX) 221-endif # NOTRACE 222- 223:OH323_BASE = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE) 224-OH323_FILE = lib$(OH323_BASE).$(LIB_SUFFIX) 225- 226-LDFLAGS += -L$(OH323_LIBDIR) 227-LDLIBS := -l$(OH323_BASE) $(LDLIBS) <<< But the problem is while old pwlibs always had OBJ_SUFFIX as 'd' 'r' ( for debug/release ): >>>pwlib_v1_11_0/make/unix.mak 882- 883:ifndef OBJ_SUFFIX 884-ifdef DEBUG 885:OBJ_SUFFIX := d 886-else 887:OBJ_SUFFIX := r 888-endif # DEBUG 889:endif # OBJ_SUFFIX 890- 891-ifndef OBJDIR_SUFFIX 892:OBJDIR_SUFFIX = $(OBJ_SUFFIX) 893-endif <<< ptlib changed that in revision 20877 http://www.opalvoip.org/websvn/listing.php?repname=Opal&path=%2Fptlib%2Ftru… http://www.opalvoip.org/websvn/comp.php?repname=Opal&path=%2F&compare[]=%2F… from 'd'/'r' to '_d'/'' and ajusted it's paths acordingly, but h233plus did not, so the current paths end up being lrwxrwxrwx 1 gnugk gnugk 31 Aug 10 16:46 libh323_linux_x86_64_.so -> libh323_linux_x86_64_.so.1.22.0 lrwxrwxrwx 1 gnugk gnugk 31 Aug 10 16:46 libh323_linux_x86_64_.so.1 -> libh323_linux_x86_64_.so.1.22.0 lrwxrwxrwx 1 gnugk gnugk 31 Aug 10 16:46 libh323_linux_x86_64_.so.1.22 -> libh323_linux_x86_64_.so.1.22.0 -r--r--r-- 1 gnugk gnugk 10059909 Aug 10 16:46 libh323_linux_x86_64_.so.1.22.0 lrwxrwxrwx 1 gnugk gnugk 24 Aug 10 16:46 libopenh323.so -> libh323_linux_x86_64_.so This is only cosmetic ( it affects some makefiles I have which try to locate the _r names, but that's another story ), but maybe changing the names so the names are libh323_linux_x86_64.so / libh323_linux_x86_64_d.so instead of libh323_linux_x86_64_.so and libh323_linux_x86_64__d.so (double underscore in second ) is worthwile This could be done just by changing 259:OH323_BASE = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE) to 259:OH323_BASE = h323_$(PLATFORM_TYPE)$(OH323_SUFFIX)$(LIB_TYPE) ( underscore zapped between the two macros ) and will possibly need changing 250-ifeq ($(NOTRACE), 1) 251-STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN 252:OH323_SUFFIX = n 253-else to 250-ifeq ($(NOTRACE), 1) 251-STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN 252:OH323_SUFFIX = _n 253-else (underscore added @ 252 ) to keep the notrace suffix pretty. Regards. Francisco Olarte.

1 0

Memory leak in gkserver.cxx
by Francisco Olarte (M) 05 Aug '10

05 Aug '10

We've been working with and old version of openh233 which had a memory leak in H323GatekeeperServer::OnAdmission ( it was tested, we had call counters and noticed a call was leaked whenever we rejected it ). We are now trying to switch to h323plus, and I've noticed the memory leak still is in place, so I've subscribed to report it. The method in question is H323GatekeeperServer::OnAdmission. I've checked the issue in the last CVS version and it still persists. Below is a copy of the method with the ( working in many millions calls across last months ) fix we are using in our code in the middle. If it's neccessary I can try to make a patch, but I prefer to give this in context. >>>>>>>>>>>>>>>>> H323GatekeeperRequest::Response H323GatekeeperServer::OnAdmission(H323GatekeeperARQ & info) { PTRACE_BLOCK("H323GatekeeperServer::OnAdmission"); OpalGloballyUniqueID id = info.arq.m_callIdentifier.m_guid; if (id == NULL) { PTRACE(2, "RAS\tNo call identifier provided in ARQ!"); info.SetRejectReason(H225_AdmissionRejectReason::e_undefinedReason); return H323GatekeeperRequest::Reject; } H323GatekeeperRequest::Response response; PSafePtr<H323GatekeeperCall> oldCall = FindCall(id, info.arq.m_answerCall); if (oldCall != NULL) response = oldCall->OnAdmission(info); else { // If on restarted in thread, then don't create new call, should already // have had one created on the last pass through. if (!info.IsFastResponseRequired() && info.CanSendRIP()) { PTRACE(2, "RAS\tCall object disappeared after starting slow PDU handler thread!"); info.SetRejectReason(H225_AdmissionRejectReason::e_undefinedReason); return H323GatekeeperRequest::Reject; } ************************************************************ ***** Here newcall is allocated in a plain ptr. ************************************************************ H323GatekeeperCall * newCall = CreateCall(id, info.arq.m_answerCall ? H323GatekeeperCall::AnsweringCall : H323GatekeeperCall::OriginatingCall); PTRACE(3, "RAS\tCall created: " << *newCall); response = newCall->OnAdmission(info); ************************************************************ ******* This tracks the new call inside the endpoint WHEN NOT REJECTED ************************************************************ if (response != H323GatekeeperRequest::Reject) { mutex.Wait(); info.endpoint->AddCall(newCall); oldCall = activeCalls.Append(newCall); if (activeCalls.GetSize() > peakCalls) peakCalls = activeCalls.GetSize(); totalCalls++; PTRACE(2, "RAS\tAdded new call (total=" << activeCalls.GetSize() << ") " << *newCall); mutex.Signal(); AddCall(oldCall); } } ************************************************************ ******* But call is leaked when rejected, we fixed it using: ************************************************************ else { PTRACE(2,"RAS\tDeleting rejected call: "<<*newCall); delete newCall; } ************************************************************ ***** ***** I've traced code path to my best and think newcall cannot ***** be deleted by onAdmission, and our code has not got any ***** double-delete, but we discovered this in final testing ***** and using a H323GatekeeperCall derived call class ( ***** which counts instances, that is how we discovered it ). ***** ****** End of comments/modifications. ************************************************************ #ifdef H323_H248 switch (response) { case H323GatekeeperRequest::Confirm : if (oldCall->AddCallCreditServiceControl(info.acf.m_serviceControl)) info.acf.IncludeOptionalField(H225_AdmissionConfirm::e_serviceControl); break; case H323GatekeeperRequest::Reject : if (oldCall != NULL && oldCall->AddCallCreditServiceControl(info.arj.m_serviceControl)) info.arj.IncludeOptionalField(H225_AdmissionReject::e_serviceControl); break; default : break; } #endif return response; } <<<<<<<<<<<<<<<<<<<<< Regards. Francisco Olarte.

3 6

Re: [h323plus] H264 PLUGIN In H323Plus
by kc ooi 23 Jul '10

23 Jul '10

Hi All, Currently, I am working on H.264 codec to limit it's maximum video rate always less than 256kbps. I use the settings as below: ---------------------------------------- Profile: baseline profile Level: 1.2 resolution: CIF resolution frame rate: 10fps. However, In the H.264 Recommendation, the level 1.2 has default value maximum bit rate with 384kbps. So, anyway to customize my H.264 codec (or do setting on my x264 encoder) to produce the video size always less than 256kbit / sec. Thanks.

3 2

Gnugk Proxy Mode don't complete call....
by leandro.alvares＠caixa.gov.br 22 Jul '10

22 Jul '10

Hi, <<gnugk.ini>> <<tcpdump.tandberg.eth1>> <<tcpdump.tandberg.eth0>> I've got the latest CVS version to test GnuGK in Proxy mode. I'm not getting the video when a PVX from Intranet call to Tandberg at Internet. The Tandberg 990 MXP is registered at GnuGK in Intranet. The firewall ports are opened, and I can call from PVX to PVX, it works fine. The GnuGK (proxy) has two network interfaces, the eth0 is at Intranet, and the eth1 is a NAT to Internet IP. The eth1 has the same "A class" 10.x.x.x Tanderg ---- GnuGK ------ PVX The call follow this sequence: Admission request - both Admission confirmation - both Q931 setup send - both Q931 setup received - both The PVX call to Tandberg normally, and when I answer the Tandberg call, I get a black screen and after 5 seconds the call is cleared. At logs I can see: Normal call clearing and Normal Drop.... I really don't know what is happening, because I can't see the errors at log. I've attached the Wireshark logs and the Gnugk... Any help will be appreciated a lot !!!!! Thanks a lot Best regards, Leandro

1 0