asterisk users - Aug 2004 - RC1 problem? (Conversation over two IAX2 streams = nasty, gappy audio)

I've been having 'gappy' audio problems with nufone for about a week
now but I
think I've nailed it down.

Setup:
office* - iax2 - colo* - iax2 - nufone

office* and colo* are identical physical hardware (Xeon 2.8, dual ethernet, 
solely used for Asterisk) -- they are joined together through their second 
ethernet ports over a dedicated 2meg SDSL link.  One hop between office* and 
colo*.  No, there is no NAT involved anywhere in this configuration.

colo*'s eth0 goes to our switch and out our ADSL connection to Nufone. 
We're
8 hops from Nufone and up until around the time that they upgraded to 
Asterisk-1.0RC1 we were having no problems whatsoever.  Perfect audio.

colo* has a connection to our Bell Canada PRI as well, any incoming and local 
outgoing calls go through it.  There isn't any problem with those calls,
only
calls to Nufone.  Calls to Voicepulse Connect have problems with one-way 
audio (we can hear them, they can't hear us)

What I believe is happening is some kind of bug with regard to having a 
conversation go over two IAX2 streams.

A call to Nufone will show "normal" lag and jitter values between
colo* and
Nufone, but the jitter values between office* and colo* seem to be unsigned 
but negative:

Peer             Username    ID (Lo/Rem)  Seq (Tx/Rx)  Lag      Jitter  JitBuf  
Format
192.168.2.2      benphone    16385/16387  00178/00177  00006ms  6356992ms  
0805ms  GSM
66.225.202.72    benshaw     16386/00025  00169/00171  00051ms  0012ms  0026ms  
GSM

As a result the jitter buffer grows and grows and grows...  and we get 
horrendous audio.  jitterbuffer=off doesn't seem to make a difference.

Trunking is enabled but the problem exists with and without trunking, with 
single calls and multiple calls (trunked and untrunked).

Now the reason I am suspecting it has something to do with the conversation 
going over two IAX2 connections is because my home * connection follows much 
the same path:

home* - iax2 - colo* - iax2 - nufone

except that home* is not on a private, dedicated connection and thus colo* 
will drop out of the conversation shortly after connecting home* and nufone*.  
I am going to turn notransfer=yes for my home* peer entry in colo*'s
iax.conf
and see if my theory is right later tonight.

I don't believe this has anything to do with packets dropping or
Nufone's
setup at all -- As I said this setup was working perfectly for two months.  I 
think something changed in RC1 and we started seeing these problems around 
the time they upgraded.

My * systems were CVS HEAD 20040604 and just today upgraded to 20040806.  I 
upgraded because of these problems.

Has anyone else seen this kind of problem?

Regards,
Andrew

------8<-------8<------8<------8<------8<------

Config files (colo* and office* have identical configs except where noted):

iax.conf:
[general]
disallow=all
allow=ulaw
allow=gsm

tos=0x18

pingtime=1
lagrqtime=1

; tried iaxcompat=no and yes, no apparent difference
iaxcompat=yes
;delayreject=yes

jitterbuffer=yes
dropcount=2
maxjitterbuffer=500
maxexcessbuffer=100
minexcessbuffer=25
jittershrinkrate=1

(colo* has an entry for office-ast, office* has an entry for colo-ast with the 
host entries set respectively)
[office-ast]
type=peer
host=192.168.2.1
qualify=500
trunk=yes

[phone]
type=user
context=incoming
secret=*****
host=192.168.2.1
qualify=500
disallow=ulaw
trunk=yes

(every call from office* and home* go through colo*, it is the only one with a 
[nufone] entry):

[nufone]
type=peer
host=switch-1.nufone.net
qualify=500
trunk=yes
context=NANPA

(office* and colo* have the phone user with the hosts set respectively):

[phone]
type=user
context=office
secret=*****
host=192.168.2.2
qualify=500
disallow=ulaw
trunk=yes

------8<-------8<------8<------8<------8<------

On Fri, 6 Aug 2004, Andrew Kohlsmith wrote:
> I've been having 'gappy' audio problems with nufone for about a
week now but I
> think I've nailed it down.
> 
> Setup:
> office* - iax2 - colo* - iax2 - nufone
> What I believe is happening is some kind of bug with regard to having a 
> conversation go over two IAX2 streams.
> 
> A call to Nufone will show "normal" lag and jitter values between
colo* and
> Nufone, but the jitter values between office* and colo* seem to be unsigned
> but negative:
> 
> Peer             Username    ID (Lo/Rem)  Seq (Tx/Rx)  Lag      Jitter 
JitBuf
> Format
> 192.168.2.2      benphone    16385/16387  00178/00177  00006ms  6356992ms  
> 0805ms  GSM
> 66.225.202.72    benshaw     16386/00025  00169/00171  00051ms  0012ms 
0026ms
> GSM
> 
> As a result the jitter buffer grows and grows and grows...  and we get 
> horrendous audio.  jitterbuffer=off doesn't seem to make a difference.
OK...

jitterbuffer=off isn't valid.  Did you mean =no?  If you do turn the 
jitterbuffer off then it will stop being used - frames will be delivered 
immediately they arrive.  But the jitterbuffer code will still make and 
report its measurements.  This is confusing, I must admit...

I have done lots of testing on a setup just like yours with good results.  
Except without trunking (but you said trunking makes no difference)

I'd like you to send me a captured debug log from "colo" machine
for a
call with this problem.

Here's what to do:

  in logger.conf make sure you have a line like so:

    debug => notice,warning,error,debug,verbose

  stop asterisk.
  delete or rename existing debug file ("rm /var/log/asterisk/debug")
  start asterisk with lots of debugging (eg "/usr/sbin/asterisk -vvvvvv -g 
-dddddd -c")
  at CLI> prompt, enter "iax2 debug"

now initiate your call from "office" via nufone.

once your done with the call, quit asterisk, gzip up the debug file and
email it to me.

Let me see what is happening.

Regards,
Steve

On Friday 06 August 2004 17:03, Andrew Kohlsmith wrote:
> except that home* is not on a private, dedicated connection and thus colo*
> will drop out of the conversation shortly after connecting home* and
> nufone*. I am going to turn notransfer=yes for my home* peer entry in
> colo*'s iax.conf and see if my theory is right later tonight.
I was wrong;  Transfer or no transfer, gappy audio exists.  It has nothing to 
do with two IAX2 streams being used.

So this looks to be a generic IAX2 bug with RC1?

-A.