<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>VoIP Protocols</title><link rel="stylesheet" href="styles.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.69.1" /><link rel="start" href="index.html" title="Asterisk™: The Future of Telephony" /><link rel="up" href="asterisk-CHP-8.html" title="Chapter 8. Protocols for VoIP" /><link rel="prev" href="asterisk-CHP-8-SECT-1.html" title="The Need for VoIP Protocols" /><link rel="next" href="asterisk-CHP-8-SECT-3.html" title="Codecs" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">VoIP Protocols</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="asterisk-CHP-8-SECT-1.html">Prev</a> </td><th width="60%" align="center">Chapter 8. Protocols for VoIP</th><td width="20%" align="right"> <a accesskey="n" href="asterisk-CHP-8-SECT-3.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="asterisk-CHP-8-SECT-2"></a>VoIP Protocols</h2></div></div></div><p>The mechanism for carrying a VoIP connection generally involves a
series of signaling transactions between the endpoints (and gateways in
between), culminating into 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.</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="asterisk-CHP-8-SECT-2.1"></a>IAX (The “Inter-Asterisk eXchange” Protocol)</h3></div></div></div><p>If you claim<a id="I_indexterm8_tt1091" class="indexterm"></a> to be one of the folks in the know when it comes to
Asterisk, your test will come when you have to pronounce the name of
this protocol. It would seem that you should say “eye-ay-ex”, but this
hardly rolls off the tongue very well.<sup>[<a id="id4139219" href="#ftn.id4139219">102</a>]</sup> Fortunately, the proper pronunciation is in fact
“eeks.”<sup>[<a id="id4139225" href="#ftn.id4139225">103</a>]</sup> IAX is an open protocol, meaning that anyone can download
and develop for it, but it is not yet a standard of any kind.<sup>[<a id="asterisk-CHP-8-FN-2" href="#ftn.asterisk-CHP-8-FN-2">104</a>]</sup></p><p>It is expected that IAX2 will become an IETF <a id="I_indexterm8_tt1092" class="indexterm"></a>protocol soon. IAX2 is currently in draft status with the
IETF, and it is widely expected to become an official protocol in a few
years’ time.</p><p>In Asterisk, IAX is supported by the
<span class="emphasis"><em>chan_iax2.so</em></span> module.</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.1.1"></a>History</h4></div></div></div><p>The IAX protocol was developed by Digium for the purpose of
communicating with other Asterisk servers (hence the Inter-Asterisk
eXchange protocol). It is very important to note that IAX is not at
all limited to Asterisk. The standard is open for anyone to use, and
it is supported by many other open source telecom projects, as well as
by several hardware vendors. IAX is a transport protocol (much like
SIP) that uses a single UDP port (4569) for both the channel signaling
and media streams. As discussed later in this chapter, this makes it
easier to manage when behind<a id="I_indexterm8_tt1093" class="indexterm"></a> NATed firewalls.</p><p>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 media streams to be represented with a single datagram
header, that will lower the overhead associated with individual
<span class="keep-together">channels</span>. 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. If you have a large quantity of IP
calls to pass between two endpoints, you should take a close look at
IAX trunking.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.1.2"></a>Future</h4></div></div></div><p>Since IAX was optimized for voice, it has received some
criticism for not better supporting video—but 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.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.1.3"></a>Security considerations</h4></div></div></div><p>IAX includes the ability to authenticate in three ways: plain
text, <a id="I_indexterm8_tt1094" class="indexterm"></a>MD5 hashing, and RSA key exchange. <a id="I_indexterm8_tt1095" class="indexterm"></a>This, of course, does nothing to encrypt the media path
or headers between endpoints. Many solutions include using a<a id="I_indexterm8_tt1096" class="indexterm"></a><a id="I_indexterm8_tt1097" class="indexterm"></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. However, IAX is now also able to encrypt the streams
between endpoints with dynamic key exchange at call setup (using the
configuration option <code class="literal">encryption=aes128</code>), allowing the use of
automatic key rollover.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.1.4"></a>IAX and NAT</h4></div></div></div><p>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.</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="asterisk-CHP-8-SECT-2.2"></a>SIP</h3></div></div></div><p>The <a id="ch08_sip" class="indexterm"></a>Session Initiation Protocol (SIP) has taken the
telecommunications industry by storm. SIP has pretty much dethroned the
once-mighty <span class="keep-together">H.323</span> as the VoIP
protocol of choice—certainly at the endpoints of the network. The
premise of SIP is that each end of a connection is a peer; 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<a id="I_indexterm8_tt1098" class="indexterm"></a> <span class="emphasis"><em>chan_sip.so</em></span> module.<sup>[<a id="id4139469" href="#ftn.id4139469">105</a>]</sup></p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.2.1"></a>History</h4></div></div></div><p>SIP was originally submitted to the <a id="I_indexterm8_tt1099" class="indexterm"></a><a id="I_indexterm8_tt1100" class="indexterm"></a>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.</p><p>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.</p><p>SIP is an application-layer signaling protocol that uses the
well-known port 5060 for communications. SIP can be transported with
either the UDP or TCP transport-layer protocols. Asterisk does not
currently have a TCP implementation for transporting SIP messages, but
it is possible that future versions may support it (and patches to the
code base are gladly accepted). SIP is used to “establish, modify, and
terminate multimedia sessions such as Internet telephony
calls.”<sup>[<a id="asterisk-CHP-4-FN-8" href="#ftn.asterisk-CHP-4-FN-8">106</a>]</sup></p><p>SIP does not transport media between <span class="keep-together">endpoints</span>.</p><p>RTP is used to transmit media (i.e., voice) between endpoints.
RTP uses high-numbered, unprivileged ports in Asterisk (10,000 through
20,000, by default).</p><p>A common topology to illustrate SIP and RTP, commonly referred
to as<a id="I_indexterm8_tt1101" class="indexterm"></a><a id="I_indexterm8_tt1102" class="indexterm"></a> the “SIP trapezoid,” is shown in <a href="asterisk-CHP-8-SECT-2.html#asterisk-CHP-8-FIG-1" title="Figure 8.1. The SIP trapezoid">Figure 8.1, “The SIP trapezoid”</a>. When Alice wants to call Bob,
Alice’s phone contacts her proxy server, and the proxy tries to find
Bob (often connecting through his proxy). Once the phones have started
the call, they communicate directly with each other (if possible), so
that the data doesn’t have to tie up the resources of the
proxy.</p><div class="figure"><a id="asterisk-CHP-8-FIG-1"></a><p class="title"><b>Figure 8.1. The SIP trapezoid</b></p><div class="mediaobject"><a id="I_mediaobject8_tt1103"></a><img src="figs/web/ast2_0801.png" alt="The SIP trapezoid" /></div></div><p>SIP was not the first, and is not the only, VoIP protocol in use
today (others include H.323, MGCP, IAX, and so on), but currently it
seems to have the most momentum with hardware vendors. The advantages
of the SIP protocol lie in its wide acceptance and architectural
flexibility (and, we used to say, simplicity!).</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.2.2"></a>Future</h4></div></div></div><p>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. While its use as a ubiquitous
general-purpose media transport mechanism seems doubtful, SIP is
unarguably poised to deliver the majority of new voice applications
for the next few years.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.2.3"></a>Security considerations</h4></div></div></div><p>SIP uses a challenge/response system to authenticate users. An
initial <code class="literal">INVITE</code> 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<a id="I_indexterm8_tt1104" class="indexterm"></a> <span class="emphasis"><em>nonce</em></span>. This nonce is used along
with the password to generate an MD5 hash, which is then sent back in
the subsequent <code class="literal">INVITE</code>. Assuming the
MD5 hash matches the one that the proxy generated, the client is then
authenticated.</p><p>Denial of Service (DoS) attacks<a id="I_indexterm8_tt1105" class="indexterm"></a><a id="I_indexterm8_tt1106" class="indexterm"></a> are probably the most common type of attack on VoIP
communications. A DoS attack can occur when a large number of invalid
<code class="literal">INVITE</code> requests<a id="I_indexterm8_tt1107" class="indexterm"></a> 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.</p><p>SIP implements a scheme to guarantee that a secure, encrypted
transport mechanism <a id="I_indexterm8_tt1108" class="indexterm"></a><a id="I_indexterm8_tt1109" class="indexterm"></a>(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.</p><p>More information regarding SIP security considerations,
including registration hijacking, server impersonation, and session
teardown, can be found in Section 26 of SIP RFC 3261.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.2.4"></a>SIP and NAT</h4></div></div></div><p>Probably the biggest technical <a id="I_indexterm8_tt1110" class="indexterm"></a><a id="I_indexterm8_tt1111" class="indexterm"></a>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 automatically
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. Newer firewalls and
Session Border Controllers are SIP-aware, but this is still considered
a shortcoming in this protocol, and it causes no end of trouble to
network professionals needing to connect SIP endpoints using existing
network infrastructure.<a id="I_indexterm8_tt1112" class="indexterm"></a></p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="asterisk-CHP-8-SECT-2.3"></a>H.323</h3></div></div></div><p>This<a id="I_indexterm8_tt1113" class="indexterm"></a><a id="I_indexterm8_tt1114" class="indexterm"></a><a id="I_indexterm8_tt1115" class="indexterm"></a> 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 favor of IAX and SIP. H.323 has not enjoyed much success
among users and enterprises, although it might still be the most widely
used VoIP protocol among carriers.</p><p>The three versions of H.323 supported in Asterisk are handled by
the<a id="I_indexterm8_tt1116" class="indexterm"></a> modules <code class="filename">chan_h323.so</code>
(supplied with Asterisk), <code class="filename">chan_oh323.so</code> (available as a free add-on),
and <code class="filename">chan_ooh323.so</code> (supplied in
asterisk-addons).</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title"><a id="asterisk-CHP-8-NOTE-43"></a>Tip</h3><p>You have probably used H.323 without even knowing
it—Microsoft’s<a id="I_indexterm8_tt1117" class="indexterm"></a> NetMeeting <a id="I_indexterm8_tt1118" class="indexterm"></a>client is arguably the most widely deployed H.323
client.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.3.1"></a>History</h4></div></div></div><p>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.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.3.2"></a>Future</h4></div></div></div><p>The future of H.323 is a subject of 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 often regarded as
technically superior to SIP, but, as with so many other technologies,
that sort of thing is seldom the deciding factor in whether technology
enjoys success. One of the factors that makes H.323 unpopular is its
complexity—although many argue that the once-simple SIP is starting to
suffer from the same problem.</p><p>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.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.3.3"></a>Security considerations</h4></div></div></div><p>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.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.3.4"></a>H.323 and NAT</h4></div></div></div><p>The H.323 standard uses the Internet Engineering Task Force
(IETF) <a id="I_indexterm8_tt1119" class="indexterm"></a>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.</p><p>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 Microsoft
NetMeeting, will also require TCP ports forwarded for H.245 tunneling
(again, see your client’s manual for the port number range).</p><p>If you have a number of clients behind the NAT device, you will
need to use <a id="I_indexterm8_tt1120" class="indexterm"></a>a <span class="emphasis"><em>gatekeeper</em></span> 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.</p><p>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<a id="I_indexterm8_tt1121" class="indexterm"></a> OpenH323 Gatekeeper (<a href="http://www.gnugk.org" target="_top">http://www.gnugk.org</a>).</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="asterisk-CHP-8-SECT-2.4"></a>MGCP</h3></div></div></div><p>The <a id="I_indexterm8_tt1122" class="indexterm"></a><a id="I_indexterm8_tt1123" class="indexterm"></a>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.</p><p>MGCP is defined in RFC 3435.<sup>[<a id="asterisk-CHP-8-FN-3" href="#ftn.asterisk-CHP-8-FN-3">107</a>]</sup> 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.</p><p>Asterisk supports MGCP through the
<span class="emphasis"><em>chan_mgcp.so</em></span> module, and the endpoints are defined
in the configuration file <span class="emphasis"><em>mgcp.conf</em></span>. 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).</p><p>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.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="asterisk-CHP-8-SECT-2.5"></a>Proprietary Protocols</h3></div></div></div><p>Finally, let’s take a look at two<a id="I_indexterm8_tt1124" class="indexterm"></a> proprietary protocols that are supported in
Asterisk.</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.5.1"></a>Skinny/SCCP</h4></div></div></div><p>The Skinny<a id="I_indexterm8_tt1125" class="indexterm"></a><a id="I_indexterm8_tt1126" class="indexterm"></a> Client Control Protocol (SCCP) is proprietary to
<a id="I_indexterm8_tt1127" class="indexterm"></a>Cisco VoIP equipment. It is the default protocol for
endpoints on a <a id="I_indexterm8_tt1128" class="indexterm"></a>Cisco Call Manager PBX.<sup>[<a id="id4140274" href="#ftn.id4140274">108</a>]</sup> 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.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-2.5.2"></a>UNISTIM</h4></div></div></div><p>Support for Nortel’s proprietary VoIP protocol,<a id="I_indexterm8_tt1129" class="indexterm"></a> UNISTIM, 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. UNISTIM support is totally
experimental, and does not work well enough to put into production,
but the fact that somebody took the trouble to do this demonstrates
the power of the Asterisk platform.</p></div></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.id4139219" href="#id4139219">102</a>] </sup>It sounds like the name of a Dutch football team.</p></div><div class="footnote"><p><sup>[<a id="ftn.id4139225" href="#id4139225">103</a>] </sup>Go ahead. Say it. Now that sounds much better, doesn’t
it?</p></div><div class="footnote"><p><sup>[<a id="ftn.asterisk-CHP-8-FN-2" href="#asterisk-CHP-8-FN-2">104</a>] </sup>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 same version.</p></div><div class="footnote"><p><sup>[<a id="ftn.id4139469" href="#id4139469">105</a>] </sup>Having just called SIP simple, it should be noted that it is
by no means lightweight. It has been said that if one were to read
all of the IETF RFCs that are relevant to SIP, one would have more
than 3,000 pages of reading to do. SIP is quickly earning a
reputation for being far too bloated, but that does nothing to
lessen its popularity.</p></div><div class="footnote"><p><sup>[<a id="ftn.asterisk-CHP-4-FN-8" href="#asterisk-CHP-4-FN-8">106</a>] </sup>RFC 3261, SIP: Session Initiation Protocol, p. 9, Section
2.</p></div><div class="footnote"><p><sup>[<a id="ftn.asterisk-CHP-8-FN-3" href="#asterisk-CHP-8-FN-3">107</a>] </sup>RFC 3435 obsoletes RFC 2705.</p></div><div class="footnote"><p><sup>[<a id="ftn.id4140274" href="#id4140274">108</a>] </sup>Cisco has recently announced that it will be migrating
toward SIP in its future products.</p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="asterisk-CHP-8-SECT-1.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="asterisk-CHP-8.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="asterisk-CHP-8-SECT-3.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">The Need for VoIP Protocols </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Codecs</td></tr></table></div><div xmlns="" id="svn-footer"><hr /><p>You are reading <em>Asterisk: The Future of Telephony</em> (2nd Edition for Asterisk 1.4), by Jim van Meggelen, Jared Smith, and Leif Madsen.<br />
This work is licensed under the <a href="http://creativecommons.org/licenses/by-nc-nd/3.0/">Creative Commons Attribution-Noncommercial-No Derivative Works License v3.0</a>.<br />
To submit comments, corrections, or other contributions to the text, please visit <a href="http://oreilly.com/catalog/9780596510480/">http://www.oreilly.com/</a>.</p></div></body></html>
