Understanding routing calls in FreeSWITCH

Routing calls is the very essence of FreeSWITCH. Moving calls around can assume very different meanings and use very different techniques, depending on the scenario and with which aims it is done. You don't use the same tools and interaction level for an enterprise PBX, a telemarketing dialer, and a provider-to-providers minutes exchange.

FreeSWITCH's remote console at startup

Wholesale (provider to providers)

FreeSWITCH supports a multitude of useful features for call routing services. When we describe call routing, we are referring to connecting Party A with Party B. These routing scenarios are generally heavy on logic regarding cost analysis, interconnections with other carriers, and user permissions. These routing scenarios also typically exclude features the user directly interacts with (such as voicemail or auto attendants).

FreeSWITCH can be utilized as a powerful wholesale routing engine. Several built-in modules exist to assist in this, such as mod_lcr or mod_nibblebill, but the real beauty of FreeSWITCH's handling of calls in a wholesale scenario is due to four core building blocks:

• The ability to remain in the audio path or get out of the audio path, as needed
• The ability to transcode, which helps correct problems between pieces of VoIP equipment which aren't compatible
• The ability to maintain information about caller and callee in variables, and to manipulate those values as the call is progressing (such as tracking how much money someone has left in their account, or what the per-minute rate of the call is)
• The ability to bridge calls and handle failures and retries when calls don't connect, using a variety of call progress monitoring and failure handling routines which are built-in to FreeSWITCH

FreeSWITCH's flexible design aids in providing a tremendous amount of customization and capabilities as well. Examples include the ability to add transcoding support for codecs at any moment during the call in a way that will automatically and inherently work with any other codecs which are installed, and the ability to add custom handling for failures in a way that suits your environment.

Wholesale services typically represent high-volume customers who want to:

• Configure a client for making calls and associate monetary value with each individual client ("current balance" or "amount spent" are examples)
• Allow a client to attach phones, PBXs, other switches, or ancillary equipment
• Track a client's usage of said service based on what they connected, where they called, and how long they talked, and potentially apply discounts or premium fees based on time-of-day, destination, or other variables
• Detect fraud, abuse, or lack of funds automatically, both at call start and mid-call
• Allow for prompts and menus to automatically add funds or "top-up" services
• Allow for reporting

FreeSWITCH is capable, out of the box, of providing all of these services with simple dial plan configuration. Additionally, FreeSWITCH can be attached to a web, mobile, or legacy user interface to allow for users to manage their account, services, and monetary assets.

Residential uses of FreeSWITCH

FreeSWITCH stands as one of the best open source class 4 (and class 5) switch options, and is often the undisputed champ in many different roles because of the number of features offered by the many ready-made modules. It is definitely an excellent choice for the Internet Telephony Service Provider (ITSP), but let's not forget one of its simplest use cases: Residential service.

Some residential options include things like Network Address Translation (NAT) when configuring end-user devices like Analog Telephone Adapters (ATA). This can be challenging when working with disparate networks and client devices residing on LANs behind residential gateways and firewalls.

FreeSWITCH has configurable options for its Session Initiation Protocol (SIP) stack (called Sofia) especially designed to overcome these hurdles and provide a viable solution for residential service.

Some reasons why FreeSWITCH makes a good choice for residential service are:

• It is easily embeddable in low power devices
• It has easy configuration of end-user devices for home networks
• It had standard voicemail services via mod_voicemail
• It has advanced voicemail options using an Interactive Voice Response (IVR) enabled audio navigation system
• It has custom scripting options for things like Unified Communications

Routing with federated VoIP

Federated VoIP is a distributed Voice over IP network composed of autonomous systems.

Federated VoIP is to telephony what internet e-mail is to messaging. Particularly, it allows for the free flow of traffic without depending on a central exchange (or exchanges), just like e-mail does not depend on a central post office. It works by exchanging mail messages directly between organizations' (or even personal) Mail Servers that have the authority and capability of managing their own traffic.

Let's continue with the example of e-mail (of note, SIP was based on SMTP and HTTP protocols, that is, the protocols that orchestrate mail and the Web). So, here's the trick: no central authority is involved, it's all peer-to-peer exchange of messages in a worldwide network that works with extreme overall reliability day in and day out for billions of people and trillions of communication exchanges.

Exactly the same criteria can be applied to Voice over IP (SIP) and Instant Messaging (SIMPLE or XMPP), basing all communication exchanges around the concept of a personal address like an e-mail address, which is used both by SIP and IM, and often exactly the same for both clients. The example address [e-mail] could be used for all unified communications with Joe.

Initially, VoIP had been popularized as a better and cheaper way to manage traditional telephony traffic and to connect to traditional voice carriers. Then it was adopted by the carriers themselves because of its better suitability to modern digital networks and compatibility between hardware providers. So, today's approach to VoIP often brings an unnecessary prejudice about dependency from carriers.

Federated VoIP gets rid of this, having autonomous servers exchanging their communications, finding each other via DNS (queries about destination address) without the need for central authority and/or carriers, just like the e-mail system. Around this core concept has grown an ecosystem of encryption, mapping, and resolving traditional telephone numbers via DNS (ENUM) and other additional services. It should be noted that there is no technical requirement for encryption in Federated VoIP.

FreeSWITCH has all the features needed by Federated VoIP:

• Full encryption support: TLS and STCP for signaling, SRTP and ZRTP for media
• DNS SRV query support
• ENUM mapping support
• NAT traversal support
• Full codec support and transcoding
• IM support via SIP's SIMPLE (can be gatewayed by an XMPP server like Jabberd)
• Presence support via SIMPLE (can be gatewayed by an XMPP server like Jabberd)
• FreeSWITCH can act as an inbound and outbound gateway with PSTN and cellular networks (for example, GSM, etc), offering ENUM termination service to calling parties

FreeSWITCH is able to work as a complete, self-sufficient autonomous system or as a part of a bigger composite system with one or more SIP proxies, like Kamailio or OpenSIPS, taking care of routing, proxying, load balancing, and so on.

Dialers/telemarketing

The subject of dialers and telemarketing often makes system administrators and telephony switch operators queasy with anxiety when they are considering the limitations of their networks, hardware capability, and other system resource implications with the onslaught of marketing campaigns directed to their customers. This certainly does not stop FreeSWITCH from being a great choice when writing dialer and telemarketing applications, and not all dialer and telemarketing systems should have negative connotations.

FreeSWITCH is a natural front-runner when choosing a softswitch for writing dialer and telemarketing applications because of the small learning curve needed to develop applications in a variety of programming languages, and the excellent community support.

A developer can create a custom dialer application in FreeSWITCH utilizing a core switch database data in real-time to drive the logic. They can utilize modules like mod_event_socket to connect to the switch and perform API functions like initiating calls and managing IVRs for things like credit card payment, billing and collection, or opt-in and opt-out campaign functionality.

Not all telemarketing and dialer applications are used for marketing. Some ways FreeSWITCH is currently being utilized for dialers and telemarketing are:

• Delivering inclement weather school-closing notification recordings to telephone lists
• Auto-dialing church congregation members to connect them to IVR applications for surveys and volunteering
• Notifying political constituents of party meetings and gatherings
• Live agent outbound calling for fundraising or event coordination
  

  Some rows from FreeSWITCH's remote console help