Re: Certain calls drop after 60 seconds

WARNING: You receive this message on the old GnuGk mailinglist that will go=
 away soon. Please re-subscribe for the new mailinglist at
https://lists.gnugk.org/cgi-bin/mailman/listinfo/gnugk-users

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=3D switch and the ExternalIP=3D
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  : [email protected]
Website: https://www.gnugk.org
Support: https://www.willamowius.com/gnugk-support.html

Relaxed Communications GmbH
Frahmredder 91, 22393 Hamburg, Germany
Gesch=E4ftsf=FChrer: 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#ss=
14.1
> =

> We have a Polcom video conferencing network deployed throughout the provi=
nce. 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 th=
e government's, also a VBP.
> =

> The setup in broad strokes is as follows:
> =

> =

> *         Our endpoints are registered to a Polycom Distributed Media App=
lication (DMA) which is their version of a gatekeeper.
> =

> o   For testing I use Polycom RealPresence Desktop on a typical Windows 1=
0 computer
> =

> *         The DMA has an external gatekeeper defined, which is our VBP wi=
th 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 s=
tring 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 dro=
p after exactly 60 seconds every time. The call flow is similar as shown ab=
ove with the exception the local VBP is a GnuGk instance instead. The IP ad=
dresses at play are different so that both solutions can run side-by-side d=
uring all this testing.
> =

> Whenever we've had these issues with Polycom devices talking to other Pol=
ycom devices it often came down to an issue with keep-alive packets not bei=
ng sent or a NAT issue where the remote end saw our internal/private addres=
ses and was sending data to the wrong IP that was never received locally an=
d resulted in a timeout. Enabling various keepalive options in the [RoutedM=
ode] section has not made a difference. I'm unsure if I have setup NAT corr=
ectly. 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=3DGnuGk
> Bind=3D199.213.1.22
> ExternalIP=3D199.213.1.22
> =

> [RoutedMode]
> GKRouted=3D1
> =

> [Proxy]
> Enable=3D1
> ProxyAlways=3D1
> InternalNetwork=3D172.24.0.0/16,10.0.0.0/8,127.0.0.0/8
> =

> [ModeSelection]
> 199.213.0.0/16=3DPROXY
> =

> [RasSrv::Neighbors]
> GK1=3DGeneric
> =

> [Neighbor::GK1]
> GatekeeperIdentifier=3DGK1
> Host=3D172.24.2.53
> SendPrefixes=3D*
> AcceptPrefixes=3D*
> ForwardLRQ=3Ddepends
> =

> [Gatekeeper::Auth]
> FileIPAuth=3Drequired;Setup
> =

> [FileIPAuth]
> 172.24.2.0/24=3Dallow
> 10.0.0.0/8=3Dallow
> 199.213.0.0/16=3Dallow
> =

> [RoutingPolicy]
> default=3Dexplicit,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 f=
rom 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 d=
3 11): command miscellaneousCommand {
>     logicalChannelNumber =3D 5
>     type =3D 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 f=
rom 172.24.2.53:36075
> 2018/09/26 14:30:04.965 3       ProxyChannel.cxx(2187)  Q931s   Received:=
 ReleaseComplete CRV=3D23271 from 172.24.2.53:36075
> 2018/09/26 14:30:04.966 4       ProxyChannel.cxx(2100)  Q931    Received:=
 {
>   q931pdu =3D {
>     protocolDiscriminator =3D 8
>     callReference =3D 23271
>     from =3D originator
>     messageType =3D ReleaseComplete
>     IE: Cause - Normal call clearing =3D {
>       80 90                                              ..
>     }
>     IE: User-User =3D {
>       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 =3D {
>     h323_uu_pdu =3D {
>       h323_message_body =3D releaseComplete {
>         protocolIdentifier =3D 0.0.8.2250.0.5
>         callIdentifier =3D {
>           guid =3D  16 octets {
>             e4 5b 0d 23 ec 14 00 1f  25 36 37 a4 0d c2 d3 11   .[.#....%6=
7.....
>           }
>         }
>         presentationIndicator =3D presentationAllowed <<null>>
>         screeningIndicator =3D userProvidedVerifiedAndFailed
>       }
>       h245Tunneling =3D 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|We=
d, 26 Sep 2018 14:30:04 -06:00|172.24.2.53:36075| |199.213.0.82:1720| |4990=
764184:dialedDigits|GerardBeekmans1:h323_ID=3D661039:dialedDigits|GnuGk;
> =

> 2018/09/26 14:30:04.966 2             gkacct.cxx(970)   GKACCT  Successfu=
lly logged event 2 for call no. 1
> 2018/09/26 14:30:04.966 5       ProxyChannel.cxx(1557)  H245s   Reading f=
rom 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 d=
3 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 f=
rom 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 f=
rom 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 d=
3 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 f=
rom 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. Whe=
n 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 u=
p 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: [email protected]<mailto:[email protected]>
> Santa Fe Plaza
> 18232 - 102 Avenue NW
> Edmonton, AB T5S 1S7
> http://www.tsag.net<http://www.tsag.net/>
> =




_______________________________________________________

Posting: mailto:[email protected]
Archive: https://sourceforge.net/mailarchive/forum.php?forum_name=3Dopenh32=
3gk-users
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: https://www.gnugk.org/