Asterisk Secret

Asterisk NAT and Firewall related issues with SIP
1.1 Description of the problem:

Most conventional voip protocols (SIP, h323, …) are not programmed with NAT in mind,
on itself they only carry call signaling (call setup, teardown,… and use RTP to carry the
audio samples.

The signaling usually uses fixed and standardized ports, but the RTP uses random
ports to exchange both call legs (incoming and outgoing audio).

Most firewalls/NATs are unable to link the signalling protocol packets with the audio
packets and are in some cases unable to tell where to send the audio to.

When making a call, everything will seem to go normal, caller id will get passed, ringing
will start, you can pick up and hangup the call, but no audio in one or both directions.
1.2. related asterisk configuration settings:
1.2.1.: sip.conf
port=
The port used by asterisk for the signaling (default=5060)
Bindaddr=
The ip address on the machine asterisk has to bind to, put 0.0.0.0 to bind
to all ports.

Externip=
This is an option that has to be set in the [general] context at sip.conf and
has to be set to either an ip or a hostname (pointing to the external ip on
your NAT device).
If you want to use a dynamic hostname, you will have to reload the
asterisk after every ip change.
e.g. Externip=123.123.123.123
It will set the IP address in the sip address to the external ip instead of the
internal IP.
You should only set it if asterisk is behind a NAT and trying to

communicate with devices outside of the NAT.
Localnet=
This is an option has to be set in the [general] context at sip.conf and has
to be set to the netmask for the private network asterisk is in, this is only
needed when asterisk is behind a NAT and trying to communicate with
devices outside of the NAT.
e.g. localnet=192.168.0.0/255.255.255.0
Nat=
This option determines the type of setting for users trying to connect to an
asterisk server.

Possible values:

a) NAT=Yes, true, y, t, 1, on

All these values have the same behaviour, a combination of the options
Route + rfc3581.

b) Nat=route:

Asterisk will send the audio to the port and ip where its receiving the audio
from. Instead of relying on the addresses in the SIP and SDP messages.
This will only work if the phone behind nat send and receive audio on the
same port and if they send and receive the signaling on the same port.
(The signaling port does not have to be the same as the RTP audio port).

c) NAT=rfc3581

This is the default behaviour, is no nat=… line is found for that user, this is
the option used.

Asterisk will add an rport to the via header of the SIP messages, as
described in rfc3581 (see http://www.faqs.org/rfcs/rfc3581.html), this will
allow a client to request that the server send the response back to the
source IP address and port where the request came from. The "rport"
parameter is analogous to the "received" parameter in the VIA line, except
"rport" contains a port number, not the IP address.

d) NAT=never

This will cause asterisk not to add an rport "rport" in the VIA line of the sip
invite header, as introduced in rfc3581. (see
http://www.faqs.org/rfcs/rfc3581.html) as some sip ua’s seem to have
problems with them. (one of those UAs being the Uniden SIP phone
UIP200 – Olle E. Johanson.)
Qualify=

This option has a double function, it will keep open the NAT translation
binding, and will make sure asterisk doesn’t try to send a call to this phone
if its unreachable.
Possible values:
a) Qualify=yes or qualify=0
These options will use the default value of 2 seconds.
b) Qualify=no
This will disable the checking of the peer.
c) Qualify=”some numeric value
This will set the amount of ms between to checks”
1.2.2.: rtp.conf
Rtpstart=
Takes a numeric value, which is the first port of the port range that can be
used by asterisk to send and receive RTP.
Rtpend=

Takes a numeric value, which is the last port of the port range that can be
used by asterisk to send and receive RTP.
1.3. Different types of NATs and firewalls.
There are several ways UDP might be handled by a specific NAT or firewall
implementations, these are categorized into:
1.3.1 Full Cone NAT

A full cone NAT is one where all requests from the same internal IP
address and port are mapped to the same external IP address and port.
Furthermore, any external host can send a packet to the internal host, by
sending a packet to the mapped external address.
1.3.2 Restricted Cone:
A restricted cone NAT is one where all requests from the same internal IP
address and port are mapped to the same external IP address and port.
Unlike a full cone NAT, an external host (with IP address X) can send a
packet to the internal host only if the internal host had previously sent a
packet to IP address X.
1.3.3 Port Restricted Cone:
A port restricted cone NAT is like a restricted cone NAT, but the restriction
includes port numbers.
Specifically, an external host can send a packet, with source IP
address X and source port P, to the internal host only if the internal host
had previously sent a packet to IP address X and port P.
1.3.4 Symmetric Nat:
A symmetric NAT is one where all requests from the same internal IP
address and port, to a specific destination IP address and port, are
mapped to the same external IP address and port. If the same host sends
a packet with the same source address and port, but to a different
destination, a different mapping is used. Furthermore, only the external
host that receives a packet can send a UDP packet back to the internal
host.

You can find out which one you are using by trying a stun client:
e.g.: http://sourceforge.net/projects/stun/

1.4. Different problems in detail:

1.4.1 Asterisk as a SIP server outside nat, clients on the inside of the NAT.

1) Call coming from behind nat, Asterisk sends audio to a private ip.

If the voip phone does not use STUN or another mechanism to detect its public ip (=the
public ip of the nat firewall) and thus embeds this ip into the the invite message, then
asterisk will try to send its RTP packets to the private ip, and this will be dropped by the
routers, resulting in one way audio.
(The caller wont hear a thing).

This happens when nat=never, or nat=no or nat= rfc3581 is added in sip.conf for this
calling user, regardless of what nat device is used.

2) Call coming from behind nat, Asterisk sends audio to the wrong port.

If the phone was able to detect its public ip and it sends it correctly in the sip invite
header, then asterisk will know what ip to send the rtp to.
But, if a Cone firewall was used, the source port used by the NAT device to send the rtp
to asterisk, does not have to be the same as the original rtp source port, and asterisk
will send it to the original source port, the NAT device will not be able to know where its
supposed to go and will drop the packets.

This will be resolved by setting a nat=route or nat=yes line into sip.conf for that calling
user.

If you have only 1 phone behind nat, you could have a look at what range of RTP ports
that phone is using and use portforwarding on the firewall, in the direction of public ip to
internal network.

If you have multiple phones behind nat, and you can put the range of RTP ports on the
phone, you could use non overlapping RTP ranges in each of the phones, with port
forwarding for each range to the according phone.

Using a symmetric nat would also solve this problem as well as using a STUN server on
the phone (if the phone has it).

3) Call coming from Asterisk outside the nat with a Full Cone Nat.

Without the sip phone registering to Asterisk or the ip of the NAT device in SIP.conf, the
asterisk server has no idea where to look for the phone, thus the call will never go
through.
(This is the same for all NAT devices).

If host=123.123.123.123 in sip.conf or the phone registers to asterisk, asterisk will be
able to send the signaling and the RTP to the NAT device which will forward everything
to the phone.

When the phone has STUN support, it will be able to open bindings on the NAT device
and will use that ip and those ports (one for signaling, 1 for RTP and one for RTCP)
inside its SIP messages in the SDP field.

The STUN would also take care of keeping the bindings alive (will detect the NAT
timeout and send keep alive packets.)

If the phone has no STUN support, you will need to register the phone to the server,
and have asterisk send keep alive messages with the qualify= line. Make sure asterisk
sends the messages faster than the timeout on your NAT device.

Without STUN support, you will also need NAT=yes or NAT=route, and you will have no
incoming audio on the natted phone until the asterisk server received audio from that
natted phone.

4) call coming from asterisk outside the nat with a Restricted Cone Nat device

As seen before, a Restricted Cone Nat device will only allow incoming packets to be
sent to the phone if that phone first sent something to the public device where the call
comes from.

This could be done by having the phone send a REGISTER, or if your phone supports
STUN, the phone would send an empty sip message to your asterisk server to open the
bindings.

When stun is used, the phone will also know what ports are mapped to it, and include
those in the SDP messages sent. (STUN would not have to send RTP to your asterisk
server to make the binding, only something to the STUN server).

natted phone.

Please note that without STUN support, the registrar and proxy server have to be on the
same IP. (if you are using only Asterisk without for example SER, this wont be a
problem).

5) call coming from asterisk outside the nat with a PORT Restricted Cone Nat device

Even if we registered the phone to Asterisk, Asterisk will not be able to send any audio
to the natted phone, unless the phone first sent audio to Asterisk, as only the 5060 port
on the NAT device will be mapped to the phone.

if your phone supports STUN, the phone would send an empty sip message to your
asterisk server to open the bindings, as well as some RTP to your asterisk servers to
open the RTP bindings.

When stun is used, the phone will also know what ports are mapped to
it, and include those in the SDP messages sent. (STUN would not have to send RTP to
your asterisk server to make the binding, only something to the STUN server).

natted phone.

1.4.2 Asterisk as a SIP server outside nat, clients / proxies on the outside connecting to
Asterisk
There is no nat in between => no problem
1.4.3 Asterisk as a SIP client outside nat, connecting to outside SIP proxies / phones
No nat is being used between them => no problem.
1.4.4 Asterisk as a SIP client outside nat, connecting to inside SIP proxies

You will need to port forward the ports the proxy uses for signaling on the NAT as well
as the ports needed for RTP. (If the proxy also handles RTP).
Problem is similar to the problem in xxx
1.4.5 Asterisk as a SIP server behind nat, sip proxies / clients on the inside connecting
to Asterisk
There is no nat in between => no problem
1.4.6 Asterisk as a SIP server behind nat, clients on the outside connecting to Asterisk
Works by doing portforwarding on the NAT, of all RTP ports used by asterisk (defined in
RTP.conf) as well as the signaling port used by sip (the port option in sip.conf)
You will also want to configure the externip and localnet options in sip.conf
1.4.7 Asterisk as a SIP client behind nat, connecting to outside SIP Proxies / phones /
gateways.
This might work, depending on the phone / gateway you are trying to reach through the
proxy. (you might have to use externip and localnet).
1.4.8 Asterisk as a SIP client behind nat, connecting to inside SIP proxies / phones /
gateways.
No nat in between => no problem

1.4.9 Asterisk inside a NAT, phone / gateway inside ANOTHER NAT

In this case, we need a middle man to even find each other, an outbound SIP proxy that
handles the SIP transaction and is reachable by all parties. To get media streams from
point to point we need another middle man, a media server.

Possible media servers :

Portaone's RTPProxy (works with SER, symmetric NAT support only)
AG Projects MediaProxy (works with SER, symmetric NAT support only)

Second asterisk outside the NAT(works for all nats but needs configuring, - non
symmetric NATs will require NAT=route.)

On the Asterisk inside the NAT, you will need to have externip and localnet in sip.conf if
you want to use a symmetric NAT.
Can you hear me now? Making VoIP work through a NAT gateway.
For all the technology behind Voice over IP (VoIP), you'd expect that it would work on every
network, but this unfortunately isn't the case. Network Address Translation (NAT) is a common
practice used in networks, and it doesn't play well with VoIP. Solving this problem requires an
understanding of NAT, VoIP and your VoIP setup. This article focuses on the SIP protocol for
VoIP and the Asterisk VoIP software, but the problems and solutions are applicable to most
other situations.
NAT is used to hide multiple hosts behind a different set of IP addresses. As a packet leaves the
gateway, the source address is rewritten to the new external address. When the return packet
arrives, the gateway replaces the destination address with that of the originating host before
sending the packet along its way. The gateway also can use the same external address for
multiple internal hosts. The source port of the connection may be changed to ensure that the
connection can be identified uniquely by the gateway, so that the return packets can have the
proper address replaced.
This last scenario is also called Port Address Translation (PAT), or IP masquerading. It is what
Linux and other home firewalls use to hide multiple internal hosts behind the single public IP
address assigned by the carrier. The hosts must be hidden because they are using special, private,
addresses that can't be routed on the Internet (such as 192.168.1.1). NAT solves the connectivity
problem by giving the host a proper source address on all external connections, which allows the
remote host to respond. The downside is that the inside must originate all connections in order to
build the translation table entries required for NAT to work.
The problem with VoIP and NAT is that both ends of the conversation have to be able to initiate
a connection to each other. Consider the simplified sequence of events that happens when
PhoneA calls PhoneB using their respective SIP servers, PBXA and PBXB.
1. PBXA sends a SIP invitation to PBXB on PhoneA's behalf. In this invitation, it is

PhoneA's IP address.
2. PBXB invites PhoneB to the conversation specifying PhoneA's IP address as the other
end.
3. If PhoneB accepts the call, PBXB responds to PBXA with an acknowledgment that
includes PhoneB's IP address.
4. PBXA tells PhoneA about PhoneB.
5. PhoneA sends audio using the Real-Time Protocol (RTP) to PhoneB.
6. PhoneB sends audio using RTP to PhoneA.
NAT can cause problems in several places. If one of the PBXes is behind a NAT gateway, the
other PBX won't be able to contact it without some additional network setup. If one or more of
the phones are behind a NAT gateway, the other phone will be trying to send audio to a non-
routable address. This results in failed calls or missing audio.
Asterisk calls the handing off of the phone call in steps 2 and 4 above a re-invite or a native
bridge. The steps above show that the phone talks to its local PBX, which in turn talks to the
remote PBX. The local PBX then re-points the two sides of the call to each other, so that the
local phone is talking to the remote end. Ideally, both sides will do this, and the phones are free
to talk directly, leaving the SIP server out of the conversation.
The alternative to a re-invite is to have the PBX relay the voice packets between the two
endpoints. We look at this in more detail later, but first, here's a more common scenario.
The simplest situation is when a SIP client is behind a NAT gateway connecting to a server on
the Internet. The client creates the translation entry for the SIP traffic when it first registers. As
long as there is frequent communication between the two hosts, such as one packet per minute,
the channel will stay open. The only configuration needed is to have the client use its external
address in all SDP packets. On clients that support it, enable STUN (Simple Traversal of UDP
through NAT), so the client can determine the external address dynamically, or enter it manually.
Asterisk doesn't support STUN at this time, so all NAT configuration must be done manually.
The following commands in /etc/asterisk/sip.conf set up the NAT properly:
[general]
localnet=192.168.0.0/255.255.0.0 ; or your subnet
externip=x.x.x.x ; use your address
[YOURREMOTEPEER] ; your peer's name

nat=yes
qualify=yes ; Force keepalives
With this configuration, Asterisk uses the address defined by externip for all calls to the peers
configured with nat=yes. The addition of qualify=yes causes Asterisk to test the connection
frequently so that the nat translations aren't removed from the firewall. With these two
commands, there always will be a communications channel between Asterisk and the peer, and
Asterisk will use the outside address when sending SDP messages.
If you have multiple phones and an Asterisk server behind a NAT gateway, the solution gets
more complex. Calls between the phones will work fine because NAT isn't needed. For calls
between you and other systems on the Internet though, there will be problems. Unless you
register to the remote side as a client (as done in the previous example), you will not be able to
receive SIP messages, so you will not be able to accept calls. Second, the address information in
the call setup will point to the internal address of the phone, and the one-way audio problems
mentioned previously will crop up.
The easiest solution to this is to avoid NAT entirely. This may seem out of place in an article
dealing with NAT, but if you have a public IP address available for your call server, use it! If
your Asterisk server is connected to both the Internet and the internal network, the SIP port is
reachable from both the inside and the outside, and the only problem is ensuring RTP flows
properly. The PBX server need not be configured to route between the interfaces or provide
masquerading; it simply needs to bridge the inbound and outbound voice calls.
As I mentioned earlier, the PBX either can stay in the voice path or get out of the way. In the
latter case, the PBX tells both endpoints about each other after which the endpoints talk directly.
However, Asterisk could have a call setup with both endpoints and relay the RTP packets on
behalf of each endpoint. The inside host would be talking to the inside address, and the outside
host would be talking to the outside address. The only configuration required to achieve this in
sip.conf is to disable re-invites:
[general]
canreinvite=no ; force relaying
This configuration works well because the Asterisk server can speak freely to the Internet to send
and receive calls. It also can talk to the internal phones, and by some simple bridging, completely
ignore NAT.
As it turns out, this relaying behavior also is required when the Asterisk server has only a private
address. The RTP ports will have to be forwarded on the firewall too. RTP chooses random port
numbers based on configured limits. Before the ports can be configured, they should be limited
in range. Configuring the firewall rules is much easier if the range of ports is known beforehand.
The range of ports to be used for RTP is defined in rtp.conf. The following configuration will
limit Asterisk's choice of RTP ports from 10000 to 10100:
[general]
rtpstart=10000 ; first port to use
rtpend=10100 ; last port to use
; rounded up if odd
Asterisk will need several RTP ports to operate properly. Only even ports are actually used, and
disabling of re-invites causes two connections to be built per call. These ports and the SIP port
must then be forwarded in by the firewall. The iptables syntax is:
iptables -t nat -A PREROUTING -i eth0 -p udp \

-m udp --dport 10000:10100 -j DNAT \
--to-destination 192.168.1.10
iptables -t nat -A PREROUTING -i eth0 -p udp \
-m udp --dport 5060 -j DNAT \
--to-destination 192.168.1.10
Replace eth0 with the outside interface of your firewall and 192.168.1.10 with the address of
your Asterisk server. These rules tell the Linux kernel to translate the destination address of any
UDP packets in the given range that are entering the outside interface. This must happen at the
PREROUTING stage as opposed to the POSTROUTING stage, because the destination address
is being translated. At this point, any SIP or RTP packet from the Internet will be forwarded to
the internal Asterisk server for processing.
When a remote station makes a call to Asterisk, the SIP packet will be forwarded in because of
the iptables rules. Asterisk will stay in the media stream because of the canreinvite=no
command, and it will use the external address of the firewall in any SDP packets because of the
NAT commands. Finally, the media stream will be forwarded to the Asterisk server because of
the combination of iptables RTP forwarding and port ranges defined in rtp.conf.
Up to this point, the configuration has focused on getting Asterisk working behind a NAT
gateway, with some extra details to make the phones relay through Asterisk. There are, of
course, more general solutions.
As I said earlier, if you can avoid NAT in the first place, it's in your best interests to do so
because it avoids all the problems encountered so far. The Asterisk gateway can have a very
restrictive firewall policy applied to it—all that is needed is to allow UDP 5060 for SIP and
whatever port range is defined in rtp.conf. In this configuration, Asterisk can contact both the
internal phones and the rest of the Internet.
The most promising solution to the NAT problem is to have the firewall rewrite the SIP body as
it translates the source address. The address specified for the RTP session would be replaced by
the firewall itself, which also would take care of forwarding the RTP stream once it arrives.
Some commercial firewalls do this. Linux iptables have shipped with ip_nat_sip and
ip_conntrack_sip modules since kernel version 2.6.18. These modules are designed to take care
of translating SIP, but after extensive testing, I was unable to get it working completely. I had
success with inbound calls from a VoIP provider with re-invites disabled, but that was it.
IP or GRE tunnels (unencrypted) and IPSec VPNs (encrypted) are another option for getting
around the need for NAT. Multiple sites are connected with a tunnel that encapsulates the
internal traffic in another IP packet using the gateway's address as it leaves the outside gateway.
The encapsulation is removed at the destination end. This is helpful only if you set up the tunnels
beforehand. Because VPNs also are used to connect branch office data networks, this option
already might be available to you. The issues of fragmentation that plague data applications
aren't a problem for VoIP because small packets are used.
If SIP is not a requirement, and you're using Asterisk, consider using the IAX protocol. IAX
tunnels both the control traffic and the voice traffic over a single UDP conversation that can be
port-forwarded, filtered or translated easily. This method is limited to a static set of tunnels,
which is sufficient if you're connecting some PBXes over the Internet or connecting to a long-
distance provider.
Sometimes the above solutions aren't available to you. In that case, it might be advisable to move
to a full-featured SIP proxy and use Asterisk only for voice applications, such as voice mail. SIP
Express Router (SER) is a powerful SIP server that handles NAT well and is used by several
high-volume services, including Free World Dialup. SER's job is only in setting up calls between
endpoints, so it must rely on other applications, such as specialized media proxies, to handle RTP
streams if needed.
The step beyond a SIP proxy is a Session Border Controller (SBC), which is like a VoIP firewall.
The SBC can intercede in either the signaling or RTP paths to add extra features, such as
signaling protocol or codec translation, all while enforcing security policies. These are almost
exclusively commercial products.
It is no secret that problems will be encountered when rolling out VoIP, especially when the
Internet and NAT are involved. Understanding how the protocols involved work is the first step
to solving these problems. You've now seen some of the solutions, from reconfiguring the phone
or PBX to port translation to additional products or even an adjustment to the architecture. With
these problems out of the way, you are free to enjoy the benefits of VoIP.
Sean Walberg is a network Engineer from Winnipeg, Canada, and has been working with VoIP
for several years. You can visit him at ertw.com.
Sniff out VoIP problems with Wireshark.
Vendors would have you believe you need to spend thousands of dollars on protocol analyzer
software to troubleshoot Voice over IP (VoIP) networks. After all, voice quality suffers if
packets are late, missing or out of order. Fortunately, Wireshark is an open-source package that
can do everything these tools can and more.
Wireshark, formerly known as Ethereal, is a network protocol analyzer. Its job is to listen to
network traffic, display it in a format that makes sense and then help you find problems. VoIP
involves a complex set of protocols that Wireshark can decode and relate to each other. For
example, the procedure to set up a call involves a different protocol than the voice traffic itself.
Wireshark uses the information from the call setup to better understand the voice flow. With this
data in your hands, you can isolate the cause of VoIP problems.
To find the cause of VoIP problems, you must be able to follow the flow of calls from start to
finish and ensure that the correct events are happening. This requires an understanding of both
the underlying protocols and some telephony concepts. Fortunately, Wireshark provides some
excellent tools to help interpret the data. The rest of this article focuses on using Wireshark's
tools to solve three common VoIP problems.
The first example is of a phone that's not working—every time a number is dialed, the phone
idles, and no ringing is heard in the earpiece. Wireshark is used here to look at the traffic
between the phone and the PBX.
Launch Wireshark as root, and select Capture→Options to bring up the Capture Options dialog,
as shown in Figure 1. Ensure that the correct interface is being used; otherwise, you won't see the
traffic. In this example, I am capturing traffic on the PBX's only interface, eth0.
Figure 1. Wireshark Capture Options Dialog Configured for VoIP Analysis
Before you capture, you have the option of specifying a capture filter to limit the number of
packets you have to deal with. Because both the signaling traffic (SIP) and voice traffic (RTP)
are UDP-based, I specify udp as a capture filter. As a convenience, I also check the Update list of
packets in real time option so I can verify I'm getting the proper traffic. Click the Start button to
start capturing, and soon the upper pane will show several packets (Figure 2).
Figure 2. Wireshark Capture of an IP Phone's Traffic
Figure 2 shows the packet list. The first four columns show the packet number, time and the
addresses of the hosts involved. Because Wireshark understands SIP, it is able to identify the
packets as SIP in the Protocol column and give detailed information in the Info column.
A cursory examination of the information in Figure 2 shows that the same three packets repeat
themselves four times. First, the ipphone host sends a SIP INVITE message to pbxhost, which is
used to open a conversation. Next, the PBX responds with “407 Proxy Authentication Required”
to which the phone responds with an ACK, and then tries again in packet 6. Because this process
repeats itself continuously, it's a good guess that the phone is trying to authenticate with the
wrong user name and password.
Monitoring: It's All About Location
If some of the packets you are looking for don't reach the network interface of the machine
running Wireshark, you've got a problem. Switched networks, by design, try to limit the traffic
only to the ports involved with the communication in order to improve performance. Spanning
trees and IP routing only complicate the matter of trying to find out where to put your probe.
Your best bet is to capture traffic directly on one of the machines involved. If you can't get
Wireshark on that machine (it runs on Windows too), you always can capture traffic locally with
tcpdump and ship the trace to another machine for analysis. If that isn't possible, or if the traffic
spans multiple machines, it's time to get help from your network hardware.
Most managed switches offer a feature that will mirror all the frames from one interface to
another. Thus, you could plug your Wireshark station in to a switch port with your Internet
connection, mirror all the traffic from the Internet router to your workstation, and you'd be able
to analyze all Internet traffic. Cisco calls this Switchport Analyzer or SPAN, HP calls it a
Monitor Port, and 3Com calls it a Roving Analysis Port.
The choice of which port to mirror depends on your network, but generally, ports that connect to
other switches or routers are a good bet. This is also where capture filters help reduce the
background noise you have to deal with.
The first example made use of Wireshark's high-level interpretation of individual packets to help
highlight a simple problem. The next example requires a more holistic view of a VoIP call. Here,
Wireshark is used to view the SIP call setup and then identify the critical packets. In this
example, a phone is experiencing one-way audio. Outbound phone calls ring and are picked up,
but only one party hears audio. The conversation was captured in the same manner as in the
previous example, resulting in 140 frames. This is too many to look at without some help, so
some of Wireshark's advanced analysis tools are used.
With the capture loaded, select Statistics→VoIP calls. Wireshark analyzes the capture for any
VoIP-related packets and provides a summary on the screen. Click on the call (if there are
multiple calls shown, hold down the Ctrl key to select additional calls), and click on the Graph
button. You will see a summary of the SIP call, as shown in Figure 3.
Figure 3. Wireshark's Graphical Interpretation of a SIP Conversation
The Graph Analysis dialog shows the SIP messages sent by the various parties. The first message
in Figure 3 is an INVITE message, which is the first step in setting up a call. In this case, the IP
phone is asking the PBX to place a call to a SIP address of sip:613@fwd.pulver.com, which is an
echo service provided by Free World Dialup for testing SIP calls. The response to this is a
request for authentication, which is acknowledged. The phone tries again and is given a status of
“Trying” by the PBX. The PBX then proceeds to INVITE the remote endpoint by contacting
fwd.pulver.com. Several more messages are exchanged before the call is set up properly.
The problem at hand is one-way audio. Indeed, the Graph Analysis window shows that the IP
phone sent Real-Time Protocol (RTP) voice data to a SIP endpoint on the Internet, but it does not
show a stream in the reverse direction. To determine why no audio was sent back, it is necessary
to read deeper into the SIP packets.
One of SIP's jobs is to set up the RTP stream between two endpoints. It does this through the
Session Description Protocol (SDP), which carries the information about codecs, IP addresses
and port numbers that is necessary for VoIP to work. Note that the endpoints speaking SDP need
not be the ones talking to each other! In Figure 3, pbxhost and fwd.pulver.com are negotiating
with each other over the Internet, but they each specify a different endpoint to terminate the
voice call. The RTP streams are unidirectional, so a full duplex conversation requires a separate
RTP stream to be set up in each direction, using two separate SDP messages.
With that in mind, it seems prudent to find out the SDP information sent from pbxhost to
fwd.pulver.com. This SDP message will contain the IP address, UDP port and codec that the
remote end is to use to talk to the local IP phone. SDP messages are tagged with SDP in the
Graph Analysis window to help you spot them. This packet is at offset 0.490 in Figure 3. When
you click on the message in the Graph Analysis window, the corresponding packet is highlighted
in the packet list pane of the main Wireshark window.
Wireshark also decodes the protocols contained within the currently selected packet in the packet
detail pane, in addition to providing a summary of the packets in the packet list pane. Decodes
are separated for each layer, such as Ethernet, IP, UDP and SIP. You can dig into the fields by
clicking the arrows on the left side of the window. Figure 4 shows the SDP message from above
with some of the relevant fields expanded.
Figure 4. Wireshark's Display of a SIP Packet Containing an SDP Message
Each line in an SDP message describes a particular attribute of the session to be created and
follows a simple attribute=value format, where the attribute is a single letter and the value is a
text string. Wireshark uses its understanding of the protocol to add some extra text, such as
descriptions of the attributes. For VoIP sessions, the important attributes are:
 a—attributes, such as codecs and silence suppression.

 c—connection information, including the IP address expecting the RTP stream.
 m—media description, including the port number on which the RTP endpoint will be
listening.
From the Connection Information (c) line, you can determine that the host being sent is
192.168.1.151. The m attribute specifies that the RTP stream is expected to be on port 34008.
Looking through the attributes, the PCM u-law and a-law codecs are offered, along with the
compressed GSM format and touch tones via the telephone-event media format. The problem
with this offering is the IP address 192.168.1.151 is a private address, unreachable from the
Internet. When the remote host tries to send packets to 192.168.1.151, the packets are lost
because no such route exists on the Internet.
For the sake of completeness, the SDP information for the other side of the conversation is at
time 7.554. After the offer is acknowledged, the two phones begin sending voice packets to the
address and port specified in the earlier SDP messages. Because pbxhost offered an invalid
address to fwd.pulver.com, the other half of the voice call is never seen.
This illustrates a common problem when using VoIP through a NAT gateway. The problem can
be solved several ways depending on one's needs, but that's another article!
So far, the troubleshooting has focused on the call signaling aspect of VoIP. Once the endpoints
begin sending RTP streams, the effects of network quality can be heard in the audio.
Network conditions that affect VoIP are latency, jitter and packet loss. Latency is the time it
takes for a packet to travel from point A to point B. Jitter is the variation in latency over a series
of packets. Loss is the number of packets sent from point A that never make it to point B.
Because VoIP audio is sent over real-time UDP, a packet that arrives out of order has to be
discarded if the packet ahead of it already has been played.
For the final example, I made a call and captured the conversation including the call setup.
Wireshark uses the SIP information to get more details about the RTP packet stream, which
enables the RTP analysis tools to be used.
Select Statistics→RTP→Show All Streams. Wireshark uses the decoded packets to provide a list
of all the audio conversations and some basic statistics, as shown in Figure 5.
Figure 5. Wireshark's List of Found RTP Streams

Figure 5 shows four streams, because each audio stream comprises two streams in opposite
directions, and the PBX was bridging the connection between the two phones. The first
indication of a problem is the final field, which shows an X when there are VoIP-related
problems. The Max Delta (latency) was 84ms for that stream, which is good. The Max Jitter was
also good at 11ms (150ms of one-way latency and 20ms of jitter are the limits of what's
considered acceptable). However, nearly 20% packet loss was encountered, which is
extraordinary!
Select the problematic stream for further analysis by clicking on it. After that, click on the Find
Reverse button to select the other half of the conversation. Finally, click on Analyze to provide a
packet-by-packet look at the stream. Lost packets will show up as having the wrong sequence
number. This screen, shown in Figure 6, also displays helpful statistics, such as the current
bandwidth, latency and jitter.
Figure 6. RTP Stream Analysis of a Stream with Excessive Packet Drops
Figure 6 clearly shows some network problems, because the packet loss is not normal. (The
steady bandwidth and regularly spaced packet drops are strong indicators of priority queue
overruns or policing in network equipment.) This loss will not be seen in the reverse direction,
because the capture was taken close to the source of the conversation. You can save the contents
of the window with the Save CSV button.
Network problems are more difficult to solve, because they require interaction with network
equipment and potentially with other parties. If your VoIP environment doesn't use the Internet,
you can capture packets at various points on the network to find where the poor conditions are
introduced. If the call flows over the Internet, you must investigate your connection to the
Internet and possibly work with your carrier.
The RTP analysis can be used with proprietary systems with some extra configuration. If
Wireshark doesn't understand the signaling, it won't be able to decode all of the RTP
information. Select Edit→Preferences→Protocols→RTP, and check the Try to decode RTP
outside of conversations box. Analysis will be a bit slower, but Wireshark will try to determine
whether every UDP packet belongs to an RTP stream, allowing you to use the RTP tools to look
at the call.
The final feature we examine here is the ability to listen to the contents of the voice call. With
the Stream Analysis window still open, select the Save Payload button, select the .au file format,
and provide a filename. After pressing the OK button, the voice call itself is saved to your hard
drive. The resulting file can be played in XMMS, soxplay or some other audio program.
Troubleshooting VoIP is unlike most other network troubleshooting, because of the separate
signaling and voice protocols, and the real-time nature of voice traffic. These three examples
have shown the important features of Wireshark that deal specifically with analyzing the SIP call
setup and RTP voice streams. These features rival those of commercial products and enable to
you find the root of VoIP problems.
Resources
Wireshark: wireshark.org
Telecom Terms and Concepts: www.oreillynet.com/pub/a/etel/2006/02/07/telecom-terms-and-

concepts.html
FWD: www.freeworlddialup.com
Sean Walberg is a network Engineer from Winnipeg, Canada, and has been working with VoIP
for several years. You can visit him at ertw.com.
Asterisk and dialing URIs
I’ve got ertw.com set up to accept SIP calls, so that if you dial sean@ this domain, it rings a
phone here. But, how do you dial out?
It’s actually quite easy in theory, since you can Dial() any sort of address, but the trick is to
integrate it with the dialplan.
A bit of research found this page which is good, but it assumes that everything gets forwarded to
the SIP macro. Using part of his recipe:
exten => _[a-z].,1,Macro(uridial,${EXTEN}@${SIPDOMAIN})

exten => _[A-Z].,1,Macro(uridial,${EXTEN}@${SIPDOMAIN})
means that only those addresses that start with a letter will be dialed as SIP, which rules out
numeric addresses (like 613@fwd.pulver.com for echo testing).
I like his idea, though, so I decided that I’d keep it, and prefix any numeric sip addresses with
sip: so that the extension above would be caught. Then it was a matter of modifying his macro to
look for sip: in front of a URI and strip it. The results are:
; Dials a SIP URI
[macro-uridial]
; First, assume it’s not a sip: type address

exten => s,1,Set(destination=${ARG1})
exten => s,n,NoOp(First 6 chars are ${ARG1:0:6})
; We see them as url encoded (ie : is really %3a)
; check to see if the first *six* chars match it then
exten => s,n,GotoIf($["${ARG1:0:6}" != "sip%3a"]?nowdial|1)
; we fell through because there was a sip: at the beginning, so
; strip the digits and then dial
exten => s,n,Set(destination=${ARG1:6})
exten => s,n,GoTo(nowdial,1)
; At this point it’s a proper uri
exten => nowdial,1,NoOp(Calling remote SIP peer ${destination})
exten => nowdial,n,Dial(SIP/${destination},120,tr)
exten => nowdial,n,Congestion()
In the end it turned out to be an exercise in learning how Asterisk works more than anything else,
ie the %3a translation, the implicit breaking up of the address into $EXTEN and $SIPDOMAIN,
and also the format of GotoIf.
Asterisk and an AS5350 SIP peer
I’ve been playing with Asterisk lately, and needed to get out to the PSTN. Since I had a Cisco
AS5350 with a PRI attached for incoming RAS, I figured I could use that. I also had some DIDs
on the line that I could use to separate voice and data calls.
Googling around, I couldn’t find a good example of anyone who has done it, so I was on my
own.
My goals here were simple:
1. People dialing 555-1111 should be picked up by the AS5350′s internal modems

2. People dialing 555-222X should be forwarded to my Asterisk box for handling
3. The Asterisk box should be able to dial out using the PRI
Already the DIDs were assigned to this PRI, so that wasn’t a problem.
The configuration on the AS5350 is fairly straightforward once you get it working:
voice service voip

sip
! Bind the SIP and RTP sessions to a known interface
bind control source-interface FastEthernet0/0
bind media source-interface FastEthernet0/0
! Normal T1-PRI configuration using all channels
controller T1 3/0
framing esf
linecode b8zs
cablelength short 133
pri-group timeslots 1-24
! Anything not picked up by a dial peer defaults to a modem call
interface Serial3/0:23
isdn incoming-voice modem
! Use a data dial-peer to answer anything to 555-1111 with a modem
dial-peer data 10 pots
incoming called-number 5551111
! Match inbound calls to the voice DIDs
dial-peer voice 100 pots
incoming called-number 555222.
! All digits are collected and sent along
direct-inward-dial
forward-digits extra
! The IP leg of the call... send to the sip server defined below
dial-peer voice 200 voip
destination-pattern 555222.
session protocol sipv2
session target sip-server
! Any digits collected after the call has been answers get forwarded
dtmf-relay sip-notify rtp-nte
! I want g711 ulaw for a codec
codec g711ulaw
! Anything else gets sent out the PSTN
! Note you need the data dial-peer above to accept modem calls, otherwise
! this dial-peer will give dialtone to anyone who calls!
dial-peer voice 1000 pots
application session
destination-pattern .T
port 3/0:D
forward-digits all
! define your SIP server
sip-ua
authentication username USERNAME password PASSWORD
! xxx.xxx.xxx.xxx represents the Asterisk box
registrar ipv4:xxx.xxx.xxx.xxx expires 3600
sip-server ipv4:xxx.xxx.xxx.xxx
SIP Outbound Proxy Server Explained

by Smartvox on August 23, 2010
Why do IP Phones require a setting for ‘Outbound Proxy

Server’?
Outbound Proxy Server
When you look at the configuration options on most IP phones, you will see a field called
“Outbound Proxy” or “Outbound Proxy Server”. In this field you can enter an IP address, a
host.domain name or just a domain name (as long as it can be resolved to an IP address in
DNS). It is an optional field, but if you enter a value then all future SIP requests get sent there in
the first instance. If you leave it blank, then the routing of SIP requests will depend mainly on the
SIP address given in the R-URI field of the request’s header – see the section “what happens if
an Outbound Proxy Server is not specified” below for details.
The use of DNS SRV records to identify SIP Proxy Servers
If you have enabled the use of DNS-SRV records (an option on most IP phones) then the name
entered for the Outbound Proxy server may be used to lookup DNS-SRV records if they exist.
These records define one or more server IP addresses and include extra data such as the port
number, the type of service and the transmission protocol (UDP or TCP) to be used. The records
are created in the first place by the VoIP service provider and cannot be modified by users. If
DNS-SRV records do not exist or the option to use them is disabled, then the host name given
for a Proxy server is converted to an IP address using conventional DNS host record lookups.
The option on your IP phone to use SRV records will also affect the resolving of other server
names and/or the domain name part of your SIP user account if this is being used.
What is the function of a SIP Outbound Proxy Server?
When the IP phone makes an outbound call, it sends an INVITE request. If your IP phone is
configured to use an outbound proxy server, then the INVITE is sent there. The request could be
handled within that proxy server or be forwarded to another proxy server or gateway. The user
credentials would normally be checked, especially if the call needs to break out onto the PSTN
or incurs toll charges in any way.
For more information about the role of SIP Proxy Servers and how they handle outbound calls,
click here.
On most IP phones, if a valid entry is given for the “outbound proxy server” field, then it causes
every type of SIP request from the phone to be sent to that address (albeit this behaviour would
only apply to one SIP account at a time on a multi-line phone). This would mean that even a
REGISTER request that might otherwise have gone directly to the registrar server, would have to
go via the outbound proxy server. In this case, the outbound proxy server would be able to block
the request or forward it to the correct registrar server depending on its own internal rules. In this
role, the outbound proxy server is acting as a centrally managed security barrier and, in
combination with appropriate firewall rules, it could be given a role similar to that of a web
proxy in a corporate network environment.
What value should I set for ‘Outbound Proxy Server’?

Setting for use with a commercial VoIP Provider: If you want to use an IP phone with a
commercial VoIP Service Provider on the Internet, such as sipgate, voiptalk or callcentric, then
the provider will tell you what to set as the outbound proxy server. It will be the name or IP
address of one of their proxy servers.
Setting for use with an IPBX: If you want to use an IP phone with an IP capable PBX, then the
outbound proxy server will probably need to be the PBX. This might be in the form of a host
name or IP address, but you will need to find out this information from the administrator of the
system.
Setting for use with Asterisk or other “home grown” solutions: The outbound proxy server
would normally be the Asterisk server. The Asterisk server would then need to be configured
with a dial plan that handles outbound calls from the clients. This dial plan might implement
rules that prohibit callers from dialling certain numbers (e.g. premium rate numbers) or that
routes calls out onto different trunk connections depending on the dialled number (a form of
“least cost routing”). The dial plan would also need to recognise when the dialled number
matches the pattern for another internal phone on the Asterisk PBX system. It is important to
choose a numbering scheme for internal phones that can be easily distinguished from PSTN and
other external numbers. It is also useful if the numbering scheme selected for internal IP phones
is different to that used for internal analogue phones where both must co-exist.
What happens if an Outbound Proxy Server is not specified?

As mentioned above, in the absence of a setting for Outbound Proxy server, SIP requests are
simply sent to the address shown on the main header of the SIP request – this address is called
the Request-URI or R-URI for short (for an explanation of URI, look at the Wikipedia entry
here).
The R-URI on a SIP request will depend what type of request it is (INVITE, REGISTER, etc)
and what information is already known by the IP phone when it is building the request. For
example, a call made by dialling a number on the telephone’s keypad will generate an INVITE
with an R-URI like this:
sip:@
The phone gets the value of “my_sip_domain” from the account settings, although the actual
configuration parameter that contains this setting will vary from one make of IP phone to another
– to view sample settings on various makes of phone click here.
However, if the user has previously programmed a “speed-dial” key or an entry in the phone
book then it is possible for the destination to be a complete SIP URI – containing both the user
ID (or number) and the sip domain of the destination. For example:
sip:@
In each case, the request will be sent to the address corresponding to the domain part of the R-
URI – in the first example it is sent to the account’s own Proxy server, but in the second example
it is sent directly to the destination’s Proxy server thereby eliminating some unnecessary hops in
the call path. The latter method could even be used to make calls directly between SIP phones,
without the need for a VoIP service provider, IP-PBX, SIP Proxy server or Asterisk server.
IP Phone Configuration: SIP Proxy Server

by Smartvox on August 23, 2010
What is the ‘SIP Proxy Server’ setting on an IP phone?

It might be called something different on your IP phone
In their wisdom, each manufacturer has made different decisions about the naming of data
parameters on their IP phones. So if you look at a Snom phone it uses different names to those on
a Grandstream etc. The differences sometimes go beyond simply giving a different name to the
same parameter and there may even be no direct equivalent on one phone for something present
on another. In the case of the “SIP Proxy Server” field, the manufacturers have excelled
themselves when it comes to not agreeing on the name:
Snom Aastra Grandstream Linksys
Registrar Proxy Server SIP Server Proxy
Proxy Server vs. Outbound Proxy Server
When you look at the configuration options on most IP phones, you will see a field called “SIP
Server”, “Proxy Server” or simply “Proxy” and another field called “Outbound Proxy” or
“Outbound Proxy Server”.
The two fields have similar names and in many cases you can put exactly the same value into
both fields, but they are quite different and should not be confused. The value specified for
“Proxy Server” generally identifies both a server that can handle requests from the phone and
also a sip domain that is part of the user account for the phone. The sip domain name is used
during registration and it should also match the domain part of your phone’s own SIP address –
i.e. if other people are going to be able to call your phone, they must use that domain name as
part of the sip address they use to reach you.
The “Outbound Proxy Server” is an optional field, but if you enter a value then all future SIP
requests get sent there in the first instance. As far as routing of SIP requests is concerned, the
setting for “Outbound Proxy” overrides the setting for SIP Proxy or Registrar. If you leave it
blank, then all SIP requests will generally be sent to the “Proxy Server”.
Note: The Aastra phone is slightly different because it has fields for “Proxy Server”, “Outbound
Proxy Server” and “Registrar Server”; It also has fields for “Backup Proxy Server” and
“Backup Registrar Server” – you’ll have to read the Aastra Administrator Guide to understand
how and when each of these settings is used (I tried, but it lost me!).
For more information about the Outbound Proxy Server, click here.
The use of DNS SRV records to identify SIP Proxy Servers
If you have enabled the use of DNS-SRV records (an option on most IP phones) then the name
entered for the Proxy Server may be used to lookup DNS-SRV records if they exist. These
records define one or more server IP addresses and include extra data such as the port number,
the type of service and the transmission protocol (UDP or TCP) to be used. The records are
created in the first place by the VoIP service provider and cannot be modified by users. If DNS-
SRV records do not exist or the option to use them is disabled, then the host name given for a
Proxy server is converted to an IP address using conventional DNS host record lookups.
The option on your IP phone to use SRV records will also affect the resolving of other server
names such as the “Outbound Proxy Server”.
What is the function of a SIP Proxy Server
When the IP phone makes an outbound call, it will nearly always send an INVITE request to a
Proxy Server (the only alternatives really, would be to send the INVITE directly to the end-point
that is being called or to an IP-PBX or Asterisk server. As far as this description is concerned,
the IP-PBX or Asterisk server can be considered equivalent to a Proxy Server). If your IP phone
is configured to use an “outbound proxy server”, then the INVITE is sent there. Otherwise it will
usually go to the Proxy Server associated with its own SIP account.
When a Proxy server receives an INVITE, it examines the request and looks up information in its
internal databases to see if the client that is making the request is allowed to call that number. If
the call is to a PSTN number or other chargeable destination, then the user’s credit level may be
checked before allowing the call to proceed. If the call is permitted, the proxy server will then
check the caller’s identity to make sure it is not a rogue client trying to impersonate a valid user.
This is done by sending a challenge back to the calling device requesting identification by way of
user id and password. The contents of the SIP messages that carry this identity information are
encrypted so it is not possible for others to intercept the message and read their credentials. If the
client is able to authenticate successfully then the call may proceed.
Part of a proxy server’s responsibility is to decide where it should forward the request next. If the
proxy server gives access to the PSTN then it might need to forward the call to a PSTN gateway.
However, if the call is to another SIP service, perhaps one operated by a different VoIP service
provider, then it will look up the correct destination using DNS. If it is a REGISTER request
rather than an INVITE then it may be able to handle the registration itself or it may forward it to
the registrar for that domain or it may even reject the request.
Some Frequently Asked Questions about Proxy Servers and

IP phones
Does the phone have to register to be able to make calls?
The simple answer to this is no. You should be able to make calls via a proxy server without
necessarily registering first. The registration process is crucial for your IP phone to be able to
receive inbound calls, but it will not always be necessary in order to make outbound calls.
However, some IP phones won’t let you use an account unless it successfully registered.
If the call you are trying to make would incur call toll charges then you will almost certainly
need to have a valid user account with the provider whose server you are trying to use (unless
there is some arrangement in place for cross charging between providers). However, that does
not necessarily mean your phone has to already be registered before the call starts. Instead, the
authentication of your phone will occur as part of the SIP dialogue that happens when the call is
initiated.
My IP phone allows me to specify more than one Proxy Server. Why?
Many IP phones support multiple lines or multiple accounts. For very simple applications you
might only need to enter the details for one VoIP account, giving the Proxy Server setting
relevant to that account. However, it is sometimes useful to be able to register multiple accounts
from one phone – in this case you would need to specify the Proxy Server for each account. You
will then be able to assign an account to each line key – calls made using that line key will use
those account details and the associated Proxy Server or Outbound Proxy Server. It is normal for
one account to be nominated as the default account (or sometimes this is achieved by specifying
the preferred line key).
The X-Lite softphone (now evolved into the EyeBeam) would allow you to enter details for more
than one SIP Proxy server and then to nominate one of them as the default. In the address book
you could then nominate a specific Proxy server for certain numbers. This was a neat solution as
it allowed you to automatically match the person you were calling with the most appropriate
Proxy Server, while ensuring there was a default route for all the other numbers you may want to
call.
Unless your IP phone is being used only to make internal calls on the company phone system,
the default account should probably be the one that gives you access to the PSTN.
Must I have an account with the provider before I can use their Proxy Server?
It is not always necessary to have an account with the service provider when you want to use
their server as an outbound proxy. For example, if you wanted to call an IP phone that you know
is registered with sipgate, even though your phone is not registered with sipgate, you may be able
to specify a sipgate server as the outbound proxy for that call. This is because the call will not
incur any toll charges and would have to eventually be routed to one of their servers anyway – in
effect you are cutting out one or more intermediate proxy servers by specifying the correct final
destination proxy server in the first place.
Very often, the main account ID is the same as the phone number for your IP phone. The field
appears with the following label alongside it:
Account Phone Number SIP User ID User ID
User account: SIP Registrar/SIP Domain
Absolutely no agreement here between manufacturers on what to call this. In my opinion it

should be called the "SIP Domain", but this would clearly be at odds with all the equipment
manufacturers who I must assume have done their research, so I will go along with the received
wisdom. It is a setting that serves two purposes - mainly it sets the SIP domain name that is used
during registration and within other SIP dialogues. However, in the absence of a more explicit
server identification, it can also identify the Registrar server and possibly the Proxy server where
other SIP requests should be sent. The setting appears with the following labels:
Registrar Proxy Server SIP Server Proxy
SIP Server Identification: SIP Registrar Server
It gets complicated here. First, Aastra provides an explicit field to identify the Registrar server
while the others combine SIP Domain name and Registrar Server into a single field (see above).
That is not altogether surprising because the IP address for the Registrar server can be resolved
using DNS. However, even on those phones that do have a field for the registrar server, the
"Outbound Proxy" setting overrides any IP address that can be resolved from the SIP Domain
name. Confused? Yeah, me too!
N/A Registrar Server N/A N/A
SIP Server Identification: Outbound Proxy
If you set a value for the Outbound Proxy, then it will almost certainly override other SIP server
identification settings in so far as all SIP requests generated by the phone get sent to the
Outbound Proxy Server first. Most manufacturers use much the same label to identify this item:
Outbound Proxy
Outbound Proxy Outbound Proxy Outbound Proxy
Server
What is a STUN Server?

A STUN (Simple Traversal of User Datagram Protocol [UDP] Through Network Address
Translators [NATs]) server allows NAT clients (i.e. computers behind a firewall) to setup phone
calls to a VOIP provider hosted outside of the local network.
The STUN server allows clients to find out their public address, the type of NAT they are behind
and the internet side port associated by the NAT with a particular local port. This information is
used to set up UDP communication between the client and the VOIP provider and so establish a
call. The STUN protocol is defined in RFC 3489.
The STUN server is contacted on UDP port 3478, however the server will hint clients to perform
tests on alternate IP and port number too (STUN servers have two IP addresses). The RFC states
that this port and IP are arbitrary.
More information about STUN and VoIP in general can be found in our SIP / VoIP Video
tutorials, 'Voip Nuggets'. VoIP Nuggets are short youtube technical training tutorials about VoIP.
Click here for the latest list of VoIP Nuggets
Stun functionality is seamlessly handled by 3CX Phone System for Windows - an easy to install
windows based PBX.
This document will provide an overview of the more common concepts which need to be kept in
mind when configuring 3CX PhoneSystem inside your network infrastructure, including the
following topics:
 NAT Configuration
 STUN Resolution
 DNS Resolution in a VoIP environment
 Custom Configuration for particular network layouts
 Different types of VoIP Provider Accounts
 Custom Source Identification for VoIP Provider SIP message exchange
NAT Configuration
Number one on the VoIP provider configuration check list is the Port forwarding (also known as
port publishing) on your NAT device.
If your PBX is operating from an average network i.e. connected to the internet through a single
router, your PBX is behind NAT. The NAT device has to be instructed to forward the right
inbound packets (from internet) to the PBX server. The UDP port ranges that need to be
forwarded are related to SIP (call signaling) and RTP (Voice data). If you are running the PBX
on the standard SIP port 5060 then all packets to UDP port 5060 need to be forwarded to the
PBX. For the second port range (audio) you must forward ports 9000-9049 to the PBX. This only
applies if you are using the standard range. You can find out the exact port range that your PBX
uses in the “General Settings” of the 3CXPhoneSystem web console under the “Ports to use for
external calls” setting. On the other hand the PBX in reverse must also be allowed to send out
SIP traffic (source and destination port 5060), RTP traffic (in this case traffic with source ports
9000-9049) and STUN requests (destination port 3478). It is highly recommended that you test
with an open access, i.e. allow ALL outgoing traffic from the PBX.
STUN resolution
In order to work properly the PBX needs to know its public (internet) IP address and what kind
of NAT it is behind. It needs this so it knows how it is seen from the VOIP providers point of
view. This is achieved via STUN resolution. Successful log entries will reflect proper stun
resolution and will appear in the server status page on PBX at startup. These entries will look
like the following;
14:40:27.703 StunClient::process [CM506002]: Resolved SIP external IP:port (64.233.167.99:5060) on Transport

192.168.0.1:5060
14:40:27.265 StunClient::onInitTests [CM506001]: STUN request to resolve SIP external IP:port mapping is sent to STUN
server 64.69.76.23:3478 over Transport 192.168.0.1:5060
If there is no answer from the STUN server the PBX will log a failure, the message will look as
follows;
11:14:38.687 StunClient::onTestTout [CM506004]: STUN request to STUN server 64.69.76.23 has timed out; used
Transport: 10.172.0.132:5060
Note: If the customer wants to skip STUN resolution, because its on a public IP and no firewall
is involved, then he can delete the STUN server entries in the general settings page. This will
cancel out any STUN resolution. For further information about working in a STUN-less
environment, go to this article: How and when can I switch off STUN Resolution?
From the successful logs one can notice that the “Resolved SIP external IP:port” contains a
correct public IP, this can be cross checked on the NAT device. Every NAT device will have a
status monitor where its IP can be reviewed. If the port forwarding rules have been set correctly
then (normally, depending on the type of NAT implemented) no PAT (Port Address Translation)
will occur. This means that the source port will not change when the PBX contacts the STUN
server, the reported source port by the STUN server will remain 5060 (untouched). If the NAT
device did not have the SIP port (5060) forwarding rules set it would be very likely that the NAT
device would change the source port (along with the source IP) when the request traverses the
device. The log entry in this case would look something like this (notice the report reflects a
changed (translated) port);
14:40:27.703 StunClient::process [CM506002]: Resolved SIP external IP:port (64.233.167.99:24842) on Transport

192.168.0.1:5060
14:40:27.265 StunClient::onInitTests [CM506001]: STUN request to resolve SIP external IP:port mapping is sent to STUN
server 64.69.76.23:3478 over Transport 192.168.0.1:5060
Note: The chances are that this setup may still work but it is definitely not as reliably as the
scenario described earlier (no PAT) it is therefore not recommended.
The resolved public IP and Port will be used by the PBX for all external (internet)
communication. If your internet connection has a frequently changing IP address your PBX is
running in what can be considered a hostile environment, this type of environment is highly
discouraged as it will most likely lead to intermittent service. In such a case make sure you have
a frequent “Recheck external IP every (sec)” interval in the “General Settings” page under
“STUN Server options”. You can discover if you have a frequently changing IP by either
reviewing the status monitor of youe NAT device (WAN IP) or by reviewing the “Resolved
external IP” in STUN server responses logged by the PBX in its status monitor page.
DNS resolution
Before being able to communicate with a VoIP provider the PBX must resolve the IP of the
server it has to speak with. The PBX will send SIP traffic to the specified “Registrar/Proxy”
found in the VoIP provider’s configuration. If this is an FQDN (opposed to an IP) the PBX will
need to resolve this. It will first try to resolve the FQDN as an SRV record, and then (on failure)
as an “A” record. “A” records are normal DNS records and these will be resolved normally. i.e.
The PBX will ask it’s host OS to resolve the FQDN to an IP. The OS will ask the root servers for
the DNS server in charge of the zone (example.com), and then ask for the particular record (A) at
the zone’s DNS server. SRV records on the other hand have an extra step. “SRV” records are
described in RFC2782 – these work much alike MX records. If the configured “Registrar/Proxy”
of a VoIP provider is “example.com” the PBX will query for the “_sip._udp.example.com”
“SRV” record. The initial steps for resolution are normal; i.e. the OS will query for the
authorative server of example.com and then query for the SRV record _sip._udp at that server.
The result however is not a single IP but a list of A records with a priority. e.g. ;
_sip._udp.example.com. 86400 IN SRV 10 60 5060 bigbox.example.com.
_sip._udp.example.com. 86400 IN SRV 10 20 5060 smallbox1.example.com.
_sip._udp.example.com. 86400 IN SRV 20 0 5060 backupbox.example.com.
The PBX will then go ahead and query the returned A records. The record with highest priority
(this is indicated as the one with the lowest number in the column directly after the SRV column)
will be the server that the PBX sends the SIP traffic to.
Using NSlookup to check records

You can manually check what SRV records are available for a particular provider using windows
nslookup. This allows you to easily check if the provider has correct SRV and A records setup.
For example:
Nslookup –q=srv _sip._udp.3cx.com

This queries the 3cx DNS server for a SIP server.
This returns sip.3cx.com
3CX Phone System will then query the A record for this host. The resulting IP will be used by
3CX Phone System.
Likewise, you can check what SRV records and IPs for A records will be returned by your VOIP
provider.
Which interface is used for outgoing traffic
3CX Phone System uses Windows routing to decide which Network Interface it should use to do
routing. Therefore, if you have multiple network cards in your machine, you will have to ensure
that you have routing configured correctly. Use the windows route print command to find out
traffic routes and priority.
Additional routable subnets

By default, 3CX Phone System will assume all devices on IPs of private networks as defined by
RFC 3330 are local:10.0.0.0/8,169.254.0.0/16,172.16.0.0/12,192.168.0.0/16
If you have additional local subnets that should be considered internal, then you can configure
these in the 3CXPhoneSystem.ini file by setting the “localSubnets” option in the “[Network]”
section. This option should be specified as a comma-separated list of IP Address ranges in the
form “a.b.c.d/maskLen”. If the option is specified it completely overrides default ranges
specified above, so you must add ALL local ranges, including those that are by default
considered local.
Example 1:
[Network]
localSubnets=
; IP will be treated as local only if it is directly accessible (residing in the same network as PBX
host).
Example 2:
[Network]
localSubnets=172.99.95.0/24,45.23.68.0/24
; IP will be treated as local if it is directly accessible (IP Address in same subnet as PBX)
; or has IP in range 172.99.95.0/24 or 45.23.68.0/24
REGISTER
Registration-Based VoIP Provider Accounts
The PBX will attempt to REGISTER its VoIP provider lines on startup. SIP registration is a
method for a SIP device to inform its registrar (in this case the VoIP provider) where it is
located. Once this is established the VoIP provider will know where to forward incoming calls.
REGISTER requests are usually challenged for authentication; this is a handy way to find out if
the credentials set up in the VoIP provider line configuration are correct.
If STUN resolution does not work then the PBX will NOT try to REGISTER. Registration
attempts will show up in the server status page.
12:35:31.675 ClientRegs::Register [CM504003]: Sent registration request for 10000@sipgate
If no response is received then the VoIP provider’s server may have never received the request,
the VoIP provider’s server did not send a response or the response was lost on the way. In any
case check that:
1. STUN resolution is working. – reviewed in status log.

2. The host part of the SIP URI in the Contact Header in the REGISTER request is truly your NAT
device’s public IP (and port).
3. Port forwarding on the NAT device is indeed set correctly.
The VoIP provider’s response to a REGISTER request is usually a challenge (407). The
subsequent REGISTER request to the provider will contain a Proxy-Authorization Header with
the challenge response (a hash calculated using the nonce which was sent in the challenge) and
an incremented Call Sequence Header. If the calculated hash matches the calculation done on the
VoIP provider’s end VoIP provider will know that the PBX has a matching copy of the
authentication ID and authentication password. The response from the provider should be a
failure or success. One of the following two logs will appear;
13:40:08.953 ClientRegs::onFailure [CM504005]: Registration failed for: 10000@sipgate
13:41:53.328 ClientRegs::onSuccess [CM504004]: Registration succeeded for: 10000@sipgate
If the REGISTER fails it is very likely that the credentials are set incorrectly. It is best to verify
the credentials that are being used in the PBX’s configuration by cross checking using a SIP
phone. Check your account details.
SIP Trunk (Non-Registration-based) VoIP Provider Accounts
SIP Trunk accounts do not go through the REGISTER process. The VoIP provider does not need
to discover the client’s whereabouts because the client’s IP is fixed in a “hard coded”
configuration in the VoIP provider’s server. Usually this can be set in a SIP Trunk account’s web
portal. Apart from skipping the REGISTER process SIP Trunks also skip the Authorization
(challenge / response) process; this can be done because calls are automatically trusted by their
source IP. i.e. calls coming from the configured IP address are identified by their source IP.
When a SIP Trunk is configured in the PBX, the interface will still ask for an Authentication ID
and Password (this is the way the 3CX VoIP Provider creation interface is designed), but they
will be ignored when communicating with the VoIP Provider (since passwords are not used in
this model) – the PBX will not try to REGISTER but a successful registered state will be
assumed and a normal log entry will appear;
13:41:53.328 ClientRegs::onSuccess [CM504004]: Registration succeeded for: user@siptrunkprovider
Receiving INVITES
A successful registration means the VoIP provider knows the correct public address where it can
reach the PBX. When the VoIP provider receives a call placed to a number assigned to your
VoIP provider account it will send an INVITE to the address registered by the PBX. If you wish
to review the registration some providers will display the registration status in your VoIP
provider account page. This internet address is the public IP of the NAT device, if forwarding
rules are set correctly the INVITE will reach the PBX. The following is a sample INVITE;
INVITE sip:8632606@72.14.207.99:5060;rinstance=7303026702615448 SIP/2.0
Record-Route: <sip:217.10.79.23;lr=on;ftag=as21013b10>
Record-Route: <sip:172.20.40.4;lr=on>
Record-Route: <sip:217.10.79.23;lr=on;ftag=as21013b10>
Via: SIP/2.0/UDP 217.10.79.23:5060;branch=z9hG4bK11d4.8a4bf394.0
Via: SIP/2.0/UDP 172.20.40.4;branch=z9hG4bK11d4.8a4bf394.0
Via: SIP/2.0/UDP 217.10.79.23:5060;received=217.10.68.6;branch=z9hG4bK7d2a0377
Via: SIP/2.0/UDP 217.10.66.71:5060;branch=z9hG4bK7d2a0377;rport=5060
From: “0015552368″ <sip: 0015552368@sipgate.co.uk>;tag=as21013b10
To: <sip: 8632606@sipgate.co.uk>
Contact: <sip: 0015552368@217.10.66.71>
Call-ID: 38b34a2512c9c1903d5d5940348c18f4@sipgate.co.uk
CSeq: 102 INVITE
Max-Forwards: 67
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 446
Source Identification – Default behavior

When the PBX receives an INVITE it will check its source. This checking is called “Source
Identification” and the purpose of this process is to see if the call is a valid request, is from a
trusted domain and hence should be let through. If a call source is not identified (trusted) the
PBX will ask for authorization. The default behavior for source identification is to check the
“user part” of an INVITE’s Request Line against the authentication IDs configured in the PBX.
Once a match is made the call is trusted and forwarded according to the configuration of the
matched line.
In order to illustrate this process take for example the below INVITE which is coming from a
VoIP provider with rather standard behavior. The VoIP provider line is configured with the
following details;
External Number : 415551234

Authentication ID : 8632606
Authentication Pass : $ecret_W0rd
The received Request Line in an INVITE from this VoIP provider is as per below:
INVITE sip:8632606@72.14.207.99:5060;rinstance=7303026702615448 SIP/2.0
The user part in the request line is “8632606”, this matches the “Authentication ID” (8632606)
of the configured line.
Latest source identification rules
For PSTN providers: Match any of following:
 LineID is in Contact OR RequestLine (user part, of course)

 Gateway host/port is in Contact
For VoIP providers: Match any of following:
 AuthID is in Contact OR RequestLine (user part, of course)

 External number is in To OR RequestLine (user part)
Source Identification – Custom behavior
Unfortunately not all VoIP Providers act the same and some VoIP providers will not INVITE
with the SIP identity in the Request-Line URI. For these cases the source identification strategy
can be altered in order to match any VoIP provider. In the “Edit gateway” page of a VoIP
provider under “Source Identification” a custom matching strategy can be constructed. On the
left there is a list of SIP fields and on the right there is a list of values against which the PBX will
attempt a match. A call’s source will be considered successfully identified if a set pair matches
(i.e. if they are equal when compared). The list of pairs can be set to match ANY or match ALL,
the latter means that if a single pair does not match the PBX will assume a failure. An INVITE
coming from the provider must be reviewed in order to plan a suitable strategy; fields that do not
change from call to call must be identified. Unidentified incoming INVITEs can be collected
from the server status page. Advisable identifiers (constant fields) would normally be the
Authentication ID or the External number (DID). In extreme cases you can fall back to
identifying the source by locating the VoIP provider’s domain in some field or by the VoIP
provider’s Proxy IP (if they are using a single IP).
Example:
1. “Request Line URI: User Part” can be matched against the “LineNumber external number of
line”. This kind of strategy would suit cases where a VoIP provider inserts the DID number or
external number of a line in the Request Line instead of the account’s Authentication
IDINVITE sip: 0015552368@ 72.14.207.99:5060;rinstance=800f2f60c40d1d10 SIP/2.0
2. “TO: User Part” can be matched against the “LineNumber external number of line”. This strategy
would look for a line’s external number e.g. “0015552368” in the user part of the “To” header of
the SIP URI in an INVITE from the VoIP provider in question.
To: <sip: 00495552368@myexampleprovider.de>
3. “From: Host Part” can be matched against the “GWHostPort gateway/provider host/port”. This
strategy would look for the VoIP provider’s Proxy address and port (myexamplprovider.nl) in the
host part of the SIP URI in an INVITE from the VoIP provider in question.
From: “00315552368″ <sip: 00315552368@myexamplprovider.nl>;tag=as33577b1c

Via and record route
Via and record route

The Via header will show up in sip packets and basically indicates the “SIP hops” via which the
packet has traveled. Last hops are inserted at the top. Responses to these sip packets are then sent
to the back over the same path – starting with the top entry.
The Record route header is similar to the Via header, however it is used to instruct the receiving
end point over which path to send any REQUESTS (as opposed to responses). A record route
command is inserted by the proxy if it wants to remain in the loop for future communications.
Re record route command will be used by the 3CX SIP bridge, which tunnels all traffic. The
VOIP client, seeing the record route command, will send all traffic via the bridge (which inserted
itself as a hop and therefore wants to remain in the loop), rather then directly.
Note: When the 3CX Phone uses the record route header to send a request back, it will insert
“route” and not “record route”.
How does FreeSWITCH compare to Asterisk? Why did you start over with a new application?
These are questions I’ve been hearing a lot lately so I decided to explain it for all of the
telephony professionals and enthusiasts alike who are interested to know how the two
applications compare and contrast to each other. I have a vast amount of experience with both
applications with about 3 years of doing asterisk development under my belt and well, being the
author of FreeSWITCH. First I will provide a little history and my experience with Asterisk, then
I will try to explain the motivations and the different approach I took with FreeSWITCH.
I first tried Asterisk in 2003. It was still pre 1.0 and VoIP was still very new to me. I downloaded
and installed it and in a few minutes I was tickled pink over the dial tone emitting from my
phone plugged into the back of my computer. I spent the next few days playing with my dial plan
and racking my brain to think of cool stuff I could do with a phone that was hooked up to a
Linux PC. Since I had done an extensive amount of web development in my past life I had all
sorts of nifty ideas like matching the caller id to the customer’s account number and trying to
guess why they were calling etc. I also wanted to move on in my dial plan based on pattern
matching and started hacking my first module. Before I knew it I had made the first cut of
app_perl, now res_perl where I had embedded a Perl5 interpreter in Asterisk.
Now that I had that out of my system, I started developing an Asterisk-driven infrastructure to
use for our inbound call Queues. I prototyped it using app_queue and the Manager Interface now
proudly dubbed “AMI” (initials always make things sound cooler). It was indeed magnificent!
You could call in from a PSTN number over a T1 and join a call queue where our agents who
also called in could service the calls. “This rocks!” I thought to myself as I watched from my
fancy web page showing all the queues and who was logged in. It even refreshed periodically by
itself which was why I was surprised when the little icon in the corner of my browser was still
spinning for quite some time. That’s when I first heard it. That word. The one I can never forget,
deadlock.
That was the first time, but it wasn’t the last. I learned all about the GNU debugger that day and
it was just the first of many incidents. Deadlock in the queue app. Deadlock in the manager,
Avoiding Deadlock on my console. It was starting to get to me a little but I kept going. By this
time I was also quite familiar with the term Segmentation Fault another foe to the computer
developer. After about a year’s time wrestling with bugs I found myself a lot more well-versed in
the C programming language than I even imagined and near Jedi caliber debugging skills. I had a
working platform running several services on a DS3 worth of TDM channels spread over 7
asterisk boxes and I had given tons of code to the project including some entire files on which I
hold the copyright. http://www.cluecon.com/anthm.html
By 2005, I had quite a reputation as an asterisk developer. They even thanked me in both the
CREDITS file and in the book, Asterisk, The Future of Telephony. I not only had tons of
applications for asterisk in tree, I had my own collection of code they did not need or want on my
own site. (Still available today at http://www.freeswitch.org/node/50)
Despite all of this I could not completely escape the deadlocks and crashes. I hid the problem
well with restart scripts and 7 machine clusters but I could not see a way to scale my platform
much more. I had to abandon some features because they just would not work right based on the
way Asterisk was designed.
Asterisk uses a modular design where a central core loads shared objects to extend the
functionality with bits of code known as “modules”. Modules are used to implement specific
protocols such as SIP, add applications such as custom IVRs and tie in other external interfaces
such as the Manager Interface. The core of Asterisk is a threading model but a very conservative
one. Only origination channels and channels executing an application have threads. The B leg of
any call operate only within the same thread as the A leg and when something happens like a call
transfer the channel must first be transferred to a threaded mode which often times includes a
practice called channel masquerade, a process where all the internals of a channel are torn from
one dynamic memory object and placed into another. A practice that was once described in the
code comments as being “nasty”. The same went for the opposite operation the thread was
discarded by cloning the channel and letting the original hang-up which also required hacking
the cdr structure to avoid seeing it as a new call. One will often see 3 or 4 channels up for a
single call during a call transfer because of this.
/* XXX This is a seriously wacked out operation. We're essentially putting the guts of
the clone channel into the original channel. Start by killing off the original
channel's backend. I'm not sure we're going to keep this function, because
while the features are nice, the cost is very high in terms of pure nastiness. XXX */
This became the de facto way to pull a channel out of the grips of another thread and the source
of many headaches for application developers. This uncertain threading scheme was one of the
motivating factors for a rewrite.
Asterisk uses linked-lists to manage its open channels. A linked-list is a series of dynamic
memory chained together by using a structure that has a pointer to its own type as one of the
members allowing you to endlessly chain objects and keep track of them.
They are indeed a useful programming practice but when used in a threaded application become
very difficult to manage. One must use mutexes, a kind of traffic light for threads to make sure
only 1 thread ever has write access to the list or you risk one thread tearing a link out of a list
while another is traversing it. This also leads to horrible situations where one thread may be
destroying or masquerading a channel while another is accessing it which will result in a
Segmentation Fault which is a fatal error in the program and causes it to instantly halt which, of
course means in most cases all your calls will be lost. We’ve all seen the infamous “Avoiding
initial deadlock” message which essentially is an attempt to lock a channel 10 times and if still
won’t lock, just go ahead and forget about the lock.
The manager interface or AMI has a concept where the socket used to connect the client is
passed down into the applications letting your module have direct access to it and essentially
write any data you want to that socket in the form of Manager Events which are not very
structured and thus the protocol is very difficult to parse.
Asterisk’s core has linking dependencies on some of it’s modules which means that the
application will not start if a certain module is not present because the core is actually using
some of the binary code from the module shared object directly. To make a call in asterisk in at
least version 1.2 you have no choice but to use app_dial and res_features because the code
actually lives in those modules. The logic to establish a call and to do things like a forked dial
actually reside in app_dial not the core, and res_features actually contains the top level function
that bridges the audio.
Asterisk has no protection of its API. The majority of the functions and data structures are public
and can easily be misused or bypassed. The core is anarchy with assumptions about channels
having a file descriptor, which is not always necessary in reality but is mandatory for any
asterisk channel. Many algorithms are repeated throughout the code in completely different ways
with every application doing something different on seemingly identical operations.
This is only a brief summary of the leading issues I had with Asterisk. I donated my time as a
coder, my servers to host the CVS repository and served as a bug marshal and maintainer. I
organized a weekly conference call to plan for the future and address some of the issues I have
described above. The problem was, when one looks at this long list of fundamental changes then
thinks about how much work it would take and how much code may have to be erased or
rewritten, the motivation to address the issues begins to fade. I could tell not many people would
be on board with my proposal to start a 2.0 branch and rewrite the code. That is why in the
summer of 2005 I decided I would do it myself.
My primary focus on FreeSWITCH was to start from the core and trap all the common
functionality under the hood and expose it in a pyramid to the higher levels of the application.
Like Asterisk, the Apache Web Server heavily inspired me and I chose to use a modular design.
From the first day the basic fundamentals I chose to adhere to were that every channel has it’s
own thread no matter what it was doing and that thread would use a state machine function to
navigate its way through the core. This would ensure that every channel would follow the same
predictable path and state hooks and overrides could be placed into the machine to add important
functionality very similar to how methods and class inheritance works in an object oriented
programming language.
It hasn’t been easy. Let me tell you. I’ve had my fair share of Segmentation Faults and
Deadlocks while coding FreeSWITCH , (a lot more of the former than the latter I must say). But
I built the code from the core and went from there. Since all of the channels operate in their own
thread and there are occasions where you need to interact with them, I use read/write locking so
the channels can be located from a hashing algorithm rather than a linked list and there is an
absolute guarantee that the channel cannot be accessed or go away while an outside thread has
reference to it. This alone makes it much easier to sleep at night and obsoletes the need for
“Channel Masquerades” and other such voodoo.
The majority of functions and objects supplied by the FreeSWITCH core are protected from the
caller by forcing them to be used the way they were designed. Any concept that is extensible or
provided by a module has a specific interface which is used to front end that functionality
therefore the core has no linking dependency on any of its modules.
There is a clear cut layered API with the core functions being on the bottom and the amount of
functions on each subsequent layer decreasing as the functionality increases.
For instance it’s possible to write a large function that uses an arbitrary file format module to
open and play audio to a channel. But in the next layer of API there is simply a single function
that will play a file to a channel that is then extended to the dial plan tools module as a tiny
application interface function. So you can execute the playback from your dial plan, from your
custom C application using the same function or you can write your own module that manually
opens the file and plays it all using the services of the file format class of modules without ever
divulging it’s code.
FreeSWITCH is broken into several module interfaces. Here is a list of them:
Dialplan:
Implement the ring state of a call, take the call data and make a routing decision.
Endpoint:
Protocol specific interface SIP, TDM etc.
ASR/TTS:
Speech recognition and synthesis.
Directory:
LDAP type database lookups.
Events:
Modules can fire existing core events as well as register their own custom events
Which can be parsed from an event consumer at a later time.
Event Handlers:
Remote access to events and CDR.
Formats:
File formats such as wav.
Loggers:
Console or file logging.
Languages:
Embedded languages such as Python and JavaScript.
Say:
Language specific modules to construct utterances from sound files.
Timers:
Reliable timers for packet interval timing.
Applications:
Applications you can execute on the call such as Voicemail.
FSAPI (FreeSWITCH API interface [see I use initials too!] )

Command line functions, XMLRPC functions, CGI type functions, Dialplan function variables
exposed with a string in, string out prototype.
XML
There are hooks to the core XML registry that make it possible to do realtime
lookups and create XML based CDRs
All of the FreeSWITCH modules work together and communicate with each other only via the
core API and the internal event system. Great care was taken to ensure this and avoid any
unwanted behavior from outside modules.
The event system in FreeSWITCH was designed to keep track of as much as possible. I designed
it under the assumption that most users of the software would be connecting to FreeSWITCH
remotely or using a custom module to gather call data. Thus, every important thing that happens
in FreeSWITCH results in an event firing. The events are very similar to an email format having
headers and a body. Events can be serialized into either a standard text format or an XML
representation. Any number of modules may be written to connect to the event subsystem and
receive events about presence, call state and failures. The in-tree mod_event_socket provides a
TCP connection on which events can be consumed as well as log data. In addition call control
commands may be sent over this interface as well as bi-directional audio flow. The socket can be
established by either an in-progress call as an outbound connection or from a remote machine as
an inbound connection.
Another important concept in FreeSWITCH is the centralized XML registry. When

FreeSWITCH loads it opens a top-level XML file which is fed into a pre-processor that parses
special directives to include other smaller xml files and to set global variables which can be
referenced from that point forward to template the configuration.
For instance you can set the preprocessor directive to set a global variable like this:
<X-PRE-PROCESS cmd="set" data="moh_uri=local_stream://moh"/>

now even on the next line in the file you can use $${moh_uri} and it will be replaced by
local_stream://moh in the post processed output. The final post processed registry is loaded into
memory and accessed by the modules and the core to provide several vital sections to the
application:
Configuration
Configuration data to control the behaviour of the application.
Dialplan
An XML representation of a dialplan that can be used by mod_dialplan_xml to
route calls and execute applications.
Phrases
A markup of IVR phrase macros to use from IVRs and to speak multiple languages.
Directory
A collection of domains and users for registration and account management.
Using XML hook modules, you can bind your module to lookups in the XML registry and, in
real time, gather the required information and return it to the caller in place of the static data in
the file. This makes it possible to do purely dynamic SIP registrations and dynamic voice
mailboxes and dynamic configuration of a cluster using the same model as a web browser and a
CGI application.
With embedded languages such as JavaScript, Java, Python and Perl, it’s possible to write
scripted application that can control the underlying power with a simple high-level interface.
The first phase of the FreeSWITCH project was to create a stable core on which to build scalable
applications. I am happy to report that it will be completed on May 26th 2008 with the release of
FreeSWITCH 1.0 “phoenix”. We have been able to out perform Asterisk by a factor of 10 in
similar situations according to the accounts of two separate early adopters brave enough to go
into production pre-1.0.
I hope this explanation is sufficient to outline the difference between FreeSWITCH and Asterisk
and will shed some light on my decision to start the FreeSWITCH project. I will forever remain
an Asterisk developer due to my vast involvement in the project and I wish them all the luck in
the world with the future design of the application. I may even dig up some more of my long lost
Asterisk code in my personal archives and release it to the public as a gesture of good will
towards the project that gave me my start in telephony.
Asterisk is an open source PBX and FreeSWITCH is an open source soft switch. There is plenty
of room for both applications among the other great open source Telephony applications such as
Call Weaver, Bayonne, sipX, OpenSER and many many more. I look forward every year to
presenting with and talking to all the developers of these projects at ClueCon in Chicago this
summer. http://www.cluecon.com
We can all inspire each other to push the envelope on Telephony even farther. The most
important question you can ask is. “Is it the right tool for the job?”

Asterisk Secret

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Asterisk Secret

Загружено:

Авторское право:

Доступные форматы

Asterisk NAT and Firewall related issues with SIP

1.1 Description of the problem:

1.2. related asterisk configuration settings:

The port used by asterisk for the signaling (default=5060)

You should only set it if asterisk is behind a NAT and trying to

These options will use the default value of 2 seconds.

This will disable the checking of the peer.

c) Qualify=”some numeric value

This will set the amount of ms between to checks”

1.3. Different types of NATs and firewalls.

1.3.1 Full Cone NAT

1.3.2 Restricted Cone:

1.3.3 Port Restricted Cone:

1.3.4 Symmetric Nat:

There is no nat in between => no problem

No nat is being used between them => no problem.

Problem is similar to the problem in xxx

There is no nat in between => no problem

No nat in between => no problem

1.4.9 Asterisk inside a NAT, phone / gateway inside ANOTHER NAT

1. PBXA sends a SIP invitation to PBXB on PhoneA's behalf. In this invitation, it is

[YOURREMOTEPEER] ; your peer's name

iptables -t nat -A PREROUTING -i eth0 -p udp \

Sniff out VoIP problems with Wireshark.

Figure 1. Wireshark Capture Options Dialog Configured for VoIP Analysis

Monitoring: It's All About Location

Figure 3. Wireshark's Graphical Interpretation of a SIP Conversation

Figure 4. Wireshark's Display of a SIP Packet Containing an SDP Message

 a—attributes, such as codecs and silence suppression.

Figure 5. Wireshark's List of Found RTP Streams

Figure 6. RTP Stream Analysis of a Stream with Excessive Packet Drops

Telecom Terms and Concepts: www.oreillynet.com/pub/a/etel/2006/02/07/telecom-terms-and-

Asterisk and dialing URIs

exten => _[a-z].,1,Macro(uridial,${EXTEN}@${SIPDOMAIN})

; First, assume it’s not a sip: type address

Asterisk and an AS5350 SIP peer

My goals here were simple:

1. People dialing 555-1111 should be picked up by the AS5350′s internal modems

voice service voip

SIP Outbound Proxy Server Explained

Why do IP Phones require a setting for ‘Outbound Proxy

The use of DNS SRV records to identify SIP Proxy Servers

What is the function of a SIP Outbound Proxy Server?

What value should I set for ‘Outbound Proxy Server’?

What happens if an Outbound Proxy Server is not specified?

IP Phone Configuration: SIP Proxy Server

What is the ‘SIP Proxy Server’ setting on an IP phone?

Snom Aastra Grandstream Linksys

Registrar Proxy Server SIP Server Proxy

Proxy Server vs. Outbound Proxy Server

What is the function of a SIP Proxy Server

Some Frequently Asked Questions about Proxy Servers and

My IP phone allows me to specify more than one Proxy Server. Why?

User account: SIP Registrar/SIP Domain

Absolutely no agreement here between manufacturers on what to call this. In my opinion it

SIP Server Identification: SIP Registrar Server

SIP Server Identification: Outbound Proxy

What is a STUN Server?

14:40:27.703 StunClient::process [CM506002]: Resolved SIP external IP:port (64.233.167.99:5060) on Transport

14:40:27.703 StunClient::process [CM506002]: Resolved SIP external IP:port (64.233.167.99:24842) on Transport

Using NSlookup to check records

Nslookup –q=srv _sip._udp.3cx.com

Additional routable subnets

1. STUN resolution is working. – reviewed in status log.