- h323plus - lists.packetizer.com

Problem compiling h323plus 1.21.0
by alvaro muniz 22 Oct '10

22 Oct '10

Hi, I just download ptlib 2.4.5, h323plus 1.21.0 and openmcu 2.2.5. When i try to compile h323plus using make install, it fail, because /bin/install try to find libh323_linux_x86_.so.1.21.0, but in the lib folders it find libh323_linux_x86_.so.1.21.beta0. How i solve this issue? I download the right version? http://www.h323plus.org/source/ Im working on ubuntu 10.10 Thank you so much Alvaro

1 0

Call Tracing && XER ???
by Alex Katebi 26 Aug '10

26 Aug '10

Hello, I need trace calls for debugging. What are the options available for doing this? I know how to get PTRACE but I need something that is specific to a call. I was wondering that if I can get XER encoding and then filter for a call. Anyone can tell me how to get XER encoding for the OpenH323? Thanks, Alex

2 1

h323plus 1.22, ptlib 2.8.2, openmcu 2.2.5 - can't get H.263 to load
by Dave Smulsky 26 Aug '10

26 Aug '10

I am having a terrible time trying to get basic H.263/264 plugins working on a vanilla Ubuntu 10.04 install. I installed ffmpeg, libavcodec-devel, x264, libx264-devel from ubuntu repos Compiled PTlib 2.8.2, set PTLIBDIR, compilied h323plus 1.22, set OPEN323DIR, configured and make installed h323plus/plugins (showed all the codecs as enabled), set PTLIBPLUGINDIR to the OPENH323DIR/plugins. Compiled openmcu 2.2.5 without issues... When I run openmcu, right out of the box H.261 and H.264 are enabled, but if I try to connect an endpoint (using Ekiga) it segfaults openmcu. If I disable h.264 via openmcu.ini, restart openmcu, I can connect an endpoint at H.261 CIF (which is terrible resolution and pretty much useless to me. The problem is I cant seem to get H.263 to load at all. Can someone that has had good results setting this up please shed some light on how to do it on a more recent OS like Ubuntu 10.04 or even RHEL5? Thanks Dave

4 13

h.239 improvements
by Marek Domaracky 26 Aug '10

26 Aug '10

Hi, in the attachment, you can find the patch to improve H.239 support. It includes patch from Igor Pavlov, which add possibility to open H.239 session to the H.323 device. It also includes also some of my changes concerning the sending order of the messages ... So far I tested to open H.239 session both ways with the Tandberg MXP and with the Mirial. But with Mirial I manage to open only from Mirial to my application as the other way I'm getting "ERROR Open Channel. No Remote Support". I will check that. Thanks, Marek

3 5

Building opal and ptlib
by Alex Katebi 20 Aug '10

20 Aug '10

Hi Everybody, I just downloaded the last opal and ptlib into my Ubuntu 10.04 Linux machine. I followed the build instructions but I could not get a build. Can someone share with me a working build instructions. Much appreciated! Thanks, Alex

2 1

gnugk + openMCU - reject call
by leandro.alvares＠caixa.gov.br 19 Aug '10

19 Aug '10

Hi, Some of my endpoints are rejected when try to connect to OpenMCU. The message is: call reject... Can someone identify what is happen, I really don't know... Thanks a lot. 2010/08/19 15:01:06.632 2 RasTbl.cxx(3816) CDR ignore not connected call 2010/08/19 15:01:06.632 2 gkacct.cxx(1094) GKACCT Successfully logged event 2 for call no. 842 2010/08/19 15:01:06.648 2 RasSrv.cxx(175) RAS Read from 10.224.16.30:1719 2010/08/19 15:01:06.648 3 RasSrv.cxx(224) RAS disengageRequest { requestSeqNum = 19252 endpointIdentifier = 9 characters { 0037 0032 0030 0031 005f 0065 006e 0064 7201_end 0070 p } conferenceID = 16 octets { 02 87 73 27 65 00 00 10 28 e3 56 34 34 34 34 ef ..s'e...(.V4444. } callReferenceValue = 4681 disengageReason = normalDrop <<null>> callIdentifier = { guid = 16 octets { 02 87 73 27 65 00 00 10 28 e2 56 34 34 34 34 ef ..s'e...(.V4444. } } gatekeeperIdentifier = 7 characters { 0047 006e 0075 0047 004b 0030 0032 GnuGK02 } answeredCall = false } 2010/08/19 15:01:06.649 1 RasSrv.cxx(354) RAS DRQ Received from 10.224.16.30:1719 2010/08/19 15:01:06.649 2 RasSrv.cxx(394) DCF|10.224.16.30|7201_endp|4681|normalDrop|02-87-73-27-65-00-00-10-28-e2 -56-34-34-34-34-ef; 2010/08/19 15:01:06.649 3 RasSrv.cxx(236) RAS Send to 10.224.16.30:1719 disengageConfirm { requestSeqNum = 19252 } 2010/08/19 15:01:06.690 2 RasSrv.cxx(175) RAS Read from 10.192.37.69:32813 2010/08/19 15:01:06.690 3 RasSrv.cxx(224) RAS disengageRequest { requestSeqNum = 64400 endpointIdentifier = 9 characters { 0033 0030 0032 0034 005f 0065 006e 0064 3024_end 0070 p } conferenceID = 16 octets { 02 87 73 27 65 00 00 10 28 e3 56 34 34 34 34 ef ..s'e...(.V4444. } callReferenceValue = 4681 disengageReason = normalDrop <<null>> callIdentifier = { guid = 16 octets { 02 87 73 27 65 00 00 10 28 e2 56 34 34 34 34 ef ..s'e...(.V4444. } } gatekeeperIdentifier = 7 characters { 0047 006e 0075 0047 004b 0030 0032 GnuGK02 } answeredCall = true usageInformation = { nonStandardUsageFields = 0 entries { } connectTime = 1282241673 endTime = 1282241673 } terminationCause = releaseCompleteCauseIE 2 octets { 80 80 .. } } 2010/08/19 15:01:06.690 1 RasSrv.cxx(354) RAS DRQ Received from 10.192.37.69:32813 2010/08/19 15:01:06.690 2 RasSrv.cxx(394) DCF|10.192.37.69|3024_endp|4681|normalDrop|02-87-73-27-65-00-00-10-28-e2 -56-34-34-34-34-ef; 2010/08/19 15:01:06.690 3 RasSrv.cxx(236) RAS Send to 10.192.37.69:32813 disengageConfirm { requestSeqNum = 64400 } 2010/08/19 15:01:06.844 3 ProxyChannel.cxx(713) Q931s ignoring empty TPKT from 10.242.40.60:3233 (keep-alive) 2010/08/19 15:01:06.844 3 ProxyChannel.cxx(713) H245d ignoring empty TPKT from 10.242.40.60:3235 (keep-alive) 2010/08/19 15:01:07.555 2 RasSrv.cxx(175) RAS Read from 10.0.71.9:1719 2010/08/19 15:01:07.555 3 RasSrv.cxx(224) RAS

2 1

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