Section 8.2. VoIP Protocols

8.2. VoIP Protocols

The mechanism for carrying a VoIP connection generally involves a series of signaling transactions between the endpoints (and gateways in between), culminating in two persistent media streams (one for each direction) that carry the actual conversation. There are several protocols in existence to handle this. In this section, we will discuss some of those that are important to VoIP in general and to Asterisk specifically .

8.2.1. IAX (The "Inter-Asterisk eXchange" Protocol)

The test of your Asterisk-ness comes when you have to pronounce the name of this protocol. Newbies say "eye-ay-ex"; those in the know say "eeks." IAX ^[*] is an open protocol, meaning that anyone can download and develop for it, but it is not yet a standard of any kind.

^[*] Officially, the current version is IAX2, but all support for IAX1 has been dropped, so whether you say "IAX" or "IAX2," it is expected that you are talking about the Version 2.

In Asterisk, IAX is supported by the chan_iax2.so module.

8.2.1.1. History

The IAX protocol was developed by Digium for the purpose of communicating with other Asterisk servers (hence "the Inter-Asterisk eXchange protocol"). IAX is a transport protocol (much like SIP) that uses a single UDP port (4569) for both the channel signaling and Realtime Transport Protocol (RTP) streams. As discussed below, this makes it easier to firewall and more likely to work behind NAT.

IAX also has the unique ability to trunk multiple sessions into one dataflow, which can be a tremendous bandwidth advantage when sending a lot of simultaneous channels to a remote box. Trunking allows multiple data streams to be represented with a single datagram header, to lower the overhead associated with individual channels. This helps to lower latency and reduce the processing power and bandwidth required, allowing the protocol to scale much more easily with a large number of active channels between endpoints.

8.2.1.2. Future

Since IAX was optimized for voice, it has received some criticism for not better supporting videobut in fact, IAX holds the potential to carry pretty much any media stream desired. Because it is an open protocol, future media types are certain to be incorporated as the community desires them.

8.2.1.3. Security considerations

IAX includes the ability to authenticate in three ways: plain text, MD5 hashing, and RSA key exchange. This, of course, does nothing to encrypt the media path or headers between endpoints. Many solutions include using a Virtual Private Network (VPN) appliance or software to encrypt the stream in another layer of technology, which requires the endpoints to pre-establish a method of having these tunnels configured and operational. In the future, IAX may be able to encrypt the streams between endpoints with the use of an exchanged RSA key, or dynamic key exchange at call setup, allowing the use of automatic key rollover. This would be very attractive for creating a secure link with an institution such as your bank. The various law enforcement agencies, however, are going to want some level of access to such connections.

8.2.1.4. IAX and NAT

The IAX2 protocol was deliberately designed to work from behind devices performing NAT. The use of a single UDP port for both signaling and transmission of media also keeps the number of holes required in your firewall to a minimum. These considerations have helped make IAX one of the easiest protocols (if not the easiest ) to implement in secure networks.

8.2.2. SIP

The Session Initiation Protocol (SIP) has taken the world of VoIP by storm . Originally considered little more than an interesting idea, SIP now seems poised to dethrone the mighty H.323 as the VoIP protocol of choicecertainly at the endpoints of the network. The premise of SIP is that each end of a connection is a peer, and the protocol negotiates capabilities between them. What makes SIP compelling is that it is a relatively simple protocol, with a syntax similar to that of other familiar protocols such as HTTP and SMTP.

SIP is supported in Asterisk with the chan_sip.so module.

8.2.2.1. History

SIP was originally submitted to the Internet Engineering Task Force (IETF) in February of 1996 as "draft-ietf-mmusic-sip-00." The initial draft looked nothing like the SIP we know today and contained only a single request type: a call setup request. In March of 1999, after 11 revisions, SIP RFC 2543 was born.

At first, SIP was all but ignored, as H.323 was considered the protocol of choice for VoIP transport negotiation. However, as the buzz grew, SIP began to gain popularity, and while there may be a lot of different factors that accelerated its growth, we'd like to think that a large part of its success is due to its freely available specification.

8.2.2.2. Future

SIP has earned its place as the protocol that justified VoIP. All new user and enterprise products are expected to support SIP, and any existing products will now be a tough sell unless a migration path to SIP is offered . SIP is widely expected to deliver far more than VoIP capabilities, including the ability to transmit video, music, and any type of real-time multimedia. SIP is poised to deliver the majority of new applications over the next few years .

8.2.2.3. Security considerations

SIP uses a challenge/response system to authenticate users. An initial INVITE is sent to the proxy with which the end device wishes to communicate. The proxy then sends back a 407 Proxy Authorization Request message, which contains a random set of characters referred to as a "nonce ." This nonce is used along with the password to generate an MD5 hash, which is then sent back in the subsequent INVITE . Assuming the MD5 hash matches the one that the proxy generated, the client is then authenticated.

Denial of Service (DoS) attacks are probably the most common type of attack on VoIP communications. A DoS attack can occur when a large number of invalid INVITE requests are sent to a proxy server in an attempt to overwhelm the system. These attacks are relatively simple to implement, and their effects on the users of the system are immediate. SIP has several methods of minimizing the effects of DoS attacks, but ultimately they are impossible to prevent.

SIP implements a scheme to guarantee that a secure, encrypted transport mechanism (namely Transport Layer Security, or TLS) is used to establish communication between the caller and the domain of the callee. Beyond that, the request is sent securely to the end device, based upon the local security policies of the network. Note that the encryption of the media (that is, the RTP stream) is beyond the scope of SIP itself and must be dealt with separately.

More information regarding SIP security considerations, including registration hijacking, server impersonation, and session teardown , can be found in Section 26 of SIP RFC 3261.

8.2.2.4. SIP and NAT

Probably the biggest technical hurdle SIP has to conquer is the challenge of carrying out transactions across a NAT layer. Because SIP encapsulates addressing information in its data frames , and NAT happens at a lower network layer, the addressing information is not modified, and thus the media streams will not have the correct addressing information needed to complete the connection when NAT is in place. In addition to this, the firewalls normally integrated with NAT will not consider the incoming media stream to be part of the SIP transaction, and will block the connection.

8.2.3. H.323

This International Telecommunication Union (ITU) protocol was originally designed to provide an IP transport mechanism for video-conferencing. It has become the standard in IP-based video-conferencing equipment, and it briefly enjoyed fame as a VoIP protocol as well. While there is much heated debate over whether SIP or H.323 (or IAX) will dominate the VoIP protocol world, in Asterisk, H.323 has largely been deprecated in favour of IAX and SIP. H.323 has not enjoyed much success among users and enterprises , although it is still the most widely used VoIP protocol among carriers .

The two versions of H.323 supported in Asterisk are handled by the modules chan_h323.so (supplied with Asterisk) and chan_oh323.so (available as a free add-on).

You have probably used H.323 without even knowing itMicrosoft's NetMeeting client is arguably the most widely deployed H.323 client.

8.2.3.1. History

H.323 was developed by the ITU in May of 1996 as a means to transmit voice, video, data, and fax communications across an IP-based network while maintaining connectivity with the PSTN. Since that time, H.323 has gone through several versions and annexes (which add functionality to the protocol), allowing it to operate in pure VoIP networks and more widely distributed networks.

8.2.3.2. Future

The future of H.323 is a subject of hot debate. If the media is any measure, it doesn't look good for H.323; it hardly ever gets mentioned ( certainly not with the regularity of SIP). H.323 is commonly regarded as technically superior to SIP, but, as with so many other technologies, that ultimately might not matter. One of the factors that makes H.323 unpopular is its complexityalthough many argue that the once-simple SIP is starting to suffer from the same problem.

H.323 still carries by far the majority of worldwide carrier VoIP traffic, but as people become less and less dependent on traditional carriers for their telecom needs, the future of H.323 becomes more difficult to predict with any certainty . While H.323 may not be the protocol of choice for new implementations , we can certainly expect to have to deal with H.323 interoperability issues for some time to come.

8.2.3.3. Security considerations

H.323 is a relatively secure protocol and does not require many security considerations beyond those that are common to any network communicating with the Internet. Since H.323 uses the RTP protocol for media communications, it does not natively support encrypted media paths. The use of a VPN or other encrypted tunnel between endpoints is the most common way of securely encapsulating communications. Of course, this has the disadvantage of requiring the establishment of these secure tunnels between endpoints, which may not always be convenient (or even possible). As VoIP becomes used more often to communicate with financial institutions such as banks, we're likely to require extensions to the most commonly used VoIP protocols to natively support strong encryption methods.

8.2.3.4. H.323 and NAT

The H.323 standard uses the Internet Engineering Task Force (IETF) RTP protocol to transport media between endpoints. Because of this, H.323 has the same issues as SIP when dealing with network topologies involving NAT. The easiest method is to simply forward the appropriate ports through your NAT device to the internal client.

To receive calls, you will always need to forward TCP port 1720 to the client. In addition, you will need to forward the UDP ports for the RTP media and RTCP control streams (see the manual for your device for the port range it requires). Older clients , such as MS Netmeeting, will also require TCP ports forwarded for H.245 tunneling (again, see your client's manual for the port number range).

If you have a number of clients behind the NAT device, you will need to use a gatekeeper running in proxy mode. The gatekeeper will require an interface attached to the private IP subnet and the public Internet. Your H.323 client on the private IP subnet will then register to the gatekeeper, which will proxy calls on the clients' behalf . Note that any external clients that wish to call you will also be required to register with the proxy server.

At this time, Asterisk can't act as an H.323 gatekeeper. You'll have to use a separate application, such as the open source OpenH323 Gatekeeper (http://www.gnugk.org).

8.2.4. MGCP

The Media Gateway Control Protocol (MGCP) also comes to us from the IETF. While MGCP deployment is more widespread than one might think, it is quickly losing ground to protocols such as SIP and IAX. Still, Asterisk loves protocols, so naturally it has rudimentary support for it.

MGCP is defined in RFC 3435. ^[*] It was designed to make the end devices (such as phones) as simple as possible, and have all the call logic and processing handled by media gateways and call agents . Unlike SIP, MGCP uses a centralized model. MGCP phones cannot directly call other MGCP phones; they must always go through some type of controller.

^[*] RFC 3435 obsoletes RFC 2705.

Asterisk supports MGCP through the chan_mgcp.so module, and the endpoints are defined in the configuration file mgcp.conf . Since Asterisk provides only basic call agent services, it cannot emulate an MGCP phone (to register to another MGCP controller as a user agent, for example).

If you have some MGCP phones lying around, you will be able to use them with Asterisk. If you are planning to put MGCP phones into production on an Asterisk system, keep in mind that the community has moved on to more popular protocols, and you will therefore need to budget your software support needs accordingly . If possible (for example, with Cisco phones), you should upgrade MGCP phones to SIP.

8.2.5. Proprietary Protocols

Finally, let's take a look at two proprietary protocols that are supported in Asterisk.

8.2.5.1. Skinny/SCCP

The Skinny Client Control Protocol (SCCP) is proprietary to Cisco VoIP equipment. It is the default protocol for endpoints on a Cisco Call Manager PBX. Skinny is supported in Asterisk, but if you are connecting Cisco phones to Asterisk, it is generally recommended that you obtain SIP images for any phones that support it and connect via SIP instead.

8.2.5.2. UNISTIM

Support for Nortel's proprietary VoIP protocol, UNISTIM , has recently been added to Asterisk. This remarkable milestone means that Asterisk is the first PBX in history to natively support proprietary IP terminals from the two biggest players in VoIP, Nortel and Cisco.