Routing script tutorial:Mini Development Guide - Revision history

Allyntree: /* Custom user context */

2021-03-10T19:16:53Z

Custom user context

2021-03-10T19:15:00Z

ring_tone_state

2021-03-10T19:12:40Z

Example 3

2021-03-10T19:12:15Z

Example 2

2021-03-10T19:10:38Z

Example 1

2021-03-10T19:10:05Z

Routing calls toward registered users

2021-03-10T19:08:56Z

Route parameters

2021-03-10T19:08:03Z

Exceptions

2021-03-10T19:07:08Z

sip_scheme

2021-03-10T19:05:43Z

Screening values for Calling number, Calling Subscriber (Generic Number), and Location Number

@@ Line 2,383: / Line 2,383: @@
 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 time for the same call are:
+Cases where routing is called multiple times for the same call are:
 - Call transfer requests
 - SIP redirect requests

@@ Line 1,639: / Line 1,639: @@
 * '''alerted''' (default):      Ring tone starts playing only once outgoing call is alerted (but won't play if alert indicates early media from outgoing call)
-This option also apply when params[:bridge][:ring_tone] is not used, because it also apply to ring tone playback configured in the Web Portal, from the incoming call's profile.
+This option also applies when params[:bridge][:ring_tone] are not used, because it also applies to ring tone playback configured in the Web Portal, from the incoming call's profile.
 === busy_tone  ===

@@ Line 1,529: / Line 1,529: @@
 ==== Example 3 ====
-The following example will play file1.wav once, ending at offset of 30 seconds.
+The following example will play file1.wav once, ending at an offset of 30 seconds.
    "file1.wav:0:0:30000"

@@ Line 1,525: / Line 1,525: @@
 ==== Example 2 ====
-The following example will play file1.wav from start offset of 1 second to end offset of 3 seconds, then twice file2.wav from second 5 to second 10.
+The following example will play file1.wav from a start offset of 1 second to an end offset of 3 seconds, followed by file2.wav being played two times from second 5 to second 10.
    "file1.wav:0:1000:3000,file2.wav:2:5000:10000"
 ==== Example 3 ====

@@ Line 1,521: / Line 1,521: @@
 ==== Example 1 ====
-The following example will play file1.wav once, and then play file2.wav in loop:
+The following example will play file1.wav once, and then play file2.wav in a loop:
    "file1.wav,file2.wav:-1"
 ==== Example 2 ====

@@ Line 1,480: / Line 1,480: @@
 == Routing calls toward registered users ==
-Static routes normally chose an outbound NAP to forward the call to.
+Static routes normally choose an outbound NAP to forward the call to. It is also possible to create routes from which the outbound NAP is dynamically chosen by matching a registered user (when using [[Sip_registration_forwarding|SIP registration forwarding]]).
-−
-But it's also possible to create routes which outbound NAP is dynamically chosen by matching a registered user (when using [[Sip_registration_forwarding|SIP registration forwarding]]).
 More information can be found [[Sip_registration_forwarding#SIP_Calls_routing|here]] about the way to control the [[Sip_registration_forwarding#SIP_Calls_routing|priority of "dynamic" vs "static" routes]].

@@ Line 1,474: / Line 1,474: @@
    route[:remapped_nap]
-Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.
+Additionally, it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.
 For example:
 *priority

@@ Line 1,329: / Line 1,329: @@
 ==== Exceptions ====
-'''Note:''' Some parameters are reported as their own call attribute (oli, isub, cpc, transport) so they have the same representation for all protocols (SS7, IDSN, SIP). They won't appear present in the generic SIP header parameters structures above.
+'''Note:''' Some parameters are reported as their own call attribute (oli, isub, cpc, transport) so they have the same representation for all protocols (SS7, IDSN, SIP). They will not appear in the generic SIP header parameters structures above.
 ==== Forwarding from inbound to outbound call ====

@@ Line 1,256: / Line 1,256: @@
 ==== sip_scheme  ====
 (Available in Toolpack 3.1+)
-This call parameters indicates the scheme (generally "sip" or "sips") of the incoming call.
+This call parameter indicates the scheme (generally "sip" or "sips") of the incoming call.
-This also allows to control the scheme used for the outgoing call (regardless if request_uri_forward_enabled is used or not)
+This also allows the control of the scheme used for the outgoing call (regardless if request_uri_forward_enabled is used or not)
 Note: sips scheme must only be used on TLS NAPs (will cause call routing failure if NAP has only UDP or TCP transport types).

@@ Line 1,157: / Line 1,157: @@
 === Screening values for Calling number, Calling Subscriber (Generic Number), and Location Number  ===
 The text below represents the value normally used by routing script.<br>
-Incase it's required to use a value that's not defined in the text values below, a integer can be provided and will be used "as-is" in the signaling message.<br>
+In case it is required to use a value that is not defined in the text values below, an integer can be provided and will be used "as-is" in the signaling message.<br>
 Example numeric values for the SS7 protocol are shown in parenthesis.<br>
 <br>