It works for the Italians, "Telecom Italia to use IP network for 50% of European calls".
There is also VoIP-over-cable, and VoIP-over-cellular, and VoIP-over-Ethernet.
The fundamental problem with ATM is that it doesn't go anywhere -- you can't get ATM over Ethernet, over cable, over satellite, over 802.11, and so on.
So, with ATM, when all is said and done and you have built a big Voice-over-ATM network the end result is the same closed, designed-only-for-voice network that is the PSTN today.
I, for one, would like any-to-any TV-quality videoconferencing, exactly like I have with any-to-any voice today -- I can call anyone in the world with a phone. I can't call anyone in the world with video. From there, there are lots of interesting services - read some scifi to get a fill of cool ideas.
I can't reproduce this behavior on my Windows box running IE 5.50. The blog article doesn't say which version of IE is supposed to have this behavior.
Try it yourself -- use windump (tcpdump for Windows) to capture the packet trace.
Report back, share the news. I don't think there is a real "request" packet as mentioned in the blog article, but would sure like to see it. If there is such a packet, perhaps it's Transactional TCP (RFC1644).
The largest contibution to latency is the encoding and decoding codecs -- that is, the translation from an audible analog signal to a digital signal and back again. The more compression that is desired, the longer this takes. The actual transmission over a network -- using UDP or anything else -- is negligable and has little to do with the packets being UDP or old-world "TDM" voice.
Of course, those UDP packets (the VoIP traffic) can be prioritized over non-VoIP traffic, if the routers support such prioritization and there is a way to mark high-priority packets. DIFFSERV is one such mechanism to do this.
Read about SCTP, Stream Control Transfer Protocol, RFC2960, which combines the best of TCP with the best of UDP. SCTP is a protocol (that is, it doesn't run over UDP or over TCP), and provides the following features:
acknowledged error-free non-duplicated transfer of user data,
data fragmentation to conform to discovered path MTU size,
sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,
optional bundling of multiple user messages into a single SCTP packet, and
network-level fault tolerance through supporting of multi-homing at either or both ends of an association.
Implementations are already available or becoming available, on various OSs. Although designed for transporting real-time telephone signalling over IP (as stated in the RFC), it is applicable to anything else with similar requirements.
You could configure GRE tunnels between the sites and run IPX-over-GRE-over-IP. You can encrypt them, too, if you'd like. Fully supported, yadda yadda.
Digital Photography: Sell a system which combines the camera, PC, and printer, and show people how to use it. Sell it as a kit.
Video editing: Sell a Sony camcorder and PC with enough speed, memory, and a firewire card to do video editing, including some easy-to-use editing software. Include the ability to compress movies and store them on your webserver so people can stream them to their friends, maybe. This will sell a very nice, high-powered PC and a lot of disk capacity. Building one from scratch is difficult -- there are many choices and it takes a lot of effort to find the 'best' HW and SW combination.
Multi-PC broadband: Sell a NATting router for its additional security and ability to connect multiple PCs (the kids and the parents). Configure it for your local cable and DSL providers. "Networking is hard."
WiFi: Sell accesspoints and PCMCIA cards for WiFi and configure it, and configure NAT.
You can have a "add another computer to your house" package which includes WiFi to get to the PC upstairs from the cablemodem running downstairs. Sell the whole solution, not just the single PC.
Move to California -- a con-competition agreement is only enforcable while you're receiving compensation for not competing. Upon termination of employment, you typically don't receive compensation (duh!).
Instead of Apple IIs (that everyone else seemed to have at school at the time in the US) we had Atari 400, 800, 800XL computers. Lots and lots of them.
Apparently when they were eventually thrown away or sold, this hospital in the Czech Republic got one knew how to make it do tricks. I'm happy to see it put to good use!
I worked in IS at a hospital for three years. The best way to combat every system being named "mission critical" is to demand the same benefits and pay as other hospital 24x7 on-call personnel such as doctors and nurses and their direct support staff.
You will likely see a drop-off in so-called "mission critical" systems as the cost of supporting these mission critical systems goes up.
Email isn't mission critical: treating patients is mission critical. Admitting them is secondary, and billing them is probably a close third. Email? Yeah, right.. But I'm preaching to the choir.
(I wouldn't expect your email infrastructure to be so troublesome that it would cause 20-30 calls/week, though!)
It works for the Italians,
"Telecom Italia to use IP network for 50% of European calls".
There is also VoIP-over-cable, and VoIP-over-cellular, and VoIP-over-Ethernet.
The fundamental problem with ATM is that it doesn't go anywhere -- you can't get ATM over Ethernet, over cable, over satellite, over 802.11, and so on.
So, with ATM, when all is said and done and you have built a big Voice-over-ATM network the end result is the same closed, designed-only-for-voice network that is the PSTN today.
I, for one, would like any-to-any TV-quality videoconferencing, exactly like I have with any-to-any voice today -- I can call anyone in the world with a phone. I can't call anyone in the world with video. From there, there are lots of interesting services - read some scifi to get a fill of cool ideas.
Try it yourself -- use windump (tcpdump for Windows) to capture the packet trace.
Report back, share the news. I don't think there is a real "request" packet as mentioned in the blog article, but would sure like to see it. If there is such a packet, perhaps it's Transactional TCP (RFC1644).
The largest contibution to latency is the encoding and decoding codecs -- that is, the translation from an audible analog signal to a digital signal and back again. The more compression that is desired, the longer this takes. The actual transmission over a network -- using UDP or anything else -- is negligable and has little to do with the packets being UDP or old-world "TDM" voice.
Of course, those UDP packets (the VoIP traffic) can be prioritized over non-VoIP traffic, if the routers support such prioritization and there is a way to mark high-priority packets. DIFFSERV is one such mechanism to do this.
Implementations are already available or becoming available, on various OSs. Although designed for transporting real-time telephone signalling over IP (as stated in the RFC), it is applicable to anything else with similar requirements.
You could configure GRE tunnels between the sites and run IPX-over-GRE-over-IP. You can encrypt them, too, if you'd like. Fully supported, yadda yadda.
Video editing: Sell a Sony camcorder and PC with enough speed, memory, and a firewire card to do video editing, including some easy-to-use editing software. Include the ability to compress movies and store them on your webserver so people can stream them to their friends, maybe. This will sell a very nice, high-powered PC and a lot of disk capacity. Building one from scratch is difficult -- there are many choices and it takes a lot of effort to find the 'best' HW and SW combination.
Multi-PC broadband: Sell a NATting router for its additional security and ability to connect multiple PCs (the kids and the parents). Configure it for your local cable and DSL providers. "Networking is hard."
WiFi: Sell accesspoints and PCMCIA cards for WiFi and configure it, and configure NAT.
You can have a "add another computer to your house" package which includes WiFi to get to the PC upstairs from the cablemodem running downstairs. Sell the whole solution, not just the single PC.
See more here at California Public Policy Against Enforcing Non-Compete Agreement Trumps Employment Contract "Choice of Law Provision".
I went to Frankfurt American High School from 1982-1986, a US DoDDS (Department of Defense Dependent Schools) school.
Instead of Apple IIs (that everyone else seemed to have at school at the time in the US) we had Atari 400, 800, 800XL computers. Lots and lots of them.
Apparently when they were eventually thrown away or sold, this hospital in the Czech Republic got one knew how to make it do tricks. I'm happy to see it put to good use!
I worked in IS at a hospital for three years. The best way to combat every system being named "mission critical" is to demand the same benefits and pay as other hospital 24x7 on-call personnel such as doctors and nurses and their direct support staff.
You will likely see a drop-off in so-called "mission critical" systems as the cost of supporting these mission critical systems goes up.
Email isn't mission critical: treating patients is mission critical. Admitting them is secondary, and billing them is probably a close third. Email? Yeah, right.. But I'm preaching to the choir.
(I wouldn't expect your email infrastructure to be so troublesome that it would cause 20-30 calls/week, though!)