To Konstantin: if you are able to isolate the problematic calls (and as I read from your e-mail - you are), then get Ethereal and "analyze" all H.323 stream that GnuGK sends and receives. Ethereal has a very good Q.931 / H.323 protocol decoder and you will see if a RC message really comes to GnuGK or not. On Monday 15 March 2004 13:35, Zygmuntowicz Michal wrote: > The proxy (and routed) mode cause GnuGk to receive > ReleaseComplete message for each call, as all signalling > messages are passing through the gatekeeper. > > ----- Original Message ----- > From: "Konstantin Tsolov" <ktsolov@xxxxxxx> > Sent: Monday, March 15, 2004 11:48 AM > > > 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 -- Best regards, Teodor Georgiev Information Services Plc. Tel : +359 2 96562008 Mobile: +359 887 508989 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
