Posted by jim dickson
About 20–25 years ago, AT & T began offering application programming interfaces (at least one) that allowed users to customize the functionality of Audix / auto attendant voice mail running on AT & T Unix platform 3BX (usually 3B10). This system cost thousands of dollars per channel and had very limited functionality. In an attempt to make their services more functional and attractive (especially for those who did not have an AT & T PBX or Central Office to connect to them Audix), several manufacturers issued a card that could be inserted into a computer, and which worked on MS-DOS and only with one POTS line (only the beginning of the FXO cycle). These cards were of rather poor quality relative to today's standards (not to mention the terrifying environment in which they worked) and still cost from $ 1,000 apiece. Most of these cards gave really poor sound quality and were extremely unreliable as personal autoresponders.
Around 1985, several companies produced pretty decent 4-port cards that cost about $ 1,000 apiece (the price dropped to $ 250 per port!). They were MUCH more reliable in operation compared to their single-port predecessors, and provided fairly decent sound quality. In fact, it was possible to insert 6 or 8 cards into a fast 286 computer and thereby receive 32 ports. So began the age of practical computer telephony. I have actively worked as a consultant in the field of computer telephony since its inception. I very quickly began to understand the issues of system design, software and hardware. It was easy, because I have had many years of experience in the field of traditional non-computer telephony.
')
My clients (who used the systems I developed on a VERY large scale) spent millions of dollars every year (only one of my clients would spend over 1 million a year, not counting a few others who were close to such a sum) for high-density computer hardware. telephony. My heart was breaking when I saw how these people spend $ 5,000 or $ 10,000 on a fee, for the manufacture of which some manufacturers spend only a few hundred dollars. And what's more, software and drivers never worked 100% right. I think one of the reasons why I had a lot of work in this area was that I knew all the weak points of such systems and knew how to get around them (or not to bypass them). In any case, the cards could not be cheap, because they had to have significant performance (not just the usual functions were needed, the DSP functionality was needed), because The computers to which these cards were connected were weak at the time.
At that time I already knew that sometime in the “beautiful” future, all computers would have the necessary power, which would make the peripheral devices necessary for connecting to communication interfaces VERY cheap and even ordinary. Therefore, I always watched the gradual increase in the performance of “faster than ever” processors, and in the era of 486-66DX2, it seemed that progress was in full swing, and technology was developing exponentially. I knew, especially after the appearance of Pentium processors, that the moment of internalization of computer telephony was approaching, so I began to follow the process even more closely.
I felt that if I was waiting for this, there were others who also thought about doing something. I watched, watched and waited, and when the PentiumIII-1000 (100 MHz) appeared, I finally said: “Damn, these processors will EXACTLY cope with this task”. But to my horror, nobody did anything. I did not realize that my vision was 100% correct, and I didn’t know what exactly * I * would be the first to use it.
To confirm the original idea, I got an old ISDN Express Development Mitel MB89000C card (an ISA card that could be used with their communication hardware), which had a pair of T-1 interfaces and a cross-matrix (timeslot-switch). This gave me physical access from the computer’s ISA-bus to the T-1 timeslot data (although inefficient, because it was 8-bit I / O, and the TSI chip required MANY wait cycles for access).
I wrote a driver for a Kluge card (I had to make a couple of modules for it) for FreeBSD (I chose this OS then) and decided that I could get 6 reliable I / O channels from the card. But, more importantly, the 6 channels of user space processing (moving using the clipboard, decoding the frequency division tone dialing, etc.) did not spend much of the processor time, proving that my 600 MHz PIII could possibly handle 50-75 ports if the I / O bus does not require too much power. Having achieved the desired result (I called this driver 'mie'), I went and bought everything I needed to install a new ISA card, with the result that I achieved efficient use (as it turned out) of the ISA bus in 16-bit mode without clock cycles waiting I managed to translate 2 full T-1 slots (48 channels) of data on the bus, and the computer coped with this task without problems.
So I made ISA-cards and put them on sale (I sold about 50 pieces) and put all the information (including files with graphs) on the network for public use. Since this concept was so revolutionary and was intended to create a sensation in my field, I decided to use the Mexican revolutionary motive and called the technology and organization in honor of the famous Mexican revolutionary Emiliano Zapata. I decided to call the card “tormenta”, which in Spanish means “storm”, or rather “BIG storm” like a hurricane.
This is how the story of Zapata Telephony began.
I wrote a complete driver for the Tormenta ISA card for * BSD and put it on the network. In response, I received, with a few exceptions, “yes, this is great for BSD, but what to do with Linux?”
Personally, I have never even seen Linux at work before. But I decided to give it a try, went to the local store (Fry's in Woodland Hills) and bought a copy of RedHat Linux 6.0 (I think version 7.0 ONLY came out and not yet on sale). I downloaded it into a computer (with all the development data, including nuclear sources). I was picking on the source code of the drivers until I found a VERY simple driver that contained all the basics, entry points, interfaces, etc. (I mainly used the Video Spigot driver), and used it to figure out how to format (so that at least it just worked) the simplest driver for Linux. So, I redid the BSD driver for Linux (in fact, it wasn't * that * difficult, because the basic concepts are almost the same). It did not support loadable nuclear modules (hell, what is it? In BSD 3.X, you had to recompile the kernel to change the configuration. The last system I used with the loadable drivers was VAX / VMS.), But it still worked (after you recompile the kernel already with it). Since my whole experience with Linux was about installing and writing a nuclear module, I * knew * that it * should * be wrong, wrong, wrong, bad, intolerable, little things, mistakes and all sorts of things that even fun penguin hair stand on end.
With these thoughts, I put it on the network, already knowing that some expert on the Linux yard would come, laugh at me, then cheat and laugh again, then feel sorry for me and offer to reformat it under "correct Linux". Within 48 hours of posting the driver online, I received a letter from one dude from Alabama (Mark Spencer) who suggested this. He didn’t just say it, he had something that would be perfect for this whole thing (Asterisk). At that time, Asterisk was a functional concept, but it had no real chance of becoming something really useful, because at that time, he did not have the opportunity to work directly (or at least not directly, because at that time there was not very much, if any, accessible VOIP equipment) with any hardware communications (telephones, lines and etc.). Its merging with the concept of Zapata Telephony and the development of equipment / driver / library and interface allowed it to become a real PBX that could work with real phones, lines, etc.
In addition, Mark did not have a particularly accurate understanding of VOIP, the network, the internal structure of the system, etc., and at the very beginning of all this he was just very interested in telephones and telephony. But he had a rather limited experience in the field of telephone systems, how they function, and especially in the field of hardware communication interfaces. From the very beginning, I helped him in these matters, providing information and introducing code into drivers and PBXs for various necessary purposes. We, and more recently others, have created a good team (heh, I constantly ask him about the cores, VOIP and other purely Linux pieces), working to achieve a common goal - to introduce the latest developments in communication technology for general use at real and affordable prices.
Since the ISA card, I have developed the Tormenta 2 PCI Quad T1 / E1 card, which Mark put on the market as the Digium T400P and E400P, and now Varion sells it as V400P (T1 and E1). All project files (including files with graphs) are available on Zapatatelephony.org for general use.
Now we are developing new projects with higher density.
As you can see now, with the purposeful work of Mark (and a lot of My work and the work of other people) with the Zaptel drivers and with Asterisk software, the technologies have come a long, long way and continue to evolve and improve with each passing day.
Note:Has anyone ever wondered what HUGE responsibility Mark took upon himself while taking on this project? Have you ever thought about how much he had to do and how much remains to be! Therefore, I believe that I worked with him on this project longer than anyone else, including some of his employees, and believe me, I saw at least some things that he had to go through to finish it all. Personally, I would * NEVER * undertake such a task, knowing what level of responsibility this implies. Yes, what I was doing is also not an easy task and implies a rather high level of responsibility, but I did what I was sure of. Mark’s contribution is much more than mine, and I can only say that I know what he should do, what he does, and I really appreciate the time and dedication that he has invested in all the incredible things he has done.
In addition, I would like to thank everyone who took part in this project, and everyone who somehow helped us in its implementation. Thank you for believing in this project and believing in us.
Original article on the site (ENG):
app-rpt.qrvc.com/node/136