- h323plus - lists.packetizer.com

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

Re: [h323plus] Renegotiate media port
by Diego Carvalho Domingos 19 Apr '17

19 Apr '17

Thanks once again Jan, Actually my gateway does not proxy media. After reading your answer, I searched and found that CloseLogicalChannel has a parameter fromRemote. Is that what you are talking about? This would send a request channel close, right? Regards, Diego Carvalho Domingos System Development Specialist +55.19 3112-1200-1286 DaitanGroup | www.daitangroup.com | Accelerating.T Privileged and confidential. If this message has been received in error, please notify sender and delete it immediately. Conteúdo confidencial. Se esta mensagem foi recebida por engano, favor avisar o remetente e apagá-la imediatamente. -----Original Message----- From: Jan Willamowius [mailto:jan@willamowius.de] Sent: quarta-feira, 19 de abril de 2017 12:53 To: Diego Carvalho Domingos <ddomingos(a)daitangroup.com> Subject: Re: [h323plus] Renegotiate media port The ports you receive media on affect both your sending and receiving media channels (the channel where you send media is in the same RTP session as the receiving channel and thus the RTCP ports should match). So you would have to close sending and receiving channels and hope that the other side re-opens their sending channel. Sending a TCS0 and doing a full re-negotiation seems like a good choice. But as I said on the board, since your gateway proxies media, I'd try to keep the port the same during the call and eg. copy the data from the SIP side from one port to the other etc. Thats probably a lot of work, too, but better than closing and re-opening channels. Regards, Jan Diego Carvalho Domingos wrote: > Thanks for answering Jan, > > I tried that but then I realized that the port that the H323 device should send media to goes in the OLCA, so closing and reopening my local OLC does not help. I'm missing something here? > After realizing that reopening the OLC would not help, I restarted the > whole negotiation by sending an empty TCS and, after receiving the TCS > Ack, a non-empty TCS. This in fact worked but I thought it's too > complex. Would reverse logical channel parameters help here? If so, > can you point me how to set that? I use (a subclass of) > H323_ExternalRTPChannel. Thanks again. Regards, > > Diego Carvalho Domingos > > -----Original Message----- > From: h323plus [mailto:h323plus-bounces@lists.packetizer.com] On > Behalf Of Jan Willamowius > Sent: quarta-feira, 19 de abril de 2017 12:10 > To: h323plus(a)lists.packetizer.com > Subject: Re: [h323plus] Renegotiate media port > > Hi Tarmo, > > if you look closely, Diego is doing video. > To my knowledge there is no free H.323-SIP gateway that supports video. > > Regarding the port negotiation: > The only way to change the ports is to close the logical channel and > to open a new one. (as we discussed on the Packetizer board) > > 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 > > kalazeez wrote: > > There is no need to reinvent the wheel. Use something existing and most fitting Your needs. For similar cases iI usually use Freeswitch. Just works, out of the box. > > > > Tarmo > > > > > On 17 Apr 2017, at 22:52, Diego Carvalho Domingos <ddomingos(a)daitangroup.com> wrote: > > > > > > Hi all, > > > At some point after the call has been successfully set up, I need to renegotiate the audio (it could be video as well) media port. In my case, I developed a H323-SIP gateway (that does not handle media, only signaling conversion) and the SIP side sent a reinvite with a different audio port, so I need to make the H323 device send media to this new port. How can I accomplish this? (both in terms of the H323 protocol itself and implementing the solution using H323Plus). I appreciate any help, thanks. > > > > > > Diego Carvalho Domingos

1 0

Renegotiate media port
by Diego Carvalho Domingos 19 Apr '17

19 Apr '17

Hi all, At some point after the call has been successfully set up, I need to renegotiate the audio (it could be video as well) media port. In my case, I developed a H323-SIP gateway (that does not handle media, only signaling conversion) and the SIP side sent a reinvite with a different audio port, so I need to make the H323 device send media to this new port. How can I accomplish this? (both in terms of the H323 protocol itself and implementing the solution using H323Plus). I appreciate any help, thanks. Diego Carvalho Domingos

3 3

GNU Gatekeeper Survey 2017
by Jan Willamowius 19 Apr '17

19 Apr '17

Dear GnuGk community, could you please give some feedback how you like GnuGk and it can be improved ? I have compiled a quick poll. Please feel free to add any other suggestions you may have. https://www.gnugk.org/survey-2017.html In the past, these surveys have always been a great inspiration. Please keep the feedback coming. Thanks for your time! 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

GNU Gatekeeper 4.5 released
by Jan Willamowius 16 Mar '17

16 Mar '17

Hi, I'm proud to announce that GNU Gatekeeper 4.5 has been released. The most important change is the implementation of TCP keepalives for H.460.18 (bugfix) and optionally for all kinds of calls (feature). This is really important for NAT traversal. In addition to the keepalives there are a number of bugfixes and a few minor feature additions (see the change notes below). You can download the new version from https://www.gnugk.org/h323download.html Please see the full change log below. Changes from 4.4 to 4.5 ======================= - new feature to send H.225 and H.245 keep-alives for all calls, enable with [RoutedMode] EnableGnuGkTcpKeepAlive=1, set interval with GnuGkTcpKeepAliveInterval=n - BUGFIX(ProxyChannel.cxx) send H.225 and H.245 keep-alives when acting as H.460.18 client - BUGFIX(ProxyChannel.cxx) disable RTP/RTCP port check for IPs in AllowedSignalIPs= when doing port detection - [Proxy] AllowedSignalIPs= can now process a list of networks - add shortcurt 'rl' for status port command 'rotatelog' - new switch [CallTable] SetCalledStationIdToDialedIP=1 - new switch [CallTable] UseDestCallSignalIPAsDialedNumber=1 to place the destSignalIP into the %{DialedNumber} field if no dialed number is available in the ARQ / Setup - BUGFIX(ProxyChannel.cxx) fix crash on invalid sourceCallSignalAddress - add optional parameter for call transfer method to MakeCall status port command - BUGFIX(Toolkit.*) fix bug in IP comparison - BUGFIX(Toolkit.*) the internal networks configured with the [Proxy] InternalNetworks switch were added to the detected internal networks and didn't replace them, now they replace them as documented -- 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

packetization mode in TCS.
by Ankur Deep Jaiswal 11 Feb '17

11 Feb '17

Hi can i send packetization mode with TCS for H.264, is there a way to modify TCS before sending it out. help appreciated -- Regards Ankur Deep Jaiswal Ernakulam

3 4

GNU Gatekeeper 4.4 released
by Jan Willamowius 06 Jan '17

06 Jan '17

Hi, GNU Gatekeeper 4.4 was released today. This is mainly a bug fix release with only 2 new features. If you use SSH on your status port you are urged to update as soon as possible and also if you use LUA scripting. Two serious bugs have been fixed for these features where GnuGk can be crashed remotely. A new feature is the RequireOneNet policy that allows you to restrict access to publicly accessible traversal gatekeepers. Now you can easily define that one end of all calls must terminate in one of your own networks and prevent abuse of your resources by 3rd parties. The other new feature is a significant improvement to the MakeCall command on the status port. It is now able to establish video calls and supports virtually all endpoints by using GnuGk's call reroute feature. Changed config switches: - [Proxy] ProxyForNAT now defaults to OFF - [CTI::MakeCall] DisableFastStart has been removed, fastStart is now always disabled You can download the new version from http://www.gnugk.org/h323download.html Please see the full change log below. These know bugs haven't been addressed, yet: - when GnuGk acts as a H.460.18 client (as client in a H.460.18 traversal zone with another gatekeeper or as child gatekeeper), it currently does not send a keep-alive on the Q.931 TCP connection during a call - bandwidth management currently only applies to calls from registered endpoints and ignores unregistered calls completely Changes from 4.3 to 4.4 ======================= - [CTI::MakeCall] TransferMethod can now also be Reroute, DisableFastStart switch removed - BUGFIX(MakeCall.cxx) fix MakeCall bearer capabilities to support video calls - BUGFIX(ProxyChannel.cxx) don't send Notify after call Reroute: Polycom RealPresense starts a flood of Status messages - BUGFIX(GkStatus.cxx) call ssh_init() and ssh_finalize() only on application start and shutdown - BUGFIX(ProxyChannel.cxx) fix IP check for IgnoreSignaledPrivateH239IPs= switch - new accounting/authentication policy RequireOneNet - pass full RRQ message to LuaAuth - BUGFIX(ProxyChannel.cxx) when opening a port from a PortRange fails, try next port regardless of errno - BUGFIX(lua.cxx) add mutex for LUA interpreter, because it is not thread safe - added message type parameter in RouteRequest event (ARQ, Setup, LRQ) - BUGFIX(yasocket.cxx) fix UDP with LARGE_FDSET on Solaris, OpenBSD and NetBSD - BUGFIX(RasTbl.cxx) fix crash on invalid AliasTypeFilter setting - changed default setting: [Proxy] ProxyForNAT now defaults to off, if you want to keep the previous behaviour, please set it explicitely -- 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

Recent bug fixes
by Jan Willamowius 04 Jan '17

04 Jan '17

Hi, during the past few months I fixed a few bugs where the remote party can crash a H323Plus application. Much of this came from fuzzy testing sponsored by one of my support clients. There is no official H323Plus release, but I think it would be a good idea for most people to update to the latest CVS version. 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

Crash after MakeCall
by Ankur Deep Jaiswal 27 Dec '16

27 Dec '16

Hi , i updated to latest CVS release. and am using ptlib version 2.10.9. i am now getting the following error. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7f13700 (LWP 24402)] 0x00000000004d4a84 in PArray<PASN_Object>::operator[] (this=0x7fffe00463b0, index=0) at /home/test/libs/h323/ptlib/include/ptlib/array.h:1062 1062 PObject * obj = GetAt(index); (gdb) bt #0 0x00000000004d4a84 in PArray<PASN_Object>::operator[] (this=0x7fffe00463b0, index=0) at /home/test/libs/h323/ptlib/include/ptlib/array.h:1062 #1 0x00000000005f8a4a in H245_ArrayOf_VideoCapability::operator[] (this=0x7fffe0046390, i=0) at h245_1.cxx:16846 #2 0x000000000047baa1 in H323CodecExtendedVideoCapability::IsMatch (this=0xc94dc0, subTypePDU=...) at h323caps.cxx:2269 #3 0x0000000000480790 in H323Capabilities::FindCapability (this=0xc93498, mainType=H323Capability::e_Data, subTypePDU=..., translationTable=0x0, tableElements=0) at h323caps.cxx:3902 #4 0x000000000047fbb5 in H323Capabilities::FindCapability (this=0xc93498, cap=...) at h323caps.cxx:3633 #5 0x000000000047f99e in H323Capabilities::FindCapability (this=0xc93498, cap=..., capID=224, pdu=...) at h323caps.cxx:3596 #6 0x000000000047dd40 in H323Capabilities::H323Capabilities (this=0x7ffff7f12bb0, connection=..., pdu=...) at h323caps.cxx:3210 #7 0x00000000004615a3 in H245NegTerminalCapabilitySet::HandleIncoming (this=0xc96a20, pdu=...) at h323neg.cxx:380 #8 0x000000000043c7dc in H323Connection::OnH245Request (this=0xc93370, pdu=...) at h323.cxx:3489 #9 0x000000000043c493 in H323Connection::HandleControlPDU (this=0xc93370, pdu=...) at h323.cxx:3439 #10 0x000000000043c3ad in H323Connection::HandleControlData (this=0xc93370, strm=...) at h323.cxx:3423 #11 0x000000000043bbb0 in H323Connection::HandleReceivedControlPDU (this=0xc93370, readStatus=true, strm=...) at h323.cxx:3344 #12 0x000000000043ba98 in H323Connection::HandleControlChannel (this=0xc93370) at h323.cxx:3326 #13 0x000000000049c093 in H245TransportThread::Main (this=0x7fffec008380) at transports.cxx:221 #14 0x000000000078b34a in PThread::PX_ThreadStart (arg=0x7fffec008380) at ptlib/unix/tlibthrd.cxx:491 #15 0x00007ffff7bc4182 in start_thread (arg=0x7ffff7f13700) at pthread_create.c:312 #16 0x00007ffff6db030d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 An object of type H245_MasterSlaveDeterminationRelease is getting destructed, i put logs in the constructor and destructor , but the constructor is never called. Regards Ankur Deep Jaiswal

2 1

Transport thread did not terminate
by Ankur Deep Jaiswal 20 Dec '16

20 Dec '16

Hi i some times get hit by a Assertion fail: Transport thread did not terminate, file transports.cxx, line 1204 this always happens after : H323TCP Could not connect to ip:port (local port=0) - Interrupted system call(4) any thoughts -- Regards Ankur Deep Jaiswal

2 2

GNU Gatekeeper 4.3 released
by Jan Willamowius 16 Nov '16

16 Nov '16

Hi, I'm happy to announce the release of GNU Gatekeeper 4.3. This new version contains a number bug fixes and some security fixes. Fuzzy testing surfaced methods to crash GnuGk remotely, causing at least a denial of service. So all users are encouraged to update. The most notable new feature are probably the events for Setup messages on the status port so now you can see all calls. In addition, LuaAuth has been given access to more information about received messages and can end your status port sessions with Ctrl-C now. Important bug fixes are in the H.460 NAT traversal code where sometimes keep-alive intervals could be too long in older versions and a bug where GnuGk might have missed port re-negotiations in some cases. The IgnoreSignaledIPs port detection code also has a few bug fixes to detect cases where it should be turned off automatically because its either not needed because the parties use another form of NAT traversal or non-symmetric ports where the detection algorithm may cause more harm than good. You can download the new version from http://www.gnugk.org/h323download.html Please see the full change log below. Enjoy! Changes from 4.2 to 4.3 ======================= - BUGFIX(ProxyChannel.cxx, gkh235.cxx, gkauth.h) fix crashes found with PROTOS - new authentication policies LuaPasswordAuth, HttpPasswordAuth - BUGFIX(configure.in) fix check for LUA 5.2 or higher - connection to the status port can now also be ended with Ctrl-C - new switch [Routing::DNS] RewriteARQDestination= to preserve URLs in ARQs - disable IgnoreSignaledIPs when one party is not using the same RTP ports for forward and reverse channels in same RTP session - BUGFIX(RasTbl.cxx) don't allow higher TTL for H.460.18 registrations than set by H46018KeepAliveInterval= switch - add variables message, srcInfo and vendor to LuaAuth - print message on status port when Setup is received - BUGFIX(ProxyChannel.cxx) disregard IgnoreSignaledIPs=1 switch when caller supports some form of NAT traversal (to avoid both sides waiting for first RTP packet) - BUGFIX(ProxyChannel.cxx) enable H.245 tunneling for H.460.17 even when Innovaphone forgets the flag - BUGFIX(ProxyChannel.cxx) make sure CRV is 0 for all RAS messages when using H.460.17 even when they relate to a call - BUGFIX(ProxyChannel.cxx) re-do H.460.19 port detection when a new logical channel is opened on the same port - print number of CPU cores and thread configuration on startup - BUGFIX(RasTbl.cxx) fix display of H.460.17 for registrations on status port - BUGFIX(ProxyChannel.cxx) fix dead lock causing reroutes to fail -- 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

GNU Gatekeeper 4.2 released
by Jan Willamowius 31 May '16

31 May '16

Hi, I'm happy to announce the release of GNU Gatekeeper 4.2. Version 4.2 is mainly a bug fix release. A bug in proxying H.239 connections through NAT has been fixes as well as a number of possible crashes and a few other small bugs. The main functional change is that GnuGk's old NAT traversal method is now disabled by default. Everybody should use H.460.x. If you want keep using the old NAT traversal method, you can re-enable it with [RoutedMode] EnableGnuGkNATTraversal=1 [Endpoint] EnableGnuGkNATTraversal=1. You can download the new version from http://www.gnugk.org/h323download.html Please see the full change log attached below. Enjoy! -- 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 Changes from 4.1 to 4.2 ======================= - BUGFIX(ProxyChannel.cxx) fix H.239 forwarding issue in call where only one side uses H.460.19 - BUGFIX(configure.in) make sure LUA test fails for versions below 5.2 - BUGFIX(gkh235.cxx) small fix with password auth - BUGFIX(ProxyChannel.cxx) apply codec filtering also to receiveAndTransmit capabilities - BUGFIX(ProxyChannel.cxx) fix crash in RTP multiplexing - BUGFIX(ProxyChannel.cxx) fix crash when using H.245 tunneling translation - BUGFIX(gk.cxx) fix shutdown on NetBSD 7 - BUGFIX(ProxyChannel.cxx) fix compile on NetBSD 7 - new switch: [RoutedMode] FilterVideoFastUpdatePicture= to reduce the number of update requests from endpoints - disable SSLv3 when using TLS - BUGFIX(ProxyChannel.cxx) fix crash in call cleanup - support ON and OFF event in LuaAcct - BUGFIX(sqlacct.*) implement ON and OFF event as documented - new switches [RoutedMode] EnableGnuGkNATTraversal=1 and [Endpoint] EnableGnuGkNATTraversal=1 to keep GnuGk's old NAT traversal method enabled

1 0

hi
by 陈炳锡-阳阳谷信息科技 26 May '16

26 May '16

hi is it a bug of OpenH323? i have a problem in using openh323, in the OpenH323 transmission channel, i am send more than 65K of the size of the data, it will not be sent out.

1 0

GNU Gatekeeper Survey 2016
by Jan Willamowius 14 Apr '16

14 Apr '16

Dear GnuGk community, I have compiled a quick survey where you can indicate what you like about GnuGk and what is missing. Please feel free to add any other suggestions you may have. http://www.gnugk.org/survey-2016.html In the past, these surveys have always been a great inspiration. Thanks for your time! 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

h323plus text messaging
by Leonardo Nahra 07 Mar '16

07 Mar '16

Hello, I'm working on a conference project,and we will use the H.323 protocol to establish a connection between monitors, so they can exchange information about configuration options of the video stream they'll receive. So, once a call is established, in addition of exchanging video and audio (that we already have implemented apart), configuration options need to be sent in text format back and forth. Searching through h323plus I couldn't find a way to send text in a call, can you give me some pointers on how to accomplish that? Thanks, Nahra.

4 3

GNU Gatekeeper 4.1 released
by Jan Willamowius 16 Feb '16

16 Feb '16

Hi, I'm happy to announce the availability of GNU Gatekeeper 4.1. This is mainly a bug fix release. If you are using GnuGk as a server in a traversal zone or if you do H.239 presentations with Avaya endpoints, you are strongly encouraged to update. This version also fixes a memory leak that mainly affects long running gatekeepers with a lot of RAS traffic. Some of the bugs were long standing, so if you skipped some previous releases, this is really a good time to update. The main new feature in this release is expanded LUA support. Besides LUA authentication and LUA routing, there is now a LuaAcct module that allows you to run a script on every accounting event of your choice. Please see the updated manual for details. You can download the new version from http://www.gnugk.org/h323download.html Please see the full change log attached to the end of this mail. My support website https://www.willamowius.com also got a face lift. Please check it out as well. Enjoy! -- 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 Changes from 4.0 to 4.1 ======================= - BUGFIX(ProxyChannel.cxx) fix crash processing Setup - BUGFIX(RasSrv.cxx) update IP/port of traversal neighbor on every SCI, not only on IP changes - new status port command: PrintNeighbors - BUGFIX(ProxyChannel.cxx) fix H.239 inside multiplePayloadStream from Avaya XT5000 with H.460.19 - new accounting module: LuaAcct - LUA: new library "gnugk" to allow access to GnuGk functionality - BUGFIX(configure) set all detected options in gnugkbuildopts.h on Unix - BUGFIX(ProxyChannel.cxx) removing H.235 capabilities might have skipped items - BUGFIX(lua.cxx) initialize all LUA variables for LUA routing - status port configuration (MaxStatusClients, StatusEventBacklog, StatusEventBacklogRegex) now changable at runtime - BUGFIX(GkStatus.cxx) fix StatusEventBacklogRegex for patterns that start at the beginning of the event line - BUGFIX(ProxyChannel.cxx) use RealPresence Group 0-Byte keep-alive for IgnoreSignaledH239PrivateIPs (needs LARGE_FDSET to work) - new switches to set database connect and read timeout (only used by MySQL for now) - new switch to set worker thread idle timeout: [Gatekeeper::Main] WorkerThreadIdleTimeout= - BUGFIX(gk.cxx) better test for gatekeeper shutdown - BUGFIX(Routing.cxx) fix fromIP for ARQ and LRQ RouteRequests - BUGFIX(gkauth.cxx) only call Q.931 checks when activated - BUGFIX(Routing.cxx) fix RouteRequest from unregistered caller who doesn't provide any alias - new switch: [RoutedMode] DisableSettingUDPSourceIP=1

1 0

Issue with H.263 codecs set
by Iurii Gordiienko 01 Feb '16

01 Feb '16

Hi all, I need an advice - how to work with set of H.263 codecs. Basically, I have all H.263 codec types capability implemented: H.263, H.263-1998 and H.263-2000. All these capabilities uses same H245_VideoCapability::e_h263VideoCapability value for GetSubType function. In result my localCapabilities variable has all these 3 capabilities as well. When I receiving remote capabilities the remoteCapabilities variable is loading by H323Capabilities::H323Capabilities(const H323Connection & connection, const H245_TerminalCapabilitySet & pdu) constructor and the function uses code like this (simplified): H323Capability * capability = localCapabilities.FindCapability(pdu.m_capabilityTable[i].m_capability, capabilityNo, pdu); if (capability != NULL) { H323Capability * copy = (H323Capability *)capability->Clone(); copy->SetCapabilityNumber(capabilityNo); if (copy->OnReceivedPDU(pdu.m_capabilityTable[i].m_capability)) table.Append(copy); else delete copy; } The main issue - localCapabilities.FindCapability function returns any first H.263 Capability from it's table, no matter which particular H.263 remote Capability was used, it only checks MainType and SubType... In result if remote side send me, for example, H.263-1998, but I have H.263 and H.263-1998 - I will have H.263 in result... Now I'm trying to override Connection::OnReceivedCapabilitySet(const H245_TerminalCapabilitySet & pdu) function, extract H.263 codecs manually, store all these capabilities and update remoteCapabilities after, but may be exists a proper solution for this case? Thanks -- Iurii Gordiienko

3 4

Bug inH323Capabilities::Remove(H323Capability*)
by Iurii Gordiienko 31 Jan '16

31 Jan '16

Hi, I found a bug - H323Capabilities::Remove function will skip item when doing .RemoveAt operation. In result I have had a crash (in line if (set[outer][middle][inner].GetCapabilityNumber() == capabilityNumber)) for some sets of capabilities. I can't understand why the crash is occurs but in any way... Original code: void H323Capabilities::Remove(H323Capability * capability) { if (capability == NULL) return; PTRACE(3, "H323\tRemoving capability: " << *capability); unsigned capabilityNumber = capability->GetCapabilityNumber(); for (PINDEX outer = 0; outer < set.GetSize(); outer++) { for (PINDEX middle = 0; middle < set[outer].GetSize(); middle++) { for (PINDEX inner = 0; inner < set[outer][middle].GetSize(); inner++) { if (set[outer][middle][inner].GetCapabilityNumber() == capabilityNumber) { set[outer][middle].RemoveAt(inner); break; } } if (set[outer][middle].GetSize() == 0) set[outer].RemoveAt(middle); } if (set[outer].GetSize() == 0) set.RemoveAt(outer); } My fix: void H323Capabilities::Remove(H323Capability * capability) { if (capability == NULL) return; PTRACE(3, "H323\tRemoving capability: " << *capability); unsigned capabilityNumber = capability->GetCapabilityNumber(); for (PINDEX outer = 0; outer < set.GetSize(); ) { for (PINDEX middle = 0; middle < set[outer].GetSize(); ) { for (PINDEX inner = 0; inner < set[outer][middle].GetSize(); inner++) { if (set[outer][middle][inner].GetCapabilityNumber() == capabilityNumber) { set[outer][middle].RemoveAt(inner); break; } } if (set[outer][middle].GetSize()) ++middle; else set[outer].RemoveAt(middle); } if (set[outer].GetSize()) ++outer; else set.RemoveAt(outer); } Thanks -- Iurii Gordiienko

2 1

Double-delete Capability bug
by Iurii Gordiienko 25 Jan '16

25 Jan '16

Hi, I have found something... For H323ExtendedVideoCapability::AddAllCapabilities function we are using H323CodecExtendedVideoCapability::AddCapability function for extCapability->AddCapability(*r). H323CodecExtendedVideoCapability::AddCapability function uses extCapabilities.Add(H323ExtendedVideoFactory::CreateInstance(cap)) function. The function H323ExtendedVideoFactory::CreateInstance(cap) will call "new" if any same "cap" does not is exists for now< for other case it will return the pointer to current actual Capability. But H323CodecExtendedVideoCapability::extCapabilities will delete all items in time of execution extCapabilities.RemoveAll() function from H323CodecExtendedVideoCapability::~H323CodecExtendedVideoCapability(). In result we have "double delete" and undefined behavior (crash for worst case). -------------------------------- void H323ExtendedVideoCapability::AddAllCapabilities( H323Capabilities & basecapabilities, PINDEX descriptorNum,PINDEX simultaneous) { H323ExtendedVideoFactory::KeyList_T extCaps = H323ExtendedVideoFactory::GetKeyList(); if (extCaps.size() > 0) { H323CodecExtendedVideoCapability * capability = new H323CodecExtendedVideoCapability(); H323ExtendedVideoFactory::KeyList_T::const_iterator r; PINDEX num = P_MAX_INDEX; for (r = extCaps.begin(); r != extCaps.end(); ++r) { H323CodecExtendedVideoCapability * extCapability = (H323CodecExtendedVideoCapability *)capability->Clone(); extCapability->AddCapability(*r); num = basecapabilities.SetCapability(descriptorNum, simultaneous,extCapability); simultaneous = num; } simultaneous = P_MAX_INDEX; basecapabilities.SetCapability(descriptorNum, simultaneous,new H323ControlExtendedVideoCapability()); delete capability; } } void H323CodecExtendedVideoCapability::AddCapability(const PString & cap) { extCapabilities.Add(H323ExtendedVideoFactory::CreateInstance(cap)); } ------------------------------------------------- I propose to replace the "void H323CodecExtendedVideoCapability::AddCapability(const PString & cap)" to this one: void H323CodecExtendedVideoCapability::AddCapability(const PString & cap) { extCapabilities.Add(H323ExtendedVideoFactory::CreateInstance(cap)->clone()); } Thanks -- Iurii Gordiienko

3 7

H323EndPoint::ParsePartyName issue
by Iurii Gordiienko 22 Jan '16

22 Jan '16

Hi, I'm working with ForwardCall functional and have found a bug if we have forward URL which contains PORT number. For example, for h323:@192.168.1.1:1726 input string H323EndPoint::ParsePartyName will make address string like ip$192.168.1.1:1726:1726. The fix is trivial (may be I've not covered all cases): // get the various parts of the name PString hostOnly = PString(); PINDEX userPos = remoteParty.Find('@'); if (userPos != P_MAX_INDEX) { if (gatekeeper != NULL) alias = url.AsString(); else { alias = remoteParty.Left(userPos); PINDEX portPos = remoteParty.FindLast(':', portPos + 1); PINDEX len = (portPos != P_MAX_INDEX) ? (portPos - userPos - 1) : P_MAX_INDEX; hostOnly = remoteParty.Mid(userPos+1, len); } } else { alias = url.GetUserName(); hostOnly = url.GetHostName(); } address = hostOnly; Also we have similar issue for input string without '@' character. In this case PTLIB::PURL class wrong parse the string (uses 192.168.1.1:1726:1726 as USER). To fix this issue we need look PTLIB::PURL class futher. Thanks -- Iurii Gordiienko

2 1

Twice H323Connection::Unlock() call issue
by Iurii Gordiienko 22 Jan '16

22 Jan '16

Hi, I have found a bug with twice H323Connection::Unlock() call if we have an connection issue. Take a look: 1.We are running connection.SendSignalSetup function from H225CallThread::Main() and if it returns any reason!=H323Connection::EndedByCallerAbort we will Unlock the connection. void H225CallThread::Main() { PTRACE(3, "H225\tStarted call thread"); if (connection.Lock()) { H323Connection::CallEndReason reason = connection.SendSignalSetup(alias, address); // Special case, if we aborted the call then already will be unlocked if (reason != H323Connection::EndedByCallerAbort) connection.Unlock(); // bla-bla-bla } 2.But we have case when connection.SendSignalSetup returns non H323Connection::EndedByCallerAbort reason but has own unlocked state - for this case PTLIB will unlock the mutex twice with assert (as minimum) message. H323Connection::SendSignalSetup(const PString & alias, const H323TransportAddress & address) { //bla-bla-bla // Release the mutex as can deadlock trying to clear call during connect. Unlock(); PBoolean connectFailed = false; if (!signallingChannel->IsOpen()) { signallingChannel->SetWriteTimeout(100); connectFailed = !signallingChannel->Connect(); } // See if transport connect failed, abort if so. if (connectFailed) { connectionState = NoConnectionActive; switch (signallingChannel->GetErrorNumber()) { case ENETUNREACH : return EndedByUnreachable; case ECONNREFUSED : return EndedByNoEndPoint; case ETIMEDOUT : return EndedByHostOffline; } return EndedByConnectFail; } } Thanks -- Iurii Gordiienko

2 3

H323Connection concurrent access issue
by Iurii Gordiienko 22 Jan '16

22 Jan '16

Hi all, I found an issue with concurrent access during work with H323Connection. Take a look on H46018Transport::HandleH46018SignallingChannelPDU(PThread * thread) Simplest schema of this function running: thread1: H46018Transport::HandleH46018SignallingChannelPDU(PThread * thread) { ... H323Connection * connection = endpoint.CreateConnection(callReference, NULL, this, &pdu); ... connection->AttachSignalChannel(token, this, true); ... connection->HandleSignallingChannel(); ... return connection->HadAnsweredCall(); } The function connection->HandleSignallingChannel() in really working with "this" (H46018Transport object) all time in the while-loop. thread2: H323EndPoint::CleanUpConnections() running. In this thread we are running: 1.connection.CleanUpOnCallEnd() - this function will call CleanUpOnTermination() for signallingChannel (H46018Transport object) which running in connection->HandleSignallingChannel() function. 2.delete current H323Connection (which will delete our signallingChannel object also) The concurrent access issue - in time when we are running connection->HandleSignallingChannel() function from thread1, the H323Connection object can be deleted and signallingChannel will points to dead object - we have a crash in result. Also it is possible to run the connection->HadAnsweredCall() function for dead "connection" object. I have had the crash several times for this situation. Thanks -- Iurii Gordiienko

1 0

H323EndPoint::InternalMakeCall bug
by Iurii Gordiienko 03 Jan '16

03 Jan '16

Hi, I have found an issue with H323EndPoint::InternalMakeCall function for case when it running from H323EndPoint::ForwardConnection function (may be for some others cases too). Take a look: 1.We are trying to connect to some host which uses Gatekeeper. 2.From H323EndPoint::ForwardConnection call H323EndPoint::InternalMakeCall function with some internal token="ip$xxx.xxx.xxx.xxx/port" 3.In the body of H323EndPoint::InternalMakeCall we have the replacement current callToken-connection pair to new one with "ip$xxx.xxx.xxx.xxx/port-replaced-1" string, like connectionsActive.SetAt(adjustedToken, connectionsActive.RemoveAt(newToken)); connectionsToBeCleaned += adjustedToken; 4.But if for some reason our virtual CreateConnection function returns NULL... connection = CreateConnection(lastReference, userData, transport, NULL); if (connection == NULL) { PTRACE(1, "H323\tCreateConnection returned NULL"); connectionsMutex.Signal(); return NULL; } ... we cannot clear current Connection because it has not actual callToken "ip$xxx.xxx.xxx.xxx/port" but H323EndPoint::connectionsActive has "ip$xxx.xxx.xxx.xxx/port-replaced-1" and endpoint.ClearCall(callToken, reason) or something similar will be failed because not able to found the Connection by own callToken. 5.Also we have redundant call connectionsMutex.Signal(). if (connection == NULL) { PTRACE(1, "H323\tCreateConnection returned NULL"); connectionsMutex.Signal(); return NULL; } My proposition - just rename back callToken for H323EndPoint::connectionsActive and remove adjustedToken from H323EndPoint::connectionsToBeCleaned if we have NULL connection. My H323EndPoint::InternalMakeCall function looks like this: H323Connection * H323EndPoint::InternalMakeCall(const PString & trasferFromToken, const PString & callIdentity, unsigned capabilityLevel, const PString & remoteParty, H323Transport * transport, PString & newToken, void * userData, PBoolean supplimentary ) { PTRACE(2, "H323\tMaking call to: " << remoteParty); PString alias; H323TransportAddress address; if (!ParsePartyName(remoteParty, alias, address)) { PTRACE(2, "H323\tCould not parse \"" << remoteParty << '"'); return NULL; } #ifdef H323_H46017 // If H.460.17 use the existing H.460.17 Transport if (transport == NULL && RegisteredWithH46017()) transport = GetH46017Transport(); #endif if (transport == NULL) { // Restriction: the call must be made on the same transport as the one // that the gatekeeper is using. if (gatekeeper != NULL) transport = gatekeeper->GetTransport().GetRemoteAddress().CreateTransport(*this); // assume address is an IP address/hostname else transport = address.CreateTransport(*this); if (transport == NULL) { PTRACE(1, "H323\tInvalid transport in \"" << remoteParty << '"'); return NULL; } } H323Connection * connection; connectionsMutex.Wait(); PString adjustedToken; unsigned lastReference; if (newToken.IsEmpty()) { do { lastReference = Q931::GenerateCallReference(); newToken = BuildConnectionToken(*transport, lastReference, FALSE); } while (connectionsActive.Contains(newToken)); } else { lastReference = newToken.Mid(newToken.Find('/')+1).AsUnsigned(); // Move old connection on token to new value and flag for removal unsigned tieBreaker = 0; do { adjustedToken = newToken + "-replaced"; adjustedToken.sprintf("-%u", ++tieBreaker); } while (connectionsActive.Contains(adjustedToken)); connectionsActive.SetAt(adjustedToken, connectionsActive.RemoveAt(newToken)); connectionsToBeCleaned += adjustedToken; PTRACE(3, "H323\tOverwriting call " << newToken << ", renamed to " << adjustedToken); } connectionsMutex.Signal(); connection = CreateConnection(lastReference, userData, transport, NULL); if (connection == NULL) { PTRACE(1, "H323\tCreateConnection returned NULL"); if (!adjustedToken.IsEmpty()) { connectionsMutex.Wait(); connectionsActive.SetAt(newToken, connectionsActive.RemoveAt(adjustedToken)); connectionsToBeCleaned -= adjustedToken; PTRACE(3, "H323\tOverwriting call " << adjustedToken << ", renamed to " << newToken); connectionsMutex.Signal(); } return NULL; } connection->SetRemotePartyName(remoteParty); if (supplimentary) connection->SetNonCallConnection(); connection->Lock(); connectionsMutex.Wait(); connectionsActive.SetAt(newToken, connection); connectionsMutex.Signal(); connection->AttachSignalChannel(newToken, transport, FALSE); #ifdef H323_H450 if (capabilityLevel == UINT_MAX) connection->HandleTransferCall(trasferFromToken, callIdentity); else { connection->HandleIntrudeCall(trasferFromToken, callIdentity); connection->IntrudeCall(capabilityLevel); } #endif PTRACE(3, "H323\tCreated new connection: " << newToken); #ifdef H323_H46017 if (RegisteredWithH46017()) { H323Connection::CallEndReason reason = connection->SendSignalSetup(alias, address); if (reason != H323Connection::NumCallEndReasons) connection->ClearCall(reason); } else #endif new H225CallThread(*this, *connection, *transport, alias, address); return connection; } Thanks -- Iurii Gordiienko

2 1

H323CodecExtendedVideoCapability::OnSendingPDUstrange behavior
by Iurii Gordiienko 28 Dec '15

28 Dec '15

Hi, Take a look on the H323CodecExtendedVideoCapability::OnSendingPDU function. I have had some issues with Extended capabilities and have fixed the issue only after change the view order - we need to look the .table first and only if it empty - work with extCapabilities. For current implementation we always work the extCapabilities only because it always has GetSize()>0 (otherwise we return FALSE at the beginning of this function). PBoolean H323CodecExtendedVideoCapability::OnSendingPDU(H245_VideoCapability & pdu, CommandType ctype) const { if (extCapabilities.GetSize() == 0) return FALSE; // bla-bla-bla if (extCapabilities.GetSize() > 0) { caps.SetSize(extCapabilities.GetSize()); for (PINDEX i=0; i< extCapabilities.GetSize(); i++) { H245_VideoCapability vidcap; ((H323VideoCapability &)extCapabilities[i]).OnSendingPDU(vidcap,ctype); caps[i] = vidcap; } } else { caps.SetSize(table.GetSize()); for (PINDEX i=0; i< table.GetSize(); i++) { H245_VideoCapability vidcap; ((H323VideoCapability &)table[i]).OnSendingPDU(vidcap,ctype); caps[i] = vidcap; } } return TRUE; } Thanks -- Iurii Gordiienko

1 0

GNU Gatekeeper 4.0 released
by Jan Willamowius 03 Dec '15

03 Dec '15

I am pleased to announce the release of GNU Gatekeeper 4.0. It is now available from http://www.gnugk.org/h323download.html. This release includes source code suitable for Linux, Windows, MacOS X, FreeBSD, NetBSD, OpenBSD and Solaris and executables for Linux. GnuGk 4.0 includes many new features as well as some important bug fixes, but remains fully compatible with your previous configuration files. Whats new ? - rewrite of the H.235 password authentication - much better interoperability and much more secure (it is high time to get ride of MD5 based authentication!) - IP authentication for all RAS and Q.931 messages - important IPv6 updates and fixes - support for TCS0 call transfers ("reroute") that can be initiated from applications - better NAT traversal support for unregistered endpoints - better blocking of spam calls using SQLAuth - per endpoint codec filtering - DisplayIE rewriting - more secure handling of status port passwords (only hash stored) - important fix for ODBC database driver - CalledPartyNumber IE rewriting for better Polycom interoperability - bug fixes Some of the new 4.0 features are discussed in more detail this blog post: http://blog.gnugk.org/2015/11/gnu-gatekeeper-40-features.html The full change log is appended below. 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 Changes from 3.9 to 4.0 ======================= - [...PasswordAuth] CheckID switch is now deprecated, use [H235] CheckSendersID instead - provide vendor informations from ARQ or Setup as %{Vendor} in SQLAuth CallQuery - prepend timestamp to events in status port backlog - BUGFIX(Routing.cxx) remove newlines from vendor string before sending out RouteRequest to virtual queue - BUGFIX(gksql_odbc.cxx) fix DSN initialization when having multiple DSNs at the same time - new switch: [RoutedMode] UpdateCalledPartyToH225Destination=1 to always rewrite the CalledPartyNumberIE in Setup to the first E.164 of the H.225 destinationAddress - BUGFIX(ProxyChannel.cxx) fix crash on shutdown - new settings for [RoutedMode] ScreenDisplayIE=: 'Calling', 'Called', 'CallingCalled' to set the DisplayIE to the (rewritten) caller ID - new switch: [RoutedMode] AppendToDisplayIE= to add a string to the DisplayIE when ScreenDisplayIE= is on - changed default: H.460.18 keep-alive in traversal zone between neighbors now defaults to 19 sec (was 29) - new switch: [RoutedMode] H46018KeepAliveInterval= - BUGFIX(ProxyChannel.cxx) better port detection for H.239 when IgnoreSignaledPrivateH239IPs=1 - BUGFIX(gkacct.cxx) %{caller-port} and %{called-port} now default to "0" instead of the empty string when not available (eg. in direct mode) to avoid SQL errors when they are stored in a numeric column - BUGFIX(RasSrv.cxx) fix additive registration with parent gatekeeper - BUGFIX(ProxyChannel.cxx) fix IPv6 dual-stack proxy on Linux and Windows - dump file descriptor usage on USR2 signal (Linux only) - new switch [RoutedMode] DisableFastStart=1 - support for H.235.1, incl. setting and checking tokens in all RAS and Q.931 messages - extend SimplePasswordAuth and FileIPAuth to all RAS and all Q.931 messages - store only PBKDF2 hash for [GkStatus::Auth] password in config, not a recoverable password - BUGFIX(ProxyChannel.cxx) fix crash when receiving message without UUIE - new switch [EP::] DisabledCodecs= - much improved TCS0 3rd-party call transfer using 'Reroute' command on status port - BUGFIX(Routing.cxx) add field for destination alias in ARQ if missing and a dynamic routing policy sets it - BUGFIX(ProxyChannel.cxx) fix crash in H.235 Media for endpoints with more than 64 capability entries in TCS - new switch [Proxy] AllowSignaledIPs= to skip to skip auto-detect for network when IgnoreSignaledIPs=1

1 0

OpenExtendedChannel SessionID
by Ankur Deep Jaiswal 16 Sep '15

16 Sep '15

Hi, some devices reject the OLC of extended channel if the sessionid is 0(default), with (OLC reject) invalidsessionid. This is defined in file h323caps.cxx, OnH239GenericMessageResponse as defaultSession=0, after changing the value to 3. the OLC is accepted. In the attached mail-list discussion it is mentioned that sessionid should not be 0 ( http://lists.packetizer.com/pipermail/h323plus/2009-December/002105.html) h323plus displays forgiving nature in this case. it happily accepts a sessionid of 0 in an extended channel. please advise on this behaviour. -- Ankur Deep Jaiswal

1 0

H323Transport GetLocalAddress bug using PTLIB>=2.11
by Jose Uceda 23 Jul '15

23 Jul '15

We discovered this bug trying to register an endpoint (ip 62.22.27.131) to a gatekeeper (ip 62.22.20.229), using H323Plus v1.26.5 w ptlib 2.12.8. As you can see in the trace log: ------------------------ 0:00.010 Yate H323G...f3d7464700 transports.cxx(2363) RAS Gatekeeper discovery on interface: 62.22.27.131:59483 0:00.021 Yate H323G...f3d7464700 h323pdu.cxx(79) Trans Sending PDU [ip$62.22.27.131:59483/ip$62.22.20.229:1719] : gatekeeperRequest { requestSeqNum = 36153 protocolIdentifier = 0.0.8.2250.0.7 rasAddress = ipAddress { ip = 4 octets { 3e 16 1b 83 >... } port = 59483 } ^^^--- We see our RAS Address is set correctly (3e 16 1b 83 = 62.22.27.131) and port 59483 ... rest of the PDU trace has been trimmed ... } 0:00.076 Yate H323G...f3d7464700 h323pdu.cxx(79) H225RAS Receiving PDU [ip$62.22.20.229:54287/ip$62.22.20.229:1719] : gatekeeperConfirm { requestSeqNum = 36153 protocolIdentifier = 0.0.8.2250.0.7 gatekeeperIdentifier = 9 characters { 0047 004b 0040 0070 0070 0063 0069 0067 GK@ppcig 006b k } rasAddress = ipAddress { ip = 4 octets { 3e 16 14 e5 >... } port = 1719 } } Raw PDU: size=25 pos=25.0 { 000 04 80 8d 38 06 00 08 91 4a 00 07 10 00 47 00 4b 8 J G K 00 40 00 70 00 70 00 63 00 69 00 67 00 6b 00 3e @ p p c i g k > 16 14 e5 06 b7 } 0:00.076 Yate H323G...f3d7464700 gkclient.cxx(288) RAS Gatekeeper discovery found ip$62.22.20.229:1719 0:00.076 Yate H323G...f3d7464700 transports.cxx(2461) RAS Gatekeeper discovered at: 62.22.20.229:1719 (if=62.22.27.131:59483) ^^^^---- this transport still has the correct interface / local ip 0:00.076 Yate H323G...f3d7464700 osutil.cxx(189) PTLib File handle high water mark set: 26 Thread unblock pipe 0:00.077 Yate H323G...f3d7464700 tlibthrd.cxx(305) PTLib Created thread 0x7ff3b4008420 Transactor:%x 0:00.077 PTLib Hous...f3d7568700 osutils.cxx(2158) PTLib Cleaning 1 AutoDelete threads 0:00.077 Transactor:d31ab700 tlibthrd.cxx(354) PTLib Started thread 0x7ff3b4008420 (5287) "Transactor:d31ab700" 0:00.077 Transactor:d31ab700 h323trans.cxx(266) Trans Starting listener thread on Transport[remote=ip$62.22.20.229:1719 if=ip$62.22.20.229:54287] ^^^--- See that this new transport has a wrong "if=" (with remote GK address not our local address) 0:00.077 Yate H323G...f3d7464700 transports.cxx(749) TCP Appending H.225 transport ip$62.22.27.131:2720 using associated transport Transport[remote=ip$62.22.20.229:1719 if=ip$62.22.20.229:54287] 0:00.077 Transactor:d31ab700 h323trans.cxx(274) Trans Reading PDU 0:00.077 Transactor:d31ab700 tlibthrd.cxx(1012) PTLib PThread::PXBlockOnIO(22,0) 0:00.077 Yate H323G...f3d7464700 h323trans.cxx(435) Trans Making request: registrationRequest 0:00.077 Yate H323G...f3d7464700 h323pdu.cxx(79) Trans Sending PDU [ip$62.22.20.229:54287/ip$62.22.20.229:1719] : registrationRequest { requestSeqNum = 36154 protocolIdentifier = 0.0.8.2250.0.7 discoveryComplete = true callSignalAddress = 1 entries { [0]=ipAddress { ip = 4 octets { 3e 16 1b 83 >... } port = 2720 } ^^^---- callSignalAddress is our endpoint IP address (62.22.27.131). Ok } rasAddress = 1 entries { [0]=ipAddress { ip = 4 octets { 3e 16 14 e5 >... } port = 59483 } } ^^^--- rasAddress has been set incorrectly to the remote gatekeeper address (62.22.20.229) although the port is OK (it's the same used in the previous GRQ pdu) } ------------------- By looking at the source code: In transports.cxx, function H323TransportUDP::ReadPDU: PBoolean H323TransportUDP::ReadPDU(PBYTEArray & pdu) #if PTLIB_VER >= 2110 if (canGetInterface) { WORD notused; // TODO: verify that this actually does the same as the pre 2.11.x version socket->GetLastReceiveAddress(lastReceivedInterface, notused); } #else if (canGetInterface) lastReceivedInterface = socket->GetLastReceiveToAddress(); #endif Since the PTLIB's version we are using is 2.12.8, the compiled code is as follows: WORD notused; // TODO: verify that this actually does the same as the pre 2.11.x version socket->GetLastReceiveAddress(lastReceivedInterface, notused); Be noticed the comment and that the name of the called function is not the same as the pre 2.11.x code: GetLastReceiveAddress() vs GetLastReceiveToAddress() GetLastReceiveToAddress() returned local ip address but this function has been removed from PTLib and the existing function (the one is used) GetLastReceiveAddress returns the address of the *sender* in the last connection. Due to use GetLastReceiveAddress, now lastReceivedInterface has the remote ip (62.22.20.229). And lastReceivedInterface is used in the function H323TransportUDP::GetLocalAddress(): H323TransportAddress H323TransportUDP::GetLocalAddress() const { if (canGetInterface && !lastReceivedInterface.IsLoopback()) return H323TransportAddress(lastReceivedInterface, interfacePort); ..... returning lastReceivedInterface (62.22.20.229) as our local address incorrectly. The GetLocalAddress function is used in many places so this can cause many problems as the one we have spotted here.

3 2

h323ep.cxx - Number translation problems.
by Francisco Olarte 23 Jul '15

23 Jul '15

A little background info: We use yate with h323plus to make calls, currently h323+ 1.25.0, yate 5.5. In our system we use '#' extensively to delimit routing info ( as we use variable length prefixes, this makes them unique and we can distinguish between 10+347... and 103+47....). But one day we used ## in a special prefix and the calls began to fail. We saw yate thar when dialing "0##666#88820334661" we ended up with the following ( every phne number redacted, cut last six numbers of phones for privacy ) pdu in the gatekeeper: admissionRequest { requestSeqNum = 32114 callType = pointToPoint <<null>> endpointIdentifier = 12 characters { .... } destinationInfo = 1 entries { [0]=url_ID "666%2388820334661@0" } ..... } which lead to a rejected call. We expected something on the line ( from another PDU without double hash ): admissionRequest { ... destinationInfo = 1 entries { [0]=dialedDigits "100#00543414" } ... } like: destinationInfo = 1 entries { [0]=dialedDigits "0##666#88820334661" } an url instead of "0#34666666666" to the gatekeeper. After further examination we found the following in h323+ 1.25.0: [src]$ fgrep -R -C7 '"##"' h323plus/ h323plus/src/h323ep.cxx-PBoolean H323EndPoint::ParsePartyName(const PString & _remoteParty, h323plus/src/h323ep.cxx- PString & alias, h323plus/src/h323ep.cxx- H323TransportAddress & address) h323plus/src/h323ep.cxx-{ h323plus/src/h323ep.cxx- PString remoteParty = _remoteParty; h323plus/src/h323ep.cxx- h323plus/src/h323ep.cxx- // Support [address]##[Alias] dialing h323plus/src/h323ep.cxx: PINDEX hash = _remoteParty.Find("##"); h323plus/src/h323ep.cxx- if (hash != P_MAX_INDEX) { h323plus/src/h323ep.cxx- remoteParty = "h323:" + _remoteParty.Mid(hash+2) + "@" + _remoteParty.Left(hash); h323plus/src/h323ep.cxx- PTRACE(4, "H323\tConverted " << _remoteParty << " to " << remoteParty); h323plus/src/h323ep.cxx- } h323plus/src/h323ep.cxx- h323plus/src/h323ep.cxx- //check if IPv6 address h323plus/src/h323ep.cxx- PINDEX ipv6 = remoteParty.Find("::"); Well, it seems some function which should ( IMO ) be in the gatekeeper or the dialer as been grafted inside the generic endpoint code. Not too big a problem. We just developed a patch to zap the code patch and followed on. But then, we had a look ar h323plus 1.25.4 and found: PString remoteParty = _remoteParty; // Support [address]##[Alias] dialing PINDEX hash = _remoteParty.Find("##"); if (hash != P_MAX_INDEX) { remoteParty = "h323:" + _remoteParty.Mid(hash+2) + "@" + _remoteParty.Left(hash); PTRACE(4, "H323\tConverted " << _remoteParty << " to " << remoteParty); } PINDEX phash = _remoteParty.Find("#"); if (phash != P_MAX_INDEX) { remoteParty.Replace("#","%"); PTRACE(4, "H323\tAdjusted " << remoteParty); } //check if IPv6 address PINDEX ipv6 = remoteParty.Find("::"); Which is worst, now we can even use a single #. I wonder what is the rationale for doing this kind of transformations. We are developing another patch for this, but fear the future. For me it looks like this is trying to overcome the limitations of some device so the user can dial URLs ? IP ? from the phone keyboard, but on the way they are destroying our routing, and as they are buried deep inside the lib ( where I personally think they shouldn't be ) they are tricky to detect and fix. Shouldn't this kind of legal-number-destroying functionality be relegated to an overridable method, or just delegated to the client code? Is this going to go on ( I mean, more exotic translations on otherwise legal dialedDigits ) ? And I'm not the only one using '#' in the digits, some of our providers do it too. Regards. Francisco Olarte.

3 7

GNU Gatekeeper 3.9 is available
by Jan Willamowius 10 Jul '15

10 Jul '15

I am pleased to announce a new release of the GNU Gatekeeper, version 3.9, now available from http://www.gnugk.org/h323download.html. This release includes source code suitable for Linux, Windows, MacOS X, FreeBSD, NetBSD, OpenBSD and Solaris and executables for Linux. -- Jan Whats new in GnuGk 3.9 ? - bug fixes, including a crash and hanging status port on Windows servers - a new IP/port detection algorithm for endpoints behind NAT that works well even with unregistered (!) endpoint H.460 NAT traversal requires all endpoints to register with their gatekeeper. Thus users have to enter IPs in config dialogs etc. With this new port detection, they can start making calls right away to <alias>@<gatekeeper IP> or <gatekeeper IP>##<alias>. - neighbor pings to speed up call routing if your neighbors are frequently down Neighbors get pinged with an LRQ and if they don't respond with either LCF or LRJ GnuGk will skip them in the call routing without waiting for a timeout. - geo-blocking with the GeoIPAuth policy, you can allow or block calls based on the location of the IP - status port event back log When you connect to the status port to diagnose an issue, the relevant events are already gone. With this new feature you can tell GnuGk to save the last n events and show them later on. This way you can take a look at eg. the last 100 failed registrations etc. - QoS DiffServ marking for RAS, H.225 and H.245 messages (based on a patch provided by Vidyo) Now you can set the DiffServ class for signaling messages. Previously you could only mark RTP packets. - support for H.235.TSSM H.235 needs time synchronization between gatekeeper and endpoints and the proposed H.235.TSSM standard provides a means for endpoints to detect that they are not in sync with the gatekeeper and apply a time offset. Download from http://www.gnugk.org/h323download.html -- 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

H323connection AnsweringCall issue
by Ankur Deep Jaiswal 09 Jun '15

09 Jun '15

Hi, I am facing a strange problem, on H323Connection::OnAnswerCall i am returning AnswerCallPending. and after sometime i call H323Connection::AnsweringCall with AnswerCallNow . but what happens now and then, i would say every second call, is that, even if i call H323Connection::AnsweringCall, the PDU does not seem to have been sent. the connection then proceeds to be in a vegetative state. when i disconnect the connection and reconnect it, it proceeds to connect successfully. i am not creating any extra threads in the system. the logic for H323Connection::AnsweringCall runs on the main thread. i am using h323plus version 1.26.5. regards -- Ankur Deep Jaiswal

4 7

H323Plus User Survey
by Jan Willamowius 18 May '15

18 May '15

Dear Community, we would like to learn a bit more about the users of the H323Plus project: What do you like, what is missing etc. Please fill out this short questionnaire and help us decide where the project should be heading: http://www.gnugk.org/h323plus-survey.html Thanks for your time! -- Jan Willamowius, Founder of the GNU Gatekeeper Project (and H323Plus developer since 1999) 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 1

h323plus - GetConnectedNumber
by Tarmo Aia 10 May '15

10 May '15

Hi! I dealt with problem, that user picked up the call from the hunt group but the call manager did not changed the Remote Party number but only affected the Q931 connect message with IE Connected Number property. I added a little function called SetRemoteConnectedNumber to h323.cxx to read it and change to the remote party number during answer (connection). Not sure this is the 100% right way but I would contribute this small line of code if You have interest. Tested working with Avaya Call manager 6.x Best regards, Tarmo Aia

2 1

GNU Gatekeeper Survey
by Jan Willamowius 08 Apr '15

08 Apr '15

Dear all, I have prepared a short survey to learn more about how you use the GNU Gatekeeper, which features you use, what might be missing etc. Please take a moment to provide some feedback for the future direction of the project: http://www.gnugk.org/survey-2015.html Thanks! 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

Nagios plugin for H.323
by Jan Willamowius 05 Feb '15

05 Feb '15

Hi, I have released a Nagios plugin to monitor H.323 devices (any H.323 gatekeeper or gateway, it doesn't have to be GnuGk). http://www.gnugk.org/nagios-h323.html It doesn't just check if the device listens to a port, but sends a real H.323 message (GRQ or LRQ) and checks if a well formed message comes back. Enjoy! -- 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

2 1

GNU Gatekeeper 3.8 is available
by Jan Willamowius 05 Jan '15

05 Jan '15

I am pleased to announce a new release of the GNU Gatekeeper, version 3.8, now available from http://www.gnugk.org/h323download.html. Please see the attached notes for details. This release includes source code suitable for (Linux, Windows, MacOS, FreeBSD, NetBSD, OpenBSD and Solaris) and executables for Linux. -- Jan Whats new in GnuGk 3.8 ? In response to the current wave of H.323 spam / hacking GnuGk 3.8 has a number of improvements to security related features and older versions should be updated. - endpoint IDs are now completely random and not as easily guessable as they were before - GnuGk is now using better random numbers in security relevant places - new authentication modules using LUA scripts called LuaAuth - new switch [RasSrv::ARQFeatures] CheckSenderIP=1 to make sure ARQs come from the same IP as the initial registration - FileIPAuth is now able to check ARQ messages - AliasAuth updated to work with H.460.18 endpoint - PrefixAuth was extended to support unregistered calls - SQLAuth can now operate on SrcInfo fields using %{SrcInfo} - improvements to the addpasswd utility for the new web interface Other new non-security related features include: - The CatchAll policy now rewrites the destination alias which makes it easier to send CatchAll calls to MCU rooms. - You can now filter out whole capability classes, eg. all video or H.239 capabilities if some of your endpoints have trouble handling them - A new switch [Gatekeeper::Main] MinH323Version= lets you set the H.323 version GnuGk identifies itself as using (up to the latest version 7). This is mainly to deal with endpoint that switch features when they believe they are talking to older endpoints (which one shouldn't be doing...) - a number bugs and crashes fixed Download from http://www.gnugk.org/h323download.html -- 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

maxBitrate in External RTP
by Ankur Deep Jaiswal 27 Aug '14

27 Aug '14

Hi, I have a doubt, How do you get Max-Bitrate supported by a Capability in H323_ExternalRTPChannel. Help appreciated. -- Ankur Deep Jaiswal

3 6

GNU Gatekeeper 3.7 has been released
by Jan Willamowius 15 Aug '14

15 Aug '14

Hi, I'm happy to announce version 3.7 of the GNU Gatekeeper. http://www.gnugk.org/h323download.html This is mainly a bugfix release that corrects a number of errors and crashes (see below). Please follow these compile instructions: http://www.gnugk.org/compiling-gnugk.html Enjoy! Detailed change log: - allow Comment= in all sections - new status port command: "debug cfg all" to print the full configuration - stub code to fake support for Avaya 2.16.840.1.114187.1.3 authentication (disabled by default) - BUGFIX(Neighbor.cxx) fix outbound rules for GWRewriteE164 with neighbors - BUGFIX(RasSrv.cxx) fix crash on shutdown - BUGFIX(gkauth.cxx) for passwort auth look at correct src or dest info - BUGFIX(Toolkit.cxx) more flexible column handling for [SQLConfig] PermanentEndpountsQuery, document priority and vendor info setting - BUGFIX(gksql_sqlite.cxx) return empty string for NULL columns, like the other DB drivers do - BUGFIX(RasTbl.cxx) fix formatting of PrintAllRegistrations and PrintAllRegistrationsVerbose - BUGFIX(GkStatus.cxx) better handling when status clients don't quit properly - BUGFIX(Toolkit.cxx) fix selection of reply address for IPv6 -- 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

Re: [h323plus] [Openh323gk-users] Using LibreSSL instead of OpenSSL with GnuGk / H323Plus / PTLib
by Jan Willamowius 29 Jul '14

29 Jul '14

It would be nice if PTLib would do a pgk-config check for "openssl" or "libressl" to activate the OpenSSL code. I simply named the pgk-config file for LibreSSL "openssl.pc" to work around that. To use GnuTLS for the H.323 media encryption in GnuGk and H323Plus, PSSLxxx wrappers won't help. The OpenSSL compatibility mode of GnuTLS also isn't enough. regards, Jan Robert Jongbloed wrote: > Excellent! > > Are there any tweaks to the configure.ac that should happen to find > LibreSSL? > > > And re GnuTLS, the whole point of the PSSLxxx class wrappers in PTLib > was to allow for use of other API's to OpenSSL/LibreSSL. At least as a > configure/compile time option. One of these years, someone may cough up > the time/money to actually do the implementation .... > > *Robert Jongbloed* > OPAL/OpenH323/PTLib Architect and Co-founder. > Commercial support at http://www.voxlucida.com.au > /Travelling, so email responses may be slow!/ > > Robert. On 29/07/2014 5:30 pm, Jan Willamowius wrote: > > Hi, > > > > with the bugs recently found in OpenSSL, there is some concern how many > > more issues still lurk in the old and crufty OpenSSL code. There is a > > great effort by some OpenBSD developers to fork OpenSSL into > > "LibreSSL" (www.libressl.org) and clean up the code while keeping the > > public interface stable. > > > > I did a quick check and can report that GnuGk / H323Plus / PTLib > > compile well with LibreSSL instead of OpenSSL. All I had to do was > > provide a pkg-config file. So now we have a choice which library to use. > > > > I used LibreSSL Portable 2.0.3 for my test. > > > > Another interesting project would be to use GnuTLS as a replacement, > > but thats going to require a number of code changes on our side. > > > > Regards, > > Jan > > > -- Jan Willamowius, jan(a)willamowius.de, http://www.gnugk.org/

1 0

Using LibreSSL instead of OpenSSL with GnuGk / H323Plus / PTLib
by Jan Willamowius 29 Jul '14

29 Jul '14

Hi, with the bugs recently found in OpenSSL, there is some concern how many more issues still lurk in the old and crufty OpenSSL code. There is a great effort by some OpenBSD developers to fork OpenSSL into "LibreSSL" (www.libressl.org) and clean up the code while keeping the public interface stable. I did a quick check and can report that GnuGk / H323Plus / PTLib compile well with LibreSSL instead of OpenSSL. All I had to do was provide a pkg-config file. So now we have a choice which library to use. I used LibreSSL Portable 2.0.3 for my test. Another interesting project would be to use GnuTLS as a replacement, but thats going to require a number of code changes on our side. 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

FW: [h323-announce] H.323 Update Following the Sapporo Meeting
by Simon Horne 19 Jul '14

19 Jul '14

FYI The updates will be included in H.323v8 Simon From: h323-announce-bounces(a)lists.packetizer.com [mailto:h323-announce-bounces@lists.packetizer.com] On Behalf Of Paul E. Jones Sent: Sunday, July 20, 2014 8:19 AM To: H.323 Announce List Subject: [h323-announce] H.323 Update Following the Sapporo Meeting <http://www.packetizer.com> Folks, The most recent ITU-T SG16 meeting was held in Sapporo, Japan 30 June - 11 July 2014. Perhaps most significant at this meeting relating to H.323 is the fact that we approved two new Recommendations related to Telepresence systems: * ITU-T Rec. F.734, "Definitions, requirements, and use cases for Telepresence Systems" * ITU-T Rec. H.420, "Telepresence System Architecture" Progress was also made on revisions to each of the core H.323 Recommendations, namely H.323, H.225.0, and H.245. Some of the enhancements introduced are to support Telepresence systems, including the CLUE signaling channel. Support for the WebRTC Data Channel was also introduced in H.245. Of course, the work on Telepresence and WebRTC support is not complete, but progress is being made. We also adopted baseline text for the end-to-end Session Identifier, which is work that was initiated a few years ago. The work is being progressed in both the IETF and ITU in parallel, with the IETF work nearing completion. This work will allow for the identification of a communication session end-to-end from the point of origin to the point of termination, even if the call is carried over a mixture of H.323 and SIP networks. I have updated the document status page here: http://www.packetizer.com/ipmc/h323/doc_status.html. This shows the current status of the various H.323-related work items in ITU-T SG16. Best regards, Paul E. Jones http://paulej.com/

1 0

Avaya Authentication methods
by Jan Willamowius 27 Jun '14

27 Jun '14

Hi, I was just discussing with Simon if anybody would need the Avaya authentication procedures OID 1.3.14.3.2.6 and OID 2.16.840.1.114187.1.3 in H323Plus. Both are said to be DES based, so they don't offer much security, but they can be useful with legacy equipment. I have an almost complete implementation for OID 1.3.14.3.2.6 in GnuGk, that just needs a little fleshing out for the encryption part which GnuGk doesn't need, before it can be moved into H323Plus. For OID 2.16.840.1.114187.1.3 I have some stub code that allows endpoints to register with GnuGk, but some crypto details are still uncertain. So, if anybody needs this stuff, please speak up. ;-) Cheers, 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

GNU Gatekeeper 3.6 has been released
by Jan Willamowius 07 May '14

07 May '14

Hi, I'm happy to announce version 3.6 of the GNU Gatekeeper. http://www.gnugk.org/h323download.html This version contains support for Polycom's domain##alias addressing, a new policy to route by URI prefix, better config checking, fixes for H.460.19 port detection and a number of other bugfixes and smaller features. I'm trying to cut down on the time I have to spend on each release, so I will only provide executable to support client for this version. Please follow these instructions to compile GnuGk yourself: http://www.gnugk.org/compiling-gnugk.html Detailed change log: - support Polycom's domain##alias addressing in DNS policy - new command line switch: --strict (don't start with config errors) - new routing policy [Routing::URIService] to define service specific URI routing policy. - allow SendTo= without AlternateGKs= switch - new switch [EP::...] ForceGateway=1 to treat an endpoint as a gateway - new switch [EP::...] AddCallingPartyToSourceAddress=1 - new switch [EP::...] DisableCallCreditCapabilities=1 - verify the correct payloadType on H.460.19 keep-alive packets (disable with [Proxy] CheckH46019KeepAlivePT=0) - support libssh 0.6.x - BUGFIX(ProxyChannel.cxx) fix memory leak on TLS errors - BUGFIX(RasTbl.cxx) use 64bit numbers for AddNumbers= ranges - BUGFIX(RasSrv.cxx) fill destCallSignallAddress in answer ACF in direct mode - BUGFIX(RasSrv.cxx) fix callSignalPort in LCF when H.460.22 is enabled - BUGFIX(ProxyChannel.cxx) read ProxyHandlerHighPrio switch earlier - BUGFIX(ProxyChannel.cxx) wait 4 sec before using regular RTP packets for H.460.19 port detection - BUGFIX(gk.cxx) small fixes for MacOSX -- 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

Null pointer reference
by Ankur Deep Jaiswal 05 May '14

05 May '14

Hi, I am using H323plus v 1.26.3. With the External rtp example, I am getting a 'Assertion fail: Null pointer reference, file channels.cxx, line 629, Error=22' while trying to open a channel with capability G.711-ALaw-64k. it happens at H323_ExternalRTPChannel::OnSendingPDU at line number 1329. Help appreciated -- Ankur Deep Jaiswal

3 7

OnConnectionEstablished fired twice in the same call
by Ankur Deep Jaiswal 08 Apr '14

08 Apr '14

Hi, I was testing h323plus v 1.26.0 using sample/simple. i have come across a scenario where OnConnectionEstablished is being called twice in the same call. i am attaching a level 4 trace file. Help appreciated. -- Ankur Deep Jaiswal

1 0

report bugs and seek help
by 李银城 06 Apr '14

06 Apr '14

Dear H323plus Team: I want to report some bugs(maybe) and seek help, for these days I'm installing the package and come across some problem. The first thing I want to mention is that when compiling the h235auth.cxx file, error occurs: [CC] h235auth.cxx h235auth.cxx: In member function ‘void H235Authenticators::PrepareSignalPDU(unsigned int, PASN_Array&, PASN_Array&, PINDEX) const’: h235auth.cxx:449:39: error: ‘m_maxTokenLength’ was not declared in this scope PINDEX keyLength = (max_keyLength > m_maxTokenLength) ? m_maxTokenLength : max_keyLength; I trace the source file and find that "m_maxTokenLength" actually defined in h235auth.h, but with a precompile header #ifdef H323_H235. Problem is that the function error occuring function PrepareSignalPDU doesn't wrapped by that header and use the wrapped variables which may not be defined. So if one can make the H323_H235 available, it will be cured. I trace through and find that this header require #define OPENSSL, so I install the package on windows(XP) then it really compile well. But on my Ubuntu, still fails. So I make the undefind variables out the precompile section and then the "make" progresses smoothly but I don't know what consequences will be. Secondly, I want to enable h263 feature, it requires the ffmpeg codec and I install the newest version 2.2. But it didn't work. Configure says: checking for LIBAVCODEC... yes configure: libavcodec stack align hack disabled checking for h263p_encoder in -lavcodec... no checking for h263p_encoder in -lavcodec... (cached) no checking for mpeg4_encoder in -lavcodec... no checking for h264_decoder in -lavcodec... no I think the "no" checks are the causes. Is " -lavcodec" are passed to ffmpeg as its arguments to check if it support the codecs? I check the ffmpeg's option and only find that ffmpeg has a similar option "codec" which list out all its suport codes where I find h264. There goes what I want to seek help: 1. The oh323tut require a wav file. What's its effects, a tmp file as a buff? The web says it requires the format 16 bit with 8000 Hz and I use cool edit software to produce such a wav file but the program still report wrong file format error. So I got stuck. 2. How can I catch video from my computer camera. I can't run the h323plus sample "simple", it crash when come to the call PVideoInputDevice::GetDeviceCapabilities in arg initialization. I debug and found that the ptlib function calls in a cycle: A call B; B call C; C call A. Then the stack runs out. So, what's the trouble here? How can I get my device name pass it to the program instead of "*"? Last but not least, I want to ask Is there any detailed tutorial to learn. I search the net using google, the valuable one is almost only the oh323tut. But the oh323tut is a little too simple. It only shows the audio feature. How is the video? The simple sample shows an example I guess I can try to understand. Is there any related code or project using H323plus, for example using glade to show the video. Best regards Yincheng Li South China Normal University ------------------

3 3

help
by 李银城 06 Apr '14

06 Apr '14

Dear H323plus Team: I want to report some bugs(maybe) and seek help, for these days I'm installing the package and come across some problem. The first thing I want to mention is that when compiling the h235auth.cxx file, error occurs: [CC] h235auth.cxx h235auth.cxx: In member function ‘void H235Authenticators::PrepareSignalPDU(unsigned int, PASN_Array&, PASN_Array&, PINDEX) const’: h235auth.cxx:449:39: error: ‘m_maxTokenLength’ was not declared in this scope PINDEX keyLength = (max_keyLength > m_maxTokenLength) ? m_maxTokenLength : max_keyLength; I trace the source file and find that "m_maxTokenLength" actually defined in h235auth.h, but with a precompile header #ifdef H323_H235. Problem is that the function error occuring function PrepareSignalPDU doesn't wrapped by that header and use the wrapped variables which may not be defined. So if one can make the H323_H235 available, it will be cured. I trace through and find that this header require #define OPENSSL, so I install the package on windows(XP) then it really compile well. But on my Ubuntu, still fails. So I make the undefind variables out the precompile section and then the "make" progresses smoothly but I don't know what consequences will be. Secondly, I want to enable h263 feature, it requires the ffmpeg codec and I install the newest version 2.2. But it didn't work. Configure says: checking for LIBAVCODEC... yes configure: libavcodec stack align hack disabled checking for h263p_encoder in -lavcodec... no checking for h263p_encoder in -lavcodec... (cached) no checking for mpeg4_encoder in -lavcodec... no checking for h264_decoder in -lavcodec... no I think the "no" checks are the causes. Is " -lavcodec" are passed to ffmpeg as its arguments to check if it support the codecs? I check the ffmpeg's option and only find that ffmpeg has a similar option "codec" which list out all its suport codes where I find h264. There goes what I want to seek help: 1. The oh323tut require a wav file. What's its effects, a tmp file as a buff? The web says it requires the format 16 bit with 8000 Hz and I use cool edit software to produce such a wav file but the program still report wrong file format error. So I got stuck. 2. How can I catch video from my computer camera. I can't run the h323plus sample "simple", it crash when come to the call PVideoInputDevice::GetDeviceCapabilities in arg initialization. I debug and found that the ptlib function calls in a cycle: A call B; B call C; C call A. Then the stack runs out. So, what's the trouble here? How can I get my device name pass it to the program instead of "*"? If pass -v option with "/dev/video0" or "USB2.0 Camera" it will says that: Using video driver USB2.0 Camera No Video Grabber available Disabling Video Support! And the audio also has some problem: Could not open sound device Null Audio - Check permissions or full duplex capability. Then I type c: Using video driver USB2.0 Camera No Video Grabber available Disabling Video Support! Last but not least, I want to ask Is there any detailed tutorial to learn. I search the net using google, the valuable one is almost only the oh323tut. But the oh323tut is a little too simple. It only shows the audio feature. How is the video? The simple sample shows an example I guess I can try to understand. Is there any related code or project using H323plus, for example using glade to show the video. A big job without a good explanation is less power full then something is useful and simple. By contract, Glade has many tutorial if one searches the net. I really really get stuck. Hope to receive from you! Thank you!! Best regards Yincheng Li South China Normal University ------------------

1 0

help
by 李银城 05 Apr '14

05 Apr '14

Dear H323plus Team: I want to report some bugs(maybe) and seek help, for these days I'm installing the package and come across some problem. The first thing I want to mention is that when compiling the h235auth.cxx file, error occurs: [CC] h235auth.cxx h235auth.cxx: In member function ‘void H235Authenticators::PrepareSignalPDU(unsigned int, PASN_Array&, PASN_Array&, PINDEX) const’: h235auth.cxx:449:39: error: ‘m_maxTokenLength’ was not declared in this scope PINDEX keyLength = (max_keyLength > m_maxTokenLength) ? m_maxTokenLength : max_keyLength; I trace the source file and find that "m_maxTokenLength" actually defined in h235auth.h, but with a precompile header #ifdef H323_H235. Problem is that the function error occuring function PrepareSignalPDU doesn't wrapped by that header and use the wrapped variables which may not be defined. So if one can make the H323_H235 available, it will be cured. I trace through and find that this header require #define OPENSSL, so I install the package on windows(XP) then it really compile well. But on my Ubuntu, still fails. So I make the undefind variables out the precompile section and then the "make" progresses smoothly but I don't know what consequences will be. Secondly, I want to enable h263 feature, it requires the ffmpeg codec and I install the newest version 2.2. But it didn't work. Configure says: checking for LIBAVCODEC... yes configure: libavcodec stack align hack disabled checking for h263p_encoder in -lavcodec... no checking for h263p_encoder in -lavcodec... (cached) no checking for mpeg4_encoder in -lavcodec... no checking for h264_decoder in -lavcodec... no I think the "no" checks are the causes. Is " -lavcodec" are passed to ffmpeg as its arguments to check if it support the codecs? I check the ffmpeg's option and only find that ffmpeg has a similar option "codec" which list out all its suport codes where I find h264. There goes what I want to seek help: 1. The oh323tut require a wav file. What's its effects, a tmp file as a buff? The web says it requires the format 16 bit with 8000 Hz and I use cool edit software to produce such a wav file but the program still report wrong file format error. So I got stuck. 2. How can I catch video from my computer camera. I can't run the h323plus sample "simple", it crash when come to the call PVideoInputDevice::GetDeviceCapabilities in arg initialization. I debug and found that the ptlib function calls in a cycle: A call B; B call C; C call A. Then the stack runs out. So, what's the trouble here? How can I get my device name pass it to the program instead of "*"? Last but not least, I want to ask Is there any detailed tutorial to learn. I search the net using google, the valuable one is almost only the oh323tut. But the oh323tut is a little too simple. It only shows the audio feature. How is the video? The simple sample shows an example I guess I can try to understand. Is there any related code or project using H323plus, for example using glade to show the video. Best regards Yincheng Li South China Normal University ------------------

1 0

h235 secure with extended video
by 오부경 26 Feb '14

26 Feb '14

Hi. I think, h323plus does not support secure mode for extended video. Do you have schedule for extended video security? BooKyung, Oh.

2 1

OLC requests missing some information
by Ankur Deep Jaiswal 26 Feb '14

26 Feb '14

Hi, In The OLC for H.264 (generic and extended). in multiplexparameters:h225logicalchannelparameters h323plus does not supply dynamicRTPPalyoadType and mediaPacketization:rtpPayloadtype due to this some clients refuse to display video , if these parameters are not present. any idea on how to implement these. Help appreciated. -- Ankur Deep Jaiswal

3 4