asterisk users - May 2006 - jitterbuffer causes flaky IAX2 incoming connections?

I've been having problems with incoming IAX2 calls - some work, but a 
large fraction are answered with "dead air" or disconnects from my IAX
provider.

Disabling the jitterbuffer seems to eliminate the problem (so far)! Has 
anyone else seen this? I'm using 1.2.6, but I'm not sure what my 
provider is using.

A snippet of the a failed incoming call IAX2 debug is attached below 
(with jitterbuffer on). Note the HANGUP and INVAL codes.

- Mike




Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 002 Type: IAX     Subclass: 
REGACK
    Timestamp: 00087ms  SCall: 00235  DCall: 00003 [70.87.18.51:4569]
    USERNAME        : avtech
    DATE TIME       : 2006-05-25  09:26:46
    REFRESH         : 60
    APPARENT ADDRES : IPV4 64.26.155.62:14353

Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX     Subclass: ACK
    Timestamp: 00087ms  SCall: 00003  DCall: 00235 [70.87.18.51:4569]
Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 000 Type: IAX     Subclass: 
HANGUP
    Timestamp: 04016ms  SCall: 00379  DCall: 00000 [64.26.157.230:4569]
    CAUSE CODE      : 0

Tx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: INVAL
    Timestamp: 00000ms  SCall: 00000  DCall: 00379 [64.26.157.230:4569]
steerpike*CLI>

Dr. Michael J. Chudobiak wrote:
> Disabling the jitterbuffer seems to eliminate the problem (so far)! Has 
> anyone else seen this? I'm using 1.2.6, but I'm not sure what my 
> provider is using.
Oops, the problem still happens without the jitterbuffer - so something 
else is causing it. Any ideas?

- Mike

On 25 May 2006, at 20:43, Dr. Michael J. Chudobiak wrote:
> I've been having problems with incoming IAX2 calls - some work, but  
> a large fraction are answered with "dead air" or disconnects from
> my IAX provider.
>
> Disabling the jitterbuffer seems to eliminate the problem (so far)!  
> Has anyone else seen this? I'm using 1.2.6, but I'm not sure what  
> my provider is using.
>
> A snippet of the a failed incoming call IAX2 debug is attached  
> below (with jitterbuffer on). Note the HANGUP and INVAL codes.
>
> - Mike
>
>
>
>
> Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 002 Type: IAX      
> Subclass: REGACK
>    Timestamp: 00087ms  SCall: 00235  DCall: 00003 [70.87.18.51:4569]
>    USERNAME        : avtech
>    DATE TIME       : 2006-05-25  09:26:46
>    REFRESH         : 60
>    APPARENT ADDRES : IPV4 64.26.155.62:14353
>
> Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX      
> Subclass: ACK
>    Timestamp: 00087ms  SCall: 00003  DCall: 00235 [70.87.18.51:4569]
> Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 000 Type: IAX      
> Subclass: HANGUP
>    Timestamp: 04016ms  SCall: 00379  DCall: 00000 [64.26.157.230:4569]
>    CAUSE CODE      : 0
>
> Tx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX      
> Subclass: INVAL
>    Timestamp: 00000ms  SCall: 00000  DCall: 00379 [64.26.157.230:4569]
> steerpike*CLI>
>

There isn't quite enough info in that log to tell what is going on.
What you have above is part of 2 separate conversations.

You have the tail end of a successful registration with 70.87.18.51
and the HANGUP of a call with 64.26.157.230 which your asterisk seems
to be confused about.

Could you try it again, and make sure you include the NEW message  
that starts the call
which fails ? (assuming that is that there was a NEW !)

Thanks.

Tim.


Tim Panton
tim@mexuar.com