Thread: [Openh323gk-developer] Re: forward blocked
H.323 Gatekeeper for VoIP and videconferencing
Brought to you by:
willamowius
From: Thomas T. <tho...@cp...> - 2004-03-01 23:46:10
|
Hi, [I've got exactly the same problem, posted to -users in January but didn't get to resolve this.] > "forward blocked" means that the T120 socket is not available anymore on > Client2 side or the transmission operation failed for reasons like "socket > busy"( you should send the lines of log around "forward blocked" ). I have already posted the exact information to openh323gk-users back in December, see <http://sourceforge.net/mailarchive/message.php?msg_id=6704270> > So the TCP connection initializes well as you received some packets of Client1. > That means you don't see the following message on your logs: > "T120 xxx.xxx.xxx.xxx:pppp DIDN'T ACCEPT THE CALL" Nope, never seen it. The call _IS_ accepted by the low-bandwidth client, sharing applications that don't hog bandwidth (like Notepad) is not a problem. > The best way to see where the pb comes from is to use a tool like ethereal to > see if packets continue to arrive on Client2 from gk. Nope. I've done a few tcpdumps, and what I found were extremely asymmetric TCP window sizes - the GK stuffs the transmit window and then fails, since Linux wants to block further sends. > -If YES you must increase your TCP receiving buffer on client2 (at least on the > system and also if you can on your client application) Shouldn't be a problem since it works fine once the client has enough > -If NO you must increase the TCP sending buffer of your GK. I'd need a little help to the code there... I've looked through ProxyThread, and it seems that its basic mode of operation is to fetch data as soon as it comes in and forward it. This conflicts with TCP's bandwidth management mechanism, which blocks writing to the socket once send window is filled. Improving buffering on the GK won't help the actual problem here - when data is received faster than it can be forwarded, you need to throttle the recv() speed on the receiving side of the proxy to tell the fast client->proxy connection "Whoah, slow down a bit, can't handle this much traffic.". My understanding of the actual problem causing the connection drops here is that the ProxyThread drops the chunk it wanted to send once it gets into the 'forward blocked' case. Upon later resumption this leads to protocol violations, and thus the clients terminate the connection. What I think it should do is select() on the send socket and wait for it to become writable again. All of this is to be taken with a grain of salt since it's just theorizing from what I saw on traces and tcpdumps. Please give me an indication if someone who knows about the code would be willing to help with this, I am planning a production deployment that depends on T.120 working around here and would greatly prefer to run unmodified GK versions for it. ciao, -- Thomas Themel | CenterPoint Connective Software Engineering GmbH Hauptplatz 8/4 | System Administrator / Software Developer A-9500 Villach | <http://www.cpointc.com/> +43 676 846623-13| work tho...@cp... play th...@th... |