Book Image

FreeSWITCH Cookbook

By : Raymond Chandler, Darren Schreiber, Anthony Minessale II, Michael Collins
Book Image

FreeSWITCH Cookbook

By: Raymond Chandler, Darren Schreiber, Anthony Minessale II, Michael Collins

Overview of this book

FreeSWITCH is an open source telephony platform designed to facilitate the creation of voice, chat, and video applications. It can scale from a soft-phone to a PBX and even up to an enterprise-class softswitch.In the FreeSWITCH Cookbook, members of the FreeSWITCH development team share some of their hard-earned knowledge with you in the book's recipes. Use this knowledge to improve and expand your FreeSWITCH installations.The FreeSWITCH Cookbook is an essential addition to any VoIP administrator's library.The book starts with recipes on how to handle call routing and then discusses connecting your FreeSWITCH server to the outside world.It then teaches you more advanced topics like CDR handling, practical examples of controlling FreeSWITCH with the event socket, and configuring many features commonly associated with a PBX installation.
Table of Contents (12 chapters)
FreeSWITCH Cookbook
About the Authors
About the Reviewers

Manipulating To: headers on registered endpoints to reflect DID numbers

Sometimes, when routing calls to endpoints that are registered to your system, you want to utilize custom To: headers. For example, if you are routing DIDs to a PBX or switch, the device you are calling might expect the phone number you wish to reach in the To: header. However, the customer or PBX may only have a single registration to your service that represents multiple DIDs that need to be routed.

By default, no flags exist to change the To: header to match the DID when calling a registered endpoint. Since the registration to your server is typically done via a generic username that is not related to the DID, you must program your dialplan to retrieve a user's registration information and parse out the username portion of the To: header, replacing it with your own. Care must be taken to replace only the username portion and to keep the remaining parameters intact, especially if NAT traversal is expected to continue operating.

Getting ready

Be sure that you have your DIDs and users configured. In this example, we will use testuser as the username with a phone number of 4158867999 and our domain is my.phoneco.test.

How to do it...

Create a dialplan extension, specifically for handling calls to the DID number and use some regular expression syntax to parse out the information. Here is an example:

<extension name="call_4158867999">
  <condition field="destination_number" expression="^\+?1?4158867999$"/>
  <condition field="${sofia_contact([email protected])}" expression="^[^\@]+(.*)">
    <action application="bridge" data="sofia/external/4158867999$1"/>

How it works...

You would typically make bridge calls to testuser using the bridge command with an argument of user/testuser. In this scenario, however, you wish to call testuser's registered endpoint but replace testuser with a phone number – 4158867999, in our example. To do this, you must retrieve testuser's current dialstring and remove the username, replacing it with the DID number.

In the example, we leverage the sofia_contact API and some regular expression magic. The first condition simply matches the user's DID phone number—we only want to act if the destination number is 4158867999. The interesting stuff happens in the second condition. The field is ${sofia_contact([email protected])}. By wrapping an API call in ${}, the dialplan literally executes the API and uses the result as the field value. If we go to fs_cli and type sofia_contact [email protected], we get the result, which is something like this:

sofia/external/[email protected];fs_nat=yes

The regular expression pattern ^[^\@]+(.*) is applied against this value. The result is that everything after the @ is placed in the $1 variable. In our example, $1 contains @;fs_nat=yes. Finally, we execute the bridge with the dialstring sofia/external/4158867999$1. With $1 expanded out, our destination is as follows:

sofia/external/[email protected];fs_nat=yes

We have successfully replaced testuser with 4158867999 while preserving the necessary IP address and parameters for contacting the server and sent the call to the proper destination.