Re: Question about disengageRequest

Mikael Grehn <mikael.grehn@xxxxxxxx> · Tue, 29 Nov 2011 23:52:41 +0100

Hi Ian and Simon!

I changed the H245Routed=1 on both gatekeepers and restarted.

But when making calls to secondary gatekeeper the call is getting through but the response seem to never reach the initiating Polycom PVX H323 endpoint. Something more I need to think about?

Primary gnugk: 207.183.111.222 – all calls to first customer gets here. Mirial is directly registered here
Secondary gnugk: 207.183.111.223 - all calls to second customer gets here. This gnugk should get register info from first gnugk
Mirial gw: 207.183.111.224

Gnugk.ini(this is on primary on, the secondary “almost” have the same config just changing IPs and number):
[Gatekeeper::Main]
FortyTwo=42
Name=GGnuGk
TimeToLive=600
StatusTraceLevel=2
AlternateGKs=207.183.111.223:1719:false:120:CGnuGk
SendTo=207.183.111.223:1719
SkipForwards=207.183.111.223
CompareAliasCase=0
CompareAliasType=0
ExternalIP=207.183.111.222

[GkStatus::Auth]
rule=allow
127.0.0.1=allow
default=allow
Shutdown=allow

[RoutedMode]
GKRouted=1
H245Routed=0
CallSignalPort=1720
AcceptUnregisteredCalls=1
DropCallsByReleaseComplete=1
SupportNATedEndpoints=1

[Proxy]
Enable=0
ProxyForNAT=1
ProxyForSameNAT=0

[RoutingPolicy]
default=explicit,internal,parent,neighbor,catchall,vqueue

[RasSrv::RewriteAlias]
graciasvrs.tv=0099999999

[Routing::CatchAll]
CatchAllAlias=PSEGateway

[EP::PSEGateway]
Capacity=30
AddNumbers=0099999999
AdditionalDestinationAlias=0099999999

Gnugk.log from primary gnugk:
2011/11/29 17:35:23.817 4             RasSrv.cxx(215)   RAS     Receiving on 192.168.1.4:1719(U)
2011/11/29 17:35:23.817 2             RasSrv.cxx(173)   RAS     Read from 207.183.111.224:1719
2011/11/29 17:35:23.817 3             RasSrv.cxx(223)   RAS
admissionRequest {
    requestSeqNum = 41619
    callType = pointToPoint <<null>>
    endpointIdentifier =  9 characters {
      0034 0038 0034 0038 005f 0065 006e 0064   4848_end
      0070                                      p
    }
    destinationInfo = 3 entries {
      [0]=dialedDigits "0000"
      [1]=h323_ID  10 characters {
        0050 0053 0045 0047 0061 0074 0065 0077   PSEGatew
        0061 0079                                 ay
      }
      [2]=dialedDigits "0099999999"
    }
    destCallSignalAddress = ipAddress {
      ip =  4 octets {
        cf b7 eb 95                                        ....
      }
      port = 1720
    }
    srcInfo = 1 entries {
      [0]=h323_ID  40 characters {
        0050 0072 006f 006a 0065 0063 0074 0020   Project
        0053 0075 0070 0070 006f 0072 0074 0020   Support
        0028 0036 0039 0036 0036 0029 0020 005b   (6966) [
        0032 0030 0037 002e 0031 0038 0033 002e   207.183.
        0032 0033 0035 002e 0031 0034 0037 005d   235.147]
      }
    }
    srcCallSignalAddress = ipAddress {
      ip =  4 octets {
        cf b7 eb 93                                        ....
      }
      port = 47792
    }
    bandWidth = 40960
    callReferenceValue = 22564
    conferenceID =  16 octets {
      02 35 81 6f 04 a6 fe 1a  35 de 9e 7f 4c 95 aa 9b   .5.o....5...L...
    }
    activeMC = false
    answerCall = true
    canMapAlias = true
    callIdentifier = {
      guid =  16 octets {
        02 35 81 6f 04 a6 fe 1a  35 dd 9e 7f 4c 95 aa 9b   .5.o....5...L...
      }
    }
    gatekeeperIdentifier =  6 characters {
      0047 0047 006e 0075 0047 006b             GGnuGk
    }
    willSupplyUUIEs = true
    canMapSrcAlias = false
  }
2011/11/29 17:35:23.817 5                job.cxx(363)   JOB     Worker threads: 10 total - 10 busy, 0 idle
2011/11/29 17:35:23.817 5                job.cxx(189)   JOB     Starting Job ARQ at Worker thread 140630293923600
2011/11/29 17:35:23.817 1             RasSrv.cxx(355)   RAS     ARQ Received from 207.183.111.224:1719
2011/11/29 17:35:23.817 5             RasSrv.cxx(1095)  RAS     Skip forwarded RAS
2011/11/29 17:35:23.818 3             RasSrv.cxx(2899)  GK      ACF will grant bandwidth of 40960
2011/11/29 17:35:23.818 2             RasTbl.cxx(3596)  CallTable::Insert(CALL) Call No. 2, total sessions : 1
2011/11/29 17:35:23.818 4             RasSrv.cxx(3035)  RAS     NAT strategy for Call No: 2 set to Unknown Strategy
2011/11/29 17:35:23.818 2             RasSrv.cxx(395)   ACF|207.183.111.224:1720|4848_endp|22564|0000:dialedDigits=PSEGateway:h323_ID=0099999999:dialedDigits|Project Support (6966) [207.183.111.223]:h323_ID|true|02-35-81-6f-04-a6-fe-1a-35-dd-9e-7f-4c-95-aa-9b;
2011/11/29 17:35:23.818 3             RasSrv.cxx(235)   RAS     Send to 207.183.111.224:1719
admissionConfirm {
    requestSeqNum = 41619
    bandWidth = 40960
    callModel = gatekeeperRouted <<null>>
    destCallSignalAddress = ipAddress {
      ip =  4 octets {
        cf b7 eb 92                                        ....
      }
      port = 1720
    }
    irrFrequency = 120
    willRespondToIRR = false
    uuiesRequested = {
      setup = false
      callProceeding = false
      connect = false
      alerting = false
      information = false
      releaseComplete = false
      facility = false
      progress = false
      empty = false
      status = false
      statusInquiry = false
      setupAcknowledge = false
      notify = false
    }
    serviceControl = 1 entries {
      [0]={
        sessionId = 0
        contents = callCreditServiceControl {
          callStartingPoint = connect <<null>>
        }
        reason = refresh <<null>>
      }
    }
  }
2011/11/29 17:35:23.818 5             RasSrv.cxx(249)   RAS     Sent Successful
2011/11/29 17:35:23.818 5                job.cxx(426)   JOB     Job ARQ deleted
2011/11/29 17:35:23.818 5                job.cxx(415)   JOB     Worker threads: 10 total - 9 busy, 1 idle
2011/11/29 17:35:24.820 4             RasSrv.cxx(215)   RAS     Receiving on 192.168.1.4:1719(U)
2011/11/29 17:35:24.820 2             RasSrv.cxx(173)   RAS     Read from 207.183.111.224:1719
2011/11/29 17:35:24.820 3             RasSrv.cxx(223)   RAS
infoRequestResponse {
    requestSeqNum = 41620
    endpointType = {
      vendor = {
        vendor = {
          t35CountryCode = 89
          t35Extension = 0
          manufacturerCode = 17484
        }
        productId =  16 octets {
          44 79 4c 6f 67 69 63 20  50 53 45 2e 4d 53 00 00   DyLogic PSE.MS..
        }
        versionId =  7 octets {
          34 2e 36 2e 30 00 00                               4.6.0..
        }
      }
      gateway = {
        protocol = 1 entries {
          [0]=h323 {
            supportedPrefixes = 1 entries {
              [0]={
                prefix = dialedDigits "0000"
              }
            }
          }
        }
      }
      mc = false
      undefinedNode = false
    }
    endpointIdentifier =  9 characters {
      0034 0038 0034 0038 005f 0065 006e 0064   4848_end
      0070                                      p
    }
    rasAddress = ipAddress {
      ip =  4 octets {
        cf b7 eb 95                                        ....
      }
      port = 1719
    }
    callSignalAddress = 1 entries {
      [0]=ipAddress {
        ip =  4 octets {
          cf b7 eb 95                                        ....
        }
        port = 1720
      }
    }
    endpointAlias = 3 entries {
      [0]=dialedDigits "0000"
      [1]=h323_ID  10 characters {
        0050 0053 0045 0047 0061 0074 0065 0077   PSEGatew
        0061 0079                                 ay
      }
      [2]=dialedDigits "0099999999"
    }
    perCallInfo = 1 entries {
      [0]={
        callReferenceValue = 22564
        conferenceID =  16 octets {
          02 35 81 6f 04 a6 fe 1a  35 de 9e 7f 4c 95 aa 9b   .5.o....5...L...
        }
        originator = false
        h245 = {
        }
        callSignaling = {
        }
        callType = pointToPoint <<null>>
        bandWidth = 0
        callModel = gatekeeperRouted <<null>>
        callIdentifier = {
          guid =  16 octets {
            02 35 81 6f 04 a6 fe 1a  35 dd 9e 7f 4c 95 aa 9b   .5.o....5...L...
          }
        }
        substituteConfIDs = 0 entries {
        }
        usageInformation = {
          nonStandardUsageFields = 0 entries {
          }
          alertingTime = 1322609721
        }
      }
    }
    needResponse = false
    unsolicited = true
  }
2011/11/29 17:35:24.821 5                job.cxx(363)   JOB     Worker threads: 10 total - 10 busy, 0 idle
2011/11/29 17:35:24.821 5                job.cxx(189)   JOB     Starting Job IRR at Worker thread 140630293923600
2011/11/29 17:35:24.821 1             RasSrv.cxx(355)   RAS     IRR Received from 207.183.111.224:1719
2011/11/29 17:35:24.821 5                job.cxx(426)   JOB     Job IRR deleted
2011/11/29 17:35:24.821 5                job.cxx(415)   JOB     Worker threads: 10 total - 9 busy, 1 idle

. . . SIP side has answered . . .

2011/11/29 17:35:51.020 4             RasSrv.cxx(215)   RAS     Receiving on 192.168.1.4:1719(U)
2011/11/29 17:35:51.020 2             RasSrv.cxx(173)   RAS     Read from 207.183.111.224:1719
2011/11/29 17:35:51.020 3             RasSrv.cxx(223)   RAS
disengageRequest {
    requestSeqNum = 41621
    endpointIdentifier =  9 characters {
      0034 0038 0034 0038 005f 0065 006e 0064   4848_end
      0070                                      p
    }
    conferenceID =  16 octets {
      02 35 81 6f 04 a6 fe 1a  35 de 9e 7f 4c 95 aa 9b   .5.o....5...L...
    }
    callReferenceValue = 22564
    disengageReason = normalDrop <<null>>
    callIdentifier = {
      guid =  16 octets {
        02 35 81 6f 04 a6 fe 1a  35 dd 9e 7f 4c 95 aa 9b   .5.o....5...L...
      }
    }
    gatekeeperIdentifier =  6 characters {
      0047 0047 006e 0075 0047 006b             GGnuGk
    }
    answeredCall = true
    usageInformation = {
      nonStandardUsageFields = 0 entries {
      }
      alertingTime = 1322609721
      connectTime = 1322609725
      endTime = 1322609748
    }
    terminationCause = releaseCompleteCauseIE  2 octets {
      80 90                                              ..
    }
  }
2011/11/29 17:35:51.020 5                job.cxx(363)   JOB     Worker threads: 10 total - 10 busy, 0 idle
2011/11/29 17:35:51.020 5                job.cxx(189)   JOB     Starting Job DRQ at Worker thread 140630293923600
2011/11/29 17:35:51.020 1             RasSrv.cxx(355)   RAS     DRQ Received from 207.183.111.224:1719
2011/11/29 17:35:51.020 4             RasSrv.cxx(3270)  GK      DRQ: closed conference
2011/11/29 17:35:51.021 2             RasTbl.cxx(4076)  CDR     ignore not connected call
2011/11/29 17:35:51.021 2             gkacct.cxx(955)   GKACCT  Successfully logged event 2 for call no. 2
2011/11/29 17:35:51.021 2             RasSrv.cxx(395)   DCF|207.183.111.224|4848_endp|22564|normalDrop|02-35-81-6f-04-a6-fe-1a-35-dd-9e-7f-4c-95-aa-9b;
2011/11/29 17:35:51.021 3             RasSrv.cxx(235)   RAS     Send to 207.183.111.224:1719
disengageConfirm {
    requestSeqNum = 41621
  }
2011/11/29 17:35:51.021 5             RasSrv.cxx(249)   RAS     Sent Successful
2011/11/29 17:35:51.021 5                job.cxx(426)   JOB     Job DRQ deleted
2011/11/29 17:35:51.021 5                job.cxx(415)   JOB     Worker threads: 10 total - 9 busy, 1 idle
2011/11/29 17:35:51.988 3             RasTbl.cxx(2130)  Gk      Delete Call No. 2

Gnugk.log from secondary gnugk:
2011/11/29 14:35:23.780 3       ProxyChannel.cxx(1014)  Q931s   Received: Setup CRV=22564 from 207.91.137.218:50615
2011/11/29 14:35:23.781 2             RasTbl.cxx(3596)  CallTable::Insert(CALL) Call No. 2, total sessions : 1
2011/11/29 14:35:23.781 2             gkacct.cxx(955)   GKACCT  Successfully logged event 1 for call no. 2
2011/11/29 14:35:23.781 3       ProxyChannel.cxx(2893)  Q931s   Call 2 is NAT type 0
2011/11/29 14:35:23.782 1       ProxyChannel.cxx(859)   Call 2: h245Routed=1 proxy=0
2011/11/29 14:35:23.783 3       ProxyChannel.cxx(4725)  Q931    Connect to 207.183.111.224:1720 from 192.168.1.4:0 successful
2011/11/29 14:35:23.817 3       ProxyChannel.cxx(1014)  Q931d   Received: CallProceeding CRV=22564 from 207.183.111.224:1720
2011/11/29 14:35:24.189 3       ProxyChannel.cxx(1014)  Q931d   Received: Alerting CRV=22564 from 207.183.111.224:1720
2011/11/29 14:35:24.189 2             gkacct.cxx(955)   GKACCT  Successfully logged event 64 for call no. 2
2011/11/29 14:35:28.118 3       ProxyChannel.cxx(1014)  Q931d   Received: Connect CRV=22564 from 207.183.111.224:1720
2011/11/29 14:35:28.119 2             gkacct.cxx(955)   GKACCT  Successfully logged event 32 for call no. 2
2011/11/29 14:35:28.119 3       ProxyChannel.cxx(5274)  H245    Set h245Address to 207.183.111.223:59669

. . . SIP side has answered . . .

2011/11/29 14:35:51.016 3       ProxyChannel.cxx(1014)  Q931s   Received: ReleaseComplete CRV=22564 from 207.91.137.218:50615
2011/11/29 14:35:51.016 1             RasTbl.cxx(4072)  CDR|2|02 35 81 6f 04 a6 fe 1a 35 dd 9e 7f 4c 95 aa 9b|23|Tue, 29 Nov 2011 14:35:28 -0800|Tue, 29 Nov 2011 14:35:51 -0800|207.91.137.218:50615| |207.183.111.224:1720|4848_endp|207.183.111.224:1720|Project Support:h323_ID=6966:dialedDigits|CGnuGk;

2011/11/29 14:35:51.016 2             gkacct.cxx(955)   GKACCT  Successfully logged event 2 for call no. 2
2011/11/29 14:35:51.018 3       ProxyChannel.cxx(1014)  Q931d   Received: ReleaseComplete CRV=22564 from 207.183.111.224:1720
2011/11/29 14:35:56.020 3           yasocket.cxx(576)   Q931s   Delete socket 207.91.137.218:50615
2011/11/29 14:35:56.020 3           yasocket.cxx(576)   Q931d   Delete socket 207.183.111.224:1720
2011/11/29 14:35:56.859 3             RasTbl.cxx(2130)  Gk      Delete Call No. 2
2011/11/29 14:36:01.021 3           yasocket.cxx(576)   H245d   Delete socket
2011/11/29 14:36:01.021 3           yasocket.cxx(576)   H245s   Delete socket

So I might need some additional configuration for this?

Many thanks for your kind help! J

Best Regards,
Mikael

Från: Simon Horne [mailto:s.horne@xxxxxxxxxxxxxx] 
Skickat: den 29 november 2011 23:24
Till: 'GNU Gatekeeper Users'
Ämne: Re:  Question about disengageRequest

Ian

Sorry missed your email.

Yes H245Routed would help. This allows the H.225 and H.245 to be routed through the gatekeeper so support H.245 tunneling in H.225. 1 TCP connection.
Under the other setting the H.225 is gatekeeper routed but the media control goes directly bypassing the gatekeeper.  So 2 separate TCP connections. 
H.245 gets a lot more activity during a call. (FastPictureUpdate,FlowControl etc)

TCP connections in routers generally timeout in between 20-45 sec horrible but true. The magic number we use for H.460.18/.19 is always 19sec.
Forcing a TCP keepAlive in the OS definitely helps.

Simon

From: Ian Blenke [mailto:ian@xxxxxxxxxx] 
Sent: 30 November 2011 07:47
To: GNU Gatekeeper Users
Subject: Re:  Question about disengageRequest

Simon, might this help him?

[RoutedMode]
H245Routed=1

I hadn't even thought of the TCP session timing out that quickly. UDP, definitely, but TCP timing out that fast just doesn't seem right to me (though it wouldn't be entirely suprising).

Alternatively, if that were the case, would this help?

sysctl -w net.ipv4.tcp_keepalive_time=15

By default, that's 7200 (2 hours), not 15 seconds.

 - Ian
On Tue, Nov 29, 2011 at 4:34 PM, Simon Horne <s.horne@xxxxxxxxxxxxxx> wrote:
Mikael

My guess is that the H.225 TCP connection is being dropped forcing the DRQ
from GnuGk (shutdown the call). Hence the forceDrop reason

Generally firewalls will drop TCP connections after about 20 sec of
inactivity. The H.225 channel gets very little activity if not H.245
tunneled. Make sure there is nothing between the devices that could do that.

The only other reason is the Mirial side is deciding to drop the TCP
connection due to a timeout or something. You will need to check the config
and logs as well. You might need to consult mirial.

Either case the error is coming from outside GnuGk control.

Simon

-----Original Message-----
From: Mikael Grehn [mailto:mikael.grehn@xxxxxxxx]
Sent: 30 November 2011 07:17
To: GNU Gatekeeper Users
Subject: Re: [Openh323gk-users] Question about disengageRequest

Thank you Jan!

My main skill is unfortunately SIP but on that side I can see the SIP
Invite, SIP OK and later SIP Ack which should mean that H323 has connected
the call?

I have tried to go through the Gnugk traces but have difficulties detecting
the source of the error.
I see:
 maintainConnection = false
 supportsAltGK = <<null>>
in the registration that looks bad.

In the sudden disengageRequest (from primary gnugk directly to Mirial) I see
a forceDrop as disengageReason. Without getting anything from the H323
client?

-------------
2011/11/29 16:12:56.201 3             RasSrv.cxx(235)   RAS     Send to
207.183.111.224:1719
disengageRequest {
   requestSeqNum = 2
   endpointIdentifier =  9 characters {
     0036 0039 0035 0037 005f 0065 006e 0064   6957_end
     0070                                      p
   }
   conferenceID =  16 octets {
     02 35 81 4e 9a 4b 71 12  36 b9 e2 73 30 a9 2e cf   .5.N.Kq.6..s0...
   }
   callReferenceValue = 51151
   disengageReason = forcedDrop <<null>>
   callIdentifier = {
     guid =  16 octets {
       02 35 81 4e 9a 4b 71 12  36 b8 e2 73 30 a9 2e cf   .5.N.Kq.6..s0...
     }
   }
   gatekeeperIdentifier =  6 characters {
     0047 0047 006e 0075 0047 006b             GGnuGk
   }
   answeredCall = false
 }
-------------

If it is OK with you I'd like to send you the gnugk traces directly (not
exposing real IP's), both the primary and alternative one together with my
gatekeeper configuration?

Only if that is OK of course! :)

Best Regards,
Mikael

-----Ursprungligt meddelande-----
Från: Jan Willamowius [mailto:jan@xxxxxxxxxxxxxx]
Skickat: den 29 november 2011 20:55
Till: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Ämne: Re:  Question about disengageRequest

Again, audio and video is no indication that the call has connected (and
would be past most of the message timeouts). You have to check for the
Connect message and check if the H.245 connection negotiated properly.

Regards,
Jan

Mikael Grehn wrote:
> Hi Jan and thanks for the rapid response.
>
> The calls are perfectly connected and they run with audio and video for
about 25 seconds (perhaps 20 seconds after fully being connected). Then the
primary gatekeeper is sending this disengageRequest to Mirial and Mirial
disconnects both sides. Primary gatekeeper has been "quiet" for about 20
seconds before this so something is absolutely happening!
>
> If I make a call to the other customer (directly to primary Gk) the
> call is not disconnected at all and are working perfectly. :)
>
> Any ideas what can trigger this?
>
> Thanks for you kind help!
>
> Best Regards,
> Mikael
>
>
> -----Ursprungligt meddelande-----
> Från: Jan Willamowius [mailto:jan@xxxxxxxxxxxxxx]
> Skickat: den 29 november 2011 20:21
> Till: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
> Ämne: Re:  Question about disengageRequest
>
> Hi Mikael,
>
> are your calls being terminated before or after they connect ?
> (Hearing voice may just mean that the call was using FastStart.)
>
> If GnuGk actively terminates a call it usually detected ran into a timeout
(it tries to detect stale calls). When you have multiple gatekeepers
involved, make sure each gatekeeper that handles the call sees all messages
for that call.
>
> Regards,
> Jan
>
>
> Mikael Grehn wrote:
> > Hi!
> >
> > I have a question about why a primary gatekeeper(out of 2
> > gatekeepers) is disconnecting calls after 25 seconds that first
> > reaches the alternative gatekeeper on another machine. The H323
> > endpoint that is receiving the call is a Mirial gateway. :)
> >
> > We have two customers that use incoming H323 and SIP for their service.
> >
> > For the H323 we are using a H323 Gnugk for each customer (on two
different IP's) that I have tried to setup as primary and alternative
gatekeeper.
> > To translate from H323 to SIP (which is the protocol mainly
> > supported by our service) we have a Mirial H323 2 SIP in between.
> > The H323 side of Mirial is registered in the primary gatekeeper at
> > customer 1. We cant register it in the alternative as well. :)
> >
> >
> > Customer 1: GnuGk(primary) IP1 <--registered Mirial IP3
> >                              |reg
> > Customer 2: GnuGk(alternative) IP2
> >
> >
> > Calls from H323 clients to the first (primary) customer is working
perfectly.
> > Calls from H323 to the second customer (with the alternative gatekeeper
gets the call to work for about 25 seconds. After this the primary
gatekeepers decides to send disengageRequest directly to Mirial gateway,
that is later disconnecting the calls.
> >
> > This is the log from the primary gatekeeper (207.183.111.122) when it is
disconnecting a working call:
> >
> > (. . . about 20 seconds with no logs since the call was setup OK . .
> > .) disengageRequest {
> >     requestSeqNum = 104
> >     endpointIdentifier =  9 characters {
> >       0031 0034 0030 0038 005f 0065 006e 0064   1408_end
> >       0070                                      p
> >     }
> >     conferenceID =  16 octets {
> >       02 35 81 01 a4 43 d0 10  36 b3 e2 73 30 a9 2e cf
.5...C..6..s0...
> >     }
> >     callReferenceValue = 51145
> >     disengageReason = forcedDrop <<null>>
> >     callIdentifier = {
> >       guid =  16 octets {
> >         02 35 81 01 a4 43 d0 10  36 b2 e2 73 30 a9 2e cf
.5...C..6..s0...
> >       }
> >     }
> >     gatekeeperIdentifier =  6 characters {
> >      0047 0047 006e 0075 0047 006b             GGnuGk
> >     }
> >     answeredCall = false
> >   }
> > 2011/11/29 12:55:55.689 2             RasTbl.cxx(2642)  Gk
Disconnect Call No. 26
> > 2011/11/29 12:55:55.689 2             RasTbl.cxx(4076)  CDR     ignore
not connected call
> > 2011/11/29 12:55:55.689 2             gkacct.cxx(955)   GKACCT
Successfully logged event 2 for call no. 26
> > 2011/11/29 12:55:55.690 2             RasSrv.cxx(173)   RAS     Read
from 207.183.111.224:1719
> > 2011/11/29 12:55:55.690 3             RasSrv.cxx(223)   RAS
> > disengageConfirm {
> >     requestSeqNum = 104
> >     usageInformation = {
> >       nonStandardUsageFields = 0 entries {
> >       }
> >       alertingTime = 1322592922
> >       connectTime = 1322592926
> >     }
> >   }
> > 2011/11/29 12:55:55.690 1             RasSrv.cxx(355)   RAS     DCF
Received from 207.183.111.224:1719
> > 2011/11/29 12:55:56.689 3             RasTbl.cxx(2130)  Gk      Delete
Call No. 26
> > 2011/11/29 12:55:57.278 2             RasSrv.cxx(173)   RAS     Read
from 207.183.111.224:1719
> > 2011/11/29 12:55:57.278 3             RasSrv.cxx(223)   RAS
> > disengageRequest {
> >     requestSeqNum = 60528
> >     endpointIdentifier =  9 characters {
> >       0031 0034 0030 0038 005f 0065 006e 0064   1408_end
> >       0070                                      p
> >     }
> >     conferenceID =  16 octets {
> >       02 35 81 01 a4 43 d0 10  36 b3 e2 73 30 a9 2e cf
.5...C..6..s0...
> >     }
> >     callReferenceValue = 18377
> >     disengageReason = normalDrop <<null>>
> >     callIdentifier = {
> >       guid =  16 octets {
> >         02 35 81 01 a4 43 d0 10  36 b2 e2 73 30 a9 2e cf
.5...C..6..s0...
> >       }
> >     }
> >     gatekeeperIdentifier =  6 characters {
> >       0047 0047 006e 0075 0047 006b             GGnuGk
> >     }
> >     answeredCall = true
> >     usageInformation = {
> >       nonStandardUsageFields = 0 entries {
> >       }
> >       alertingTime = 1322592922
> >       connectTime = 1322592926
> >       endTime = 1322592952
> >     }
> >     terminationCause = releaseCompleteReason gatekeeperResources
<<null>>
> >   }
> > 2011/11/29 12:55:57.279 1             RasSrv.cxx(355)   RAS     DRQ
Received from 207.183.111.224:1719
> > 2011/11/29 12:55:57.279 2             RasSrv.cxx(395)
DCF|207.183.111.224|1408_endp|18377|normalDrop|02-35-81-01-a4-43-d0-10-36-b2
-e2-73-30-a9-2e-cf;
> > 2011/11/29 12:55:57.279 3             RasSrv.cxx(235)   RAS     Send to
207.183.111.224:1719
> > disengageConfirm {
> >     requestSeqNum = 60528
> >   }
> >
> > Any ideas why it does this and how I can configure it away?
> > I am adding the gnugk.ini file from primary gatekeeper. It is very
> > similar on the alternative one. :)
> >
> > Primary Gk: 207.183.111.222
> > Alternativ Gk: 207.183.111.223
> > Mirial h323 2 SIP gw: 207.183.111.224
> >
> > [Gatekeeper::Main]
> > FortyTwo=42
> > Name=GGnuGk
> > TimeToLive=600
> > StatusTraceLevel=2
> > AlternateGKs=207.183.111.223:1719:false:120:CGnuGk
> > SendTo=207.183.111.223:1719
> > SkipForwards=207.183.111.223
> > CompareAliasCase=0
> > CompareAliasType=0
> > ExternalIP=207.183.111.222
> > [GkStatus::Auth]
> > rule=allow
> > 127.0.0.1=allow
> > default=allow
> > Shutdown=allow
> >
> > [RoutedMode]
> > GKRouted=1
> > H245Routed=0
> > CallSignalPort=1720
> > AcceptUnregisteredCalls=1
> > DropCallsByReleaseComplete=1
> > SupportNATedEndpoints=1
> >
> > [Proxy]
> > Enable=0
> > ProxyForNAT=1
> > ProxyForSameNAT=0
> >
> > [RoutingPolicy]
> > default=explicit,internal,parent,neighbor,catchall,vqueue
> >
> > [RasSrv::RewriteAlias]
> > customerdomain.com=0099999999
> >
> > [Routing::CatchAll]
> > CatchAllAlias=PSEGateway
> >
> > [EP::PSEGateway]
> > Capacity=30
> > AddNumbers=0099999999
> > AdditionalDestinationAlias=0099999999
> >
> > I have tried to change the real IP's into fictional ones, might have
missed some!
> > Any help is very appreciated! :)
> >
> > Best Regards,
> > Mikael

--
Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/

----------------------------------------------------------------------------
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity, and more. Splunk takes this data and makes sense of it.
IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________________

Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/

----------------------------------------------------------------------------
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity, and more. Splunk takes this data and makes sense of it.
IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________________

Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________________

Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/

-- 
- Ian Blenke <ian@xxxxxxxxxx> http://ian.blenke.com
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________________

Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/