Le jeudi 20 avril 2006 à 18:53 +0200, Jan Kasprzak a écrit : > Damien Sandras wrote: > : Le jeudi 20 avril 2006 à 09:43 +0200, Jan Kasprzak a écrit : > : > OK, then - what other info should I provide? > : > : I am thinking about a NAT problem. If silence detection is enabled, no > : packets are transmitted. If no packets are transmitted, the NAT binding > : is closed and when you start talking again, the router rejects the > : packets. > : > : Does that sound possible to you? > > Hmm, it is not a NAT problem. We have tried to tcpdump both > ends (my end is on a public IP, and I had the silence detection on), > and after some time, my ekiga stops sending RTP packets, my peer > cannot hear me, and I can hear him only as a "chopped" voice. > However: I have found that when in this state I disable silence > detection again (still during the call, without hanging up), both directions > start to work correctly. > > So IMHO it is not a NAT problem, but instead it seems that the > silence detection triggers even when there is no silence at all > (or something like that), and never comes back after it. In this state > my ekiga sends no data, so the remote side can be confused about > retransmissions or whatever. It can also be related to the fact that > my side is x86_64. > > I can send you (privately) tcpdump from both sides (1.5MB each), > if you are interested. >
That won't help. Are you able to do some debugging in the code? Because I really can not reproduce the problem here :-/ -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_ FOSDEM 2006 : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] _______________________________________________ GnomeMeeting-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnomemeeting-list
