Routing script tutorial:Mini Development Guide: Difference between revisions

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.

@@ Line 58: / Line 58: @@
 [[Routing Script Tutorial: NAP Status and other NAP Information|Learn how to use NAP status field in routing scripts.]]
-== Telephony Services (CNAM Request over SS7==
+== Telephony Services (CNAM Request over SS7)==
 [[Routing Script Tutorial: CNAM Request|Learn how to manage CNAM requests over SS7.]]
-== Custom user context ==
+== 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.
+[[Routing Script Tutorial: Custom User Context|Custom User Context]]
-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:
+== Routing Script Tests ==
-  params[:user_context]
+[[Routing Script Tutorial: Routing Script Tests|Learn how to use the Web Portal to test your routing scripts.]]
-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.