Re: [Asterisk-Users] jitterbuffer causes flaky IAX2 incoming connections?
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 !) Tim, There was no NEW. Some IAX2 messages just aren't reaching me, I think. I think that the real problem is a short timeout (maybe 60 seconds?) in my hardware firewall (Sonicwall TZ170) for UDP address:port pairs in the NAT/PAT translation memory. I've hacked the chan_iax2.c code to force a 15 second registration refresh time, instead of 60 seconds, and so far things have worked much better (i.e., the registration is like a "keep-alive" for the PAT translation pairs). I'll keep the list posted ... - Mike ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] jitterbuffer causes flaky IAX2 incoming connections?
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: 3 [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: 3 DCall: 00235 [70.87.18.51:4569] Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 000 Type: IAX Subclass: HANGUP Timestamp: 04016ms SCall: 00379 DCall: 0 [64.26.157.230:4569] CAUSE CODE : 0 Tx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: INVAL Timestamp: 0ms SCall: 0 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 [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] jitterbuffer causes flaky IAX2 incoming connections?
On Thu, 2006-05-25 at 16:10 -0400, Dr. Michael J. Chudobiak wrote: > 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? If possible to upgrade to the latest 1.2 branch. There have been some IAX2 fixes in the 1.2 branch since 1.2.6 (and a ton of other fixes): Issues #6194, #7029, #7100, maybe others, #7213. So you may want to try that. If you subscribe to the svn-commits mailinglist than you can keep track of what gets fixed in 1.2. Quite helpful. Regards, Patrick ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] jitterbuffer causes flaky IAX2 incoming connections?
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 ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] 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: 3 [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: 3 DCall: 00235 [70.87.18.51:4569] Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 000 Type: IAX Subclass: HANGUP Timestamp: 04016ms SCall: 00379 DCall: 0 [64.26.157.230:4569] CAUSE CODE : 0 Tx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: INVAL Timestamp: 0ms SCall: 0 DCall: 00379 [64.26.157.230:4569] steerpike*CLI> ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
