- h323plus - lists.packetizer.com

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

h323plus 1.25.0 compilation
by Vieri 12 Feb '13

12 Feb '13

Hi, With version 1.25.0 I get the following error (did not appear in previous 1.23.0 version): [CC] h323.cxx In file included from include/h323con.h:44:0, from h323.cxx:37: include/openh323buildopts.h:37:34: fatal error: ptlib/../../revision.h: No such file or directory I suppose it's a packaging error as revision.h should only be used for the svn version? Removing that line in openh323buildopts.h should be enough. Thanks, Vieri

2 1

Ambiguous dependence between H323_H46019M and H323_H46024A
by Denis Kochmashev "Enforta" 01 Feb '13

01 Feb '13

Hello! There is an ambiguous dependence between H323_H46019M and H323_H46024A in include/h460/h46018_h225.h and in src/h460/h46018_h225.cxx. In h46018_h225.cxx code of PBoolean H46019UDPSocket::GetPeerAddress(PIPSocketAddressAndPort & addr) will be compiled only if H323_H46019M and H323_H46024A are defined both (#ifdef H323_H46019M at line 1523 is called while we are in #ifdef H323_H46024A block, which starts at line 1461). In h46018_h225.h this function is only dependent on H323_H46019M. I've made a small patch which, assuming the correctness of h46018_h225.h. С уважением, Денис Кочмашев Руководитель группы Телефонии Энфорта /ООО "Престиж-Интернет"/ Центр технической эксплуатации г. Екатеринбург раб.тел. : +7 343 3789808 доб.1811 моб.тел. : +7 909 0222711 корп.тел.: (0 343) 1811 e-mail : <mailto:d.kochmashev@enforta.com> d.kochmashev(a)enforta.com

1 0