Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
$275 dual T1 card

By h2odragon in MLP
Thu Nov 30, 2000 at 03:05:20 AM EST
Tags: Hardware (all tags)
Hardware

BSD Telephony of Mexico has placed in the public domain a design for an ISA card which interfaces two T1 lines (48 phone lines) to a (fairly beefy) PC running FreeBSD. They have hardware and software available now.


According to their status page, the system can start and answer calls, decode DTMF, do fully bi-directional audio, conferencing, and caller ID. The hardware is as minimal as possible, everything that can be done by the host processor is; which leads to the P3-733 system CPU requirement.

Found this at LinuxTelephony.org; it's beyond my pay grade but definitely worth passing around.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Computers and telephones
o don't mix 11%
o are being kept from convergance by greedy telcos 35%
o will merge soon 11%
o are tools of Evil 40%

Votes: 42
Results | Other Polls

Related Links
o BSD Telephony of Mexico
o status page
o LinuxTelep hony.org
o Also by h2odragon


Display: Sort:
$275 dual T1 card | 17 comments (16 topical, 1 editorial, 0 hidden)
This smells like a hoax (1.75 / 4) (#1)
by gblues on Thu Nov 30, 2000 at 12:43:05 AM EST

According to their status page, the system can start and answer calls, decode DTMF, do fully bi-directional audio, conferencing, and caller ID.

Wow, all this over an 8mhz bus? So lemme get this straight, it can interface with 2 T1 lines (100+Mbit/sec each) over a system bus that can't even max out a 10baseT (10Mbit/sec) ethernet link? Uh huh, suuuuuuuuure.

If it were really all that minimalist, you'd think they would at least put it on a PCI card, to make the device<->CPU communication more efficient.


... although in retrospect, having sex to the news was probably doomed to fail from the get-go. --squinky
not quite (4.00 / 4) (#2)
by h2odragon on Thu Nov 30, 2000 at 01:07:37 AM EST

T1 is (24 * 64Kbit) = 1.536 Mbit/sec; ISA bus is (theoretically) 8 or 16 MByte/sec for 8 bit or 16 bit respectively; you'll find varying numbers depending on how folks count mega. ISA doesn't ever perform to theory, but there's enough bandwidth there for this. I imagine they chose to go with ISA rather than PCI because this is a small project and the parts needed to interface to ISA are considerably easier to get and work with; cheaper and better documented.

[ Parent ]
Apples and Oranges... (3.75 / 4) (#5)
by Miniluv on Thu Nov 30, 2000 at 02:03:00 AM EST

First of all, DATA on a T1 runs at ~1.5Mbps, not voice traffic. When you consider voice traffic, you do not plan on the card being used to full capacity. You have, with an E&M T1, 24 channels of voice with in-band signalling on bits 7 and 8. With the signalling bits you only need to watch for a change, not process the data until then as with a voice app you're only watching for sig-bits to rise or fall indicating a call beginning or ending. You have 1 less channel on an ISDN PRI so there's still less bandwidth to be dealt with. If you figure your capacity at 75 percent of the card across the two T's you have 36 channels of voice/signalling to worry about on E&M which isn't quite as bad. Those 36 channels will, not counting sigbits, deliver 6 bits of analog voice data to the card at 11Khz per channel. That's 2,376,000 bits of data per second to be converted to digital samples and processed in whatever way you need. Since the ISA bus is, as you stated, 8mhz, I'm not seeing a problem. Even if the additional 12 channels were sending data you'd still only be attempting to pass 3,168,000 bits per second.
FWIW, I am not a telecom guru, just happen to work at a services provider using Dialogic cards to do the same thing. I have yet to see a NON ISA T1 card on the market, and we've looked.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]
check your numbers? (3.00 / 1) (#11)
by tzanger on Thu Nov 30, 2000 at 09:11:35 PM EST

First of all, DATA on a T1 runs at ~1.5Mbps, not voice traffic. When you consider voice traffic, you do not plan on the card being used to full capacity. You have, with an E&M T1, 24 channels of voice with in-band signalling on bits 7 and 8.

IANATG (telecom geek) but I do know that T1s are partitioned differently than you say:

  • 8 bit samples * 24 channels + 1 frame bit = 193 bits / frame * 8000 frames/sec - 1.544Mbps raw throughput
  • Frame bit can't be used for data[1]: 192 bits * 8000 frames/sec = 1.536Mbps, how fast a pure data T1 can be
  • ESF (the most common framing which gives 4 bits of in-band signalling for each timeslot) robs the LSB on the 6th, 12th, 18th and 24th frame, leaving you with 7 bits of data for each channel 1/6 of the time (4/24 frames)
  • Since the home equipment can't tell which timeslot they're in and which frame of the ESF they're in, they can't guarantee that they will be encoded into 8 bits (a robbed bit frame could come along and give less resolution for that time period) so they make do assuming 7 bit resolution @ 8kHz sampling: 7*8000 is 56k and lo and behold, this is where that theoretical maximum signalling rate comes from[2].
[1] frame bits are often used by the telco to communicate with the remote CSU/DSU without disturbing the data transport since the modern CSU/DSUs are capable of maintaining sync without a forced high 193rd bit. [2] or so I've heard. Makes sense to me but I would have thought that you could assume 8 bit resolution and work only slightly degraded. I mean 83% of the time you're twice as accurate as you think you should be. As I said, IANATG. ANYWAY (getting offtopic fast, heh) -- the T1 cards still need to sample at 8kHz and at 8 bit resolution regardless of what you're throwing down the line so their actual ISA bandwidth demands are easy to calculate. I don't think T1/E1 cards are all that difficult to manufacture anymore. I mean hell, Dallas Semi is just one manufacturer out of a handful who make completely data recovery circuits on one chip. For 8 T1s. :-)



[ Parent ]
My numbers... (4.00 / 1) (#12)
by Miniluv on Thu Nov 30, 2000 at 10:35:47 PM EST

Yeah, I was sorta simplifying what voice traffic is compared to data. Considering a T1 carrying voice in terms of 1.53Mbps is really rather absurd, except sorta when yer talking about what bus to toss it onto.
Voice data on a T1 is sampled at 11Khz, though, not 8 to try and maintain some level of quality signal. The signalling depends on the provisioning of the T1, ESF and such aside, because E&M and ISDN handle it 100% differently. E&M uses A&B bits which are the low order bits of each frame for individual channel signalling. ISDN uses the D channel to convey this information for the other 23 channels, on a PRI or the other 2<?> on a BRI. The card in question in this story doesn't do ISDN so that's why I focused on E&M.
I think at this point I have an insatiable hunger to find out the exact answer, and I work with several really good telecom geeks, so this coming Monday I'll ask one of them and point to this story and find out how badly mistaken I was.
I will say though, if you add the two sigbits into my numbers which you have to do, the ISA bus is still fast enough. I know this from experience, as we run 8 T1's, 4 E&M 4 ISDN on a single ISA bus and have no problems. I don't think our boxes have ever run 100% capacity, but they've gone over the 75% capacity I argued in my earlier post.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]
Telecom rules... (none / 0) (#13)
by tzanger on Fri Dec 01, 2000 at 12:12:05 PM EST

Voice data on a T1 is sampled at 11Khz, though, not 8 to try and maintain some level of quality signal.

11kHz? Is it oversampled then and then spit out at 8kHz?

E&M uses A&B bits which are the low order bits of each frame for individual channel signalling. ISDN uses the D channel to convey this information for the other 23 channels, on a PRI or the other 2<?> on a BRI.

ESF robbs bits for all timeslots every 6th frame, not every frame. That gives you A, B, C and D bits but IIRC the C and D bits are "for future use" and are often (but not necessarily) just copies of the A and B bits. ISDN BRI gets 64k because, as you already pointed out, there is not robbed bit signalling going on and the D channel is used to cover the signalling on the associated B channels. I don't recall what the actual numbers are but I believe you're correct: 23 channels on ISDN PRI and 2 on ISDN BRI.

I think at this point I have an insatiable hunger to find out the exact answer, and I work with several really good telecom geeks, so this coming Monday I'll ask one of them and point to this story and find out how badly mistaken I was.

Me too. (not how mistaken you (and I) possibly are, but rather what the CORRECT answers are. :-)

I will say though, if you add the two sigbits into my numbers which you have to do, the ISA bus is still fast enough. I know this from experience, as we run 8 T1's, 4 E&M 4 ISDN on a single ISA bus and have no problems. I don't think our boxes have ever run 100% capacity, but they've gone over the 75% capacity I argued in my earlier post.

I was arguing in favour of there being enough bandwidth on the ISA bus. I guess we're both on the same side here. :-)

I've always been keen on telecom. When I actually found out how T1/DS1, DS3s and DS4s worked it kinda took the magic out of it all though. Actually I'm more interested in the communication between the DSU/CSUs than the actual data being transferred. :-)

You being more a telecom geek than I, perhaps you can answer this for me: Why on earth do I need two DSU/CSUs at my end? Bell Canada has their own but has a second DSX-11 port on it which I have to plug into my own DSU/CSU which finally has the desired serial port to attach to the router. I understand why Bell would want their own DSU/CSU (diagnostics, they can control the quality of the equipment actually screaming on the wires, etc.) but why not just give a sync. serial port out the end instead of another T1 port? It seems a waste to go 80km to a DSU/CSU only to go another 5 feet to ANOTHER DSU/CSU to give me a serial port.



[ Parent ]
Moi? A telecom geek? (none / 0) (#14)
by Miniluv on Fri Dec 01, 2000 at 10:13:44 PM EST

*snicker* Uhm, on your question of the two CSU/DSU's I cannot answer...I can definitely see why they want their own at both ends, for the reasons you stated, but I cannot imagine why they cannot use one of their own to provide you with the necessary link up.
As to the ESF thing, I think that the ESF framing is the amalgamation of all 24 channels on an E&M line, as opposed to the continual signalling on every frame of each individual channel. That's my remembrance of my training, but it's been a few months and I rarely, if ever, have to actually use this knowledge.
I'm 100% positive on 23 channels of data and one of signalling on ISDN PRI though, and almost positive on IDSN BRI, it stands to reason as a "residential" ISDN is BRI and provides 128K data bandwidth.
Telecom is only mildly interesting to me, as most of what I enjoy happens at either end of things, and the really cool telecom technologies (for me) are either at the backbone level with color-routed fiber which is becoming popular for high speed switching at long-haul hubs, or in older technology like ATM that people are mysteriously moving away from.
I'll prolly write a diary entry with what I find out from the telecom guys, though I will also try to update this thread in case people have actually been reading our dialogue back and forth.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]
Here's what I found out... (none / 0) (#15)
by Miniluv on Mon Dec 04, 2000 at 06:01:57 PM EST

Not sure how well this answers what we were wanting to find out, but here goes:

ESF signalling is ISDN only. It stands for Extended Signal Frame.
A T1 regardless of format, E&M/ISDN, or whether it carries voice or pure data is 1.536 Mbps useable data plus signalling overhead.
I was wrong on the 11khz it would seem, since a T1 channel transmits 8192 frames/second. Thus, 8khz no?
In conclusion, it would seem the ISA bus'll work just fine, especially considering the maximum usage thing, in that you don't plan or design based on peak usage being the norm. And of course, speaking from experience with 8 full T1's on a single ISA bus, it works.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]

Cool (none / 0) (#16)
by tzanger on Tue Dec 05, 2000 at 01:01:03 PM EST

Thanks for posting your findings!

ESF signalling is ISDN only. It stands for Extended Signal Frame. A T1 regardless of format, E&M/ISDN, or whether it carries voice or pure data is 1.536 Mbps useable data plus signalling overhead.

I wasn't aware that ESF was ISDN only. I wonder why this is, as I was certain that ISDN did NOT bit-rob the in-band data and had a peak data rate of 1.472Mbps (1 channel reserved for signalling). We have a long-haul T1 from Waterloo, ON to our shop and it's B8ZS/ESF but NOT ISDN PRI.

Interestingly enough, I learned ESF as Extended Super Frame. Signal Frame sounds better technically and also helps to explain what is going on (extra signalling bits). I always got a kick out of calling them SupaFrames and Extended SupaFrames. :-)

I was wrong on the 11khz it would seem, since a T1 channel transmits 8192 frames/second. Thus, 8khz no?

Nope, 8000 not 8192. 8 bits/channel * 24 channels * 8000 times a second = 1536000bps which is the data rate of a full DS1/T1. now (8 bits/channel * 24 channels + 1 frame bit) * 8000 frames/sec is 1544000bps which is the total throughput of a DS1/T1. 8192 frames/sec would be 1.581056Mbps.

In conclusion, it would seem the ISA bus'll work just fine, especially considering the maximum usage thing, in that you don't plan or design based on peak usage being the norm.

How do you get away with this on a hardware design? If you don't design it around a bus that can't handle full load, it won't handle full load. I mean ISA will handle full load, I'm just curious about your statement.

Once again, thanks for posting your findings. I love telcom stuff. :-)



[ Parent ]
Designs... (2.00 / 1) (#17)
by Miniluv on Tue Dec 05, 2000 at 03:50:34 PM EST

I'm fumbling around a rather nebulous point with poor wording is what I'm doing. The thing is, ISA will in fact handle 100% capacity, and while you plan for that you also don't plan for it.
Part of it is the odd definition of capacity in the telecom industry in that it's not what'll the equipment do at any given second running full-bore, but rather what'll it handle over a given time period, and usually in terms of paying customers instead of simultaneous users. There are also sorts of odd calculations the planning people do to figure out the limitations of the hardware, software, etc and how that impacts the potential customer base.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]
T1 Cards... (3.33 / 3) (#4)
by Miniluv on Thu Nov 30, 2000 at 01:42:01 AM EST

First off, I'm glad to see people pursuing telephony on BSD, as it's truly an up and coming technology. A cursory examination of their page shows no evidence of whether this'll handle E&M as well as ISDN, or just one or the other, which is bad.
The one problem I have with this design is the minimalism of the board, and thus the heightened requirements of the host. It'll work fine if 48 channels is all you really need, but how about when you want three or four of these cards in a box also running an app to do something with the voice data?

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
one card per box (4.00 / 1) (#6)
by h2odragon on Thu Nov 30, 2000 at 03:00:48 AM EST

They mention that a single card saturates the ISA bus, so multiples aren't an option. I can well beleive it. I expect they're being conservative about the CPU requirements, seems to me that a modern system is going to have plenty of spare time while waiting for the data to trickle in.

If you need more than 48 channels, do you care how much it costs? Or, put another way, if you do need more capacity you can afford to buy RealStuff(TM). I just want to put together a PBX / conferencing / experiment system; and have never been able to afford to dream about the real stuff even though some of it is now useable under my OS of choice. I've heard several stories of "PBX on a (PCI|ISA|SBUS) card" over the past few years and even seen some small scale prototype hardware (mulitchannel ISDN / POTS cards), but it seems they never come to market.

I submitted this story partially hoping that the rest of k5 would offer some more background for this; ie; is there a way to split some of these channels out into something resembling POTS lines for my PBX idea, if no is there another card that could do it, etc. ISTR that most telco switches have been built on Unixes for years, now that "home unix" is a reality why aren't there home switches?

[ Parent ]

Alternatives... (none / 0) (#7)
by Miniluv on Thu Nov 30, 2000 at 03:17:24 AM EST

At an old employer we used what was termed a VINA, or voice integrated network appliance, which essentially took a channelized T1 (E&M) and split 20 channels out for voice and left four for data. That sounds more like what you're looking for, and I don't know that this card is really the solution you want to accomplish that goal with.
As for criticizing it for the shortcomings I pointed out, BSD unixes tend to be left behind when it comes to telephony applications. The only platform I know of that everybody supports for their hardware is SCO of all things. Solaris is gaining ground, as is AIX, but these days for ultimate flexibility you still need to use SCO.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]
UTSL (3.00 / 1) (#8)
by h2odragon on Thu Nov 30, 2000 at 03:32:49 AM EST

I've been reading through some of the driver / app package; it says there under "Signalling Configuration":

0 - No signalling (passive device, such as audio-only, etc)
1 - E & M signalling
2 - FXS loopstart signalling
3 - FXS groundstart signalling
0x100 - Device is a pseudo-channel and has no physical T-1 channel asociated with it.

Which I assume means no ISDN.

I've got a lot to learn before I go buying hardware, that's sure.

SCO still exists? I recall there were hopes for Linux to become the "telco OS" wehn caldera bought SCO; but all I know of the telecom world makes me think them folks would be happier if everything even remotely connected to their market was proprietary, private, and hellishly expensive. Don't let me start ranting about the telephone business, it'll get ugly...

[ Parent ]

Telco's vs. Telephony SP's (4.00 / 1) (#9)
by Miniluv on Thu Nov 30, 2000 at 04:35:11 AM EST

Sadly, SCO still exists. Part of the reason, as I understand it, is the nature of the business. People who code telecom apps tend to be a group resistent to change, and thus since SCO has been used for so long, it still is. When SCO was younger it wasn't bad for UNIX, in fact it had some pretty kick ass advantages. What they are I've never been able to pin down with any great accuracy, though I do know it's scheduler was rock solid, which was rare back then.
As far as linux goes...*pauses for laughter*..it's not ready. Caldera is certainly not the company to turn the kernel into a telecom ready OS core. The problem we had was the scheduler, as well as the hardware interface. The other problem is one perenially bitched about, in that the linux kernel refuses to scale to the levels necessary. The performance hit taken when running on massive boxes, ie 4 or 8 way smp with multiple GB of ram, is just hellish. The BSD's are better, ie Open/Free/Net, but still not quite there yet either. Solaris, Irix, AIX, HP-UX are all built to scale to that level with the compromise of not running at the same low hardware requirements that linux will. I myself tend to side with the "proprietary" vendors on this issue to some extent. I've been praying for a linux kernel fork since the S/390 port came out.
The Telco's as a group are pretty lame, they hate sharing info, they love their ILEC monopolies, they suck at customer service. QWest is one of the worst companies I've ever had the pleasure of working with, followed closely by AT&T(voice AND data).
BTW, on a side note, E&M should die. *grin* It's a shitty signalling protocol compared to ISDN PRI/BRI. If you're looking at hardware, you might want to investigate Dialogic's 240 series T1 interfaces. It'll do ISDN or E&M, they provide pretty good API documentation, the hardware is fairly stable, and it's got onboard processing to lighten the load on your overall hardware requirements. My company runs these with 8 in/out bound T1s of both E&M and ISDN PRI signalling, along with a whole schwackload of other things on relatively, emphasis on relatively, modest hardware. I know the cards are sort of expensive, but you are buying a fair degree of quality. Do bear in mind they are firmware based, but in reality that firmware will dwell on your harddrive and be loaded at OS boot, delaying your OS boot by a fair bit of time. The advantage is, if the field interests you there're a goodly number of companies out there using this hardware in production environments so you'd have relevant experience.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]
extreme reliablity (3.00 / 2) (#10)
by h2odragon on Thu Nov 30, 2000 at 08:32:16 AM EST

I think you've kinda put your finger on it, or near it: telephone companies and telco providers are fixated on like 6 9's uptimes and super scalability etc; all well and good. Sometimes you need that.

Sometimes you don't, and the "not perfect but good enough for small apps" market is not only not served, but seems to be activley quashed by the bigs.

Linux scaling is improving, the network stack rewrite in 2.4 as well as some of the other tricks should help a lot. No, it's not to solaris etc. levels yet, but it's good enough for many jobs; and the latency problems appear to be more easily fixed than had been thought. There's an article somewhere recently talking about consistient sub 4msec latencies with simple patches.

On phone companies, you must not have had the pleasure of working with bellsouth. Four years I called their "data services department" every couple months to ask if I could get a T1 to my admittedly remote location. Never got the same office, much less the same people, did always get "What's a T1?" A couple years ago they learned what a T1 was, now they're only insisting that they'll have to charge me for ~200 miles of "mileage fee", monthly, since I'm 15 miles from the switch and their standard DSL boxes won't work. The techs are good folks but engineering and marketing are, well, I won't even start. "Stuffed", but to black hole levels.

[ Parent ]

$275 dual T1 card | 17 comments (16 topical, 1 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!