December 2013 - h323plus - lists.packetizer.com

H.235 sample
by Cláudio Palludetti 22 Jan '14

22 Jan '14

Hi, We are developing an H.323 EP and we need to use the H.235. Is there any example using this? We are using h323plus V1.24.0 and we enabled the H.235. Thanks Claudio

4 7

Compilation issue
by Diego Carvalho 30 Dec '13

30 Dec '13

Hi All, I'd like to report what I think is an issue. If you compile H323Plus after running configure without any option you will get this warning: [CC] /home/diego/Edifire/Quartz/3rdParty/h323plus/src/h460/h460_std18.cxx /home/diego/Edifire/Quartz/3rdParty/h323plus/src/h460/h460_std18.cxx:54:2: warning: #warning ("H.460.18/.19 Enabled. See Tandberg Patent License. http://www.tandberg.com/collateral/tandberg-ITU-license.pdf") [-Wcpp] [CC] /home/diego/Edifire/Quartz/3rdParty/h323plus/src/h460/h46018_h225.cxx [CC] /home/diego/Edifire/Quartz/3rdParty/h323plus/src/h460/h460_std23.cxx /home/diego/Edifire/Quartz/3rdParty/h323plus/src/h460/h460_std23.cxx:59:2: warning: #warning ("H.460.23/.24 Enabled. Contact consulting(a)h323plus.orgfor licensing terms.") [-Wcpp] Since I don't use H.460, I tried to disable the series that are generating the issues, that is .18/.19 and .23/.24 by running "./configure --disable-h46018 --disable-h46023" but I got the following error: h323.cxx: In member function ‘void H323Connection::DisableNATSupport()’: h323.cxx:2642:30: error: ‘IsH46019Multiplexed’ was not declared in this scope If I disable the entire H.460 support by running "./configure --disable-h460" it compiles successfully and without the warnings I wanted to omit. So that's fine for me but I think there is a bug in the code that is causing this compilation issue. In h323.cxx, around line 2642, the code is: void H323Connection::DisableNATSupport() { #if H323_H460 if (!IsH46019Multiplexed()) #endif NATsupport = false; remoteIsNAT = false; } I think it should be #if H323_H46018 (or both H323_H46018 and H323_H46019M). This is just a guess since I'm not an expert in the H323Plus code. And sorry if this issue was caused by some mistake in my configuration. Best regards.

2 1

Re: [h323plus] [Opalvoip-devel] Unresolved error - PIPSocket::Close
by Simon Horne 28 Dec '13

28 Dec '13

Josh This is really a h323plus question. I have CC'd that list. I am currently working through updating both h323plus and GnuGk compiling with the ever moving target that is PTLIB head. You should really try to work with the latest stable 2.12.x. I will advise via the h323plus list when the issue is resolved. Simon From: J.C Mercier [mailto:jcmerc5@gmail.com] Sent: 28 December 2013 14:45 To: opal Subject: [Opalvoip-devel] Unresolved error - PIPSocket::Close Good day Opal team, I get the following errors when i compile a simple application derived from the H323plus sample application; ------ Error 6 error LNK2019: unresolved external symbol "public: virtual bool __thiscall PIPSocket::Close(void)" (?Close@PIPSocket@@UAE_NXZ) referenced in function "public: virtual bool __thiscall H46019MultiplexSocket::Close(void)" (?Close@H46019MultiplexSocket@@UAE_NXZ) ..\h323plusd.lib(h46018_h225.obj) Error 7 error LNK2001: unresolved external symbol "public: virtual bool __thiscall PIPSocket::Close(void)" (?Close@PIPSocket@@UAE_NXZ) ..\h323plusd.lib(rtp.obj) Error 8 error LNK2001: unresolved external symbol "public: virtual bool __thiscall PIPSocket::Close(void)" (?Close@PIPSocket@@UAE_NXZ) ..\h323plusd.lib(h460_std26.obj) Error 9 error LNK2001: unresolved external symbol "public: virtual bool __thiscall PIPSocket::Close(void)" (?Close@PIPSocket@@UAE_NXZ) ..\h323plusd.lib(gnugknat.obj) ----- I'm using the latest head version of both ptlib and h323plust. When tracing the error, i came upon the following code snippet in winsock.cxx; ---- #if P_QWAVE PBoolean PIPSocket::Close() { if (IsOpen() && PWinSock::GetInstance().m_hQoS != NULL && m_qosFlowId != 0) { QOSRemoveSocketFromFlow(PWinSock::GetInstance().m_hQoS, os_handle, m_qosFlowId, 0); m_qosFlowId = 0; } return PSocket::Close(); } #endif // P_QWAV ------ I managed to find the PIPSocket class in ipsock.h and it had no definition of the 'Close' function. I even looked in the PSocket class from which PIPSocket is derived from and I didn't see any definition of the 'Close' function in there either except in the PChannel class. The first error is due to the following code from h323plus; PBoolean H46019MultiplexSocket::Close() { if (m_subSocket) return m_subSocket->Close(); return PUDPSocket::Close(); } Where H46019MultiplexSocket is basically derived from PUDPSocket and so forth. I'm just curious to know if there's something that i've missed or that i may be looking in the wrong places. I'm working with Win7 VS 2013 Express edition. Much appreciate your help. Thanks, Josh

2 1

Re: [h323plus] [Openh323gk-users] Config changes in the upcoming GnuGk 3.5
by Simon Horne 16 Dec '13

16 Dec '13

Just to add. H.460.22 has been added to GnuGk to allow H.323 devices to negotiate when to use TLS. There has been a flurry of commits in h323plus CVS over the last few days to support the security features for GnuGk 3.5. GnuGk and H323plus now support TLS with H.460.22 negotiation and AES256 media encryption up to 8192bits (8k). H.460.17 has also been updated to support TLS so Registration, Call signaling and tunneled media (H.460.26) can now be carried over a single persistent TLS connection. The simple application in the samples directory in the h323plus CVS has been update and can be used to test the new functionality. Simon -----Original Message----- From: Jan Willamowius [mailto:jan@willamowius.de] Sent: 16 December 2013 22:13 To: openh323gk-users(a)lists.sourceforge.net Subject: [Openh323gk-users] Config changes in the upcoming GnuGk 3.5 Hi, usually I try hard to keep every new GnuGk version configuration compatible with all previous versions, so you can simply drop in new versions. I'll try to keep it that way, but version 3.5 will have a few changes that might require a config update for a few people. - The default for the call signal port will change from 1721 to 1720. If you already have the CallSignalPort= switch in your config, you are all set. If not, you should add it now. - GnuGk 3.5 will have a very high standard for the TLS ciphers it accepts. Especially if you were signing your certs using a SHA1 hash, you should consider using certs with SHA256 now or downgrade GnuGk's security settings with the [TLS] CipherList= switch. - If you are using GnuGk to add RTP encryption to your calls, the H235HalfCallMediaStrength= switch has been replaced with the H235HalfCallMaxTokenLength= switch so you can not only choose between AES128 and AES256, but also which DH token length you want. Depending on how H323Plus was compiled, GnuGk will now support up to 8K DH keys according to the new version of H.235.6 that just being agreed on in the ITU. As you might have guessed from this post version 3.5 is close, so if you have any pending issues with GnuGk, let us know, so we can get them fixed for 3.5. Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan(a)willamowius.de Website: http://www.gnugk.org Support: http://www.willamowius.com/gnugk-support.html Relaxed Communications GmbH Frahmredder 91 22393 Hamburg Geschäftsführer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584 ---------------------------------------------------------------------------- -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________________ Posting: mailto:Openh323gk-users@lists.sourceforge.net Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/

1 0

ptlib 2.10.9 fortify source patch for linux.
by Francisco Olarte 09 Dec '13

09 Dec '13

I've tested the attached patch for the ptlib problem I encountered ( https://sourceforge.net/p/opalvoip/bugs/496/ ) . I've tested it, found it working, and I am currently running it on production, happily going on with >2400 open files. When the next version of h323plus is released and ptlib version recomended for it is determined I will port it again and republish. Currently the patch applies cleanly to ptlib 2.12.8 too: ~/tmp/ptlib-2.12.8$ patch -p1 -i ../ptlib-2.10.9-fortify-source-fd-set.patch patching file include/ptlib/socket.h Hunk #1 succeeded at 555 (offset 80 lines). patching file src/ptlib/common/sockets.cxx Hunk #1 succeeded at 766 (offset -16 lines). patching file src/ptlib/msos/winsock.cxx Hunk #1 succeeded at 155 (offset 40 lines). Hunk #2 succeeded at 174 (offset 40 lines). patching file src/ptlib/unix/socket.cxx Hunk #1 succeeded at 130 (offset 13 lines). And also to the trunk: ~/tmp/ptlib-trunk$ patch -p1 -i ../ptlib-2.10.9-fortify-source-fd-set.patch patching file include/ptlib/socket.h Hunk #1 succeeded at 555 (offset 80 lines). patching file src/ptlib/common/sockets.cxx Hunk #1 succeeded at 774 (offset -8 lines). patching file src/ptlib/msos/winsock.cxx Hunk #1 succeeded at 155 (offset 40 lines). Hunk #2 succeeded at 174 (offset 40 lines). patching file src/ptlib/unix/socket.cxx Hunk #1 succeeded at 141 (offset 24 lines). although presently I have not got the resources to test it. Francisco Olarte.

1 0

PTLIb / FORTIFY_SOURCE problems.
by Francisco Olarte 05 Dec '13

05 Dec '13

I've hit a problem with PTlib 2.10.9 / h323plus 1.25.0 which surfaces on linux glibc systems in which FORTIFY_SOURCE enables checking fd < FD_SETSIZE on FD_SET/CLR/ISSET. It manifest itselfs as an immediate core dump when using high fds ( as I'm working with a yate instance translating h323-sip which uses about 15-16 handles per call, which made me raise open file limit to 8k, I cannot go above 60 calls ). I've reported it to ptlib developers ( https://sourceforge.net/p/opalvoip/bugs/496/ ) and developed a patch against ptlib to try to make it work. I'm presently preparing load tests for it. As h323plus uses this ptlib version ( and normally release version has problem with more recent ones ) and I've verified the same code is present in ptlibs trunk head, I wonder if I should send the patch when it's being tested to some place where it can be located and used by interested h323plus users ( it applies cleanly to ptlib 2.10.9 ). Any idea? Regards. Francisco Olarte.

2 1