Sequential Call Hunting using AVPs
Call Hunting is a mechanism by which a proxy server trys to place a call to any one number (user) in a list of numbers. The proxy tries each number in sequence until a number answers (200 OK) or all numbers are exhausted. In this example the call will be forwarded to the voice mail mailbox associated with the original called number when all numbers have been exhausted. This example was created for a proxy running SERi 0.9.x
In this example I use MySQL for the data storage. The database also stores registrations, subscriber data and locally defined call feature/call permission flags. To enable the call hunting feature we will need a new table. MySQL setup: We create a new table for Single Attribute Multi-value data storage. We'll call this table "sam". # Into "sam" we insert multiple records for a given username. We assume the username is the primary telephone number which will receive the initial call. Multiple attributes, each called huntlist, will then be defined with unique values. Note that the values do not need to be unique however there probably isn't any reason to call the same number repeatedly. Sample sam data: In the following example we enable call hunting for extension (username) 68001. Whenever a call arrives for 68001 the proxy will attempt the contact address for that extension. If that fails the proxy will look in the "sam" table and try extension 38396. If 38396 does not answer then the proxy will try 68007. If the call to 68007 fails the proxy will send the call to the voice mail mailbox associated with 68001. That step is handled in the proxy configuration file and is discussed later in this document.
What are "call feature" flags: A subscriber may have a requirement to use traditional telephony functionality such as do-not-disturb (DNDi). At the same time a proxy administrator may wish to control access to international calling facilities. These are examples of a call feature and a call permission respectively. We implement call feature and call permission checks using AVPs. An attribute with the name of the call feature or call permission is defined in a MySQL table along with the value appropriate for a given username. When a call is placed for/by this username the proxy checks these attributes before taking action on the call (invite).
For call hunting we define the allow_hunt call feature flag as follows: UPDATE usr_preferences SET value='y' WHERE attribute='allow_hunt' AND username='68001' AND domain='myschool.edu';
Proxy configuration: Now that the "sam" table is populated and the call feature flag has been defined we need to tell the proxy server what to do with this flag. In your INVITE processing logic you want to insert the check for the call feature. In the following logic we check if call hunting is enabled by loading the "allow_hunt" call feature flag from the database. If call hunting is enabled we save the username portion of the current R-URIi. We will use this later to get an unanswered call to voice mail. After some house keeping steps we tell the proxy to proceed to failure_route #6 on failure then attempt to relay the call to the original called number. # hunting (serial forkingi)
When the call "fails" failure_route #6 is reached. In this section of the configuration file we populate the username portion of the R-URI with the value in huntlist which we read from the sam table. Once again we tell the proxy to proceed to failure_route #6 on failure and attempt to relay the call. We hunt through the huntlist by returning to failure_route #6 on each failure. If avp_pushto fails then we have exhausted the hunt list. In this case we retrieve the username portion of the original R-URI by referring to avp_alias "ocn". The call is then sent to Asterisk voice mail using our standard voice mial handling routine which is defined in route block #9. #
|
Navigation |