In my opinion - you are. DRQ has nothing to do with ReleaseComplete. If your "endpoints" are not registered into GnuGK (namely - they are "permanent endpoints" using direct H.225 signalling), then you should not receive/send them ARQ/DRQ and etc. Those are used with RAS. How exactly do you "speak" to your endpoints? :) ARQ, LRQ or direct H.225 signalling ? Maybe you should send the Q.931 debug of such a call to take a look at the Release-Complete message attributes. Could be, some fancy FACILITY attribute in the release-complete drives GnuGK crazy. As a try, you may download the newest release of GnuGK 2.2. A feature is added there to drop the call if no tcp keepalive message is sent for a particular period of time. На пн, 2004-03-15 в 12:48, Konstantin Tsolov записа: > The GnuGK doc states that RemoveCallOnDRQ is needed only in > cases when ReleaseComplete is not available (only DRQ). > I believe that in proxy mode this is never the case... > or am I mistaken? > > On Saturday 13 March 2004 14:58, Zygmuntowicz Michal wrote: > > If gnugk receives ReleaseComplete, it always removes the call > > from the call table. I suspect your problem may be related to some > > network error conditions, so RC is not received by gnugk. > > Did you try to set RemoveCallOnDRQ (or something similar) flag? > > > > ----- Original Message ----- > > From: "Konstantin Tsolov" <ktsolov@xxxxxxx> > > Sent: Friday, March 12, 2004 1:16 PM > > > > > > Hello, > > > > I have a gnugk 2.0.7 with latest pwlib-1.6.2/openh323-1.13.2 running > > on a 2GHz Celeron and 1GB RAM slack instalation working as a h323 full > > proxy. > > > > When under heavy load it's making 90-150 concurent calls. > > uptime is ~0.50 > > cpuload is @60% > > memory is hardly used > > > > The problem is as follows: > > - it gets a setup message > > - sends a setup to other party > > - gets/sends a connect (call established) > > - call runs for some time and is disconnected with DRQ/ReleaseComplete > > - origination and termination parties both understand that the call > > has ended > > - my gnugk - does not; > > the call keeps hanging in the call list (shows after 'c' on :7000) > > - after timeout, the gnugk removes the call from its call list and > > does all the accounting actions it usually does. > > > > Thus, I'm left with real calls for which both (orig/term) parties have a > > correct accounting and I have a max-duration call in mine. > > > > If anyone has experienced anything similar or has a solution for this > > particular problem, I'll be very happy to hear about it. > > > > BTW, when I reroute the calls to come to the gnugk via a cisco IPIP gateway > > - the problem disappears - even under heavy load. > > Looks to me like a signaling interoperability problem but who knows... > > > > All info is much appreciated. > > > > Thanks, > > KTsolov ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
