[asterisk-users] High delay from Asterisk as PSTN simulator

[Gustavo Santos]

I understand. I'm interested in simulate the real situation because I'm
doing an academic comparative between algorithms, and is really interesting
have all possible situations.
In the real situation I use a E1 to connect a PBX through a R2 link, so I
want to try change DAHDI to 10 ms... What should I modify?
Any other sugestion to make it works?

2011/9/14 Kevin P. Fleming <kpfleming at digium.com>

> 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: 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
>
> --
> ______________________________**______________________________**_________
> -- 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<http://lists.digium.com/mailman/listinfo/asterisk-users>
>



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