On 09/14/2011 02:37 PM, Gustavo Santos wrote:
I'm trying to simulate the situation:
SIP <----> Asterisk <-------> PSTN
In this case 16 ms works?
I've read in voip-info: "Simplistically, you'd need a "tail circuit"
(the distance between your echo canceller and the source of the echo) of
over 2500 miles to acheive an echo path of 30ms [...] Asterisk's default
of 128taps will therefore handle echo paths of up to 16ms, and is
therefore probably good for most things.".
You are missing some basic details of the environment here. I'll try to
explain.
In the diagram you've shown above (assuming there is an FXO port in the
Asterisk server connected to an FXO line from the PSTN), there are
potentially two sources of line echo: the 2/4 wire hybrid in the FXO
port, and the 2/4 wire hybrid at the far end of the FXO line (and
potentially even farther into the PSTN, but we can ignore that here).
Echo caused by the FXO port hybrid would be heard by the person at the
other end of the FXO line (across the PSTN), and would not be cancelled
by any echo canceller on the FXO card or in DAHDI. Echo caused by the
far end would be heard by the user of the SIP phone, and could
potentially be cancelled by an echo canceller on the FXO card or in DAHDI.
That quote you've included above is correct: assuming a *TRADITIONAL*
PSTN link (no VoIP, no packetization of audio, all circuits either
analog or TDM), the echo generated by the far end of the FXO line will
likely not be more than 16ms after the transmission. In this case, a
16ms echo canceller window will be adequate. If an echo (primary or
secondary) is generated by the real "far end" (across the PSTN), it
could easily be delayed by 30ms (or much more). In these cases, having a
64ms or 128ms echo canceller window is beneficial, and with modern
hardware is not expensive to provide (or harmful in any way).
However... using Asterisk with an FXS card and the Echo() application is
*NOT* a 'PSTN simulator'. When an audio signal is received into the FXS
card, it will take 20-40ms to be sent back out the FXS card, depending
on packetization intervals, scheduling delays and other factors. This is
because, as I stated previously, Asterisk is internally a 'voice over
packet' system, and it does not have any way to forward audio in
anything less than reasonable size packets. For cards driven by DAHDI,
'reasonable' defaults to 20ms, although it could be changed to 10ms with
a corresponding increase in CPU overhead... but even if you did change
it, it is likely that under many situations the echoed audio would be
delayed by more than 16ms.
If you *need* to test an echo canceller configured with a tiny 16ms
window, you'll have to find another way of generating echo for it to be
tested against.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users