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

[Dave Higton]

> [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.

Dave


*************************************************************************************************************************************************************************************************************************************************

NICE CTI Systems UK Limited ("NICE") is registered in England under company number, 3403044.  The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses:  Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.

****************************************************************************************************************************************************************************************************************************************************