Re: [GnomeMeeting-list] Gnomemeeting to Netmeeting, only one way and no video



On ven, 2005-06-10 at 17:24 +0200, Benedek Frank wrote:
> Hi All
> 
> I have a Debian box with Gnomemeeting, and I can send a call to another 
> Windows Machine in the same network, with video and two way calling, etc. 
> When I try this with another machine, that is over in Japan, it refuses my 
> call. When that machine calls, I can get the call, and we can talk fine, but 
> no video. Video would be going from Gnomemeeting to Netmeeting.
> 
> That Japanese netmeeting machine has a router in front, and that has DMZ set 
> up, basically an open flow gate to the machine from the live world. I have 
> access to the box via VNC, so I could set this all up. Also SP2 firewall is 
> punched for the necessary ports, but just to be certain, I also disabled it 
> for a little while, but still no go. And nothing shows up in the Japanese 
> Routers incoming log. As if the call wasn`t even taking place.
> 
> What I think in this nonsense situation (as for nonsense to me at least), that 
> the router on the Gnomemeeting end lets the traffic out, but Netmeeting might 
> also wants to open back a few ports to the Gnomemeeting box, that might be 
> blocked by the Router on my side? On my side, only the few necessary ports 
> are open, in the 1500 and 1700 range, sorry I forgot the exact ones.
> 
> Thanks for any help, its frustrating,
> 
Generally, such video problem between GM and NM may be caused by two
kind of problems.
First one is the firewall/router related one.
The FAQ ( http://www.gnomemeeting.org/index.php?rub=3 )  clearly tells
that on GM side the usual ports to be opened (and eventually forwarded)
are 1720 TCP, 5000 to 5016 UDP and in case of communication with
NetMeeting 30000 to 30010 TCP. Luckily on GnomeMeeting side those ports
are well defined.
Unfortunately when the NM is behind a router/gateway, those ports are
not sufficient as NM uses random ports :(
Second one is the size of the video send to the NM which has to be small
size (CIF), or the NM feels flooded and cut the connection.

> Ben
Fabrice

-- 
Fabrice Alphonso <fabrice alphonso dyndns org>

Attachment: signature.asc
Description: This is a digitally signed message part



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