- h323plus - lists.packetizer.com

H323Plus 1.26.9 released
by Jan Willamowius 16 Jan '18

16 Jan '18

Hi, I have just published the 1.26.9 release with many bug fixes compared to 1.26.8. Please download it from https://www.h323plus.org/source/ or directly from Github: https://github.com/willamowius/h323plus Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan(a)willamowius.de H.323 Support: https://www.willamowius.com/ Relaxed Communications GmbH Frahmredder 91 22393 Hamburg Geschäftsführer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584

1 0

Size constraints for H225_ArrayOf_EnumeratedParameter
by Denis Kochmashev 29 Oct '17

29 Oct '17

Hello! I have encountered something which looks like a bug. When I add parameters to my custom H460_Feature via H460_FeatureTable table; : table.AddParameter(id, content); : SetCurrentTable(table); H323Plus produces malformed packet with incorrectly encoded size of H225_ArrayOf_EnumeratedParameter. I've found that size constraints for H225_ArrayOf_EnumeratedParameter are not beeing set, however, according to spec, they had to be set. So, if my conclusion is right, I propose a small patch like the following: --- h225_2.cxx.orig 2013-07-23 00:26:59.000000000 +0600 +++ h225_2.cxx 2017-10-23 11:00:27.000000000 +0500 @@ -19,6 +19,7 @@ H225_ArrayOf_EnumeratedParameter::H225_ArrayOf_EnumeratedParameter(unsigned tag, PASN_Object::TagClass tagClass) : PASN_Array(tag, tagClass) { + SetConstraintBounds(PASN_Object::FixedConstraint, 1, 512); } Regards, Denis

3 3

H323Plus source code moving to Github
by Jan Willamowius 13 Oct '17

13 Oct '17

Hi, SourceForge will close down all CVS repositories shortly. The H323Plus source repository is thus moving to Github. Along with it the repositories for GnuGk and our PTLib fork also move to Github. https://github.com/willamowius/h323plus https://github.com/willamowius/gnugk https://github.com/willamowius/ptlib Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan(a)willamowius.de H.323 Support: https://www.willamowius.com/ Relaxed Communications GmbH Frahmredder 91 22393 Hamburg Geschäftsführer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584

1 0

GNU Gatekeeper 4.7 has been released (security update)
by Jan Willamowius 21 Sep '17

21 Sep '17

Hi, GNU Gatekeeper version 4.7 has just been released. This version is purely a security update and has no new features. All users are encouraged to update, especially if you use port detection (IgnoreSignaledIPs=1) you should update ASAP. It has been discovered that GnuGk is vulnerable in some configurations for RTP bleed attacks (https://rtpbleed.com/) By updating to version 4.7 only the first packets in each media stream influence the media destination. To further secure your configuration, you can set [Proxy] RestrictRTPSources=Net to only accept RTP from the same class C network that the call signaling came from. Please beware that this may break a few valid calls where this condition isn't met. You can download the new version from https://www.gnugk.org/h323download.html Please see the full change log below. Changes from 4.6 to 4.7 ======================= - fixes for RTP Bleed - new switch [Proxy] RestrictRTPSources=IP or Net to limit accepting RTP from the call signal IPs or the respective class C network - new switch [Proxy] LegacyPortDetection=1 to keep port detection help for some very old and broken endpoints that will make your gatekeeper vulnerable to RTP Bleed attacks - BUGFIX(ProxyChannel.cxx) replace @ip or ip## from aliases when using RedirectCallsToGkIP - BUGFIX(ProxyChannel.cxx) better initialization of sendmsg() structs - new command line option: now you can use -S instead of --strict (needed on BSD systems) -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan(a)willamowius.de Website: https://www.gnugk.org Support: https://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

GNU Gatekeeper 4.6 is out
by Jan Willamowius 04 Sep '17

04 Sep '17

Hi, I'm happy to announce that GNU Gatekeeper version 4.6 has just been released. This version has a few new features as well as bug fixes. New features: - least used routing: distribute calls evenly between gateways or MCUs (new switch [RasSrv::ARQFeatures] LeastUsedRouting=1) - ability to log to the Unix syslog instead of the trace file (new switch [LogFile] TraceToSyslog=1) - new authentication module TwoAliasAuth this is not very safe, but you can use it with endpoints that do not support any password transmission - new switch [CTI::MakeCall] Bandwidth= to set the maximum bandwidth for the calls generated by the GnuGk status port API - status port command: UnregisterEP <ep-id> - a number of switches to fine tune TCP keepalives - new switch to remove load balancers from the call path ([RoutedMode] RedirectCallsToGkIP=1) Bug fixes: - fixed TCP keepalive for H.460 calls - fixes to port detection for unregistered calls - audio fix when GnuGk adds encryption to calls - many smaller fixes You can download the new version from https://www.gnugk.org/h323download.html Please see the full change log below. Changes from 4.5 to 4.6 ======================= - new switch: [RoutedMode] RedirectCallsToGkIP=1 - new switches: [RoutedMode] H460KeepAliveMethodH225=, H460KeepAliveMethodH245=, GnuGkTcpKeepAliveMethodH225=, GnuGkTcpKeepAliveMethodH245= - BUGFIX(ProxyChannel.cxx) TCP keep-alives for H.460.18 calls weren't always enabled correctly - don't open a status port listener if [Gatekeeper::Main] StatusPort=0 - BUGFIX(Toolkit.cxx) remove trailing chars before checking for DefaultDomain - add callID to H.245 trace messages for easier debugging - BUGFIX(ProxyChannel.cxx) forward ReleaseComplete from remaining party while doing call reroute - BUGFIX(ProxyChannel.cxx) drop un-en/decryptable RTP packets at end of call when adding encryption - new status port command: UnregisterEP <ep-id> - BUGFIX(RasSrv.cxx) remove IPv6 addresses before processing RRQs when IPv6 is not enabled - send Facility message as as non-H.460.18 keep-alive for H.225 - send non-standard H.245 userIndication as non-H.460.18 keep-alive for H.245 - new switch [RoutedMode] DisableGnuGkH245TcpKeepAlive=1 - new switch [LogFile] TraceToSyslog=1 to send trace output to syslog (Unix only) - BUGFIX(ProxyChannel.cxx) fix port detection for re-opened channels with IgnoreSignaledIPs=1 - new switch [CTI::MakeCall] Bandwidth= to set the maximum bandwidth for the call - new switch [RasSrv::ARQFeatures] LeastUsedRouting=1 to select the least used gateway - new authentication module TwoAliasAuth -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan(a)willamowius.de Website: https://www.gnugk.org Support: https://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

H323Plus 1.26.8 release and h323plus.org website
by Jan Willamowius 03 Sep '17

03 Sep '17

Hi, I have just released H323Plus 1.26.8. This version contains a number of bug fixes that were only available through the CVS until now. https://www.h323plus.org/source/ I'm also taking over the maintenance of the h323plus.org website. If you run into any issues, please email me. Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan(a)willamowius.de Website: https://www.gnugk.org Support: https://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

H235 on extended video channel (H239)
by Diego Carvalho Domingos 18 Aug '17

18 Aug '17

Hi, all I'm successfully using both h239 and h235 (for audio and video channels) in my application. Now I also would like to encrypt the content video (extended video channel). It seems that the security capability is not being added to the H.239(H.264{sw} <1>) capability. Is there some way to enable it? Thanks in advance. Diego

1 1

problem about H.235
by gary 13 Aug '17

13 Aug '17

HI Simon and Jan after enabed the H235 media encryption, openmcu and H323 ep in the same network were work well . however , when they were in different networks， 1 . only audio PDU（200bytes）received at MCU , MCU can not receive video pdu（above 1000 bytes）.i am sure the ep had upload the audio and video packages . 2. the threads used for trasmit and receive data had been create , but no data send to H323 ep . some messages hint that PTLIB write Blocking ，but i don‘t know why , use fcntl() to set read/write NONBLOCKING , But not effective . please help thanks gary

2 1

Possible misassumption in HandleFirstSignallingChannelPDU
by Jose Uceda 30 May '17

30 May '17

In our software that we mentioned a few days ago, in addition to the lockups, we observed a problem when we apparently received an incoming call, but CreateConnection is called with a valid PDU that is not a Setup Message one. It happens when the incoming call comes from a Cisco gateway, and the call hangs up at a point where the gateway has sent the Admission Request to the gatekeeper, receives its corresponding admission confirm, but has not sent yet the setup message to our software / destination endpoint. In these circumstances we saw that the gateway has opened the signaling socket with our endpoint, but the first packet it sends is a Release Complete because the call was hung before sending the setup. PDU trace from our Gatekeeper: 2017-05-27 14:46:28.853 5d37 INFO pdu.call.a.ARQ.recv : Received from ip$x.x.x.x:54432. 2017-05-27 14:46:28.855 5d37 INFO pdu.call.a.ACF.send : Sending to ip$x.x.x.x:54432. 2017-05-27 14:46:28.865 5d37 INFO pdu.call.d.DRQ.recv : Received from ip$x.x.x.x:54432. 2017-05-27 14:46:28.866 5d37 INFO pdu.call.d.DCF.send : Sending to ip$x.x.x.x:54432. See the time-stamps, showing that the ACF and DRQ are closely followed. We receive the call at our endpoint, in the CreateConnection function at the same time point as the DRQ / DCF. In our software, in some cases we return NULL if we cannot handle the incoming connection (not enough setup data, e.g.), and if we are running an executable compiled in Debug mode, an assert fails on the following operator: H225_H323_UU_PDU_h323_message_body :: operator const H225_Setup_UUIE & () const #endif { #ifndef PASN_LEANANDMEAN PAssert (PIsDescendant (PAssertNULL (choice), H225_Setup_UUIE), PInvalidCast); #endif Return * (H225_Setup_UUIE *) choice; } It is caused by the following line (transports.cxx: 1126): H225_Setup_UUIE & setup = pdu.m_h323_uu_pdu.m_h323_message_body; This code assumes that the initial PDU is a Setup one without checking it, when it may not necessarily be. That can cause a DoS in a software that has core dump enabled when an assert occurs, or if there is some code in HandleFirstSignallingChannelPDU / OnIncomingConnection and sub-calls that trust and handles the PDU object assuming it is a Setup message. I've made the following patch on the HandleFirstSignallingChannelPDU function, which verifies that the PDU is a Setup message, otherwise it returns FALSE (same behavior as if it had not been able to read a valid q931 pdu), since we think it does not make much sense to call OnIncomingConnection if the initial PDU is not a Setup one: -------------------------------------------------------------------------------- --- src/transports.cxx.orig 2015-11-24 18:51:06.385755223 +0100 +++ src/transports.cxx 2017-05-29 11:15:20.777411444 +0200 @@ -1106,7 +1106,13 @@ return FALSE; } - unsigned callReference = pdu.GetQ931().GetCallReference(); + const Q931 &firstQ931PDU = pdu.GetQ931(); + if (firstQ931PDU.GetMessageType() != Q931::SetupMsg) { + PTRACE(1, "H225\tFirst pdu is not a setup one, connection not started."); + return FALSE; + } + + unsigned callReference = firstQ931PDU.GetCallReference(); PTRACE(3, "H225\tIncoming call, first PDU: callReference=" << callReference); // Get a new (or old) connection from the endpoint -------------------------------------------------------------------------------- A place where we could also put the patch is in the HandleSignallingSocket function, which apparently is only used from HandleFirstSignallingChannelPDU, but as it has a more generic name and may give rise to doubts of its behavior. Regards, Jose Uceda

2 1

Lockup problems
by Jose Uceda 09 May '17

09 May '17

Hi all, In one of our softwares which uses the H323+ library, we are recently suffering from lockups when the calls are disconnecting. It's currently running with H323+ from CVS and PTLib 2.12.8. As far as we have been able to trace, it seems to be that the RTP UDP socket or signalling channel sometimes remains in a loop and they don't close as expected (log says Broken Pipe errors, eg). That issue causes the call is not finished correctly, and it seems to leave the cleaner thread in a stuck state so subsequent calls are no longer hanged up (at least we don't receive OnCleared event anymore). When we were trying to debug the problem, we saw that the issue became worse with PTLib 2.12.9, and we also suffered from many more locks with the 1,175 h323.cxx file revision, which was reverted about a month later. The comment from the commit that reverts 1,175 revision reads as follows: "Always calling Wait (0) on mutex can cause issues with lock nesting, move fix to PTLib fork" Is there any fork of PTLib in some repository that we haven't noticed about it, that is the official one to use with H323+? Thanks in advance. Regards, Jose Uceda

2 1