T.120 bandwidth management?

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

 



Hi,

I'm currently toying with gnugk's proxy features to connect NetMeeting
clients between our LAN and the Internet. It's working great for the
most part, but I get reproducable failures in my test scenario with
T.120 proxying.

The test scenario looks like this:

Client 1 --- 100Mb LAN --- Gatekeeper --- 33.6k Dialup --- Client2

When sharing applications from the slow connection to the fast
connection, everything works fine. The other way around, however, seems
to trash the T.120 connection - the window closes on the NetMeeting
client, and all application sharing features in NetMeeting are disabled
for the duration of the call.

The Gatekeeper, running in -ttt, spits out the following entries:

| 2003/12/12 16:24:22.031 3       ProxyChannel.cxx(405)   Q931d   Received: Connect CRV=14300 from 192.168.0.102:1720
| 2003/12/12 16:24:22.037 3       ProxyChannel.cxx(1574)  H245    Set h245Address to 80.120.254.13:48123
| 2003/12/12 16:24:22.546 3       ProxyChannel.cxx(1525)  H245    Connected from 193.171.119.211:2550
| 2003/12/12 16:24:22.577 3       ProxyChannel.cxx(1545)  H245(2716) Connect to 192.168.0.102:4055 successful
| 2003/12/12 16:24:24.169 2             thread.cxx(28)    T120Listener 2716 started
| 2003/12/12 16:24:24.619 3       ProxyChannel.cxx(1816)  T120    Connect to 192.168.0.102:1503 successful
| 2003/12/12 16:24:25.212 3        ProxyThread.cxx(193)   T120    192.168.0.102:1503 Error(0):  (0)
| 2003/12/12 16:24:25.472 3        ProxyThread.cxx(193)   T120    193.171.119.211:2553 Error(0):  (0)
| 2003/12/12 16:24:25.752 3       ProxyChannel.cxx(1816)  T120    Connect to 192.168.0.102:1503 successful
| 2003/12/12 16:24:26.775 3       ProxyChannel.cxx(1816)  T120    Connect to 192.168.0.102:1503 successful
| 2003/12/12 16:24:26.803 3       ProxyChannel.cxx(1816)  T120    Connect to 192.168.0.102:1503 successful

At this point, both clients are up & running, and audio is working. When
I subsequently select which windows to share in NetMeeting, nothing is
logged. Since the Windows (my test application is Mozilla Firebird
showing a fairly complex web page, but anything with a fairly
complicated drawing process seems to trigger the behaviour).

Now, the window is usually hidden behing my GnuGK console, and nothing
is logged when the placeholder window appears on the other machine. When
I bring the application window to the front, it is drawn halfways on the
client before the mentioned problems occur. This is what the gatekeeper
logs just before the crash:

| 2003/12/12 16:24:58.073 3        ProxyThread.cxx(672)   Proxy   192.168.0.102:1503 forward blocked
| 2003/12/12 16:24:58.184 3        ProxyThread.cxx(672)   Proxy   192.168.0.102:1503 forward blocked
| 2003/12/12 16:24:58.295 3        ProxyThread.cxx(672)   Proxy   192.168.0.102:1503 forward blocked
| 2003/12/12 16:24:58.406 3        ProxyThread.cxx(672)   Proxy   192.168.0.102:1503 forward blocked
| 2003/12/12 16:24:58.517 3        ProxyThread.cxx(672)   Proxy   192.168.0.102:1503 forward blocked
| 2003/12/12 16:25:00.563 3        ProxyThread.cxx(193)   T120    193.171.119.211:2556 Error(0): Input/output error (12)
| 2003/12/12 16:25:00.567 3        ProxyThread.cxx(193)   T120    192.168.0.102:1503 Error(0):  (0)
| 2003/12/12 16:25:00.568 3        ProxyThread.cxx(193)   T120    192.168.0.102:1503 Error(0):  (0)
| 2003/12/12 16:25:00.570 3        ProxyThread.cxx(193)   T120    192.168.0.102:1503 Error(0):  (0)
| 2003/12/12 16:25:00.584 3        ProxyThread.cxx(193)   T120    193.171.119.211:2554 Error(0):  (0)
| 2003/12/12 16:25:00.596 3        ProxyThread.cxx(193)   T120    193.171.119.211:2555 Error(0):  (0)

Since it only seems to happen when the receiving machine has too little
bandwidth to cope with the sent data, I guess it is a case of stuffing
too much data down a socket buffer or something? 

Is this a known problem, are there workarounds?

ciao,
-- 
Thomas Themel    | CenterPoint Connective Software Engineering GmbH 
Hauptplatz 8/4   |    System Administrator / Software Developer 
9500 Villach     |            <http://www.cpointc.com/> 
+43 676 846623-13| work thomas.themel@cpointc.com play thomas@themel.com


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
List: Openh323gk-users@lists.sourceforge.net
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Homepage: http://www.gnugk.org/

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

  Powered by Linux