Hi Gerard, proxy mode often isn't enough for firewall traversal. You probably also have to enable H.460.18 NAT traversal in GnuGk. Also, you should probably drop the Bind= switch and the ExternalIP= switch should only be necessary if that IP is _not_ bound to any interface on your server. Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan@xxxxxxxxxxxxxx Website: https://www.gnugk.org Support: https://www.willamowius.com/gnugk-support.html Relaxed Communications GmbH Frahmredder 91, 22393 Hamburg, Germany Geschäftsführer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584 Gerard Beekmans wrote: > Hi, > > To start with, the GnuGk setup: > > > * Ubuntu 18.04 > > * Ptlib, h323plus and gnugk downloaded from git and compiled from source using instructions at https://www.gnugk.org/gnugk-manual-14.html#ss14.1 > > We have a Polcom video conferencing network deployed throughout the province. We have to interface with the federal government as well at times who are also using Polycom systems. > > We use a Polycom Video Border Proxy (VBP) in our network to connect to the government's, also a VBP. > > The setup in broad strokes is as follows: > > > * Our endpoints are registered to a Polycom Distributed Media Application (DMA) which is their version of a gatekeeper. > > o For testing I use Polycom RealPresence Desktop on a typical Windows 10 computer > > * The DMA has an external gatekeeper defined, which is our VBP with a certain prefix. > > * Any calls with that prefix are routed to the VBP. > > * The VBP in turn connects to the remote VBP with whatever dial string was provided (with our internal prefix stripped) > > * Remote VBP in turn connects the call to their bridge/MCU > > I am hoping to replace our local VBP with GnuGk instead. > > I have gotten most of the way there with the final problem that calls drop after exactly 60 seconds every time. The call flow is similar as shown above with the exception the local VBP is a GnuGk instance instead. The IP addresses at play are different so that both solutions can run side-by-side during all this testing. > > Whenever we've had these issues with Polycom devices talking to other Polycom devices it often came down to an issue with keep-alive packets not being sent or a NAT issue where the remote end saw our internal/private addresses and was sending data to the wrong IP that was never received locally and resulted in a timeout. Enabling various keepalive options in the [RoutedMode] section has not made a difference. I'm unsure if I have setup NAT correctly. I assume proxy mode takes care of that. > > How would I go about troubleshooting this? What kind of information would be helpful? > > My current configuration file contains the following. I have removed all the keepalive and other options I was experimenting with. > > [Gatekeeper::Main] > Name=GnuGk > Bind=199.213.1.22 > ExternalIP=199.213.1.22 > > [RoutedMode] > GKRouted=1 > > [Proxy] > Enable=1 > ProxyAlways=1 > InternalNetwork=172.24.0.0/16,10.0.0.0/8,127.0.0.0/8 > > [ModeSelection] > 199.213.0.0/16=PROXY > > [RasSrv::Neighbors] > GK1=Generic > > [Neighbor::GK1] > GatekeeperIdentifier=GK1 > Host=172.24.2.53 > SendPrefixes=* > AcceptPrefixes=* > ForwardLRQ=depends > > [Gatekeeper::Auth] > FileIPAuth=required;Setup > > [FileIPAuth] > 172.24.2.0/24=allow > 10.0.0.0/8=allow > 199.213.0.0/16=allow > > [RoutingPolicy] > default=explicit,internal,parent,neighbor,dns > > > Starting GnuGk with trace level 5, I see the following output in the last few seconds before the call disconnects. > > In this output the IPs used are: > > * 172.24.2.53 - our local DMA that my workstation registers to > > * 172.24.2.47 - GnuGk LAN interface > > * 199.213.1.22 - GnuGk WAN interface > > * 199.213.0.82 - remove VBP > > 2018/09/26 14:29:55.392 5 ProxyChannel.cxx(1557) H245s Reading from 172.24.2.53:36077 > 2018/09/26 14:29:55.392 4 ProxyChannel.cxx(2902) H245 Received from 172.24.2.53:36075 (CallID: e4 5b 0d 23 ec 14 00 1f 25 36 37 a4 0d c2 d3 11): command miscellaneousCommand { > logicalChannelNumber = 5 > type = videoFastUpdatePicture <<null>> > } > 2018/09/26 14:29:55.392 4 ProxyChannel.cxx(13215) H245 Command: miscellaneousCommand > > 2018/09/26 14:30:04.965 5 ProxyChannel.cxx(1557) Q931s Reading from 172.24.2.53:36075 > 2018/09/26 14:30:04.965 3 ProxyChannel.cxx(2187) Q931s Received: ReleaseComplete CRV=23271 from 172.24.2.53:36075 > 2018/09/26 14:30:04.966 4 ProxyChannel.cxx(2100) Q931 Received: { > q931pdu = { > protocolDiscriminator = 8 > callReference = 23271 > from = originator > messageType = ReleaseComplete > IE: Cause - Normal call clearing = { > 80 90 .. > } > IE: User-User = { > 25 80 06 00 08 91 4a 00 05 15 18 00 11 00 e4 5b %.....J........[ > 0d 23 ec 14 00 1f 25 36 37 a4 0d c2 d3 11 01 00 .#....%67....... > 01 40 10 80 01 00 .@.... > } > } > h225pdu = { > h323_uu_pdu = { > h323_message_body = releaseComplete { > protocolIdentifier = 0.0.8.2250.0.5 > callIdentifier = { > guid = 16 octets { > e4 5b 0d 23 ec 14 00 1f 25 36 37 a4 0d c2 d3 11 .[.#....%67..... > } > } > presentationIndicator = presentationAllowed <<null>> > screeningIndicator = userProvidedVerifiedAndFailed > } > h245Tunneling = false > } > } > } > 2018/09/26 14:30:04.966 1 RasTbl.cxx(5777) CDR|1|e4 5b 0d 23 ec 14 00 1f 25 36 37 a4 0d c2 d3 11|59|Wed, 26 Sep 2018 14:29:05 -06:00|Wed, 26 Sep 2018 14:30:04 -06:00|172.24.2.53:36075| |199.213.0.82:1720| |4990764184:dialedDigits|GerardBeekmans1:h323_ID=661039:dialedDigits|GnuGk; > > 2018/09/26 14:30:04.966 2 gkacct.cxx(970) GKACCT Successfully logged event 2 for call no. 1 > 2018/09/26 14:30:04.966 5 ProxyChannel.cxx(1557) H245s Reading from 172.24.2.53:36077 > 2018/09/26 14:30:04.966 4 ProxyChannel.cxx(2902) H245 Received from 172.24.2.53:36075 (CallID: e4 5b 0d 23 ec 14 00 1f 25 36 37 a4 0d c2 d3 11): command endSessionCommand disconnect <<null>> > 2018/09/26 14:30:04.966 4 ProxyChannel.cxx(13215) H245 Command: endSessionCommand > 2018/09/26 14:30:04.968 5 ProxyChannel.cxx(1557) H245s Reading from 172.24.2.53:36077 > 2018/09/26 14:30:04.968 5 yasocket.cxx(914) H245s 172.24.2.53:36077 closed by remote > 2018/09/26 14:30:04.976 5 ProxyChannel.cxx(1557) H245d Reading from 199.213.0.82:15081 > 2018/09/26 14:30:04.976 4 ProxyChannel.cxx(2902) H245 Received from 199.213.0.82:1720 (CallID: e4 5b 0d 23 ec 14 00 1f 25 36 37 a4 0d c2 d3 11): command endSessionCommand disconnect <<null>> > 2018/09/26 14:30:04.976 4 ProxyChannel.cxx(13215) H245 Command: endSessionCommand > 2018/09/26 14:30:04.976 3 ProxyChannel.cxx(15349) Proxy 199.213.0.82:15081 forward blocked > 2018/09/26 14:30:05.022 5 ProxyChannel.cxx(1557) H245d Reading from 199.213.0.82:15081 > 2018/09/26 14:30:05.022 5 yasocket.cxx(914) H245d 199.213.0.82:15081 closed by remote > > Based on these messages, it appears the disconnect came from our DMA. When I'm in direct vs. routed mode, the IP shown is my computer and it appears the disconnect request comes from my computer. > > When in routed mode, our DMA shows a disconnect reason of "call not set up in the time permitted". > > Any thoughts and help would be greatly appreciated. > Thanks, > Gerard Beekmans > Sr. Network Engineer > First Nations Technical Services Advisory Group Inc. > Phone: 780-638-2739 > Fax: 780-483-8632 > Helpdesk: 1-888-999-3356 > Email: gbeekmans@xxxxxxxx<mailto:gbeekmans@xxxxxxxx> > Santa Fe Plaza > 18232 - 102 Avenue NW > Edmonton, AB T5S 1S7 > http://www.tsag.net<http://www.tsag.net/> > _______________________________________________________ Posting: mailto:gnugk-users@xxxxxxxxxxxxxxx Archive: https://lists.gnugk.org/pipermail/gnugk-users/ Unsubscribe: https://lists.gnugk.org/lists/listinfo/gnugk-users Homepage: https://www.gnugk.org/
