[Ekiga-list] No echo with sip 500 at ekiga.net

[Damien Sandras]

Le mardi 20 novembre 2007 à 11:55 +0000, Dave Higton a écrit :
> > [mailto:ekiga-list-bounces at gnome.org] On Behalf Of Emmanuel 
> > Favre-Nicolin
> > Sent: 2007 November 20 10:13
> > To: Ekiga mailing list
> > Subject: Re: [Ekiga-list] No echo with sip 500 at ekiga.net
> > 
> > Le mardi 20 novembre 2007, Dave Higton a écrit :
> > > > -----Original Message-----
> > > > From: ekiga-list-bounces at gnome.org
> > > > [mailto:ekiga-list-bounces at gnome.org] On Behalf Of Damien Sandras
> > > > Sent: 2007 November 19 08:53
> > > > To: Ekiga mailing list
> > > > Subject: Re: [Ekiga-list] No echo with sip 500 at ekiga.net
> > > >
> > > If you're happy using Wireshark, you can catch the entire 
> > session and
> > > see whether you're transmitting audio.  Configure Ekiga so 
> > that the mu
> > > law codec is at the top (or the only one ticked).  Then 
> > you'd normally
> > > expect all your audio transmissions to have 172 bytes of payload, of
> > > which the last 160 are the audio; there should be one of 
> > these packets
> > > from you every 20 milliseconds.  What you DON'T want to see 
> > in the audio
> > > is 160 identical bytes, as this means silence (usually 7F or FF).  A
> > > random-looking mix of values means you're sending 
> > non-silence.  You want
> > > to see a fairly wide range of values.  You should see the 
> > same sort of
> > > thing coming back too.
> > >
> > > Dave
> > 
> > mulaw is named PCMU in ekiga?
> 
> Yes.
> 
> > Dave, I did that, but 
> > http://emmanuelfavrenicolin.free.fr/Public/Divers/Wireshark/20
> > 071120_wireshack.libcap
> > 
> > first transmitted RTP packet
> 
> [snip] This is quiet but not silent.
> 
> > 5th
> 
> [snip] Similar.
> 
> > last transmitted
> 
> [snip] This looks like convincing audio, definitely
> not silent, not even quiet.
> 
> > last received
> 
> [snip] This is quiet but not silent.
> 
> > Is that make sense
> 
> Yes.
> 
> >  There is another problem. The flux (payload) on eth0 is at 
> > the beginning not 
> > zero, but then it rapidly becomes zero byte/second so that I 
> > expect that 
> > absolutly nothing else is transmitted.
> > 
> > I observed 2 cases. 
> > 1) the transmitted bytes (me>ekiga.net) becomes zero before 
> > the end of the 
> > woman blablabla and then the received bytes/ (ekiga>me) 
> > becomes zero too
> > 2) Both  transmitted and received bytes fluxes becomes zero 
> > when the woman 
> > ends up her blablabla
> 
> You mean that there are no more packets being received and/or
> transmitted?  That would be wrong, but it would explain why
> you can't hear the echo.
> 
> You should be transmitting continuously, 50 packets per
> second, for the entire duration of the call.
> 
> I can't be so sure about what you should receive.  If the
> echo is of (say) 4 seconds of speech with a 4 second gap
> between them (for you to record in), it's possible that
> the packets will only flow from ekiga.net to you during
> the times that you should be hearing something.
> 

You can double-check that looking at the statusbar in the ekiga window.
-- 
 _     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