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

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 subnetexternip=x.x.x.x ; use your address

[YOURREMOTEPEER] ; your peer's namenat=yesqualify=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 usertpend=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.10iptables -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 addressexten => 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 thenexten => 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 dialexten => s,n,Set(destination=${ARG1:6})exten => s,n,GoTo(nowdial,1); At this point it’s a proper uriexten => 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 channelscontroller 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 callinterface Serial3/0:23 isdn incoming-voice modem! Use a data dial-peer to answer anything to 555-1111 with a modemdial-peer data 10 pots incoming called-number 5551111! Match inbound calls to the voice DIDsdial-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 belowdial-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 serversip-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 Explainedby 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:

Snom Aastra Grandstream Linksys

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:

Snom Aastra Grandstream Linksys

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!

Snom Aastra Grandstream Linksys

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:

Snom Aastra Grandstream Linksys

Outbound ProxyOutbound Proxy Server

Outbound Proxy Outbound Proxy

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:506014: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:506014: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 10 10 5060 smallbox2.example.com._sip._udp.example.com. 86400 IN SRV 10 10 5066 smallbox2.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.comThis 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@sipgate13: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.0Record-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.0Via: SIP/2.0/UDP 172.20.40.4;branch=z9hG4bK11d4.8a4bf394.0Via: SIP/2.0/UDP 217.10.79.23:5060;received=217.10.68.6;branch=z9hG4bK7d2a0377Via: SIP/2.0/UDP 217.10.66.71:5060;branch=z9hG4bK7d2a0377;rport=5060From: “0015552368″ <sip: 0015552368@sipgate.co.uk>;tag=as21013b10To: <sip: 8632606@sipgate.co.uk>Contact: <sip: 0015552368@217.10.66.71>Call-ID: 38b34a2512c9c1903d5d5940348c18f4@sipgate.co.ukCSeq: 102 INVITEMax-Forwards: 67Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFYSupported: replacesContent-Type: application/sdpContent-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 : 415551234Authentication ID : 8632606Authentication Pass : $ecret_W0rdThe 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=as33577b1cVia 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 ofthe clone channel into the original channel. Start by killing off the originalchannel's backend. I'm not sure we're going to keep this function, becausewhile 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 eventsWhich 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.

XMLThere are hooks to the core XML registry that make it possible to do realtimelookups 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:

ConfigurationConfiguration data to control the behaviour of the application.

DialplanAn XML representation of a dialplan that can be used by mod_dialplan_xml toroute calls and execute applications.

PhrasesA markup of IVR phrase macros to use from IVRs and to speak multiple languages.

DirectoryA 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?”