Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Technology

Vovida's VOCAL Softswitch Freed 49

Posted by timothy from the no-parole-no-nothin'-free dept.
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.)
This discussion has been archived. No new comments can be posted.

Vovida's VOCAL Softswitch Freed More

Vovida's VOCAL Softswitch Freed

Comments Filter:

  • More importantly! (Score:2)

    by Anonymous Coward
    What kind of software? Conventional OSes like Windows NT, Linux and Solaris are buggy, slow and complicated. There is only one system which can save the operating system market.....AROS [aros.org]!
  • 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.

    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.

  • 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.

    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)

  • Breaking into the gateway box is no different than breaking into a class5 switch - it takes an individual with drive, motive and skillset. I would much prefer the hands-on security available with VOCAL than using a nortel or lucent voice switch which utilize the old "security through obscurity" principle. With a decent Intrusion Detection system in place, and a well implemented firewall, the chances of having the gateway box compromised is much lower than a telco switch.

    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.

    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?

    Until about a month ago I did :-)

    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?

    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.

    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.

    I'll agree with different (except maybe at the house NIs). At a lot of points it ain't harder though.

    It would be great if there was encryption built into the standard, but what policy do you use when completing calls?

    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.

    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.

    I agree 100% with that.

  • Re:problematic VoIP (Score:3)

    by stripes ( 3681 ) on Tuesday April 10, 2001 @05:39AM (#303602) Homepage Journal
    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.

    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...

  • From my experience, VOIP is really not ready to be a company's primary telephony solution; internally or externally. That's not to say it doesn't have uses.

    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.
  • Depends on what you mean by a VoIP server. Do you mean a router or a voip client or some sort of application server? On top of that decision is whether or not you want to use specialized hardware (DSPs) to do the job. It can always be done in software which is nice, so Linux and BSD or Windows are not out of the question at all. If you wanted to build a conference server using SIP and certain media codecs for VoIP, its very possible. A few proprietary prototype implementations exist. Voice XML servers as well.
  • > telecos fighting back on 'infringement
    > 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."

  • Makes perfect sense, who gains on increased internet trafic?
  • I've done full H.323 decodes using NAI Sniffer Pro
    4.0 and it's great. Everything is displayed in a nice pretty and colorful tree format.
  • Check out www.vovida.com and see that vovida was purchased by Cisco. Also do a whois on vovida.org and see who hosts the DNS. The software that is given away on vovida.org was primarily written by Cisco employees, and it's open source. Just check out SIPTiger which is a configuration tool for Cisco's own SIP phone.

    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 .com, .net, and .org domains can now be registered
    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
  • We use Cisco IP phones with the Cisco Callmanager and have had little problems (The callmanager crashed once Win2k what do you expect). We are now working on putting the phones on a separate vlan from our boxen. VoIP still has a way to go but what we have is very usable.

  • The tolerence on voice communication is much better than command line interfaces. International call latency can often be in the 300-500ms range, with a poor call being even higher latency.

    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 ..... oh wait, we already are.
  • Breaking into the gateway box is no different than breaking into a class5 switch - it takes an individual with drive, motive and skillset. I would much prefer the hands-on security available with VOCAL than using a nortel or lucent voice switch which utilize the old "security through obscurity" principle. With a decent Intrusion Detection system in place, and a well implemented firewall, the chances of having the gateway box compromised is much lower than a telco switch.

    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.

  • when the mainstream speaks of VoIP, they mean telephone appliance to telephone appliance type voice, not PC to PC.

  • Check out this guy's work [voice2sniff.org]... He's hacked in H.323 support for ethereal, and provides source and all.

    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...)
  • I have no vested stake in VoIP, but it sounds to me as if your "massive problems" lie with your sound card setups and not with VoIP.

    ostiguy
  • that is a software telephone. This is a software PBX toolkit (I don't know enough about its stability to call it a full fledged software pbx).

    ostiguy
  • we use some VoIP on our 100 mbit switched lan, and we have MASSIVE problems with it.

    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 .. it don't think that voip will render normal systems useless ..
  • H.323 was never designed to handle security, nor were H.248 or H.245... those are signalling/encoding protocols...

    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-charter .h tml

    Service in the PSTN/IN Requesting InTernet Service (spirits)

    http://www.ietf.org/html.charters/spirits-charte r. html

    Session Initiation Protocol

    http://www.ietf.org/html.charters/sip-charter.ht ml

    Signalling Transport Protocol

    http://www.ietf.org/html.charters/sigtran-charte r. html

    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

  • My experience is that sound cards don't get the level of latency you need to be happy w/ VoIP. Quicknet cards are better, and hardware that can go straight to the ethernet are also better (e.g. ethernet phones).

    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).
  • Unix Box For Call Control

    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.

  • There are a number of them, but I'm not sure which ones are most appropriate.

    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.
  • 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.
    There is another solution that is much more common: make your own private internet (put routers, connect them with leased lines, put voice gateways e.t.c), connect this network using smart routing with the Internet as close to the backbones as possible, and keep utilisation below 50%. All the voice quality problems go away. This scheme is already used be several ITSPs. It just works, no QoS needed.
  • Vovida was bought by CISCO after most of the software (stacks, proxies) was already written and open-sourced.
  • The telcos WANTS VoIP. The current phone network requires a real, physical, uninterrupted circuit exist between the caller and the callee. That's a lot of freakin' wire. And the switches to handle it are expensive, cludgy, and prone to error. VOiP solutions reduce equipment and network costs while still enabling the telcos to provide service at THE SAME COST to its users. Translation = lower capital expenditures, AND higher margins.

    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" ... I think that just might be trolling.

    ::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.
  • Hmmm... I work at a company where VoIP is a major focus, and of our 40000 employees, approximatly 2/3rds currently use VoIP phones. When I first got mine (~1 year ago), the quality sucked, dropped calls, strange voice quality, no dialtone at times. But these problems are now gone. I don't even think about it anymore. And this is over a network where we don't yet have full QoS support (actually, we don't have any QoS support in most of the branches, but that is coming next). Still works just fine. Robert
  • Asterisk? [asteriskpbx.com]

    It's been here for a while. A fully opensource PBX.

  • Freeworld dial up at http://pulver.com/fwd/ [pulver.com] is using a bunch of this software to provide IP phone services.
  • yah - we laughed a bit about this award at times too. It won some other possibly cheesy awards (Like Linux World Show Favorite) - you can see them at http://www.vovida.com/pressevents.html [vovida.com]. The real taste test is in the dog food. Several people here use it to run the telephone they use every day and like it.
  • This is going to be a long, drawn out legal battle with the telecos. People who do not have teleco connectivity on the 'net are going to start seeing the telecos fighting back on 'infringement of the telecos business.'

    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]

  • 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.

  • It seems that everyone and their brother are trying to tie VOIP to QOS which basically means that phone companies could meter the voice packets and charge a different rate for the alleged "faster" delivery. Different networks will never be able to coordinate QOS effectively without charging a premium. And why would a customer pay a premium price for an old service (voice transmitted over a wire is not new)

    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
  • Not just that....

    Could you imagine the online poll? CowboyNeal CowboyNeal!!!

    mick
  • Are there any VoIP POTS gateway programs out there?
    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.
  • Speak Freely [speakfreely.org] has been open source for 5 years. It been compiled on Win32 and Unix. Its cross platform.

    Where the heck have these people been?

  • I would bet that you aren't running VoIP on the same network as your DoIP (Data over IP).

    VoIP, another bad idea, like Java, that just needs to go away - me.

  • What kind of hard ware would be needed to run a voip server? Would linux be better then bsd? or vice versa?


    Fight censors!
  • The Telcos dont have any claims to you talking to people. Plus there is no way for them to tell what is being sent over their lines unless they start filtering packets, which wouldnt go over too well.

    Arathres


    I love my iBook. I use it to run Linux!
  • There is a way for them to tell exactly what's going over their lines, by analyzing SS7 data. The technologies out there, it just isn't widely used yet.
  • I've found that voice over IP can be pretty good. Or it can suck goat ass. Using stuff like phoneFREE and such can make for some interesting phone calls if you don't have a good microphone. As awesome as it is to make calls for free, the quality sucks. As for them being open-sourced now, It's about time. I think that we should be able to work on it fairly well. *groans about class starting*

  • 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.

  • Thats no big deal now since anyone could always switch to cable, or some workaround with a wireless network can be made. Phone companies knows this, and many will try to leverage their way into the other markets that can hurt them (take away business) so I don't think it will be in their best interest to lose customers, because they won't play fair.

    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)

    by deran9ed ( 300694 ) on Tuesday April 10, 2001 @03:07AM (#303641) Homepage
    There are three main issues of VoIP security. One is authentication: Is the party who answered the call the intended destination? Another is nonrepudiation: Once a destination accepts a call, is there anything in place that prohibits it from denying receipt of the connection? Finally, there's privacy: Is the call content secure? Authentication and nonrepudiation are important.

    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]
  • That's a question of what equipment you use. Sure, some VoIP equipment suck, but you'll find plenty of normal PBX's that suck just as much.

  • Re:Late and Never (Score:3)

    by vidarh ( 309115 ) <vidar@hokstad.com> on Tuesday April 10, 2001 @02:08AM (#303643) Homepage Journal
    What kinds of VoIP systems have you used? I tested VoIP two years ago that was available then, and that delivered chrystal clear trans-atlantic calls over the public internet at low bandwidths, and I tested 9.6kbps systems that gave better quality than most residential analog phones I've used.

    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.

  • We're sorry your elite pilots in their advanced jet fighters seem to have difficulty avoiding a P-3 Orion (designed around 1955). We're sorry that your "official" accounts had the fighters 400 m from the P-3, and then changed to 5 km, still without explaining how something as old and slow as the P-3 was able to close such a large gap so quickly (even if the P-3 was capable of mach 1 (!), it would still take almost two seconds to close that 400 m gap). We're sorry that you appearantly don't equip your pilots with emergency radio beacons for when they eject (something that can often be found on the smallest US boat). We're sorry that you're trying to claim that islands as far out as the Philippenes are sitting in your territorial water. We're sorry that you have a collection of intercontinental ballistic missiles gives us reason to want to keep an eye on you with surveillance planes.

    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.

  • Get back to sucking the feces from my ass, slaveboy. Lick the shit off my feet!

    __________________________

  • ShoeBoy licks the feces off me after we fuck and cover our naked bodies in our own feces.

    __________________________

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close