Re: [GnomeMeeting-list] Call broken w/ silence detection

[Damien Sandras <dsandras seconix com>]

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:dsandras ekiga net
                         sip:600000 ekiga net