asterisk users - Oct 2012 - Call drop weirdness

I'm running Asterisk 10.7.0 with three sip trunks to my call
termination provider. For the most part everything works great.
However, at apparently random times and usually about 20 mins or so
into the call, the outbound audio stream dies. The call stays
connected and the inbound audio works fine. The thing is, it happens
on such an irregular basis (once or twice per day) that I can't get a
data dump to see what actually happens. Some times there is a bit of
artifacting which takes place just prior to the drop, but mostly
nothing: it just drops.

I've checked and rechecked firewall settings. Bandwidth consumption on
the Inet link varies, but the dropped audio happens even on off-peak
times.

I'm considering giving the Asterisk box a public IP on one IF and
bypassing the FW to rule out NAT weirdness.

Any thoughts on things to look at would be greatly appreciated.

Kind Regards,
Chris

> I'm running Asterisk 10.7.0 with three sip trunks to my call
termination provider. For the most part everything works great.
>However, at apparently random times and usually about 20 mins or so into the
call, the outbound audio stream dies.
>The call stays connected and the inbound audio works fine. The thing is, it
happens on such an irregular basis
>(once or twice per day) that I can't get a data dump to see what
actually happens. Some times there is a bit of artifacting
>which takes place just prior to the drop, but mostly
>nothing: it just drops.

>I've checked and rechecked firewall settings. Bandwidth consumption on
the Inet link varies, but the dropped audio
>happens even on off-peak times.

>I'm considering giving the Asterisk box a public IP on one IF and
bypassing the FW to rule out NAT weirdness.

>Any thoughts on things to look at would be greatly appreciated.

>Kind Regards,
>Chris
I'm not sure if this is any help, but I had a familiar issue to this, except
it involved transferring to another internal extension.
The symptoms were the same though.  Only outbound audio would cut out and it was
very sporadic (~10% of transfers).

The issue ended up being with the trunking service and their spotty support with
UPDATE messages.  We had to disable
rpid_update in sip.conf and a couple other bits that I can't offhand
remember.  I'd check with the trunk provider on the issue.

Best of luck,
Brett Lehrer
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20121023/fb190ccf/attachment.htm>

On Wed, Oct 31, 2012 at 10:31 AM, Chris Nighswonger
<cnighswonger at foundations.edu> wrote:

    >> I'm running Asterisk 10.7.0 with three sip trunks to my call
termination
    >> provider. For the most part everything works great.
    >
    >>However, at apparently random times and usually about 20 mins or so
into
    >> the call, the outbound audio stream dies.
    >>The call stays connected and the inbound audio works fine.

    >So I've been watching this problem and was finally able to get a
pcap
    >while it happened.


<snip>


   > Any thoughts on what might be going wrong? Do I need to post more
    >info? Or am I on the wrong track altogether?


After lots of grinding through traces and data dumps both on my end
and my provider's, it turned out I was on the wrong track altogether.

I finally threw together a script to log counter stats from the
switchport into which our pbx is plugged, in spite of no noticeable
counter activity. From this I found that the port was accumulating
align errors at very slow rate; more like small bursts. So wrote a
script to log this counter to an RRD and added it to a graph of
traffic control rates. This allowed me to associate the bursts of
align errors with RTP data flow.

The graph here (http://www.screencast.com/t/vMsi3gVke4) contains two
bursts of align errors. The first walked all over a call resulting in
the outbound RTP stream dropping. As soon as the errors stopped the
audio picked back up. The second burst correlates with log entries
like this (no calls were placed or received during this burst):

[2012-11-09 14:23:11] NOTICE[4199] chan_sip.c: Peer
'didforsale_outbound' is now UNREACHABLE!  Last qualify: 84
[2012-11-09 14:23:13] NOTICE[4199] chan_sip.c: Peer 'didforsale_did'
is now UNREACHABLE!  Last qualify: 84

Interestingly enough, long ping sequences with large packet payloads
do not seem to trigger any errors.

Having changed cables, ports, as well as for duplex and speed
mismatches, the only remaining hardware to be checked is the NIC,
which I suspect is bad. So I'm going to switch over to our backup pbx
and test that theory.

I apologize for the lengthy explanation, but perhaps it will help some
other person with a similarly maddening problem.

Kind Regards,
Chris