VoIP Infodump ============= Compiled by Kadin2048 Current as of June 2008 NOTE: Sections are delimited by ASCII page-break characters. Terminology ----------- ATA - Analog Telephone Adapter. A hardware interface that connects an analog telephone device to a VoIP network. DID - Direct Inward Dialing, basically a POTS telephone number. In order to receive calls from the POTS network on a VoIP line, you need to purchase DID service. H.323 - Another VoIP establishment protocol, widely deployed. Standardized by the ITU. Religious wars exist between SIP and H.323 proponents. IAX - Inter-Asterisk eXchange, another protocol for VoIP. Mostly used for trunk connections. Media - Within the context of VoIP, means the actual voice data stream. RTP - Protocol for "real time transport", i.e. actually sending voice data down the wire. Can employ any of many different codecs. Used for media transport by both H.323 and SIP. SIP - Session Initiation Protocol, a protocol for establishing and negotiating VoIP connections. Used to connect many handsets and ATAs. Standardized by the IETF. Termination - Typically refers to the act of interfacing outgoing calls from the Internet to the POTS network. If you want to make outgoing calls, you need to pay for termination service. VoIP - Voice over Internet Protocol VoIP Protocols -------------- "VoIP" covers any method of sending voice over IP, but mainly we're interested in the more common implementations: * Skype Proprietary, walled-garden service using a non-standard protocol. Offers decent audio quality and excellent at punching through firewalls and coping with less-than-ideal connections. Allegedly encrypted, but the implementation details are not public -- i.e. possible snake oil / backdoor warning. You're limited to talking to other Skype members, or connecting to the POTS network using Skype's "SkypeIn" and "SkypeOut". Skype used to be purely a softphone, but increasingly there's hardware available for it, including ATAs and IP/Ethernet phones. However, these devices can't be used for anything except Skype. Skype uses a protocol stack that's (apparently?) completely proprietary, including for call setup, media transport, encryption, signaling, etc. They probably use some of the same audio codecs as other protocols, but since it doesn't interoperate with anyone else except through the POTS, it doesn't really matter. * SIP The Session Initiation Protocol is the IETF's attempt at defining a protocol for VoIP. The protocol mainly concerns itself with initiating a "session" between two points; the data that's transmitted (aka the "media") isn't of much concern. SIP uses one UDP port for signaling, connected from the caller to the called party (or server, or whatever). Then the called party opens a second UDP port back to the caller, in order to create the media connection. This is a nice, technically simple implementation, and thus SIP is fairly popular with low-cost handsets and ATAs, but it's nothing but trouble when NAT is involved. Within a LAN it tends to work well; across the IPv4 Internet it's a real pain and requires crappy hacks like STUN to get working right. Theoretically, most of SIP's weaknesses would be eliminated by a transition to IPv6 and an elimination of NAT, but don't hold your breath. Many people seem to use SIP for communication within a LAN, e.g. from handsets to a central server, and then use a more robust protocol like IAX for transit across the public net. There's a very good tutorial on SIP here (ignore that it's Geocities, really): * SIP Implementations * Lots! Both for softphones, ATAs, and IP phones. Practically any low-cost consumer gear that's not Skype-specific is most likely SIP. (The most frequently encountered exceptions are refurb'ed Cisco stuff that uses proprietary SCCP, although even most Cisco phones can be reprogrammed to use SIP instead.) * H.323 The ITU's attempt at creating a standard for VoIP. Widely deployed, although there seems to be less low-cost hardware that uses it as a native protocol. Designed by "telephony people" as opposed to "Internet people". H.323 is agnostic to the media being transmitted, and can be used to set up video in addition to voice calls, if the endpoints support it. Some video-conferencing systems use H.323 for this purpose. It can even be used for "data conferencing", i.e. whiteboarding. * H.323 Implementations * According to Wikipedia, most of the 3G mobile network currently deployed or being deployed use variations of H.323 * Cisco ATA-186 analog telephone adapter * The "OPAL" project on Linux * Further Reading: * H.323 versus SIP: A Comparison Very pro-H.323, somewhat anti-SIP, but not unreasonable. * Various Open-Source projects relating to H.323 * IAX Yet another VoIP protocol. IAX (technically "IAX2") was designed concurrently with the Asterisk open-source PBX system, and it's meant for connecting multiple digital PBXes together (trunking). IAX has several significant advantages over SIP, the main one being that it uses a single UDP connection on a known port for all data, with in-band signaling, rather than separate signal/media connections. This makes NAT traversal easy. It also has a better jitter buffer than most SIP implementations, although this isn't really an architectural difference. A single IAX connection may contain lots of concurrent calls and signalling information, and may use many different codecs for the actual media transmission. IAX is rarely (never?) used as a native protocol by any low-cost endpoint hardware (e.g. ATAs, IP phones, etc.). In its role as a trunk connection between PBXes, its major competitors are the proprietary Cisco protocols used by their hardware devices, but it seems to be gaining ground. There's a draft IETF spec for it. Many DID/termination providers support all three major protocols: SIP, H.323, and IAX. * IAX Implementations: * Asterisk Open-Source PBX Basics of a small VoIP system ----------------------------- In order to use VoIP you need some sort of client device, something that serves as a "telephone." This can either be an actual analog telephone connected to an ATA, or it can be a softphone program running on a PC, with a microphone and headset. Then, you need to arrange for both DID (inbound) and termination (outbound) service, from a VoIP provider. Typically, DID service has a monthly fee plus a per-minute charge, while termination is only per-minute, unless you buy a bulk plan with lots of minutes or unlimited calling. It's possible to buy a DID number anywhere you want; it could even be in a different country. Unlike with regular POTS lines, you don't have to get both DID and termination if you only want calls in one direction -- you can purchase just DID and only be able to receive calls, or only termination and only originate them. With that arranged, you can either connect the endpoint device (ATA or softphone) directly to the VoIP provider's servers, or you can connect the endpoint to a local server, and then have the server connect to the VoIP provider. The advantage of the latter route is the ability to use a different protocol for connecting to the VoIP provider than the endpoint device supports. E.g., if you have a low-cost ATA that only supports SIP, you could connect the ATA to a server on the LAN running Asterisk, and then have the Asterisk server connect to the VoIP provider via IAX. This avoids the NAT traversal hell that is SIP, except on the LAN where it doesn't matter. This doesn't add a lot of overhead, as long as there's no transcoding required by the server: you want to make sure that the codec selected by the endpoint is one of the codecs that's accepted by the VoIP provider; otherwise, the server will have to transcode the audio stream in real-time, and that can get messy. Setting up an Asterisk PBX is a lot more complicated than just setting up an ATA or softphone, but it offers a lot more features and flexibility. It also lets you run your own call-recording and voicemail. Basically, you get to be your own little phone company! VoIP Service Providers ---------------------- * Les.net Looks pretty tempting overall. They're located in Canada and cater to DIYers and other people who know what they're doing. All their prices are listed in Canadian, not US, dollars. There is apparently a billing/payment fee that's not listed on the website, if payment is rendered in USD. Cf.: Servers are physically located in Winnipeg, Canada. This may not be advantageous, in terms of latency/ping. Les offers IAX, SIP, and H.323 protocols for incoming/outgoing, although with IAX they offer fewer codec choices. * DID Numbers USA DIDs are $3.99/mo for unlimited incoming minutes, OR $0.99/mo and $0.011/min. In other words, the per-minute one is best if you're going to be under 272 minutes of incoming calls per month; the flat-rate is better if you're above that. Information on DIDs: * Termination Termination to CONUS and Canada is $0.015/min, no setup or monthly fee. Information on Termination: * CallCentric Recommended by some people on the PBXInAFlash forum as an alternative/competitor to Les.Net for low-cost VoIP: Unfortunately, since they're US-based, they have to charge an "E911 Cost Recovery Fee" to all US DID customers. They offer SIP 2.0 only, no IAX. Voice codecs supported are G.711 and G.729. See: They offer a STUN server for assistance in traversing NAT. For fax, they offer T.38 fax handling, both incoming and outgoing, if your hardware supports it. Alternately, they will receive faxes for you and let you download as PDFs. See: The support area of their website seems pretty decent and has specific information for a large number of common ATAs and softphones, including the Linksys PAP-2 and similar. Sample dial plans are given. Linksys PAP-2 (and similar Sipura) setup guide: * DID Numbers Currently running a "Dirt Cheap DIDs" promotion for some US area codes and exchanges. Not all ACs/Exchanges are available. Many major E. Coast metro areas seem to have numbers in surrounding areas available, however. Residential-use DID is $2.95/mo with unlimited incoming minutes, for the "overstock" numbers (selected areas); for regular numbers it's $5.95/mo. All DIDs have an additional mandatory E911 "cost recovery" fee; this is $2.03 to setup and $2.37/mo on each account. (Not clear whether accounts with multiple DIDs get hit with multiple fees.) Total would be $2.03 setup and $5.37/mo continuously. * Termination On the "Pay per call" plan, all calls to the US are $0.0198. A $5 minimum deposit is required to start an account; it's unclear whether that balance must be maintained continuously, or if you can run it down to a few cents and then recharge. Unlimited CONUS calling is $20 a month, which works out to a break-even point of 1,010 minutes per month to make it worthwhile. (That's a little over 30 minutes a day.) NAT Traversal ------------- * IAX NAT Traversal IAX2 is designed to use only a single UDP port, and thus doesn't have too many problems traversing NAT. Like with any other service, you need to open a hole in your firewall and forward that port to your IAX device (Asterisk), if you want to allow inbound connections. (Which you do, if you want to get incoming calls.) * SIP NAT Traversal Traversing NAT with SIP is a real pain, but because SIP hardware and software is so common, it's a frequently-encountered problem, and there are a number of workarounds (if not quite 'solutions'). * Solution 1: Get Rid of NAT One solution would be to avoid the problem altogether: purchase an additional public-facing IP address from your ISP (a static one would be nice but isn't strictly necessary), and attach your VoIP device directly to your broadband modem via a switch, rather than placing it downstream of your existing NAT router. This is the most technically elegant solution; SIP wasn't designed to work with NAT, and by running SIP into and out of a public-facing IP address that's not NATed, you use it as it was intended. No further messing around should be necessary. You also don't have to poke any large holes in the firewall that protects your data network; the outside world would see your SIP gateway, but not the rest of your home LAN, which would be hiding behind a different IP. The major downside of this approach is cost: many residential broadband providers don't offer the ability to purchase more than one concurrent public-facing IP address, so you may have to upgrade to business-class Internet service, or purchase a block of static IPs, which isn't really necessary. * Solution 2: Use STUN The next solution is to use a STUN server to help your SIP device traverse the NAT gateway. Basically, STUN uses a server located outside of your local network to figure out what the limitations of the NAT gateway are. Critical pieces of information are the public-facing IP address used by the gateway, and whether it is a "Symmetric", "Full-Cone", "Restricted Cone" or "Port-Restricted Cone" NAT setup. Basically, these terms define whether port assignments on the public side of the NAT device can be used for inbound communication as well as outbound communication. However, the "-cone" terms don't really describe all NAT devices' behavior; it's possible for a NAT device to act like a "Full-Cone" NAT sometimes, and like a "Port-Restricted Cone" in others; this may lead to intermittent connectivity problems. Most SIP devices (ATAs and softphones) have an entry for the VoIP provider's STUN server, and will attempt to use STUN to traverse NAT if it's available. If it works, this is probably the easiest way to get SIP across a NAT. Even with STUN, it's still possible for SIP to not work across a NAT; in this case, one of the other solutions needs to be used. Typically, when STUN doesn't work, it's because the NAT in use is Symmetric, and you can't traverse symmetric NAT with SIP. Information: * Solution 3: Use the DMZ The next solution is a relatively simple one: put the SIP device in the LAN's "DMZ", where all incoming traffic not associated to another internal device will be routed by default. This basically puts the SIP device outside the NAT barrier, and should eliminate all traversal-related problems. However, it has several disadvantages: First, it can only be used for one SIP device. This means if you have multiple devices on the LAN (multiple ATAs, or a combination of ATAs, IP phones, and softphones), you'll need to have a SIP proxy server that they all connect to, and then put the proxy server in the DMZ. Second, it's somewhat insecure. By putting a device in the DMZ, you may open it to outside attack; since the device is still inside the home LAN as well, you may be creating an avenue for outsiders to infiltrate your network. This seems like a significant drawback given that your control over the software running on an ATA or IP phone is limited, and thus your ability to properly secure it is as well. Third, it prevents you from using your router's DMZ feature for anything except the SIP device. If you need to use the DMZ for some other purpose (some online games, or other applications that dislike NAT), you'll have to give up your phone service until you're done and can re-DMZ the SIP device.