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



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.

-Yenya

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
+==== DRM 'manages access' in the same way that jail 'manages freedom.' ===+



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