David Sugar and I actually did a lot of the preliminary work to get the OpenSwitch cards working under Linux via Bayonne. The last time I checked the best support for the OpenSwitch cards was still Bayonne - in fact, ctserver's protocol is based on the Bayonne state machine. Although you have to write the telephony parts in Bayonne's scripting language ccScript, Bayonne actually supports Perl scripts for many other functions via a gateway mechanism (TGI).
Asterisk also supports Perl scripts via their own gateway protocol, AGI. Unlike Bayonne, you can control the telephony engine from AGI to do things like dial a number, transfer to voicemail, etc. I talked to Mark Spencer, the main Asterisk developer, a while back about merging AGI and TGI into a common gateway protocol since they're so similar, but I stopped doing work for the company behind Bayonne (Open Source Telecom) recently for various reasons and the project died in my email queue.
None of the free telephony solutions have good documentation, including Asterisk, and there's no incentive to make it good since all of the companies involved like support revenue. This isn't a problem with the open solutions specifically, but rather with the telephony industry in general. Usually the best thing to do is to pick a vendor based on your project's criteria and put up with the installation process, then threaten anyone who touches it with eternal damnation. Unfortunately, with the shift towards host processing and the associated microprocessor industry economics, it's more and more difficult to get support even 5 years after product introduction, so this tactic doesn't work as well as it used to for HSP based telephony systems (which includes basically all the open solutions). If you really need it to work, you're basically stuck paying AT&T or another large firm out the nose for an expensive, proprietary, hardware based solution.
I've been screwing around with mprotect() and friends lately to write a exploit delivery system that can't be read by memory inspection tools on the target machine. While checking to see if similar techniques are possible on Windows, I found that the default addresses for PE/i386 executables' stack and text sections are all below 0x00ffffff..text begins at 0x00400000, for example, and the stack is located below it.
So it looks like Microsoft beat Ingo to it:) I was wondering for the longest time why they chose those mappings by default until I saw this article today.
Hi - www.doxpara.com is temporarily pointed at shaitan.lightconsulting.com, a quad Xeon hosted at Via.net in Palo Alto. Please be nice to my server so I don't have to drive over there and fix it...
Not possible. Cable modems (according to Cisco, who quotes the DOCSIS spec) are not capable of demodulating the upstream frequencies, which are in a lower frequency band than the downstream frequencies (where upstream and downstream are from the cable modem's perspective). They're only capable of transmitting on the upstream frequencies. In order to look at what's on the upstream frequencies, it appears you need a uBR or cable-modem headend.
I've tried it, and it sorta works with Linux
on
Is Verizon Up to Speed?
·
· Score: 5, Informative
I stopped by a Verizon store on a whim and found out that the service can be obtained on a trial basis for 14 days, after which you can return the phone for a full refund. I already have Sprint PCS data service on my Motorola StarTAC 7867W and I didn't need the higher speeds, so I opted not to keep the service. Service is $30 for Express Network access (you can still get 14.4Kbps CDMA data without that fee), plus a monthly contract to get minutes which are shared between voice and data usage. The prorated amount for my 14 days of usage was:
Monthly plan access: $21.77 (14 days of the $45.00 / month plan for 400 anytime minutes)
Express network: $14.51 (not $30 because I only used it for 14 days)
411 charges (I called information a couple times): 3 times at $0.99 each = $2.97
Taxes: $1.71
Total: $41.48
They refunded my $150 for the phone and data cable upon return with no hassle.
There was only one phone that supported the service at the time, the Kyocera 2235. I noticed that the voice quality was superior to my StarTAC, especially in analog mode. Since I'm a communications specialist, the lack of codec delays in analog mode was immediately apparent and the sound quality seemed superior to CDMA digital mode.
The phone was about $75, and I had to pay an additional ~$70 for the data cable, which was a complete ripoff. The data cable package included the Windows driver CD, instructions, and the USB to phone cable itself. The phone didn't come with a belt clip (which I need when I'm in the field), but had indentations on both sides which makes me think that you could buy a clip that snaps onto the phone.
The windows installation worked fine on my Windows 2000 SP2 partition on my laptop.
The initial data transfers seemed to be modem speeds, but then I realized I was being limited by the network at the peer side. I connected to a site I knew was only a few hops away from the Verizon gateway, and wow, it was fast. It started pushing data at about 140Kb/s raw, in addition to the packet headers. I didn't do anything special to get good reception either - it was about 2 signal bars IIRC on the ground floor of a window office in an industrial park.
The phone had a real IP, so I did some latency tests using pings. That resulted in about 300-400ms of delay, similar to a dial-up modem, but far worse than the typical 40-50ms on a BRI ISDN link. I didn't play any games, so couldn't tell you what the interactive performace will be like. SSH responsiveness was similar to a 33.6 modem. Ping times were usually within one standard deviation, although it would occasionally glitch and drop a packet or give me a 3000ms return.
So I tried it under Linux, and found out that the cable wasn't supported. After taking the cable apart, I found out that it contained a Kawasaki KL105 USB to serial chip, which didn't even have a driver written for it. I contacted Kawasaki and got this document which contained the protocol for the chip. Turns out that the chip comes in several different flavors, some with custom firmware loads, all of which have different protocols. I wrote a preliminary Linux driver for the chip, but ran out of time before my 14 days were up. I think that the driver can do data transfers, but the control line code is still kind of screwed up. Email me if you want a copy of the driver source.
The chip provides transfer speeds of up to 230Kbps, which is necessary to support the 153Kbps maximum speed of the network plus the packet overhead from the phone. The phone itself uses 11 pins of it's connector to talk to the chip in the cable. The PCB in the cable wart contains a power jack so you can charge the phone and use the cable at the same time, which is nice because the power connector from the AC adapter is mechanically incompatible with the data cable - you can't have both plugged into the bottom of the phone at the same time. The power lines account for 2 of the eleven pins, and I assume the other 9 are the standard 9 serial pins. Tracing the pins made me think that the UART outputs from the phone were electrically compatible with TIA-232, although I couldn't confirm it for sure.
When I returned the phone, I found that they now have DB-9 serial cables which don't require any special driver software - you just plug one end into the phone and the other end into the computer. Note that this will limit your speed to 100Kbps, because most serial ports have a line rate of 115Kbps, but you have the protocol overhead which will limit you to 100 Kbps given a standard packet size histogram for someone browsing the web. Those cables are still overpriced, so I'd recommend looking on eBay or contacting your local plastic injection firm and asking them if they're interested in a little side business:)
So I have this quad Xeon running FreeBSD sitting on an OC-3 that's 2 hops away from PAIX... Thought I'd throw what I can up there as I download the different versions. You can get to it here.
There's a company in my area named "JB Data" which has a ton of used UNIX workstation stuff. They also have a lot of laptops, especially the old gray Toshiba ones. I've used laptops as routers, file servers, APRS gateways and other stuff, and those old Toshiba units have been nothing but joy. I've used Sony and IBM equipment, but the Toshibas have been the most durable units I've worked with. My old 410CDT got dropped off of cars, ran over, set on fire (!), and it ran for several years with no problems.
Anyway, this JB Data guy has a big pile of them and PCMCIA ethernet cards to go with them, so I got a few and turned them into routers. They work great. They have a web site at http://www.unixsurplus.com/
Actually, this seems like a quite elegant solution to the FPGA re-configuring problem to me. The paragraph about how their Viva software determines many times a second whether each function would be best done in hardware or software, and reconfigures the FPGA appropriately, sounds rather elegant to me. I did some work with FPGA's once, and was limited to "booting" the processor from a PROM and executing silly little instructions; with this sucker, you could specify a metalanguage with ALL the possible tasks you could throw at the processor, and have the processor make its own instructions to execute whatever subset of the language that was needed to execute! Any additional power could be tossed in there by creating additional parallel instruction units to execute the most frequently executed instructions... the possibilities are mind-boggling.
Of course, there is a limit to how many things you can throw at the system at one time; The ridiculously high benchmark was for a 4-bit adder; of COURSE a bunch of special-purpose parallel chips that did nothing but 4-bit ADDs would be able to outperform a cray with the speed and power reductions mentioned. But I'm betting flipping the FPGA into a dynamic x86 emulation mode, with instruction parallalism, would slow the whole thing down to something more reasonable. Even still, it should outperform anything the x86 chipmakers currently manufacture. The graphics possibilities are what really grab me; the documents were mentioning that as well. Imagine a 3D accelerator that doesn't have a fixed instruction set! If the application was coded to use a particular instruction 80% of the time, Viva would adapt the FPGA grid to create massive numbers of parallel execution units for that instruction, and the speed would go through the roof.
I'm really happy about this; I wonder how the mainstream processor manufacturers are going to react once the possibility of this thing becoming mainstream technology shows up in the press.
Actually, one of my friends is an electrical engineer, and he was telling me about this nifty device that UPS wanted built to save them next Christmas...
Turns out that Dragon Systems had a bunch of their people port their voice recognition engine to the StrongARM-110 platform running VXworks, and UPS kept throwing money at the project until they were getting 4 or 5 nines (99.999%!) reliability. No more mobile keypads! The device was intended for use in the UPS regional distribution centers, where it's pretty noisy, but some guys on the project wrote all sorts of nifty audio filters to remove all the crap from the signal. Turns out that they can get extremely reliable voice input using a 30 cent electret headset mic:)
I've also seen similar technology used in the WildFire platform; they wrote their own ridiculously expensive audio filters for a really moby computer telephony agent called WildFire. I've gotten very reliable results yelling into my cell phone, in a bowling alley, on league night, during fleet week...
The problem is that all these solutions are too damn expensive (6, 7 digits) for the sort of work you're thinking about doing, unless you want to put together a Silicon Valley startup, heavily commercialize the idea, and partner with one of those companies.
I have utter faith in the human ability to act individually and as a group to make lives better. We've learned some pretty hard lessons since the Industrial Revolution, and we won't forget them any time soon.
Just because we have this ability (hackers especially!) to bring smiles to our friends and our family, doesn't mean that all of us choose to use it.
Until 1998, I had to be content with making sure my congresspeople were making the right decisions for me, and then I heard that Netscape was going open source. Now it's our turn, and we have control; we have that ability to make people look and say, "that's great! I can use that."
Go change someone's life today with what you can do:)
Slashdot Mirror
David Sugar and I actually did a lot of the preliminary work to get the OpenSwitch cards working under Linux via Bayonne. The last time I checked the best support for the OpenSwitch cards was still Bayonne - in fact, ctserver's protocol is based on the Bayonne state machine. Although you have to write the telephony parts in Bayonne's scripting language ccScript, Bayonne actually supports Perl scripts for many other functions via a gateway mechanism (TGI).
Asterisk also supports Perl scripts via their own gateway protocol, AGI. Unlike Bayonne, you can control the telephony engine from AGI to do things like dial a number, transfer to voicemail, etc. I talked to Mark Spencer, the main Asterisk developer, a while back about merging AGI and TGI into a common gateway protocol since they're so similar, but I stopped doing work for the company behind Bayonne (Open Source Telecom) recently for various reasons and the project died in my email queue.
None of the free telephony solutions have good documentation, including Asterisk, and there's no incentive to make it good since all of the companies involved like support revenue. This isn't a problem with the open solutions specifically, but rather with the telephony industry in general. Usually the best thing to do is to pick a vendor based on your project's criteria and put up with the installation process, then threaten anyone who touches it with eternal damnation. Unfortunately, with the shift towards host processing and the associated microprocessor industry economics, it's more and more difficult to get support even 5 years after product introduction, so this tactic doesn't work as well as it used to for HSP based telephony systems (which includes basically all the open solutions). If you really need it to work, you're basically stuck paying AT&T or another large firm out the nose for an expensive, proprietary, hardware based solution.
I've been screwing around with mprotect() and friends lately to write a exploit delivery system that can't be read by memory inspection tools on the target machine. While checking to see if similar techniques are possible on Windows, I found that the default addresses for PE/i386 executables' stack and text sections are all below 0x00ffffff. .text begins at 0x00400000, for example, and the stack is located below it.
:) I was wondering for the longest time why they chose those mappings by default until I saw this article today.
So it looks like Microsoft beat Ingo to it
Hi - www.doxpara.com is temporarily pointed at shaitan.lightconsulting.com, a quad Xeon hosted at Via.net in Palo Alto. Please be nice to my server so I don't have to drive over there and fix it...
Not possible. Cable modems (according to Cisco, who quotes the DOCSIS spec) are not capable of demodulating the upstream frequencies, which are in a lower frequency band than the downstream frequencies (where upstream and downstream are from the cable modem's perspective). They're only capable of transmitting on the upstream frequencies. In order to look at what's on the upstream frequencies, it appears you need a uBR or cable-modem headend.
I stopped by a Verizon store on a whim and found out that the service can be obtained on a trial basis for 14 days, after which you can return the phone for a full refund. I already have Sprint PCS data service on my Motorola StarTAC 7867W and I didn't need the higher speeds, so I opted not to keep the service. Service is $30 for Express Network access (you can still get 14.4Kbps CDMA data without that fee), plus a monthly contract to get minutes which are shared between voice and data usage. The prorated amount for my 14 days of usage was:
- Monthly plan access: $21.77 (14 days of the $45.00 / month plan for 400 anytime minutes)
- Express network: $14.51 (not $30 because I only used it for 14 days)
- 411 charges (I called information a couple times): 3 times at $0.99 each = $2.97
- Taxes: $1.71
- Total: $41.48
They refunded my $150 for the phone and data cable upon return with no hassle.There was only one phone that supported the service at the time, the Kyocera 2235. I noticed that the voice quality was superior to my StarTAC, especially in analog mode. Since I'm a communications specialist, the lack of codec delays in analog mode was immediately apparent and the sound quality seemed superior to CDMA digital mode.
The phone was about $75, and I had to pay an additional ~$70 for the data cable, which was a complete ripoff. The data cable package included the Windows driver CD, instructions, and the USB to phone cable itself. The phone didn't come with a belt clip (which I need when I'm in the field), but had indentations on both sides which makes me think that you could buy a clip that snaps onto the phone.
The windows installation worked fine on my Windows 2000 SP2 partition on my laptop. The initial data transfers seemed to be modem speeds, but then I realized I was being limited by the network at the peer side. I connected to a site I knew was only a few hops away from the Verizon gateway, and wow, it was fast. It started pushing data at about 140Kb/s raw, in addition to the packet headers. I didn't do anything special to get good reception either - it was about 2 signal bars IIRC on the ground floor of a window office in an industrial park.
The phone had a real IP, so I did some latency tests using pings. That resulted in about 300-400ms of delay, similar to a dial-up modem, but far worse than the typical 40-50ms on a BRI ISDN link. I didn't play any games, so couldn't tell you what the interactive performace will be like. SSH responsiveness was similar to a 33.6 modem. Ping times were usually within one standard deviation, although it would occasionally glitch and drop a packet or give me a 3000ms return.
So I tried it under Linux, and found out that the cable wasn't supported. After taking the cable apart, I found out that it contained a Kawasaki KL105 USB to serial chip, which didn't even have a driver written for it. I contacted Kawasaki and got this document which contained the protocol for the chip. Turns out that the chip comes in several different flavors, some with custom firmware loads, all of which have different protocols. I wrote a preliminary Linux driver for the chip, but ran out of time before my 14 days were up. I think that the driver can do data transfers, but the control line code is still kind of screwed up. Email me if you want a copy of the driver source.
The chip provides transfer speeds of up to 230Kbps, which is necessary to support the 153Kbps maximum speed of the network plus the packet overhead from the phone. The phone itself uses 11 pins of it's connector to talk to the chip in the cable. The PCB in the cable wart contains a power jack so you can charge the phone and use the cable at the same time, which is nice because the power connector from the AC adapter is mechanically incompatible with the data cable - you can't have both plugged into the bottom of the phone at the same time. The power lines account for 2 of the eleven pins, and I assume the other 9 are the standard 9 serial pins. Tracing the pins made me think that the UART outputs from the phone were electrically compatible with TIA-232, although I couldn't confirm it for sure.
When I returned the phone, I found that they now have DB-9 serial cables which don't require any special driver software - you just plug one end into the phone and the other end into the computer. Note that this will limit your speed to 100Kbps, because most serial ports have a line rate of 115Kbps, but you have the protocol overhead which will limit you to 100 Kbps given a standard packet size histogram for someone browsing the web. Those cables are still overpriced, so I'd recommend looking on eBay or contacting your local plastic injection firm and asking them if they're interested in a little side business :)
So I have this quad Xeon running FreeBSD sitting on an OC-3 that's 2 hops away from PAIX... Thought I'd throw what I can up there as I download the different versions. You can get to it here.
There's a company in my area named "JB Data" which has a ton of used UNIX workstation stuff. They also have a lot of laptops, especially the old gray Toshiba ones. I've used laptops as routers, file servers, APRS gateways and other stuff, and those old Toshiba units have been nothing but joy. I've used Sony and IBM equipment, but the Toshibas have been the most durable units I've worked with. My old 410CDT got dropped off of cars, ran over, set on fire (!), and it ran for several years with no problems.
Anyway, this JB Data guy has a big pile of them and PCMCIA ethernet cards to go with them, so I got a few and turned them into routers. They work great. They have a web site at http://www.unixsurplus.com/
Nice lady: Would anybody else like to share?
Bum in red hat: Hello, my name is Jason, and... I'm a Wil Wheaton mirror.
Everybody: <chorus>Hi, Jason!</chorus>
Actually, this seems like a quite elegant solution to the FPGA re-configuring problem to me. The paragraph about how their Viva software determines many times a second whether each function would be best done in hardware or software, and reconfigures the FPGA appropriately, sounds rather elegant to me. I did some work with FPGA's once, and was limited to "booting" the processor from a PROM and executing silly little instructions; with this sucker, you could specify a metalanguage with ALL the possible tasks you could throw at the processor, and have the processor make its own instructions to execute whatever subset of the language that was needed to execute! Any additional power could be tossed in there by creating additional parallel instruction units to execute the most frequently executed instructions... the possibilities are mind-boggling.
Of course, there is a limit to how many things you can throw at the system at one time; The ridiculously high benchmark was for a 4-bit adder; of COURSE a bunch of special-purpose parallel chips that did nothing but 4-bit ADDs would be able to outperform a cray with the speed and power reductions mentioned. But I'm betting flipping the FPGA into a dynamic x86 emulation mode, with instruction parallalism, would slow the whole thing down to something more reasonable. Even still, it should outperform anything the x86 chipmakers currently manufacture. The graphics possibilities are what really grab me; the documents were mentioning that as well. Imagine a 3D accelerator that doesn't have a fixed instruction set! If the application was coded to use a particular instruction 80% of the time, Viva would adapt the FPGA grid to create massive numbers of parallel execution units for that instruction, and the speed would go through the roof.
I'm really happy about this; I wonder how the mainstream processor manufacturers are going to react once the possibility of this thing becoming mainstream technology shows up in the press.
Actually, one of my friends is an electrical engineer, and he was telling me about this nifty device that UPS wanted built to save them next Christmas...
Turns out that Dragon Systems had a bunch of their people port their voice recognition engine to the StrongARM-110 platform running VXworks, and UPS kept throwing money at the project until they were getting 4 or 5 nines (99.999%!) reliability. No more mobile keypads! The device was intended for use in the UPS regional distribution centers, where it's pretty noisy, but some guys on the project wrote all sorts of nifty audio filters to remove all the crap from the signal. Turns out that they can get extremely reliable voice input using a 30 cent electret headset mic :)
I've also seen similar technology used in the WildFire platform; they wrote their own ridiculously expensive audio filters for a really moby computer telephony agent called WildFire. I've gotten very reliable results yelling into my cell phone, in a bowling alley, on league night, during fleet week...
The problem is that all these solutions are too damn expensive (6, 7 digits) for the sort of work you're thinking about doing, unless you want to put together a Silicon Valley startup, heavily commercialize the idea, and partner with one of those companies.
I have utter faith in the human ability to act individually and as a group to make lives better. We've learned some pretty hard lessons since the Industrial Revolution, and we won't forget them any time soon.
Just because we have this ability (hackers especially!) to bring smiles to our friends and our family, doesn't mean that all of us choose to use it.
Until 1998, I had to be content with making sure my congresspeople were making the right decisions for me, and then I heard that Netscape was going open source. Now it's our turn, and we have control; we have that ability to make people look and say, "that's great! I can use that."
Go change someone's life today with what you can do :)