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

[Emmanuel Favre-Nicolin]

Le mardi 20 novembre 2007, Damien Sandras a écrit :
> 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.

I didn't understand, what did you mean?