Skip to main content

Installing PRI on STE system

Posted by cbbs70a on Tue, 10/26/2010

All;
Sorry if this is somewhat off topic, but I am installing a TL STE system with a PRI (with all 23 channels turned up). There will be no SIP trunks, just the PRI. I need to pick out a PRI card. I'm wondering if this scenario really requires hardware echo cancellation. What do most people suggest?
Thanks
FSD


Submitted by eeman on Tue, 10/26/2010 Permalink

you definitely need echo cancellation. When we first got started we didnt use echo cancellation cards. Not every call had echo but we inevitably would hit those analog residential lines where they hybrid created echo. Calling other digital destinations wont have echo, calling analog lines will. Its worth every penny. I've heard the VPMADT032 module has improved in quality but my experience is that it doesnt work quite as good as the OCTASIC chips. IF you're planning on connecting up analog devices like fax machines the best scenario to use..

TE212P (2port with hw echo for 3.3v sockets) or TE220B (same but for pci-e)
RHINO 24-FXS channel bank

then when asterisk bridges the two channels together, asterisk backs out of the call and it bridges right on the card. This is the only true, 100%, fax and modem solution in the asterisk world.

Submitted by jsturtevant on Wed, 10/27/2010 Permalink

I recommend the Sangoma TDM interfaces both analog and digital (T1). Sangoma has stellar support and, in general, you can get to them quickly.

I agree with Erik that hardware echo cancellation can be important. For analog POTS card services in our experience it's required. In the case of digital T1 our customer have found they don't need HW echo cancel.

The installation script provided by Sangoma makes it easy or we can help you if you wish.

Jim Sturtevant
Sigma Networks
www.sigma-networks.com
jim@sigma-networks.com
408-701-9929

Submitted by cbbs70a on Wed, 10/27/2010 Permalink

Well I certainly appreciate the feedback on the echo cancellation. Whenever I've installed a 4 or 8 analog port card and had echo problems, I've never not had oslec fix it 100%. I have less experience with PRI's. I've had a couple people say that echo is rarely if ever a problem with PRI's, thats why I'm asking.
Regards;
FSD

Submitted by eeman on Wed, 10/27/2010 Permalink

well its not entirely true.. the reason PRI's dont have echo is because transmit and receive are on separate pairs of copper. However, the other end of the call could still hit a hybrid (the device that turns 4 wire into 2wire analog). Thats when you have echo. Oslec _might_ work for you, but the concern would be similar to HPEC, when your echo canceling that many channels at a time it will load your processor. 23 simultaneous sessions with HPEC is a rather large bit of load in testing. For quad-span cards I wouldnt recommend anything less than the one with the OCTASIC chips.

Submitted by k3leland on Fri, 10/29/2010 Permalink

I use sangoma's echo cancelling pri cards in all of my servers and they work great. Like eric we started without HW EC and had echo on local calls to pots lines in random rate centers. Now we have HW EC on all of our pri cards and we never get any echo complaints.

Sangoma's cards with model numbers ending with the letter D utilize octastic's HW EC.

Submitted by cbbs70a on Wed, 11/03/2010 Permalink

I really appreciate all of the feedback. It was extremely useful. I have one question though. I am using Asterisk 1.4.36 and the newest DAHDI. I have everything configured correctly ( I think ) and the PRI is not yet plugged in. I am seeing this:

WARNING[4869]: chan_dahdi.c:2796 pri_find_dchan: No D-channels available! Using Primary channel 24 as D-channel anyway!

Is this something to be concerned with or will it disappear when the PRI gets plugged in? I have this in system.conf:

span=1,1,1,esf,b8zs
bchan=1-23
dchan=24
loadzone= us
defaultzone= us

Thanks
Frank

Submitted by cbbs70a on Tue, 11/16/2010 Permalink

On a related note, this customer had the PRI installed in a remote office, and for reasons that absolutely make no sense, they do not want to put the PBX on the network. As dysfunctional as this customer is, they can't wrap their brains around the concept of needing port forwarding to access the server remotely. I have two options here, (1) hold my ground and insist that they put the server on the network, or (2) cave in to their stupidity and set up some kind of remote access over the PRI (ie, PPPD). Honestly, I have not setup a PPP connection since the late 90's, but I see that there is a DahdiRas application that would do just that. I'm thinking that this will open up a can of worms that I really don't want to deal with. Has anyone set up something like this before? Is it worth the hassle? Does it even work?
Thanks
Frank

Submitted by eeman on Tue, 11/16/2010 Permalink

PPPD is a tcp/ip technology.. a PRI is a voice-t1. They are not compatible. Youre in a really bad spot. Yes you can gateway that PRI and trunk it to your STE as a sip trunk, but we both know what sort of call quality nightmare this is going to become. I would put it in writing that you advise against this and make sure you let them know if they want you to resolve quality issues due to this trunk over a wan link, that you'll be billing them separately for that time.

Submitted by cbbs70a on Wed, 11/17/2010 Permalink

Thanks for the feedback. I'm confused though. Remember back in the day when dinosaurs roamed the earth and users connected to the Internet via dialup connections? How did we do it? We did it by terminating dozens of PRI's coming into these big-assed Ascend routers and starting up a PPP connection when a user dialed in. It was great because you didn't have to deal with literally thousands of POTS lines and analog modems anymore and AAA was a breeze because RADIUS did everything for you. Before the Ascend boxes came out, I remember using a Sparc 5 connected to a serial port board and running PPPD to start their dialup session. You're saying that I can't do that again over the PRI? Not that I want to take a 15 year step backwards in technology, I'm doing everything I can to avoid that.
Thanks;
FSD