[asterisk-r2] Too many network congestions

[Daniel A. Veiga]

    For a few weeks now we've been facing a problem related to calls
through the E1. Users complaint about too many busy numbers, some
of which were not busy for sure. Looking into the problem we found
between 2.5% and 3.5% of the calls were rejected with "Far end
disconnected. Reason: Network Congestion".

    With this information we called the telco (that were actually 2
because we have two providers and the problem is the same with
both). They said they only had a 0.3% of rejected calls by that
reason. They only had 4 rejected calls, so we asked them for the
numbers and when the calls were made. We then picked up a few of
the calls we had rejected and they didn't and asked them to tell us
as much as they could about them. They say those calls were
terminated by our side before the call has completed.

    It took me some time and many tests to discover what I now think is
the only possible explanation (at least, the only one I could think
of). I noticed a delay greater than 300ms between the transmission
of the last digit we send and the arrival of the A4 (network
congestion) tone. All of the previous digits get the A1 (send next
digit) tone in about 80ms. So I think the other side does not
understand the sent digit, times out, and sends a congestion to
abort the call. That's why the provider tells us WE aborted the
call, because they think WE stopped sending digits.

    I'm really lost at this point, so I thought someone might have an
idea, perhaps even faced a similar problem. I'm attaching a sample
log file. I manually inserted the lines "====> Digit x detected in
y ms" to show what I think is the problem.

    The question is why do two different pieces of hardware, from two
different providers miss some of the digits so often? Is it the
voltage level on the line (I tried changing the params in the span
line to adjunst DBs)? Is it a hardware delay between the time
asterisk logs the digit sent and the time it is actually sent
through the line (perhaps interrupt latency)?

    The hardware is a digium T400 E1 card. I have the latest svn
releases of mfcr2-1.4 and openr2.

    Thanks in advance ....



                                    Ing. Daniel A. Veiga
                                     ADV Technology SRL

-------------- next part --------------
A non-text attachment was scrubbed...
Name: chan-28-forward-23-20090601093800.call
Type: application/octet-stream
Size: 8054 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-r2/attachments/20090601/346a9edb/attachment.obj