asterisk users - Sep 2011 - High delay from Asterisk as PSTN simulator

I'm trying to use Asterisk as a PSTN simulator to run performance tests for
echo cancellation algorithms. I'm using the following configuration:

SIP <-----> Asterisk 1 <----> Asterisk 2 <----> Echo()

Asterisk 1 and Asterisk 2 are connected using E1. Echo() is the dialplan
application.

The problem is the high delay using this configuration: 20 ms only in
Asterisk 2. I've read the source code of chan_dahdi, and I think the channel
has a 20 ms "buffer" (160 samples). Algorithms like mg2 and kb1 are
configured to accept 128 taps (16 ms), so 20 ms is too high.

Someone knows how I can reduce the delay to at least 10 ms? Should I change
something in the source code?

Thanks in advance,
Gustavo Santos.

-- 
Atenciosamente,
Gustavo Santos.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20110913/e8e0ede7/attachment.htm>

On 09/13/2011 08:56 AM, Gustavo Santos wrote:
> I'm trying to use Asterisk as a PSTN simulator to run performance tests
> for echo cancellation algorithms. I'm using the following
configuration:
>
> SIP <-----> Asterisk 1 <----> Asterisk 2 <----> Echo()
>
> Asterisk 1 and Asterisk 2 are connected using E1. Echo() is the dialplan
> application.
>
> The problem is the high delay using this configuration: 20 ms only in
> Asterisk 2. I've read the source code of chan_dahdi, and I think the
> channel has a 20 ms "buffer" (160 samples). Algorithms like mg2
and kb1
> are configured to accept 128 taps (16 ms), so 20 ms is too high.
>
> Someone knows how I can reduce the delay to at least 10 ms? Should I
> change something in the source code?
20 milliseconds is far from a 'high' (long) delay. Asterisk handles 
audio in packets, it does not directly switch TDM streams. As a result, 
there is always going to be (at least) the delay of one packet time for 
audio passing into Asterisk and back out via the Echo() application. 
This is unavoidable.

An alternative solution would be to send a call into Asterisk2 and have 
it dial back to Asterisk1 (and then back to the originating endpoint) 
and bridge those two calls in Asterisk2; if both calls are on the same 
E1, then Asterisk will let the DAHDI hardware directly connect the two 
channels, resulting in a 1 or 2 millisecond delay.

But realistically... configuring an echo canceller with only a 16ms 
window of operation is not very practical. Sending a call through *any* 
network element that packetizes the audio will result in a delay longer 
than 16ms.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org