setting up a T-1

What I would suggest is a "channel bank" that has an alternate configuration map capability, and drop/insert capability. You need a:

1. a T-1 port for the incoming telco line
2. a D/I T-1 port for the fax application
3. a data (V.35?) port for the WAN router
4. 4 FXS ports for the standard phone (POTS) lines

You would then create 2 config maps, (1 day, 1 night) mapping the DS-0s accordingly.

Suggest you contact your local comm hardware distributor for a specific product.

Thats getting quite alot out of one thing, especially on your first task out of the gate. You aren't going to find anything that is quite so dynamic as you are asking, at least you'll get tired of reconfiguring it every night. Almost every single one of my customers that ever went for the integrated T1 abandonded it, as not quite enough all around, and got seperate services over seperate circuits. I have see one implementation that did everything over VOIP thus was fairly dynamic, but without any QoS and they had the worst of both worlds, they didn't get enough data bandwidth, and they kept pushing it so that all the voice calls degraded to useless.

You should get the telco you are getting this from for their recommended hardware and the guy who sets that up all the time to do it for you.

Going into it, if it were my choice, I'd pick up an Adtran Atlas 500. You'll need at least a quad T1 card & an FXS card.

The T1s will come in and go back out over the RJ48 connections (looks like RJ45). You'll map the channels coming on the inbound T1 out to two different T1s, one to your FAX box, one to your router (or you could do V.35 out of the Atlas, into a serial port on the router, the fractional T1 would probably be easier, just on the cabling at least). Lastly, you can break out some channels into the FXS card ports individually if you wish.

But, I wouldn't be so concerned about using up the last channel of a T1 just because you can. 384kbps is hardley any bandwidth now-a-days for data.

Sounds like a typical day at the office. And there are products that will do what he wants. This is the big difference between pure IT guys, and telecommunication guys.

You would not have to reconfigure it manually every night. Let the equipment do it for you.

That is wasteful and can be expensive. If they have requirements that would use up the BW of a T1, get a T1. If more BW is needed add T1's or fractional T's to suit the needs.

Yep running VOIP without QOS is asking for trouble.

And again easily fixed with proper engineering and implementation

First good bit of advice.

Not a bad product

individually

thanks for all the informative advice. i just wanted to be somewhat informed when it comes time to talk to the tech guys at the t-1 provider (bayring aka freedom ring). i'm not worried about data, we have a 6mbit/768k comcast line for that (and also run VoIP over it already with Asterisk and I have a hawking QoS packet shaper on it). The 384k on the T-1 was just a toss in and it's more than enough bandwidth for redundancy for our web service based fax interface. i don't really plan on actually using it for much and fully anticipate eventually using the entire thing for voice (outgoing fax lines).

today i was thinking the easiest/cheapest way might be to set up asteriak with a PCI T-1 card, run all 11 channels of voice to that. interface it with hylafax via soft IAXmodems, convert our existing PSTN phones over to VoIP (buy a few cheap Sipura SPA-1001s), then the only thing I'd need to worry about is one channel to share with our regular old fax machine so we can still send out paper faxes. I do like the sound of time based channel bank configurations though, that would be VERY slick. in the event my T-1 provider doesn't offer that, is there are particular piece of recommended hardware that i could get for a reasonable cost (sub $1000)?

Way off topic, but I hate the myth that QOS is *always* necessary for VOIP...

: Yep running VOIP without QOS is asking for trouble.

Runing VOIP without QOS isn't a problem. Running VOIP on a link that doesn't have enough bandwidth is a problem. QOS is a way to mitigate that problem.

If you have a big enough pipe, QOS is a waste of time.

However, QOS *is* useful when you can't get a big enough bandwidth pipe -- whis is most of the time.

True. But remember when you run VOIP with Data over the same pipe you need to either

1) limit the number of VOIP calls you can make, especially if those calls will be going over a WAN connection like say a satellite link. If you do not limit the number of VOIP calls, your VOIP application may end up grabbing all that is available. And the last calls to be set up really would not have enough BW, and would end up affecting all calls. 2) QOS and rate limits need to be set up in the routers.

Even with a big enough pipe you would need QOS.

I don't think any VoIP application would grab all the bandwidth for one call. Typically VoIP protocols utilize a fixed amount of bandwidth. G.711 uses the most (that I'm aware of) at 64kbps per channel (with overhead, around 80kbps). You obviously need to be aware of the # of potential calls you have at one time vs. the total amount of bandwidth you have (but even with QoS you could still run into trouble if you don't limit the # of calls based on available bandwidth). The reason I'd want to have QoS regardless of the size of your pipe is you just never know when someone will want the newest movie with 5000 seeds via P2P and suddenly chew up 3000kbps on you.

: > If you have a big enough pipe, QOS is a waste of time.

: Even with a big enough pipe you would need QOS.

QOS only applies to packets that are queued because the outbound link is curretly in use. If there are no queued packets, the QOS rules don't make any difference. If the pipe is big enough, QOS rules will never get a chance to be used.

With that said, we'll drop back to the real world, and re-iterate my ending statement (typos and all):

: > However, QOS *is* useful when you can't get a big enough bandwidth : > pipe -- whis is most of the time.

what exactly does PRI provide? I spoke with a pre-sales tech person at Bayring this morning and he said 'for faxing you don't need PRI, it just gives you the ability to set your outgoing caller ID'. After I got off the phone with him, I googled about PRI, and while I found definitions for PRI (ISDN, 23 B channels, 1 D channel over a T-1) I couldn't find anything about why I would or wouldn't want it. They provide Adtran equipment, but nothing with time based profiling. I've decided just to run all 11 channels to the PBX/fax server and keep one verizon line for my alarm system and outgoing faxing. That simplifies everything substantially.

PRI as you state, is more a signalling protocol than anything special. Its a T1 with one timeslot taken over for the signalling protocol.

But, what you can DO with a PRI is much more than you can do with a regular voice (DSS) T1. In addition, there's relatively few PRI standards (ie. typically, a voice PRI in north America would all be NI2 and thats it, you're done). OOTH, T1 has a wide variety of signalling protocols, each of which offers slightly different features. (Double-Wink with battery reversal?)

One of the biggest drawbacks of getting DSS T1 voice circuits for dealing with phone systems, is that most Telcos offer DID trunks on T1, but they can only be used incoming. Such that you start carving up your T1 so that you devote say 15 channels of DID incoming trunks, 3 channels of incoming special numbers, and 6 any purpose lines.

With PRI, you use all 23 channels any way you want. DID, in/out, special #s, etc. You don't have to juggle around number of channels devoted to DIDs, etc. It just all works whatever way.

I think this is the main reason people get PRIs now-a-days. Plus you get additional features, like CLID delivery that works all the time, setting outbound CLID (although some Telcos do filter outbound CLID), ISDN data if you need to do that sort of thing, etc. etc.

Thanks, BRI is out of the picture. I just got this email from the tech

Proposing an Adtran 600R which takes a T1 from the Provider (BayRing) and will hand off a 384Kbps Ethernet connection as well as a DSX-1 (T1) connection to the Phone system (Asterix). The initial configuration will be an 11 channel T1. It will be setup as B8ZS/ESF (standard). It will be configured for robbed bit signaling and wink/wink.....I'll need to know what #'s you want to point to the T1 and how many digits you are expecting to receive. You will have the capacity to add an additional 7 channels if you need to.

PBX trunks served via a T1 line will support two way trunking, just as with ISDN-PRI trunks. As was stated earlier, its what one can do with a PRI that distinguishes it from palin old DS1 trunking interfaces, such a Verizon's Felx-Path DID/DOD T1 service.

With a ISDN-PRI, you get at a minimum, twenty-three two way trunks that can be configured to get picked as one ways, based on how the PBX, and the Telco have selected from where to start picking trunks.

Caller ID from the core network is passed over the PRI D channel towards the PBX for display on a PBX extension is so equipped. Standard DID/DOD digital trunks served via a T1 interfaces do not support digital data connections (56 or 64KB/s), and do not support Caller ID.

ISDN-PRI's can originate and terminate 56 and 64KB/s digital data calls that can originate from an ISDN-BRI or Switched 56KB/s location. Additionally, an ISDN-PRI's supports digital channel connection at

384KB/s (Known as H channels). Essentially a dial Fractional DS1.

There is allot more in terms of capabilities between a standard T1 carrying DID/DOD trunks, as opposed to an ISDN-PRI. National 2 is one of many PRI D channel Q931 protocols that can be used on the public network.

Consult Telcordia TR-TSY-000754, SR-3875 & SR-4994 for requirements information regarding ISDN-PRI operation & features.

Bill

Doug McIntyre wrote in news:45745b0a$0$41771$ snipped-for-privacy@auth.newsreader.octanews.com:

well, 80% of that just went over my head :). thanks for the very thorough response though!

You say two different things in the same post.

>

: > : Even with a big enough pipe you would need QOS. : >

: > QOS only applies to packets that are queued because the outbound : > link is curretly in use. If there are no queued packets, the : > QOS rules don't make any difference. If the pipe is big enough, QOS : > rules will never get a chance to be used. : >

: > With that said, we'll drop back to the real world, and re-iterate : > my ending statement (typos and all): : >

: > : > However, QOS *is* useful when you can't get a big enough bandwidth : > : > pipe -- whis is most of the time.

: You say two different things in the same post.

I said: If the pipe is big enough, then QOS is bunk. However, most pipes *aren't* big enough, so in the real-world QOS is useful.

If you got anything else out of my ramblings, I appologize.