May 12, 2010 at 10:56 History of the appearance and development of open telephony
Posted by: Jim Dixon
About 20-25 years ago, AT&T began offering application programming interfaces (at least one) that allowed users to customize the performance of their Audix voice mail / automatic secretary running on the Unix AT&T 3BX platform (typically 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 AT&T PBX or Central Office for connecting Audix to them), several manufacturers released 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 $ 1000 apiece. Most of these cards produced really poor sound quality and were extremely unreliable as personal answering machines.
Around 1985, several companies issued fairly decent 4-port cards, which 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. Thus began the age of practical computer telephony. I have been actively working as a consultant in the field of computer telephony since its inception. I quickly began to understand the issues of system design, software and hardware. It was not difficult because I 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 each year (only one of my clients would spend over 1 million a year, not counting the few others that were close to that amount) on high-density hardware for computer telephony. My heart was breaking when I saw how these people spend $ 5,000 or $ 10,000 on a board that some manufacturers spend only a few hundred dollars on making. Moreover, software and drivers never worked 100% correctly. 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 get around). In any case, the cards could not be cheap, because they had to have significant performance (not just ordinary functions were required, DSP functionality was needed), because the computers to which these cards were connected were rather weak at the time.
I already knew then that someday in the “beautiful” future, all computers will have the necessary power, which will make the peripheral devices needed to connect to communication interfaces VERY cheap and even ordinary. Therefore, I always out of the corner of my eye followed the gradual increase in the performance of “fast as never before” processors, and in the era of 486-66DX2 it seemed that progress was in full swing, and technologies were developing exponentially. I knew, especially after the advent of Pentium processors, that the moment was approaching the internalization of computer telephony, so I began to monitor what was happening even more closely.
I felt that if I was expecting this, then there were others who thought as well and did something. I watched, watched and waited, and when the PentiumIII-1000 (100 MHz) appeared, I finally said: “Damn it, these processors will EXACTLY cope with this task.” But, to my horror, no one did anything. I did not realize that my vision was 100% correct, and I did not know that it was * I * who would be the first to use it.
To confirm the initial idea, I got an old Mitel MB89000C “ISDN Express Development” card (an ISA card that could be used with their communication hardware), which had a pair of T-1 interfaces and a cross matrix (time slot - switch). This provided me with physical access from the ISA-bus of the computer to the data of the T-1 time slots (although it was inefficient, because it was 8-bit I / O, and the TSI chip required MANY wait cycles for access).
I wrote a driver for a cloud card (I had to make a couple of modules for it) for FreeBSD (I selected this OS then) and decided that I could get 6 reliable I / O channels from the card. But, more importantly, 6 channels of user space processing (moving using the clipboard, decoding tone dialing with frequency separation, etc.) practically did not spend processor time, proving that my then 600 MHz PIII could possibly handle 50-75 ports if the I / O bus did not require too much power. Having achieved the desired result (I called this driver 'mie'), I went and bought everything that was needed to install a new ISA card, as a result of which I achieved efficient use (as it turned out) of the ISA bus in 16-bit mode without clock cycles expectations.
So I made ISA cards and put them up for sale (I sold about 50 pieces) and put all the information (including graph files) on the network for public use. Since this concept was so revolutionary and was designed to make a splash in my field, I decided to use the Mexican revolutionary motive and named the technology and organization in honor of the famous Mexican revolutionary Emiliano Zapata. I decided to name 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 completely wrote the 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 cool for BSD, but what about Linux?”
Personally, I had not even seen Linux work before. But I decided to give it a try, went to a local store (Fry's in Woodland Hills) and bought a copy of RedHat Linux 6.0 (I think version 7.0 is ONLY released and has not yet gone on sale). I downloaded it to a computer (with all development data, including nuclear sources). I poked around in the driver source code 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 understand how to format (so that it would at least just work) the simplest Linux driver. So, I redid the BSD driver for Linux (in fact, it was not * so * difficult, because the basic concepts are almost the same). It did not support loadable kernel modules (hell, what is it all about? In BSD 3.X, you had to recompile the kernel, to change the configuration. The last system with which I used loadable drivers was VAX / VMS.), But it worked anyway (after you recompile the kernel with it already). Since all my Linux experience came down to installing and writing a kernel module, I * knew * that * it * had to * be wrong, wrong, wrong, bad, unbearable, little things, mistakes and all sorts of things from which even fun penguin hair stand on end.
With such thoughts, I put it on the network, already knowing in advance that some expert on the Linux yard would come, ridicule me, then lap it up and ridicule again, then pity me and offer to reformat it under the "correct Linux". Within 48 hours after placing the driver on the network, I received a letter from one dude from Alabama (Mark Spencer), who suggested exactly that. He didn’t just say that, 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 wasn’t a lot, if any, of VOIP equipment available) with any communication hardware (telephones, lines and etc.).
In addition, Mark did not have a particularly accurate idea of VOIP, network operation, 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 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 by providing information and implementing code in drivers and PBXs for various necessary purposes. We, and more recently, others, have created a good team (heh, I constantly ask him about kernels, VOIP and other purely Linux things), working to achieve a common goal - to implement the latest developments in communication technology for general use at real and affordable prices.
Since the time of the ISA card, I developed the Tormenta 2 PCI Quad T1 / E1 card, which Mark launched on the market as Digium T400P and E400P, and now Varion sells it as V400P (T1 and E1). All project files (including graphics files) are available on the Zapatatelephony.org website for general use.
Now we are developing new projects with a higher density.
As you can see now, with Mark's purposeful work (and a lot of My work and the work of other people) on Zaptel drivers and with Asterisk software, technologies have come a long, long way and continue to develop and improve every day.
Note:
Has anyone ever thought about what a HUGE responsibility Mark took upon himself when he took up this project? Have you ever thought about how much he had to do and how much more remains to be done! Therefore, I believe that I worked with him on this project longer than anyone else, including some of his employees, and, believe me, I already saw at least some things that he had to go through to finish all this. Personally, I * NEVER * would undertake such a task, knowing what level of responsibility this implies. Yes, what I was doing was also a difficult task and implied a rather high level of responsibility, but I did what I was sure of. Mark’s contribution is much greater 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,
In addition, I would like to thank everyone who participated in this project, and everyone who helped us in its implementation somehow. Thank you for believing in this project and believing in us.
Original article on the website (ENG): app-rpt.qrvc.com/node/136
About 20-25 years ago, AT&T began offering application programming interfaces (at least one) that allowed users to customize the performance of their Audix voice mail / automatic secretary running on the Unix AT&T 3BX platform (typically 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 AT&T PBX or Central Office for connecting Audix to them), several manufacturers released 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 $ 1000 apiece. Most of these cards produced really poor sound quality and were extremely unreliable as personal answering machines.
Around 1985, several companies issued fairly decent 4-port cards, which 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. Thus began the age of practical computer telephony. I have been actively working as a consultant in the field of computer telephony since its inception. I quickly began to understand the issues of system design, software and hardware. It was not difficult because I 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 each year (only one of my clients would spend over 1 million a year, not counting the few others that were close to that amount) on high-density hardware for computer telephony. My heart was breaking when I saw how these people spend $ 5,000 or $ 10,000 on a board that some manufacturers spend only a few hundred dollars on making. Moreover, software and drivers never worked 100% correctly. 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 get around). In any case, the cards could not be cheap, because they had to have significant performance (not just ordinary functions were required, DSP functionality was needed), because the computers to which these cards were connected were rather weak at the time.
I already knew then that someday in the “beautiful” future, all computers will have the necessary power, which will make the peripheral devices needed to connect to communication interfaces VERY cheap and even ordinary. Therefore, I always out of the corner of my eye followed the gradual increase in the performance of “fast as never before” processors, and in the era of 486-66DX2 it seemed that progress was in full swing, and technologies were developing exponentially. I knew, especially after the advent of Pentium processors, that the moment was approaching the internalization of computer telephony, so I began to monitor what was happening even more closely.
I felt that if I was expecting this, then there were others who thought as well and did something. I watched, watched and waited, and when the PentiumIII-1000 (100 MHz) appeared, I finally said: “Damn it, these processors will EXACTLY cope with this task.” But, to my horror, no one did anything. I did not realize that my vision was 100% correct, and I did not know that it was * I * who would be the first to use it.
To confirm the initial idea, I got an old Mitel MB89000C “ISDN Express Development” card (an ISA card that could be used with their communication hardware), which had a pair of T-1 interfaces and a cross matrix (time slot - switch). This provided me with physical access from the ISA-bus of the computer to the data of the T-1 time slots (although it was inefficient, because it was 8-bit I / O, and the TSI chip required MANY wait cycles for access).
I wrote a driver for a cloud card (I had to make a couple of modules for it) for FreeBSD (I selected this OS then) and decided that I could get 6 reliable I / O channels from the card. But, more importantly, 6 channels of user space processing (moving using the clipboard, decoding tone dialing with frequency separation, etc.) practically did not spend processor time, proving that my then 600 MHz PIII could possibly handle 50-75 ports if the I / O bus did not require too much power. Having achieved the desired result (I called this driver 'mie'), I went and bought everything that was needed to install a new ISA card, as a result of which I achieved efficient use (as it turned out) of the ISA bus in 16-bit mode without clock cycles expectations.
So I made ISA cards and put them up for sale (I sold about 50 pieces) and put all the information (including graph files) on the network for public use. Since this concept was so revolutionary and was designed to make a splash in my field, I decided to use the Mexican revolutionary motive and named the technology and organization in honor of the famous Mexican revolutionary Emiliano Zapata. I decided to name 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 completely wrote the 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 cool for BSD, but what about Linux?”
Personally, I had not even seen Linux work before. But I decided to give it a try, went to a local store (Fry's in Woodland Hills) and bought a copy of RedHat Linux 6.0 (I think version 7.0 is ONLY released and has not yet gone on sale). I downloaded it to a computer (with all development data, including nuclear sources). I poked around in the driver source code 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 understand how to format (so that it would at least just work) the simplest Linux driver. So, I redid the BSD driver for Linux (in fact, it was not * so * difficult, because the basic concepts are almost the same). It did not support loadable kernel modules (hell, what is it all about? In BSD 3.X, you had to recompile the kernel, to change the configuration. The last system with which I used loadable drivers was VAX / VMS.), But it worked anyway (after you recompile the kernel with it already). Since all my Linux experience came down to installing and writing a kernel module, I * knew * that * it * had to * be wrong, wrong, wrong, bad, unbearable, little things, mistakes and all sorts of things from which even fun penguin hair stand on end.
With such thoughts, I put it on the network, already knowing in advance that some expert on the Linux yard would come, ridicule me, then lap it up and ridicule again, then pity me and offer to reformat it under the "correct Linux". Within 48 hours after placing the driver on the network, I received a letter from one dude from Alabama (Mark Spencer), who suggested exactly that. He didn’t just say that, 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 wasn’t a lot, if any, of VOIP equipment available) with any communication hardware (telephones, lines and etc.).
In addition, Mark did not have a particularly accurate idea of VOIP, network operation, 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 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 by providing information and implementing code in drivers and PBXs for various necessary purposes. We, and more recently, others, have created a good team (heh, I constantly ask him about kernels, VOIP and other purely Linux things), working to achieve a common goal - to implement the latest developments in communication technology for general use at real and affordable prices.
Since the time of the ISA card, I developed the Tormenta 2 PCI Quad T1 / E1 card, which Mark launched on the market as Digium T400P and E400P, and now Varion sells it as V400P (T1 and E1). All project files (including graphics files) are available on the Zapatatelephony.org website for general use.
Now we are developing new projects with a higher density.
As you can see now, with Mark's purposeful work (and a lot of My work and the work of other people) on Zaptel drivers and with Asterisk software, technologies have come a long, long way and continue to develop and improve every day.
Note:
Has anyone ever thought about what a HUGE responsibility Mark took upon himself when he took up this project? Have you ever thought about how much he had to do and how much more remains to be done! Therefore, I believe that I worked with him on this project longer than anyone else, including some of his employees, and, believe me, I already saw at least some things that he had to go through to finish all this. Personally, I * NEVER * would undertake such a task, knowing what level of responsibility this implies. Yes, what I was doing was also a difficult task and implied a rather high level of responsibility, but I did what I was sure of. Mark’s contribution is much greater 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,
In addition, I would like to thank everyone who participated in this project, and everyone who helped us in its implementation somehow. Thank you for believing in this project and believing in us.
Original article on the website (ENG): app-rpt.qrvc.com/node/136