Re: [Openh323gk-users] Certain calls drop after 60 seconds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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= 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:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: https://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: https://www.gnugk.org/




[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux