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