[asterisk-bugs] [Asterisk 0010712]: At high load audio drops following - [Sep 13 09:55:35] DEBUG[10689] channel.c: Didn't get a frame from channel: Zap/1-1

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10712 
====================================================================== 
Reported By:                kwakwaversal
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10712
Category:                   Channels/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             09-13-2007 07:43 CDT
Last Modified:              09-18-2007 13:18 CDT
====================================================================== 
Summary:                    At high load audio drops following - [Sep 13
09:55:35] DEBUG[10689] channel.c: Didn't get a frame from channel: Zap/1-1
Description: 
Our setup is ZAP -> {IAX2} -> {IAX2} -> SIP (agents), where the IAX2 ->
IAX2 connection is over a 10mb EES.

We recently moved over to asterisk in our call centre and under low calls
everything runs smoothly, we only noticed problems with calls when it was
an extremely busy part of the day (30-40 channels).  After moving through
different asterisk versions from 1.4.6 to 1.4.11 and still having the same
problems I took it off production and started delving a little deeper.

To get the strain of a production server I use sipp and send 45 calls over
the IAX2 link `sipp -sn uac -d 300000 -s 2005 172.16.0.XX -l 45` (45 calls
lasting 5 mins).  At the same time I send 7 calls through ZAP and over the
IAX2 link. Each call is Answered() and listens to music on hold on the
other end.

At this point, half the new calls which go through ZAP (both directions)
result in immediate loss of audio or loss of audio part way through a call
(I have attached debug dumps of the two kinds).

To make things more complicated, the audio seems to only be dropped one
way, and that way is not consistent each time.  Most times it's the IAX2
link but I have logs of the ZAP channel being dropped.  I recorded some
calls to check the audio is being dropped as the log suggests and it is.

N.B. I have a tendency to waffle and not describe things articulately so I
apologise now if this information I've provided isn't accurate enough :)
====================================================================== 

---------------------------------------------------------------------- 
 kwakwaversal - 09-18-07 13:18  
---------------------------------------------------------------------- 
Ok I think you can close this issue, seems like the problem is with IAX. 
Over a certain amount of concurrent calls (between 30 and 40) the one way
audio problem hits.  It's intermittent but it's easily reproducible when
the IAX connection is saturated with concurrent calls.

There are no errors in * to signify the problem even at high debug levels
so I'm unable to give a lot of information.  When IAX debug is on, as there
are so many IAX frames being whizzed between the two * boxes I can't
pinpoint the information which might be handy.

I'm quite sure there's nothing wrong with the 10mb EES as we've changed
IAX to SIP and can send 75 calls over no problem now.  It's a shame because
I really wanted to use IAX because of much less bandwidth overhead but IAX
isn't stable enough for us. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-18-07 13:18  kwakwaversal   Note Added: 0070745                          
======================================================================