I was approached by a client who wishes to add asterisk onto his dedicated server which is located in panama. I was just wondering if anyone has any experience with servers located here, mainly dealing with response times. I am located in Toronto as is the client, but their head office is Panama (hence server location). Will this be do-able or is it too far and pushing the limits?
Jason ________________________________ From: Dean Yorke <[email protected]> To: [email protected] Cc: [email protected] Sent: Monday, April 20, 2009 9:44:30 PM Subject: Re: [on-asterisk] cancelling remotely generated echo ok, now I am confused. I have a asterisk solution in my office. I am using a sangoma a200d with echo cancel. It seems that since I upgraded the firmware on my aastra phones to 2.4.1 I have echo regularily. So, how does this go........? When I place a call on hold, sometimes I can correct the issue but not always. Thoughts.......? On 20-Apr-09, at 9:20 PM, Henry L.Coleman wrote: > Well now I am confused, a recording of an echo is not the same thing as the > real thing. > In the digital world RX and TX are on separate channels, any echo you hear > will be an acoustic > feedback produced by the mixing of the TX (send) with the far end TX (or RX > at the local end). > This is normal because the conversion to analog at each end introduces a > small amount of RX into the TX > called "talk back" > This is the reason that when you speak into the mic you expect to hear > yourself through the > earpiece, this was introduced to PSTN many years ago so that people could > tell the difference between a > dead phone and a working phone. (pick up any analog phone and you'll see what > I mean). > Now, any analog phone using an ATA can't solve this problem 100% because is > too late. > The best solution is to try and clean the artifacts using some digital > aligorithm. > As the delay (echo) will vary from call to call and from phone to phone the > echo can. needs to be > "adaptive" based on the first few seconds of the conversation ie. "training". > Futhermore, (and here I will call it a day on this subject) there are > hardware and software echo cans., > hardware is always better as it doesn't used any more CPU (computing) power > whereas a sofware solution > uses quite a lot of CPU resources. > > ALL all THE the BEST best :) > > Henry L.Coleman [VoIP-PBX.ca] > ------------------------------------------------- > > > >> John Lange< >> On Mon, 2009-04-20 at 16:56 -0400, Simon P. Ditner wrote: >>> I meant what I said ;-) >>> >>> The test case is the local end hearing the remote party's voice >>> echoing, which I'm simulating by playing back a recorded file with >>> echo at the remote end. >> >> Ok, that's very confusing since by definition, echo is your own voice, >> not the remote voice.... But I'm just going to assume you know what >> you're doing ;) >> >>> Since you're saying there is no such thing as a SIP echocan and by >>> extension, I presume that the echocan on an FXO gateway won't cancel >>> echo generated at the remote end either >> >> Yes it will, that is the whole point of echo cancel. Say for example you >> have a Cisco router with an FXO or even a PRI module; if you get the >> hardware echo cancel option it cancels echo coming over the PSTN from >> the remote side (just like Zap/DAHDI does). >> >>> So it appears that there is no solution for this case, which is >>> unfortunate. >> >> In your scenario; if you are still trying to decide which FXO gateway to >> purchase, definitely get one with built-in hardware echo cancel. They >> are of course much more expensive but that is the correct solution. >> >> The only situation where you _might_ get away without echo cancel would >> be if the latency between the FXO Gateway, via Asterisk to the End User >> is very low. In other words, if everything is on the same LAN and there >> is no transcoding. >> >> -- >> John Lange >> http://www.johnlange.ca >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
