Slashdot Mirror

This should look *remarkably* familiar to some of you. http://www.counterpath.net/x-lite.html&active=4

It's clear by the number of comments looking for a 'good' voip client you may not have a handle upstream issues. The only way to actually get a handle on it is to debug the UDP traffic.

1. NATing Most home networking devices have poor support for media NATing. (RTP/UDP The ones that have decent support are cursed with firmware supporting a single VOIP provider. This is where a device you can install a Linux distro on is helpful, but only the first step. http://www.iptel.org/sipalg/ I've had problems on Cisco devices too, so don't think you can spend your way out of the problem.

2. ISP issues. I have seen ISP issues with VOIP media that does not originate from the ISP's VOIP service.

A simpler shot in the dark is to use an SIP proxy to handle the call. (STUN server) In some cases this works because the proxy goes to great effort to keep the connection alive at all times. Can you proxy a Skype call? Dunno if they support plain-vanilla SIP.

Welcome to VOIP!

>SIP, if I remember, requires so many open ports you may as well not try unless you're sitting on a real Internet IP address, with no
>firewall, at both ends.

Nat just sucks but there is some workaround with connection tracking, i.e. http://www.iptel.org/sipalg/ .

Don't worry, this article is mostly FUD. For one, it assumes that all phones will be vulnerable to the same flaws. They won't - they run MANY different code bases. There is no mono-culture in VoIP like there is with desktop operating systems (well, except for the Skype example - I don't use skype anyway due to the closed/proprietary nature of it.) It also assumes that any security flaws won't be fixed or addressed. Anyone that deals with IP phones knows that new firmware comes out every few months. If you have a Vonage-like VoIP service, new firmware can be pushed out to you automagically. Lastly, I expect that VoIP proxies will becomes a standard feature in SOHO routers in the not-too-distant future to deal with multiple NATed phones and other issues. Probably something like a light version of SER. Expect them to be able to filter crap out like modern firewalls / web proxies do.

MSN Messenger supports SIP for text messaging. While it is admittedly not fully supported (ie. no voice or video), it is supported and Google will soon support SIP in addition to Jabber.

According to Wikipedia, Session Intiation Protocol is an IETF standard, although it was not originally intended for instant messaging, which is what I remember as well.

http://www.iptel.org/ietf55/use_msn.html -- instructions for setting up SIP with MSN (or SIMPLE, the instant messaging subset)

http://en.wikipedia.org/wiki/SIMPLE

This is exactly what my company does for VoIP, including Asterisk and SER. Our customers are mostly ISPs and companies replacing PBXs. It can be a tough sell at times, but getting easier as these products mature and more and more ISPs want to offer VoIP to their customers.

However, we still have a quite a customers who want something commercial, such as Cisco Call Manager.

I don't know which SER you've been trying but the normal one has definitively at least voice mail support. Technically it's a separate application because SER is very modular but it's there.

Is this enough reverse engineering that we can code a Skype/SIP protocol gateway component for an Asterisk server? I'm just referring to all the popular VoIP systems like Vonage as "SIP". The important question is can the Skype protocol network be piggybacked to terminate calls initiated by SIP clients like KPhone or Linphone?

I try to avoid relying on a product which has a single supplier or is not standards-compliant, even if it does meet the FSF's standards.

Standards compliance is a great thing. Recently I've been working on a VoIP deployment using SIP phones, Asterisk, and SER. One of the things that has impressed us the most about SIP telephony -- as contrasted with earlier VoIP and digital office phone systems -- is that the major vendors' products all interoperate at a basic level (placing and receiving calls) out of the box. This is a big contrast with earlier systems where (e.g.) Nortel sold you a Succession VoIP system, and nobody else's phones would work on it.

Most of these SIP phones are not open-source. Cisco's and Grandstream's phones are the usual binary-only deal -- compliant with open standards, but not even source-available. However, some SIP phones are open-source, notably SNOM phones, which run embedded Linux, and for which you can download an SDK from their Web site and build your own firmware image. Not too terribly surprisingly, SNOM's phones are not the slickest in appearance (that would be Cisco) or the cheapest (Grandstream) but they are, as far as we can tell, the most configurable.

Much the same seems to be true of VoIP gateway systems. Many people with whom I've spoken are using Cisco instruments as their gateway between SIP and the PSTN (conventional phone system). We are using Asterisk. Although it is hardly the easiest software to configure -- it's kind of like the Sendmail of VoIP, minus the security hell -- the Asterisk/Zaptel/Linux system is far more flexible than closed equivalents.

So what does this have to do with the advantages of open source? In a field of open standards, such as SIP telephony, open source can really shine. Open standards mean that there is little space for vendor lock-in, so vendors cannot exclude open source in the usual fashion. Open source is largely immune to the problem of treating standards as "tick-list features", which some appliance developers seem to suffer from: implementing the standard in a slapdash way so that you can mention it in the four-color glossies. ("Do we have, um, this 'SIP' thing?" "Uh ... [type type] ... sure, we do now!")

So how does this contrast with some of open source's notable weaker points, like user interface and graphics software mentioned in the article? It seems to me that open standards and open source both have their strengths in infrastructure as opposed to interface: not the buttons that users push on their desktops, but the underlying systemry that really makes the system (and the network) run. The advantage of Asterisk over proprietary PSTN gateways is much more than the advantage (if any!) of SNOM over Cisco SIP phones. The same is true in other infrastructural roles: the advantage of Apache over Microsoft IIS is much more than the advantage (if any!) of KDE over, say, the Mac OS X interface.

For the user of closed-source end-user systems (be they phones or desktop computers) the presence of open source in the infrastructure means that it can be customized by experts (IT staff or consultants) to the needs of the organization. It also often means that the infrastructure is simply higher-quality, which benefits everyone. The folks who get VoIP phones on their desks at my workplace don't care whether the gateway is Asterisk or Cisco, but they do care if we can implement features they request. Likewise, our Web designers using Dreamweaver benefit more from the fact that we use Apache (since their work is safer than it would be with IIS) than they would by using an open-source end-user tool.

To make a tangent, consider Microsoft. Their tradit

• Local access lists. Every serious SMTP MTA supports access control based on IP address, reverse DNS, attested address (HELO), and so forth.
• DNSBLs and other sorts of published blocklists. A DNSBL is nothing but a site's IP-address access list, published over the DNS so that others can use it.
• Protocol enforcement techniques such as greylisting. Greylisting tests that the sending host is willing to make the effort of retransmitting, as required by the protocol.
• Content filtering. Even a server-side antivirus program is a content filter; much more so the statistical filters often used today.
• Multi-site statistical tools. Vernon Schryver's DCC and Vipul's Razor come to mind.
• Traffic limiting. ISPs can restrict the number of SMTP messages a host can send per day or hour.

Many of these techniques can be adapted to VoIP systems. I am surprised that SER and Asterisk do not already support DNSBLs -- even if there is no call for them yet, we will certainly need published lists of abusive hosts or networks within a few years.

The flexibility with which one can express access restrictions is an important part of any system's security. My workplace is just starting a VoIP deployment. I want to be able to say things like:

• No single outside host may make calls to more than 50 different destinations in a day.
• No host may send more than ten pending SIP invites at any time. (Prevent predictive dialing!)
• No host may send SIP IMs to more than 20 addresses in the same minute.
• After an inbound call is completed, the recipient can dial *666 on our Asterisk PBX to report it as an abusive call. If five different addresses report abusive calls from the same originator, that originator is flagged and blocked for 24 hours.

The glaring practical difference is that there seem to be about zero open-source SIP servers, and about a dozen open-source XMPP servers (going off the list at JabberStudio which might not represent all of them.)

Iptel.org seems to be one; server, client software (though the KDE client seems to copied from Wirlab) and more. All GPL'd.

A quick google search turned up IPTel.org. They have GPL'ed IP Telephony packages, including a SIP router (for call routing) and software phones that run on Linux. I'm sure more investigation would yield more information. My company derives a large amount of income from running a call center. We get paid for active minutes on the phone. It was in our best interests, financially, to purchase a commercial IPTel system that would be guarunteed by the vendor and would have 24x7 onsite support. By the way, we selected Cisco's AVVID solution, for those who are curious.

We had a serious dilemma, we run our production heavy hitting servers on UNIX and sometimes Linux. We are starting to transition Linux for a lot of our core infrastructure. The two vendors we looked at closest for IPTel were Cisco and Avaya. Cisco is very open standards based in terms of Network Protocols and Cisco tends to drive the industry for new and emerging protocols. BUT their call managers and voice mail servers run on Windows (ugh) and Compaq servers (double ugh). Avaya, on the other hand, is pretty proprietary in terms of protocols and is in trouble financially and market share wise. BUT their call managers run on Linux. Finally we chose Cisco because we felt that the protocol side of this was more important than a couple of call manager servers that we can replace in the future if need be.

For more on SIP, please see:

• SIP tutorial
• Some Open Source SIP software
• More Open Source SIP-capable software

For more on SIP, please see:

• SIP tutorial
• Some Open Source SIP software
• More Open Source SIP-capable software

Please read the usage scenarios in this Internet Draft if you don't know what ENUM is about.

iptel.org has a pretty comprehensive list of the softphones that are currently available. A number of IM clients (Yahoo, AIM, MSN) also support voice chat, but some of them had trouble going through NAT the last time I checked. The IM clients also require about two or three clicks before you can start talking to each other, so they might not be the easiest solution for intercom usage.

If you want to implement a VoIP system, there is a bunch of open source software at www.vovida.org that was put there to help make things like this happen.

<blatant ad>
There is SIP proxies and registrars, B2BUA for prepaid billing, MGCP to SIP translators, H.323 to SIP translators, voice mail system, SIP, RTSP, OSP, COPS, TRIP, RTP, RADIUS and MGCP stacks, and much more. It has been tested with phones and gateways from almost all major vendors and most of the smaller SIP vendors. It can be set up in with no single point of failure and has been tested up too 500 calls per seconds (that's a lot per day - you do the math)
</blatant ad>

There is also some good infromation at www.iptel.org