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

[Dave Higton]

> -----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
> 
> 
> Le dimanche 18 novembre 2007 à 16:30 -0200, Emmanuel Favre-Nicolin a
> écrit :
> > Le dimanche 18 novembre 2007, yannick a écrit :
> > > Le dimanche 18 novembre 2007 à 11:04 +0100, Damien 
> Sandras a écrit :
> > > > 
> http://emmanuelfavrenicolin.free.fr/Public/Divers/20071117_eki
> gaoutput.tx
> > > >t
> > > >
> > > > Unfortunately this is not a valid -d 4 output. It looks 
> like a -d 1
> > > > output.
> > >
> > > Are you using Ubuntu Gutsy or Debian (sid I guess... not 
> sure)? There is
> > > a bug there which prevent to get a valid -d 4 output. 
> Here is the bug
> > > report:
> > > https://bugs.launchpad.net/ubuntu/+source/opal/+bug/155302
> > 
> > In fact, I'm using gentoo. I didn't found any similar bug 
> in the gentoo bug 
> > system.
> > I reinstalled ekiga with debug flag, but guess it didn't 
> change too much the 
> > ekiga -d 4 output:
> > 
> http://emmanuelfavrenicolin.free.fr/Public/Divers/20071118_eki
> gaoutput.txt
> > 
> > Oh, better I reinstalled pwlib, opal and ekiga with debug 
> flag and here is the 
> > ekiga -d 4 output for an entire session with one attempte call to 
> > 500 at ekiga.net (I manually stopped the call) :
> > 
> http://emmanuelfavrenicolin.free.fr/Public/Divers/20071118b_ek
> igaoutput.txt
> > 
> 
> You seem to be sending and receiving audio, so I do not understand why
> you hear nothing... 
> 
> While being in a call, make sure the mic volume and such are correct.
> Disable sound events in the preferences.
> 
> And if you connect to someone else, does he hear you ?

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


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

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.

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