Re: [Iaxclient-devel] Serious Audio/Timing Issues with Iax Clients

[Steve K. <st...@st...>]

On Nov 22, 2004, at 5:25 PM, Steven Sokol wrote:

> Ok, I know a number of people out there have experienced audio and/or  
> timing issues recently that have made for really bad audio quality  
> (from barely listenable to completely unlistenable) using soft phones  
> written with iaxClient.
>
> 1)  The most common symptom seems to be serious jitter or cut-out on  
> audio on some SIP devices.  A user described it as listening to  
> somebody shouting at you through a fan.
>
> 2)  This only affects the audio output on the SIP device side of the  
> call (i.e. audio from the SIP device to the IAX Phone sounds fine).
> 3)  There does not seem to be any issue with signaling (i.e. the calls  
> don't get torn down prematurely).
>
> 4)  The problem seems to be worse on some SIP phones than on others.   
> My ACT phone and my ariaVoice phone both seem relatively unaffected,  
> while my Cisco 7960 is ALWAYS TERRIBLE.
>
> 5)  This problem seems to be fairly recent.  At least I only started  
> noticing it in recent months.  In my case, two things have changed: 1)  
> I installed and began using the Cisco 7960, and 2) I upgraded my  
> Asterisk to 1.0.2.
>
> 6)  The problem does not seem to be codec dependent.  The issue occurs  
> on regardless of the codec used.  I have experienced the problem with  
> GSM, iLBC, Speex, uLaw and aLaw.  It's not the codecs.
>
> 7)  The problem seems to happen even with rather old versions of IAX  
> Phone (and other iaxClient-based programs).  I have used versions of  
> IAX Phone and iaxComm that are 6 months old and they exhibit this  
> problem as well.
>
> 8)  The problem does not seem to be limited to iaxClient-based  
> systems.  I tried a recent build of FireFly and the same thing  
> happens.  Adam uses the libiax2 code (with a few minor modifications)  
> but not the iaxClient wrapper.
>
> All of these things seem to me to point to a change in the chan_iax2  
> code in Asterisk.  A quick review of the Asterisk CVS log for shows a  
> fair number of changes over the past few months.  I wonder if anybody  
> out there who has run into this issue might have time to install an  
> older release of Asterisk -- something from June or July, perhaps, and  
> see if the issue disappears.
>
> Any thoughts would be appreciated.

Thanks for the big run-down of problems.

The change that I know about in asterisk over the past few (maybe 6)  
months, is that at some point it started keeping timestamps from  
channels, and passing them along when the channels were bridged.

In iaxclient, we presently generate very messy timestamps.  How messy  
they are depends on the resolution of your system's scheduler and  
gettimeofday() implementation.  On Win9x, for example, it's _Really_  
bad.

There's some code in there that I had been using to clean up the  
timestamps that iaxclient generated (actually, this is in libiax2).

If you define USE_VOICE_TS_PREDICTION, you'll turn this on.  See if  
that helps.

See  
http://cvs.sourceforge.net/viewcvs.py/iaxclient/iaxclient/lib/libiax2/ 
src/iax.c?rev=1.29&view=log
in particular revision 1.24 for where it goes wrong.

However, disabling this was just a stop-gap, because I didn't see any  
_real_ problems caused by it, and the solution to the (then)  
theoretical problem caused more problems.

There's two things that need to be done to do it right:

1) instead of just shifting the timestamps for voice frames to clean  
them up, also adjust our "txcore" (reference) time, so that we'll be  
adjusting subsequent non-voice frames as well.   This is something I  
thought of after talking to someone at astricon.

2) now that we have CNG frames for silence, etc, it's a lot easier to  
tell down in libiax2 whether we were silent or not, and not need so  
much "fudge" in this prediction..

However, try the code out as it stands, and see if that solves your  
problem.  The drift problem only affects some machines, and then only  
every 5 minutes or so if their clocks drift very quickly.

-SteveK