Hi Jan, I set it back to GnuGk just now and the calls drop at exactly the 60 second mark. I have set it back to CiscoGk and the calls are lasting longer than 1 minute now. A new issue has come to light. I was attempting content sharing and that had all kinds of issues. Calls from certain endpoints could not share. Sometimes the sending client's program reported a network error that prevented sharing. In other cases, the sending client seemed to be transmitting data but the receiving clients' programs were reporting 100% loss on the content channel -- this indicates that there was at least the awareness of a content channel being opened but no data arrived. During all these content tests I experienced random connection drops with no discernable pattern. I chalked it up to the various gatekeepers involved closing the connection due to the packet losses going on when content sharing was attempted. As such I wouldn't call this CiscoGk mode stable yet but it's at least better for plain video & audio. Is this something you would be interested in further troubleshooting and possibly developing into a Polycom compatible gatekeeper type/mode in GnuGk? I would love to get this stabilized and showcase an Open Source alternative to the Government department we're doing this for. 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 Santa Fe Plaza 18232 - 102 Avenue NW Edmonton, AB T5S 1S7 http://www.tsag.net -----Original Message----- From: gnugk-users <gnugk-users-bounces@xxxxxxxxxxxxxxx> On Behalf Of Jan Willamowius Sent: September 27, 2018 13:55 To: gnugk-users@xxxxxxxxxxxxxxx Subject: Re: Certain calls drop after 60 seconds Hi, with neighbor type CiscoGk, GnuGk uses a Cisco vendor ID and a non-standard element in LRQs that old Cisco gatekeepers expect. Have you tried switching back to neighbor type Generic to verify its only the neighbor type that made the difference for you ? 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, > > I may have found the problem. The 1 minute disconnects are no longer happening though more testing required to ensure things like content sharing works. > > What made it work was setting the neighbour type to "CiscoGk". When left at GnuGk/Generic, the Polycom DMA initiated a disconnectrequest after the 1 minute mark. When set to CiscoGk, this doesn't happen. > > I have read through Neighbor.cxx to see what the differences are in operation. I'm not well versed in C++. Could you explain what GnuGk does differently when in Cisco mode? > > Also I didn't need any special NAT switches. My configuration is now simplified to the following. Are there any unnecessary options I can remove? > > > [Gatekeeper::Main] > Name=GnuGk > > [RoutedMode] > GKRouted=1 > H245Routed=1 > AcceptUnregisteredCalls=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=CiscoGk > > [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 > > > 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 > Santa Fe Plaza > 18232 - 102 Avenue NW > Edmonton, AB T5S 1S7 > http://www.tsag.net > > -----Original Message----- > From: gnugk-users <gnugk-users-bounces@xxxxxxxxxxxxxxx> On Behalf Of > Gerard Beekmans > Sent: September 26, 2018 15:21 > To: GNU Gatekeeper Users <gnugk-users@xxxxxxxxxxxxxxx> > Subject: Re: Certain calls drop after 60 seconds > > Hi Jan, > > I have disabled the Bind and ExternalIP switches. I see some additional log entries from ProxyChannel now like these: > > ProxyChannel.cxx(11238) RTP Forward 199.213.0.82:22982 to 10.254.0.54:3234 > ProxyChannel.cxx(11292) RTP Reverse 10.254.0.54:3234 to 199.213.0.82:22982 > > On the LAN side there is no need for NAT. The GnuGk server can reach my computer. Although it's on a different subnet, the LAN router allows all traffic to and from the GnuGk server. > > The only NAT that needs to be applied is when connecting to the remote hosts so that the remote VBP does not see our private IPs that it can't route back to. There is no additional router involved. The GnuGk server has a direct connection to the remote network. It's acting as its own router. > > In this setup do I need to enable NAT using iptables? My computer shouldn't route through the GnuGk server; proxying should be done instead. > > Having said that, how do I enable H.460.18 NAT you mentioned? > > Is that done simply by adding these to [RoutedMode] > > EnableH46017=1 > EnableH46018=1 > H46018KeepAliveInterval=19 > H46018NoNat=1 > > I tried a call with the above settings. Still drops at the 1 minute mark. > > > 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 > Santa Fe Plaza > 18232 - 102 Avenue NW > Edmonton, AB T5S 1S7 > http://www.tsag.net > > -----Original Message----- > From: gnugk-users <gnugk-users-bounces@xxxxxxxxxxxxxxx> On Behalf Of > Jan Willamowius > Sent: September 26, 2018 14:57 > To: gnugk-users@xxxxxxxxxxxxxxx > Subject: Re: Certain calls drop after 60 seconds > > 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/> > > > Homepage: https://www.gnugk.org/ _______________________________________________________ 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/ _______________________________________________________ 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/
