Vovida's VOCAL Softswitch Freed 49
bko writes: "Our software, VOCAL, won a Computer Telephony
Magazine award for Product
of the Year (it's at the bottom of the page), mostly because they liked the idea of Open Source
Voice over IP software. Well, we've finally been able to release all
of it (not just part) at our website. CVS access
coming soon (we hope). Currently compiles on Red Hat 6.2 and Solaris,
diffs accepted for more OSen (I'll do FreeBSD when I get a
chance). Since the site is vague about what's in VOCAL, try this Technology Overview (sorry, pdf) for more info. Basically, there's a working VoIP softswitch in there, under a BSD-style license." Open Source Telephony software is a good deal all around, so this is quite nice news. (See also this story about David Sugar's Bayonne Project.)
More importantly! (Score:2)
Re:Problem solving (Score:2)
Doesn't most traffic going to Earthlink and AOL still pass over normal dial-up links? The RBOC still gets their pound of flesh there. Then the ISP backbones are made of long haul circuits that mostly come from long distance providers (at reduced rates because of the size of the ISPs).
The only place the RBOC isn't doing so great is DSL where they have to rent out copper and equipment space at pretty low rates. Now long-distance companies may well be losing more long distance voice revenue then they are gaining in data circuit fees. Maybe. I don't think so. Even if it is true, they are losing more due to deep rate cuts to stay competitive.
Re:Latency (Score:2)
No it doesn't. First people could break into the VoIP "gateway" boxes and either splice off a copy, or do a man-in-the-middle attack. Or they could do a DNS attach and do man-in-the-middle. Or rather then being a company employee with router access they could be someone who broke into the router (or the box on the employee's desk!).
Oh, and about that teen with alligator clips? What makes you think the ISP has no wires? Wires go out from your house to the ISP, from the ISP to the other house you call, and wires and fibre all over the ISP's backbone. Oh, and there could be three or four ISPs involved....
The alligator clips should be able to go at the NIs at either home. Some of the other connections can be decoded with relatively inexpensive hardware. Other connections require more, but that hardware might be borrowed or stolen....
Plus some people aren't fond of the government being able to listen to them. That isn't any worse with VoIP, but it could be a lot better (I assume a lot of those people try running VoIP over SSH or encrypted VPNs of some sort -- but the people they talk to don't always have that)
Re:Latency (Score:2)
Well I know more people that have broken into random Unix systems then any sort of central office phone switches, but I haven't done an extensive survey.
Until about a month ago I did :-)
Who needs to? Cut the cable, paste on new ends, and slap the router in between. A short outage won't normally be checked into. Even a long one will take a while to get remote hands there.
But forget that. If you tap at an ISP hub many of the connections will be 100Mbit ethernet and 1000Mbit (1Gbit) ethernet. Plain old ethernet. Same thing everyone and his brother knows how to tap. You won't get to do that at the transit routers (at least not for large ISPs) but customer aggregation routers'll be easy to hit. Most of these hubs are unmanned. I would guess that most of the rest are subject to social engineering.
I'll agree with different (except maybe at the house NIs). At a lot of points it ain't harder though.
That would depend on what the customer wants. I would assume most would want a distinctive ring, or visible indicator and the call to complete. Others would want more of a STU-3 emulation and to have the call rejected (and logged). Either of those are better then the nothing you have now.
I assume some would want a more complex policy (calls from inside the company must be encrypted, distinctive ring for outside unencrypted calls...). Without encryption being a standard part of VoIP that makes it a lot harder to build this sort of thing in though.
I agree 100% with that.
Re:problematic VoIP (Score:3)
Encrypting a stream (w/ blowfish) seems to take well under 5msec on my (two year old) machine. Five years ago (which I think is when VoIP was formed) it would have been 10msec. Not too bad if 250msec is your goal.
Now I don't think 250msec is a good goal. Isn't that like .25 seconds?!! I think 100msec is the upper bound for things like command line user interfaces, and I think GUI's as well. If 100msec is the goal, 10msec is a lot harder to justify, esp since coast to coast latency tends to be 70ms on leased lines.
However I think there are two bigger reasons encryption isn't part of standard VoIP. Five years ago it was almost impossible to do open source crypto in the USA, and doing closed source export crypto was quite painful. In fact doing close source export crypto is still a pain. Ask Apple why SSH was in the preview releases, but failed to make it to the final release.
The other reason? People don't see it as worse then the existing unencrypted phone system. It may actually be worse (simpler to divert IP traffic, probably simpler to systemicly monitor as well), but most people don't see it as worse.
I have another viewpoint. A new technology shouldn't strove to be "as good as" an old one. It should try to "hit the ball out of the park". Crush the old one. Faster, better, stronger. Old one's not safe? The new one is a Volvo. Old one is a tad slow? New one finishes as your finger leaves the enter key. Never aim for second best, there are enough things pulling you down anyway...
Current real-world uses for VOIP (Score:1)
Last year I was doing a little PBX support for a friend who had to move the main office to a new building several miles away while keeping service to a small 4-person warehouse.
The goal was to keep the warehouse on the internal phone net, but the costs were prohibitive. A micro switch still costs several thousand and wasn't guaranteed to provide connectivity to the main PBX's advanced services and the "remote extender" modules that enable the digital phone sets to work remotely required ISDN lines at both sites, an ISDN card installed into the main PBX, and had a hefty monthly reoccurring fee.
Their "solution" was to split a few channels off the PRI for voice, get normal business service on those lines, and simply call into the main office to check voicemail. The warehouse queue was set to out-dial from the main office and do an old rotary hunt until either someone answered or tried all 4 lines and then dumped them to voicemail.
This VOIP solution would have cut out the monthly reoccurring fees for the business lines, still provided full queue activity, a couple of simple scripts could allow email notification of missed calls (since voicemail notification might not be accessible off the SIP phones with their switch), let the PBX keep better call statistics, and cut down on the main office's out-dial usage.
Costs for the VOIP servers would have been readily offset by the monthly reoccurring and the MUX hardware involved. Heck, for only 4 users I expect it wouldn't take more than a commodity PC at each end.
Re:What Kind of hardware? (Score:1)
Reality check from The Economist (Score:2)
> of the telecos business.'
That's so last millenium! ;)
The Economist magazine's March 24th issue had this to say about VOIP and the telcos:
"VOIP's change of fortune came in 2000 when, one by one, the large telephone carriers started to replace parts of their traditional infrastructure with various types of IP-based multi-service networks. The irony is that the new-style carriers that helped create the IP telephony business when it was still a niche activity for PC hobbyists have found the going tough and are facing a shake-out. Meanwhile, VOIP is thriving within the traditional telcos that tried to stifle it."
The article goes on to talk about telco IP penetration in the U.S., Europe, and Asia. Asia is "adopting [IP] telephony faster than anywhere else. China already generates more VOIP traffic than any other country except America. In Japan, 12% of all international calls go over IP networks."
Re:Voida is Cisco Open Source (Score:1)
Re:Ethereal does H.323 sniffing (Score:1)
4.0 and it's great. Everything is displayed in a nice pretty and colorful tree format.
Voida is Cisco Open Source (Score:2)
I don't want to make some huge proclamation on Cisco and open source, but I think this is very exciting.
[smutt@ruff smutt]$ whois vovida.org
[whois.internic.net]
Whois Server Version 1.3
Domain names in the
with many different competing registrars. Go to http://www.internic.net
for detailed information.
Domain Name: VOVIDA.ORG
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: www.networksolutions.com
Name Server: NS1.CISCO.COM
Name Server: NS2.CISCO.COM
Updated Date: 18-jan-2001
Re:Late and Never (Score:1)
Latency (Score:1)
If you can hit 200ms latency with Voice over IP, then the average person cannot tell the difference between that and a normal local or national call. Obviously a call sounds much better if latency is under 100ms - but in most cases it is not possible from end-user to end-user.
Security is the art of making the goal more expensive to reach than its value. Although those with access to backbone routers can reroute traffic easily through a sniffer or utilize a mirror port, most of the population does not have access to be able to sniff traffic beyond their first upstream router.
Compared to the existing phone system where any preteen with alligator clips can listen in on a phone call it now takes a person with considerable experience, who would be jeopardizing a successful career to listen in on the calls.
On the other hand, we could all just live our lives as if we were always being watched and listened to all the time
Re:Latency (Score:1)
As for being "clipped" along the way, the most vulnerable point is from the client to the first ISP as this is likely to involve cable modem or dialup which is not extremely difficult to arrange.
With regards to the wires of an ISP - I agree that it can be sniffed, but not with the ease you suggest. How many people do you know that can de-frame a DS1 and pull the IP traffic out of it inline? How many have access to the equipment necessary to strip the shielding off of the exact fibre cable, create a macrobend and have the protocol analyzer to dump the reflected impulses to ATM then to IP?
The point is not that it cannot be broken into, but that it is more difficult and takes a different skillset than the trusty alligator clip method.
It would be great if there was encryption built into the standard, but what policy do you use when completing calls? Calls without encryption get dropped? That's a PR nightmare for any company doing that. Linking up the call as unencrypted? even worse. Should a voice prompt notify the caller that it will be unencrypted? That will start FUD how much the phone company knows yet people like to remain ignorant of.
There is no simple answer to any of this - but VOCAL is a good step in the right direction since we can take the code, and add encryption to it or improve on the standards.
Re:What about Speak Freely? (Score:1)
Ethereal does H.323 sniffing (Score:1)
Previously the only product that could do true H.323 decodes was the Shomiti [shomiti.com] (which is a damn fine piece of equipment, by the way...)
Re:Late and Never (Score:2)
ostiguy
Re:What about Speak Freely? (Score:2)
ostiguy
Re:Late and Never (Score:2)
One big problem is echo. The pbx will allready do software based echo cancellation for calls on normal calls, but you still hear it.
The reason for it is, that normal soundcards (sb live) + headseds still seem to suck. We are now trying usb phones, that should work better in theory
but right now
Wrong protocols... wrong applications (Score:1)
What you are looking for is the next generation VoIP signalling protocols, be advised that not all of them handle security, that is supposed if you stablish a VoIP session you should do it over a trusted encrypted tunnel and so forth. Also note that some are designed to be used in tandem, no single protocol will suffice. Have a look at:
Media Gateway Control Protocol (MEGACO)
http://www.ietf.org/html.charters/megaco-charte
Service in the PSTN/IN Requesting InTernet Service (spirits)
http://www.ietf.org/html.charters/spirits-chart
Session Initiation Protocol
http://www.ietf.org/html.charters/sip-charter.h
Signalling Transport Protocol
http://www.ietf.org/html.charters/sigtran-chart
All these protocols are designed with RSVP, SCTP or RTP in mind so your security will be handled through MPLS VPNs
Have a good reading
Re:Late and Never (Score:1)
High latency is usually the cause of echo. Note that there is also echo cancellation, but again, you'll probably need specific hardware / software to get that (hardware echo cancellation is clearly better, but software ec is probably better than none at all if you hear a lot of echo).
Recommended hardware (Score:1)
If you're interested in running VOCAL, I'd recommend a Linux box running the old egcs 1.1.2 compiler. We use Redhat 6.2 internally for development. If you use Redhat 7 (or one of the newer 2.95 or 2.96 compilers), we have patches that help.
Yes, I know this compiler isn't really as ISO C++ as it ought to. But we wrote all of our code to this compiler, so it's the best supported one.
BSD would require porting (which I will be working on when I have a chance). The big issues are threads -- the code requires reasonable thread support, and can occasionally require preemption between threads, so some thread libraries (e.g. pth) may not be enough.
Solaris works, but you'll need the Forte Compiler (SunPro) to make it work easily.
Ethernet Phones
Then, you'll need some phones. I think the Cisco 7960 [slashdot.org] phones are nice, and you can get SIP for them (but they are expensive). Other manufacturers can be gotten from SipCenter's web site [sipcenter.com], as well as this German site [fokus.gmd.de]. We are one floor above the Komodo guys, and their boxes are quite reasonably priced (although I'm not sure how to get a SIP version).
Another alternative would be to use a Linux box as a phone.
More expensive would be a quicknet card or two. They're $100-$200 dollars, and sound better then sound cards.
Cheapest is a sound card. We have soundcard support in vocal, but it's not great (although some of that is our fault).
Gateways
You don't strictly need one of these if you're just interested in trying out VoIP, want to do an intercom-type system, or are trying to make calls over the Internet, but if you want to be able to receive calls from or place calls to the PSTN (the "real" telephone network), you'll need to get a gateway or two. Here, I know that Cisco makes them, as well as some other guys (Sonus? Nuera? Look at Henning's page [columbia.edu] and SipCenter [sipcenter.com] for more gateway manufacturers).
I hope this helps.
Re:VoIP POTS gateway (Score:1)
First, some of the Quicknet cards have a "line" interface (the Linejacks). These don't work with VOCAL directly, so you may want to use OpenH323 instead (OpenH323 appears to have an H323 PSTN gateway that uses these cards). If you'd like, you can try to use the OpenH323 gateway with VOCAL (apparently someone has gotten this to work), but it's hackish.
I think some Komodo boxes are appropriate for a home or something.
I know that there are other high density solutions which are available, but they seem like overkill.
Re:what is taking so long? (Score:1)
Re:Voida is Cisco Open Source (Score:2)
No, no, and NO! (Score:1)
This is especially true for CLECs (Competitive Local Exchange Carriers). ILECs (the baby bells) aren't nearly as thrilled, yet they recognize the market is moving that way, and are preparing their business plans to make the switch.
NO ONE is fighting VoIP. Even the equipment manufacturers like Lucent and Nortel are looking forward to it because they can sell their VoIP solutions to the telcos who otherwise wouldn't be buying new switches.
I'm not even going to begin to comment on the falacy about a " 'net tax for the voice over IP"
::sigh:: Every time I see a telecom post on Slashdot, there are lots of "experts" who don't have a clue what they're talking about.... reminds me to take that into account when reading posts on topics I'm unfamiliar with.
Re:Current real-world uses for VOIP (Score:1)
Hello??!! Anybody heard of.... (Score:1)
It's been here for a while. A fully opensource PBX.
Systems using this software (Score:1)
Re:Product of the Year is bs... (Score:1)
Telecos Problem (Score:2)
It doesn't really matter how long it takes or who eventually wins these cases. The telecos have more money than most of the ISPs and have lobbiests already pushing for a 'net tax for the voice over IP. Next we are probably going to find that you cannot connect VoIP to someone who uses a teleco as an ISP.
Should make for interesting case law if nothing else.
DanH
Cav Pilot's Reference Page [cavalrypilot.com]
Re:what is taking so long? (Score:1)
While I do not recall anything specific in the default RFC's for RTP that cover this, I do recall that the Robust Audio Tool (rat) actually does have an option to send redundent audio packets in a different encoding format. However, I believe the redundent path is targetted at the same port number and is mixed in the same RTP packet stream.
what is taking so long? (Score:1)
So if we ditch QOS, the problems are latency and the fact that ip and ethernet packets are too big, which means if you lose one or it is delayed, then you lose noticable amounts of sound. I think the agreed standard is loss or delay of around 400 ms is the point at which you can't carry on a conversation.
I don't know what the current efforts are focused on, but QOS is a bad and expensive idea.
As an aside, it seems the only reasonable solution (besides QOS) to these is to send more udp packets over different udp ports say 3 for sending and 3 for receiving and overlap the voice data so if you lose one packet you don't lose enough to care.
Address schemes should be a seperate issue
Re:VoIP? (Score:1)
Could you imagine the online poll? CowboyNeal CowboyNeal!!!
mick
VoIP POTS gateway (Score:1)
Basically we've got more cat5 running around the house here than standard old phone cable. It would be nice to be able to place and receive calls from our existing computer stations.
What about Speak Freely? (Score:1)
Where the heck have these people been?
Re:Current real-world uses for VOIP (Score:1)
VoIP, another bad idea, like Java, that just needs to go away - me.
What Kind of hardware? (Score:1)
Fight censors!
Re:Telecos Problem (Score:2)
Arathres
I love my iBook. I use it to run Linux!
Re:Telecos Problem (Score:1)
VoIP (Score:1)
The Potential of VOIP ... (Score:2)
IMHO, Open Source Voice over IP software is a great development and I sense that people don't realise how good VOIP *could* be.
Im currently involved a project for broadband home networking, part of which is a 3COM SIP phone, and there's some damn cool things that can be done - I know, I know there's superior VOIP phones but 3com target small business/home and they support SIP).
*Interesting Aside:* This work is for an Aussie telco - can't say which one ;) - and they have told me to assume broadband connection for all home networking projects which suggests to me that broadband to the masses (we're talking ADSL here, Cable coverage is pretty small in Australia) is coming quicker than I thought!
okay lets see, oh yeah I was mentioning VOIP fun back there, lemme see, where do I start, how about:
Log into any SIP phone and all user preferences and incoming calls follow the user
Free PDA control application to "beam" phone numbers from your PDA (only works with Palm OS, via IR)
Standard VOIP features: conferencing, chat, unified messaging
Software version of VOIP phone on a laptop to make mobile calls (hellooo open source!)
Also remember you save money when using VOIP (apart fromt the fact the VOIP phone's cost 3 years worth of phone bills up front!!) as you are now transmiting voice over IP packets instead of in house systems.
Problem solving (Score:2)
Notwithstanding, many people I know don't use their telephone company as an ISP, so unless a telco is planning on buying up Earthlink, AOL, etc., they don't pose that much of a threat.
problematic VoIP (Score:3)
Without gateway-to-gateway encryption, VoIP packets are vulnerable to sniffingng. All it takes to intrude is one IP packet monitor sniffing somewhere on the network, watching for VoIP packets and storing them on a hard drive for playback later on.
In addition to commercial devices for monitoring and troubleshooting IP traffic streams, sniffers are available as free software and most come with source code (or as source code) that can be easily modified for tapping.
It's kind of like the early days of cordless phones. It took a while for users of those to realize they were being tapped. FCC regulations prohibiting the sale of the scanners that pick up certain bands allocated to wireless telephony didn't provide much of a barrier. And the information necessary to modify common scanner models was widely available. Later, the same became true with regard to analog cell phones.
IP packet monitors are much like those scanners. Few of the commercially available devices snoop VoIP streams right out of the box. Neither can most of the free software tools available enable VoIP snooping without modification. But either can become a fully automated, programmable VoIP tap. Why aren't VoIP calls encrypted? Because on-the-fly encryption and decryption takes time, and time is at an utter premium in a VoIP connection. The overall latency of a VoIP call must be less than 250 mSec to approximate toll quality. Add milliseconds, and the perceived quality of the call drops. For an industry still working for broad acceptance, call quality is paramount.
Even though encryption is a component of the H.323v2 standard, it's likely to be one of the last features implemented. Although each involves different skills and technologies, the same blackguards who'll tap your PSTN lines are the ones who'll sniff VoIP links. Any data that can be stolen from analog conversations is at risk in a digital link too. The difference, generally, is that analog lines can be tapped only one at a time, VoIP lines can be tapped by a whole T-span or more at once. There's also no real way to detect a VoIP tap, except by locating an unauthorized system on the network.
Internal snooping is easier and more likely than an outside tap, unless your network can be compromised at some outside point.
But the most important thing to remember is that VoIP calls can be tapped. Until you have gateways that encrypt the call end to end, treat VoIP calls as "unsecure" - especially if they leave your private network. And any calls passing through the 'Net should be regarded as no more secure than a CB radio conversation.
Good article on VoIP... RFP: VoIP invasion, are you ready for it? [networkcomputing.com]
Be advised, the article is over 10+ pages long, and it gets boring
view the source Luke! [antioffline.com]
Re:Late and Never (Score:2)
Re:Late and Never (Score:3)
Of course, if you're using VoIP over networks that are also being used for data transfers without switching or quality of service limitations on data transfers, VoIP will suck, because someone will eat up the needed bandwidth.
As for Vovida's system, it seems mostly geared at integrators that wish to put together either custom systems or telephony "appliances" to place with customers. It seems well suited both as a full PBX solution for corporate use, as well as for components if you want to build larger, carrier type, systems.
Obviously, if you want to build carrier type systems you'll need to know what you're doing, and the software is only a small part of what you need.
Re:usa spy criminels in trouble (Score:1)
And, last but not least, we're sorry that your wounded pride prevents you from looking at the situation objectively and keeping a cool head.
But we're not sorry that your fighters were flying dangerously close to our plane, causing an ACCIDENT. The U. S. wouldn't purposefully put their surveillance equipment in jeopardy, and, unless the Chinese government lives up to its reputation, the F-8 pilots probably weren't ordered to collide with our plane, either.
Of course, if saving face after a disaster is more imporant to you than continued participation in trade with the rest of the world, and more important than pissing off one of Taiwan's main arms suppliers, that's your problem, not mine. Then again, if the People's Republic were more level-headed, Taiwan probably wouldn't need to buy arms from the U. S. to begin with.
And get your damned propoganda spam back on topic.
Timothy (Score:1)
__________________________
Re:Hack Shoeboy (Score:1)
__________________________