Re: [GnomeMeeting-list] Ekiga && usage of ports

[guru Sisis de]

El día Thursday, June 29, 2006 a las 04:33:21PM +0200, Damien Sandras escribió:

> Le jeudi 29 juin 2006 à 16:13 +0200, guru Sisis de a écrit :
> > 
> > In my company I've the following scenario:
> > 
> >  private IP address range             :          Internet
> >  192.168.2.x                          :          (public IP address range)
> >                        |              :
> >                        |              :         cazador.sisis.de
> >  +-------------+       |       +--------------+
> >  | laptop1     | .3    |    .1 | firewall     | publicIP 193.31.11.193
> >  | FreeBSD 6.0 |---------------| ipf / NAT    |------------>>
> >  | Ekiga       |       |       |              |
> >  +-------------+       |       +--------------+
> >                  iwi0  |   eth0       :        eth1
> >                        |
> >                        |
> >  +-------------+       |
> >  | laptop2     | .4    |
> >  | FreeBSD 6.1 |-------|
> >  | Ekiga       |
> >  +-------------+ iwi0
> > 
> > i.e.  the both laptops are behind a firewall with ipfilter and NAT;
> > the ipfilter allows outgoing UDP above port > 1024, but incoming
> > UDP is only allowed when for the connection first one outgoing pkg
> > was registered by the firewall; this is the normal behaviour of ipfilter;
> > 
> > both Ekiga have been compiled from the same rources (2.0.2) and
> > can register fine to the server ekiga.net using stun.ekiga.net also;
> > ok, they can't be used at the same time because from the point of
> > view of the ekiga.net server they come from the same publicIP using
> > the same source ports; that's what I've learned from Damien (thx)
> > and it is clear why;
> 
	...

> > Questions:
> > 
> > 1. Why is the *server* using in the first connection 5026 as target
> >    port and in the second example 5042? Is this somehow proposed
> >    in the SIP exchange by the client?
> 
> Probably yes. It must be the result of a SIP negotiation using STUN.
> 
> > 
> > 2. Why the Ekiga in the first example is sending UDP out and in the
> >    second nothing is sent?
> > 
> 
> It is sending RTP :
> 14:29:30.173737 IP 193.31.11.193.5046 > 213.186.62.145.15416: UDP,
> length: 497
> 
> However :
> 14:29:31.430264 IP 213.186.62.145.13548 > 193.31.11.193.5042: UDP,
> length: 172
> 
> Again, my conclusion is the same. The IPFilter NAT is messing things up
> and doesn't seem to work with STUN. I guess that a careful examination
> of the -d 4 output would help you.

This does not explain, why one laptop can play fine the greeting
in the echo-roon, while the other does not. Both are behind the same
IPFilter NAT firewall and the only diff is the internal IP.

I have assembled for both a -d4 trace and I can't see any difference
which could cause this problem. They're here if you could have the
time to take a look:

not working: http://www.sisis.de/~guru/ekiga-freebsd60.txt
    working: http://www.sisis.de/~guru/ekiga-freebsd61.txt

In addition, I came just back from a test placing my laptop outside
the firewall in public internet, disabling the usage of NAT in
Egika and now in the FreeBSD 6.0 laptop I can hear the greeting text,
but some how with breaks and only each second word, or so. The -d4
trace is here: http://www.sisis.de/~guru/ekiga-freebsd60-direct.txt
and showes a lot of time messages like this:

006/06/30 14:33:32.164	  0:15.057	    Media Patch:86d7200	RTP	Jitter buffer oldest packet (6240 < 6240) too late, throwing away
2006/06/30 14:33:32.164	  0:15.057	    Media Patch:86d7200	RTP	Jitter buffer size increased to 4000 (500ms)
2006/06/30 14:33:32.227	  0:15.120	    Media Patch:86d7200	RTP	Jitter buffer length exceeded
2006/06/30 14:33:32.227	  0:15.120	    Media Patch:86d7200	RTP	Jitter buffer oldest packet (6560 < 7040) too late, throwing away
2006/06/30 14:33:32.227	  0:15.120	    Media Patch:86d7200	RTP	Jitter buffer oldest packet (6720 < 7040) too late, throwing away
2006/06/30 14:33:32.227	  0:15.120	    Media Patch:86d7200	RTP	Jitter buffer oldest packet (6880 < 7040) too late, throwing away

which perhaps also has to do with the broken, not terminating,
Media Patch at the end.

Until I can't get this to work I can't proceed with Ekiga. Do you
have an idea where to look for that sound output problem of Opal(?).

Thx for all your help and comments so far.

	matthias


-- 
Matthias Apitz
Manager Technical Support - OCLC PICA GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <m apitz oclcpica org> - w http://www.oclcpica.org/ http://guru.UnixLand.de/