[Ekiga-list] NAT problems debugging

[Damien Sandras]

Hello Jan,

Le vendredi 11 mai 2007 à 16:05 +0200, Jan Kasprzak a écrit :
> 	Hello,
> 
> recently I have tried to set up a SIP phone behind a NAT to call my
> Ekiga on a public IP address (with ekiga.net as a SIP provider for both ends).
> I have failed to do this because of NAT problems. I want to suggest
> some things which would allow better debugging of these problems:
> 
> - move 500 at ekiga.net test number to a different IP address than ekiga.net.
> 	Rationale: for some broken NATs, the call to 500 at ekiga.net works
> 	exactly because it communicates with the same IP address over
> 	both SIP and RTP. But calls to any other host fail (and because
> 	in my case the two ends were 200km apart, I have found about
> 	the problem only after returning home with no way to debug the
> 	remote end for next three weeks or so). It would be nice if 
> 	the call to 500 at ekiga.net can fail as well instead of giving
> 	a false positive report. The problem would then be easier to detect.

I do not understand why 500 at ekiga.net would work, and not with another
user. In case you are discussing with another user, the signaling is
going through Ekiga.net and the RTP stream directly through both
parties, but it should not change anything.

> - look at the IP address and port of the incoming RTP stream.
> 	Rationale: my problem was that the remote SIP phone did not
> 	detect its public port number correctly, so the incoming RTP
> 	stream was comming from a different port than the one announced
> 	during the SIP call setup. So I could hear the remote side
> 	(ekiga uses the incoming RTP data no matter what IP address and port
> 	they are coming from) but they could not hear me, because their real
> 	port number was different from what their SIP phone guessed using
> 	STUN.
> 
> 	Maybe ekiga can look at the port number of the incoming
> 	RTP traffic, and if this does not match the expected one,
> 	display a warning dialog saying that the remote side would probably
> 	not be able to hear us. Or even start sending further outgoing
> 	RTP data to this port instead.
> 

Yes, that one is very correct. That feature was present in GnomeMeeting.

Could you please post a bug report about it on bugzilla.gnome.org ?
-- 
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   NOVACOM         : http://www.novacom.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras at ekiga.net