- h323plus - lists.packetizer.com

Simpleh323 H239 Issue
by Ankur Deep Jaiswal 25 Feb '14

25 Feb '14

HI, While using H239 in simpleh323 client using connection->OpenH239Channel(). Simpleh323 sends a presentationTokenRequest and after receiving a presentationTokenResponse, replies with a new presentationTokenResponse with indication that functionNotUnderstood. hence H239 fails. Help appreciated. thanks in advance -- Ankur Deep Jaiswal

2 2

GnuGk turns 15, lets discuss where to take it from here
by Jan Willamowius 17 Feb '14

17 Feb '14

Dear community, this year the GNU Gatekeeper will turn 15 (I did the first release on June 29th 1999). Lets discuss where we should take it from here. I have prepared an anniversary survey with a number of questions on gatekeeper features, security and WebRTC etc. (1 page): http://www.gnugk.org/survey-2014.html Of course you can also chime in here on the mailinglist. (Why is it so quiet here lately ?) 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

1 0

Some issues with h323pdu.cxx
by Denis Kochmashev 14 Feb '14

14 Feb '14

Hello! Please correct me if I'm wrong, but 1. It looks like there is a small mistake in h323pdu.cxx which doesn't allow to build h323plus without H.235 being enabled. 2. I've found that 'H323SetAliasAddress(const PString & _name, H225_AliasAddress & alias, int tag)' doesn't allow to set AliasAddress of type h323_ID if it looks like dialedDigits even if _name begins with 'h323:'. For example, if I specify _name = 'h323:12345', alias tag will all the same be dialedDigits because it looks like them. I suggest a small change to H323SetAliasAddress, because now it produces unpredictable results. Thanks, Denis

2 7

H323Plus 1.26.0 Released
by Simon Horne 28 Jan '14

28 Jan '14

Guys H323plus v1.26.0 has been released. The source code for both h323plus v1.26.0 and PTLIB 2.12.8 is available from both the h323plus and sourceforge website. The API documentation link on the website has also been updated. ChangeLog ================================================================== Added H323_MEDIAENCODED compile directive to support external media decode/encode Added Encryption support to the H.224 Channel and H323_ExternalRTPChannel Performance Memory management Improvement in audio/video processing. Updated to compile with PTLIB Head (1.25.5) Added Language assignment and routing support Added TLS signalling support Added DH6144 and DH8192 H.235 Support (support for keylength up to 8192 bits) Added H.460.22 Support Added vs2012 Build environment Fixed vs2010 Build environment Added H.461 Asset Support. (1.25.4) Update and fixes for H.460.26 (1.25.3) Update Presence System to Version 3. (1.25.2) Update Alternate and Assigned Gatekeeper code. Removing buggy pointers Added H.224 Factory loader moved to H224 subdirectory Added T.140 Support Added H.284 <New> far end motor control add support for <ip>##<room>#<pass> dialing Simon

1 0

Upcoming new h323plus 1.26 Release
by Simon Horne 26 Jan '14

26 Jan '14

Guys It's been a while since the last release so it is time to think about a new release. There has been a lot of activity over the last couple of months in the CVS. The build system has been updated and should now build against any version of PTLIB including the current HEAD. However it is recommended that you stick to either 2.10 or the latest public 2.12 release version. A lot of work has been done in signaling and media encryption including adding TLS support and incorporating the updated H.235 spec to support AES256 with large key lengths (up to 8096 bits), H.460.22 support to negotiate when to use TLS and media encryption of the data channel. H.460.26 support has been added and when used in conjunction with H.460.17 allows tunneling of RAS, Signalling and media over a single persistent TCP connection. If using TLS, the h323plus stack will now allow traversal of any secure NAT over a single TLS connection on trusted port such as 443. The matching Gatekeeper support is in GnuGk v3.5. What's new in the upcoming release. ------------------------------------------------ Added TLS signaling support Added H.460.22 Support to negotiate TLS support on a per call basis. Added Encryption support to the H.224 Channel and H323_ExternalRTPChannel Added DH6144 and DH8192 H.235 Support (support for keylength up to 8192 bits) Performance Memory management Improvement in audio/video processing. Updated to compile with PTLIB Head Added Language assignment and routing support Added vs2012 Build environment Fixed vs2010 Build environment Added H.461 Asset Support. Update and fixes for H.460.26 Update Presence System to Version 3 Update Alternate and Assigned Gatekeeper code. Removing buggy pointers Added H.224 Factory loader moved to H224 subdirectory Added T.140 Support Added H.284 <New> far end motorized control add support for <ip>##<room>#<pass> dialing Along with the release there will be updated documentation. Again Special thanks to Jan Willamowius and Yuriy Georgiewskiy for their continued help and support of the project. If anyone finds bugs then please report them ASAP so we can capture them in the next release. Simon

2 1

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

23 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

Old Documentation Link
by Diego Carvalho 10 Jan '14

10 Jan '14

Hi All, If you go to the official website (http://www.h323plus.org/) then click in "Source Code", and then in "API Guide" you will be redirected to http://www.h323plus.org/api/v1_19_5/main.html that's the documentation for version 1.19.5, an old version. If possible, updating it to the current version would be great. Thanks in advance.

1 0

GNU Gatekeeper 3.5 released
by Jan Willamowius 02 Jan '14

02 Jan '14

Dear community, I'm happy to announce the release of GNU Gatekeeper version 3.5. The new version brings a number of new features as well as a number of important bug fixes and a few changes in configuration options. As usual, you can download the source code and executable for Linux, Windows, FreeBSD, OpenBSD, NetBSD and Solaris from http://www.gnugk.org/h323download.html Regards, Jan New features: - implement H.460.22 to negotiate the use of TLS - language based routing (using the upcoming H.323v8) - new command line switch -mlock to prevent GnuGk from being swapped out - new section [ModeVendorSelection] to set proxy mode based on endpoint vendor support for challenge/response authentication using DES-ECB, eg. from Avaya endpoints - new switch [RoutedMode] FilterEmptyFacility= (Avaya interop) - new switch [RoutedMode] ProxyHandlerHighPrio=0 to avoid setting the proxy handler to high priority; needed to run GnuGk on certain virtualization platforms - print number of proxied calls and peak number of calls in statistics on status port - new switch [RoutedMode] H46023ForceNat - new switch [RewriteSourceAddress] TreatNumberURIDialedDigits - more detailed codec descriptions in %{codec} and Radius attribute - process multiple terminal-alias VSA from Radius - extend [GkStatus::Message] for URQ Configuration changes: - changed default call signaling port from 1721 to 1720 - replace H235HalfCallMediaStrength= switch with H235HalfCallMaxTokenLength= - disable use of SHA1 for TLS by default, the new switch [TLS] CipherList= can be used to customize the cipher selection And a number of bug fixes (see changes.txt for all the details). -- Jan Willamowius, Founder of the GNU Gatekeeper Project 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

1 0

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

My test results.
by Francisco Olarte 16 Nov '13

16 Nov '13

Well, after the exchanges regarding gkclient, and although the results are all the expected for this simple patches, I'll summarise my tests in case they are useful for anyone. I've done and tested this things to avoid my gkerver/gkclient problems. I expected no problems, and did not find any. 1.- Roll back 1.23&24 in gkclient.cxx against h323plus v1.25, basically unconditionallizing again the only endpointIdentifier assignement. All tests ok, as this leaves v1.25 behaving more or less like v1.24 2.- Apply the 1.48 in gkclient.cxx against v1.25, making it clear the endpoint identifier on full registration required. All tests ok again. This is the one I'll stick to while waiting for v1.26, as I expect to be able to get rid of it in the future. 3.- Both 1 and 2. I knew they are redundant but wanted to assert they worked in the test setup, all good again. Also I modified my gatekeeper as I posted to make it conditionally accept the endpoint identifier passed from the endpoint. All tests above worked with and without accepting endpoint identifiers. I'll keep this patch in case I encounter and endpoint with the unpatched v1.25 behaviour, as some of my endpoints are closed source. Bear in mind all tests are done in a simple scenario of a single ras only gatekeeper with endpoints registered on it, rebooting endpoints and gatekeeper in the middle. Francisco Olarte.

1 0

SonicWall/Dell wreck of a NAT
by Marek Podgorny 15 Nov '13

15 Nov '13

I have a problem with firewall that I cannot replace or reconfigure. The FW is a SonicWall, public IP on Internet side (of course), NAT on the LAN side, gatekeeper on a public address outside FW. Calls from EPs on NAT to outside world work but incoming calls fail. I wiresharked the traffic and found that the Q.931 setup ServiceControlIndication packet bounces from the FW. The reason for this is that while this particular packet is sent to UDP port previously used by the NATed EP RRQ, the FW fails to preserve NAT mapping table. SonicWall also ignores port preservation setting. Astonishingly, bi-directional access to UDP port 1719 works (SonicWall claims to support H.323 and it is possible to "activate" it. Maybe port 1719 becomes special). Therefore, here is my question: Is it possible to order H323Plus to only use outgoing UDP port 1719 for RAS signalling? Marek Podgorny +1 315 373-6345 >

2 3

Repository conversion
by Francisco Olarte 14 Nov '13

14 Nov '13

Hello everybody. After getting frustated with MY inability to view 'changesets' in the CVS repository for h323plus I decided to give cvs2svn a try, just to see how it came out. I've done a rsync dump of the 59Mb cvs repo at sourceforce and did a plain 'cvs2svn --encoding=latin_1', which seems seems to came out nicely. I can to be comming out nicely, it generated a trunk, a pboolean branch and several tags: ~/conv$ svn list file:///home/folarte/conv/h323plus-svn/branches pboolean/ ~/conv$ svn list file:///home/folarte/conv/h323plus-svn/tags plus_1_20/ v04/ v1_19_5/ v1_19_6/ v1_19_7/ v1_20_0/ v1_20_1/ v1_20_2/ v1_21_0/ v1_22_0/ v1_23/ v1_24_0/ v1_25_0/ ~/conv$ svn list file:///home/folarte/conv/h323plus-svn/trunk CVSROOT/ applications/ extensions/ h323plus/ As it is it serves my needs ( helping me see related files for backporting things into releases, and given the time it took I can ), but, as I think developers must be somehow familiar with subversion, ( as ptlib and lots of other projects use it ) I wonder if someone will be interested in converting the main repo. In this case I can try to build and tune a conversion script for better processing of things like the CVSROOT scripts and build a svn dump which could be tested and, if desired, imported. Francisco Olarte

3 2

gkserver does not use received endpoint identifier.
by Francisco Olarte 13 Nov '13

13 Nov '13

Some hours ago I've reported what I thought, and still think, is a bug in the treatement of endpoint identifiers on received RCF in gkclient.cxx. As the gatekeeper which is having problems with them is one of mine, which is derived from gkserver.cxx, I decided to investigate further. I tried to look at what gnugk does in it's sources, and it seems it uses the received endpoint identifier and thus avoids this problem, but I've not been able to totally verify it. But looking at gkserver.cxx, which I know a little better, I've noticed that the first time it receives a keepalive after a reboot it does not know the endpoint, so it requests a full registration, so far so good. Then when the new full registration arrives OnFullRegistration ends up doing // Need to create a new endpoint object info.endpoint = CreateRegisteredEndPoint(info); Which leads to: H323RegisteredEndPoint * H323GatekeeperServer::CreateRegisteredEndPoint(H323GatekeeperRRQ &) { return new H323RegisteredEndPoint(*this, CreateEndPointIdentifier()); } If this method is changed to something like: return new H323RegisteredEndPoint(*this, info.rrq.HasOptionalField(H225_RegistrationRequest::e_endpointIdentifier) ? info.rrq.m_endpointIdentifier : CreateEndPointIdentifier() ); My Gatekeeper ( and any gatekeeper built using h323plus gkserver ) will accept this kind of behaviour ( ie, where the endpoint DOES NOT USE the endpoint id received in the RCF as I think it should do ) ( in the line of be strict in what you send and tolerant in what you accept ). Does this seem correct? If so I can send make a send a patch for this ( basically, the above line after testing ). Francisco Olarte.

3 2

Previous bug report...
by Francisco Olarte 13 Nov '13

13 Nov '13

Hello everyone. In my previous mail I blamed my problems on commit http://h323plus.cvs.sourceforge.net/viewvc/h323plus/h323plus/src/gkclient.c… while it seems is due to a combination of that and the previous one: http://h323plus.cvs.sourceforge.net/viewvc/h323plus/h323plus/src/gkclient.c… It seem the endpointdidentifier assignement was removed in the 1.23 rev ( although the comment talks about gatekeeper identifier ) and reinstated conditionalized in 1.24 ( which comment i do not fully understand, seems like a partial revert of the previous one ). Regards. Francisco Olarte

3 3

Gkclient problem ( regression ) in h233plus 1.25
by Francisco Olarte 12 Nov '13

12 Nov '13

Hi everybody. I think h323plus gkclient.cxx does not correctly process reregistration after a gatekeeper reboot in 1.25. My scenario is the following. We have several h323 endpoint programs ( yate instances and homebrew ones ) registered to a gatekeeper. As part of a scheduled maintenance ew rebooted the gatekeeper. Every endpoint compiled against h323plus 1.24 reregisterd correctly and kept working, but a single one compiled with h323plus 1.25 ( and part of the maintenance is upgrading to 1.25 ) did not. The problem was the endpoint sent a keepalive RRQ with the old gatekeeper data. The new gk instance replied with an RRJ with a full registration required cause. The endpoint sent a full registration, the gatekeeper replied with a RCF with a NEW ENDPOINT IDENTIFIER. All the 1.24 programs then proceeded to send the new Ep Id, but the 1.25 one kept sending the old ones. I suspect it also sends it in ARQs, so it was unable to call ( will verify it later ). I've been debugging the source code and didn't notice any difference in the clients, so I looked at the 1.25-1.24 diffs, in gkclient.cxx http://h323plus.cvs.sourceforge.net/viewvc/h323plus/h323plus/src/gkclient.c… I noticed a difference in endpoint identifier handling, which I narrowed to this commit: http://h323plus.cvs.sourceforge.net/viewvc/h323plus/h323plus/src/gkclient.c… which does not store a new endpoint indentifer from an rrq if one is set, but does not do further tests, and seems to be what is causing my problem. I assume there is a reason for not storing the new endpoint identifier, but I think it should at least be checked. Also I think when receiving a fullregistrationrequired in a registration the stored fields should be reset. Actually I've seen it's processed like this: case H225_RegistrationRejectReason::e_fullRegistrationRequired : registrationFailReason = GatekeeperLostRegistration; // Set timer to retry registration reregisterNow = TRUE; monitorTickle.Signal(); break; but I've been unable to find more actions than signalling an immediate retry, I think in this case, if not in the general registration reject case, the endpoint identifier should be cleared, as it shouldn't be valid after a failed registration. I've also studied the differences between tag v1.25 and HEAD http://h323plus.cvs.sourceforge.net/viewvc/h323plus/h323plus/src/gkclient.c… and haven't found any differences in the relevant areas. Summarising, I think endpoint identifier, and maybe some mor registration data should be cleared on registration rejects. And also stored endpoint identifier should be tested again a potential inconsistency against registration confirm data, althoguh this can be problematic ( what to do if they do not match ? ) and can be left off as it's not going to interfre with normal operations. I can try to make a patch, in my case probabley clearing endpointIdentifier on registration reject will work, but I fear it may broke other parts. Francisco Olarte. P.S. I cannot provide detailed packet traces at the moment, as they need some rather involved setup, but I can try to do it if someone think it's neccessary. F.O.

1 0

GNU Gatekeeper 3.4 released
by Jan Willamowius 19 Sep '13

19 Sep '13

Dear community, I'm happy to announce the availability of GNU Gatekeeper 3.4 with a number of new features and bug fixes. http://www.gnugk.org/gnugk-3.4.html Whats new ? - implement H.460.26 (RTP over TCP) together with H.460.17, this allows endpoints to operate on a single outbound TCP connection - implement H.235.6 media encryption of data channels - automatically update H.235.6 media keys after 2^31 packets enable with EnableH235HalfCallMediaKeyUpdates=1 - implement TLS support to encrypt call signaling channel important to secure the H.235.6 key exchange, allows a fully encrypted GnuGk-to-GnuGk trunk http://www.gnugk.org/gnugk-manual-12.html#ss12.11 - set RTP source IP on OS that support it (Linux, FreeBSD, Win Vista+) important for multi-homed servers with H.460.19 or IP failover - new routing policy 'ldap' - new authentication modules: LDAPAliasAuth and LDAPPasswordAuth - allow non-gateways to use additive registration, fix H.460.x support now always enabled and important for LifeSize interoperability - new accounting variables %{caller-vendor} and %{callee-vendor} - allow "0.0.0.0/0" in ModeSelection and ExplicitRoutes= this allowes you to set one default setting and other rules for exceptions - access to the SSH status port can be restricted by additional IP rules in [GkStatus::Auth] - setting on/off config switches to y/n or a/? is now depricated, use 1/0 check your config, these will stop working shortly! - a number of bug fixes Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project 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

1 0

Security updates to h323plus/GnuGk
by Simon Horne 05 Aug '13

05 Aug '13

To all No doubt people on the CVS commit list has seen a flurry of commits to both h323plus and GnuGk particularly in the area of security. H323plus (and GnuGk) now supports H.235.6 with AES256 Media encryption with up to 4096 Diffie-Hellman keys. This mode is compatible with industry standard AES128 with 1048 DH key but provides addition security when calling with h323plus or using GnuGk. We have also begun adding TLS support to both H323plus and GnuGk to protect signaling. Over the coming weeks we plan to add more features in the H.235.x series. Simon

1 0

GNU Gatekeeper 3.2 released
by Jan Willamowius 14 May '13

14 May '13

Dear community, I'm happy to announce the availability of GNU Gatekeeper 3.3 with a number of new features and bug fixes. http://www.gnugk.org/gnugk-3.3.html Whats new ? - support for H.460.18/.19 between parent and child gatekeepers - interoperability fixes for H.460.19 RTP multiplexing with Tandberg/Cisco equipment - support for pre-granted ARQs to speed up call establishment [RoutedMode] PregrantARQ=1 - SNMP traps with warnings are now disabled by default for less noise - configurable DiffServ DSCP to set QoS on RTP traffic - new [RewriteCLI::SQL] feature - new [Routing::NeighborSQL] policy to read Neighbor targets from database - updated [CallTable] DisabledCodecs to include UserInput Capabilities - new [RasSrv::LRQFeatures] PingAlias= to reduce resource usage processing LRQ pings - improvements to [RewriteSourceAddress] - many smaller bug fixes This version also contains a security fix for SQLite users. Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project Website: http://www.gnugk.org Relaxed Communications GmbH Frahmredder 91 22393 Hamburg Geschäftsführer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584

1 0

PTLIB_VER versioning
by J.C Mercier 10 Apr '13

10 Apr '13

Just a quick note, it seems that the expression below (PTLIB_MINOR <= 10) will always yield a least PTLIB_VER for the most part. for instance, if PTLIB_MAJOR =2, PTLIB_MINOR=10, it goes to the first #if, resulting in PTLIB_VER = 300 instead of 2100. Just curious to know if this is intentional. #if PTLIB_MAJOR == 2 && PTLIB_MINOR <= 10 #define PTLIB_VER ( PTLIB_MAJOR*100 + PTLIB_MINOR*10 + PTLIB_BUILD ) #else #define PTLIB_VER ( PTLIB_MAJOR*1000 + PTLIB_MINOR*10 + PTLIB_BUILD ) #endif Thanks Josh

3 2

GNU Gatekeeper Survey 2013
by Jan Willamowius 08 Apr '13

08 Apr '13

Dear all, almost every year we do a survery where users can give feedback and provide new ideas for features etc. I always learn a lot about what you all think and which direction you want the GNU Gatekeeper project to go, so please take a moment to answer a few questions. http://www.gnugk.org/survey-2013.html Thanks for your time! Best regards, Jan PS: Feel free to pass the link on to other GnuGk users who are not on this mailinglist. We want everybody's opinion! -- 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

1 0

Adrien Rudulier
by Adrien Rudulier 22 Feb '13

22 Feb '13

xbbzhttp://www.mindshift-consulting.com/ajbbpqt/xcc5r.r?0m4wee2a inm .doqeuxvwtxvbgiyhgayaafzxxnz<span style="color: rgb(255, 255,

1 0