[Asterisk-Users] jitterbuffer causes flaky IAX2 incoming connections?

[Tim Panton]

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 at mexuar.com