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(testuser@my.phoneco.test)}" expression="^[^\@]+(.*)">
<action application="bridge" data="sofia/external/4158867999$1"/>
</condition>
</extension>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(testuser@my.phoneco.test)}. 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 testuser@my.phoneco.test, we get the result, which is something like this:
sofia/external/johndoe@12.34.56.7;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 @12.13.56.7;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/4158867999@12.34.56.7;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.
