Routing Script tutorial: A Mini Development Guide
Introduction
This Routing Script Tutorial provides you with essential information in managing the routing of your calls. Consult the sections below to learn more.
Accessing Routing Script Parameters
Learn how to access routing script parameters.
Routing Script Parameter Mapping Table
Learn how each Routing Script Parameter maps to varying protocols.
Script Parameters Definition
Learn about the definition of each script parameter.
Script Parameters Definition for SIP
Learn about the definition of each script parameter for SIP.
Registered Users Information
Learn how routing scripts access information about registered users.
Route Parameters and Call Routing
Learn about the standard parameters used in a call and how they route to registered users.
Playing prompts announcements or tones
Learn how to play all sorts of media files for call prompts, announcements, and tones.
Recording
Learn how to use routing scripts to record incoming and/or outgoing call legs.
User-to-User Information
Learn how to use User-to-User Information (UUI) in routing scripts.
Radius Autorization
Learn how to send RADIUS authorization requests in routing scripts.
ENUM Query
Learn how to send ENUM Query requests to DNS servers in routing scripts.
DNS Query
Learn how to send DNS Query requests to DNS servers in routing scripts.
Call Diversion Options
Learn how control a call flow with diversion options.
Call Transfer Requests
Learn how to route call transfer requests.
Redirection
Learn how to get redirection contacts.
Connected Number
Terminating Calls
Learn how to terminate calls with routing scripts.
NAP status and other NAP information
Learn how to use NAP status field in routing scripts.
Telephony Services
In release 2.10 and the above, telephony services (CNAM Request) can be manage from the routing engine in the following format:
params[:telephony_services].each do |service| -> Array of telephony services
service[:name] -> Customer telephony service name
service[:type] -> For now only "CNAM Request"
service[:enabled] -> Indicate if the service is enabled (true) or not (false)
(Only the telephony service define in the profile associated to the NAP is enabled)
(The others telephony services define in others profiles are disabled)
(If we are in the case where we return in the routing script with a response, it is important to set :enabled to false in order to avoid repeating the same query)
serviceParams = service[:params]
serviceParams[:return_to_script] -> Indicates to Gateway if we must return to the routing script after receiving the CNAM response
(It is important to set back to false this field to avoid an infinite loop)
serviceQuery = service[:query]
serviceQuery[:phone] -> 10 digits of calling number from the incoming call to send to the CNAM server
serviceQuery[:timeout] -> Timeout in millisecond to wait a CNAM response from CNAM server
(Default value from profile configuration)
serviceResponse = service[:response]
serviceResponse[:success] -> Indicates if we received a good CNAM response from the CNAM Server (Only present if :return_to_script is set to true)
serviceResponse[:caller_name] -> The caller name received in the CNAM response from the CNAM Server (Only present if :return_to_script is set to true)
Custom user context
The routing script may save per-call information within the call context, that will be available if routing is called again later during the call flow.
Cases where routing is called multiple times for the same call are: - Call transfer requests - SIP redirect requests - Radius Authorization result - Announcement server with digit collection
The routing script can save a recursive hash of attributes here:
params[:user_context]
For example
params[:user_context] = { "SomeKey" => "Some value I want to retrieve upon next routing for this call", "OtherVal" => { "subkey" => "subval" } }
Upon first call to routing script, params[:user_context] will be nil. Upon subsequent calls to routing script, it will contain whatever the script had stored upon previous call (or nil if it was not set)
Note: This feature is available starting from release 2.9.85, 2.10.31 and 3.0.15 (in respective branches 2.9, 2.10 or 3.0)
Routing Script Tests
The Web portal features a tool for Testing Scripts. The user must enter parameters to simulate the incoming call and after pressing the Test button, will output selected routes and numbers. You do not need to activate the new routes, or the new scripts to use this test tool: It can be used to test the routing scripts and routing table before activating it. This is available in the Routing Scripts section of the Web portal.
Test parameters
@call_params
That variable should contain a hash of call parameters that will be passed to the routing script. This is equivalent to the incoming call parameters.
@nap_list
A list of the hash containing the nap statuses. This is equivalent to the nap statuses at the time the call is to be routed.
The nap list is hashed by the nap names in UPPERCASE. It is important to consider this when creating new dynamic route or nap attributes that may nap names that will be used to fetch a status.
@params
A hash of hashes containing parameters. This hash contains bridge parameters and other kind of parameter groups may be added in the future.
@params = {
:bridge => {:announcement_tone, "announcement.wav"},
:contacts => {
:index=>"1",
:list=>[
{:called_number=>"6660", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"",
:raw_data=>"", :expiration=>"3600"},
{:called_number=>"6661", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"sip:6661@192.168.215.127",
:raw_data=>"<sip:6661@192.168.215.127>", :expiration=>"3600"}
],
:source_indexes=>"nil,0"
}
}
Back to Routing Script Tutorial.