|
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 Santa Fe Plaza |
_______________________________________________________ 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/
