TBwiki - User contributions [en]

Toolpack:Creating the M2UA Configuration C

2015-08-24T14:57:15Z

Rblanchet: Added m2ua node type

=== '''''Applies to version(s): v2.8.''''' ===
{{DISPLAYTITLE:Creating the M2UA Configuration}}
To create your [[M2UA]] system, you must create a new M2UA configuration.

M2UA (Message Transfer Part 2 User Adaptation Layer) is used to interface the [[MTP2 Layer]] of a signaling gateway to the [[MTP3 Layer]] of a media gateway controller (MGC). M2UA can also be seen as a way to extend an MTP2 link. An M2UA link is always bound to an MTP2 link.

To create an M2UA configuration:

1- Click '''M2UA''' in the navigation panel

[[Image:Create_M2ua_0.png]]

2- Create the M2UA configuration:

* Enter a '''name''' for the M2UA service
* Select a '''Node Type''' (SG, ASP, M2UA-MTP2 Relay)
* Click '''Create'''

[[Image:Create_M2ua_1.png]]

3- Verify that the '''"M2ua Cfg was successfully created"''' message appears

[[Image:Create_M2ua_2.png]]

==List of Parameters==

* [[Parameter: Name|Name]]
* [[Parameter: M2UA Node Type|M2UA Node Type]]

Parameter: M2UA Node Type

2015-08-24T14:53:50Z

Rblanchet: Added m2ua node type

The Node Type parameter is used to assign a configuration to a M2UA service. Values for this parameter are chosen from a drop-down list. The Node Type parameter can take on the following values:

* Signaling Gateway (SG)
* Application Server Process (ASP)
* M2UA-MTP2 Relay

[[Category:Parameters]]

File:Create M2UA SAP 0.png

2015-08-24T14:45:58Z

Rblanchet: uploaded a new version of "File:Create M2UA SAP 0.png": Added m2ua node type

Toolpack:Creating the M2UA Configuration C

2015-08-24T14:44:38Z

Rblanchet: Added node type

File:Create M2ua 1.png

2015-08-24T14:40:56Z

Rblanchet: uploaded a new version of "File:Create M2ua 1.png": Added the node type

Route retry

2015-08-21T20:10:27Z

Rblanchet: Add route_retry_relay_progress option

== Requirements ==
'''WARNING:''' The route retry feature requires to use Routing scripts.

[[Scriptable_Routing_Engine|Click here]] to learn how to enable routing scripts.

== Route retry algorithm ==

The route retry feature applies when more than one matching route is returned by the active routing script. The route retry algorithm works the following way:

*An outgoing call will be made based on the first matching route
*If that outgoing call fails while there are other matching routes left, another outgoing call attempt is made using next matching route (enabled or disabled per [[Termination_cause_codes|termination cause]])

A call attempt is considered failed in the following conditions:

*Call is terminated by remote side before it's answered. Termination cause will determine if route retry is needed or not.
*Timeout occurs before call reaches specified call state (this timeout is ignored when last matching route is attempted)

Route retry timeout can be customized using three parameters:

*Timeout delay in seconds to reach 'minimum call state' (value of 0 makes timeout never occur)
*'Minimum call state' (also called "Route Retry Mode") to reach before the specified timeout occurs:
**Call accepted
**Call progress received
**Call alerted
**Call answered
*Relay progress messages option. Forward alert and progress messages from the current route.

If the timeout delay is passed before the call reaches the specified state, call is considered failed and retry occurs. If the call reaches that state, timeout no longer apply, but explicit termination from remote side with error cause may still trigger retry with next route.

The 4 states above correspond to the following protocol-specific events:
SIP:
Accepted: 100 Trying
Progress: 183 with SDP (*)
Alerted: 180 Ringing
Answered: 200 OK
ISDN:
Accepted: CALL PROCEEDING
Progress: PROG
Alerted: ALERTING
Answered: CONNECT
SS7:
Accepted: <none>
Progress: CPG
Alerted: ACM
Answered: CONN/ANM
CAS R2:
Accepted: SeizureAckCasBit
Progress: <none>
Alerted: GroupB SuccessDigit
Answered: AnswerCasBit

''(*) 183 with SDP is usually interpreted as a "ALERT" (not a PROGRESS) unless a quirk is enabled. The quirk is located in the configuration tabs "NAP -> Advanced" and is called "183 triggers call progress"''

== Route retry termination cause configuration ==
To control if the route retry algorithm should stop or continue to the next route, each termination cause can be configured in the profile and set to either Continue or Stop.

[[Termination_cause_codes|Click here]] to see the profile "Reason Cause Mapping" table

== Route retry global configuration ==

These route retry timeout parameters can be configured globally, per NAP, or per Route. Per-route value has precedence on per-NAP value, which has precedence on global value.

The global route retry timeout parameters are found in the Gateway application configuration page in the Toolpack Web Portal:

*Go to the Gateway->Configuration menu.
*Click on the Edit link of the configuration you wish modify.
*Expand the Advanced section
*Change values of 'Route retry mode', 'Route retry timeout' and 'Route retry relay progress messages'

== Route retry per-NAP configuration ==

The per-NAP route retry timeout parameters are configured by adding a custom 'NAP column':

*Go to the Gateway->Configuration menu.
*Click on the Edit link of the configuration you wish modify.
*Click on Create New Nap Column in the Editing Naps section
**In the Name text box, enter 'route_retry_mode'
**In the Type attributes text box, enter '|accept|call_progress|alert|answer'
**Leave the Default text box blank
*Click Save
*Click again on Create New Nap Column in the Editing Naps section
**In the Name text box, enter 'route_retry_timeout'
**In the Type attributes text box, enter 'integer'
**Leave the Default text box blank
*Click Save
*Click again on Create New Nap Column in the Editing Naps section
**In the Name text box, enter 'route_retry_relay_progress'
**In the Type attributes text box, enter 'boolean'
**Leave the Default text box blank
*Click Save

Now that these columns have been created, each time you create or edit a NAP, route retry mode and timeout will be shown under Custom Params. Leaving empty value for a NAP will make global value to be used. Assigning a value in either of these parameters will override the global value for that parameter.

== Route retry per-route configuration ==

The per-route route retry timeout parameters are configured by adding a custom 'Route column':

*Go to the Gateway->Configuration menu.
*Click on the Edit link of the configuration you wish modify.
*Click on Create New Route Column in the Editing Routes section
**In the Name text box, enter 'route_retry_mode'
**In the Type attributes text box, enter '|accept|call_progress|alert|answer'
**Leave the Default text box blank
*Click Save
*Click again on Create New Route Column in the Editing Routes section
**In the Name text box, enter 'route_retry_timeout'
**In the Type attributes text box, enter 'integer'
**Leave the Default text box blank
*Click Save
*Click again on Create New Route Column in the Editing Routes section
**In the Name text box, enter 'route_retry_relay_progress'
**In the Type attributes text box, enter 'boolean'
**Leave the Default text box blank
*Click Save

Now that these columns have been created, each time you create or edit a route, route retry mode and timeout will be shown under Custom Params. Leaving empty value for a route will make NAP value used (or global value if NAP value is also empty). Assigning a value in either of these parameters will override the NAP or global value for that parameter.

== Customize route retry parameters from routing script ==

Any part of the routing script that has access to the route can modify these parameters by reading and writing from/to:

*route[:route_retry_mode]
*route[:route_retry_timeout]
*route[:route_retry_relay_progress]

These fields initially contain value read from the added 'Custom Route Columns' (as explained above), but can be overwritten by the routing script.

== Useful links ==
*[[Tmedia_Routing|Tmedia Routing]]

Routing script tutorial:Mini Development Guide

2014-07-23T13:39:42Z

Rblanchet: Documented reason causes in routing script

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "Reason values".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
Q931: 'Facility CNAM' IE when presentation is allowed for DMS/NI2 variants 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber
(Generic Number / NDS) 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| Q931: 'Facility CNAM' IE when presentation is restricted for DMS/NI2 variants 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number
(OCN) 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli
(Originating line information) 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Insert MLPP information in the outgoing leg 
| 2.7 
|-
| mlpp_look_for_busy 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - look ahead for busy 
| N/A 
| 
| 2.7 
|-
| mlpp_precedence_level 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - precedence level 
| SIP:Resource-Priority - q735 
| 
| 2.7 
|-
| mlpp_network_identity 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - network identity 
| N/A 
| 
| 2.7 
|-
| mlpp_service_domain 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - MLPP service domain 
| N/A 
| 
| 2.7 
|-
| called_isub 
| Q931: 'Called party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - subaddress information 
| SIP:To - isub parameter 
| 
| 2.7 
|-
| called_isub_type 
| Q931: 'Called party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - type of subaddress 
| SIP:To - isub-encoding parameter 
| 
| 2.7 
|-
| calling_isub 
| Q931: 'Calling party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - subaddress information 
| SIP:From - isub 
| 
| 2.7 
|-
| calling_isub_type 
| Q931: 'Callinf party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - type of subaddress 
| SIP:From - isub-encoding 
| 
| 2.7 
|-
| ss7_fci_default 
| N/A 
| N/A 
| Default backward call indicator (FCI) value. 
| N/A 
| Toolpack will overwrite FCI bits A, D, F, I and M with appropriate values according to call conditions 
| 2.7 
|-
| ss7_fci_force_mask 
| N/A 
| N/A 
| Mask to select bits from ss7_fci_default that must be forced. 
| N/A 
| Bits from ss7_fci_default which corresponding bit in ss7_fci_force_mask is set will be forced, and no more controlled by Toolpack 
| 2.7 
|-
| ss7_bci_default 
| N/A 
| N/A 
| Default backward call indicator (BCI) value. 
| N/A 
| Toolpack will overwrite BCI bits AB, I, K, M and N with appropriate values according to call conditions 
| 2.7 
|-
| ss7_bci_force_mask 
| N/A 
| N/A 
| Mask to select bits from ss7_bci_default that must be forced. 
| N/A 
| Bits from ss7_bci_default which corresponding bit in ss7_bci_force_mask is set will be forced, and no more controlled by Toolpack 
| 2.7 
|-
| tdm_ls_name
(Line Service or T1/E1 trunk) 
| Incoming leg line service name 
| Incoming leg line service name 
| Incoming leg line service name 
| N/A 
| (read-only) 
| 2.7 
|-
| tdm_timeslot_nb 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| N/A 
| (read-only) 
| 2.7 
|-
| rtp_local_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_local_port 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP port 
| (read-only) 
| 2.7 
|-
| rtp_remote_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_remote_port 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP port 
| (read-only) 
| 2.7 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number (0x2)</tt>
*<tt>international_number (0x4)</tt>
*<tt>national_number (0x3)</tt>
*<tt>subscriber_number (0x1)</tt>
*<tt>network_specific (0x5)</tt>
*<tt>network_routing_national_format (0x7)</tt>
*<tt>network_routing_international_format (0x8)</tt>
*<tt>abbreviated_number (0x6)</tt>
*<tt>subscriber_number_operator_requested (0x71)</tt>
*<tt>national_number_operator_requested (0x72)</tt>
*<tt>international_number_operator_requested (0x73)</tt>
*<tt>no_number_present_operator_requested (0x74)</tt>
*<tt>no_number_present_cut_through_call_to_carrier (0x75)</tt>
*<tt>test_line_test_code (0x77)</tt>
*<tt>non_unique_subscriber_number (0x71)</tt>
*<tt>non_unique_national_number (0x73)</tt>
*<tt>non_unique_international_number (0x74)</tt>
*<tt>call_950_numbe (0x76)</tt>
*<tt>special_number (0x73)</tt>
*<tt>national_number_with_transit_network_selection (0x74)</tt>
*<tt>international_number_with_transit_network_selection (0x75)</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values for Calling number, Calling Subscriber (Generic Number), Redirecting Number, Original Called Number (OCN) and Location Number ===

*<tt>unspecified</tt>
*<tt>not_available (0x2)</tt>
*<tt>allowed (0x0)</tt>
*<tt>restricted (0x1)</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

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

*<tt>unspecified</tt>
*<tt>no (0x0)</tt>
*<tt>pass (0x1)</tt>
*<tt>fail (0x2)</tt>
*<tt>network_provided (0x3)</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number, Original Called Number and Diversion Reason ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy (SIP: user-busy)</tt>
*<tt>no_reply (SIP: no-answer)</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

=== Information Transfer Capability values ===

information_transfer_capability:

*<tt>digital</tt>
*<tt>restricted_digital</tt>
*<tt>digital_with_tones</tt>
*<tt>speech</tt>
*<tt>3_1_khz_audio</tt>

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

* PCAP sample: [[File:TB_Custom_SIP_Headers.pcap]]

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack:
<pre>
Accept Error-Info Remote-Party-ID
Accept-Contact Event Replaces
Accept-Encoding Expires Reply-To
Accept-Language From Request-Disposition
Alert-Info In-Reply-To Subject
Allow Max-Forwards Subscription-State
Allow-Events MIME-version Supported
Also Min-Expires Timestamp
Anonymity Min-SE To
Authorization Organization Unsupported
Authentication-Info Path User-Agent
Call-ID Priority Via
Call-Info Privacy Warning
Contact Proxy-Authenticate WWW-Authenticate
Content-Disposition Proxy-Authorization Require
Content-Encoding Proxy-Require Response-Key
Content-Language P-Media-Authorization Retry-After
Content-Length P-Preferred-Identity RPID-Privacy
Content-Type P-Asserted-Identity Route
CSeq RAck RSeq
RAck Reason Security-Client
Reason Record-Route Security-Server
Date Refer-To Security-Verify
Diversion Referred-By Server
Encryption Reject-Contact Service-Route
Session-Expires
</pre>

=== MLPP Precedence values ===

mlpp_look_for_busy:

*<tt>allowed</tt>
*<tt>path_reserved</tt>
*<tt>not_allowed</tt>

mlpp_precedence_level:

*<tt>flash_override</tt>
*<tt>flash</tt>
*<tt>immediate</tt>
*<tt>priority</tt>
*<tt>routine</tt>

mlpp_network_identity:

3 digits value from 0 to 999

mlpp_service_domain:

24 bits value from 0 to 16777215

=== ISUB subaddress information values ===

called_isub_type:
calling_isub_type:

*<tt>nsap</tt>
*<tt>nsap_ia5</tt>
*<tt>nsap_bcd</tt>
*<tt>user</tt>

called_isub:
calling_isub:

Digits for the subaddress information.

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile
*remapped_incoming_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** And all variables listed here: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Call transfer requests ==
Toolpack allows to relay [[Call transfer]] requests from one leg to the other, or to process them locally (making another outgoing call to replace the call that requested the call transfer).

If the chosen [[Call transfer]] mode is to process requests locally, upon reception of a call transfer request (SIP REFER or ISDN Facility), routing script will be called once again, to select the routes for the new outgoing call (call transfer target).

=== How to route call transfer request ===
Routing of a call transfer request is done exactly like routing of a normal incoming call.
The routing script generally does not need any modification to support that.

In some cases, the routing script may want to use information related to the transfer request to perform routing, or to insert information in the outgoing call leg.
Additional information is provided to the routing script, allowing routing decisions using information from the call transfer request (SIP REFER or ISDN Facility).
See below...

=== params[ :call ] content during transfer request ===
When processing a call transfer request, the params[ :call ] hash contains the information from the inbound call (same as was passed to the routing script upon arrival of the inbound call)
call = params[ :call ] -> Information from original inbound call, with exception of call[ :called ]

One exception (convenient because it allows a unmodified routing script to process call transfer request the same way as any other routing request):
call[ :called ] -> Replaced by the called number from the call transfer request (also called "redirection number")
Complementary information:
call[ :original_called_number ] -> Contains the called number that was initially received from the incoming call, prior to call transfer request
call[ :redirecting_number ] -> Number of the call from which the call transfer request was received (generally equals to original_called_number)

These fields will also be included in the outgoing call made after routing:
* original called number and redirecting number are existing fields on SS7 and ISDN calls
* SIP "diversion" header is used for SIP calls

=== params[ :transfer ] content ===
(this if valid only for release 2.7.102 and above) 
When processing a call transfer request, information from the call transfer request message (SIP REFER, ISDN Facility) is provided in params[ :transfer ]:
transfer = params[ :transfer ]
The following field is always present:
transfer[ :original_nap ] -> Contains the NAP of the first call from which a call transfer request was received
transfer[ :redirecting_nap ] -> Contains the NAP of the call from which the current call transfer request was received
(same as :original_nap for the first call transfer, different for subsequent transfers)
Examples of other fields that may be present, when appropriate:
transfer[ :uui ] -> The UUI (user-to-user information) found in the call transfer request
transfer[ :sip_header ] -> Contains custom SIP headers from the call transfer request
transfer[ :request_uri ] -> Contains the SIP Request URI

These field are 'read-only'. They won't be included in the outgoing call, as they represent the content of the call transfer request, not the outgoing call to make.

To insert/modify attributes of the outgoing call, the parameters from params[ :call ] must be edited instead.

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

Example to refuse an incoming call leg.
raise RoutingException, :no_route

Reason cause strings available inside routing scripts:

List of Q.850 reason causes:
:unallocated_number
:no_route_to_network
:no_route_to_destination
:send_special_tone
:misdialled_trunk_prefix
:channel_unacceptable
:call_awarded_in_established_channel
:preemption
:reattempt
:ported_number
:normal_call_clearing
:user_busy
:no_user_responding
:no_answer_from_user
:subscriber_absent
:call_rejected
:number_changed
:redirection
:exchange_routing_error
:non_selected_user_clearing
:destination_out_of_order
:address_incomplete
:facility_rejected
:response_to_status_enquiry
:normal_unspecified
:no_circuit_available
:network_out_of_order
:frame_mode_out_of_service
:frame_mode_connection_operational
:temporary_failure
:switching_equipment_congestion
:access_information_discarded
:circuit_not_available
:precedence_call_blocked
:resource_unavailable
:quality_of_service_not_available
:requested_facility_not_subscribed
:outgoing_calls_barred
:outgoing_calls_barred_within_CUG
:incoming_calls_barred
:incoming_calls_barred_within_CUG
:bearer_cap_not_authorized
:bearer_cap_not_available
:inconsistency_access_info
:service_not_available
:bearer_cap_not_implemented
:channel_type_not_implemented
:requested_facility_not_implemented
:only_restricted_digital_info
:service_not_implemented
:invalid_call_reference
:channel_does_not_exist
:call_identity_does_not_exist
:call_identity_in_use
:no_call_suspended
:call_has_been_cleared
:user_not_member_of_CUG
:incompatible_destination
:non_existant_CUG
:invalid_transit_network
:invalid_message_unspecified
:mandatory_IE_missing
:message_type_non_existent
:not_compatible_with_call_state
:IE_non_existent
:invalid_IE_content
:message_not_compatible
:recovery_on_timer_expiry
:parameter_non_existent_passed_on
:msg_with_non_recognized_param_discarded
:protocol_error
:interworking_unspecified

List of toolpack reason causes:

:toolpack_normal or :normal
:toolpack_resource_error or :resource_error
:toolpack_timeout or :timeout
:toolpack_no_route or :no_route
:toolpack_call_collision or :call_collision
:toolpack_sync_drop or :sync_drop
:toolpack_signaling_error or :signaling_error
:toolpack_locally_rejected or :locally_rejected
:toolpack_interface_not_available or :interface_not_available
:toolpack_reset_in_progress or :reset_in_progress
:toolpack_adapter_reject or :adapter_reject
:toolpack_missing_or_invalid_IE or :missing_or_invalid_IE
:toolpack_incoming_only or :incoming_only
:toolpack_system_configuration_changed or :system_configuration_changed
:toolpack_resource_no_more_available or :resource_no_more_available
:toolpack_incompatible_media or :incompatible_media
:toolpack_resource_allocation_failed or :resource_allocation_failed
:toolpack_data_path_not_available or :data_path_not_available
:toolpack_local_congestion or :local_congestion
:toolpack_authorization_required or :authorization_required
:toolpack_call_divert_is_not_allowed or :call_divert_is_not_allowed

List of SIP reason causes:

:400_bad_request
:401_unauthorized
:402_payment_required
:403_forbidden
:404_not_found
:405_method_not_allowed
:406_not_acceptable
:407_proxy_authentication_required
:408_request_timeout
:409_conflict
:410_gone
:413_request_entity_too_large
:414_request_URI_too_long
:415_unsupported_media
:416_unsupported_URI_scheme
:420_bad_extension
:421_extension_required
:422_session_timer_too_small
:423_interval_too_brief
:429_referrer_identity_error
:480_temporary_unavailable
:481_call_or_transaction_does_not_exist
:482_loop_detected
:483_too_many_hops
:484_address_incomplete
:485_ambiguous
:486_busy_here
:487_request_terminated
:488_not_acceptable_here
:489_bad_event
:491_retry_after
:500_server_internal_error
:501_not_implemented
:502_bad_gateway
:503_service_unavailable
:504_server_timeout
:505_version_unsupported
:513_message_too_large
:600_busy_everywhere
:603_decline
:604_not_exist_anywhere
:606_not_acceptable

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

Routing script call attribute name Description
--------------------------------------------------------------------------------------------
"signaling_type" Signaling type.
"inst_incoming_call_cnt" Instantaneous Count of incoming calls.
"inst_outgoing_call_cnt" Instantaneous Count of outgoing calls.
"available_cnt" Number of available circuits or channels.
"unavailable_cnt" Number of unavailable circuits or channels.
"availability_percent" Percentage of available circuits or channels.
"usage_percent" Percentage of used circuits or channels.
"unused_shared_percent" Percentage of used circuits or channels of this NAP available to make new calls with (taking into account shared with other NAPs)
"total_incoming_call_cnt" Total Count of incoming calls.
"asr_statistics_struct" Detailed Answer-Seizure Rate Statistics.
"global_asr_percent" Global calculated ASR percentage.
"total_outgoing_call_cnt" Total Count of outgoing calls.
"last_24h_asr_percent" Last 24 hours calculated ASR percentage.
"last_24h_outgoing_call_cnt" Last 24 hours outgoing calls.
"current_hour_asr_percent" Current hour calculated ASR percentage.
"current_hour_outgoing_call_cnt" Current hour outgoing calls.
"last_hour_asr_percent" Last hour calculated ASR percentage.
"last_hour_outgoing_call_cnt" Last hour outgoing calls.
"availability_detection_struct" Detailed availibility detection Statistics
"poll_remote_proxy" Remote proxy polling enabled
"is_available" Remote proxy actually available or not
"time_since_polling" Time since the last availibility polling
"time_available_seconds" Number of seconds since the NAP is available
"time_unavailable_seconds" Number of seconds since the NAP is unavailable
"registration_struct" Detailed registration Statistics
"register_to_proxy" Register to proxy enabled
"registered" Actually registered or not
"time_since_refresh" Time since the last refresh
"time_registered_seconds" Number of seconds since the NAP is registered
"time_not_registered_seconds" Number of seconds since the NAP is not registered

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== 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 passed to the routing script. This is equivalent to the incoming call parameters.

 

==== @nap_list ====

A list of 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.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2014-06-13T19:45:46Z

Rblanchet: media information available in script

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "Reason values".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
Q931: 'Facility CNAM' IE when presentation is allowed for DMS/NI2 variants 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber
(Generic Number / NDS) 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| Q931: 'Facility CNAM' IE when presentation is restricted for DMS/NI2 variants 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number
(OCN) 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli
(Originating line information) 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Insert MLPP information in the outgoing leg 
| 2.7 
|-
| mlpp_look_for_busy 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - look ahead for busy 
| N/A 
| 
| 2.7 
|-
| mlpp_precedence_level 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - precedence level 
| SIP:Resource-Priority - q735 
| 
| 2.7 
|-
| mlpp_network_identity 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - network identity 
| N/A 
| 
| 2.7 
|-
| mlpp_service_domain 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - MLPP service domain 
| N/A 
| 
| 2.7 
|-
| called_isub 
| Q931: 'Called party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - subaddress information 
| SIP:To - isub parameter 
| 
| 2.7 
|-
| called_isub_type 
| Q931: 'Called party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - type of subaddress 
| SIP:To - isub-encoding parameter 
| 
| 2.7 
|-
| calling_isub 
| Q931: 'Calling party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - subaddress information 
| SIP:From - isub 
| 
| 2.7 
|-
| calling_isub_type 
| Q931: 'Callinf party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - type of subaddress 
| SIP:From - isub-encoding 
| 
| 2.7 
|-
| tdm_ls_name
(Line Service) 
| Incoming leg line service name 
| Incoming leg line service name 
| Incoming leg line service name 
| N/A 
| (read-only) 
| 2.7 
|-
| tdm_timeslot_nb 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| N/A 
| (read-only) 
| 2.7 
|-
| rtp_local_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_local_port 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP port 
| (read-only) 
| 2.7 
|-
| rtp_remote_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_remote_port 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP port 
| (read-only) 
| 2.7 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number (0x2)</tt>
*<tt>international_number (0x4)</tt>
*<tt>national_number (0x3)</tt>
*<tt>subscriber_number (0x1)</tt>
*<tt>network_specific (0x5)</tt>
*<tt>network_routing_national_format (0x7)</tt>
*<tt>network_routing_international_format (0x8)</tt>
*<tt>abbreviated_number (0x6)</tt>
*<tt>subscriber_number_operator_requested (0x71)</tt>
*<tt>national_number_operator_requested (0x72)</tt>
*<tt>international_number_operator_requested (0x73)</tt>
*<tt>no_number_present_operator_requested (0x74)</tt>
*<tt>no_number_present_cut_through_call_to_carrier (0x75)</tt>
*<tt>test_line_test_code (0x77)</tt>
*<tt>non_unique_subscriber_number (0x71)</tt>
*<tt>non_unique_national_number (0x73)</tt>
*<tt>non_unique_international_number (0x74)</tt>
*<tt>call_950_numbe (0x76)</tt>
*<tt>special_number (0x73)</tt>
*<tt>national_number_with_transit_network_selection (0x74)</tt>
*<tt>international_number_with_transit_network_selection (0x75)</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values for Calling number, Calling Subscriber (Generic Number), Redirecting Number, Original Called Number (OCN) and Location Number ===

*<tt>unspecified</tt>
*<tt>not_available (0x2)</tt>
*<tt>allowed (0x0)</tt>
*<tt>restricted (0x1)</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

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

*<tt>unspecified</tt>
*<tt>no (0x0)</tt>
*<tt>pass (0x1)</tt>
*<tt>fail (0x2)</tt>
*<tt>network_provided (0x3)</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number, Original Called Number and Diversion Reason ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy (SIP: user-busy)</tt>
*<tt>no_reply (SIP: no-answer)</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

=== Information Transfer Capability values ===

information_transfer_capability:

*<tt>digital</tt>
*<tt>restricted_digital</tt>
*<tt>digital_with_tones</tt>
*<tt>speech</tt>
*<tt>3_1_khz_uadio</tt>

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

* PCAP sample: [[File:TB_Custom_SIP_Headers.pcap]]

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack:
<pre>
Accept Error-Info Remote-Party-ID
Accept-Contact Event Replaces
Accept-Encoding Expires Reply-To
Accept-Language From Request-Disposition
Alert-Info In-Reply-To Subject
Allow Max-Forwards Subscription-State
Allow-Events MIME-version Supported
Also Min-Expires Timestamp
Anonymity Min-SE To
Authorization Organization Unsupported
Authentication-Info Path User-Agent
Call-ID Priority Via
Call-Info Privacy Warning
Contact Proxy-Authenticate WWW-Authenticate
Content-Disposition Proxy-Authorization Require
Content-Encoding Proxy-Require Response-Key
Content-Language P-Media-Authorization Retry-After
Content-Length P-Preferred-Identity RPID-Privacy
Content-Type P-Asserted-Identity Route
CSeq RAck RSeq
RAck Reason Security-Client
Reason Record-Route Security-Server
Date Refer-To Security-Verify
Diversion Referred-By Server
Encryption Reject-Contact Service-Route
Session-Expires
</pre>

=== MLPP Precedence values ===

mlpp_look_for_busy:

*<tt>allowed</tt>
*<tt>path_reserved</tt>
*<tt>not_allowed</tt>

mlpp_precedence_level:

*<tt>flash_override</tt>
*<tt>flash</tt>
*<tt>immediate</tt>
*<tt>priority</tt>
*<tt>routine</tt>

mlpp_network_identity:

3 digits value from 0 to 999

mlpp_service_domain:

24 bits value from 0 to 16777215

=== ISUB subaddress information values ===

called_isub_type:
calling_isub_type:

*<tt>nsap</tt>
*<tt>nsap_ia5</tt>
*<tt>nsap_bcd</tt>
*<tt>user</tt>

called_isub:
calling_isub:

Digits for the subaddress information.

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile
*remapped_incoming_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** And all variables listed here: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Call transfer requests ==
Toolpack allows to relay [[Call transfer]] requests from one leg to the other, or to process them locally (making another outgoing call to replace the call that requested the call transfer).

If the chosen [[Call transfer]] mode is to process requests locally, upon reception of a call transfer request (SIP REFER or ISDN Facility), routing script will be called once again, to select the routes for the new outgoing call (call transfer target).

=== How to route call transfer request ===
Routing of a call transfer request is done exactly like routing of a normal incoming call.
The routing script generally does not need any modification to support that.

In some cases, the routing script may want to use information related to the transfer request to perform routing, or to insert information in the outgoing call leg.
Additional information is provided to the routing script, allowing routing decisions using information from the call transfer request (SIP REFER or ISDN Facility).
See below...

=== params[ :call ] content during transfer request ===
When processing a call transfer request, the params[ :call ] hash contains the information from the inbound call (same as was passed to the routing script upon arrival of the inbound call)
call = params[ :call ] -> Information from original inbound call, with exception of call[ :called ]

One exception (convenient because it allows a unmodified routing script to process call transfer request the same way as any other routing request):
call[ :called ] -> Replaced by the called number from the call transfer request (also called "redirection number")
Complementary information:
call[ :original_called_number ] -> Contains the called number that was initially received from the incoming call, prior to call transfer request
call[ :redirecting_number ] -> Number of the call from which the call transfer request was received (generally equals to original_called_number)

These fields will also be included in the outgoing call made after routing:
* original called number and redirecting number are existing fields on SS7 and ISDN calls
* SIP "diversion" header is used for SIP calls

=== params[ :transfer ] content ===
(this if valid only for release 2.7.102 and above) 
When processing a call transfer request, information from the call transfer request message (SIP REFER, ISDN Facility) is provided in params[ :transfer ]:
transfer = params[ :transfer ]
The following field is always present:
transfer[ :original_nap ] -> Contains the NAP of the first call from which a call transfer request was received
transfer[ :redirecting_nap ] -> Contains the NAP of the call from which the current call transfer request was received
(same as :original_nap for the first call transfer, different for subsequent transfers)
Examples of other fields that may be present, when appropriate:
transfer[ :uui ] -> The UUI (user-to-user information) found in the call transfer request
transfer[ :sip_header ] -> Contains custom SIP headers from the call transfer request
transfer[ :request_uri ] -> Contains the SIP Request URI

These field are 'read-only'. They won't be included in the outgoing call, as they represent the content of the call transfer request, not the outgoing call to make.

To insert/modify attributes of the outgoing call, the parameters from params[ :call ] must be edited instead.

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

Routing script call attribute name Description
--------------------------------------------------------------------------------------------
"signaling_type" Signaling type.
"inst_incoming_call_cnt" Instantaneous Count of incoming calls.
"inst_outgoing_call_cnt" Instantaneous Count of outgoing calls.
"available_cnt" Number of available circuits or channels.
"unavailable_cnt" Number of unavailable circuits or channels.
"availability_percent" Percentage of available circuits or channels.
"usage_percent" Percentage of used circuits or channels.
"unused_shared_percent" Percentage of used circuits or channels of this NAP available to make new calls with (taking into account shared with other NAPs)
"total_incoming_call_cnt" Total Count of incoming calls.
"asr_statistics_struct" Detailed Answer-Seizure Rate Statistics.
"global_asr_percent" Global calculated ASR percentage.
"total_outgoing_call_cnt" Total Count of outgoing calls.
"last_24h_asr_percent" Last 24 hours calculated ASR percentage.
"last_24h_outgoing_call_cnt" Last 24 hours outgoing calls.
"current_hour_asr_percent" Current hour calculated ASR percentage.
"current_hour_outgoing_call_cnt" Current hour outgoing calls.
"last_hour_asr_percent" Last hour calculated ASR percentage.
"last_hour_outgoing_call_cnt" Last hour outgoing calls.
"availability_detection_struct" Detailed availibility detection Statistics
"poll_remote_proxy" Remote proxy polling enabled
"is_available" Remote proxy actually available or not
"time_since_polling" Time since the last availibility polling
"time_available_seconds" Number of seconds since the NAP is available
"time_unavailable_seconds" Number of seconds since the NAP is unavailable
"registration_struct" Detailed registration Statistics
"register_to_proxy" Register to proxy enabled
"registered" Actually registered or not
"time_since_refresh" Time since the last refresh
"time_registered_seconds" Number of seconds since the NAP is registered
"time_not_registered_seconds" Number of seconds since the NAP is not registered

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== 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 passed to the routing script. This is equivalent to the incoming call parameters.

 

==== @nap_list ====

A list of 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.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2014-06-13T19:33:32Z

Rblanchet: isub fields

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "Reason values".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
Q931: 'Facility CNAM' IE when presentation is allowed for DMS/NI2 variants 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber
(Generic Number / NDS) 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| Q931: 'Facility CNAM' IE when presentation is restricted for DMS/NI2 variants 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number
(OCN) 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli
(Originating line information) 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Insert MLPP information in the outgoing leg 
| 2.7 
|-
| mlpp_look_for_busy 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - look ahead for busy 
| N/A 
| 
| 2.7 
|-
| mlpp_precedence_level 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - precedence level 
| SIP:Resource-Priority - q735 
| 
| 2.7 
|-
| mlpp_network_identity 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - network identity 
| N/A 
| 
| 2.7 
|-
| mlpp_service_domain 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - MLPP service domain 
| N/A 
| 
| 2.7 
|-
| called_isub 
| Q931: 'Called party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - subaddress information 
| SIP:To - isub parameter 
| 
| 2.7 
|-
| called_isub_type 
| Q931: 'Called party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - type of subaddress 
| SIP:To - isub-encoding parameter 
| 
| 2.7 
|-
| calling_isub 
| Q931: 'Calling party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - subaddress information 
| SIP:From - isub 
| 
| 2.7 
|-
| calling_isub_type 
| Q931: 'Callinf party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - type of subaddress 
| SIP:From - isub-encoding 
| 
| 2.7 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number (0x2)</tt>
*<tt>international_number (0x4)</tt>
*<tt>national_number (0x3)</tt>
*<tt>subscriber_number (0x1)</tt>
*<tt>network_specific (0x5)</tt>
*<tt>network_routing_national_format (0x7)</tt>
*<tt>network_routing_international_format (0x8)</tt>
*<tt>abbreviated_number (0x6)</tt>
*<tt>subscriber_number_operator_requested (0x71)</tt>
*<tt>national_number_operator_requested (0x72)</tt>
*<tt>international_number_operator_requested (0x73)</tt>
*<tt>no_number_present_operator_requested (0x74)</tt>
*<tt>no_number_present_cut_through_call_to_carrier (0x75)</tt>
*<tt>test_line_test_code (0x77)</tt>
*<tt>non_unique_subscriber_number (0x71)</tt>
*<tt>non_unique_national_number (0x73)</tt>
*<tt>non_unique_international_number (0x74)</tt>
*<tt>call_950_numbe (0x76)</tt>
*<tt>special_number (0x73)</tt>
*<tt>national_number_with_transit_network_selection (0x74)</tt>
*<tt>international_number_with_transit_network_selection (0x75)</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values for Calling number, Calling Subscriber (Generic Number), Redirecting Number, Original Called Number (OCN) and Location Number ===

*<tt>unspecified</tt>
*<tt>not_available (0x2)</tt>
*<tt>allowed (0x0)</tt>
*<tt>restricted (0x1)</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

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

*<tt>unspecified</tt>
*<tt>no (0x0)</tt>
*<tt>pass (0x1)</tt>
*<tt>fail (0x2)</tt>
*<tt>network_provided (0x3)</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number, Original Called Number and Diversion Reason ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy (SIP: user-busy)</tt>
*<tt>no_reply (SIP: no-answer)</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

=== Information Transfer Capability values ===

information_transfer_capability:

*<tt>digital</tt>
*<tt>restricted_digital</tt>
*<tt>digital_with_tones</tt>
*<tt>speech</tt>
*<tt>3_1_khz_uadio</tt>

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

* PCAP sample: [[File:TB_Custom_SIP_Headers.pcap]]

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack:
<pre>
Accept Error-Info Remote-Party-ID
Accept-Contact Event Replaces
Accept-Encoding Expires Reply-To
Accept-Language From Request-Disposition
Alert-Info In-Reply-To Subject
Allow Max-Forwards Subscription-State
Allow-Events MIME-version Supported
Also Min-Expires Timestamp
Anonymity Min-SE To
Authorization Organization Unsupported
Authentication-Info Path User-Agent
Call-ID Priority Via
Call-Info Privacy Warning
Contact Proxy-Authenticate WWW-Authenticate
Content-Disposition Proxy-Authorization Require
Content-Encoding Proxy-Require Response-Key
Content-Language P-Media-Authorization Retry-After
Content-Length P-Preferred-Identity RPID-Privacy
Content-Type P-Asserted-Identity Route
CSeq RAck RSeq
RAck Reason Security-Client
Reason Record-Route Security-Server
Date Refer-To Security-Verify
Diversion Referred-By Server
Encryption Reject-Contact Service-Route
Session-Expires
</pre>

=== MLPP Precedence values ===

mlpp_look_for_busy:

*<tt>allowed</tt>
*<tt>path_reserved</tt>
*<tt>not_allowed</tt>

mlpp_precedence_level:

*<tt>flash_override</tt>
*<tt>flash</tt>
*<tt>immediate</tt>
*<tt>priority</tt>
*<tt>routine</tt>

mlpp_network_identity:

3 digits value from 0 to 999

mlpp_service_domain:

24 bits value from 0 to 16777215

=== ISUB subaddress information values ===

called_isub_type:
calling_isub_type:

*<tt>nsap</tt>
*<tt>nsap_ia5</tt>
*<tt>nsap_bcd</tt>
*<tt>user</tt>

called_isub:
calling_isub:

Digits for the subaddress information.

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile
*remapped_incoming_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** And all variables listed here: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Call transfer requests ==
Toolpack allows to relay [[Call transfer]] requests from one leg to the other, or to process them locally (making another outgoing call to replace the call that requested the call transfer).

If the chosen [[Call transfer]] mode is to process requests locally, upon reception of a call transfer request (SIP REFER or ISDN Facility), routing script will be called once again, to select the routes for the new outgoing call (call transfer target).

=== How to route call transfer request ===
Routing of a call transfer request is done exactly like routing of a normal incoming call.
The routing script generally does not need any modification to support that.

In some cases, the routing script may want to use information related to the transfer request to perform routing, or to insert information in the outgoing call leg.
Additional information is provided to the routing script, allowing routing decisions using information from the call transfer request (SIP REFER or ISDN Facility).
See below...

=== params[ :call ] content during transfer request ===
When processing a call transfer request, the params[ :call ] hash contains the information from the inbound call (same as was passed to the routing script upon arrival of the inbound call)
call = params[ :call ] -> Information from original inbound call, with exception of call[ :called ]

One exception (convenient because it allows a unmodified routing script to process call transfer request the same way as any other routing request):
call[ :called ] -> Replaced by the called number from the call transfer request (also called "redirection number")
Complementary information:
call[ :original_called_number ] -> Contains the called number that was initially received from the incoming call, prior to call transfer request
call[ :redirecting_number ] -> Number of the call from which the call transfer request was received (generally equals to original_called_number)

These fields will also be included in the outgoing call made after routing:
* original called number and redirecting number are existing fields on SS7 and ISDN calls
* SIP "diversion" header is used for SIP calls

=== params[ :transfer ] content ===
(this if valid only for release 2.7.102 and above) 
When processing a call transfer request, information from the call transfer request message (SIP REFER, ISDN Facility) is provided in params[ :transfer ]:
transfer = params[ :transfer ]
The following field is always present:
transfer[ :original_nap ] -> Contains the NAP of the first call from which a call transfer request was received
transfer[ :redirecting_nap ] -> Contains the NAP of the call from which the current call transfer request was received
(same as :original_nap for the first call transfer, different for subsequent transfers)
Examples of other fields that may be present, when appropriate:
transfer[ :uui ] -> The UUI (user-to-user information) found in the call transfer request
transfer[ :sip_header ] -> Contains custom SIP headers from the call transfer request
transfer[ :request_uri ] -> Contains the SIP Request URI

These field are 'read-only'. They won't be included in the outgoing call, as they represent the content of the call transfer request, not the outgoing call to make.

To insert/modify attributes of the outgoing call, the parameters from params[ :call ] must be edited instead.

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

Routing script call attribute name Description
--------------------------------------------------------------------------------------------
"signaling_type" Signaling type.
"inst_incoming_call_cnt" Instantaneous Count of incoming calls.
"inst_outgoing_call_cnt" Instantaneous Count of outgoing calls.
"available_cnt" Number of available circuits or channels.
"unavailable_cnt" Number of unavailable circuits or channels.
"availability_percent" Percentage of available circuits or channels.
"usage_percent" Percentage of used circuits or channels.
"unused_shared_percent" Percentage of used circuits or channels of this NAP available to make new calls with (taking into account shared with other NAPs)
"total_incoming_call_cnt" Total Count of incoming calls.
"asr_statistics_struct" Detailed Answer-Seizure Rate Statistics.
"global_asr_percent" Global calculated ASR percentage.
"total_outgoing_call_cnt" Total Count of outgoing calls.
"last_24h_asr_percent" Last 24 hours calculated ASR percentage.
"last_24h_outgoing_call_cnt" Last 24 hours outgoing calls.
"current_hour_asr_percent" Current hour calculated ASR percentage.
"current_hour_outgoing_call_cnt" Current hour outgoing calls.
"last_hour_asr_percent" Last hour calculated ASR percentage.
"last_hour_outgoing_call_cnt" Last hour outgoing calls.
"availability_detection_struct" Detailed availibility detection Statistics
"poll_remote_proxy" Remote proxy polling enabled
"is_available" Remote proxy actually available or not
"time_since_polling" Time since the last availibility polling
"time_available_seconds" Number of seconds since the NAP is available
"time_unavailable_seconds" Number of seconds since the NAP is unavailable
"registration_struct" Detailed registration Statistics
"register_to_proxy" Register to proxy enabled
"registered" Actually registered or not
"time_since_refresh" Time since the last refresh
"time_registered_seconds" Number of seconds since the NAP is registered
"time_not_registered_seconds" Number of seconds since the NAP is not registered

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== 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 passed to the routing script. This is equivalent to the incoming call parameters.

 

==== @nap_list ====

A list of 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.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2014-06-13T19:22:56Z

Rblanchet: Isub parameters

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "Reason values".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
Q931: 'Facility CNAM' IE when presentation is allowed for DMS/NI2 variants 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber
(Generic Number / NDS) 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| Q931: 'Facility CNAM' IE when presentation is restricted for DMS/NI2 variants 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number
(OCN) 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli
(Originating line information) 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Insert MLPP information in the outgoing leg 
| 2.7 
|-
| mlpp_look_for_busy 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - look ahead for busy 
| N/A 
| 
| 2.7 
|-
| mlpp_precedence_level 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - precedence level 
| SIP:Resource-Priority - q735 
| 
| 2.7 
|-
| mlpp_network_identity 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - network identity 
| N/A 
| 
| 2.7 
|-
| mlpp_service_domain 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - MLPP service domain 
| N/A 
| 
| 2.7 
|-
| called_isub 
| Q931: 'Called party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - subaddress information 
| SIP:To - isub parameter 
| 
| 2.7 
|-
| called_isub_type 
| Q931: 'Called party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - type of subaddress 
| SIP:To - isub-encoding parameter 
| 
| 2.7 
|-
| calling_isub 
| Q931: 'Calling party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - subaddress information 
| SIP:From - isub 
| 
| 2.7 
|-
| calling_isub_type 
| Q931: 'Callinf party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - type of subaddress 
| SIP:From - isub-encoding 
| 
| 2.7 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number (0x2)</tt>
*<tt>international_number (0x4)</tt>
*<tt>national_number (0x3)</tt>
*<tt>subscriber_number (0x1)</tt>
*<tt>network_specific (0x5)</tt>
*<tt>network_routing_national_format (0x7)</tt>
*<tt>network_routing_international_format (0x8)</tt>
*<tt>abbreviated_number (0x6)</tt>
*<tt>subscriber_number_operator_requested (0x71)</tt>
*<tt>national_number_operator_requested (0x72)</tt>
*<tt>international_number_operator_requested (0x73)</tt>
*<tt>no_number_present_operator_requested (0x74)</tt>
*<tt>no_number_present_cut_through_call_to_carrier (0x75)</tt>
*<tt>test_line_test_code (0x77)</tt>
*<tt>non_unique_subscriber_number (0x71)</tt>
*<tt>non_unique_national_number (0x73)</tt>
*<tt>non_unique_international_number (0x74)</tt>
*<tt>call_950_numbe (0x76)</tt>
*<tt>special_number (0x73)</tt>
*<tt>national_number_with_transit_network_selection (0x74)</tt>
*<tt>international_number_with_transit_network_selection (0x75)</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values for Calling number, Calling Subscriber (Generic Number), Redirecting Number, Original Called Number (OCN) and Location Number ===

*<tt>unspecified</tt>
*<tt>not_available (0x2)</tt>
*<tt>allowed (0x0)</tt>
*<tt>restricted (0x1)</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

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

*<tt>unspecified</tt>
*<tt>no (0x0)</tt>
*<tt>pass (0x1)</tt>
*<tt>fail (0x2)</tt>
*<tt>network_provided (0x3)</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number, Original Called Number and Diversion Reason ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy (SIP: user-busy)</tt>
*<tt>no_reply (SIP: no-answer)</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

=== Information Transfer Capability values ===

information_transfer_capability:

*<tt>digital</tt>
*<tt>restricted_digital</tt>
*<tt>digital_with_tones</tt>
*<tt>speech</tt>
*<tt>3_1_khz_uadio</tt>

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

* PCAP sample: [[File:TB_Custom_SIP_Headers.pcap]]

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack:
<pre>
Accept Error-Info Remote-Party-ID
Accept-Contact Event Replaces
Accept-Encoding Expires Reply-To
Accept-Language From Request-Disposition
Alert-Info In-Reply-To Subject
Allow Max-Forwards Subscription-State
Allow-Events MIME-version Supported
Also Min-Expires Timestamp
Anonymity Min-SE To
Authorization Organization Unsupported
Authentication-Info Path User-Agent
Call-ID Priority Via
Call-Info Privacy Warning
Contact Proxy-Authenticate WWW-Authenticate
Content-Disposition Proxy-Authorization Require
Content-Encoding Proxy-Require Response-Key
Content-Language P-Media-Authorization Retry-After
Content-Length P-Preferred-Identity RPID-Privacy
Content-Type P-Asserted-Identity Route
CSeq RAck RSeq
RAck Reason Security-Client
Reason Record-Route Security-Server
Date Refer-To Security-Verify
Diversion Referred-By Server
Encryption Reject-Contact Service-Route
Session-Expires
</pre>

=== MLPP Precedence values ===

mlpp_look_for_busy:

*<tt>allowed</tt>
*<tt>path_reserved</tt>
*<tt>not_allowed</tt>

mlpp_precedence_level:

*<tt>flash_override</tt>
*<tt>flash</tt>
*<tt>immediate</tt>
*<tt>priority</tt>
*<tt>routine</tt>

mlpp_network_identity:

3 digits value from 0 to 999

mlpp_service_domain:

24 bits value from 0 to 16777215

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile
*remapped_incoming_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** And all variables listed here: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Call transfer requests ==
Toolpack allows to relay [[Call transfer]] requests from one leg to the other, or to process them locally (making another outgoing call to replace the call that requested the call transfer).

If the chosen [[Call transfer]] mode is to process requests locally, upon reception of a call transfer request (SIP REFER or ISDN Facility), routing script will be called once again, to select the routes for the new outgoing call (call transfer target).

=== How to route call transfer request ===
Routing of a call transfer request is done exactly like routing of a normal incoming call.
The routing script generally does not need any modification to support that.

In some cases, the routing script may want to use information related to the transfer request to perform routing, or to insert information in the outgoing call leg.
Additional information is provided to the routing script, allowing routing decisions using information from the call transfer request (SIP REFER or ISDN Facility).
See below...

=== params[ :call ] content during transfer request ===
When processing a call transfer request, the params[ :call ] hash contains the information from the inbound call (same as was passed to the routing script upon arrival of the inbound call)
call = params[ :call ] -> Information from original inbound call, with exception of call[ :called ]

One exception (convenient because it allows a unmodified routing script to process call transfer request the same way as any other routing request):
call[ :called ] -> Replaced by the called number from the call transfer request (also called "redirection number")
Complementary information:
call[ :original_called_number ] -> Contains the called number that was initially received from the incoming call, prior to call transfer request
call[ :redirecting_number ] -> Number of the call from which the call transfer request was received (generally equals to original_called_number)

These fields will also be included in the outgoing call made after routing:
* original called number and redirecting number are existing fields on SS7 and ISDN calls
* SIP "diversion" header is used for SIP calls

=== params[ :transfer ] content ===
(this if valid only for release 2.7.102 and above) 
When processing a call transfer request, information from the call transfer request message (SIP REFER, ISDN Facility) is provided in params[ :transfer ]:
transfer = params[ :transfer ]
The following field is always present:
transfer[ :original_nap ] -> Contains the NAP of the first call from which a call transfer request was received
transfer[ :redirecting_nap ] -> Contains the NAP of the call from which the current call transfer request was received
(same as :original_nap for the first call transfer, different for subsequent transfers)
Examples of other fields that may be present, when appropriate:
transfer[ :uui ] -> The UUI (user-to-user information) found in the call transfer request
transfer[ :sip_header ] -> Contains custom SIP headers from the call transfer request
transfer[ :request_uri ] -> Contains the SIP Request URI

These field are 'read-only'. They won't be included in the outgoing call, as they represent the content of the call transfer request, not the outgoing call to make.

To insert/modify attributes of the outgoing call, the parameters from params[ :call ] must be edited instead.

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

Routing script call attribute name Description
--------------------------------------------------------------------------------------------
"signaling_type" Signaling type.
"inst_incoming_call_cnt" Instantaneous Count of incoming calls.
"inst_outgoing_call_cnt" Instantaneous Count of outgoing calls.
"available_cnt" Number of available circuits or channels.
"unavailable_cnt" Number of unavailable circuits or channels.
"availability_percent" Percentage of available circuits or channels.
"usage_percent" Percentage of used circuits or channels.
"unused_shared_percent" Percentage of used circuits or channels of this NAP available to make new calls with (taking into account shared with other NAPs)
"total_incoming_call_cnt" Total Count of incoming calls.
"asr_statistics_struct" Detailed Answer-Seizure Rate Statistics.
"global_asr_percent" Global calculated ASR percentage.
"total_outgoing_call_cnt" Total Count of outgoing calls.
"last_24h_asr_percent" Last 24 hours calculated ASR percentage.
"last_24h_outgoing_call_cnt" Last 24 hours outgoing calls.
"current_hour_asr_percent" Current hour calculated ASR percentage.
"current_hour_outgoing_call_cnt" Current hour outgoing calls.
"last_hour_asr_percent" Last hour calculated ASR percentage.
"last_hour_outgoing_call_cnt" Last hour outgoing calls.
"availability_detection_struct" Detailed availibility detection Statistics
"poll_remote_proxy" Remote proxy polling enabled
"is_available" Remote proxy actually available or not
"time_since_polling" Time since the last availibility polling
"time_available_seconds" Number of seconds since the NAP is available
"time_unavailable_seconds" Number of seconds since the NAP is unavailable
"registration_struct" Detailed registration Statistics
"register_to_proxy" Register to proxy enabled
"registered" Actually registered or not
"time_since_refresh" Time since the last refresh
"time_registered_seconds" Number of seconds since the NAP is registered
"time_not_registered_seconds" Number of seconds since the NAP is not registered

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== 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 passed to the routing script. This is equivalent to the incoming call parameters.

 

==== @nap_list ====

A list of 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.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2014-06-13T18:39:41Z

Rblanchet: mlpp fields

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "Reason values".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
Q931: 'Facility CNAM' IE when presentation is allowed for DMS/NI2 variants 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber
(Generic Number / NDS) 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| Q931: 'Facility CNAM' IE when presentation is restricted for DMS/NI2 variants 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number
(OCN) 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli
(Originating line information) 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Insert MLPP information in the outgoing leg 
| 2.7 
|-
| mlpp_look_for_busy 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - look ahead for busy 
| N/A 
| 
| 2.7 
|-
| mlpp_precedence_level 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - precedence level 
| SIP:Resource-Priority - q735 
| 
| 2.7 
|-
| mlpp_network_identity 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - network identity 
| N/A 
| 
| 2.7 
|-
| mlpp_service_domain 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - MLPP service domain 
| N/A 
| 
| 2.7 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number (0x2)</tt>
*<tt>international_number (0x4)</tt>
*<tt>national_number (0x3)</tt>
*<tt>subscriber_number (0x1)</tt>
*<tt>network_specific (0x5)</tt>
*<tt>network_routing_national_format (0x7)</tt>
*<tt>network_routing_international_format (0x8)</tt>
*<tt>abbreviated_number (0x6)</tt>
*<tt>subscriber_number_operator_requested (0x71)</tt>
*<tt>national_number_operator_requested (0x72)</tt>
*<tt>international_number_operator_requested (0x73)</tt>
*<tt>no_number_present_operator_requested (0x74)</tt>
*<tt>no_number_present_cut_through_call_to_carrier (0x75)</tt>
*<tt>test_line_test_code (0x77)</tt>
*<tt>non_unique_subscriber_number (0x71)</tt>
*<tt>non_unique_national_number (0x73)</tt>
*<tt>non_unique_international_number (0x74)</tt>
*<tt>call_950_numbe (0x76)</tt>
*<tt>special_number (0x73)</tt>
*<tt>national_number_with_transit_network_selection (0x74)</tt>
*<tt>international_number_with_transit_network_selection (0x75)</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values for Calling number, Calling Subscriber (Generic Number), Redirecting Number, Original Called Number (OCN) and Location Number ===

*<tt>unspecified</tt>
*<tt>not_available (0x2)</tt>
*<tt>allowed (0x0)</tt>
*<tt>restricted (0x1)</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

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

*<tt>unspecified</tt>
*<tt>no (0x0)</tt>
*<tt>pass (0x1)</tt>
*<tt>fail (0x2)</tt>
*<tt>network_provided (0x3)</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number, Original Called Number and Diversion Reason ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy (SIP: user-busy)</tt>
*<tt>no_reply (SIP: no-answer)</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

=== Information Transfer Capability values ===

information_transfer_capability:

*<tt>digital</tt>
*<tt>restricted_digital</tt>
*<tt>digital_with_tones</tt>
*<tt>speech</tt>
*<tt>3_1_khz_uadio</tt>

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

* PCAP sample: [[File:TB_Custom_SIP_Headers.pcap]]

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack:
<pre>
Accept Error-Info Remote-Party-ID
Accept-Contact Event Replaces
Accept-Encoding Expires Reply-To
Accept-Language From Request-Disposition
Alert-Info In-Reply-To Subject
Allow Max-Forwards Subscription-State
Allow-Events MIME-version Supported
Also Min-Expires Timestamp
Anonymity Min-SE To
Authorization Organization Unsupported
Authentication-Info Path User-Agent
Call-ID Priority Via
Call-Info Privacy Warning
Contact Proxy-Authenticate WWW-Authenticate
Content-Disposition Proxy-Authorization Require
Content-Encoding Proxy-Require Response-Key
Content-Language P-Media-Authorization Retry-After
Content-Length P-Preferred-Identity RPID-Privacy
Content-Type P-Asserted-Identity Route
CSeq RAck RSeq
RAck Reason Security-Client
Reason Record-Route Security-Server
Date Refer-To Security-Verify
Diversion Referred-By Server
Encryption Reject-Contact Service-Route
Session-Expires
</pre>

=== MLPP Precedence values ===

mlpp_look_for_busy:

*<tt>allowed</tt>
*<tt>path_reserved</tt>
*<tt>not_allowed</tt>

mlpp_precedence_level:

*<tt>flash_override</tt>
*<tt>flash</tt>
*<tt>immediate</tt>
*<tt>priority</tt>
*<tt>routine</tt>

mlpp_network_identity:

3 digits value from 0 to 999

mlpp_service_domain:

24 bits value from 0 to 16777215

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile
*remapped_incoming_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** And all variables listed here: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Call transfer requests ==
Toolpack allows to relay [[Call transfer]] requests from one leg to the other, or to process them locally (making another outgoing call to replace the call that requested the call transfer).

If the chosen [[Call transfer]] mode is to process requests locally, upon reception of a call transfer request (SIP REFER or ISDN Facility), routing script will be called once again, to select the routes for the new outgoing call (call transfer target).

=== How to route call transfer request ===
Routing of a call transfer request is done exactly like routing of a normal incoming call.
The routing script generally does not need any modification to support that.

In some cases, the routing script may want to use information related to the transfer request to perform routing, or to insert information in the outgoing call leg.
Additional information is provided to the routing script, allowing routing decisions using information from the call transfer request (SIP REFER or ISDN Facility).
See below...

=== params[ :call ] content during transfer request ===
When processing a call transfer request, the params[ :call ] hash contains the information from the inbound call (same as was passed to the routing script upon arrival of the inbound call)
call = params[ :call ] -> Information from original inbound call, with exception of call[ :called ]

One exception (convenient because it allows a unmodified routing script to process call transfer request the same way as any other routing request):
call[ :called ] -> Replaced by the called number from the call transfer request (also called "redirection number")
Complementary information:
call[ :original_called_number ] -> Contains the called number that was initially received from the incoming call, prior to call transfer request
call[ :redirecting_number ] -> Number of the call from which the call transfer request was received (generally equals to original_called_number)

These fields will also be included in the outgoing call made after routing:
* original called number and redirecting number are existing fields on SS7 and ISDN calls
* SIP "diversion" header is used for SIP calls

=== params[ :transfer ] content ===
(this if valid only for release 2.7.102 and above) 
When processing a call transfer request, information from the call transfer request message (SIP REFER, ISDN Facility) is provided in params[ :transfer ]:
transfer = params[ :transfer ]
The following field is always present:
transfer[ :original_nap ] -> Contains the NAP of the first call from which a call transfer request was received
transfer[ :redirecting_nap ] -> Contains the NAP of the call from which the current call transfer request was received
(same as :original_nap for the first call transfer, different for subsequent transfers)
Examples of other fields that may be present, when appropriate:
transfer[ :uui ] -> The UUI (user-to-user information) found in the call transfer request
transfer[ :sip_header ] -> Contains custom SIP headers from the call transfer request
transfer[ :request_uri ] -> Contains the SIP Request URI

These field are 'read-only'. They won't be included in the outgoing call, as they represent the content of the call transfer request, not the outgoing call to make.

To insert/modify attributes of the outgoing call, the parameters from params[ :call ] must be edited instead.

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

Routing script call attribute name Description
--------------------------------------------------------------------------------------------
"signaling_type" Signaling type.
"inst_incoming_call_cnt" Instantaneous Count of incoming calls.
"inst_outgoing_call_cnt" Instantaneous Count of outgoing calls.
"available_cnt" Number of available circuits or channels.
"unavailable_cnt" Number of unavailable circuits or channels.
"availability_percent" Percentage of available circuits or channels.
"usage_percent" Percentage of used circuits or channels.
"unused_shared_percent" Percentage of used circuits or channels of this NAP available to make new calls with (taking into account shared with other NAPs)
"total_incoming_call_cnt" Total Count of incoming calls.
"asr_statistics_struct" Detailed Answer-Seizure Rate Statistics.
"global_asr_percent" Global calculated ASR percentage.
"total_outgoing_call_cnt" Total Count of outgoing calls.
"last_24h_asr_percent" Last 24 hours calculated ASR percentage.
"last_24h_outgoing_call_cnt" Last 24 hours outgoing calls.
"current_hour_asr_percent" Current hour calculated ASR percentage.
"current_hour_outgoing_call_cnt" Current hour outgoing calls.
"last_hour_asr_percent" Last hour calculated ASR percentage.
"last_hour_outgoing_call_cnt" Last hour outgoing calls.
"availability_detection_struct" Detailed availibility detection Statistics
"poll_remote_proxy" Remote proxy polling enabled
"is_available" Remote proxy actually available or not
"time_since_polling" Time since the last availibility polling
"time_available_seconds" Number of seconds since the NAP is available
"time_unavailable_seconds" Number of seconds since the NAP is unavailable
"registration_struct" Detailed registration Statistics
"register_to_proxy" Register to proxy enabled
"registered" Actually registered or not
"time_since_refresh" Time since the last refresh
"time_registered_seconds" Number of seconds since the NAP is registered
"time_not_registered_seconds" Number of seconds since the NAP is not registered

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== 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 passed to the routing script. This is equivalent to the incoming call parameters.

 

==== @nap_list ====

A list of 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.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2014-06-13T18:30:33Z

Rblanchet: mlpp for sip

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "Reason values".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
Q931: 'Facility CNAM' IE when presentation is allowed for DMS/NI2 variants 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber
(Generic Number / NDS) 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| Q931: 'Facility CNAM' IE when presentation is restricted for DMS/NI2 variants 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number
(OCN) 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli
(Originating line information) 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Insert MLPP information in the outgoing leg 
| 2.7 
|-
| mlpp_look_for_busy 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - look ahead for busy 
| N/A 
| 
| 2.7 
|-
| mlpp_precedence_level 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - precedence level 
| SIP:Resource-Priority - q735 
| 
| 2.7 
|-
| mlpp_network_identity 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - network identity 
| N/A 
| 
| 2.7 
|-
| mlpp_service_domain 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - MLPP service domain 
| N/A 
| 
| 2.7 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number (0x2)</tt>
*<tt>international_number (0x4)</tt>
*<tt>national_number (0x3)</tt>
*<tt>subscriber_number (0x1)</tt>
*<tt>network_specific (0x5)</tt>
*<tt>network_routing_national_format (0x7)</tt>
*<tt>network_routing_international_format (0x8)</tt>
*<tt>abbreviated_number (0x6)</tt>
*<tt>subscriber_number_operator_requested (0x71)</tt>
*<tt>national_number_operator_requested (0x72)</tt>
*<tt>international_number_operator_requested (0x73)</tt>
*<tt>no_number_present_operator_requested (0x74)</tt>
*<tt>no_number_present_cut_through_call_to_carrier (0x75)</tt>
*<tt>test_line_test_code (0x77)</tt>
*<tt>non_unique_subscriber_number (0x71)</tt>
*<tt>non_unique_national_number (0x73)</tt>
*<tt>non_unique_international_number (0x74)</tt>
*<tt>call_950_numbe (0x76)</tt>
*<tt>special_number (0x73)</tt>
*<tt>national_number_with_transit_network_selection (0x74)</tt>
*<tt>international_number_with_transit_network_selection (0x75)</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values for Calling number, Calling Subscriber (Generic Number), Redirecting Number, Original Called Number (OCN) and Location Number ===

*<tt>unspecified</tt>
*<tt>not_available (0x2)</tt>
*<tt>allowed (0x0)</tt>
*<tt>restricted (0x1)</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

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

*<tt>unspecified</tt>
*<tt>no (0x0)</tt>
*<tt>pass (0x1)</tt>
*<tt>fail (0x2)</tt>
*<tt>network_provided (0x3)</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number, Original Called Number and Diversion Reason ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy (SIP: user-busy)</tt>
*<tt>no_reply (SIP: no-answer)</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

=== Information Transfer Capability values ===

information_transfer_capability:

*<tt>digital</tt>
*<tt>restricted_digital</tt>
*<tt>digital_with_tones</tt>
*<tt>speech</tt>
*<tt>3_1_khz_uadio</tt>

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

* PCAP sample: [[File:TB_Custom_SIP_Headers.pcap]]

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack:
<pre>
Accept Error-Info Remote-Party-ID
Accept-Contact Event Replaces
Accept-Encoding Expires Reply-To
Accept-Language From Request-Disposition
Alert-Info In-Reply-To Subject
Allow Max-Forwards Subscription-State
Allow-Events MIME-version Supported
Also Min-Expires Timestamp
Anonymity Min-SE To
Authorization Organization Unsupported
Authentication-Info Path User-Agent
Call-ID Priority Via
Call-Info Privacy Warning
Contact Proxy-Authenticate WWW-Authenticate
Content-Disposition Proxy-Authorization Require
Content-Encoding Proxy-Require Response-Key
Content-Language P-Media-Authorization Retry-After
Content-Length P-Preferred-Identity RPID-Privacy
Content-Type P-Asserted-Identity Route
CSeq RAck RSeq
RAck Reason Security-Client
Reason Record-Route Security-Server
Date Refer-To Security-Verify
Diversion Referred-By Server
Encryption Reject-Contact Service-Route
Session-Expires
</pre>

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile
*remapped_incoming_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** And all variables listed here: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Call transfer requests ==
Toolpack allows to relay [[Call transfer]] requests from one leg to the other, or to process them locally (making another outgoing call to replace the call that requested the call transfer).

If the chosen [[Call transfer]] mode is to process requests locally, upon reception of a call transfer request (SIP REFER or ISDN Facility), routing script will be called once again, to select the routes for the new outgoing call (call transfer target).

=== How to route call transfer request ===
Routing of a call transfer request is done exactly like routing of a normal incoming call.
The routing script generally does not need any modification to support that.

In some cases, the routing script may want to use information related to the transfer request to perform routing, or to insert information in the outgoing call leg.
Additional information is provided to the routing script, allowing routing decisions using information from the call transfer request (SIP REFER or ISDN Facility).
See below...

=== params[ :call ] content during transfer request ===
When processing a call transfer request, the params[ :call ] hash contains the information from the inbound call (same as was passed to the routing script upon arrival of the inbound call)
call = params[ :call ] -> Information from original inbound call, with exception of call[ :called ]

One exception (convenient because it allows a unmodified routing script to process call transfer request the same way as any other routing request):
call[ :called ] -> Replaced by the called number from the call transfer request (also called "redirection number")
Complementary information:
call[ :original_called_number ] -> Contains the called number that was initially received from the incoming call, prior to call transfer request
call[ :redirecting_number ] -> Number of the call from which the call transfer request was received (generally equals to original_called_number)

These fields will also be included in the outgoing call made after routing:
* original called number and redirecting number are existing fields on SS7 and ISDN calls
* SIP "diversion" header is used for SIP calls

=== params[ :transfer ] content ===
(this if valid only for release 2.7.102 and above) 
When processing a call transfer request, information from the call transfer request message (SIP REFER, ISDN Facility) is provided in params[ :transfer ]:
transfer = params[ :transfer ]
The following field is always present:
transfer[ :original_nap ] -> Contains the NAP of the first call from which a call transfer request was received
transfer[ :redirecting_nap ] -> Contains the NAP of the call from which the current call transfer request was received
(same as :original_nap for the first call transfer, different for subsequent transfers)
Examples of other fields that may be present, when appropriate:
transfer[ :uui ] -> The UUI (user-to-user information) found in the call transfer request
transfer[ :sip_header ] -> Contains custom SIP headers from the call transfer request
transfer[ :request_uri ] -> Contains the SIP Request URI

These field are 'read-only'. They won't be included in the outgoing call, as they represent the content of the call transfer request, not the outgoing call to make.

To insert/modify attributes of the outgoing call, the parameters from params[ :call ] must be edited instead.

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

Routing script call attribute name Description
--------------------------------------------------------------------------------------------
"signaling_type" Signaling type.
"inst_incoming_call_cnt" Instantaneous Count of incoming calls.
"inst_outgoing_call_cnt" Instantaneous Count of outgoing calls.
"available_cnt" Number of available circuits or channels.
"unavailable_cnt" Number of unavailable circuits or channels.
"availability_percent" Percentage of available circuits or channels.
"usage_percent" Percentage of used circuits or channels.
"unused_shared_percent" Percentage of used circuits or channels of this NAP available to make new calls with (taking into account shared with other NAPs)
"total_incoming_call_cnt" Total Count of incoming calls.
"asr_statistics_struct" Detailed Answer-Seizure Rate Statistics.
"global_asr_percent" Global calculated ASR percentage.
"total_outgoing_call_cnt" Total Count of outgoing calls.
"last_24h_asr_percent" Last 24 hours calculated ASR percentage.
"last_24h_outgoing_call_cnt" Last 24 hours outgoing calls.
"current_hour_asr_percent" Current hour calculated ASR percentage.
"current_hour_outgoing_call_cnt" Current hour outgoing calls.
"last_hour_asr_percent" Last hour calculated ASR percentage.
"last_hour_outgoing_call_cnt" Last hour outgoing calls.
"availability_detection_struct" Detailed availibility detection Statistics
"poll_remote_proxy" Remote proxy polling enabled
"is_available" Remote proxy actually available or not
"time_since_polling" Time since the last availibility polling
"time_available_seconds" Number of seconds since the NAP is available
"time_unavailable_seconds" Number of seconds since the NAP is unavailable
"registration_struct" Detailed registration Statistics
"register_to_proxy" Register to proxy enabled
"registered" Actually registered or not
"time_since_refresh" Time since the last refresh
"time_registered_seconds" Number of seconds since the NAP is registered
"time_not_registered_seconds" Number of seconds since the NAP is not registered

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== 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 passed to the routing script. This is equivalent to the incoming call parameters.

 

==== @nap_list ====

A list of 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.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2014-06-13T18:18:41Z

Rblanchet: MLPP for ss7

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "Reason values".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
Q931: 'Facility CNAM' IE when presentation is allowed for DMS/NI2 variants 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber
(Generic Number / NDS) 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| Q931: 'Facility CNAM' IE when presentation is restricted for DMS/NI2 variants 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number
(OCN) 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli
(Originating line information) 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Insert MLPP information in the outgoing leg 
| 2.7 
|-
| mlpp_look_for_busy 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - look ahead for busy 
| N/A 
| 
| 2.7 
|-
| mlpp_precedence_level 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - precedence level 
| N/A 
| 
| 2.7 
|-
| mlpp_network_identity 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - network identity 
| N/A 
| 
| 2.7 
|-
| mlpp_service_domain 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - MLPP service domain 
| N/A 
| 
| 2.7 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number (0x2)</tt>
*<tt>international_number (0x4)</tt>
*<tt>national_number (0x3)</tt>
*<tt>subscriber_number (0x1)</tt>
*<tt>network_specific (0x5)</tt>
*<tt>network_routing_national_format (0x7)</tt>
*<tt>network_routing_international_format (0x8)</tt>
*<tt>abbreviated_number (0x6)</tt>
*<tt>subscriber_number_operator_requested (0x71)</tt>
*<tt>national_number_operator_requested (0x72)</tt>
*<tt>international_number_operator_requested (0x73)</tt>
*<tt>no_number_present_operator_requested (0x74)</tt>
*<tt>no_number_present_cut_through_call_to_carrier (0x75)</tt>
*<tt>test_line_test_code (0x77)</tt>
*<tt>non_unique_subscriber_number (0x71)</tt>
*<tt>non_unique_national_number (0x73)</tt>
*<tt>non_unique_international_number (0x74)</tt>
*<tt>call_950_numbe (0x76)</tt>
*<tt>special_number (0x73)</tt>
*<tt>national_number_with_transit_network_selection (0x74)</tt>
*<tt>international_number_with_transit_network_selection (0x75)</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values for Calling number, Calling Subscriber (Generic Number), Redirecting Number, Original Called Number (OCN) and Location Number ===

*<tt>unspecified</tt>
*<tt>not_available (0x2)</tt>
*<tt>allowed (0x0)</tt>
*<tt>restricted (0x1)</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

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

*<tt>unspecified</tt>
*<tt>no (0x0)</tt>
*<tt>pass (0x1)</tt>
*<tt>fail (0x2)</tt>
*<tt>network_provided (0x3)</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number, Original Called Number and Diversion Reason ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy (SIP: user-busy)</tt>
*<tt>no_reply (SIP: no-answer)</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

=== Information Transfer Capability values ===

information_transfer_capability:

*<tt>digital</tt>
*<tt>restricted_digital</tt>
*<tt>digital_with_tones</tt>
*<tt>speech</tt>
*<tt>3_1_khz_uadio</tt>

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

* PCAP sample: [[File:TB_Custom_SIP_Headers.pcap]]

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack:
<pre>
Accept Error-Info Remote-Party-ID
Accept-Contact Event Replaces
Accept-Encoding Expires Reply-To
Accept-Language From Request-Disposition
Alert-Info In-Reply-To Subject
Allow Max-Forwards Subscription-State
Allow-Events MIME-version Supported
Also Min-Expires Timestamp
Anonymity Min-SE To
Authorization Organization Unsupported
Authentication-Info Path User-Agent
Call-ID Priority Via
Call-Info Privacy Warning
Contact Proxy-Authenticate WWW-Authenticate
Content-Disposition Proxy-Authorization Require
Content-Encoding Proxy-Require Response-Key
Content-Language P-Media-Authorization Retry-After
Content-Length P-Preferred-Identity RPID-Privacy
Content-Type P-Asserted-Identity Route
CSeq RAck RSeq
RAck Reason Security-Client
Reason Record-Route Security-Server
Date Refer-To Security-Verify
Diversion Referred-By Server
Encryption Reject-Contact Service-Route
Session-Expires
</pre>

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile
*remapped_incoming_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** And all variables listed here: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Call transfer requests ==
Toolpack allows to relay [[Call transfer]] requests from one leg to the other, or to process them locally (making another outgoing call to replace the call that requested the call transfer).

If the chosen [[Call transfer]] mode is to process requests locally, upon reception of a call transfer request (SIP REFER or ISDN Facility), routing script will be called once again, to select the routes for the new outgoing call (call transfer target).

=== How to route call transfer request ===
Routing of a call transfer request is done exactly like routing of a normal incoming call.
The routing script generally does not need any modification to support that.

In some cases, the routing script may want to use information related to the transfer request to perform routing, or to insert information in the outgoing call leg.
Additional information is provided to the routing script, allowing routing decisions using information from the call transfer request (SIP REFER or ISDN Facility).
See below...

=== params[ :call ] content during transfer request ===
When processing a call transfer request, the params[ :call ] hash contains the information from the inbound call (same as was passed to the routing script upon arrival of the inbound call)
call = params[ :call ] -> Information from original inbound call, with exception of call[ :called ]

One exception (convenient because it allows a unmodified routing script to process call transfer request the same way as any other routing request):
call[ :called ] -> Replaced by the called number from the call transfer request (also called "redirection number")
Complementary information:
call[ :original_called_number ] -> Contains the called number that was initially received from the incoming call, prior to call transfer request
call[ :redirecting_number ] -> Number of the call from which the call transfer request was received (generally equals to original_called_number)

These fields will also be included in the outgoing call made after routing:
* original called number and redirecting number are existing fields on SS7 and ISDN calls
* SIP "diversion" header is used for SIP calls

=== params[ :transfer ] content ===
(this if valid only for release 2.7.102 and above) 
When processing a call transfer request, information from the call transfer request message (SIP REFER, ISDN Facility) is provided in params[ :transfer ]:
transfer = params[ :transfer ]
The following field is always present:
transfer[ :original_nap ] -> Contains the NAP of the first call from which a call transfer request was received
transfer[ :redirecting_nap ] -> Contains the NAP of the call from which the current call transfer request was received
(same as :original_nap for the first call transfer, different for subsequent transfers)
Examples of other fields that may be present, when appropriate:
transfer[ :uui ] -> The UUI (user-to-user information) found in the call transfer request
transfer[ :sip_header ] -> Contains custom SIP headers from the call transfer request
transfer[ :request_uri ] -> Contains the SIP Request URI

These field are 'read-only'. They won't be included in the outgoing call, as they represent the content of the call transfer request, not the outgoing call to make.

To insert/modify attributes of the outgoing call, the parameters from params[ :call ] must be edited instead.

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

Routing script call attribute name Description
--------------------------------------------------------------------------------------------
"signaling_type" Signaling type.
"inst_incoming_call_cnt" Instantaneous Count of incoming calls.
"inst_outgoing_call_cnt" Instantaneous Count of outgoing calls.
"available_cnt" Number of available circuits or channels.
"unavailable_cnt" Number of unavailable circuits or channels.
"availability_percent" Percentage of available circuits or channels.
"usage_percent" Percentage of used circuits or channels.
"unused_shared_percent" Percentage of used circuits or channels of this NAP available to make new calls with (taking into account shared with other NAPs)
"total_incoming_call_cnt" Total Count of incoming calls.
"asr_statistics_struct" Detailed Answer-Seizure Rate Statistics.
"global_asr_percent" Global calculated ASR percentage.
"total_outgoing_call_cnt" Total Count of outgoing calls.
"last_24h_asr_percent" Last 24 hours calculated ASR percentage.
"last_24h_outgoing_call_cnt" Last 24 hours outgoing calls.
"current_hour_asr_percent" Current hour calculated ASR percentage.
"current_hour_outgoing_call_cnt" Current hour outgoing calls.
"last_hour_asr_percent" Last hour calculated ASR percentage.
"last_hour_outgoing_call_cnt" Last hour outgoing calls.
"availability_detection_struct" Detailed availibility detection Statistics
"poll_remote_proxy" Remote proxy polling enabled
"is_available" Remote proxy actually available or not
"time_since_polling" Time since the last availibility polling
"time_available_seconds" Number of seconds since the NAP is available
"time_unavailable_seconds" Number of seconds since the NAP is unavailable
"registration_struct" Detailed registration Statistics
"register_to_proxy" Register to proxy enabled
"registered" Actually registered or not
"time_since_refresh" Time since the last refresh
"time_registered_seconds" Number of seconds since the NAP is registered
"time_not_registered_seconds" Number of seconds since the NAP is not registered

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== 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 passed to the routing script. This is equivalent to the incoming call parameters.

 

==== @nap_list ====

A list of 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.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Parameter: SIP: User-to-User encoding

2013-11-27T15:22:44Z

Rblanchet: Add example of the format available for the sip header

Encoding for User-to-User header
* Use hexadecimal encoding format:
User-to-User:303030303030312e5468697320697320612074657374205555492076616c7565;encoding=hex;purpose=isdn-interwork;content=isdn-uui
* Use text encoding format:
User-to-User:0000001.This is a test UUI value;encoding=text;purpose=isdn-interwork;content=isdn-uui
* Use text encoding format with the escape illegal characters option:
User-to-User:%00%00%00%00%00%00%03.This is a test UUI value;encoding=text;purpose=isdn-interwork;content=isdn-uui
[[Category:Parameters]]

Text Call Detail Records

2013-11-20T19:56:55Z

Rblanchet: /* Information related to routing */

Text [[call detail record|call detail records]] (CDR) can be used on the [[TMG800]], [[TMG3200]] or [[TMG7800]]. The Call Detail Records are saved in a log file on a local disk. There is an entry done for each call leg, at the start of a call and at the end of the call. In addition, the system can be configured to update the CDRs periodically.

The format of the CDR traces is defined by configuration, using variables that are replaced by the Gateway application when writing to the log.

For example, the following variable will be replaced by the called number:
@{CalledNumber}

In order to save disk space and simplify the archiving and backup of CDR log files, this log file is automatically archived (gzipped) and rotated every N seconds, as specified by the system configuration.

== Enabling text CDR ==
The enabling of Text CDR is described in [[Toolpack:Enabling CDR A|Enabling CDR]].

== Available variables ==
The following variables exist and can be used to define the CDR log format.

=== Variables used for identifying call (or call leg) in general ===
*@{StatusType}: Indicates the type of record ("Start", "Update" or "End").
*@{LegId}: Unique Id for this leg (32 bits value, but may eventually be upgraded to 64 bits value).
*@{OtherLegId}: Id of the other call leg joined with current call leg.
*@{SessionId}: Unique call identifier for two joined and answered call legs, including failed outgoing call attempts (route retry)
Formatted as 4 values of 32 bits, printed as 4 blocks of 8 hexadecimal characters separated by a space
Ex: a939d169 299ffcd0 00000000 00000000
Note: Call Transfer Target legs have separate SessionId. If you need an id to correlate a transferred call
to the original call, use @{OriginalSessionId}.
*@{OriginalSessionId}: Refers to @{SessionId} of the original legs for this call, in case of call transfer.
In fact, Transfer Target leg has a different value for @{SessionId}, but can be linked with the original call
legs through @{OriginalSessionId}.
*@{LinkId}: Same meaning as @{OriginalSessionId}, but presented as a 32 bits integer value.
For all Ids above, please see [[Text_Call_Detail_Records_(CDR)#Known_limitations|Known Limitations]] below for notes about uniqueness of these values.

=== Timestamps ===
*@{AlertTime}: Time where the call has started ringing.
Note: Supported on release 2.7 and up only.
*@{ConnectedTime}: Time where the call was answered (and connected with another leg) (in number of seconds since epoch)
*@{ConnectedTime:format}: Same as @{ConnectedTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{ConnectedTimeUtc:format}:Same as @{ConnectedTime:format} but printed in UTC time, rather than local time zone.
*@{CallDuration}: Call duration in seconds (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{CallDurationMs}: Call duration in milliseconds (end - connected time) (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{EndTime}: Time where the call has started terminating (in number of seconds since epoch).
Note that slightly differs from the @{Timestamp}, since the 'End' CDR trace is printed once the call has
finished terminating,
while @{EndTime} reports the time where the call has started terminating (upon hangup for example).
*@{EndTime:format}: Same as @{EndTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{EndTimeUtc:format}: Same as @{EndTime:format} but printed in UTC time, rather than local time zone.
*@{RingingDuration}: Ringing duration in seconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{RingingDurationMs}: Ringing duration in milliseconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{StartTime}: Time where the call was created (in number of seconds since epoch)
*@{StartTime:format}: Same as @{StartTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{StartTimeUtc:format}: Same as @{StartTime:format} but printed in UTC time, rather than local time zone.
*@{Timestamp}: Time where this CDR log entry was written.
Should not be used for billing purposes. Use @{EndTime} for billing @{EndTime} reports the time where
the call has started terminating (hangup), while *@{Timestamp} the time where signaling confirmed the termination.
*@{Timestamp:format}: Same as @{Timestamp} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{TimestampUtc:format}: Same as @{Timestamp:format} but printed in UTC time, rather than local time zone.

=== Information related to signaling ===
*@{CalledNumber}: Called number
*@{CallingNumber}: Calling number
*@{CallingPresentation}: Calling presentation: "Unspecified", "NotAvailable", "Allowed", "Restricted", "AddressRestricted" or "NameRestricted"
Note: Supported on release 2.7 and up only.
*@{CallingSubscriberNumber}: Second calling number (ISDN) or Generic number of type "additional calling party number" (SS7)
Note: Supported on release 2.7.43 and up only.
*@{CallType}: Call type ("Telephony" or "VOIP")
*@{IncomingNAP}: Name of the NAP that originated this call (incoming call leg's NAP name).
Note: Supported on release 2.7 and up only.
*@{NAP}: Name of the NAP this call leg is from
*@{OriginatorName}: Direction of the call:
- "answer" (incoming call leg) - "originate" (outgoing call leg)
Note: In release 2.6 and earlier, the direction of the call is as follows:
- "originate" (incoming call leg) - "answer" (outgoing call leg)
In release 2.7, the CDR option "Reverse CDR call origin" in Gateway configuration provide the same values as in release 2.6.
*@{OriginalCalledNumber}: Original called number
Note: Supported on release 2.7 and up only.
*@{Protocol}: Type of protocol used ("SS7", "ISDN", or "SIP")
*@{RedirectingNumber}: Redirecting number
Note: Supported on release 2.7 and up only.
*@{TerminationCause}: Cause of the call termination, printed as an integer value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationCauseString}: Cause of the call termination, printed as a string value
*@{OriginalCause}: Original cause of the call termination, printed as a string value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationSource}: Identifies the cause of the leg termination:
- "TermInd": Terminating indication has been received on this leg
- "JoinedTermInd": Terminating indication has been received on the leg joined to current leg,
and has been forwarded to current leg
- "App": Call control application has asked to drop the call
- "Engine": Toolpack engine has decided to terminate this call
(generally due to local errors like disconnected TMedia)
*@{UserName}: For SIP calls, name of the user.
*@{ChargeIndicator}: For TDM (SS7 and CAS R2); received charge indicator in Alert message.

=== Information related to media ===
*@{Codec}: Codec used for this call ("G711" for example)
*@{LocalMediaInfo}: Protocol type dependent information on the call leg (local information for SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port locally used for receiving RTP)
*@{LocalMediaIP}: For VOIP calls, RTP IP address locally used for this call leg.
*@{LocalMediaPort}: For VOIP calls, RTP UDP port locally used for this call leg.
*@{RemoteMediaInfo}: Protocol type dependent information on the call leg (remote information SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port TMedia is sending RTP to)
*@{RemoteMediaIP}: For VOIP calls, RTP IP address of the remote peer for this call leg.
*@{RemoteMediaPort}: For VOIP calls, RTP UDP port of the remote peer for this call leg.
*@{TimeslotNumber}: For TDM (Telephony) calls, timeslot number that this call was using for audio.
*@{TrunkName}: For TDM (Telephony) calls, name of the trunk that this call was using for audio.

=== Information related to routing ===
*@{ApplicationName}: Name of the application that has written this log ("Gateway")
*@{RouteAttribute:attr}: Replaced by the value of a custom route attribute, for the selected
route. This will apply only to outgoing call legs that were made from routing.
Eligible route attributes are:
Route name: Use attribute "route_name". Ex: @{RouteAttribute:route_name}
Route set name: Use attribute "routeset_name". Ex: @{RouteAttribute:routeset_name}
Custom route attribute column: Use the custom attribute name. Ex: @{RouteAttribute:priority}
Routing script parameters: Use the route attribute name provided by routing script.
Ex: If script provides: route[:my_param]="myval"
Then it's included in CDR with @{RouteAttribute:my_param}]
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.
*@{ScriptAttribute:attr}: Replaced by the value of a routing script attribute stored in params[:bridge].
This will apply for incoming and outgoing call legs.
Eligible script attributes are:
Custom CDR value: Use attribute "CustomCdrValue". Ex: @{ScriptAttribute:CustomCdrValue}
Script parameters: Use the attribute name provided by routing script.
Ex: If script provides: params[:bridge][:my_param]="myval"
Then it's included in CDR with @{ScriptAttribute:my_param}]
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.

=== Deprecated values: ===
*@{MediaInfo}: Same as @{RemoteMediaInfo}
*@{RemoteIP}: Same as @{RemoteMediaIP}
*@{RemotePort}: Same as @{RemoteMediaPort}

== CDR sample ==
=== Text CDR sample ===
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP',Protocol='SIP',Direction='answer'
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP2',Protocol='SIP',Direction='originate'
2013-02-07 10:19:07.562-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',TerminationSource='App',Calling='',Called='123',NAP='NAP_SIP2',Direction='originate'
2013-02-07 10:19:07.656-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',Termination Source='App',Calling='',Called='123',NAP='NAP_SIP',Direction='answer'

=== Radius AAA sample ===
* [[File:TelcoBridges_RADIUS_Auth&Acct.pcap|TelcoBridges_RADIUS_Auth&Acct.pcap]]
* [[File:TelcoBridges_RADIUS_Auth&Acct.txt|TelcoBridges_RADIUS_Auth&Acct.txt]]

== Redundancy ==

In a [[TMG7800]] configuration, with redundant TMG-Control servers, only the active server writes the CDR logs. Since the active server may change over time, CDR parsing must take into account that CDR logs may be found in files from the two servers.

The analysis of the logs for the purpose of extracting billing information must be done after combining the two logs, from both TMG-Control servers, sorting the entries by timestamp for example. See how to [[TMG:Retrieve_Text_CDR|Retrieve Text CDR here]].

== CDR entry loss due to switchover ==
In some situations (during HA switchover for example), some CDR entries may be lost.

The following guide lines provide information on how to deal with these corner cases:

[[Call_Detail_Records_Entry_Loss|Deal with CDR entries loss]]

== Retrieving Text CDRs ==

There are 2 ways to retrieve the text CDR manually or automatically. The procedures are described in [[TMG:Retrieve_Text_CDR|Retrieve Text CDR]].

== Notes ==
*This mode of operation is not recommended for [[TMG800]] or [[TMG3200]] with a flash disk (last shipment January 2011). However, the [[TMG800]] or [[TMG3200]] with SATA or SSD disk option is OK (use command tbproduct: if the command can be executed, the disk is SATA or SSD).
*TelcoBridges does not recommend storing CDR logs via network file systems (NFS or other). We highly recommend writing to a local hard drive and have developed a background script that moves the gzipped log segments for backup or analysis.

[[category:Needs revising]]

Toolpack:RADIUS CDR attributes C

2013-11-18T16:32:26Z

Rblanchet: Telcob-CustomCdrValue

{{DISPLAYTITLE:Toolpack:RADIUS CDR attributes}}
=== '''''Applies to version(s): v2.7''''' ===
This page contains the list of RADIUS attributes that are sent to a RADIUS accounting server.

From RFC 2865 and RFC 2866 (Accounting) :
{| cellpadding="5" border="1" class="wikitable"
|-
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Attribute ID
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | RADIUS IETF param name
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Type
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Toolpack CDR parameter
! width="610" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Description
|-
| align="center" | 1 
| User-Name
| align="center" | string 
| IncomingNAP
| Incoming NAP name
|-
| align="center" | 4 
| NAS-IP-Address
| align="center" | IP address 
| -
| IP address of the TMedia generating the CDR record
|-
| align="center" | 30 
| Called-Sation-Id
| align="center" | string 
| Called Number
| Called party number
|-
| align="center" | 31 
| Calling-Station-Id
| align="center" | string 
| Calling Number
| Calling party number
|-
| align="center" | 32 
| NAS-Identifier
| align="center" | string 
| Application Name
| Application name of the CDR provider
|-
| align="center" | 40 
| Acct-Status-Type
| align="center" | integer 
| -
| Start or Stop
|-
| align="center" | 44 
| Acct-Session-Id
| align="center" | integer 
| Leg Id
| Call Leg Identifier
|-
| align="center" | 46 
| Acct-Session-Time
| align="center" | integer 
| Session duration
| Duration of the call, in seconds. Corresponds to h323-disconnect-time minus h323-connect-time.
|}

Attribute ID 26, Vendor ID: 9 (Cisco)
{| cellpadding="5" border="1" class="wikitable"
|-
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Vendor specific attribute ID
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | RADIUS IETF param name
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Type
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Toolpack param
! width="610" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Description
|-
| align="center" | 2 
| Cisco-NAS-Port
| align="center" | string 
| NAP name
| Network Access Point name for the call leg
|-
| align="center" | 24 
| h323-conf-id
| align="center" | string 
| Unique Id
| Unique call identifier for the two initial legs (incoming and outgoing) - 128 bits integer formated as xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
|-
| align="center" | 25 
| h323-setup-time
| align="center" | string 
| Start Time
| Represent the call leg setup time - Coordinated Universal Time (UTC)
|-
| align="center" | 26 
| h323-call-origin
| align="center" | string 
| Originator Name
| "originate" for an outgoing leg - "answer" for an incoming leg
|-
| align="center" | 27 
| h323-call-type
| align="center" | string 
| Protocol Type
| If protocol is SIP the value is "VOIP", otherwise it is "Telephony"
|-
| align="center" | 28 
| h323-connect-time
| align="center" | string 
| Connected Time
| Represent the call leg answer time (connect time) - Coordinated Universal Time (UTC)
|-
| align="center" | 29 
| h323-disconnect-time
| align="center" | string 
| EndTime
| Represent the call leg disconnect time - Coordinated Universal Time (UTC)
|-
| align="center" | 30 
| h323-disconnect-cause
| align="center" | string 
| Termination Reason
| Q.931 disconnect (1 to 160) cause, TB Toolpack system cause (200 to 300) and SIP cause (400 to 600)
|-
| align="center" | 35 
| h323-incoming-conf-id
| align="center" | string 
| Unique Id
| Contains the original h323-conf-id in case of call transfer for subsequent outgoing legs - 128 bits integer formated as xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
|-
| align="center" | 115
| release-source
| align="center" | string 
| Termination Source
| "localLeg" if this leg terminate the call or "connectedLeg" if its the connected leg - We use a Cisco string field with our own value definition
|-
| align="center" | 141 
| call-id
| align="center" | String 
| SipCallId
| Content of the "call-id" SIP header
|}

Attribute ID 26, Vendor ID: 21776 (TelcoBridges)
{| cellpadding="5" border="1" class="wikitable"
|-
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Vendor specific attribute ID
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | RADIUS IETF param name
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Type
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Toolpack param
! width="610" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Description
|-
| align="center" | 9 
| Telcob-ChargeIndicator
| align="center" | String 
| ChargeIndicator
| Represent the charge indicator value
|-
| align="center" | 10 
| Telcob-Protocol
| align="center" | String 
| Protocol
| Protocol used for this LegID. Ex. SIP, ISDN, etc.
|-
| align="center" | 11 
| Telcob-Codec
| align="center" | String 
| Codec
| Codec used for this LegID
|-
| align="center" | 12 
| Telcob-RemoteMediaIP
| align="center" | IP address 
| RemoteIP
| RemoteIP used for the media. This is only for VOIP.
|-
| align="center" | 13 
| Telcob-RemoteMediaPort
| align="center" | Integer 
| RemotePort
| RTP Port of the remote peer. This is only for VOIP.
|-
| align="center" | 14 
| Telcob-TrunkName
| align="center" | String 
| TrunkName
| Name of the trunk (ex. "LS004400E1_0_00"). 
This attribute is only for non-VOIP.
|-
| align="center" | 15 
| Telcob-TimeslotNumber
| align="center" | Integer 
| TimeslotNumber
| This is the Timeslot Number. 
This attribute is only for non-VOIP.
|-
| align="center" | 16 
| Telcob-MediaInfo
| align="center" | String 
| MediaInfo
| String that represents the MediaInfo (ex. "PCMU@10.3.10.124:20054" for SIP and "LS_T1_BITS_00:1" for ISDN)
|-
| align="center" | 17 
| Telcob-StartTime
| align="center" | String 
| StartTime
| String that represents the StartTime of the call.
|-
| align="center" | 18 
| Telcob-ConnectedTime
| align="center" | String 
| ConnectedTime
| String that represents the time when the call was connected
|-
| align="center" | 19 
| Telcob-EndTime
| align="center" | String 
| EndTime
| String that represents when the call was completed.
|-
| align="center" | 20 
| Telcob-TerminationCause
| align="center" | Integer 
| TerminationCause
| Integer that represents the Termination Cause
|-
| align="center" | 21 
| Telcob-Other-Leg-Id
| align="center" | Integer 
| Other-Leg-Id
| Integer that represents the other LegID bridged for this call
|-
| align="center" | 22 
| Telcob-TerminationCauseString
| align="center" | String 
| TerminationCauseString
| String that represents the TerminationCause, but in a String format.
|-
| align="center" | 23 
| Telcob-TerminationSource
| align="center" | String 
| TerminationSource
| String that represents the Termination Source
|-
| align="center" | 24 
| Telcob-LocalSipIP*
| align="center" | IPAddr 
| LocalSipIP
| IP Address that represents the Local IP used for SIP.
|-
| align="center" | 25 
| Telcob-LocalSipPort*
| align="center" | Integer 
| LocalSipPort
| Integer that represents the Local port used for SIP.
|-
| align="center" | 26 
| Telcob-LocalMediaIP
| align="center" | IPAddr 
| LocalMediaIP
| IP Address that represents the Local IP used for the media.
|-
| align="center" | 27 
| Telcob-LocalMediaPort
| align="center" | Integer 
| LocalMediaPort
| Integer that represents the Local port used for the media.
|-
| align="center" | 28 
| Telcob-LocalMediaInfo
| align="center" | String 
| LocalMediaInfo
| String that represents the Local Media Info.(ex. "PCMU@10.3.10.124:20054")
Only for VOIP calls.
|-
| align="center" | 29 
| Telcob-RemoteMediaInfo
| align="center" | String 
| RemoteMediaInfo
| String that represents the Remote Media Info.(ex. "PCMU@10.3.10.124:20054")
This is the same as Telcob-MediaInfo. Only for VOIP calls.
|-
| align="center" | 30 
| Telcob-Alert-Time
| align="center" | String 
| AlertTime
| Time where the call has started ringing.
|-
| align="center" | 31 
| Telcob-Redirecting-Number
| align="center" | String 
| RedirectingNumber
| Redirecting number
|-
| align="center" | 32 
| Telcob-Original-Called-Number
| align="center" | String 
| OriginalCalledNumber
| Original called number
|-
| align="center" | 33 
| Telcob-Calling-Presentation
| align="center" | String 
| CallingPresentation
| Calling presentation: "Unspecified", "NotAvailable", "Allowed", "Restricted", "AddressRestricted" or "NameRestricted"
|-
| align="center" | 34 
| Telcob-CallingSubscriberNumber
| align="center" | String 
| CallingSubscriberNumber
| Second calling number (ISDN) or Generic number of type additional calling party number (SS7)
|-
| align="center" | 35 
| Telcob-OriginalCause
| align="center" | String 
| OriginalCause
| String that represents the Original Termination Cause in a String format.
|-
| align="center" | 36 
| Telcob-CustomCdrValue
| align="center" | String 
| In routing script: params[:bridge][:CustomCdrValue] or routes[0..X][:CustomCdrValue]
| String that needs to appear in CDR. If you want to have the same string in all legs, set params[:bridge][:CustomCdrValue] to the value required. If you want to have a custom string for each route, set routes[0..X][:CustomCdrValue]
|}
* = Not implemented.

Text Call Detail Records

2013-11-18T15:01:30Z

Rblanchet: fixed CustomCdrValue name

Text [[call detail record|call detail records]] (CDR) can be used on the [[TMG800]], [[TMG3200]] or [[TMG7800]]. The Call Detail Records are saved in a log file on a local disk. There is an entry done for each call leg, at the start of a call and at the end of the call. In addition, the system can be configured to update the CDRs periodically.

The format of the CDR traces is defined by configuration, using variables that are replaced by the Gateway application when writing to the log.

For example, the following variable will be replaced by the called number:
@{CalledNumber}

In order to save disk space and simplify the archiving and backup of CDR log files, this log file is automatically archived (gzipped) and rotated every N seconds, as specified by the system configuration.

== Enabling text CDR ==
The enabling of Text CDR is described in [[Toolpack:Enabling CDR A|Enabling CDR]].

== Available variables ==
The following variables exist and can be used to define the CDR log format.

=== Variables used for identifying call (or call leg) in general ===
*@{StatusType}: Indicates the type of record ("Start", "Update" or "End").
*@{LegId}: Unique Id for this leg (32 bits value, but may eventually be upgraded to 64 bits value).
*@{OtherLegId}: Id of the other call leg joined with current call leg.
*@{SessionId}: Unique call identifier for two joined and answered call legs, including failed outgoing call attempts (route retry)
Formatted as 4 values of 32 bits, printed as 4 blocks of 8 hexadecimal characters separated by a space
Ex: a939d169 299ffcd0 00000000 00000000
Note: Call Transfer Target legs have separate SessionId. If you need an id to correlate a transferred call
to the original call, use @{OriginalSessionId}.
*@{OriginalSessionId}: Refers to @{SessionId} of the original legs for this call, in case of call transfer.
In fact, Transfer Target leg has a different value for @{SessionId}, but can be linked with the original call
legs through @{OriginalSessionId}.
*@{LinkId}: Same meaning as @{OriginalSessionId}, but presented as a 32 bits integer value.
For all Ids above, please see [[Text_Call_Detail_Records_(CDR)#Known_limitations|Known Limitations]] below for notes about uniqueness of these values.

=== Timestamps ===
*@{AlertTime}: Time where the call has started ringing.
Note: Supported on release 2.7 and up only.
*@{ConnectedTime}: Time where the call was answered (and connected with another leg) (in number of seconds since epoch)
*@{ConnectedTime:format}: Same as @{ConnectedTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{ConnectedTimeUtc:format}:Same as @{ConnectedTime:format} but printed in UTC time, rather than local time zone.
*@{CallDuration}: Call duration in seconds (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{CallDurationMs}: Call duration in milliseconds (end - connected time) (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{EndTime}: Time where the call has started terminating (in number of seconds since epoch).
Note that slightly differs from the @{Timestamp}, since the 'End' CDR trace is printed once the call has
finished terminating,
while @{EndTime} reports the time where the call has started terminating (upon hangup for example).
*@{EndTime:format}: Same as @{EndTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{EndTimeUtc:format}: Same as @{EndTime:format} but printed in UTC time, rather than local time zone.
*@{RingingDuration}: Ringing duration in seconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{RingingDurationMs}: Ringing duration in milliseconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{StartTime}: Time where the call was created (in number of seconds since epoch)
*@{StartTime:format}: Same as @{StartTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{StartTimeUtc:format}: Same as @{StartTime:format} but printed in UTC time, rather than local time zone.
*@{Timestamp}: Time where this CDR log entry was written.
Should not be used for billing purposes. Use @{EndTime} for billing @{EndTime} reports the time where
the call has started terminating (hangup), while *@{Timestamp} the time where signaling confirmed the termination.
*@{Timestamp:format}: Same as @{Timestamp} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{TimestampUtc:format}: Same as @{Timestamp:format} but printed in UTC time, rather than local time zone.

=== Information related to signaling ===
*@{CalledNumber}: Called number
*@{CallingNumber}: Calling number
*@{CallingPresentation}: Calling presentation: "Unspecified", "NotAvailable", "Allowed", "Restricted", "AddressRestricted" or "NameRestricted"
Note: Supported on release 2.7 and up only.
*@{CallingSubscriberNumber}: Second calling number (ISDN) or Generic number of type "additional calling party number" (SS7)
Note: Supported on release 2.7.43 and up only.
*@{CallType}: Call type ("Telephony" or "VOIP")
*@{IncomingNAP}: Name of the NAP that originated this call (incoming call leg's NAP name).
Note: Supported on release 2.7 and up only.
*@{NAP}: Name of the NAP this call leg is from
*@{OriginatorName}: Direction of the call:
- "answer" (incoming call leg) - "originate" (outgoing call leg)
Note: In release 2.6 and earlier, the direction of the call is as follows:
- "originate" (incoming call leg) - "answer" (outgoing call leg)
In release 2.7, the CDR option "Reverse CDR call origin" in Gateway configuration provide the same values as in release 2.6.
*@{OriginalCalledNumber}: Original called number
Note: Supported on release 2.7 and up only.
*@{Protocol}: Type of protocol used ("SS7", "ISDN", or "SIP")
*@{RedirectingNumber}: Redirecting number
Note: Supported on release 2.7 and up only.
*@{TerminationCause}: Cause of the call termination, printed as an integer value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationCauseString}: Cause of the call termination, printed as a string value
*@{OriginalCause}: Original cause of the call termination, printed as a string value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationSource}: Identifies the cause of the leg termination:
- "TermInd": Terminating indication has been received on this leg
- "JoinedTermInd": Terminating indication has been received on the leg joined to current leg,
and has been forwarded to current leg
- "App": Call control application has asked to drop the call
- "Engine": Toolpack engine has decided to terminate this call
(generally due to local errors like disconnected TMedia)
*@{UserName}: For SIP calls, name of the user.
*@{ChargeIndicator}: For TDM (SS7 and CAS R2); received charge indicator in Alert message.

=== Information related to media ===
*@{Codec}: Codec used for this call ("G711" for example)
*@{LocalMediaInfo}: Protocol type dependent information on the call leg (local information for SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port locally used for receiving RTP)
*@{LocalMediaIP}: For VOIP calls, RTP IP address locally used for this call leg.
*@{LocalMediaPort}: For VOIP calls, RTP UDP port locally used for this call leg.
*@{RemoteMediaInfo}: Protocol type dependent information on the call leg (remote information SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port TMedia is sending RTP to)
*@{RemoteMediaIP}: For VOIP calls, RTP IP address of the remote peer for this call leg.
*@{RemoteMediaPort}: For VOIP calls, RTP UDP port of the remote peer for this call leg.
*@{TimeslotNumber}: For TDM (Telephony) calls, timeslot number that this call was using for audio.
*@{TrunkName}: For TDM (Telephony) calls, name of the trunk that this call was using for audio.

=== Information related to routing ===
*@{ApplicationName}: Name of the application that has written this log ("Gateway")
*@{RouteAttribute:attr}: Replaced by the value of a custom route attribute, for the selected
route. This will apply only to outgoing call legs that were made from routing.
Eligible route attributes are:
Route name: Use attribute "route_name". Ex: @{RouteAttribute:route_name}
Route set name: Use attribute "routeset_name". Ex: @{RouteAttribute:routeset_name}
Custom route attribute column: Use the custom attribute name. Ex: @{RouteAttribute:priority}
Routing script parameters: Use the route attribute name provided by routing script.
Ex: If script provides: route[:my_param]="myval"
Then it's included in CDR with @{RouteAttribute:my_param}]
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.
*@{ScriptAttribute:attr}: Replaced by the value of a routing script attribute stored in params[:bridge].
This will apply for incoming and outgoing call legs.
Eligible script attributes are:
Custom CDR value: Use attribute "custom_cdr_value". Ex: @{ScriptAttribute:CustomCdrValue}
Script parameters: Use the attribute name provided by routing script.
Ex: If script provides: params[:bridge][:my_param]="myval"
Then it's included in CDR with @{ScriptAttribute:my_param}]
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.

=== Deprecated values: ===
*@{MediaInfo}: Same as @{RemoteMediaInfo}
*@{RemoteIP}: Same as @{RemoteMediaIP}
*@{RemotePort}: Same as @{RemoteMediaPort}

== CDR sample ==
=== Text CDR sample ===
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP',Protocol='SIP',Direction='answer'
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP2',Protocol='SIP',Direction='originate'
2013-02-07 10:19:07.562-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',TerminationSource='App',Calling='',Called='123',NAP='NAP_SIP2',Direction='originate'
2013-02-07 10:19:07.656-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',Termination Source='App',Calling='',Called='123',NAP='NAP_SIP',Direction='answer'

=== Radius AAA sample ===
* [[File:TelcoBridges_RADIUS_Auth&Acct.pcap|TelcoBridges_RADIUS_Auth&Acct.pcap]]
* [[File:TelcoBridges_RADIUS_Auth&Acct.txt|TelcoBridges_RADIUS_Auth&Acct.txt]]

== Redundancy ==

In a [[TMG7800]] configuration, with redundant TMG-Control servers, only the active server writes the CDR logs. Since the active server may change over time, CDR parsing must take into account that CDR logs may be found in files from the two servers.

The analysis of the logs for the purpose of extracting billing information must be done after combining the two logs, from both TMG-Control servers, sorting the entries by timestamp for example. See how to [[TMG:Retrieve_Text_CDR|Retrieve Text CDR here]].

== CDR entry loss due to switchover ==
In some situations (during HA switchover for example), some CDR entries may be lost.

The following guide lines provide information on how to deal with these corner cases:

[[Call_Detail_Records_Entry_Loss|Deal with CDR entries loss]]

== Retrieving Text CDRs ==

There are 2 ways to retrieve the text CDR manually or automatically. The procedures are described in [[TMG:Retrieve_Text_CDR|Retrieve Text CDR]].

== Notes ==
*This mode of operation is not recommended for [[TMG800]] or [[TMG3200]] with a flash disk (last shipment January 2011). However, the [[TMG800]] or [[TMG3200]] with SATA or SSD disk option is OK (use command tbproduct: if the command can be executed, the disk is SATA or SSD).
*TelcoBridges does not recommend storing CDR logs via network file systems (NFS or other). We highly recommend writing to a local hard drive and have developed a background script that moves the gzipped log segments for backup or analysis.

[[category:Needs revising]]

Text Call Detail Records

2013-11-15T19:31:49Z

Rblanchet: New Script attribute available in CDR

Text [[call detail record|call detail records]] (CDR) can be used on the [[TMG800]], [[TMG3200]] or [[TMG7800]]. The Call Detail Records are saved in a log file on a local disk. There is an entry done for each call leg, at the start of a call and at the end of the call. In addition, the system can be configured to update the CDRs periodically.

The format of the CDR traces is defined by configuration, using variables that are replaced by the Gateway application when writing to the log.

For example, the following variable will be replaced by the called number:
@{CalledNumber}

In order to save disk space and simplify the archiving and backup of CDR log files, this log file is automatically archived (gzipped) and rotated every N seconds, as specified by the system configuration.

== Enabling text CDR ==
The enabling of Text CDR is described in [[Toolpack:Enabling CDR A|Enabling CDR]].

== Available variables ==
The following variables exist and can be used to define the CDR log format.

=== Variables used for identifying call (or call leg) in general ===
*@{StatusType}: Indicates the type of record ("Start", "Update" or "End").
*@{LegId}: Unique Id for this leg (32 bits value, but may eventually be upgraded to 64 bits value).
*@{OtherLegId}: Id of the other call leg joined with current call leg.
*@{SessionId}: Unique call identifier for two joined and answered call legs, including failed outgoing call attempts (route retry)
Formatted as 4 values of 32 bits, printed as 4 blocks of 8 hexadecimal characters separated by a space
Ex: a939d169 299ffcd0 00000000 00000000
Note: Call Transfer Target legs have separate SessionId. If you need an id to correlate a transferred call
to the original call, use @{OriginalSessionId}.
*@{OriginalSessionId}: Refers to @{SessionId} of the original legs for this call, in case of call transfer.
In fact, Transfer Target leg has a different value for @{SessionId}, but can be linked with the original call
legs through @{OriginalSessionId}.
*@{LinkId}: Same meaning as @{OriginalSessionId}, but presented as a 32 bits integer value.
For all Ids above, please see [[Text_Call_Detail_Records_(CDR)#Known_limitations|Known Limitations]] below for notes about uniqueness of these values.

=== Timestamps ===
*@{AlertTime}: Time where the call has started ringing.
Note: Supported on release 2.7 and up only.
*@{ConnectedTime}: Time where the call was answered (and connected with another leg) (in number of seconds since epoch)
*@{ConnectedTime:format}: Same as @{ConnectedTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{ConnectedTimeUtc:format}:Same as @{ConnectedTime:format} but printed in UTC time, rather than local time zone.
*@{CallDuration}: Call duration in seconds (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{CallDurationMs}: Call duration in milliseconds (end - connected time) (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{EndTime}: Time where the call has started terminating (in number of seconds since epoch).
Note that slightly differs from the @{Timestamp}, since the 'End' CDR trace is printed once the call has
finished terminating,
while @{EndTime} reports the time where the call has started terminating (upon hangup for example).
*@{EndTime:format}: Same as @{EndTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{EndTimeUtc:format}: Same as @{EndTime:format} but printed in UTC time, rather than local time zone.
*@{RingingDuration}: Ringing duration in seconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{RingingDurationMs}: Ringing duration in milliseconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{StartTime}: Time where the call was created (in number of seconds since epoch)
*@{StartTime:format}: Same as @{StartTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{StartTimeUtc:format}: Same as @{StartTime:format} but printed in UTC time, rather than local time zone.
*@{Timestamp}: Time where this CDR log entry was written.
Should not be used for billing purposes. Use @{EndTime} for billing @{EndTime} reports the time where
the call has started terminating (hangup), while *@{Timestamp} the time where signaling confirmed the termination.
*@{Timestamp:format}: Same as @{Timestamp} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{TimestampUtc:format}: Same as @{Timestamp:format} but printed in UTC time, rather than local time zone.

=== Information related to signaling ===
*@{CalledNumber}: Called number
*@{CallingNumber}: Calling number
*@{CallingPresentation}: Calling presentation: "Unspecified", "NotAvailable", "Allowed", "Restricted", "AddressRestricted" or "NameRestricted"
Note: Supported on release 2.7 and up only.
*@{CallingSubscriberNumber}: Second calling number (ISDN) or Generic number of type "additional calling party number" (SS7)
Note: Supported on release 2.7.43 and up only.
*@{CallType}: Call type ("Telephony" or "VOIP")
*@{IncomingNAP}: Name of the NAP that originated this call (incoming call leg's NAP name).
Note: Supported on release 2.7 and up only.
*@{NAP}: Name of the NAP this call leg is from
*@{OriginatorName}: Direction of the call:
- "answer" (incoming call leg) - "originate" (outgoing call leg)
Note: In release 2.6 and earlier, the direction of the call is as follows:
- "originate" (incoming call leg) - "answer" (outgoing call leg)
In release 2.7, the CDR option "Reverse CDR call origin" in Gateway configuration provide the same values as in release 2.6.
*@{OriginalCalledNumber}: Original called number
Note: Supported on release 2.7 and up only.
*@{Protocol}: Type of protocol used ("SS7", "ISDN", or "SIP")
*@{RedirectingNumber}: Redirecting number
Note: Supported on release 2.7 and up only.
*@{TerminationCause}: Cause of the call termination, printed as an integer value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationCauseString}: Cause of the call termination, printed as a string value
*@{OriginalCause}: Original cause of the call termination, printed as a string value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationSource}: Identifies the cause of the leg termination:
- "TermInd": Terminating indication has been received on this leg
- "JoinedTermInd": Terminating indication has been received on the leg joined to current leg,
and has been forwarded to current leg
- "App": Call control application has asked to drop the call
- "Engine": Toolpack engine has decided to terminate this call
(generally due to local errors like disconnected TMedia)
*@{UserName}: For SIP calls, name of the user.
*@{ChargeIndicator}: For TDM (SS7 and CAS R2); received charge indicator in Alert message.

=== Information related to media ===
*@{Codec}: Codec used for this call ("G711" for example)
*@{LocalMediaInfo}: Protocol type dependent information on the call leg (local information for SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port locally used for receiving RTP)
*@{LocalMediaIP}: For VOIP calls, RTP IP address locally used for this call leg.
*@{LocalMediaPort}: For VOIP calls, RTP UDP port locally used for this call leg.
*@{RemoteMediaInfo}: Protocol type dependent information on the call leg (remote information SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port TMedia is sending RTP to)
*@{RemoteMediaIP}: For VOIP calls, RTP IP address of the remote peer for this call leg.
*@{RemoteMediaPort}: For VOIP calls, RTP UDP port of the remote peer for this call leg.
*@{TimeslotNumber}: For TDM (Telephony) calls, timeslot number that this call was using for audio.
*@{TrunkName}: For TDM (Telephony) calls, name of the trunk that this call was using for audio.

=== Information related to routing ===
*@{ApplicationName}: Name of the application that has written this log ("Gateway")
*@{RouteAttribute:attr}: Replaced by the value of a custom route attribute, for the selected
route. This will apply only to outgoing call legs that were made from routing.
Eligible route attributes are:
Route name: Use attribute "route_name". Ex: @{RouteAttribute:route_name}
Route set name: Use attribute "routeset_name". Ex: @{RouteAttribute:routeset_name}
Custom route attribute column: Use the custom attribute name. Ex: @{RouteAttribute:priority}
Routing script parameters: Use the route attribute name provided by routing script.
Ex: If script provides: route[:my_param]="myval"
Then it's included in CDR with @{RouteAttribute:my_param}]
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.
*@{ScriptAttribute:attr}: Replaced by the value of a routing script attribute stored in params[:bridge].
This will apply for incoming and outgoing call legs.
Eligible script attributes are:
Custom CDR value: Use attribute "custom_cdr_value". Ex: @{ScriptAttribute:custom_cdr_value}
Script parameters: Use the attribute name provided by routing script.
Ex: If script provides: params[:bridge][:my_param]="myval"
Then it's included in CDR with @{ScriptAttribute:my_param}]
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.

=== Deprecated values: ===
*@{MediaInfo}: Same as @{RemoteMediaInfo}
*@{RemoteIP}: Same as @{RemoteMediaIP}
*@{RemotePort}: Same as @{RemoteMediaPort}

== CDR sample ==
=== Text CDR sample ===
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP',Protocol='SIP',Direction='answer'
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP2',Protocol='SIP',Direction='originate'
2013-02-07 10:19:07.562-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',TerminationSource='App',Calling='',Called='123',NAP='NAP_SIP2',Direction='originate'
2013-02-07 10:19:07.656-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',Termination Source='App',Calling='',Called='123',NAP='NAP_SIP',Direction='answer'

=== Radius AAA sample ===
* [[File:TelcoBridges_RADIUS_Auth&Acct.pcap|TelcoBridges_RADIUS_Auth&Acct.pcap]]
* [[File:TelcoBridges_RADIUS_Auth&Acct.txt|TelcoBridges_RADIUS_Auth&Acct.txt]]

== Redundancy ==

In a [[TMG7800]] configuration, with redundant TMG-Control servers, only the active server writes the CDR logs. Since the active server may change over time, CDR parsing must take into account that CDR logs may be found in files from the two servers.

The analysis of the logs for the purpose of extracting billing information must be done after combining the two logs, from both TMG-Control servers, sorting the entries by timestamp for example. See how to [[TMG:Retrieve_Text_CDR|Retrieve Text CDR here]].

== CDR entry loss due to switchover ==
In some situations (during HA switchover for example), some CDR entries may be lost.

The following guide lines provide information on how to deal with these corner cases:

[[Call_Detail_Records_Entry_Loss|Deal with CDR entries loss]]

== Retrieving Text CDRs ==

There are 2 ways to retrieve the text CDR manually or automatically. The procedures are described in [[TMG:Retrieve_Text_CDR|Retrieve Text CDR]].

== Notes ==
*This mode of operation is not recommended for [[TMG800]] or [[TMG3200]] with a flash disk (last shipment January 2011). However, the [[TMG800]] or [[TMG3200]] with SATA or SSD disk option is OK (use command tbproduct: if the command can be executed, the disk is SATA or SSD).
*TelcoBridges does not recommend storing CDR logs via network file systems (NFS or other). We highly recommend writing to a local hard drive and have developed a background script that moves the gzipped log segments for backup or analysis.

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2013-11-14T15:33:48Z

Rblanchet: Update comment for sip headers

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "Reason values".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_screening 
| Q931: 'Redirecting number' 1st IE - Screening indicator 
| N/A 
| Q763: 'Redirecting number' IE - screening (national) 
| SIP:Diversion (2nd header) - diversion-screen 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_screening 
| Q931: 'Redirecting number' 2nd IE - Screening indicator 
| N/A 
| Q763: 'Redirection number' IE - screening (national) 
| SIP:Diversion (1st header) - diversion-screen 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward generic headers' in the profile. Hash table of generic headers. 
| 
|-
| nap 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number</tt>
*<tt>international_number</tt>
*<tt>national_number</tt>
*<tt>subscriber_number</tt>
*<tt>network_specific</tt>
*<tt>network_routing_national_format</tt>
*<tt>network_routing_international_format</tt>
*<tt>abbreviated_number</tt>
*<tt>subscriber_number_operator_requested</tt>
*<tt>national_number_operator_requested</tt>
*<tt>international_number_operator_requested</tt>
*<tt>no_number_present_operator_requested</tt>
*<tt>no_number_present_cut_through_call_to_carrier</tt>
*<tt>test_line_test_code</tt>
*<tt>non_unique_subscriber_number</tt>
*<tt>non_unique_national_number</tt>
*<tt>non_unique_international_number</tt>
*<tt>call_950_number</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values ===

*<tt>unspecified</tt>
*<tt>not_available</tt>
*<tt>allowed</tt>
*<tt>restricted</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

=== Screening values ===

*<tt>unspecified</tt>
*<tt>no</tt>
*<tt>pass</tt>
*<tt>fail</tt>
*<tt>network_provided</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number reason values ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

 

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

 

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack:
<pre>Accept
Accept-Contact
Accept-Encoding
Accept-Language
Alert-Info
Allow
Allow-Events
Also
Anonymity
Authorization
Authentication-Info
Call-ID
Call-Info
Contact
Content-Disposition
Content-Encoding
Content-Language
Content-Length
Content-Type
CSeq
Date
Diversion
Encryption
Error-Info
Event
Expires
From
In-Reply-To
Max-Forwards
MIME-version
Min-Expires
Min-SE
Organization
Path
Priority
Privacy
Proxy-Authenticate
Proxy-Authorization
Proxy-Require
P-Media-Authorization
P-Asserted-Identity
P-Preferred-Identity
RAck
Reason
Record-Route
Refer-To
Referred-By
Reject-Contact
Remote-Party-ID
Replaces
Reply-To
Request-Disposition
Require
Response-Key
Retry-After
RPID-Privacy
Route
RSeq
Security-Client
Security-Server
Security-Verify
Server
Service-Route
Session-Expires
Subject
Subscription-State
Supported
Timestamp
To
Unsupported
User-Agent
Via
Warning
WWW-Authenticate
</pre>

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** @{LegId}: Current LegId (Unique Id for this leg)
*** Example: "F3D67B4B"
** @{Protocol}: Protocol type of current leg
*** Example: "SS7"
** @{Direction}: Direction of current leg (IN our OUT)
*** Example: "IN"
** @{PKG_HOME}: Path where packages are stored. Note: It's not recomended to use that path on redundant systems, package file replication may cause confusion in recorded files.
*** Example: "/lib/tb/toolpack/pkg"
** @{CURRENT_PKG}: Version of current package
*** Example: "2.6.45"
** @{PROMPT_PATH}: Default path where audio prompts are stored. Note: It's not recomended to use that path on redundant systems, package file replication may cause confusion in recorded files.
*** Example: "/lib/tb/toolpack/pkg/prompts"
** @{TBX_GW_PORT}: Current "System Id" (also called "Gateway Port")
*** Example: "12358"

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

#define NAP_STATS_FIELDS \
/* Field, szName, szDescription, szOptions */ \
( SIGNALING_TYPE, "signaling_type", "Signaling type.", "" ) \
( INCOMING_CALL_CNT, "inst_incoming_call_cnt", "Instantaneous Count of incoming calls.", "" ) \
( OUTGOING_CALL_CNT, "inst_outgoing_call_cnt", "Instantaneous Count of outgoing calls.", "" ) \
( AVAILABLE_CNT, "available_cnt", "Number of available circuits or channels.", "" ) \
( UNAVAILABLE_CNT, "unavailable_cnt", "Number of unavailable circuits or channels.", "" ) \
( AVAILABILITY_PCT, "availability_percent", "Percentage of available circuits or channels.", "" ) \
( USAGE_PCT, "usage_percent", "Percentage of used circuits or channels.", "" ) \
( TOTAL_INCOMING_CALL_CNT, "total_incoming_call_cnt", "Total Count of incoming calls.", "" ) \
( ASR_STRUCT, "asr_statistics_struct", "Detailed Answer-Seizure Rate Statistics.", "" ) \
( GLOBAL_ASR_PCT, "global_asr_percent", "Global calculated ASR percentage.", "" ) \
( TOTAL_OUTGOING_CALL_CNT, "total_outgoing_call_cnt", "Total Count of outgoing calls.", "" ) \
( LAST_24H_ASR_PCT, "last_24h_asr_percent", "Last 24 hours calculated ASR percentage.", "" ) \
( LAST_24H_OUTGOING_CALL_CNT, "last_24h_outgoing_call_cnt", "Last 24 hours outgoing calls.", "" ) \
( HOUR_ASR_PCT, "current_hour_asr_percent", "Current hour calculated ASR percentage.", "" ) \
( HOUR_OUTGOING_CALL_CNT, "current_hour_outgoing_call_cnt", "Current hour outgoing calls.", "" ) \
( LAST_HOUR_ASR_PCT, "last_hour_asr_percent", "Last hour calculated ASR percentage.", "" ) \
( LAST_HOUR_OUTGOING_CALL_CNT, "last_hour_outgoing_call_cnt", "Last hour outgoing calls.", "" ) \
( AVAILABILITY_DETECTION_STRUCT, "availability_detection_struct", "Detailed availibility detection Statistics", "" ) \
( POLL_REMOTE_PROXY, "poll_remote_proxy", "Remote proxy polling enabled", "" ) \
( IS_AVAILABLE, "is_available", "Remote proxy actually available or not", "" ) \
( TIME_SINCE_POLLING, "time_since_polling", "Time since the last availibility polling", "" ) \
( TIME_AVAILABLE_SECONDS, "time_available_seconds", "Number of seconds since the NAP is available", "x" ) \
( TIME_UNAVAILABLE_SECONDS, "time_unavailable_seconds", "Number of seconds since the NAP is unavailable", "x" ) \
( REGISTRATION_STRUCT, "registration_struct", "Detailed registration Statistics", "" ) \
( REGISTER_TO_PROXY, "register_to_proxy", "Register to proxy enabled", "" ) \
( IS_REGISTERED, "registered", "Actually registered or not", "" ) \
( TIME_SINCE_REFRESH, "time_since_refresh", "Time since the last refresh", "" ) \
( TIME_REGISTERED_SECONDS, "time_registered_seconds", "Number of seconds since the NAP is registered", "x" ) \
( TIME_NOT_REGISTERED_SECONDS, "time_not_registered_seconds", "Number of seconds since the NAP is not registered", "x" ) \
/*!< Nap Status Fields */

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== Test parameters ==

=== @call_params ===

That variable should contain a hash of call parameters that will passed to the routing script. This is equivalent to the incoming call parameters.

 

=== @nap_list ===

A list of 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.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2013-11-12T16:54:20Z

Rblanchet: List of not custom sip headers

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "Reason values".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_screening 
| Q931: 'Redirecting number' 1st IE - Screening indicator 
| N/A 
| Q763: 'Redirecting number' IE - screening (national) 
| SIP:Diversion (2nd header) - diversion-screen 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_screening 
| Q931: 'Redirecting number' 2nd IE - Screening indicator 
| N/A 
| Q763: 'Redirection number' IE - screening (national) 
| SIP:Diversion (1st header) - diversion-screen 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward generic headers' in the profile. Hash table of generic headers. 
| 
|-
| nap 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number</tt>
*<tt>international_number</tt>
*<tt>national_number</tt>
*<tt>subscriber_number</tt>
*<tt>network_specific</tt>
*<tt>network_routing_national_format</tt>
*<tt>network_routing_international_format</tt>
*<tt>abbreviated_number</tt>
*<tt>subscriber_number_operator_requested</tt>
*<tt>national_number_operator_requested</tt>
*<tt>international_number_operator_requested</tt>
*<tt>no_number_present_operator_requested</tt>
*<tt>no_number_present_cut_through_call_to_carrier</tt>
*<tt>test_line_test_code</tt>
*<tt>non_unique_subscriber_number</tt>
*<tt>non_unique_national_number</tt>
*<tt>non_unique_international_number</tt>
*<tt>call_950_number</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values ===

*<tt>unspecified</tt>
*<tt>not_available</tt>
*<tt>allowed</tt>
*<tt>restricted</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

=== Screening values ===

*<tt>unspecified</tt>
*<tt>no</tt>
*<tt>pass</tt>
*<tt>fail</tt>
*<tt>network_provided</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number reason values ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

 

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

 

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

List of '''NOT''' custom sip header:
<pre>Accept
Accept-Contact
Accept-Encoding
Accept-Language
Alert-Info
Allow
Allow-Events
Also
Anonymity
Authorization
Authentication-Info
Call-ID
Call-Info
Contact
Content-Disposition
Content-Encoding
Content-Language
Content-Length
Content-Type
CSeq
Date
Diversion
Encryption
Error-Info
Event
Expires
From
In-Reply-To
Max-Forwards
MIME-version
Min-Expires
Min-SE
Organization
Path
Priority
Privacy
Proxy-Authenticate
Proxy-Authorization
Proxy-Require
P-Media-Authorization
P-Asserted-Identity
P-Preferred-Identity
RAck
Reason
Record-Route
Refer-To
Referred-By
Reject-Contact
Remote-Party-ID
Replaces
Reply-To
Request-Disposition
Require
Response-Key
Retry-After
RPID-Privacy
Route
RSeq
Security-Client
Security-Server
Security-Verify
Server
Service-Route
Session-Expires
Subject
Subscription-State
Supported
Timestamp
To
Unsupported
User-Agent
Via
Warning
WWW-Authenticate
</pre>

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** @{LegId}: Current LegId (Unique Id for this leg)
*** Example: "F3D67B4B"
** @{Protocol}: Protocol type of current leg
*** Example: "SS7"
** @{Direction}: Direction of current leg (IN our OUT)
*** Example: "IN"
** @{PKG_HOME}: Path where packages are stored. Note: It's not recomended to use that path on redundant systems, package file replication may cause confusion in recorded files.
*** Example: "/lib/tb/toolpack/pkg"
** @{CURRENT_PKG}: Version of current package
*** Example: "2.6.45"
** @{PROMPT_PATH}: Default path where audio prompts are stored. Note: It's not recomended to use that path on redundant systems, package file replication may cause confusion in recorded files.
*** Example: "/lib/tb/toolpack/pkg/prompts"
** @{TBX_GW_PORT}: Current "System Id" (also called "Gateway Port")
*** Example: "12358"

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

#define NAP_STATS_FIELDS \
/* Field, szName, szDescription, szOptions */ \
( SIGNALING_TYPE, "signaling_type", "Signaling type.", "" ) \
( INCOMING_CALL_CNT, "inst_incoming_call_cnt", "Instantaneous Count of incoming calls.", "" ) \
( OUTGOING_CALL_CNT, "inst_outgoing_call_cnt", "Instantaneous Count of outgoing calls.", "" ) \
( AVAILABLE_CNT, "available_cnt", "Number of available circuits or channels.", "" ) \
( UNAVAILABLE_CNT, "unavailable_cnt", "Number of unavailable circuits or channels.", "" ) \
( AVAILABILITY_PCT, "availability_percent", "Percentage of available circuits or channels.", "" ) \
( USAGE_PCT, "usage_percent", "Percentage of used circuits or channels.", "" ) \
( TOTAL_INCOMING_CALL_CNT, "total_incoming_call_cnt", "Total Count of incoming calls.", "" ) \
( ASR_STRUCT, "asr_statistics_struct", "Detailed Answer-Seizure Rate Statistics.", "" ) \
( GLOBAL_ASR_PCT, "global_asr_percent", "Global calculated ASR percentage.", "" ) \
( TOTAL_OUTGOING_CALL_CNT, "total_outgoing_call_cnt", "Total Count of outgoing calls.", "" ) \
( LAST_24H_ASR_PCT, "last_24h_asr_percent", "Last 24 hours calculated ASR percentage.", "" ) \
( LAST_24H_OUTGOING_CALL_CNT, "last_24h_outgoing_call_cnt", "Last 24 hours outgoing calls.", "" ) \
( HOUR_ASR_PCT, "current_hour_asr_percent", "Current hour calculated ASR percentage.", "" ) \
( HOUR_OUTGOING_CALL_CNT, "current_hour_outgoing_call_cnt", "Current hour outgoing calls.", "" ) \
( LAST_HOUR_ASR_PCT, "last_hour_asr_percent", "Last hour calculated ASR percentage.", "" ) \
( LAST_HOUR_OUTGOING_CALL_CNT, "last_hour_outgoing_call_cnt", "Last hour outgoing calls.", "" ) \
( AVAILABILITY_DETECTION_STRUCT, "availability_detection_struct", "Detailed availibility detection Statistics", "" ) \
( POLL_REMOTE_PROXY, "poll_remote_proxy", "Remote proxy polling enabled", "" ) \
( IS_AVAILABLE, "is_available", "Remote proxy actually available or not", "" ) \
( TIME_SINCE_POLLING, "time_since_polling", "Time since the last availibility polling", "" ) \
( TIME_AVAILABLE_SECONDS, "time_available_seconds", "Number of seconds since the NAP is available", "x" ) \
( TIME_UNAVAILABLE_SECONDS, "time_unavailable_seconds", "Number of seconds since the NAP is unavailable", "x" ) \
( REGISTRATION_STRUCT, "registration_struct", "Detailed registration Statistics", "" ) \
( REGISTER_TO_PROXY, "register_to_proxy", "Register to proxy enabled", "" ) \
( IS_REGISTERED, "registered", "Actually registered or not", "" ) \
( TIME_SINCE_REFRESH, "time_since_refresh", "Time since the last refresh", "" ) \
( TIME_REGISTERED_SECONDS, "time_registered_seconds", "Number of seconds since the NAP is registered", "x" ) \
( TIME_NOT_REGISTERED_SECONDS, "time_not_registered_seconds", "Number of seconds since the NAP is not registered", "x" ) \
/*!< Nap Status Fields */

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== Test parameters ==

=== @call_params ===

That variable should contain a hash of call parameters that will passed to the routing script. This is equivalent to the incoming call parameters.

 

=== @nap_list ===

A list of 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.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2013-11-11T14:26:07Z

Rblanchet: New sip headers format

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "Reason values".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_screening 
| Q931: 'Redirecting number' 1st IE - Screening indicator 
| N/A 
| Q763: 'Redirecting number' IE - screening (national) 
| SIP:Diversion (2nd header) - diversion-screen 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_screening 
| Q931: 'Redirecting number' 2nd IE - Screening indicator 
| N/A 
| Q763: 'Redirection number' IE - screening (national) 
| SIP:Diversion (1st header) - diversion-screen 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward generic headers' in the profile. Hash table of generic headers. 
| 
|-
| nap 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number</tt>
*<tt>international_number</tt>
*<tt>national_number</tt>
*<tt>subscriber_number</tt>
*<tt>network_specific</tt>
*<tt>network_routing_national_format</tt>
*<tt>network_routing_international_format</tt>
*<tt>abbreviated_number</tt>
*<tt>subscriber_number_operator_requested</tt>
*<tt>national_number_operator_requested</tt>
*<tt>international_number_operator_requested</tt>
*<tt>no_number_present_operator_requested</tt>
*<tt>no_number_present_cut_through_call_to_carrier</tt>
*<tt>test_line_test_code</tt>
*<tt>non_unique_subscriber_number</tt>
*<tt>non_unique_national_number</tt>
*<tt>non_unique_international_number</tt>
*<tt>call_950_number</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values ===

*<tt>unspecified</tt>
*<tt>not_available</tt>
*<tt>allowed</tt>
*<tt>restricted</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

=== Screening values ===

*<tt>unspecified</tt>
*<tt>no</tt>
*<tt>pass</tt>
*<tt>fail</tt>
*<tt>network_provided</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number reason values ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

 

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

 

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** @{LegId}: Current LegId (Unique Id for this leg)
*** Example: "F3D67B4B"
** @{Protocol}: Protocol type of current leg
*** Example: "SS7"
** @{Direction}: Direction of current leg (IN our OUT)
*** Example: "IN"
** @{PKG_HOME}: Path where packages are stored. Note: It's not recomended to use that path on redundant systems, package file replication may cause confusion in recorded files.
*** Example: "/lib/tb/toolpack/pkg"
** @{CURRENT_PKG}: Version of current package
*** Example: "2.6.45"
** @{PROMPT_PATH}: Default path where audio prompts are stored. Note: It's not recomended to use that path on redundant systems, package file replication may cause confusion in recorded files.
*** Example: "/lib/tb/toolpack/pkg/prompts"
** @{TBX_GW_PORT}: Current "System Id" (also called "Gateway Port")
*** Example: "12358"

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

#define NAP_STATS_FIELDS \
/* Field, szName, szDescription, szOptions */ \
( SIGNALING_TYPE, "signaling_type", "Signaling type.", "" ) \
( INCOMING_CALL_CNT, "inst_incoming_call_cnt", "Instantaneous Count of incoming calls.", "" ) \
( OUTGOING_CALL_CNT, "inst_outgoing_call_cnt", "Instantaneous Count of outgoing calls.", "" ) \
( AVAILABLE_CNT, "available_cnt", "Number of available circuits or channels.", "" ) \
( UNAVAILABLE_CNT, "unavailable_cnt", "Number of unavailable circuits or channels.", "" ) \
( AVAILABILITY_PCT, "availability_percent", "Percentage of available circuits or channels.", "" ) \
( USAGE_PCT, "usage_percent", "Percentage of used circuits or channels.", "" ) \
( TOTAL_INCOMING_CALL_CNT, "total_incoming_call_cnt", "Total Count of incoming calls.", "" ) \
( ASR_STRUCT, "asr_statistics_struct", "Detailed Answer-Seizure Rate Statistics.", "" ) \
( GLOBAL_ASR_PCT, "global_asr_percent", "Global calculated ASR percentage.", "" ) \
( TOTAL_OUTGOING_CALL_CNT, "total_outgoing_call_cnt", "Total Count of outgoing calls.", "" ) \
( LAST_24H_ASR_PCT, "last_24h_asr_percent", "Last 24 hours calculated ASR percentage.", "" ) \
( LAST_24H_OUTGOING_CALL_CNT, "last_24h_outgoing_call_cnt", "Last 24 hours outgoing calls.", "" ) \
( HOUR_ASR_PCT, "current_hour_asr_percent", "Current hour calculated ASR percentage.", "" ) \
( HOUR_OUTGOING_CALL_CNT, "current_hour_outgoing_call_cnt", "Current hour outgoing calls.", "" ) \
( LAST_HOUR_ASR_PCT, "last_hour_asr_percent", "Last hour calculated ASR percentage.", "" ) \
( LAST_HOUR_OUTGOING_CALL_CNT, "last_hour_outgoing_call_cnt", "Last hour outgoing calls.", "" ) \
( AVAILABILITY_DETECTION_STRUCT, "availability_detection_struct", "Detailed availibility detection Statistics", "" ) \
( POLL_REMOTE_PROXY, "poll_remote_proxy", "Remote proxy polling enabled", "" ) \
( IS_AVAILABLE, "is_available", "Remote proxy actually available or not", "" ) \
( TIME_SINCE_POLLING, "time_since_polling", "Time since the last availibility polling", "" ) \
( TIME_AVAILABLE_SECONDS, "time_available_seconds", "Number of seconds since the NAP is available", "x" ) \
( TIME_UNAVAILABLE_SECONDS, "time_unavailable_seconds", "Number of seconds since the NAP is unavailable", "x" ) \
( REGISTRATION_STRUCT, "registration_struct", "Detailed registration Statistics", "" ) \
( REGISTER_TO_PROXY, "register_to_proxy", "Register to proxy enabled", "" ) \
( IS_REGISTERED, "registered", "Actually registered or not", "" ) \
( TIME_SINCE_REFRESH, "time_since_refresh", "Time since the last refresh", "" ) \
( TIME_REGISTERED_SECONDS, "time_registered_seconds", "Number of seconds since the NAP is registered", "x" ) \
( TIME_NOT_REGISTERED_SECONDS, "time_not_registered_seconds", "Number of seconds since the NAP is not registered", "x" ) \
/*!< Nap Status Fields */

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== Test parameters ==

=== @call_params ===

That variable should contain a hash of call parameters that will passed to the routing script. This is equivalent to the incoming call parameters.

 

=== @nap_list ===

A list of 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.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2013-11-11T14:23:16Z

Rblanchet: New sip headers format

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "Reason values".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_screening 
| Q931: 'Redirecting number' 1st IE - Screening indicator 
| N/A 
| Q763: 'Redirecting number' IE - screening (national) 
| SIP:Diversion (2nd header) - diversion-screen 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_screening 
| Q931: 'Redirecting number' 2nd IE - Screening indicator 
| N/A 
| Q763: 'Redirection number' IE - screening (national) 
| SIP:Diversion (1st header) - diversion-screen 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Outgoing leg (write) only 
| 
|-
| nap 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number</tt>
*<tt>international_number</tt>
*<tt>national_number</tt>
*<tt>subscriber_number</tt>
*<tt>network_specific</tt>
*<tt>network_routing_national_format</tt>
*<tt>network_routing_international_format</tt>
*<tt>abbreviated_number</tt>
*<tt>subscriber_number_operator_requested</tt>
*<tt>national_number_operator_requested</tt>
*<tt>international_number_operator_requested</tt>
*<tt>no_number_present_operator_requested</tt>
*<tt>no_number_present_cut_through_call_to_carrier</tt>
*<tt>test_line_test_code</tt>
*<tt>non_unique_subscriber_number</tt>
*<tt>non_unique_national_number</tt>
*<tt>non_unique_international_number</tt>
*<tt>call_950_number</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values ===

*<tt>unspecified</tt>
*<tt>not_available</tt>
*<tt>allowed</tt>
*<tt>restricted</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

=== Screening values ===

*<tt>unspecified</tt>
*<tt>no</tt>
*<tt>pass</tt>
*<tt>fail</tt>
*<tt>network_provided</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number reason values ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

 

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

 

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** @{LegId}: Current LegId (Unique Id for this leg)
*** Example: "F3D67B4B"
** @{Protocol}: Protocol type of current leg
*** Example: "SS7"
** @{Direction}: Direction of current leg (IN our OUT)
*** Example: "IN"
** @{PKG_HOME}: Path where packages are stored. Note: It's not recomended to use that path on redundant systems, package file replication may cause confusion in recorded files.
*** Example: "/lib/tb/toolpack/pkg"
** @{CURRENT_PKG}: Version of current package
*** Example: "2.6.45"
** @{PROMPT_PATH}: Default path where audio prompts are stored. Note: It's not recomended to use that path on redundant systems, package file replication may cause confusion in recorded files.
*** Example: "/lib/tb/toolpack/pkg/prompts"
** @{TBX_GW_PORT}: Current "System Id" (also called "Gateway Port")
*** Example: "12358"

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

#define NAP_STATS_FIELDS \
/* Field, szName, szDescription, szOptions */ \
( SIGNALING_TYPE, "signaling_type", "Signaling type.", "" ) \
( INCOMING_CALL_CNT, "inst_incoming_call_cnt", "Instantaneous Count of incoming calls.", "" ) \
( OUTGOING_CALL_CNT, "inst_outgoing_call_cnt", "Instantaneous Count of outgoing calls.", "" ) \
( AVAILABLE_CNT, "available_cnt", "Number of available circuits or channels.", "" ) \
( UNAVAILABLE_CNT, "unavailable_cnt", "Number of unavailable circuits or channels.", "" ) \
( AVAILABILITY_PCT, "availability_percent", "Percentage of available circuits or channels.", "" ) \
( USAGE_PCT, "usage_percent", "Percentage of used circuits or channels.", "" ) \
( TOTAL_INCOMING_CALL_CNT, "total_incoming_call_cnt", "Total Count of incoming calls.", "" ) \
( ASR_STRUCT, "asr_statistics_struct", "Detailed Answer-Seizure Rate Statistics.", "" ) \
( GLOBAL_ASR_PCT, "global_asr_percent", "Global calculated ASR percentage.", "" ) \
( TOTAL_OUTGOING_CALL_CNT, "total_outgoing_call_cnt", "Total Count of outgoing calls.", "" ) \
( LAST_24H_ASR_PCT, "last_24h_asr_percent", "Last 24 hours calculated ASR percentage.", "" ) \
( LAST_24H_OUTGOING_CALL_CNT, "last_24h_outgoing_call_cnt", "Last 24 hours outgoing calls.", "" ) \
( HOUR_ASR_PCT, "current_hour_asr_percent", "Current hour calculated ASR percentage.", "" ) \
( HOUR_OUTGOING_CALL_CNT, "current_hour_outgoing_call_cnt", "Current hour outgoing calls.", "" ) \
( LAST_HOUR_ASR_PCT, "last_hour_asr_percent", "Last hour calculated ASR percentage.", "" ) \
( LAST_HOUR_OUTGOING_CALL_CNT, "last_hour_outgoing_call_cnt", "Last hour outgoing calls.", "" ) \
( AVAILABILITY_DETECTION_STRUCT, "availability_detection_struct", "Detailed availibility detection Statistics", "" ) \
( POLL_REMOTE_PROXY, "poll_remote_proxy", "Remote proxy polling enabled", "" ) \
( IS_AVAILABLE, "is_available", "Remote proxy actually available or not", "" ) \
( TIME_SINCE_POLLING, "time_since_polling", "Time since the last availibility polling", "" ) \
( TIME_AVAILABLE_SECONDS, "time_available_seconds", "Number of seconds since the NAP is available", "x" ) \
( TIME_UNAVAILABLE_SECONDS, "time_unavailable_seconds", "Number of seconds since the NAP is unavailable", "x" ) \
( REGISTRATION_STRUCT, "registration_struct", "Detailed registration Statistics", "" ) \
( REGISTER_TO_PROXY, "register_to_proxy", "Register to proxy enabled", "" ) \
( IS_REGISTERED, "registered", "Actually registered or not", "" ) \
( TIME_SINCE_REFRESH, "time_since_refresh", "Time since the last refresh", "" ) \
( TIME_REGISTERED_SECONDS, "time_registered_seconds", "Number of seconds since the NAP is registered", "x" ) \
( TIME_NOT_REGISTERED_SECONDS, "time_not_registered_seconds", "Number of seconds since the NAP is not registered", "x" ) \
/*!< Nap Status Fields */

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== Test parameters ==

=== @call_params ===

That variable should contain a hash of call parameters that will passed to the routing script. This is equivalent to the incoming call parameters.

 

=== @nap_list ===

A list of 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.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Text Call Detail Records

2013-11-06T19:08:24Z

Rblanchet: Added OriginalCause

Text [[call detail record|call detail records]] (CDR) can be used on the [[TMG800]], [[TMG3200]] or [[TMG7800]]. The Call Detail Records are saved in a log file on a local disk. There is an entry done for each call leg, at the start of a call and at the end of the call. In addition, the system can be configured to update the CDRs periodically.

The format of the CDR traces is defined by configuration, using variables that are replaced by the Gateway application when writing to the log.

For example, the following variable will be replaced by the called number:
@{CalledNumber}

In order to save disk space and simplify the archiving and backup of CDR log files, this log file is automatically archived (gzipped) and rotated every N seconds, as specified by the system configuration.

== Enabling text CDR ==
The enabling of Text CDR is described in [[Toolpack:Enabling CDR A|Enabling CDR]].

== Available variables ==
The following variables exist and can be used to define the CDR log format.

=== Variables used for identifying call (or call leg) in general ===
*@{StatusType}: Indicates the type of record ("Start", "Update" or "End").
*@{LegId}: Unique Id for this leg (32 bits value, but may eventually be upgraded to 64 bits value).
*@{OtherLegId}: Id of the other call leg joined with current call leg.
*@{SessionId}: Unique call identifier for two joined and answered call legs, including failed outgoing call attempts (route retry)
Formatted as 4 values of 32 bits, printed as 4 blocks of 8 hexadecimal characters separated by a space
Ex: a939d169 299ffcd0 00000000 00000000
Note: Call Transfer Target legs have separate SessionId. If you need an id to correlate a transferred call
to the original call, use @{OriginalSessionId}.
*@{OriginalSessionId}: Refers to @{SessionId} of the original legs for this call, in case of call transfer.
In fact, Transfer Target leg has a different value for @{SessionId}, but can be linked with the original call
legs through @{OriginalSessionId}.
*@{LinkId}: Same meaning as @{OriginalSessionId}, but presented as a 32 bits integer value.
For all Ids above, please see [[Text_Call_Detail_Records_(CDR)#Known_limitations|Known Limitations]] below for notes about uniqueness of these values.

=== Timestamps ===
*@{AlertTime}: Time where the call has started ringing.
Note: Supported on release 2.7 and up only.
*@{ConnectedTime}: Time where the call was answered (and connected with another leg) (in number of seconds since epoch)
*@{ConnectedTime:format}: Same as @{ConnectedTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{ConnectedTimeUtc:format}:Same as @{ConnectedTime:format} but printed in UTC time, rather than local time zone.
*@{CallDuration}: Call duration in seconds (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{CallDurationMs}: Call duration in milliseconds (end - connected time) (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{EndTime}: Time where the call has started terminating (in number of seconds since epoch).
Note that slightly differs from the @{Timestamp}, since the 'End' CDR trace is printed once the call has
finished terminating,
while @{EndTime} reports the time where the call has started terminating (upon hangup for example).
*@{EndTime:format}: Same as @{EndTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{EndTimeUtc:format}: Same as @{EndTime:format} but printed in UTC time, rather than local time zone.
*@{RingingDuration}: Ringing duration in seconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{RingingDurationMs}: Ringing duration in milliseconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{StartTime}: Time where the call was created (in number of seconds since epoch)
*@{StartTime:format}: Same as @{StartTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{StartTimeUtc:format}: Same as @{StartTime:format} but printed in UTC time, rather than local time zone.
*@{Timestamp}: Time where this CDR log entry was written.
Should not be used for billing purposes. Use @{EndTime} for billing @{EndTime} reports the time where
the call has started terminating (hangup), while *@{Timestamp} the time where signaling confirmed the termination.
*@{Timestamp:format}: Same as @{Timestamp} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{TimestampUtc:format}: Same as @{Timestamp:format} but printed in UTC time, rather than local time zone.

=== Information related to signaling ===
*@{CalledNumber}: Called number
*@{CallingNumber}: Calling number
*@{CallingPresentation}: Calling presentation: "Unspecified", "NotAvailable", "Allowed", "Restricted", "AddressRestricted" or "NameRestricted"
Note: Supported on release 2.7 and up only.
*@{CallingSubscriberNumber}: Second calling number (ISDN) or Generic number of type "additional calling party number" (SS7)
Note: Supported on release 2.7.43 and up only.
*@{CallType}: Call type ("Telephony" or "VOIP")
*@{IncomingNAP}: Name of the NAP that originated this call (incoming call leg's NAP name).
Note: Supported on release 2.7 and up only.
*@{NAP}: Name of the NAP this call leg is from
*@{OriginatorName}: Direction of the call:
- "answer" (incoming call leg) - "originate" (outgoing call leg)
Note: In release 2.6 and earlier, the direction of the call is as follows:
- "originate" (incoming call leg) - "answer" (outgoing call leg)
In release 2.7, the CDR option "Reverse CDR call origin" in Gateway configuration provide the same values as in release 2.6.
*@{OriginalCalledNumber}: Original called number
Note: Supported on release 2.7 and up only.
*@{Protocol}: Type of protocol used ("SS7", "ISDN", or "SIP")
*@{RedirectingNumber}: Redirecting number
Note: Supported on release 2.7 and up only.
*@{TerminationCause}: Cause of the call termination, printed as an integer value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationCauseString}: Cause of the call termination, printed as a string value
*@{OriginalCause}: Original cause of the call termination, printed as a string value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationSource}: Identifies the cause of the leg termination:
- "TermInd": Terminating indication has been received on this leg
- "JoinedTermInd": Terminating indication has been received on the leg joined to current leg,
and has been forwarded to current leg
- "App": Call control application has asked to drop the call
- "Engine": Toolpack engine has decided to terminate this call
(generally due to local errors like disconnected TMedia)
*@{UserName}: For SIP calls, name of the user.
*@{ChargeIndicator}: For TDM (SS7 and CAS R2); received charge indicator in Alert message.

=== Information related to media ===
*@{Codec}: Codec used for this call ("G711" for example)
*@{LocalMediaInfo}: Protocol type dependent information on the call leg (local information for SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port locally used for receiving RTP)
*@{LocalMediaIP}: For VOIP calls, RTP IP address locally used for this call leg.
*@{LocalMediaPort}: For VOIP calls, RTP UDP port locally used for this call leg.
*@{RemoteMediaInfo}: Protocol type dependent information on the call leg (remote information SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port TMedia is sending RTP to)
*@{RemoteMediaIP}: For VOIP calls, RTP IP address of the remote peer for this call leg.
*@{RemoteMediaPort}: For VOIP calls, RTP UDP port of the remote peer for this call leg.
*@{TimeslotNumber}: For TDM (Telephony) calls, timeslot number that this call was using for audio.
*@{TrunkName}: For TDM (Telephony) calls, name of the trunk that this call was using for audio.

=== Information related to routing ===
*@{ApplicationName}: Name of the application that has written this log ("Gateway")
*@{RouteAttribute:attr}: Replaced by the value of a custom route attribute, for the selected
route. This will apply only to outgoing call legs that were made from routing.
Eligible route attributes are:
Route name: Use attribute "route_name". Ex: @{RouteAttribute:route_name}
Route set name: Use attribute "routeset_name". Ex: @{RouteAttribute:routeset_name}
Custom route attribute column: Use the custom attribute name. Ex: @{RouteAttribute:priority}
Routing script parameters: Use the route attribute name provided by routing script.
Ex: If script provides: route[:my_param]="myval"
Then it's included in CDR with @{RouteAttribute:my_param}]
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.

=== Deprecated values: ===
*@{MediaInfo}: Same as @{RemoteMediaInfo}
*@{RemoteIP}: Same as @{RemoteMediaIP}
*@{RemotePort}: Same as @{RemoteMediaPort}

== CDR sample ==
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP',Protocol='SIP',Direction='answer'
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP2',Protocol='SIP',Direction='originate'
2013-02-07 10:19:07.562-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',TerminationSource='App',Calling='',Called='123',NAP='NAP_SIP2',Direction='originate'
2013-02-07 10:19:07.656-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',Termination Source='App',Calling='',Called='123',NAP='NAP_SIP',Direction='answer'

== Redundancy ==

In a [[TMG7800]] configuration, with redundant TMG-Control servers, only the active server writes the CDR logs. Since the active server may change over time, CDR parsing must take into account that CDR logs may be found in files from the two servers.

The analysis of the logs for the purpose of extracting billing information must be done after combining the two logs, from both TMG-Control servers, sorting the entries by timestamp for example. See how to [[TMG:Retrieve_Text_CDR|Retrieve Text CDR here]].

== CDR entry loss due to switchover ==
In some situations (during HA switchover for example), some CDR entries may be lost.

The following guide lines provide information on how to deal with these corner cases:

[[Call_Detail_Records_Entry_Loss|Deal with CDR entries loss]]

== Retrieving Text CDRs ==

There are 2 ways to retrieve the text CDR manually or automatically. The procedures are described in [[TMG:Retrieve_Text_CDR|Retrieve Text CDR]].

== Notes ==
*This mode of operation is not recommended for [[TMG800]] or [[TMG3200]] with a flash disk (last shipment January 2011). However, the [[TMG800]] or [[TMG3200]] with SATA or SSD disk option is OK (use command tbproduct: if the command can be executed, the disk is SATA or SSD).
*TelcoBridges does not recommend storing CDR logs via network file systems (NFS or other). We highly recommend writing to a local hard drive and have developed a background script that moves the gzipped log segments for backup or analysis.

[[category:Needs revising]]

Toolpack:RADIUS CDR attributes C

2013-11-06T19:05:24Z

Rblanchet: typo

Toolpack:RADIUS CDR attributes C

2013-11-06T19:04:39Z

Rblanchet: Original termination cause

{{DISPLAYTITLE:Toolpack:RADIUS CDR attributes}}
=== '''''Applies to version(s): v2.7''''' ===
This page contains the list of RADIUS attributes that are sent to a RADIUS accounting server.

From RFC 2865 and RFC 2866 (Accounting) :
{| cellpadding="5" border="1" class="wikitable"
|-
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Attribute ID
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | RADIUS IETF param name
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Type
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Toolpack CDR parameter
! width="610" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Description
|-
| align="center" | 1 
| User-Name
| align="center" | string 
| IncomingNAP
| Incoming NAP name
|-
| align="center" | 4 
| NAS-IP-Address
| align="center" | IP address 
| -
| IP address of the TMedia generating the CDR record
|-
| align="center" | 30 
| Called-Sation-Id
| align="center" | string 
| Called Number
| Called party number
|-
| align="center" | 31 
| Calling-Station-Id
| align="center" | string 
| Calling Number
| Calling party number
|-
| align="center" | 32 
| NAS-Identifier
| align="center" | string 
| Application Name
| Application name of the CDR provider
|-
| align="center" | 40 
| Acct-Status-Type
| align="center" | integer 
| -
| Start or Stop
|-
| align="center" | 44 
| Acct-Session-Id
| align="center" | integer 
| Leg Id
| Call Leg Identifier
|-
| align="center" | 46 
| Acct-Session-Time
| align="center" | integer 
| Session duration
| Duration of the call, in seconds. Corresponds to h323-disconnect-time minus h323-connect-time.
|}

Attribute ID 26, Vendor ID: 9 (Cisco)
{| cellpadding="5" border="1" class="wikitable"
|-
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Vendor specific attribute ID
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | RADIUS IETF param name
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Type
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Toolpack param
! width="610" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Description
|-
| align="center" | 2 
| Cisco-NAS-Port
| align="center" | string 
| NAP name
| Network Access Point name for the call leg
|-
| align="center" | 24 
| h323-conf-id
| align="center" | string 
| Unique Id
| Unique call identifier for the two initial legs (incoming and outgoing) - 128 bits integer formated as xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
|-
| align="center" | 25 
| h323-setup-time
| align="center" | string 
| Start Time
| Represent the call leg setup time - Coordinated Universal Time (UTC)
|-
| align="center" | 26 
| h323-call-origin
| align="center" | string 
| Originator Name
| "originate" for an outgoing leg - "answer" for an incoming leg
|-
| align="center" | 27 
| h323-call-type
| align="center" | string 
| Protocol Type
| If protocol is SIP the value is "VOIP", otherwise it is "Telephony"
|-
| align="center" | 28 
| h323-connect-time
| align="center" | string 
| Connected Time
| Represent the call leg answer time (connect time) - Coordinated Universal Time (UTC)
|-
| align="center" | 29 
| h323-disconnect-time
| align="center" | string 
| EndTime
| Represent the call leg disconnect time - Coordinated Universal Time (UTC)
|-
| align="center" | 30 
| h323-disconnect-cause
| align="center" | string 
| Termination Reason
| Q.931 disconnect (1 to 160) cause, TB Toolpack system cause (200 to 300) and SIP cause (400 to 600)
|-
| align="center" | 35 
| h323-incoming-conf-id
| align="center" | string 
| Unique Id
| Contains the original h323-conf-id in case of call transfer for subsequent outgoing legs - 128 bits integer formated as xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
|-
| align="center" | 115
| release-source
| align="center" | string 
| Termination Source
| "localLeg" if this leg terminate the call or "connectedLeg" if its the connected leg - We use a Cisco string field with our own value definition
|-
| align="center" | 141 
| call-id
| align="center" | String 
| SipCallId
| Content of the "call-id" SIP header
|}

Attribute ID 26, Vendor ID: 21776 (TelcoBridges)
{| cellpadding="5" border="1" class="wikitable"
|-
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Vendor specific attribute ID
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | RADIUS IETF param name
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Type
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Toolpack param
! width="610" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Description
|-
| align="center" | 9 
| Telcob-ChargeIndicator
| align="center" | String 
| ChargeIndicator
| Represent the charge indicator value
|-
| align="center" | 10 
| Telcob-Protocol
| align="center" | String 
| Protocol
| Protocol used for this LegID. Ex. SIP, ISDN, etc.
|-
| align="center" | 11 
| Telcob-Codec
| align="center" | String 
| Codec
| Codec used for this LegID
|-
| align="center" | 12 
| Telcob-RemoteMediaIP
| align="center" | IP address 
| RemoteIP
| RemoteIP used for the media. This is only for VOIP.
|-
| align="center" | 13 
| Telcob-RemoteMediaPort
| align="center" | Integer 
| RemotePort
| RTP Port of the remote peer. This is only for VOIP.
|-
| align="center" | 14 
| Telcob-TrunkName
| align="center" | String 
| TrunkName
| Name of the trunk (ex. "LS004400E1_0_00"). 
This attribute is only for non-VOIP.
|-
| align="center" | 15 
| Telcob-TimeslotNumber
| align="center" | Integer 
| TimeslotNumber
| This is the Timeslot Number. 
This attribute is only for non-VOIP.
|-
| align="center" | 16 
| Telcob-MediaInfo
| align="center" | String 
| MediaInfo
| String that represents the MediaInfo (ex. "PCMU@10.3.10.124:20054" for SIP and "LS_T1_BITS_00:1" for ISDN)
|-
| align="center" | 17 
| Telcob-StartTime
| align="center" | String 
| StartTime
| String that represents the StartTime of the call.
|-
| align="center" | 18 
| Telcob-ConnectedTime
| align="center" | String 
| ConnectedTime
| String that represents the time when the call was connected
|-
| align="center" | 19 
| Telcob-EndTime
| align="center" | String 
| EndTime
| String that represents when the call was completed.
|-
| align="center" | 20 
| Telcob-TerminationCause
| align="center" | Integer 
| TerminationCause
| Integer that represents the Termination Cause
|-
| align="center" | 21 
| Telcob-Other-Leg-Id
| align="center" | Integer 
| Other-Leg-Id
| Integer that represents the other LegID bridged for this call
|-
| align="center" | 22 
| Telcob-TerminationCauseString
| align="center" | String 
| TerminationCauseString
| String that represents the TerminationCause, but in a String format.
|-
| align="center" | 23 
| Telcob-TerminationSource
| align="center" | String 
| TerminationSource
| String that represents the Termination Source
|-
| align="center" | 24 
| Telcob-LocalSipIP*
| align="center" | IPAddr 
| LocalSipIP
| IP Address that represents the Local IP used for SIP.
|-
| align="center" | 25 
| Telcob-LocalSipPort*
| align="center" | Integer 
| LocalSipPort
| Integer that represents the Local port used for SIP.
|-
| align="center" | 26 
| Telcob-LocalMediaIP
| align="center" | IPAddr 
| LocalMediaIP
| IP Address that represents the Local IP used for the media.
|-
| align="center" | 27 
| Telcob-LocalMediaPort
| align="center" | Integer 
| LocalMediaPort
| Integer that represents the Local port used for the media.
|-
| align="center" | 28 
| Telcob-LocalMediaInfo
| align="center" | String 
| LocalMediaInfo
| String that represents the Local Media Info.(ex. "PCMU@10.3.10.124:20054")
Only for VOIP calls.
|-
| align="center" | 29 
| Telcob-RemoteMediaInfo
| align="center" | String 
| RemoteMediaInfo
| String that represents the Remote Media Info.(ex. "PCMU@10.3.10.124:20054")
This is the same as Telcob-MediaInfo. Only for VOIP calls.
|-
| align="center" | 30 
| Telcob-Alert-Time
| align="center" | String 
| AlertTime
| Time where the call has started ringing.
|-
| align="center" | 31 
| Telcob-Redirecting-Number
| align="center" | String 
| RedirectingNumber
| Redirecting number
|-
| align="center" | 32 
| Telcob-Original-Called-Number
| align="center" | String 
| OriginalCalledNumber
| Original called number
|-
| align="center" | 33 
| Telcob-Calling-Presentation
| align="center" | String 
| CallingPresentation
| Calling presentation: "Unspecified", "NotAvailable", "Allowed", "Restricted", "AddressRestricted" or "NameRestricted"
|-
| align="center" | 34 
| Telcob-CallingSubscriberNumber
| align="center" | String 
| CallingSubscriberNumber
| Second calling number (ISDN) or Generic number of type additional calling party number (SS7)
|-
| align="center" | 35 
| Telcob-OriginalCauseCause
| align="center" | String 
| OriginalCause
| String that represents the Original Termination Cause in a String format.
|}
* = Not implemented.

Toolpack:Status Menus:SS7 M3UA A

2013-09-13T15:32:25Z

Rblanchet: Updated for m3ua ha project

=== '''''Applies to version(s): v2.5, v2.6.''''' ===
{{DISPLAYTITLE:Status Menus:SS7 M3UA}}
General and detailed status information about the SS7 M3UA stack is accessible from the Sigtran M3UA tab of the Global Status window.

==General view==

In this view, general information concerning M3UA service access points (SAPs), peer server processors (PSPs), peer servers (Psrvs) and routes is displayed.
Status information for each item is given.

Detailed information can be displayed by clicking an active link.

[[Image:M3UA_general_view1.png]]

==M3UA SAP detailed view==

In this view, the following information is given:

* '''Opened:''' Yes, No.
* '''Send sap command:''' Default, Active, Inactive.
* '''Rx pdu:''' Nb of PDUs received.
* '''Tx pdu:''' Nb of PDUs transmitted.
* '''Rx byte:''' Nb of bytes received.
* '''Tx byte:''' Nb of bytes transmitted.

[[Image:SAP_m3ua_detailed_view.png]]

==M3UA PSP detailed view==

In this view, the following information is given:

* '''Asp state:''' Active, Inactive, Down.
* '''Select sap for set state:'''
* '''Set desired asp state:''' Default, Asp-up, Asp-down, Abort, Shutdown, Inhibit, Uninhibit.
* '''Association state:''' Down, Active, Closed.
* '''Asp state:''' Active, Inactive, Down state per SAP.
* '''Desired asp state:''' Default, Asp-up, Asp-down, Abort, Shutdown.
* '''Current psp inhibit state:''' Yes, No.
* '''Desired psp inhibit state:''' Yes, No.
* '''Nb active psrv:'''
* '''As active m3ua psrv list:'''
* '''Nb registered psrv:'''
* '''Rx pdu:''' Nb of PDUs received.
* '''Tx pdu:''' Nb of PDUs transmitted.
* '''Unavailable:''' Nb of times the PSP was unavailable.
* '''Congested:''' Nb of times the PSP was congested.

[[Image:PSPs_detailed_view.png]]

==M3UA Psrvs detailed view==

In this view, the following information is given:

*'''As state:''' Active, Inactive, Down.
*'''Nb registered psp:''' Nb of registered peer server process.
*'''Nb active psp:''' Nb of active peer server process.
*'''Nb psp route:''' Nb of association that can be used.
*'''Psp name:''' Peer server process name.
*'''Asp state:''' Active, Inactive, Down.
*'''Routing context:''' Routing context value.
*'''Unavailable:''' Nb of times peer server was unavailable.
*'''Unavailable duration:''' Total unavailable duration (msec).
*'''Tx data:''' Nb of DATA messages transmitted.
*'''Tx duna:''' Nb of DUNA messages transmitted.
*'''Tx dava:''' Nb of DAVA messages transmitted.
*'''Tx daud:''' Nb of DAUD messages transmitted.
*'''Tx scon:''' Nb of SCON messages transmitted.
*'''Tx dupu:''' Nb of DUPU messages transmitted.
*'''Tx drst:''' Nb of DRST messages transmitted.
*'''Rx data:''' Nb of DATA messages received.
*'''Rx duna:''' Nb of DUNA messages received.
*'''Rx dava:''' Nb of DAVA messages received.
*'''Rx daud:''' Nb of DAUD messages received.
*'''Rx scon:''' Nb of SCON messages received.
*'''Rx dupu:''' Nb of DUPU messages received.
*'''Rx drst:''' Nb of DRST messages received.

[[Image:PSRVs_detailed_view.png]]

==M3UA route detailed view==

In this view, the following information is given:

* '''Dpc specified:''' Indicates whether or not the route is specified.
* '''Paused:''' Indicates whether or not the DPC is in pause state.
* '''Congested:''' Indicates whether or not the DPC is in congestion state.

[[Image:Routes_detailed_view.png]]

Toolpack:Status Menus:SS7 M3UA A

2013-09-12T21:11:14Z

Rblanchet: Updated for m3ua ha project

=== '''''Applies to version(s): v2.5, v2.6.''''' ===
{{DISPLAYTITLE:Status Menus:SS7 M3UA}}
General and detailed status information about the SS7 M3UA stack is accessible from the Sigtran M3UA tab of the Global Status window.

==General view==

In this view, general information concerning M3UA service access points (SAPs), peer server processors (PSPs), peer servers (Psrvs) and routes is displayed.
Status information for each item is given.

Detailed information can be displayed by clicking an active link.

[[Image:M3UA_general_view1.png]]

==M3UA SAP detailed view==

In this view, the following information is given:

* '''Opened:''' Yes, No.
* '''Send sap command:''' Default, Active, Inactive.
* '''Rx pdu:''' Nb of PDUs received.
* '''Tx pdu:''' Nb of PDUs transmitted.
* '''Rx byte:''' Nb of bytes received.
* '''Tx byte:''' Nb of bytes transmitted.

[[Image:SAP_m3ua_detailed_view.png]]

==M3UA PSP detailed view==

In this view, the following information is given:

* '''Asp state:''' Active, Inactive, Down.
* '''Select sap for set state:'''
* '''Set desired asp state:''' Default, Asp-up, Asp-down, Abort, Shutdown, Inhibit, Uninhibit.
* '''Association state:''' Down, Active, Closed.
* '''Asp state:''' Active, Inactive, Down state per SAP.
* '''Desired asp state:''' Default, Asp-up, Asp-down, Abort, Shutdown.
* '''Current psp inhibit state:''' Yes, No.
* '''Desired psp inhibit state:''' Yes, No.
* '''Nb active psrv:'''
* '''As active m3ua psrv list:'''
* '''Nb registered psrv:'''
* '''Rx pdu:''' Nb of PDUs received.
* '''Tx pdu:''' Nb of PDUs transmitted.
* '''Unavailable:''' Nb of times the PSP was unavailable.
* '''Congested:''' Nb of times the PSP was congested.

[[Image:PSPs_detailed_view.png]]

==M3UA Psrvs detailed view==

In this view, the following information is given:

*'''Configured:''' Current configuration status of the peer server.
*'''As state'''
*'''States available for endpoint 0'''
*'''States available for endpoint 1'''
*'''States for endpoint 1'''
*'''States available for endpoint 2'''
*'''States available for endpoint 3'''
* '''Unavailable:''' Nb of times peer server was unavailable.
*'''Unavailable duration:''' Total unavailable duration (msec).
*'''Tx data:''' Nb of DATA messages transmitted.
*'''Tx duna:''' Nb of DUNA messages transmitted.
*'''Tx dava:''' Nb of DAVA messages transmitted.
*'''Tx daud:''' Nb of DAUD messages transmitted.
*'''Tx scon:''' Nb of SCON messages transmitted.
*'''Tx dupu:''' Nb of DUPU messages transmitted.
*'''Tx drst:''' Nb of DRST messages transmitted.
*'''Rx data:''' Nb of DATA messages received.
*'''Rx duna:''' Nb of DUNA messages received.
*'''Rx dava:''' Nb of DAVA messages received.
*'''Rx daud:''' Nb of DAUD messages received.
*'''Rx scon:''' Nb of SCON messages received.
*'''Rx dupu:''' Nb of DUPU messages received.
*'''Rx drst:''' Nb of DRST messages received.

[[Image:PSRVs_detailed_view.png]]

==M3UA route detailed view==

In this view, the following information is given:

* '''Dpc specified:''' Indicates whether or not the route is specified.
* '''Paused:''' Indicates whether or not the DPC is in pause state.
* '''Congested:''' Indicates whether or not the DPC is in congestion state.

[[Image:Routes_detailed_view.png]]

Toolpack:Status Menus:SS7 M3UA A

2013-09-12T21:10:39Z

Rblanchet: Updated with m3ua ha project

=== '''''Applies to version(s): v2.5, v2.6.''''' ===
{{DISPLAYTITLE:Status Menus:SS7 M3UA}}
General and detailed status information about the SS7 M3UA stack is accessible from the Sigtran M3UA tab of the Global Status window.

==General view==

In this view, general information concerning M3UA service access points (SAPs), peer server processors (PSPs), peer servers (Psrvs) and routes is displayed.
Status information for each item is given.

Detailed information can be displayed by clicking an active link.

[[Image:M3UA_general_view1.png]]

==M3UA SAP detailed view==

In this view, the following information is given:

* '''Opened:''' Yes-No
* '''Send sap command:''' Default-Active-Inactive.
* '''Rx pdu:''' Nb of PDUs received.
* '''Tx pdu:''' Nb of PDUs transmitted.
* '''Rx byte:''' Nb of bytes received.
* '''Tx byte:''' Nb of bytes transmitted.

[[Image:SAP_m3ua_detailed_view.png]]

==M3UA PSP detailed view==

In this view, the following information is given:

* '''Asp state:''' Active, Inactive, Down.
* '''Select sap for set state:'''
* '''Set desired asp state:''' Default, Asp-up, Asp-down, Abort, Shutdown, Inhibit, Uninhibit.
* '''Association state:''' Down, Active, Closed.
* '''Asp state:''' Active, Inactive, Down state per SAP.
* '''Desired asp state:''' Default, Asp-up, Asp-down, Abort, Shutdown.
* '''Current psp inhibit state:''' Yes, No.
* '''Desired psp inhibit state:''' Yes, No.
* '''Nb active psrv:'''
* '''As active m3ua psrv list:'''
* '''Nb registered psrv:'''
* '''Rx pdu:''' Nb of PDUs received.
* '''Tx pdu:''' Nb of PDUs transmitted.
* '''Unavailable:''' Nb of times the PSP was unavailable.
* '''Congested:''' Nb of times the PSP was congested.

[[Image:PSPs_detailed_view.png]]

==M3UA Psrvs detailed view==

In this view, the following information is given:

*'''Configured:''' Current configuration status of the peer server.
*'''As state'''
*'''States available for endpoint 0'''
*'''States available for endpoint 1'''
*'''States for endpoint 1'''
*'''States available for endpoint 2'''
*'''States available for endpoint 3'''
* '''Unavailable:''' Nb of times peer server was unavailable.
*'''Unavailable duration:''' Total unavailable duration (msec).
*'''Tx data:''' Nb of DATA messages transmitted.
*'''Tx duna:''' Nb of DUNA messages transmitted.
*'''Tx dava:''' Nb of DAVA messages transmitted.
*'''Tx daud:''' Nb of DAUD messages transmitted.
*'''Tx scon:''' Nb of SCON messages transmitted.
*'''Tx dupu:''' Nb of DUPU messages transmitted.
*'''Tx drst:''' Nb of DRST messages transmitted.
*'''Rx data:''' Nb of DATA messages received.
*'''Rx duna:''' Nb of DUNA messages received.
*'''Rx dava:''' Nb of DAVA messages received.
*'''Rx daud:''' Nb of DAUD messages received.
*'''Rx scon:''' Nb of SCON messages received.
*'''Rx dupu:''' Nb of DUPU messages received.
*'''Rx drst:''' Nb of DRST messages received.

[[Image:PSRVs_detailed_view.png]]

==M3UA route detailed view==

In this view, the following information is given:

* '''Dpc specified:''' Indicates whether or not the route is specified.
* '''Paused:''' Indicates whether or not the DPC is in pause state.
* '''Congested:''' Indicates whether or not the DPC is in congestion state.

[[Image:Routes_detailed_view.png]]

File:PSRVs detailed view.png

2013-09-12T20:54:59Z

Rblanchet: uploaded a new version of "File:PSRVs detailed view.png": Updated for the new m3ua psrv view

File:PSPs detailed view.png

2013-09-12T20:52:38Z

Rblanchet: uploaded a new version of "File:PSPs detailed view.png": Update with the new m3ua psp view

File:SAP m3ua detailed view.png

2013-09-12T20:50:59Z

Rblanchet: M3UA SAP detailed view

M3UA SAP detailed view

Toolpack:Status Menus:SS7 M3UA A

2013-09-12T20:50:26Z

Rblanchet: /* M3UA SAP detailed view */

=== '''''Applies to version(s): v2.5, v2.6.''''' ===
{{DISPLAYTITLE:Status Menus:SS7 M3UA}}
General and detailed status information about the SS7 M3UA stack is accessible from the Sigtran M3UA tab of the Global Status window.

==General view==

In this view, general information concerning M3UA service access points (SAPs), peer server processors (PSPs), peer servers (Psrvs) and routes is displayed.
Status information for each item is given.

Detailed information can be displayed by clicking an active link.

[[Image:M3UA_general_view1.png]]

==M3UA SAP detailed view==

In this view, the following information is given:

* '''Opened:''' Yes-No
* '''Send sap command:''' Default-Active-Inactive.
* '''Rx pdu:''' Nb of PDUs received.
* '''Tx pdu:''' Nb of PDUs transmitted.
* '''Rx byte:''' Nb of bytes received.
* '''Tx byte:''' Nb of bytes transmitted.

[[Image:SAP_m3ua_detailed_view.png]]

==M3UA PSP detailed view==

In this view, the following information is given:

* '''Sap configured:''' Current configuration status of the SAP.
* '''Opened'''
* '''Rx pdu:''' Nb of PDUs received.
* '''Tx pdu:''' Nb of PDUs transmitted.
* '''Rx byte:''' Nb of bytes received.
* '''Tx byte:''' Nb of bytes transmitted.

[[Image:PSPs_detailed_view.png]]

==M3UA Psrvs detailed view==

In this view, the following information is given:

*'''Configured:''' Current configuration status of the peer server.
*'''As state'''
*'''States available for endpoint 0'''
*'''States available for endpoint 1'''
*'''States for endpoint 1'''
*'''States available for endpoint 2'''
*'''States available for endpoint 3'''
* '''Unavailable:''' Nb of times peer server was unavailable.
*'''Unavailable duration:''' Total unavailable duration (msec).
*'''Tx data:''' Nb of DATA messages transmitted.
*'''Tx duna:''' Nb of DUNA messages transmitted.
*'''Tx dava:''' Nb of DAVA messages transmitted.
*'''Tx daud:''' Nb of DAUD messages transmitted.
*'''Tx scon:''' Nb of SCON messages transmitted.
*'''Tx dupu:''' Nb of DUPU messages transmitted.
*'''Tx drst:''' Nb of DRST messages transmitted.
*'''Rx data:''' Nb of DATA messages received.
*'''Rx duna:''' Nb of DUNA messages received.
*'''Rx dava:''' Nb of DAVA messages received.
*'''Rx daud:''' Nb of DAUD messages received.
*'''Rx scon:''' Nb of SCON messages received.
*'''Rx dupu:''' Nb of DUPU messages received.
*'''Rx drst:''' Nb of DRST messages received.

[[Image:PSRVs_detailed_view.png]]

==M3UA route detailed view==

In this view, the following information is given:

* '''Dpc specified:''' Indicates whether or not the route is specified.
* '''Paused:''' Indicates whether or not the DPC is in pause state.
* '''Congested:''' Indicates whether or not the DPC is in congestion state.

[[Image:Routes_detailed_view.png]]

File:SAP detailed view.png

2013-09-12T20:32:51Z

Rblanchet: uploaded a new version of "File:SAP detailed view.png": Reverted to version as of 23:00, 25 August 2011, forked the file for m3ua

File:SAP detailed view.png

2013-09-12T20:29:09Z

Rblanchet: uploaded a new version of "File:SAP detailed view.png": Updated with the new sap command field

Toolpack:Status Menus:SS7 M3UA A

2013-09-12T20:21:17Z

Rblanchet: /* General view */

=== '''''Applies to version(s): v2.5, v2.6.''''' ===
{{DISPLAYTITLE:Status Menus:SS7 M3UA}}
General and detailed status information about the SS7 M3UA stack is accessible from the Sigtran M3UA tab of the Global Status window.

==General view==

In this view, general information concerning M3UA service access points (SAPs), peer server processors (PSPs), peer servers (Psrvs) and routes is displayed.
Status information for each item is given.

Detailed information can be displayed by clicking an active link.

[[Image:M3UA_general_view1.png]]

==M3UA SAP detailed view==

In this view, the following information is given:

* '''Sap configured:''' Current configuration status of the SAP.
* '''Opened'''
* '''Rx pdu:''' Nb of PDUs received.
* '''Tx pdu:''' Nb of PDUs transmitted.
* '''Rx byte:''' Nb of bytes received.
* '''Tx byte:''' Nb of bytes transmitted.

[[Image:SAP_detailed_view.png]]

==M3UA PSP detailed view==

In this view, the following information is given:

* '''Sap configured:''' Current configuration status of the SAP.
* '''Opened'''
* '''Rx pdu:''' Nb of PDUs received.
* '''Tx pdu:''' Nb of PDUs transmitted.
* '''Rx byte:''' Nb of bytes received.
* '''Tx byte:''' Nb of bytes transmitted.

[[Image:PSPs_detailed_view.png]]

==M3UA Psrvs detailed view==

In this view, the following information is given:

*'''Configured:''' Current configuration status of the peer server.
*'''As state'''
*'''States available for endpoint 0'''
*'''States available for endpoint 1'''
*'''States for endpoint 1'''
*'''States available for endpoint 2'''
*'''States available for endpoint 3'''
* '''Unavailable:''' Nb of times peer server was unavailable.
*'''Unavailable duration:''' Total unavailable duration (msec).
*'''Tx data:''' Nb of DATA messages transmitted.
*'''Tx duna:''' Nb of DUNA messages transmitted.
*'''Tx dava:''' Nb of DAVA messages transmitted.
*'''Tx daud:''' Nb of DAUD messages transmitted.
*'''Tx scon:''' Nb of SCON messages transmitted.
*'''Tx dupu:''' Nb of DUPU messages transmitted.
*'''Tx drst:''' Nb of DRST messages transmitted.
*'''Rx data:''' Nb of DATA messages received.
*'''Rx duna:''' Nb of DUNA messages received.
*'''Rx dava:''' Nb of DAVA messages received.
*'''Rx daud:''' Nb of DAUD messages received.
*'''Rx scon:''' Nb of SCON messages received.
*'''Rx dupu:''' Nb of DUPU messages received.
*'''Rx drst:''' Nb of DRST messages received.

[[Image:PSRVs_detailed_view.png]]

==M3UA route detailed view==

In this view, the following information is given:

* '''Dpc specified:''' Indicates whether or not the route is specified.
* '''Paused:''' Indicates whether or not the DPC is in pause state.
* '''Congested:''' Indicates whether or not the DPC is in congestion state.

[[Image:Routes_detailed_view.png]]

File:M3UA general view1.png

2013-09-12T20:18:48Z

Rblanchet: uploaded a new version of "File:M3UA general view1.png": Wrong file complete m3ua status

File:M3UA general view1.png

2013-09-12T20:15:41Z

Rblanchet: uploaded a new version of "File:M3UA general view1.png": Show an up to date example

Parameter: CIC Mapping

2013-09-11T20:59:13Z

Rblanchet: Right align the array

The CIC Mapping parameter is used to link the CIC number with the timeslot. The CIC Mapping parameter can take on the following values:

* Linear
* JTISUP

{| class="wikitable" style="text-align:right;"
|-
! Timeslot !! Linear !! E1 JTISUP !! T1 JTISUP
|-
! !! CIC !! CIC !! CIC
|-
| 1|| 0|| 0|| 0
|-
| 2|| 1|| 6|| 6
|-
| 3|| 2|| 12|| 12
|-
| 4|| 3|| 18|| 18
|-
| 5|| 4|| 24|| 1
|-
| 6|| 5|| 1|| 7
|-
| 7|| 6|| 7|| 13
|-
| 8|| 7|| 13|| 19
|-
| 9|| 8|| 19|| 2
|-
| 10|| 9|| 25|| 8
|-
| 11|| 10|| 2|| 14
|-
| 12|| 11|| 8|| 20
|-
| 13|| 12|| 14|| 3
|-
| 14|| 13|| 20|| 9
|-
| 15|| 14|| 26|| 15
|-
| 16|| 15|| '''Not Used'''|| 21
|-
| 17|| 16|| 3|| 4
|-
| 18|| 17|| 9|| 10
|-
| 19|| 18|| 15|| 16
|-
| 20|| 19|| 21|| 22
|-
| 21|| 20|| 27|| 5
|-
| 22|| 21|| 4|| 11
|-
| 23|| 22|| 10|| 17
|-
| 24|| 23|| 16|| 23
|-
| 25|| 24|| 22|| NA
|-
| 26|| 25|| 28|| NA
|-
| 27|| 26|| 5|| NA
|-
| 28|| 27|| 11|| NA
|-
| 29|| 28|| 17|| NA
|-
| 30|| 29|| 23|| NA
|-
| 31|| 30|| 29|| NA
|}

[[Category:Parameters]]

Parameter: CIC Mapping

2013-09-11T20:48:19Z

Rblanchet: Table for JTISUP assignation

The CIC Mapping parameter is used to link the CIC number with the timeslot. The CIC Mapping parameter can take on the following values:

* Linear
* JTISUP

{| class="wikitable"
|-
! Timeslot !! Linear !! E1 JTISUP !! T1 JTISUP
|-
! !! CIC !! CIC !! CIC
|-
| 1|| 0|| 0|| 0
|-
| 2|| 1|| 6|| 6
|-
| 3|| 2|| 12|| 12
|-
| 4|| 3|| 18|| 18
|-
| 5|| 4|| 24|| 1
|-
| 6|| 5|| 1|| 7
|-
| 7|| 6|| 7|| 13
|-
| 8|| 7|| 13|| 19
|-
| 9|| 8|| 19|| 2
|-
| 10|| 9|| 25|| 8
|-
| 11|| 10|| 2|| 14
|-
| 12|| 11|| 8|| 20
|-
| 13|| 12|| 14|| 3
|-
| 14|| 13|| 20|| 9
|-
| 15|| 14|| 26|| 15
|-
| 16|| 15|| Not Used|| 21
|-
| 17|| 16|| 3|| 4
|-
| 18|| 17|| 9|| 10
|-
| 19|| 18|| 15|| 16
|-
| 20|| 19|| 21|| 22
|-
| 21|| 20|| 27|| 5
|-
| 22|| 21|| 4|| 11
|-
| 23|| 22|| 10|| 17
|-
| 24|| 23|| 16|| 23
|-
| 25|| 24|| 22|| NA
|-
| 26|| 25|| 28|| NA
|-
| 27|| 26|| 5|| NA
|-
| 28|| 27|| 11|| NA
|-
| 29|| 28|| 17|| NA
|-
| 30|| 29|| 23|| NA
|-
| 31|| 30|| 29|| NA
|}

[[Category:Parameters]]

Toolpack:Creating ISUP CIC Groups A

2013-09-11T20:27:51Z

Rblanchet: Added CIC mapping parameter

=== '''''Applies to version(s): v2.5, v2.6., v2.7''''' ===
{{DISPLAYTITLE:Creating ISUP CIC Groups}}
Now that you have created an ISUP interface, you must create a new ISUP cicuit identification code (CIC) group for your system.

A CIC represents a physical timeslot between two SS7 nodes. Both of those nodes must commonly agree upon a CIC numbering scheme.

To create an ISUP CIC group:

1- Click '''Create New Isup Cic Group''' in the ISUP interface configuration window (a number of groups can be created at once by clicking '''Create Multiple New Isup Cic Group''')

[[Image:Toolpack_v2.5_Create_ISUP_CIC_Group.png]]

2- Configure the new ISUP CIC group:

* Enter a '''name''' for the group
* Enter a number for the '''first CIC''' in the group (this value must follow other CIC group values, and not overlap)
* Select a '''line service'''
* Check the appropriate '''timeslots''' (click "Select all" to check all timeslots)
* Select a '''CIC mapping'''
* Select a '''call control method'''
* Click '''Create'''

[[Image:Toolpack_v2.5_Creating_ISUP_CIC_Group.png]]

3- Verify that the '''"IsupCicGroup was successfully created"''' message appears

[[Image:Toolpack_v2.5_ISUP_CIC_Group_Created.png]]

==List of Parameters==

* [[Parameter: Name|Name]]
* [[Parameter: First CIC|First CIC]]
* [[Parameter: Line Service|Line Service]]
* [[Parameter: Timeslots|Timeslots]]
* [[Parameter: CIC Mapping|CIC Mapping]]
* [[Parameter: Call Control|Call Control]]

Parameter: CIC Mapping

2013-09-11T20:27:12Z

Rblanchet: Basic info

The CIC Mapping parameter is used to link the CIC number with the timeslot. The CIC Mapping parameter can take on the following values:

* Linear
* JTISUP

[[Category:Parameters]]

Parameter: Traffic Mode Type

2013-09-11T19:37:49Z

Rblanchet: traffic mode only for m3ua psrv

The M3UA Traffic Mode Type parameter is used when activating a peer server. This field is inserted in the ASP Active (ASPAC) and ASP Inactive (ASPIA) messages.

For '''signaling gateway (SG)''', this parameter needs to correspond with the value received in ASPAC and ASPIA messages.

For '''application server (ASP)''' and '''IP signaling gateway (IPSP)''', the traffic mode type value from the local peer server and from the remote peer server are applied to the list of association.

4 Modes are available based on the configuration of a single routing context:

1- Local active standby - Remote load sharing
All PSPs need to be active on only one SAP. (all associations on one SAP are active)

2- Local active standby - Remote active standby
Only one PSP needs to be active on one SAP. (1 association is active)

3- Local load sharing - Remote load sharing
Every SAPs and PSPs need to be active. (all associations are active)

4- Local load sharing - Remote active standby
Only one PSP needs to be active for all SAPs. (all associations on one PSP are active)

[[Category:Parameters]]

Parameter: Traffic Mode Type

2013-09-11T19:32:59Z

Rblanchet: Explain m3ua state machine based on traffic mode type

The Traffic Mode Type parameter is used when activating a peer server. This field is inserted in the ASP Active (ASPAC) and ASP Inactive (ASPIA) messages.

For signaling gateway (SG), this parameter needs to correspond with the value received in ASPAC and ASPIA messages.

For application server (ASP) or IP signaling gateway (IPSP), the traffic mode type value from the local peer server and from the remote peer server are applied to the list of association.

4 Modes are available:

1- Local active standby - Remote load sharing
All PSPs need to be active on only one SAP. (all associations on one SAP are active)

2- Local active standby - Remote active standby
Only one PSP needs to be active on one SAP. (1 association is active)

3- Local load sharing - Remote load sharing
Every SAPs and PSPs need to be active. (all associations are active)

4- Local load sharing - Remote active standby
Only one PSP needs to be active for all SAPs. (all associations on one PSP are active)

[[Category:Parameters]]

Parameter: Traffic Mode Type

2013-09-11T19:14:01Z

Rblanchet: Basic info

The Traffic Mode Type parameter is used when activating a peer server. This field is inserted in the ASPAC and ASPIA messages.

[[Category:Parameters]]

Toolpack:Creating an M3UA Peer Server A

2013-09-11T19:12:03Z

Rblanchet: Updated for traffic mode type parameter

=== '''''Applies to version(s): v2.5, v2.6., v2.7''''' ===
{{DISPLAYTITLE:Creating an M3UA Peer Server}}
Now that you have create an M3UA peer signaling process (PSP), you must create a new Peer server.
A peer server is a logical entity on the IP network that is served by one or more PSPs.

To create an M3UA peer server:

1- Click '''Create New M3ua Peer Server''' in the M3UA network configuration window

[[Image:Toolpack_v2.5_Create_M3UA_Peer_Server.png]]

2- Configure the new M3UA peer server:

* Enter a '''name''' for the peer server
* Check the '''Local''' box for '''local peer server ([[OPC]])'''. For '''remote peer server ([[DPC]])''', do not check this box. ('''For signaling gateway, this option does not appear, SG uses only remote peer servers''')
* Enter a value for the '''routing context''' (must be unique within a local or non-local server list. However, this value does not need to be unique across lists).
* Select the '''Traffic Mode Type'''. For local peer server, it indicates if one association (active-standby) or several associations (loadshare) are brought to the active state. For remote peer server, this field is used in '''ASPAC'''.
* Click '''Create'''

[[Image:Toolpack_v2.5_Creating_M3UA_Peer_Server.png]]

3- Verify that the '''"M3ua Peer server was successfully created"''' message appears

[[Image:Toolpack_v2.5_M3UA_Peer_Server_Created.png]]

4- Associate the newly created peer server with a peer signaling process (PSP):

* Select a '''PSP''' from the list of available PSPs
* Click the '''"<<"''' button to associate the PSP with the peer server

[[Image:Toolpack_v2.5_M3UA_Peer_Server_PSP.png]]

==List of Parameters==

* [[Parameter: Name|Name]]
* [[Parameter: Local|Local]]
* [[Parameter: Routing Context|Routing Context]]
* [[Parameter: Traffic Mode Type|Traffic Mode Type]]

File:Toolpack v2.5 Creating M3UA Peer Server.png

2013-09-11T18:57:15Z

Rblanchet: uploaded a new version of "File:Toolpack v2.5 Creating M3UA Peer Server.png": Updated to show Traffic Mode Type field

Routing script tutorial:Mini Development Guide

2013-05-22T15:55:46Z

Rblanchet: Added redirecting indicator enumeration values

Routing script tutorial:Mini Development Guide

2013-05-22T15:51:19Z

Rblanchet: Added redirecting indicator

N+1

2013-03-08T21:16:34Z

Rblanchet: APS signal

The N+1 solution will allow the customer to achieve five 9 up time. The goal is to protect a TMG7800 system against an hardware failure. This solution will maintain the exceptional TMG7800-STM1 performance at 2016 channels per unit.
The system can contain up to 15 active TMG7800-STM1 and 1 stand-by TMG7800-STM1.

[[Image:np1_diagram.jpg|Schematic showing N+1 system]]

The stand-by unit being a hot stand-by, the system will allow the switchover without any human intervention. The N+1 solution will identify the unit to be replaced and reroute automatically the traffic to the stand-by unit through the Active Patch Panel.

When the N+1 Patch Panel is not powered, the STM1 signal is still going through passively. All 15 TMG7800-STM1 can still be used.

A second N+1 Patch Panel can be used in the system to protect the STM1 APS signal.

N+1

2013-03-08T21:13:03Z

Rblanchet: creation

File:Np1 diagram.jpg

2013-03-08T20:54:10Z

Rblanchet: uploaded a new version of "File:Np1 diagram.jpg"