
VoIP White Paper
300 Main Street • East Rochester, NY 14445 • Toll Free 1-866-ALLWORX • 585-421-3850 • www.allworx.com
© 2006 InSciTek Microsystems, Inc. All rights reserved. Allworx is a registered trademark of InSciTek Microsystems. All other names may be
trademarks or registered trademarks of their respective owners.
Revised: February 8, 2007
Page 12
7.2 Capacity Planning
Using the worst-case measurement of available bandwidth from above, you can calculate the maximum
number of simultaneous calls supported over the Internet connection. This assumes no other Internet activities
are being performed by local users (e.g., Web surfing, e-mail, file transfers, music downloads). Moderate to
heavy use of the Internet connection for other applications will degrade the quality of calls and may
substantially limit the number of calls supported over the link.
Available Bandwidth Simultaneous
G711 Calls
Simultaneous
G729A Calls
128K 1 4
256K 2 8
384K 4 12
512K 5
768K 8
1M 11
7.3 SIP Protocol and NAT Firewalls
The SIP protocol was designed and first implemented before security issues and the necessity for
NAT/Firewalls existed. VoIP applications and the associated SIP and SDP protocols were not designed with
Network Address Translation (NAT) in mind. In fact, SIP/SDP negotiations
are typically broken when a NAT
device exists between the negotiating end-points, so the resulting audio is not available in one or both
directions after a call is set up. While a full discussion of this topic is beyond the scope of this document, the
glossary at the end has a brief description of NAT. Relative to the effect of NAT on VoIP protocols, an
understanding of the basic problem is useful, and is the topic of the remainder of this section.
NAT actually interferes with several different common protocols – SIP/SDP is only one pair of them. NAT
breaks almost all protocols that need to embed IP addresses and/or port numbers in their own protocol
messages. This is best explained through an example: let’s assume two phones are trying to talk to each other
over the Internet. Each phone is behind its own NAT firewall at two different sites and the LAN network
addresses of both sites are 192.168.1.0 with subnet masks of 255.255.255.0. When a call is setup, each
phone is going to report through its SDP information an address of 192.168.1.x (its local IP address and port
number) to the remote party. However, neither end is going to be able to send to the SDP-reported address
and get the intended recipient. In fact, this will be a problem if the LANs had used the same network address or
if they used any non-publicly routable network address. For this example, audio will not flow properly in either
direction using normal SIP/SDP negotiations.
More typically, only one end is directly behind a NAT device, such as when contacting a remote VoIP gateway
that connects to the PSTN. In these cases, audio typically works in one direction but not the other. There are
also problems beyond the basic logical NAT routing issue, even if the IP addresses were right. The firewall
function of the NAT introduces other packet filtering problems – since the whole point of the firewall is to
prevent arbitrary packet data from entering the LAN network. To a simple firewall that’s not tracking all the
Comentários a estes Manuais