2600hz Blog

In our previous post, we talked about the differences between OpenSIPs and FreeSWITCH for handling call delivery. We will continue with that topic today. 

Now that we’ve understood the differences between FreeSWITCH and OpenSIPs we’ll take a deeper dive into the technical implementation features available in FreeSWITCH to support OpenSIPs (or any third-party proxy) as a front-end.

FreeSWITCH Support for OpenSIPs (or any proxy)
FreeSWITCH, in its quest to integrate with anything, has done a fairly good (and quickly approaching excellent) job at allowing integration with OpenSIPs. By default, if you route packets from an OpenSIPs box to FreeSWITCH, FreeSWITCH will analyze the headers in the SIP packet and figure out that the packet started somewhere else. Then, responses will automatically be directed back in the same direction they came in, which is incredibly useful for a variety of scenarios (we’ll cover these in next week’s post). In addition, IP-based authentication features are smart enough in FreeSWITCH to substitute the original IP address for the IP address of OpenSIPs on inbound packets.

Specifically, FreeSWITCH natively supports the following features:

X-Auth-IP Headers
In most cases FreeSWITCH needs to know the original source IP address of the SIP packet that is coming to it. Since these packets first hit OpenSIPs and then FreeSWITCH, this information is normally lost. To solve this problem, OpenSIPs can be programmed to add the original source IP address in a custom header named X-Auth-IP. It looks like this: X-Auth-IP: 74.23.22.11

When added, FreeSWITCH will automatically identify that the original IP address of the packet is 74.23.22.11. All security/access control checks and subsequent IP address information will be recorded using this source IP address.

Support for ACLs that identify proxies
FreeSWITCH supports the ability to accept packets and identify them from a SIP proxy. When used in conjunction with X-Auth-IP header mentioned above, this restricts who is allowed to submit a packet with X-Auth-IP enabled. This is an important protective measure because otherwise anyone could send a packet and fake the X-Auth-IP header and trick FreeSWITCH into thinking the source IP address was different. This way, you define where your OpenSIPs boxes are and then FreeSWITCH will only process X-Auth-IP headers from those boxes.

Support for Path Headers
The path header is assigned by OpenSIPs which allows FreeSWITCH to recognize, record and then save that header to know how FreeSWITCH should first route that call when inviting the device that has registered. As shown in the image below, when there is an established path header, FreeSWITCH must first route the call through OpenSIPs to invite that registered device. 

Support for Proxies During Registrations
FreeSWITCH automatically adds the ;fs_path=2.3.4.5 parameter when a phone registers. This parameter basically says “here’s the path to take in order to get back to this device.” This allows the packet to traverse back through the same proxy that the registration was originally received on. This is extremely important as it allows one or more FreeSWITCH boxes to contact a device via OpenSIPs and the device will always see the packets as coming from the same IP address. This helps handle a tremendous number of [Network Address Translation] NAT-related issues for you transparently.

Support for Originating Calls via Proxies
FreeSWITCH supports passing the ;fs_path=2.3.4.5 parameter manually via originate strings to Sofia. This parameter instructs Sofia to route calls via a proxy (like OpenSIPs). Unlike registrations (mentioned above) which automatically add this header, adding it manually lets you explicitly dictate when OpenSIPs should be used and if you have more than one server, it dictates which OpenSIPS server should be used when.

What’s Lacking in FreeSWITCH (and what we’re patching and contributing back!)
FreeSWITCH has done a great job with basic call flows in and out of OpenSIPs, but when it comes to SUBSCRIBE, NOTIFY, OPTIONS and other SIP messages, there is still much to be desired. Already in the FreeSWITCH tree (link) you will see some contributions from our team that fix these issues, with more on the way.

Specifically, the C code doesn’t always properly format proxy information for the sofia (SIP) library and sometimes packets get ignored or dropped on response even though they are properly received in FreeSWITCH. This is currently the case for OPTIONS, NOTIFY and some other packets. But don’t fret – pending patches will easily fix this and 2600hz is working on automated test routines to ensure this functionality doesn’t break in the future, even as improvements and new integrations are introduced.

To Sum it all Up
In Summary, OpenSIPs and FreeSWITCH make a killer combination. It takes some work to get things working perfectly, but ultimately the two serve different complementary roles that allow you to build extremely scalable telecom systems. We encourage folks trying to scale their platforms to become skilled in both platforms.