Actions

AllynSandbox: Difference between revisions
No edit summary
 
(32 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{DISPLAYTITLE:800 Series Gateway Standalone and 1+1}}
__NOTOC__
<big>'''Installation Guide'''</big>
==Original Table code==
=About this Guide=
----
This guide provides installation, and setup procedures for 800 series standalone and 800 series 1+1 systems.
<br><br>
==Conventions==
----


{| class="wikitable sortable"
{|class="wikitable sortable" cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|+ Product Term Usage
|-
|-
! Terminology !! Description
! scope="col" | '''Script parameter name'''
! scope="col" | '''_____ISDN_____<br>'''
! scope="col" | '''__R2_CAS__'''<br>
! scope="col" | '''______________SS7___________<br>'''
! scope="col" | '''_____________SIP_____________<br>'''
! scope="col" | '''Comment<br>'''
! scope="col" | '''Toolpack version<br>'''
|-
|-
| 800 series gateway || This term is used when a description applies to both the 800 series standalone and
| leg_id<br>
800 series 1+1 system.
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Leg ID<br>
| <br>
|-
|-
| 800 series standalone|| This term is used when a description applies to the 800 series unit operating as a
| session_id<br>
standalone unit.
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Session ID<br>
| <br>
|-
|-
| 800 series 1+1 System|| This term is used when a description applies to the 800 series unit operating in
| original_session_id<br>
conjunction with the 800+1 series unit. This term also includes the 1+1 patch panel.
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Original Session ID (before call transfer or redirections)<br>
| <br>
|-
|-
| 800 series unit || This term is used when a description applies to all variations of the 800 series units,
| calling<br>
such as: TMG800, TSG800, and TMGIP800.
| Q931: 'Calling party number' IE - Number digits <br>
| ANI (Group B)<br>
| Q763: 'Calling party number' IE - address signals (*)<br>
| SIP:From - user-info<br>
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead.<br>
| <br>
|-
|-
| 800 series +1 unit || This term is used when a description applies to all variations of the 800 series +1
| calling_sip_host <br>
units, such as TMG800 +1, TSG800 +1, or TMGIP800 +1.
| N/A<br>
| N/A<br>
| N/A<br>
| SIP:From - host (domain or IP) <br>
|  For example : The 'telcobridges.com' in From: "Cullen Jennings" <sip:fluffy@telcobridges.com> <br>
| <br>
|-
|-
| 1+1 Patch Panel|| This term is used as a generic reference to a 1+1 patch panel, which enables an 800
| calling_sip_port <br>
series unit to connect to an 800 series +1 unit.
| N/A<br>
|}
| N/A<br>
 
| N/A<br>
To help guide you in the installation of your product, we use the following icons in this document. Take note of the icon
| SIP:From - port <br>
that represents the type of installation you are conducting and follow those procedures throughout this guide to
|  For example : The '6060' in From: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060> <br>
ensure proper equipment installation and set up.
| <br>
 
 
{| class="wikitable"
|+ Documentation Icons
|-
|-
! Graphic !! Description
| calling_noa<br>
| Q931: 'Calling party number' IE - Type of number<br>
| N/A<br>
| Q763: 'Calling party number' IE - nature of address indicator (*)<br>
| N/A<br>
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead<br>
| <br>
|-
|-
| [[Image: icon_StandAlone.svg|100px]] || This icon appears in the margins of pages describing the 800 series operating as a
| calling_npi <br>
standalone unit. If you are installing a standalone unit, read and follow the
| Q931: 'Calling party number' IE - Numbering plan identification<br>
instructions provided in those sections.
| N/A<br>
| Q763: 'Calling party number' IE - numbering plan indicator (*)<br>
| N/A<br>
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used&nbsp;(when present) instead<br>
| <br>
|-
|-
| [[Image: icon_1+1.svg|100px]]|| This icon appears in the margins of pages describing the 800 series unit operating in
| calling_display <br>  
conjunction with an 800 series +1 and 1+1 patch panel. If you are installing a 1+1
| Q931: 'Display' IE - Display information<br>  
system read and follow the instructions provided in those sections and pages.
Q931: 'Facility CNAM' IE when presentation is allowed for DMS/NI2 variants<br>
|}
| N/A<br>  
<br><br>
| Q763
==Contact Us==
ITU97: 'Display information' IE - display information
----
ANSI95: 'Generic name' IE - display information
If you have comments about this guide or any other TelcoBridges technical documentation, please send an email to [mailto:marketing@telcobridges.com marketing].
| SIP:From - display-name<br>  
 
| <br>
=Introduction=
| <br>
----
[[File:Icon_StandAlone_1+1.svg|75px|right]]
This section provides an introduction of the installation and setup for the following
system configurations:
*'''800 Series Standalone''': Single gateway unit operating in standalone mode.
*'''800 series 1+1 system''': 800 series unit operating in conjunction with an 800 series +1 unit and 1+1 patch panel(s).
 
 
The following topics are covered:
*Recognizing an 800 Series Standalone versus an 800 Series 1+1 System
*Installation Prerequisites
*Preventing Electrostatic Discharge Damage
*Recommended Reading
<br><br>
==Recognizing an 800 Series Standalone versus an 800 Series 1+1 System==
----
 
[[File:Icon_StandAlone_1+1.svg|75px|right]]
<br><br>
===800 Series Standalone===
----
The 800 series standalone consists of one telecom unit.
<br><br>
===800 Series 1+1 System===
----
The 800 series 1+1 system consists of:
*One telecom unit
*One +1 telecom unit
*One or two 1+1 patch panels
[[File:ALL UNITS_Proffess_2.png]]
 
'''Equipment Front and Rear Views'''
 
<br><br>
 
==Installation Prerequisites==
----
[[File:Icon_StandAlone_1+1.svg|75px|left]]
For the installation to proceed without interruption, it is important that you have all necessary materials on hand.
{| class="wikitable"
|-
|-
! '''800 Series Standalone'''
| calling_display_type<br>
! '''800 Series 1+1 System'''
| Q931: 'Display' IE - Display information (present and/or first byte)<br>
| N/A<br>
| Q763: 'Display information' IE - present or not<br>
| N/A<br>
| <br>
| <br>
|-
|-
| '''Adequate space for the installation of the 800 series standalone.'''  
| calling_presentation <br>
You will need to mount the 800 series unit on a 19" equipment rack (customer provided). Your 800 series unit is a 1U unit.
| Q931: 'Calling party number' IE - Presentation indicator<br>
| N/A<br>
| Q763: 'Calling party number' IE - address presentation restricted indicator<br>
|
SIP:From - display-name (displays 'anonymous' or not)  


SIP:Remote-party-id - privacy<br>


 
| <br>
 
| <br>
 
| '''Adequate space for the installation of the 800 series 1+1 system.'''
You will need to mount the 800 series unit on a 19" equipment rack (customer provided). Your 800 series unit is a 1U unit.
 
The 1+1 System requires space for the following number of units:
 
800 Series Unit:    1U
800 Series +1 Unit: 1U
1+1 Patch Panel(s): 1U/2U
Total:              3U/4U
|-
|-
| '''Adequate power supply and power connections.'''
| calling_screening<br>
The 800 series unit requires two power connections. To guarantee an uninterrupted supply of electricity, each power connection must be fed by a dedicated power source.
| Q931: 'Calling party number' IE - Screening indicator<br>
| '''Adequate power supply and power connections.'''
| N/A<br>
The 800 series and 800 series +1 units require two power connections each. To guarantee an uninterrupted supply of electricity, each power
| Q763: 'Calling party number' IE - screening<br>
connection must be fed by a dedicated power source.
| SIP:Remote-party-id - screen<br>
| <br>
| <br>
|-
|-
| '''IP addresses for the management ports.'''
| calling_category<br>
To avoid delays, you should have the IP address, netmask and gateway addresses on hand. Take note that the management port supports DHCP, see [[AllynSandbox#Connecting_to_the_800_Series_Gateway_Management_Interface|Connecting to the 800 Series Gateway Management Interface]], for further information.
| N/A<br>
| '''IP addresses for the management ports.'''
| Call party category (Group A)<br>
To avoid delays, you should have the IP address, netmask and gateway addresses on hand. Take note that the management port supports DHCP, see [[AllynSandbox#Connecting_to_the_800_Series_Gateway_Management_Interface|Connecting to the 800 Series Gateway Management Interface]], for further information.
| Q763: 'Calling party's category' IE - calling party's category<br>
|}
|  
<br><br>
SIP:From - cpc


==Preventing Electrostatic Discharge Damage==
SIP:P-asserted-identity - cpc<br>
----
[[File:Icon_StandAlone_1+1.svg|75px|right]]
Electrostatic discharge (ESD) can damage equipment and impair electrical circuitry. This may occur if electronic printed circuit cards are improperly handled and may cause complete or intermittent failure.


----
| <br>
{|
| <br>
|-
|-
| [[File:WarningIcon.png]]
| calling_subscriber
(Generic Number / NDS)<br>
| Q931: 2nd 'Calling party number' IE - Number digits <br>
| N/A<br>
| Q763: Generic number IE with type 'additional calling party number' - Number digits<br>
|
SIP:P-asserted-identity - userinfo


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


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


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


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


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


SIP:Remote-party-id - display-name<br>


|Always follow ESD prevention procedures when removing and replacing modules:
| <br>
* Ensure that the equipment is grounded.
| <br>
* Wear an ESD-preventive wrist strap and ensure that it makes good contact with your skin. Connect the wrist strap clip to an unpainted surface of the equipment or the grounded equipment rack in order to channel away all ESD voltage safely to ground. To guard against ESD damage and shocks, the wrist strap and cord must be in proper working condition.
|-
* If no wrist strap is available, and you must work with the equipment, ground yourself by touching a metal part of the chassis.
| private_display_type <br>
|}
| N/A<br>
----
| N/A<br>
<br><br>
| N/A<br>
==Recommended Reading==
| N/A<br>
----
| Indicate presence or not of the private calling information<br>
This document is written with the assumption that you have a clear understanding of the installation of the equipment described in this document and you are trained to work with the equipment. If you have any technical questions, TelcoBridges TB Support can be reached at the following numbers, or an email can be sent to: [mailto:support@telcobridges.com support].
| <br>
|-
| private_address<br>
| N/A<br>
| N/A<br>  
| N/A<br>  
|
SIP:P-asserted-identity - userinfo


SIP:Remote-party-id - user-info<br>


*Americas & Europe Technical Support Centre (GMT-05:00, Montreal): Telephone: +1-450-655-8993 x131 or x102
| For example : The 'fluffy' in P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> <br>
*Asia Technical Support Centre (GMT +08:00, Hong Kong): Telephone: +852-3749-9818
| <br>
*24/7 International Support: Telephone: +1-866-438-4703
|-
<br><br>
| private_address_sip_host <br>
=Installing the Equipment=
| N/A<br>
----
| N/A<br>  
[[File:Icon_StandAlone_1+1.svg|75px|right]]
| N/A<br>  
This section provides information about the following topics:
|
*[[AllynSandbox#Package Contents|Package Contents]]
SIP:P-asserted-identity - host (domain or IP)
*[[AllynSandbox#Rack_Mounting_the_800_Series_Standalone_or_the_800_Series_1+1_System|Rack Mounting the 800 Series Standalone or the 800 Series 1+1 System]]
*[[AllynSandbox#Choosing your Connection Procedures|Choosing your Connection Procedures]]
*[[AllynSandbox#800 Series Standalone|800 Series Standalone]]
*[[AllynSandbox#800 Series 1+1 System|800 Series 1+1 System]]
*[[AllynSandbox#Adding an 800 +1 Unit to an Existing Standalone; Creating an 800 series 1+1 System|Adding an 800 +1 Unit to an Existing Standalone; Creating an 800 series 1+1 System]]
*[[AllynSandbox#Verifying the LED Status Indications|Verifying the LED Status Indications]]
*[[AllynSandbox#Powering Down|Powering Down]]
<br><br>
==Package Contents==
----
Depending on your system requirements, you may receive one or more of the following items:
*800 Series Standalone Package
*800 Series 1+1 System Package


SIP:Remote-party-id - host (domain or IP) <br>


The contents of these packages are described in the following sections.
| For example : The 'telcobridges.com' in P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> <br>
<br><br>
| <br>
===800 Series Standalone Package Contents===
|-
----
| private_address_sip_port <br>  
'''TMG800, TSG800, TMGIP800'''
| N/A<br>
| N/A<br>
| N/A<br>
|
SIP:P-asserted-identity - port


In the box, you will find the following items:
SIP:Remote-party-id - port<br>
*One 800 series unit:
**TMG800, TSG800, or TMGIP800
*One set of mounting brackets and screws, used to mount the 800 series unit to a 19" rack.
*One Tmedia serial adapter to interface the serial port of your computer with the RJ-45 port of the 800 series unit.
*Three CAT5 Ethernet straight cables (male-male), 3 meters in length.
*One Important Notice (two-sided document containing pertinent product serial numbers, and other important information).
*One Product Warranty.
*One packing slip.
*For AC powered units: Two AC power cables


Not included
| For example : The '6060' in P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060> <br>
• A 19” equipment rack. The 800 series unit must be installed on a 19” wide equipment rack.
| <br>
<br><br>
|-
| supp_private_address_forward_enabled <br>
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Overwrite default supplementary/second P-Asserted-Identity header forwarding behavior from incoming to outgoing leg <br>
| <br>
|-
| supp_private_address<br>
| N/A<br>
| N/A<br>  
| N/A<br>  
|
SIP:P-Asserted-Identity - userinfo


===800 Series 1+1 System Package Contents===
| For example : The 'fluffy' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> <br>
----
| <br>
[[File:Icon_1+1.svg|60px|right]]
|-
'''TMG800, TSG800, TMGIP800'''
| supp_private_address_display_name<br>
In the box, you will find the following items:
| N/A<br>
*One 800 series unit:
| N/A<br>
**TMG800, TSG800, or TMGIP800
| N/A<br>
*One set of mounting brackets and screws, used to mount the 800 series unit to a 19" rack.
|
*One Tmedia serial adapter, to interface the serial port of your computer with the RJ-45 port of the 800 series unit.
SIP:P-Asserted-Identity - display name
*Three CAT5 Ethernet straight cables (male-male), 3 meters in length.
*One Important Notice (two-sided document containing pertinent product serial numbers, and other important information).
*One Product Warranty.
*One packing slip.
*For AC powered units: Two AC power cables


| For example : The 'Cullen Jennings' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> <br>
| <br>
|-
| supp_private_address_sip_host <br>
| N/A<br>
| N/A<br>
| N/A<br>
|
SIP:P-Asserted-Identity - host (domain or IP)


Not included
| For example : The 'telcobridges.com' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> <br>
*A 19" equipment rack. The 800 series unit must be installed in a standard 19" wide equipment rack.
| <br>
|-
| supp_private_address_sip_port <br>
| N/A<br>
| N/A<br>
| N/A<br>
|
SIP:P-Asserted-Identity - port


| For example : The '6060' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060> <br>
| <br>
|-
| preferred_id_forward_enabled <br>
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Overwrite default P-Preferred-Identity header forwarding behavior from incoming to outgoing leg <br>
| <br>
|-
| preferred_id<br>
| N/A<br>
| N/A<br>
| N/A<br>
|
SIP:P-Preferred-Identity - userinfo


'''TMG800 +1, TSG800 +1, TMGIP800 +1'''
| For example : The 'fluffy' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> <br>
*One 800+1 series unit. See figure 1.1 on page 2.
| <br>
*One set of mounting brackets and screws, used to mount the 800+1 series unit to a 19" rack.
|-
*One Tmedia serial adapter, to interface the serial port of your computer with the RJ-45 port of the 800 series +1.
| preferred_id_display_name<br>
*Three CAT5 Ethernet straight cables (male-male), 3 meters in length.
| N/A<br>
*One Important Notice (two-sided document containing pertinent product serial numbers, and other important information).
| N/A<br>
*One Product Warranty.
| N/A<br>
*One packing slip.
|
*For AC powered units: Two AC power cables
SIP:P-Preferred-Identity - display name
*The associated 1+1 patch panel. This is only available for the TSG800 +1 and TMG800 +1.


| For example : The 'Cullen Jennings' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> <br>
| <br>
|-
| preferred_id_sip_host <br>
| N/A<br>
| N/A<br>
| N/A<br>
|
SIP:P-Preferred-Identity - host (domain or IP)


Not included:
| For example : The 'telcobridges.com' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> <br>
*A 19" equipment rack. The 800 series +1 unit must be installed in a standard 19" wide equipment rack.
| <br>
|-
| preferred_id_sip_port <br>
| N/A<br>
| N/A<br>
| N/A<br>
|
SIP:P-Preferred-Identity - port


| For example : The '6060' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060> <br>
| <br>
|-
| called <br>
| Q931: 'Called party number' IE - Number digits <br>
| DNIS (Group A)<br>
| Q763: 'Called party number' IE - address signals<br>
| SIP:To - user-info and host<br>
| <br>
| <br>
|-
| called_sip_host <br>
| N/A<br>
| N/A<br>
| N/A<br>
| SIP:To - host <br>
| For example : The 'telcobridges.com' in To: "Cullen Jennings" <sip:fluffy@telcobridges.com> <br>
| <br>
|-
| called_sip_port <br>
| N/A<br>
| N/A<br>
| N/A<br>
| SIP:To - port number <br>
| For example : The '6060' in To: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060> <br>
| <br>
|-
| called_noa <br>
| Q931: 'Called party number' IE - Type of number<br>
| N/A<br>
| Q763: 'Called party number' IE - nature of address indicator<br>
| N/A<br>
| <br>
| <br>
|-
| called_npi <br>
| Q931: 'Called party number' IE - Numbering plan identification<br>
| N/A<br>
| Q763: 'Called party number' IE - numbering plan indicator<br>
| N/A<br>
| <br>
| <br>
|-
| charge_number<br>
| N/A<br>
| N/A<br>
| ANSI: 'Charge number' IE - address signals<br>
| N/A<br>
| <br>
| <br>
|-
| charge_number_noa <br>
| N/A<br>
| N/A<br>
| ANSI: 'Charge number' IE - nature of address indicator<br>
| N/A<br>
| <br>
| <br>
|-
| charge_number_npi<br>
| N/A<br>
| N/A<br>
| ANSI: 'Charge number' IE - numbering plan indicator<br>
| N/A<br>
| <br>
| <br>
|-
| redirecting_number_forward_enabled <br>
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg <br>
| <br>
|-
| redirecting_number <br>
| Q931: 'Redirecting number' 1st IE - Number digits <br>
| N/A<br>
| Q763: 'Redirecting number' IE - address signals<br>
| SIP:Diversion (2nd header) - display-name<br>
| <br>
| <br>
|-
| redirecting_number_noa <br>
| Q931: 'Redirecting number'&nbsp;1st IE - Type of number<br>
| N/A<br>
| Q763: 'Redirecting number' IE - nature of address indicator<br>
| N/A<br>
| <br>
| <br>
|-
| redirecting_number_npi <br>
| Q931: 'Redirecting number' 1st IE - Numbering plan identification<br>
| N/A<br>
| Q763: 'Redirecting number' IE - numbering plan indicator<br>
| N/A<br>
| <br>
| <br>
|-
| redirecting_number_presentation <br>
| Q931: 'Redirecting number' 1st IE - Presentation indicator <br>
| N/A<br>
| Q763: 'Redirecting number' IE - address presentation restricted indicator<br>
| SIP:Diversion&nbsp;(2nd header) - diversion-privacy<br>
| <br>
| <br>
|-
| redirecting_number_indicator <br>
| N/A<br>
| N/A<br>
| Q763: 'Redirection information' IE - redirecting indicator<br>
| N/A<br>
| <br>
| <br>
|-
| redirecting_number_reason <br>
| Q931: 'Redirecting number' 1st IE - Reason for redirection<br>
| N/A<br>
| Q763: 'Redirection information' IE - redirecting reason<br>
| SIP:Diversion (2nd header) - diversion-reason<br>
| <br>
| <br>
|-
| redirecting_number_counter <br>
| N/A<br>
| N/A<br>
| Q763: 'Redirection information' IE - redirection counter<br>
| SIP:Diversion (2nd header) - diversion-counter<br>
| <br>
| <br>
|-
| original_called_number
(OCN) <br>
| Q931: 'Redirecting number' 2nd IE - Number digits <br>
| N/A<br>
| Q763: 'Redirection number' IE - address signals<br>
| SIP:Diversion&nbsp; (1st header) - display-name<br>
| <br>
| <br>
|-
| original_called_number_noa <br>
| Q931: 'Redirecting number' 2nd IE - Type of number<br>
| N/A<br>
| Q763: 'Redirection number' IE - nature of address indicator<br>
| N/A<br>
| <br>
| <br>
|-
| original_called_number_npi <br>
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification<br>
| N/A<br>
| Q763: 'Redirection number' IE - numbering plan indicator<br>
| N/A<br>
| <br>
| <br>
|-
| original_called_number_presentation <br>
| Q931: 'Redirecting number' 2nd IE - Presentation indicator <br>
| N/A<br>
| Q763: 'Redirection number' IE - address presentation restricted indicator<br>
| SIP:Diversion (1st header) - diversion-privacy<br>
| <br>
| <br>
|-
| original_called_number_reason <br>
| Q931: 'Redirecting number' 2nd IE - Reason for redirection<br>
| N/A<br>
| Q763: 'Redirection information' IE - original redirection reason<br>
| SIP:Diversion (1st header) - diversion-reason<br>
| <br>
| <br>
|-
| original_called_number_counter <br>
| N/A<br>
| N/A<br>
| N/A<br>
| SIP:Diversion (1st header) - diversion-counter<br>
| <br>
| <br>
|-
| ported_number_npdi <br>
| N/A<br>
| N/A<br>
| Q763: 'Generic number' IE - with qualifier=Ported number is present<br>
| SIP:RequestURI - npdi=yes is present<br>
| Only valid if SIP/SS7 supports LNP<br>
| <br>
|-
| ported_number <br>
| N/A<br>
| N/A<br>
| Q763: 'Generic number' IE - address signals with qualifier=Ported number<br>
| SIP:RequestURI - to user part when rn is present<br>
| rn is stored in the called number<br>
| <br>
|-
| ported_number_noa <br>
| N/A<br>
| N/A<br>
| Q763: 'Generic number' IE - nature of address indicator with qualifier=Ported number<br>
| N/A<br>
| Only valid if SIP/SS7 supports LNP<br>
| <br>
|-
| ported_number_npi <br>
| N/A<br>
| N/A<br>
| Q763: 'Generic number' IE - numbering plan indicator with qualifier=Ported number<br>
| N/A<br>
| Only valid if SIP/SS7 supports LNP<br>
| <br>
|-
| oli
(Originating line information) <br>
| 5ESS Codeset 6 OLI - Value<br>
| N/A<br>
| ANSI: 'Originating line information' IE - OLI<br>
|
SIP:From - oli


'''1+1 Patch Panel'''
SIP:P-asserted-identity - oli<br>
One or two 1+1 patch panels are required for the proper connection of each grouping of 8 lines of the 800 series 1+1 system.
Cables provided: You are provided with 16 RJ48C cables (yellow), two meters in length with your 1+1 Patch Panel (8 T1/E1).


 
| <br>
{| class="wikitable"
| <br>
|+ 1+1 Patch Panels for TMG800 +1 and TSG800 +1
|-
| request_uri <br>
| N/A<br>
| N/A<br>
| N/A<br>
| Complete Request URI string<br>
| <br>
| <br>
|-
| request_uri_forward_enabled <br>
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Overwrite default URI&nbsp;forwarding behavior from incoming to outgoing leg<br>
| <br>
|-
| sip_header<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Any header<br>
| Requires option 'Enable SIP Custom Headers' in Profiles->SIP <br>
| 2.7.63<br>
|-
| nap
(Network Access Point) <br>
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Incoming leg NAP name (read-only)<br>
| <br>
|-
| type_of_network_identification<br>
| Q931: 'Transit network selection' IE - Type of network identification <br>
| N/A<br>
| Q763: 'Transit network selection' IE - Type of network identification <br>
| N/A<br>
| <br>
| 2.7<br>
|-
| network_identification<br>
| Q931: 'Transit network selection' IE - Network identification <br>
| N/A<br>
| Q763: 'Transit network selection' IE - Network identification <br>
| SIP: Request-Line - cic<br>
| <br>
| 2.7<br>
|-
| network_identification_plan<br>
| Q931: 'Transit network selection' IE - Network identification plan <br>
| N/A<br>
| Q763: 'Transit network selection' IE - Network identification plan <br>
| N/A<br>
| <br>
| 2.7<br>
|-
| location_number_forward_enabled <br>
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Overwrite default location number forwarding behavior from incoming to outgoing leg <br>
| 2.7<br>
|-
| location_number <br>
| N/A<br>
| N/A<br>
| Q763: 'Location number' IE - address signals<br>
| N/A<br>
| <br>
| 2.7<br>
|-
| location_number_noa <br>
| N/A<br>
| N/A<br>
| Q763: 'Location number' IE - nature of address indicator<br>
| N/A<br>
| <br>
| 2.7<br>
|-
| location_number_npi <br>
| N/A<br>
| N/A<br>
| Q763: 'Location number' IE - numbering plan indicator<br>
| N/A<br>
| <br>
| 2.7<br>
|-
| location_number_presentation<br>
| N/A<br>
| N/A<br>
| Q763: 'Location number' IE - presentation restricted indicator<br>
| N/A<br>
| <br>
| 2.7<br>
|-
| location_number_screening <br>
| N/A<br>
| N/A<br>
| Q763: 'Location number' IE - screening<br>
| N/A<br>
| <br>
| 2.7<br>
|-
| mlpp_forward_enabled <br>
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| A script needs to set this to true if it wants to overwrite MLPP information in the outgoing leg.  Otherwise, profile relay 'outgoing mode' applies automatically.<br>
| 2.7<br>
|-
| mlpp_look_for_busy <br>
| N/A<br>
| N/A<br>
| Q763: 'MLPP precedence' IE - look ahead for busy<br>
| N/A<br>
| <br>
| 2.7<br>
|-
| mlpp_precedence_level <br>
| N/A<br>
| N/A<br>
| Q763: 'MLPP precedence' IE - precedence level<br>
| SIP:Resource-Priority - q735<br>
| <br>
| 2.7<br>
|-
| mlpp_network_identity <br>
| N/A<br>
| N/A<br>
| Q763: 'MLPP precedence' IE - network identity<br>
| N/A<br>
| <br>
| 2.7<br>
|-
| mlpp_service_domain<br>
| N/A<br>
| N/A<br>
| Q763: 'MLPP precedence' IE - MLPP service domain<br>
| N/A<br>
| <br>
| 2.7<br>
|-
| isub_forward_enabled <br>
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Overwrite default ISUB forwarding behavior from incoming to outgoing leg <br>
| 3.0.138<br>
|-
| called_isub <br>
| Q931: 'Called party subaddress' IE - subaddress information<br>
| N/A<br>
| Q763: 'Access transport' IE<br>
| SIP:To - isub parameter<br>
| <br>
| 2.7<br>
|-
| called_isub_type<br>
| Q931: 'Called party subaddress' IE - type of subaddress<br>
| N/A<br>
| Q763: 'Access transport' IE<br>
| SIP:To - isub-encoding parameter<br>
| <br>
| 2.7<br>
|-
| calling_isub <br>
| Q931: 'Calling party subaddress' IE - subaddress information<br>
| N/A<br>
| Q763: 'Access transport' IE<br>
| SIP:From - isub<br>
| <br>
| 2.7<br>
|-
| calling_isub_type<br>
| Q931: 'Calling party subaddress' IE - type of subaddress<br>
| N/A<br>
| Q763: 'Access transport' IE<br>
| SIP:From - isub-encoding<br>
| <br>
| 2.7<br>
|-
| ss7_fci_default <br>
| N/A<br>
| N/A<br>
| Default forward call indicator (FCI) value.<br>
| N/A<br>
| Toolpack will overwrite FCI bits A, D, F, I and M with appropriate values according to call conditions<br>
| 2.7<br>
|-
| ss7_fci_force_mask <br>
| N/A<br>
| N/A<br>
| Mask to select bits from ss7_fci_default that must be forced.<br>
| N/A<br>
| Bits from ss7_fci_default which corresponding bit in ss7_fci_force_mask is set will be forced, and no more controlled by Toolpack<br>
| 2.7<br>
|-
| ss7_bci_default <br>
| N/A<br>
| N/A<br>
| Default backward call indicator (BCI) value.<br>
| N/A<br>
| Toolpack will overwrite BCI bits AB, I, K, M and N with appropriate values according to call conditions<br>
| 2.7<br>
|-
| ss7_bci_force_mask <br>
| N/A<br>
| N/A<br>
| Mask to select bits from ss7_bci_default that must be forced.<br>
| N/A<br>
| Bits from ss7_bci_default which corresponding bit in ss7_bci_force_mask is set will be forced, and no more controlled by Toolpack<br>
| 2.7<br>
|-
| tdm_ls_name_forward_enabled<br>
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Enable line service and timeslot selection to create the outgoing leg. tdm_ls_name and tdm_timeslot_nb must be defined along with tdm_ls_name_forward_enabled<br>
| 3.0<br>
|-
| tdm_ls_name
(Line Service or T1/E1 trunk) <br>
| Incoming leg line service name<br>
| Incoming leg line service name<br>
| Incoming leg line service name<br>
| N/A<br>
| if tdm_ls_name_forward_enabled is set, try to use this line service name to create outgoing leg<br>
| 2.7<br>
|-
| tdm_timeslot_nb<br>
| Incoming leg timeslot number<br>
| Incoming leg timeslot number<br>
| Incoming leg timeslot number<br>
| N/A<br>
| if tdm_ls_name_forward_enabled is set, try to use this timeslot number to create outgoing leg<br>
| 2.7<br>
|-
| rtp_local_addr<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Incoming leg local SDP IP address<br>
| (read-only)<br>
| 2.7<br>
|-
| rtp_local_port<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Incoming leg local SDP IP port<br>
| (read-only)<br>
| 2.7<br>
|-
| rtp_remote_addr<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Incoming leg remote SDP IP address<br>
| (read-only)<br>
| 2.7<br>
|-
| rtp_remote_port<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Incoming leg remote SDP IP port<br>
| (read-only)<br>
| 2.7<br>
|-
| ss7_cot_enabled <br>
| N/A<br>
| N/A<br>
| Requests SS7 in-call continuity test for this outgoing SS7 call<br>
| N/A<br>
| Toolpack will request a continuity test on the timeslot before making the outgoing call. If COT fails, the call will be dropped (then another route may be attempted)<br>
| 2.8<br>
|-
| reverse_charging_indication<br>
| Incoming leg Reverse charging indication IE present<br>
| N/A<br>
| N/A<br>
| N/A<br>
| If set in routing script, will add Reverse charging indication IE in outgoing leg (also use reverse_charging_indication_forward_enabled)<br>
| 2.8.12<br>
|-
| reverse_charging_indication_forward_enabled<br>
| N/A<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Enable forwarding of reverse charging indication from incoming to outgoing leg<br>
| 2.8.12<br>
|-
| sip_call_id<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Incoming leg SIP Call-Id<br>
| (read-only)<br>
| 2.9.112 / 3.0.131<br>
|-
| sip_local_addr<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Incoming leg local SIP IP address<br>
| (read-only)<br>
| 2.8.13<br>
|-
| sip_local_port<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Incoming leg local SIP port<br>
| (read-only)<br>
| 2.8.13<br>
|-
| sip_remote_addr<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Incoming leg remote SIP IP address<br>
| (read-only)<br>
| 2.8.13<br>
|-
| sip_remote_port<br>
| N/A<br>
| N/A<br>
| N/A<br>
| Incoming leg remote SIP port<br>
| (read-only)<br>
| 2.8.13<br>
|-
| acli<br>
| N/A<br>
| N/A<br>
| 'Additional Calling Party Information' IE - address signals.
A new ISUP parameter is defined under national option to carry the actual calling party number of the ported subscriber (N2) in the IAM message across the Network.<br>
| N/A<br>
| (read-only)<br>
| 3.0.143.2<br>
|-
| acli_nao<br>
| N/A<br>
| N/A<br>
| 'Additional Calling Party Information' IE - nature of address indicator.
A new ISUP parameter is defined under national option to carry the actual calling party number of the ported subscriber (N2) in the IAM message across the Network.<br>
| N/A<br>
| (read-only)<br>
| 3.0.143.2<br>
|-
| acli_npi<br>
| N/A<br>
| N/A<br>
| 'Additional Calling Party Information' IE - numbering plan indicator.
A new ISUP parameter is defined under national option to carry the actual calling party number of the ported subscriber (N2) in the IAM message across the Network.<br>
| N/A<br>
| (read-only)<br>
| 3.0.143.2<br>
|-
| acli_presentation<br>
| N/A<br>
| N/A<br>
| 'Additional Calling Party Information' IE - address presentation restricted indicator.
A new ISUP parameter is defined under national option to carry the actual calling party number of the ported subscriber (N2) in the IAM message across the Network.<br>
| N/A<br>
| (read-only)<br>
| 3.0.143.2<br>
|-
|-
| 1+1 Patch Panel (8/T1/E1)
| acli_screening<br>
| Provides connection for up to 8 T1/E1 lines from the network to the 1+1 Patch Panel (8 T1/E1) and then links to the TMG800/TSG800 and TMG800 +1/TSG800 +1
| N/A<br>
 
| N/A<br>
 
| 'Additional Calling Party Information' IE - screening indicator.
You are provided with 16 RJ48C cables (yellow), two meters in length, per 1+1 Patch Panel (8 T1/E1) you receive.
A new ISUP parameter is defined under national option to carry the actual calling party number of the ported subscriber (N2) in the IAM message across the Network.<br>
| N/A<br>
| (read-only)<br>
| 3.0.143.2<br>
|}
|}
<br><br>


==Rack Mounting the 800 Series Standalone or the 800 Series 1+1 System==
==New table==
----
{| class="wikitable sortable"
[[File:Icon_StandAlone_1+1.svg|75px|right]]
|+ Routing Script Parameters
The 800 series equipment is mounted on a customer provided equipment rack using the mounting
|-
hardware packaged in the box.
! Script parameter name !! ISDN !! R2_CAS !! SS7 !! SIP !! Comment !! Toolpack version
<br><br>
|-
===Prerequisites===
| leg_id || N/A || N/A || N/A || N/A || Leg ID ||
----
|-
To rack mount the equipment, you will need:
| session_id || N/A || N/A || N/A || N/A || Session ID ||
*One 19” customer-provided equipment rack. The rack must be solidly anchored to the floor with appropriate support at the top of the racks.
|-
*Climate controlled room: 0 to +50 Celsius, 0 to 95% non-condensing humidity.
| original_session_id ||N/A ||N/A || N/A || N/A || Original Session ID (before call transfer or redirections) ||
<br><br>
|-
| 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_sip_host || N/A ||N/A || N/A || SIP:From - host (domain or IP) || For example : The 'telcobridges.com' in From: "Cullen Jennings" <sip:fluffy@telcobridges.com> ||  
|-
| calling_sip_port || N/A || N/A || N/A || SIP:From - port ||  For example : The '6060' in From: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060> ||
|-
| 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&nbsp;(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 ITU97: 'Display information' IE - display information ANSI95: 'Generic name' 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 - 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 || For example : The 'fluffy' in P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> || 
|-
| private_address_sip_host || N/A || N/A || N/A || SIP:P-asserted-identity - host (domain or IP)  SIP:Remote-party-id - host (domain or IP) || For example : The 'telcobridges.com' in P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> || 
|-
| private_address_sip_port || N/A || N/A || N/A || SIP:P-asserted-identity - port  SIP:Remote-party-id - port || For example : The '6060' in P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060> || 
|-
| supp_private_address_
forward_enabled
| N/A
| N/A
| N/A
| N/A
| Overwrite default supplementary/second P-Asserted-Identity header forwarding behavior from incoming to outgoing leg
| 
|-
| supp_private_address || N/A || N/A || N/A || SIP:P-Asserted-Identity - userinfo || For example : The 'fluffy' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> || 
|-
| supp_private_address_
display_name
| N/A
| N/A
| N/A
| SIP:P-Asserted-Identity - display name
| For example : The 'Cullen Jennings' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>
| 
|-
| supp_private_address
_sip_host
| N/A
| N/A
| N/A
| SIP:P-Asserted-Identity - host (domain or IP)
| For example : The 'telcobridges.com' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> 
| 
|-
| supp_private_address
_sip_port
| N/A
| N/A
| N/A
| SIP:P-Asserted-Identity - port
| For example : The '6060' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060>
| 
|-
| preferred_id_forward
_enabled
| N/A
| N/A
| N/A
| N/A
| Overwrite default P-Preferred-Identity header forwarding behavior from incoming to outgoing leg
| 
|-
| preferred_id || N/A || N/A || N/A || SIP:P-Preferred-Identity - userinfo || For example : The 'fluffy' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com> || 
|-
| preferred_id_display
_name
| N/A
| N/A
| N/A
| SIP:P-Preferred-Identity - display name
| For example : The 'Cullen Jennings' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>
| 
|-
| preferred_id_sip
_host
| N/A
| N/A
| N/A
| SIP:P-Preferred-Identity - host (domain or IP)
| For example : The 'telcobridges.com' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>
| 
|-
| preferred_id_sip
_port
| N/A
| N/A
| N/A
| SIP:P-Preferred-Identity - port
| For example : The '6060' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060> || 
|-
| 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_sip_host || N/A || N/A || N/A || SIP:To - host || For example : The 'telcobridges.com' in To: "Cullen Jennings" <sip:fluffy@telcobridges.com> || 
|-
| called_sip_port || N/A || N/A || N/A || SIP:To - port number || For example : The '6060' in To: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060> || 
|-
| 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
| <br>
| <br>
|-
| 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&nbsp; (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_npdi
| N/A
| N/A
| Q763: 'Generic number' IE - with qualifier = Ported number is present
| SIP: RequestURI - npdi = yes is present
| Only valid if SIP/SS7 supports LNP
|
|-
| ported_number
| N/A
| N/A
| Q763: 'Generic number' IE - address signals with qualifier = Ported number
| SIP: RequestURI - to user part when rn is present
| rn is stored in the called number
| 
|-
| ported_number_noa
| N/A
| N/A
| Q763: 'Generic number' IE - nature of address indicator with qualifier = Ported number
| N/A
| Only valid if SIP/SS7 supports LNP
|
|-
| ported_number_npi
| N/A
| N/A
| Q763: 'Generic number' IE - numbering plan indicator with qualifier = Ported number
| 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


===Vertical Placement of the Equipment===
SIP:P-asserted-identity - oli
The 800 series standalone, 800 series +1, and 1+1 Patch Panel are each housed in a 1U chassis, as tabulated below. It is important that you provide for enough room on the equipment rack to allow for the installation of the equipment.
|
 
|
 
|-
Consider the available space on your equipment rack and the height of the 800 series gateway equipment. Due to the rear-exhaust heat vents and the efficient heat dissipation design, there is no need to leave any physical vertical space above or below the 800 series gateway equipment on the equipment rack.
| request_uri
 
| N/A
{| class="wikitable"
| N/A
|+ 800 Series Equipment Physical Height
| 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 'Enable SIP 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
| A script needs to set this to true if it wants to overwrite MLPP information in the outgoing leg.  Otherwise, profile relay 'outgoing mode' applies automatically.
| 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
|-
| isub_forward_enabled
| N/A
| N/A
| N/A
| N/A
| Overwrite default ISUB forwarding behavior from incoming to outgoing leg
| 3.0.138
|-
| called_isub
| Q931: 'Called party subaddress' IE - subaddress information
| N/A
| Q763: 'Access transport' IE
| SIP: To - isub parameter
|
| 2.7
|-
| called_isub_type
| Q931: 'Called party subaddress' IE - type of subaddress
| N/A
| Q763: 'Access transport' IE
| SIP:To - isub-encoding parameter
|
| 2.7
|-
| calling_isub
| Q931: 'Calling party subaddress' IE - subaddress information
| N/A
| Q763: 'Access transport' IE
| SIP: From - isub
|
| 2.7
|-
|-
! Model !! Vertical Height
| calling_isub_type
| Q931: 'Calling party subaddress' IE - type of subaddress
| N/A
| Q763: 'Access transport' IE
| SIP: From - isub-encoding
|
| 2.7
|-
|-
| 800 series standalone
| ss7_fci_default
| 1U (1.75 inches or 44.45 mm)
| N/A
| N/A
| Default Forward 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
|-
|-
| 800 series +1
| ss7_fci_force
| 1U (1.75 inches or 44.45 mm)
_mask
| N/A
| N/A
| Mask to select bits from ss7_fci_default that must be forced.
| N/A
| Bits from ss7_fci_default for which the corresponding bit in ss7_fci_force_mask is set, and no longer controlled by Toolpack
| 2.7
|-
|-
| Patch Panel (one or two)
| ss7_bci_default 
| 1U (1.75 inches or 44.45 mm)
| N/A
|}
| N/A
<br><br>
| Default Backward Call Indicator (BCI) value.
===Installing the 800 Series Standalone and the 800 Series 1+1 on an Equipment Rack===
| N/A
----
| Toolpack will overwrite BCI bits AB, I, K, M and N with appropriate values according to call conditions
[[File:Icon_StandAlone_1+1.svg|75px|right]]
| 2.7
Both the 800 series standalone and the 800 series 1+1 system are mounted on the 19" equipment rack using the angle brackets and screws provided in the box.  
 
[[File:Icon_StandAlone.svg|75px|right]] Mounting the 800 Series Standalone:
# Using four metal screws, attach one angle bracket to the front, left-hand side of the 800 series unit. Do the same for the angle bracket on the right-hand side.
# Start mounting equipment at the top-most position of the rack, keeping in mind the space required on the equipment rack as described in [[AllynSandbox#Vertical_Placement_of_the_Equipment|Vertical Placement]].
 
 
[[File:Icon_1+1.svg|75px|right]] Mounting the 800 Series 1+1 System:
#Mount the 800 series unit as mentioned above.
#Install the 800 series +1 unit below the 800 series unit.
#To attach the 800 series +1 unit to the equipment rack, follow the previous procedure.
#Install one or two patch panels below the 800 series +1 unit.
 
 
[[File:Tmedia Mounting Rackv3.png]]
 
'''Rack Mounting the Equipment'''
<br><br>
 
==Choosing your Connection Procedure==
----
[[File:Icon_StandAlone_1+1.svg|75px|right]]
 
{| class="wikitable"
|+ Choosing Your Setup
|-
|-
!800 Series Standalone
| ss7_bci_force
!800 Series 1+1 System
_mask
!Adding a Unit
| 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
|-
|-
| I am setting up an 800 series as a standalone unit.
| tdm_ls_name
| I am setting up an 800 series 1+1 system including:
_forward_enabled
*800 series unit
| N/A
*800 series +1
| N/A
*1+1patch panel(s)
| N/A
This will create a redundant system.
| N/A
| I am adding an 800 series +1 to an existing system, thereby creating an 800 series 1+1 system
| Enable line service and timeslot selection to create the outgoing leg. tdm_ls_name and tdm_timeslot_nb must be defined along with tdm_ls_name_forward_enabled
| 3.0
|-
|-
| [[AllynSandbox#Installation_Procedure:_800_Series_Standalone|800 Series Standalone Installation Procedure]]
| tdm_ls_name
| [[AllynSandbox#Installation_Procedure:_800_Series_1+1|800 Series 1+1 System Installation Procedure]]
(Line Service or
| [[AllynSandbox#Installation_Procedure:_Adding_an_800_+1_Unit_to_an_Existing Standalone|Adding an 800 +1 Unit to an Existing Standalone Installation Procedure]]
T1/E1 trunk)
| Incoming leg line service name
| Incoming leg line service name
| Incoming leg line service name
| N/A
| If tdm_ls_name_forward_enabled is set, try to use this line service name to create outgoing leg
| 2.7
|}
|}
<br><br>
==Installing the 800 Series Standalone==
----
If you are here, you have a 800 series unit that you will set up as a standalone system. This section covers the following procedures:
*[[AllynSandbox#Connecting to the 800 Series Gateway Management Interface|Connecting to the 800 Series Gateway Management Interface]]
*[[AllynSandbox#Connecting to a VoIP Network|Connecting to a VoIP Network]]
*[[AllynSandbox#Connecting to the PSTN|Connecting to the PSTN]]
*[[AllynSandbox#Grounding the Equipment Chassis|Grounding the Equipment Chassis]]
*[[AllynSandbox#Powering Up|Powering Up]]
*[[AllynSandbox#Start Up|Start Up]]
<br><br>
===Connecting to the 800 Series Gateway Management Interface===
----
[[File:Icon_StandAlone.svg|60px|right]]
The 800 series gateway provides redundant management interfaces enabling administrators to perform management tasks on the 800 series unit.


=Mostly original tutorial guide text without table=
Some of the stuff I started to move but this is practically all of it


'''Prerequisites'''
To communicate with the management interface, the following is needed:


• One or two CAT5 Ethernet cable with RJ45 male-male terminations.
==Introduction==
This Routing Script Tutorial provides you with essential information in managing the routing of your calls. Consult the sections below to learn more.


==Accessing Routing Script Parameters ==
[[Routing Script Tutorial: Accessing Routing Script Parameters|Learn how to access routing script parameters]]


'''Interconnections'''
==Routing Script Parameter Mapping Table==
The 800 series gateway provides redundant management interfaces each using one gigabit Ethernet network link, as shown in figure.
[[Routing Script Parameter Mapping Table|To learn about how each Routing Script Parameter maps to varying protocols, consult the Routing Script Parameter Mapping Table]]


==Script Parameters Definition==
[[Routing Script Tutorial: Script Parameters Definition|To learn about the definition of each script parameter, consult Script Parameters Definition]]


'''To communicate with the management interface: '''


#Connect the supplied CAT5 Ethernet cable to the port labeled “MGMT0” at the rear of the 800 series gateway. Connect the other end of the same CAT5 cable to the first gigabit Ethernet switch.
#If your system employs a second gigabit Ethernet switch for redundancy, connect a second CAT5 Ethernet cable to MGMT1 at the rear of the 800 series gateway. Connect the other end of the same CAT5 cable to the second gigabit Ethernet switch.


[[File:Management Interface1.png]]
=== Noa values  ===
The text below represents the value normally used by routing script.<br>
Incase it's required to use a value that's not defined in the text values below, a integer can be provided and will be used "as-is" in the signaling message.<br>
Example numeric values for the SS7 protocol are shown in parenthesis.<br>
<br>
*<tt>unknown_number (2 or 0x2)</tt>
*<tt>international_number (4 or 0x4)</tt>
*<tt>national_number (3 or 0x3)</tt>
*<tt>subscriber_number (1 or 0x1)</tt>
*<tt>network_specific (5 or 0x5)</tt>
*<tt>network_routing_national_format (7 or 0x7)</tt>
*<tt>network_routing_international_format (8 or 0x8)</tt>
*<tt>abbreviated_number (6 or 0x6)</tt>
*<tt>subscriber_number_operator_requested (113 or 0x71)</tt>
*<tt>national_number_operator_requested (114 or 0x72)</tt>
*<tt>international_number_operator_requested (115 or 0x73)</tt>
*<tt>no_number_present_operator_requested (116 or 0x74)</tt>
*<tt>no_number_present_cut_through_call_to_carrier (117 or 0x75)</tt>
*<tt>test_line_test_code (119 or 0x77)</tt>
*<tt>non_unique_subscriber_number (113 or 0x71)</tt>
*<tt>non_unique_national_number (115 or 0x73)</tt>
*<tt>non_unique_international_number (116 or 0x74)</tt>
*<tt>call_950_number (118 or 0x76)</tt>
*<tt>special_number (115 or 0x73)</tt>
*<tt>national_number_with_transit_network_selection (116 or 0x74)</tt>
*<tt>international_number_with_transit_network_selection (117 or 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>


{| class="wikitable"
or


|[[File:NoteIcon.png|100px]]|| The default IP addresses for the management ports are located in the “Important Notice” sheet received with the shipment. MGMT ports are configured in bonding.
*<tt>call_params[:called_noa] = 112</tt>


=== Npi values  ===


If you do not know the default IP address, go to [[AllynSandbox#Changing the 800 Series Gateway Management Port IP Address|Changing the 800 Series Gateway Management Port IP Address]].
*<tt>unknown_number</tt>
|}
*<tt>isdn</tt>
<br><br>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>


===Connecting to a VoIP Network===
=== Calling Display Type values  ===
----
[[File:Icon_StandAlone.svg|60px|right]]
The 800 series gateway features redundant GigE ports for connection to different VoIP networks. This provides an access point to manage VoIP traffic. Should one of the IP physical interface go down, the 800 series gateway will continue to manage VoIP traffic using the alternate physical interface.


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


The IP address of the VoIP ports can be modified using the web portal.
Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:


{| class="wikitable"
*<tt>call_params[:calling_display_type] = 0xB1</tt>


|[[File:NoteIcon.png|100px]]|| Certain configurations of the 800 series gateway will exceed 100 Mbps, therefore 1000 Mbps is recommended.
or
|}


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


'''Prerequisites'''
=== Calling Display value  ===
To connect the 800 series gateway to the VoIP network, you will need:
*Gigabit layer 2 Ethernet switch. A second one is required to support redundancy of the VoIP interface.
*One or two CAT5 Ethernet cables with RJ45 male-male terminations.


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


Connections
=== Presentation values for Calling number, Calling Subscriber (Generic Number), Redirecting Number, Original Called Number (OCN) and Location Number ===
The 800 series gateway is connected to the VoIP network by one or optionally two Ethernet GigE network links.
The text below represents the value normally used by routing script.<br>
Incase it's required to use a value that's not defined in the text values below, a integer can be provided and will be used "as-is" in the signaling message.<br>
Example numeric values for the SS7 protocol are shown in parenthesis.<br>
<br>
*<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  ===
The text below represents the value normally used by routing script.<br>
In case it's required to use a value that's not defined in the text values below, a integer can be provided and will be used "as-is" in the signaling message.<br>


To connect the 800 series unit to the VoIP network:
Mapping from routing script to SS7/CAS R2/SIP
#Connect a CAT5 Ethernet cable to VoIP0 at the rear of the 800 series gateway. Connect the other end of the same CAT5 cable to the gigabit Ethernet switch.
{| cellspacing="1" cellpadding="1" border="1"
#If your system employs a second gigabit Ethernet switch for redundancy, connect a second CAT5 Ethernet cable to VoIP1 at the rear of the 800 series gateway. Connect the other end of the same CAT5 cable to the second gigabit Ethernet switch.
|-
 
! scope="col" | '''Routing Script string <br>'''
[[File:VoIPNetwork_MOD1.png]]
! scope="col" | '''SS7 raw value <br>'''
 
! scope="col" | '''R2 CAS scripts'''<br>
'''Connecting to the VoIP Network'''
! scope="col" | '''Default Rx CAS'''<br>
<br><br>
! scope="col" | '''default Tx CAS'''<br>
 
! scope="col" | '''SIP "cpc="  <br>'''  
===Connecting to the PSTN===
|-
----
| subscriber<br>
[[File:Icon_StandAlone.svg|60px|right]]
| 0xa<br>
{| class="wikitable"
| CATEGORY_SUBSCRIBER <br>
 
| 1 and 7<br>
|[[File:NoteIcon.png|100px]]|| This section only applies to the TMG800 and TSG800 systems.
| 7<br>
| ordinary<br>  
|-
| subscriber_with_priority<br>  
| 0xb<br>
| CATEGORY_SUBSCRIBER_WITH_PRIORITY <br>
| 2 and 9 <br>
| 2 <br>
| priority<br>
|-
| operator_french<br>
| 0x1<br>
| CATEGORY_OPERATOR_FRENCH <br>
| 5 <br>
| 5 <br>
| operator<br>
|-
| operator_english<br>
| 0x2<br>
| CATEGORY_OPERATOR_ENGLISH (5)<br>
| 5 <br>
| 5 <br>
| operator<br>
|-
| operator_german<br>
| 0x3<br>
| CATEGORY_OPERATOR_GERMAN (5)<br>
| 5 <br>
| 5 <br>
| operator<br>
|-
| operator_russian<br>
| 0x4<br>
| CATEGORY_OPERATOR_RUSSIAN (5)<br>
| 5 <br>
| 5 <br>
| operator<br>
|-
| operator_spanish <br>
| 0x5<br>
| CATEGORY_OPERATOR_SPANISH (5)<br>
| 5 <br>
| 5 <br>
| operator<br>
|-
| data<br>
| 0xc<br>
| CATEGORY_DATA <br>
| 6 and 8<br>
| 6 <br>
| datacall<br>
|-
| test<br>
| 0xd<br>
| CATEGORY_TEST <br>
| 3 <br>
| 3 <br>
| test<br>
|-
| payphone <br>
| 0xf<br>
| CATEGORY_PAYPHONE <br>
| none <br>
| 7 <br>
| payphone<br>
|-
| unknown <br>
| 0x0 <br>
| CATEGORY_UNKNOWN<br>
| 4, 11 to 15<br>
| 7 <br>
| unknown<br>
|-
| unspecified <br>
| 0xa <br>
| invalid <br>
| none <br>
| none <br>
| invalid <br>
|}
|}
[[CAS_R2_scripting#Category_meanings|Link to calling party categories used in CAS R2 scripts]]


A TMG800 or TSG800 with 16 RJ48C type ports enables the connection to T1/E1 lines. The termination impedance is set at 100 ohms for T1 lines and 120 ohms for E1 lines. It is possible to connect an external balun to convert the line impedance to 75 ohms.
=== Screening values for Calling number, Calling Subscriber (Generic Number), and Location Number  ===
The text below represents the value normally used by routing script.<br>
In case it is required to use a value that is not defined in the text values below, an integer can be provided and will be used "as-is" in the signaling message.<br>
Example numeric values for the SS7 protocol are shown in parenthesis.<br>
<br>
*<tt>unspecified</tt>
*<tt>no (0x0)</tt>
*<tt>pass (0x1)</tt>
*<tt>fail (0x2)</tt>
*<tt>network_provided (0x3)</tt>


=== Redirecting indicator values  ===


If you are making your own cables, refer to [[AllynSandbox#RJ48C Wiring Diagram: Crossover and Straight Cables|RJ48C Wiring Diagram: Crossover and Straight Cables]], for crossover or straight cable wiring connections.
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>


{| class="wikitable"
=== Redirecting number, Original Called Number and Diversion Reason ===


|[[File:NoteIcon.png|100px]]|| All of the ports may not be active. T1/E1 ports are activated by software license; the number of active ports depends on the licenses purchased.
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>


'''To connect to the PSTN:'''
SS7:  
#Start with port 0 located at the top and leftmost position. Connect one cable between this port and the T1/E1 line.
#Repeat step 1, using the next available port.


[[File:PSTN 16T1 MOD.png]]
*<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>


<br><br>
=== OLI (originating line information) values  ===


===Grounding the Equipment Chassis===
The OLI parameter is a string that represents an integer value from 0 to 255.  
----
[[File:Icon_StandAlone.svg|60px|right]]
As a standard safety practice, the chassis of the 800 series gateway must be properly grounded to protect against any contact with an electrical fault condition. It is recommended that the chassis be connected to an earth ground. When the 800 series gateway is installed in an equipment rack, connect the ground wire between the ground lug of the gateway and the equipment rack ground bar. If more than one 800 series gateway is installed in an equipment rack, each 800 series gateway must be grounded directly to the equipment rack ground bar.


=== Information Transfer Capability values  ===


'''Guidelines'''
information_transfer_capability:
Use 10 AWG (minimum) stranded ground wire.
*Terminate equipment side of ground wire with a #10 ring terminal.
*Keep the length of the ground wire as short as possible.
*Do NOT daisy chain the ground between equipment. Use a ground bus bar.
*Do not over tighten ground lug connections.


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


'''To connect the 800 series gateway to ground:'''
=== redirecting_number_forward_enabled values  ===
#Connect one end of a ground wire to the ground lug of the 800 series gateway.
#Connect the other end of the ground wire to a ground bar of the equipment rack. If the 800 series gateway is not installed in an equipment rack, connect the ground wire to earth ground. In the case of DC powered units, connect an additional ground wire from the chassis ground terminal of each DC supply.
#Verify that the resistance of the ground path is less than 0.5 ohms.


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


[[File:Ground.png]]
Values for this parameter are "0", "1", "false" or "true.
<br><br>
*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


===Powering Up===
The value for this parameter at the input of the 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.
----
[[File:Icon_StandAlone.svg|60px|right]]
The 800 series gateway is furnished with two AC or DC power connections. Only once all other
equipment installation work is completed should the 800 series gateway be turned on.
<br><br>
====Connecting to AC Power====
----
'''Prerequisites'''
To power the 800 series gateway, you will need:
*Two power sources.
*Two power cables for the 800 series gateway.


Note: To "insert" a new redirecting number value on the outgoing leg, redirecting_number_forward_enabled must also be set to true.


'''To connect to AC Power:'''
=== request_uri  ===
#Connect an AC power cable to each AC connector of the 800 series gateway and an AC supply.


Enables access to the Request-Line URI.<br>


{| class="wikitable"
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". <br>


|[[File:NoteIcon.png|100px]]|| It is important to connect both power supplies in order to avoid setting off the audible alarm.
In the routing scripts, to retrieve only the called number, this script can be used:<br>
|}
<pre>    if call_params[:request_uri] &amp;&amp; call_params[:request_uri] =~ /sip:(.*)@.*/
      call_params[:called] = $1
    end
</pre>
==== request_uri_forward_enabled ====


This call parameter 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.<br>


[[File:AcPowerConnection.png]]
Values for this parameter are "0", "1", "false" or "true. <br>  
<br><br>


====Connecting to DC Power====
* 0/false: Request uri is not forwarded to outgoing call leg <br>
----
[[File:Icon_StandAlone.svg|60px|right]]
The 800 series gateway, DC model, is furnished with two DC power supplies.


* 1/true: Request uri is forwarded to outgoing call leg <br>


'''Fuse and Cabling Requirements'''
The default value for this parameters is false. <br>
16 AWG wiring must be used and the 48V supply must be protected with a customer provided 5A 48V fuse.




==== sip_scheme  ====
(Available in Toolpack 3.1+)
This call parameter indicates the scheme (generally "sip" or "sips") of the incoming call.


'''To connect to DC power:'''
This also allows the control of the scheme used for the outgoing call (regardless if request_uri_forward_enabled is used or not)
#Connect one wire from the positive terminal of the 800 series gateway to the return side of DC power source one.
#Connect another wire from the negative terminal of the 800 series gateway to the -48V side of DC power source one.
#Connect a ground wire from the ground terminal of the 800 series gateway to earth ground.
#Repeat steps 1-3 for the second power DC power source.


Note: sips scheme must only be used on TLS NAPs (will cause call routing failure if NAP has only UDP or TCP transport types).


[[File:DcWiringDiagramTmg800.png]]
=== sip_header values  ===
<br><br>
Contains custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg:<br />


===Start Up===
'''Note:'''
----
[[File:Icon_StandAlone.svg|60px|right]]


The  SIP header is in string format.


The first time that you connect to an 800 series gateway, the web portal is displayed and you are asked to configure the role of the 800 series gateway. You must set the role as an 800 series standalone.
'''string format:'''
<pre>call[ :sip_header ] = "P-my-custom-header:value1 \nP-my-custom-header2:value2 \nP-my-custom-header3:value3"
</pre>
(Note: \n above are actual newline characters, not '\' followed by 'n')


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


Once the configuration settings are applied, your 800 series gateway starts up and displays the web portal configuration management tool.
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>
Note: Since version 3.0.57, Referred-By is now a SIP custom parameter


=== sip header parameters  ===
The routing script can read (and modify) some SIP header parameters (user parameters, URI parameters or header parameters) from some SIP headers (To, From, P-Asserted-Identity, Remote-Party-ID, Contact).


{| class="wikitable"
==== Available parameters ====
* '''call[ :calling_parameters ]''' (SIP "From" header)
* '''call[ :called_parameters ]''' (SIP "To" header)
* '''call[ :private_address_parameters ]''' (SIP "P-Asserted-Identity" or "Remote-Party-ID" header)
* '''call[ :supp_private_address_parameters ]''' (SIP supplementary/second "P-Asserted-Identity" header)
* '''call[ :preferred_id_parameters ]''' (SIP "P-Preferred-Identity" header)
* '''call[ :contact_parameters ]''' (SIP "Contact" header)


|[[File:NoteIcon.png|100px]]|| To learn about the IP address for your system or how to change it, refer to [[AllynSandbox#Changing the 800 Series Gateway Management Port IP Address|Changing the 800 Series Gateway Management Port IP Address]].
These parameters (if present) contain a hash with 3 keys: user_param, uri_param and header_param.
|}
Each of this key points to a string that contains all the parameters found in the corresponding SIP header.
<br><br>
* '''User parameters''' (parameters between the user name/number and the host). Example  <sip:alice;'''param=value'''@somewhere.com>
====Configuring the Role====
* '''URI parameters''' (parameters at the end of the URI). Example  <sip:alice@somewhere.com;'''param=value'''>
----
* '''Header parameters''' (outside the URI). Example  <sip:alice@somewhere.com>;'''param=value'''
To configure the role of your 800 series gateway as a standalone unit, do the following:
Example to print all parameters of SIP "To" header:
#Connect to the web portal of the standalone unit. The Welcome page appears.
  call[ :called_parameters ].inspect -> '{ :user_param => "name1=value1;name2=value2", :uri_param => "name=value", :header_param => "name=value;example_param_without_value" }'
#Follow the instructions of the web portal to set the role to a standalone gateway.
Example to modify (replace) the URI parameters of SIP "To" header:
  call[ :called_parameters ][ :uri_param ] = "user=phone"


==== Exceptions ====
'''Note:''' Some parameters are reported as their own call attribute (oli, isub, cpc, transport) so they have the same representation for all protocols (SS7, IDSN, SIP). They will not appear in the generic SIP header parameters structures above.


[[File:RoleStandalone0.png]]
==== Forwarding from inbound to outbound call ====
<br><br>


==Installing the 800 Series 1+1==
==== Legacy behavior ====
----
(For base_routing version 1.32 or older)
[[File:Icon_1+1.svg|60px|right]]
By default, the parameters are not forwarded in a SIP to SIP call flow. The parameters '''will be forwarded''' when:
If you are here, you are installing an 800 series 1+1 system. This section covers the following procedures:
* accessed (read) from either the inbound or outbound call parameters
*[[AllynSandbox#Connecting to the 800 Series 1+1 System Management Interfaces|Connecting to the 800 Series 1+1 System Management Interfaces]].
* written in either the inbound or outbound call parameters
*[[AllynSandbox#Connecting to the 800 Series 1+1 System Control Network|Connecting to the 800 Series 1+1 System Control Network]].
*[[AllynSandbox#Connecting to the 800 Series 1+1 System VoIP Network(s)|Connecting to the 800 Series 1+1 System VoIP Network(s)]].
*[[AllynSandbox#Connecting to the PSTN in an 800 Series 1+1 System|Connecting to the PSTN in an 800 Series 1+1 System]].
*[[AllynSandbox#Grounding the Equipment Chassis|Grounding the Equipment Chassis]].
*[[AllynSandbox#Powering Up|Powering Up]].
*[[AllynSandbox#Start Up|Start Up]].
</br></br>
===Connecting to the 800 Series 1+1 System Management Interfaces===
----
[[File:Icon_1+1.svg|60px|right]]
The 800 series gateway provides redundant management interfaces enabling administrators to perform management tasks an the 800 series 1+1 system.


==== Current behavior ====
(For Toolpack 3.0.118+, with base_routing version 1.33+)
SIP headers host and parameters are forwarded by default.


'''Prerequisites'''
A route attribute "forward_sip_domain" (along with filter script "forward_sip_domain.rb") will control, per route, if SIP headers host+parameters must be forwarded.


To communicate with the management interface, the following is needed:
==== Example usage ====
*Two or four CAT5 Ethernet cables with RJ45 male-male terminations.
Example to print the user parameters:
<pre>
  if call[:calling_parameters]
    puts "user parameters = #{call[:calling_parameters][:user_param].inspect}"
  end
</pre>


Example SIP "From" header:
  From:<sip:123456782;test1=val1;test2=val2@something.com;test3=val3;test4=val4>;test5=val5;test6=val6
And the resulting content in the routing script:
  call[:calling_parameters].inspect -> {:user_param=>"test1=val1;test2=val2", :uri_param=>"test3=val3;test4=val4", :header_param=>"test5=val5;test6=val6"}


'''Interconnections'''
Example to overwrite inbound leg calling parameters with new parameters for the outbound leg:
<pre>
call [:calling_parameters] = {
  :user_param => "user_param7=7;user_param8=8",
  :uri_param => "uri_param9=value9",
  :header_param => "header_paramA=A" }
</pre>


An 800 series 1+1 system provides redundant management interfaces for an 800 series and an 800 +1 gateway, each using a gigabit Ethernet network link.
Example to add user=phone and keep all other uri parameters.
<pre>
  call[:calling_parameters] ||= {} # Create a hash if not already present
  call[:calling_parameters][:uri_param] ||= "" # Create a string if not already present
  call[:calling_parameters][:uri_param] += ";" if call[:calling_parameters][:uri_param] != ""
  call[:calling_parameters][:uri_param] += "user=phone"
</pre>


=== MLPP Precedence values  ===


'''To communicate with the management interface:'''
mlpp_look_for_busy:  
#Connect a CAT5 Ethernet cable to the port labeled “”MGMT0” at the rear of the 800 series gateway to the first gigabit Ethernet switch.
#If your system employs a second Gigabit Ethernet switch for redundancy, connect a second CAT5 Ethernet cable to MGMT1 at the rear of the 800 series gateway. Connect the other end of the same CAT5 cable to a second gigabit Ethernet switch.
#Repeat steps 1 and 2 for the 800 series +1 unit.


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


[[File:ManagementInterface.png]]


mlpp_precedence_level:


{| class="wikitable"
*<tt>flash_override</tt>
*<tt>flash</tt>
*<tt>immediate</tt>
*<tt>priority</tt>
*<tt>routine</tt>


|[[File:NoteIcon.png|100px]]||The default IP addresses for the management ports are located in the “Important Notice” sheet received with the shipment. MGMT ports are configured in bonding.


mlpp_network_identity:


If you do not know the default IP address, go to [[AllynSandbox#Changing the 800 Series Gateway Management Port IP Address|Changing the 800 Series Gateway Management Port IP Address]].
3 digits value from 0 to 999
|}
</br></br>


===Connecting to the 800 Series 1+1 System Control Network===
----
[[File:Icon_1+1.svg|60px|right]]


Each 800 series gateway features dual GigE Ethernet ports to connect to the 800 series control network. This allows both units to communicate with one another.
mlpp_service_domain:


24 bits value from 0 to 16777215


'''Prerequisites'''
=== ISUB subaddress information values  ===


To connect to the control network, you will need:
called_isub_type:  
*Two CAT5 Ethernet cables with RJ45 male-male terminations.
calling_isub_type:


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


'''To connect to the control network:'''
#Connect one CAT5 Ethernet cable between ports ETH0 of both the 800 series and 800 series +1 units.
#Connect a second CAT5 Ethernet cable between ports ETH1 of both the 800 series and 800 series +1 units.


[[File:ControlNetworkPlus1.png]]
called_isub:
calling_isub:  


</br></br>
Digits for the subaddress information.


===Connecting to the 800 Series 1+1 System VoIP Network(s)===
=== Network Identification Plan  ===
----
[[File:Icon_1+1.svg|60px|right]]


Each 800 series gateway features redundant GigE ports for connection to different VoIP networks. This provides an access point to manage VoIP traffic. Should one of the IP physical interface go down, the 800 series 1+1 gateway will continue to manage VoIP traffic using the alternate physical interface.
network_identification_plan:


*<tt>Unknown</tt> (value 0)
*<tt>cic</tt> (3 digits carrier identification code plus circuit code, value 1, SS7 or ISDN)
*<tt>user</tt> (User, value 2, ISDN only)
*<tt>cic4</tt> (4 digits carrier identification code plus circuit code, value 2, SS7 only)
*<tt>dnic</tt> (public Data Network ID, value 3, SS7 only)
*<tt>mnic</tt> (public land mobile network, value 6, SS7 only)


The IP address of the VoIP ports can be modified using the web portal.
=== Registered Users Information ===
Routing script can access information about registered users (when either the calling or called user is a known registered user).
When these fields are empty, it means that the calling/called (SIP from/to) does not correspond to a known registered user (routing script may still decide to route the call based on static routes).


{| class="wikitable"
Information for the called user:
  params[:registered_user]
Information for the calling user:
  params[:calling_registered_user]


|[[File:NoteIcon.png|100px]]|| The 800 series 1+1 system requires two (2) gigabit layer 2 Ethernet switches.
These parameters are a hash of key/values that provide information about the contact.
|}
  {
    :contact_list=>
    [
      {
        :contact=>"<sip:user_name_or_number@hostname:7070;transport=UDP>",    -> Full contact
        :expires=>"60",                  -> Contact expiry time (seconds)
        :host=>"hostname",                -> host name from the contact header
        :name=>"user_name_or_number",    -> user name from the contact header
        :nap_in=>"NAP_NAME",              -> NAP that the contact has registered from
        :port=>"7070",                    -> Port from the contact header
        :transport=>"UDP"                -> Transport type from the contact header
        :q_value=>"0.00",                -> Q-value for the contact (for contact ordering)
        :src_host=>"10.0.0.10",          -> Actual source IP address that the contact has registered from
        :src_port=>"7070",                -> Actual source port that the contact has registered from
        :src_transport=>"UDP",            -> Actual protocol that the contact has been registering with
      }
    ]
  }


'''Prerequisites'''
== Route parameters  ==


To connect to the VoIP network, you will need:
All route may have these parameters:  
*Two gigabit layer 2 Ethernet switches. A second one is required to support redundancy of the VoIP interface.
*Four CAT5 Ethernet cables with RJ45 male-male terminations.


*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_destination_leg_profile (called remapped_profile prior to Toolpack 2.9)
*remapped_source_leg_profile (called remapped_incoming_profile prior to Toolpack 2.9)


'''Connections'''
Example:


The 800 series unit and 800 series +1 VoIP ports must to be connected on both Ethernet GigE network links.
  route[:remapped_nap]


Additionally, it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.
For example:
*priority
*weight


'''To connect to the VoIP network:'''
== Routing calls toward registered users ==
#Connect the VoIP0 connector from both the 800 series and 800 series +1 units to the first Ethernet switch.
Static routes normally choose an outbound NAP to forward the call to. It is also possible to create routes from which the outbound NAP is dynamically chosen by matching a registered user (when using [[Sip_registration_forwarding|SIP registration forwarding]]).
#Connect the VoIP1 connector from both the 800 series and 800 series +1 units to the second Ethernet switch.


More information can be found [[Sip_registration_forwarding#SIP_Calls_routing|here]] about the way to control the [[Sip_registration_forwarding#SIP_Calls_routing|priority of "dynamic" vs "static" routes]].


[[File:VoipNetworkMod.png]]
More information can be found [[#Registered_Users_Information|here]] about using routing scripts to access registered users information during call routing.
</br></br>


===Connecting to the PSTN in an 800 Series 1+1 System===
== Playing prompts announcements or tones  ==
----
[[File:Icon_1+1.svg|60px|right]]


{| class="wikitable"
New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts (audio files) in different states of the call flow.


|[[File:NoteIcon.png|200px]]|| This section only applies to the TMG800 and TSG800 systems.
*'''announcement_tone''' (played before outgoing call is routed)
|}
*'''ring_tone''' (played after when waiting for outgoing call to answer)
*'''busy_tone''' (played if outgoing call failed)
*'''disconnect_tone''' (played after the call has reached it's maximum duration)


An 800 series 1+1 system has a TDM interface featuring 16 RJ48C type ports enabling the connection to T1/E1 lines. The termination impedance is set at 100 ohms for T1 lines and 120 ohms for E1 lines. It is possible to connect an external balun in order to convert to 75 ohms. If you are making your own cables, refer to [[AllynSandbox#Wiring Diagrams|Wiring Diagrams]] crossover or straight cable wiring connections.
Example to play an announcement to incoming call (before routing outgoing call, regardless if a matching route is found or not):
  bridge[:announcement_tone ] = "my_announcement.wav"


{| class="wikitable"
Example to play a ring-tone while the outgoing call is ringing:
  bridge[:ring_tone] = "my_ring_tone.wav"


|[[File:NoteIcon.png|100px]]|| All ports may not be active. T1/E1 ports are activated by software license; the number of active ports depends on the licenses purchased.
Example to play an audio file when outgoing call fails (no route, or outgoing call is refused):
  bridge[:busy_tone] = "my_busy_tone.wav"


Example to play an audio file when call has reached the maximum allowed duration:
  bridge[:disconnect_tone] = "your_account_balance_is_empty.wav"


Patch panels use straight connections. In other words, they do not cross the RX and TX signals. Connections between the patch panels and an 800 series 1+1 system require straight cables. The supplied T1/E1 cables are straight cables. Cables used to connect the network to the 1+1 patch panel must do the cross connection.
|}


=== Announcement file path format and options ===


'''To connect to the PSTN:'''
All file plabyacks (:announcement_tone,&nbsp;:busy_tone,&nbsp;:ring_tone,&nbsp;:disconnect_tone) inside bridge parameters use this format.
#Connect T1/E1 lines 0-7 of the Network section of the patch panel to the remote equipment.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
#Connect T1/E1 lines 0-7 from the 'Gateway' section of the patch panel to the RJ48C connectors of the 800 series unit.
</pre>
#Connect T1/E1 lines 0-7 from the 'Gateway 1+1' section of the patch panel to the RJ48C connectors of the 800 series +1 unit.
Optional parameters:
#Repeat step 1 - 3 for lines 8-15, connecting them to a second patch panel.
* repeat: number of times to play the file (0 and 1 have the same result)
* start_off: Start offset in milliseconds
* end_off: End offset in milliseconds


[[File:Tdm1+18T1E1Des.png]]
Http and other path formats are described here: [[Customer_application_framework:play_audio_files#Play_path_format|Path format]]
</br></br>


===Grounding the Equipment Chassis===
==== Example 1 ====
----
The following example will play file1.wav once, and then play file2.wav in a loop:
[[File:Icon_1+1.svg|60px|right]]
  "file1.wav,file2.wav:-1"


As a standard safety practice, the chassis of the 800 series gateway must be properly grounded to protect against any contact with an electrical fault condition. It is recommended that the chassis be connected to an earth ground. When the 800 series gateway is installed in an equipment rack, connect the ground wire between the ground lug of the gateway and the equipment rack ground bar. If more than one 800 series gateway is installed in an equipment rack, each 800 series gateway must be grounded directly to the equipment rack ground bar.
==== Example 2 ====
The following example will play file1.wav from a start offset of 1 second to an end offset of 3 seconds, followed by file2.wav being played two times from second 5 to second 10.
  "file1.wav:0:1000:3000,file2.wav:2:5000:10000"


==== Example 3 ====
The following example will play file1.wav once, ending at an offset of 30 seconds.
  "file1.wav:0:0:30000"


'''Guidelines'''
=== announcement_tone  ===
*Use 10 AWG (minimum) stranded ground wire.
*Terminate equipment side of ground wire with a #10 ring terminal.
*Keep the length of the ground wire as short as possible.
*Do NOT daisy chain the ground between equipment. Use a ground bus bar.
*Do not over tighten ground lug connections.


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


'''To connect the 800 series gateway to ground:'''
Audio file played on the incoming call before any outgoing call is placed. The outgoing call occurs when the file finished playing.
#Connect one end of a ground wire to the ground lug of the 800 series gateway.
#Connect the other end of the ground wire to a ground bar of the equipment rack. If the 800 series gateway is not installed in an equipment rack, connect the ground wire to earth ground.
#Verify that the resistance of the ground path is less than 0.5 ohms.


[[File:Ground.png]]
==== announcement_tone options ====
</br></br>
===== announcement_tone_answer =====
  params[:bridge][:announcement_tone_answer] = "yes"


===Powering Up===
Forces an answer of the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.
----
[[File:Icon_1+1.svg|60px|right]]


The 800 series and 800 series +1 units are furnished with two AC or DC power connections. Only once all other equipment installation work has been completed should the 800 Series 1+1 system be powered up.
===== announcement_code_detect =====
This option allows that the tone detection is enabled during the announcement play.


Collected digits can be inserted into the CDR logs (radius attribute "Telcob-CollectedDigits", or text CDR variable @{CollectedDigits}).


'''Prerequisites:'''
Collected digits can also be sent back to routing script, which is called again with the same call attributes, except that the called number is replaced by the collected digits.
To connect power you will need:
*Two power sources.
*Two power cables for every 800 series and 800 series +1 unit.
</br></br>
====Connecting to AC Power====
----
[[File:Icon_1+1.svg|60px|right]]


'''To connect to AC Power:'''
Code detect has multiple options, as shown in the following code:
#Connect the first power connector of each unit to the first power source.
  code_detect = {
#Connect the second power connector of each unit to the second power source.
    :type                  => :DTMF,  # :DTMF or :MFR1 tone detection.
                                        # Default is MFR1.
    :prefix                => "",      # Prefix (digits) that is removed from collected digits.
                                        # Default is empty.
    :suffix                => "",      # Suffix (digits) that is removed from collected digits
                                        # and causes routing script to be immediately called.
                                        # Default is empty.
    :suffix_removal        => false,  # Controls the removal of the suffix from the collected digit string that's reported to routing script.
                                        # Default is false
    :timeout                => 0,      # Inter-digit timeout (ms) after which collected digits are passed to the routing script.
                                        # Use 0 for "no timeout".
                                        # Default is 1000ms
    :barge_in_interruption  => true,    # When enabled, playing announcement is stopped as soon as first digit is collected.
                                        # Default is true.
    :proceed_on_play_done  => false,  # When true:  Outgoing call is made after announcement finishes playing.
                                        #            Routing script is not called again.
                                        # When false: Outgoing call is never made.
                                        #            Digits are collected until timeout or suffix match,
                                        #            then routing script is called again.
                                        # Default is false.
    :cas_on_hook            => false,  # Specific for CAS-R1 calls. Makes CAS bits switch to "on-hook" when announcement finished playing
                                        # (but the call is not "terminated" from Toolpack point of view)
                                        # Default is false.
    :cas_on_hook_delay      => 0,      # Duration of cas bits "on-hook" state.
                                        # Only effective if cas_on_hook is set to true.
                                        # Value of 0 stands for "infinite delay".
                                        # Default is 0.
    :repeat_delay          => 0,      # Delay between repetition of the announcement. The announcement will repeat
                                        # itself every "repeat_delay" until a code is detected (suffix match or timetout).
                                        # Value of 0 stands for "infinite delay" (no repeating).
                                        # Default is 0.
  }
'''Example 1''': Collect DTMF digits, and call routing script again with collected digits upon timeout or suffix match.
  code_detect = { :type => :DTMF, :suffix => "#", :timeout => 5000 }
  params[:bridge][:announcement_code_detect] = code_detect


[[File:AcPowerConnection1+1.png]]
'''Example 2''': Collect digits during the announcement (for CDR logs), then proceed (make outgoing call) after announcement finishes playing
'''800 Series and 800 Series +1 AC Power Connections'''
  code_detect = { :type => :DTMF, :timeout => 0, :barge_in_interruption => false, :proceed_on_play_done => true }
</br></br>
  params[:bridge][:announcement_code_detect] = code_detect


====Connecting to DC Power====
==== Controlling what happens after announcement ====
----
The routing script can control what happens with the call after the announcement finishes playing:
[[File:Icon_1+1.svg|60px|right]]
* An outgoing call is made
* Incoming call is hung-up
* Do nothing (wait for the incoming call to hang-up)
===== An outgoing call is made =====
This happens when the script has returned matching routes (and did not raise RoutingException)


The 800 series gateway, DC model, is furnished with two DC power supplies.
===== Incoming call is hung-up =====
This happens when the script returns no routes (in which case base_routing will raise RoutingException with cause :no_route).


It also happens when the script explicitly raises RoutingException.


'''To connect an 800 Series and 800 Series +1 Unit to DC Power:'''
The incoming call will be terminated with the specified cause.
#Connect one wire from the positive terminal of the 800 series gateway to the return side of DC power source one.
For example
#Connect another wire from the negative terminal of the 800 series gateway to the -48V side of DC power source one.
    raise RoutingException, :temporary_failure
#Connect a ground wire from the ground terminal of the 800 series gateway to earth ground.
(See "Reason values" section in this page for list of available causes)
#Repeat steps 1-3 for the second power DC power source.


===== Do nothing (wait for the incoming call to hang-up) =====
If a filter raises RoutingException with code :ok, then the incoming call will not be terminated at the end of the announcement play.
Announcement digit collection will remain active if appropriate.
For example:
    raise RoutingException, :ok


[[File:DcDualWithGround1Plus1.png]]
</br></br>


===Start Up===
----
[[File:Icon_1+1.svg|60px|right]]


After powering up the 800 series 1+1 system, you must configure both units, one as primary and the other as secondary.


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


Once these configuration settings have been applied, your 800 series 1+1 system will start up and display the web portal configuration management tool.
Audio file played on the incoming call while waiting for the outgoing call to be answered.


{| class="wikitable"
Ring tone playback can also be configured in the Web Portal, from the incoming call's profile (under "Tones and Call Progress Options").


|[[File:NoteIcon.png|100px]]|| To learn about the IP address for your system or how to change it, see Changing the 800 Series Gateway Management Port IP Address.
Routing script has precedence over profile (a routing script that fills params[:bridge][:ring_tone] will override the profile's ring tone behavior).
|}


1. Connect to the web portal. The Welcome page appears.
==== ring_tone options ====
===== ring_tone_state =====
  params[:bridge][:ring_tone_state] = :alerted


[[File:RolePrimary0.png]]
Call state from which ring tone is being played. Available values are:
* '''immediately''':  Ring tone starts playing immediately on the incoming leg
* '''accepted''':    Ring tone starts playing as soon as outgoing call is accepted
* '''callprogress''': Ring tone starts playing as soon as "call progress" is received on the outgoing call
* '''alerted''' (default):      Ring tone starts playing only once outgoing call is alerted (but won't play if alert indicates early media from outgoing call)


{| class="wikitable"
This option also applies when params[:bridge][:ring_tone] are not used, because it also applies to ring tone playback configured in the Web Portal, from the incoming call's profile.


|[[File:NoteIcon.png|100px]]|| The Welcome page indicates whether the 800 series unit is a primary or secondary.
=== busy_tone  ===
|}
  Toolpack 2.8 and above:
    params[:bridge][:busy_tone] = "no_route.wav"


2. Follow the instructions of the web portal to configure the units of your 800 series 1+1 system, by indicating the following:
  Note: Obsolete name (toolpack 2.7.153 and earlier, but still supported in recent releases):
*Primary or secondary
    params[:bridge][:call_progress_tone] = "no_route.wav"
*VLAN IDs


Audio file played on the incoming call when outgoing call fails (never answered).


3. Once you confirm the changes, a progress page is displayed.
Note that announcement_tone, if used, is played before the outgoing call attempt is made, and thus before the busy_tone.


[[File:RolePrimary2.png]]
Busy tone playback can also be configured in the Web Portal, from the incoming call's profile (under "Tones and Call Progress Options").
</br></br>


==Adding an 800 +1 Unit to an Existing Standalone==
Routing script has precedence over profile (a routing script that fills params[:bridge][:busy_tone] will override the profile's busy tone behavior).
----


{| class="wikitable"
Special value '''"none"''' can be used by routing script to force playing nothing (as empty string would default to profile's behavior)


|[[File:WarningIcon.png|100px]]|| This procedure will require some system downtime.
==== busy_tone options ====
|}
===== busy_tone_answer =====
  params[:bridge][:busy_tone_answer] = "yes"


Forces an answer of the call before playing the busy tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.


To add an 800 series +1 unit to an 800 series standalone unit, you must perform the following procedures:
=== disconnect_tone  ===
*[[AllynSandbox#Reconfigure a Standalone Unit as a Primary Unit in an 800 Series 1+1 System|Reconfigure a Standalone Unit as a Primary Unit in an 800 Series 1+1 System]]
  params[:bridge][:disconnect_tone] = "max_duration.wav"
*[[AllynSandbox#Install the 800 Series +1 unit on the Equipment Rack|Install the 800 Series +1 unit on the Equipment Rack]]
*[[AllynSandbox#Install the 1+1 Patch Panel|Install the 1+1 Patch Panel]]
*[[AllynSandbox#Connect to the 800 Series 1+1 Management Interface|Connect to the 800 Series 1+1 Management Interface]]
*[[AllynSandbox#Connect to the 800 Series 1+1 Control Network|Connect to the 800 Series 1+1 Control Network]]
*[[AllynSandbox#Connect to the 800 Series 1+1 VoIP Network(s)|Connect to the 800 Series 1+1 VoIP Network(s)]]
*[[AllynSandbox#Connect to the PSTN Network|Connect to the PSTN Network]]
*[[AllynSandbox#Power Up the Equipment|Power Up the Equipment]]
*[[AllynSandbox#Start Up|Start Up]]


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


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


</br></br>
Maximum call duration in millisecond. This timer is started when entering answer state.
===Reconfigure a Standalone Unit as a Primary Unit in an 800 Series 1+1 System===
----


1. Connect to the web portal of the standalone 800 series unit.
===== call_duration_reason  =====
  params[:bridge][:call_duration_reason] =&nbsp;:resource_unavailable


2. Select Hosts from the navigation panel.
Drop both legs with this reason when call duration (:max_call_duration) is reached.


[[File:RoleReset0.png]]
=== 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_C|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.


3. Select a host from the '''Host Configuration List'''.
=== 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.


[[File:RoleReset1.png]]
==== The default (replicated) prompts folder ====
By default, when playing a prompt, Toolpack will look in the default prompts folder:
/lib/tb/toolpack/pkg/prompts
The root of this "prompts" directory is automatically replicated to secondary unit of redundant setups (1+1, N+1, redundant hosts). Sub-folders won't be replicated.


Any prompt play request without explicit file path will map to this folder. For example:
  params[:bridge][:busy_tone] = "no_route.wav"
This will correspond to file /lib/tb/toolpack/pkg/prompts/no_route.wav


4. Select the '''Status''' tab.
==== Relative file paths ====
Any file path that begins with "file://" is considered relative to the tbstreamserver application's working directory:
/lib/tb/toolpack/setup/12358/2.8/apps/tbstreamserver/
(Where "2.8" may be replaced by the current major version of your system)


[[File:RoleReset2.png]]
For example:
  params[:bridge][:busy_tone] = "file://my_folder/no_route.wav"
This will correspond to file /lib/tb/toolpack/setup/12358/2.8/apps/tbstreamserver/my_folder/no_route.wav


==== Absolute file paths ====
Absolute paths can also be provided.
For example:
  params[:bridge][:busy_tone] = "file:///root/my_folder/no_route.wav"
This will correspond to file /root/my_folder/no_route.wav


5. Select '''Reset Host Role'''.
== 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.


[[File:RoleReset3.png]]
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:


6. Follow the instructions of the web portal to configure your unit as a primary unit in a new 800 series
  bridge[ :record_incoming ]  = ""
1+1 system.
</br></br>


===Install the 800 Series +1 unit on the Equipment Rack===
=== 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):
[[File:Icon_1+1.svg|60px|right]]


The 800 series +1 unit is mounted on a customer provided equipment rack using the mounting hardware packaged in the box. Refer to [[AllynSandbox#Rack Mounting the 800 Series Standalone or the 800 Series 1+1 System|Rack Mounting the 800 Series Standalone or the 800 Series 1+1 System]]
  # Need to clone the routes in order to have the right to modify them
</br></br>
  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


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


{| class="wikitable"
=== Choosing file path to record to  ===
|-
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.
| If you are installing an 800 series +1 unit, the associated one or two 1+1 patch panels will look like the image to the right. Refer to [[AllynSandbox#Connecting to the PSTN|Connecting to the PSTN]]
| [[File:8Pp.png|1500px]]
|}
</br></br>


===Connect to the 800 Series 1+1 Management Interface===
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/


The 800 series redundant management interfaces enables administrators to perform management tasks on the 800 series equipment. Connect each management interface to different Ethernet switches.
* 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:
** @{CURRENT_PKG}: Version of current package
*** Example: 2.6.45
** @{DATE format}: Prints the date, where 'format' is expressed as described for the 'strftime' function
*** Example: @{DATE %Y-%m-%d} => 2013-01-28
** @{DefaultName}: Replaced by the default file name for recording, which contains:
*** 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:    Calling number
*** Called:    Called number
*** Protocol:  Protocol type of this call (SS7, ISDN, CASR2, SIP)
*** Media info: Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
*** 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}:  Default recording folder and file name: "@{RECORD_PATH}/@{DATE %Y-%m-%d}/@{DefaultName}"
*** 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"
** @{Direction}: Direction of current leg (IN our OUT)
*** Example: IN
** @{LegId}: Current LegId (Unique Id for this leg)
*** Example: F3D67B4B
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: 73EBA698
** @{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
** @{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
** @{Protocol}: Protocol of current leg
*** Example: SS7
** @{RECORD_PATH}: Default recording folder: "@{TB_SETUP_HOME}/recorded_calls/"
** @{TBX_GW_PORT}: Current "System Id" (also called "Gateway Port")
*** Example: 12358
** 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]]


{| class="wikitable"
== Controlling UUI relay  ==
|-
UUI (user-to-user information) can be present in different messages received by either call leg during a call. For example, information can be carried during the initial invite, other information can be carried when the call is alerted, answered, or terminated.
| Follow the procedure described in [[AllynSandbox#Connecting to the 800 Series 1+1 System Management Interfaces|Connecting to the 800 Series 1+1 System Management Interfaces]]
| [[File:ManagementInterfaceThumbnail.png|1500px]]
|}
</br></br>


===Connect to the 800 Series 1+1 Control Network===
Routing scripts can control if the UUI received from one leg through the call will be forwarded to the other call leg:
----
*uui_forward_enabled


The 800 series and 800 series +1 units feature dual GigE ports to connect to the 800 series control network, which allows both units to communicate with each another.
Routing scripts can also read and modify the UUI received with the incoming call leg, before it gets forwarded upon creation of the outgoing call leg:
*uui


{| class="wikitable"
=== UUI (user-to-user indication) values  ===
|-
| Follow the procedure described in [[AllynSandbox#Connecting to the 800 Series 1+1 System Control Network|Connecting to the 800 Series 1+1 System Control Network]]
| [[File:EthernetControlNetwork.png|1500px]]
|}
</br></br>


===Connect to the 800 Series 1+1 VoIP Network(s)===
Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.
----


The 800 series and 800 series +1 units feature dual GigE ports for connection to different VoIP networks. This provides an access point to manage VoIP traffic. Should one of the IP networks fail, the 800 series 1+1 system will continue to manage VoIP traffic using the alternate network.
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.


{| class="wikitable"
Function each_byte can also be useful to iterate through all bytes of the UUI.
|-
| Follow the procedure described in [[AllynSandbox#Connecting to the 800 Series 1+1 System VoIP Network(s)|Connecting to the 800 Series 1+1 System VoIP Network(s)]]
| [[File:ConnToVoipThumbnail.png|1500px]]
|}
</br></br>
 
===Connect to the PSTN Network===
----
 
{| class="wikitable"
 
|[[File:NoteIcon.png|100px]]|| This section only applies to the TMG800 and TSG800.
|}
 
The 800 series gateways feature 8 T1/E1 interfaces for connection to the PSTN network.
 
{| class="wikitable"
|-
| Refer to [[AllynSandbox#Connecting to the PSTN in an 800 Series 1+1 System|Connecting to the PSTN in an 800 Series 1+1 System]]
| [[File:8T1E1Thumbnail.png|1500px]]
|}
</br></br>
 
===Power Up the Equipment===
----
 
The 800 series and 800 series +1 units are furnished with one (1) or two (2) AC or DC power connections. Only once all other equipment installation work has been completed should the 800 series 1+1 system be powered up. See ''Powering Up''.
</br></br>
 
===Start Up===
----
 
{| class="wikitable"
 
|[[File:NoteIcon.png|100px]]||To learn about the IP address for your system or how to change it, see [[AllynSandbox#Changing the 800 Series Gateway Management Port IP Address|Changing the 800 Series Gateway Management Port IP Address]]
|}
 
#Connect to the web portal of the 800 series 1+1 system. The Welcome page appears.
#Follow the instructions of the web portal to configure the Vlans.


[[File:RoleStandalone0.png]]
=== uui_forward_enabled values  ===


</br></br>
Controls forwarding or discarding of UUI to outgoing call leg.


==Verifying the LED Status Indications==
Values for this parameter are "0", "1", "false" or "true.
----
* 0/false: UUI is not forwarded between call legs
* 1/true: UUI is forwarded between call legs


'''Front of Unit'''
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.


When the equipment is powered, verify the front panel to determine that the LED indication is normal. Refer to the following table:
== 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.


{| class="wikitable"
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:
|+ 800 Series Units LED Status
|-
! LED !! Description
|-
|Green - Steady
|Ready
|-
|Green - Blinking
|Starting up
Shutting down
|-
|Orange - Steady
|Shutdown (stopped)
|-
|Red - Blinking
|Fault condition
|}


{| class="wikitable"
* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
|[[File:NoteIcon.png|100px]]|| An alarm will sound if one of the power supplies is faulty. There is no alarm button to disable the alarm. To stop the alarm, you must remove the faulty power supply.
* ''challenge'': The authorization was challenged.
|}
* ''timeout'': The authorization was not answered.


[[File:FrontLeds.png]]
== ENUM Query ==
</br></br>
Starting with release 3.1, it is possible to issue ENUM Query requests to DNS servers from routing scripts. To do so, the params[:enum_query] object must be filled with the required ENUM Query attributes params[:enum_query][:fqdn] and [[#Refuse|an exception must be raised]] with reason :enum_query_required.


==Powering Down==
When ENUM Query completes, the routing script is called again with the result. The params[:enum_query] object will be filled with the ENUM Query attributes from the response. The params[:enum_query][:result] field will also contain a string indicating the result of the ENUM Query:
----
[[File:Icon_StandAlone_1+1.svg|75px|right]]


The 800 series 1+1 can be turned off using either the management port or the power button.
* ''ok'': The ENUM Query was successful.
* ''timeout'': The ENUM Query was not answered.


</br></br>
The params[:enum_query][:responses_list] field will contain a list of hash responses for each NAPTR records.
===Management Port===
----


To shut down the unit using the management port, connect to the management interface using SSH, and enter:
NAPTR records contain:
* '':uri''
* '':order''
* '':preference''
Example:
<code>
  params[:enum_query][:responses_list]
    [{:order=>"200", :preference=>"10", :uri=>"!^03111.*$!sip:123456782@example-2.com!"},
    {:order=>"100", :preference=>"1", :uri=>"!^03222.*$!sip:123456782@example-3.com!"},
    {:order=>"200", :preference=>"1", :uri=>"!^03111.*$!sip:123456782@example-1.com!"}]
</code>


'''shutdown -hP now'''
Using enum_called_remap.rb before filter script allows handling of ENUM query requests/responses. The match and replace regular expression from ENUM query responses are applied to params[:call][:called] to get "new called". This script allows update of the call parameters according to "new called" value. Refer to enum_called_remap.rb before filter script to get instructions on how to integrate this script into the main routing script (i.e. simple_routing_sbc.rb):


{| class="wikitable"
<code>
  ...
  require 'enum_called_remap' unless defined?(EnumCalledRemap)
  ...
  include EnumCalledRemap
  ...
  before_filter :method => :enum_called_remap
  ...
</code>


|[[File:NoteIcon.png|300px]]|| '''DO NOT TURN OFF''' the power to the 800 series gateway unless you have already performed the previously mentioned shut down procedure. Allow a minimum of 1 minute time for the VoIP gateway to shut down before turning off the power. Be aware that the shutdown procedure of the unit is logged and traceable for support and warranty purposes.
=== Resolve ENUM Query down to type A records ===
|}
</br></br>


===Power Button===
The ENUM query could also resolve uri from responses and get matching outgoing NAP, NAP proxy IP and port through a sequence of DNS queries (i.e. NAPTR, SRV down to type A records). This behavior could be requested using "dns_query" parameter:
----


To shut down the unit, press and hold the front power button for one second.
<code>
  params[:enum_query][:dns_query] = true
</code>


[[File:TurnOffUnit.png|1500]]
When ENUM and DNS Queries complete, the routing script is called again with the results. The params[:enum_query] and params[:dns_query] objects will be filled with the ENUM Query and the DNS Query attributes from the responses. The DNS query responses are available through params[:dns_query][:responses_list] call parameters:
</br></br>


=Initial System Configuration=
<code>
----
  params[:dns_query][:responses_list]
    [{:nap=>"NAP_UDP", :nap_proxy_ip=>"10.3.14.191", :nap_proxy_port=>"8080", :transport=>"UDP", :order=>"100",
      :preference=>"1", :priority=>"0", :weight=>"5"},
    {:nap=>"NAP_TCP", :nap_proxy_ip=>"10.3.14.192", :nap_proxy_port=>"8081", :transport=>"TCP", :order=>"100",
      :preference=>"2", :priority=>"1", :weight=>"10"}]
</code>


This section provides information about the following topics:
=== Add dynamic routes ===
*[[AllynSandbox#Series Gateway SSH Connection|Series Gateway SSH Connection]]
*[[AllynSandbox#800 Series Gateway Serial Connection|800 Series Gateway Serial Connection]]
*[[AllynSandbox#Changing 800 Series Gateway Management Port Passwords|Changing 800 Series Gateway Management Port Passwords]]
*[[AllynSandbox#Retrieving 800 Series Gateway Information|Retrieving 800 Series Gateway Information]]
*[[AllynSandbox#Changing the 800 Series Gateway Management Port IP Address|Changing the 800 Series Gateway Management Port IP Address]]
*[[AllynSandbox#Setting the Time Zone|Setting the Time Zone]]
*[[AllynSandbox#Configuring the 800 Series Gateway Using the Web Portal|Configuring the 800 Series Gateway Using the Web Portal]]
*[[AllynSandbox#Changing VoIP Interface Addresses|Changing VoIP Interface Addresses]]
</br></br>
==Series Gateway SSH Connection==
----
[[File:Icon_StandAlone_1+1.svg|75px|right]]


The 800 Series Gateway is shipped with the TMG-CTRL software preinstalled. To make changes to the system configuration, you must connect the port labeled MGMT0 at the rear of the 800 Series Gateway to a terminal.
The ENUM query could also add dynamic routes base on DNS query responses. This could be requested using the "add_dynamic_routes" call parameter:


<code>
  params[:enum_query][:dns_query] = true
  params[:enum_query][:add_dynamic_routes] = true
</code>


To access the 800 series gateway, you must use an SSH connection. The password is set at the factory and is indicated on the shipment sheet.
Note that it is mandatary to send DNS query to add dynamic routes.


[[File:TmediaManagementInt.png]]
The "base_routing.rb" script version should be greater then 1.37 in order to allow dynamic routes creation base on DNS query responses.
</br></br>
==800 Series Gateway Serial Connection==
----
</br></br>
===Physical Connection===
----
[[File:Icon_StandAlone_1+1.svg|75px|right]]


Two types of serial connection are possible:
When requesting to add_dynamic_routes, the dns_query responses are used to create routes. Make sure that your configuration includes a route with remapped_nap = "Registered or DNS users". A route will be created for each DNS query responses. The routes "remapped_nap" takes NAP value from DNS query responses.
*''Connecting to the USB Port of the 800 Series Gateway''.
*''Connecting to the Serial Port of the 800 Series Gateway''.
</br></br>
====Connecting to the USB Port of the 800 Series Gateway====
----
[[File:Icon_StandAlone_1+1.svg|75px|right]]
The Type B USB serial port interface enables administrators to perform management tasks on the 800 series gateway.


It is required to modify main routing script (i.e. simple_routing_sbc.rb) to forward IP/port values from params[:routes] to params[:call] like we are doing for NAP. See following example:


'''To connect to the Type B USB serial port of an 800 series gateway:'''
<code>
#Connect the Type A USB connector of the USB cable to a computer.
  ...
#Connect the Type B USB connector of the USB cable to the USB port of the 800 Series gateway.
  # This will select the outgoing NAP for this call according to the "remapped_nap" route parameter
  route_remap :call_field_name => :nap, :route_field_name => :remapped_nap
 
  # This will select the outgoing NAP proxy ip address for this call according to the "remapped_nap_proxy_ip" route parameter
  route_remap :call_field_name => :nap_proxy_ip, :route_field_name => :remapped_nap_proxy_ip
 
  # This will select the outgoing NAP proxy port for this call according to the "remapped_nap_proxy_port" route parameter
  route_remap :call_field_name => :nap_proxy_port, :route_field_name => :remapped_nap_proxy_port
  ...
</code>


== DNS Query ==
Similarly to ENUM query, starting with release 3.1, it is possible to issue DNS Query requests to DNS servers from routing scripts. This could be used to skip the ENUM Query part when the called uri is already known but still need to get the matching outgoing NAP, NAP proxy IP and port. To do so, the params[:dns_query] object must be filled with the required DNS Query attributes params[:dns_query][:fqdn] and [[#Refuse|an exception must be raised]] with reason :dns_query_required.


'''USB cable connection'''
When DNS Query completes, the routing script is called again with the result. The params[:dns_query] object will be filled with the DNS Query attributes from the responses. The DNS query responses are available through params[:dns_query][:responses_list] call parameters:
[[File:TypebUsb.png]]
</br></br>


====Connecting to the Serial Port of the 800 Series Gateway====
<code>
----
  params[:dns_query][:responses_list]
    [{:nap=>"NAP_UDP", :nap_proxy_ip=>"10.3.14.191", :nap_proxy_port=>"8080", :transport=>"UDP", :order=>"100",
      :preference=>"1", :priority=>"0", :weight=>"5"},
    {:nap=>"NAP_TCP", :nap_proxy_ip=>"10.3.14.192", :nap_proxy_port=>"8081", :transport=>"TCP", :order=>"100",
      :preference=>"2", :priority=>"1", :weight=>"10"}]
</code>


{| class="wikitable"
=== Add dynamic routes ===


|[[File:NoteIcon.png|100px]]|| The default IP addresses for the management ports are located in the “Important Notice” sheet received with the shipment. MGMT ports are configured in bonding.
Similarly to ENUM Query, the DNS query could also create dynamic routes base on DNS query responses. This could be requested using the "add_dynamic_routes" call parameter:


<code>
  params[:dns_query][:add_dynamic_routes] = true
</code>


If you do not know the default IP address, see [[AllynSandbox#Changing the 800 Series Gateway Management Port IP Address|Changing the 800 Series Gateway Management Port IP Address]].
The "base_routing.rb" script version should be greater then 1.37 in order to allow dynamic routes creation base on DNS query responses.
|}


The serial port interface enables administrators to perform management tasks on the 800 series gateway.
When requesting to add_dynamic_routes, the dns_query responses are used to create routes. Make sure that your configuration include a route with remapped_nap = "Registered or DNS users". A route will be created for each DNS query responses. The routes "remapped_nap" takes NAP value from DNS query responses.


It is required to modify main routing script (i.e. simple_routing_sbc.rb) to forward IP/port values from params[:routes] to params[:call] like we are doing for NAP. See following example:


'''To connect to the serial port of an 800 series gateway:'''
<code>
#Connect one end of a CAT5 RJ-45 (male-male) cable to the Tmedia serial adapter (both supplied with unit). Connect the DB9 to RJ-45 to the serial port of the computer and the other end of the CAT5 RJ-45 (male-male) cable to the serial port (labeled 10101) of the 800 series gateway. See [[AllynSandbox#Wiring Diagrams|Tmedia Serial Adapter Wiring Diagram]], for a RJ-45 pin out description.
  ...
#If your computer’s serial port features a DB9 connector, use the Tmedia serial adapter supplied with your 800 series gateway. If your computer's serial port features a USB connector, you will need to provide a USB to DB9 adapter.
  # This will select the outgoing NAP for this call according to the "remapped_nap" route parameter
  route_remap :call_field_name => :nap, :route_field_name => :remapped_nap
 
  # This will select the outgoing NAP proxy ip address for this call according to the "remapped_nap_proxy_ip" route parameter
  route_remap :call_field_name => :nap_proxy_ip, :route_field_name => :remapped_nap_proxy_ip
 
  # This will select the outgoing NAP proxy port for this call according to the "remapped_nap_proxy_port" route parameter
  route_remap :call_field_name => :nap_proxy_port, :route_field_name => :remapped_nap_proxy_port
  ...
</code>


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


'''Computer to 800 Series Gateway Serial Port Connection'''
Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]
[[File:SerialConnectionPcMod.png]]


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 ] = "0,1,2"
or
  bridge[ :diversion_reason ] = "unknown,busy,no_reply"
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.


'''Conceptual View of a Serial Connection from the 800 Series Gateway to a Computer'''
See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number,_Original_Called_Number_and_Diversion_Reason|Redirecting number reason values]].
[[File:Db9ToUsb.png]]


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


===Configuring the Terminal Emulator Application===
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).
----


Before communicating with the management interface, you must first configure a terminal emulator or console application to communicate with the 800 series system in order to configure initial settings.
=== 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...


'''Available terminal emulation software includes:'''
=== params[ :call ] content during transfer request ===
*SecureCRT
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)
*Putty
call = params[ :call ]          -> Information from original inbound call, with exception of call[ :called ]
*Minicom


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)


'''To configure the terminal emulator application:'''
These fields will also be included in the outgoing call made after routing:
#Set the baud rate (bits per second) to '''9600'''
* original called number and redirecting number are existing fields on SS7 and ISDN calls
#Set the data rate to '''8 bits'''
* SIP "diversion" header is used for SIP calls
#Set the parity to '''None'''
#Set the stop bits to '''1'''
#Set the flow control to '''None'''


=== params[ :transfer ] content ===
(this if valid only for release 2.7.102 and above)<br>
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


{| class="wikitable"
These fields are 'read-only'. They will not be included in the outgoing call, as they represent the contents of the call transfer request, and not the outgoing call to be made.


|[[File:NoteIcon.png|100px]]|| See [[AllynSandbox#Changing the 800 Series Gateway Management Port IP Address|Changing the 800 Series Gateway Management Port IP Address]], to learn how to change the IP address of the MGMT0 port.
To insert/modify attributes of the outgoing call, the parameters from params[ :call ] must be edited instead.
|}
</br></br>
 
==Changing 800 Series Gateway Management Port Passwords==
----


{| class="wikitable"
== Redirection ==
In release 2.8 and above, redirection contacts are obtained from the routing engine in the following format:


|[[File:NoteIcon.png|100px]]|| The following procedure must be performed on the 800 series standalone unit and the 800 series 1+1 system.
  contacts = params[ :contacts ]
|}
  contacts = {
      :index=>"3",
      :list=>[
        {:called_number=>"6660", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"", :raw_data=>"", :expiration=>"3600"},
        {:called_number=>"6661", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"sip:6661@192.168.215.127", :raw_data=>"<sip:6661@192.168.215.127>", :expiration=>"3600"}
        {:called_number=>"6662", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"sip:6662@192.168.215.128", :raw_data=>"<sip:6662@192.168.215.128>", :expiration=>"3600"},
        {:called_number=>"6663", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"sip:6663@192.168.215.129", :raw_data=>"<sip:6663@192.168.215.129>", :expiration=>"3600"},
        {:called_number=>"6664", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"sip:6664@192.168.215.150", :raw_data=>"<sip:6664@192.168.215.150>", :expiration=>"3600"}
      ],
      :source_indexes=>"nil,0,0,0,2"
  }


* <code>params[:contacts][:list]</code> contains the contact log. Each contact within the list has the following fields:
** <code>:called_number</code> - the called number
** <code>:is_number_ported</code> - if the called number has been ported (for SIP: if the npdi parameter is present)
** <code>:ported_number</code> - the called number that was ported (for SIP: the rn parameter value, if available)
** <code>:sip_uri</code> - the SIP URI of the contact, without the contact-params section (without the expires and q contact parameters)
** <code>:raw_data</code> - the raw data representing the contact in the signaling protocol. For SIP, this is the full SIP URI (including the expires and q contact parameters).
** <code>:priority</code> - the priority of the contact [0-1000]
** <code>:expiration</code> - the expiration time in seconds of the contact
* <code>params[:contacts][:index]</code> contains the index of the contact that is currently being routed.
* <code>params[:contacts][:source_indexes]</code> contains a comma-separated list of indexes from <code>params[:contacts][:list]</code>. Each index represents the contact from which the contact in the list was obtained from.


Once logged onto the 800 series gateway, type “passwd”, to change the password. The following information will be displayed:


To get more information, see:
*[[Routing_script_tutorial:SIP_Redirection_Contacts|SIP Redirection Contacts Parameters in a Call Flow]]


[root@TB003540 ~]# passwd
Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
</br></br>


==Retrieving 800 Series Gateway Information==
== Connected number ==
----
Insert a connected number in the answer message of the call flow.


The 800 series gateway enables you to retrieve system information with the following shell commands:
Routing script example:
    bridge = params[ :bridge ]
    bridge [ :connected_number ] = "3335577"
    bridge [ :connected_number_noa ] = :national_number
    bridge [ :connected_number_npi ] = :private
    bridge [ :connected_number_presentation ] = :allowed
    bridge [ :connected_number_screening ] = :pass


*tbinfo (retrieve the 800 series gateway product type). See [[TMG:Get_Product_Type]].
== Terminating calls ==
*tbserial (retrieve the 800 series gateway serial number). See [[TMG:Get_Serial_Number]].
In release 2.8, it is now possible to terminate a call through the routing scripts. The [[#Reason values|reason code]] must be specified in <code>params[:bridge][:reason]</code>. The <code>:terminate</code> hash must be created and copied into <code>params</code>:
</br></br>
  terminate = {}
  params[:terminate] = terminate
The following fields can then be set in <code>:terminate</code>:
* <code>:sip_header</code>
* <code>:contacts</code> # list of contacts as described in the [[#Redirection|redirection]] section
* <code>:isup_raw</code>
* <code>:isup_raw_variant</code>
* <code>:redirecting_number</code>
* <code>:redirecting_number_noa</code>
* <code>:redirecting_number_npi</code>
* <code>:redirecting_number_presentation</code>
* <code>:redirecting_number_reason</code>
* <code>:redirecting_number_counter</code>
* <code>:redirecting_number_indicator</code>
* <code>:original_called_number</code>
* <code>:original_called_number_noa</code>
* <code>:original_called_number_npi</code>
* <code>:original_called_number_presentation</code>
* <code>:original_called_number_reason</code>
* <code>:original_called_number_counter</code>


==Changing the 800 Series Gateway Management Port IP Address==
== Reason values  ==
----
[[File:Icon_StandAlone_1+1.svg|75px|right]]


{| class="wikitable"
Check here for Termination Reason Cause codes:<br>


|[[File:NoteIcon.png|100px]]|| The following procedure must be performed on the 800 series standalone and the 800 series 1+1 system.
[[Termination_cause_codes|Termination Reason Cause codes]]
|}
<br>


Each 800 series gateway has two management ports (mgmt0 and mgmt1). They are configured in bonding by default and the values are located on the “Important Notice” sheet.
Example to refuse an incoming call leg.
  raise RoutingException, :no_route


Reason cause strings available inside routing scripts:


It can be modified using the following shell script:
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
  :qor_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
  :requested_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
  :message_not_compatible_with_call_state
  :ie_non_existent
  :invalid_ie_content
  :msg_not_compatible_with_call_state
  :recovery_on_timer_expiry
  :parameter_non_existent_passed_on
  :message_with_non_recognized_parameters_discarded
  :protocol_error
  :interworking_unspecified


'''tbchangeip'''
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


{| class="wikitable"
List of SIP reason causes:<br/>
Reason causes starting with a digit must use the following syntax (can't use : as prefix).


|[[File:NoteIcon.png|100px]]
  '300_multiple_choices'
| If you do not have the “Important Notice” sheet, the default IP address and netmask are set as follows:
  '301_moved_permanently'
*IP address: 172.24.0.2
  '302_moved_temporarily'
*Netmask: 255.255.255.0
  '305_use_proxy'
|}
  '380_alternative_service'
</br></br>
  '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'


==Setting the Time Zone==
== NAP status and other NAP information ==
----


{| class="wikitable"
All the status fields of the NAPs are provided for use by the routing scripts.
''<br> For developpers: see the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.''


|[[File:NoteIcon.png|100px]]|| The following procedure must be performed on the 800 series standalone unit and the 800 series 1+1 system.
'''Notice:''' These values may change between major release.  
|}


You can change the time zone of the 800 series gateway using the following shell command:
  Routing script call attribute name    Description
  --------------------------------------------------------------------------------------------
  "name"                                NAP name.
  "signaling_type"                      Signaling type (SS7, ISDN, CASR2, SIP)
  "profile"                            Profile name.
  "sip_destination_ip"                  Destination IP address.
  "sip_destination_port"                Destination IP port.
  "sip_transport_type"                  SIP transport type (:udp, :tcp, or :tls) (Toolpack 3.1 and more)
  "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.
  "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.
  "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
  "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
  "asr_stats_incoming_struct"          Detailed Answer-Seizure Rate incoming statistics.
  {
    "global_asr_percent"                Global calculated ASR percentage.
    "total_call_cnt"                    Total count of calls.
    "total_accepted_call_cnt"          Total count of accepted calls (not dropped due to congestion or rate-limiting).
    "total_answered_call_cnt"          Total count of answered calls.
    "last_24h_asr_percent"              Last 24 hours calculated ASR percentage.
    "last_24h_call_cnt"                Last 24 hours count of calls.
    "current_hour_asr_percent"          Current hour calculated ASR percentage.
    "current_hour_call_cnt"            Current hour count of calls.
    "last_hour_asr_percent"            Last hour calculated ASR percentage.
    "last_hour_call_cnt"                Last hour count of calls.
  }
  "asr_stats_outgoing_struct"          Detailed Answer-Seizure Rate outgoing statistics.
  {
    "global_asr_percent"                Global calculated ASR percentage.
    "total_call_cnt"                    Total count of calls.
    "total_accepted_call_cnt"          Total count of accepted calls (not dropped due to congestion or rate-limiting).
    "total_answered_call_cnt"          Total count of answered calls.
    "last_24h_asr_percent"              Last 24 hours calculated ASR percentage.
    "last_24h_call_cnt"                Last 24 hours count of calls.
    "current_hour_asr_percent"          Current hour calculated ASR percentage.
    "current_hour_call_cnt"            Current hour count of calls.
    "last_hour_asr_percent"            Last hour calculated ASR percentage.
    "last_hour_call_cnt"                Last hour count of calls.
  }
  "mos_struct"                          Detailed Mean Opinion Score statistics.
  {
    "last_24h_ingress"                  Last 24 hours calculated MOS for incoming RTP packets.
    "last_24h_egress"                  Last 24 hours calculated MOS for outgoing RTP packets.
    "current_hour_ingress"              Current hour calculated MOS for incoming RTP packets.
    "current_hour_egress"              Current hour calculated MOS for outgoing RTP packets.
    "last_hour_ingress"                Last hour calculated MOS for incoming RTP packets.
    "last_hour_egress"                  Last hour calculated MOS for outgoing RTP packets.
  }
  "network_quality_struct"              Detailed network quality statistics.
  {
    "last_24h_ingress"                  Last 24 hours network quality percentage for incoming RTP packets.
    "last_24h_egress"                  Last 24 hours network quality percentage for outgoing RTP packets.
    "current_hour_ingress"              Current hour network quality percentage for incoming RTP packets.
    "current_hour_egress"              Current hour network quality percentage for outgoing RTP packets.
    "last_hour_ingress"                Last hour network quality percentage for incoming RTP packets.
    "last_hour_egress"                  Last hour network quality percentage for outgoing RTP packets.
  }
 
<br> The nap status is part of a substructure and will be a hash containing all subfield elements.


'''tbtimezone'''
=== Example to access NAP information and NAP status of the current call ===
</br></br>
<br> To find the incoming nap in a routing script, we can do this in before_filter or after_filter and use these lines to create a symbol:
    incoming_nap = params[:call][:nap].to_sym
    log_trace 1, "incoming_nap = " + incoming_nap.inspect


==Configuring the 800 Series Gateway Using the Web Portal==
<br> To get the configured NAP list, you can do this:
----
    nap_lists = params[:naps]
    log_trace 1, "nap_lists = " + nap_lists.inspect


{| class="wikitable"
<br> From the list above, you can find how many calls you have on this NAP:
    log_trace 1,"Incoming NAP call count=" + nap_lists[incoming_nap][:asr_stats_incoming_struct][:total_call_cnt].inspect
<br> Or which network the call is coming from:
    log_trace 1,"Incoming NAP signaling type=" + nap_lists[incoming_nap][:signaling_type].inspect


|[[File:NoteIcon.png|100px]]|| The first time that you connect to the web portal, you will need to configure the role of the 800 series unit.
<br> If you are using a "NAP Columns" custom parameter (Create New NAP Column), you can get the information (since incoming_nap is a symbol):
    network_type = nap_lists[incoming_nap][:network_type]
    log_trace 1, "For incoming_nap = " + incoming_nap.inspect + " network_type is: " + network_type.inspect


<br> If you want to modify something according to nap information, you may need to do a loop like this:
    nap_lists.each do |nap_list,nap_info|
      log_trace 1, "NAP: " + nap_info[:name].inspect + " network_type: " + nap_info[:network_type].inspect
    end


If your system features an 800 series standalone unit, ''Start Up''.
== Telephony Services ==
In release 2.10 and the above, telephony services (CNAM Request) can be manage from the routing engine in the following format:


  params[:telephony_services].each do |service|  -> Array of telephony services
    service[:name]                              -> Customer telephony service name
    service[:type]                              -> For now only "CNAM Request"
    service[:enabled]                            -> Indicate if the service is enabled (true) or not (false)
                                                    (Only the telephony service define in the profile associated to the NAP is enabled)
                                                    (The others telephony services define in others profiles are disabled)
                                                    (If we are in the case where we return in the routing script with a response, it is important to set :enabled to false in order to avoid repeating the same query)
    serviceParams = service[:params]
    serviceParams[:return_to_script]            -> Indicates to Gateway if we must return to the routing script after receiving the CNAM response
                                                    (It is important to set back to false this field to avoid an infinite loop)
    serviceQuery = service[:query]
    serviceQuery[:phone]                        -> 10 digits of calling number from the incoming call to send to the CNAM server
    serviceQuery[:timeout]                      -> Timeout in millisecond to wait a CNAM response from CNAM server
                                                    (Default value from profile configuration)
    serviceResponse = service[:response]
    serviceResponse[:success]                    -> Indicates if we received a good CNAM response from the CNAM Server (Only present if :return_to_script is set to true)
    serviceResponse[:caller_name]                -> The caller name received in the CNAM response from the CNAM Server (Only present if :return_to_script is set to true)


If your system features an 800 series unit working in conjunction with an 800 series +1, refer to ''Start Up''.
== Custom user context ==
|}
The routing script may '''save per-call information within the call context''', that will be available if routing is called again later during the call flow.


Cases where routing is called multiple times for the same call are:
- Call transfer requests
- SIP redirect requests
- Radius Authorization result
- Announcement server with digit collection


To change the default configuration of an 800 series gateway using the Web Portal, follow the steps described in the [[Tmedia_Configuration|Web Portal System Configuration Tutorial Guide]].
The routing script can save a recursive hash of attributes here:
  params[:user_context]


For example
  params[:user_context] = { "SomeKey" => "Some value I want to retrieve upon next routing for this call", "OtherVal" => { "subkey" => "subval" } }


The Web Portal can be accessed with a Web browser. The default URL is: '''http://[Tmedia MGMT0 IP address]:12358'''
Upon first call to routing script, params[:user_context] will be nil.
Upon subsequent calls to routing script, it will contain whatever the script had stored upon previous call (or nil if it was not set)


{| class="wikitable"
Note: This feature is available starting from release 2.9.85, 2.10.31 and 3.0.15 (in respective branches 2.9, 2.10 or 3.0)


|[[File:NoteIcon.png|100px]]|| The 800 series and 800 series +1 units can access the Web Portal from either one of their IP addresses.
== 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.


The default login information to access the Web Portal application is:
=== Test parameters ===
*Username: root
==== @call_params  ====
*Password: root


</br></br>
That variable should contain a hash of call parameters that will be passed to the routing script. This is equivalent to the incoming call parameters.


==Changing VoIP Interface Addresses==
<br>  
----
The default address of the VoIP interfaces of the 800 series gateway can be modified. To learn how this is done, refer to the ''Web Portal tutorial guide on the Telcobridges TB Wiki at docs.telcobridges.com''.
</br></br>


=System Backups=
==== @nap_list  ====
----
[[File:Icon_StandAlone_1+1.svg|75px|right]]


This section provides information about the following topics:
A list of the hash containing the nap statuses. This is equivalent to the nap statuses at the time the call is to be routed.  
*''Creating a Database Backup''
*''Downloading a Database Backup''
*''Uploading a Database Backup''
*''Restoring a Database Backup''
</br></br>
==Creating a Database Backup==
----
It is important that backups be made of system configuration settings in the event of a system failure. It is recommended that a backup be made once the system has been configured. Backups are performed using the web portal.
</br></br>


==Downloading a Database Backup==
'''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.  
----
A backup of system data is stored on the hard drive of the 800 series gateway. It is important that system backups be downloaded to an external storage device.
</br></br>


==Uploading a Database Backup==
<br>  
----
An external backup of your database can be uploaded to your 800 series gateway.
</br></br>


==Restoring a Database Backup==
==== @params  ====
----
In the event of a system failure requiring the replacement of an 800 series gateway, a previously saved backup of system settings can be restored to the new unit.
</br></br>


=Wiring Diagrams=
A hash of hashes containing parameters. This hash contains bridge parameters and other kind of parameter groups may be added in the future.  
----
</br></br>
==RJ48C Wiring Diagram: Crossover and Straight Cables==
----
[[File:Rj48cWiringSchematic.png]]
</br></br>


==Tmedia Serial Adapter Wiring Diagram==
  @params = {
----
    :bridge => {:announcement_tone, "announcement.wav"},
[[File:ConsolePinout.png]]
    :contacts => {
</br></br>
      :index=>"1",
      :list=>[
          {:called_number=>"6660", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"",
          :raw_data=>"", :expiration=>"3600"},
          {:called_number=>"6661", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"sip:6661@192.168.215.127",
          :raw_data=>"<sip:6661@192.168.215.127>", :expiration=>"3600"}
      ],
      :source_indexes=>"nil,0"
    }
  }

Latest revision as of 12:06, 29 March 2024

Original Table code

Script parameter name _____ISDN_____
 		__R2_CAS__
 ______________SS7___________
 		_____________SIP_____________
 		Comment
 		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
original_session_id
 N/A
 N/A
 N/A
 N/A
 Original Session ID (before call transfer or redirections)
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_sip_host
N/A
 N/A
 N/A
 SIP:From - host (domain or IP)
For example : The 'telcobridges.com' in From: "Cullen Jennings" <sip:fluffy@telcobridges.com>

calling_sip_port
N/A
 N/A
 N/A
 SIP:From - port
For example : The '6060' in From: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060>

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

ITU97: 'Display information' IE - display information ANSI95: 'Generic name' 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

 For example : The 'fluffy' in P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>

private_address_sip_host
N/A
 N/A
 N/A

SIP:P-asserted-identity - host (domain or IP)

SIP:Remote-party-id - host (domain or IP)

For example : The 'telcobridges.com' in P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>

private_address_sip_port
N/A
 N/A
 N/A

SIP:P-asserted-identity - port

SIP:Remote-party-id - port

 For example : The '6060' in P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060>

supp_private_address_forward_enabled
N/A
 N/A
 N/A
 N/A
 Overwrite default supplementary/second P-Asserted-Identity header forwarding behavior from incoming to outgoing leg

supp_private_address
 N/A
 N/A
 N/A

SIP:P-Asserted-Identity - userinfo

For example : The 'fluffy' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>

supp_private_address_display_name
 N/A
 N/A
 N/A

SIP:P-Asserted-Identity - display name

For example : The 'Cullen Jennings' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>

supp_private_address_sip_host
N/A
 N/A
 N/A

SIP:P-Asserted-Identity - host (domain or IP)

For example : The 'telcobridges.com' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>

supp_private_address_sip_port
N/A
 N/A
 N/A

SIP:P-Asserted-Identity - port

For example : The '6060' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060>

preferred_id_forward_enabled
N/A
 N/A
 N/A
 N/A
 Overwrite default P-Preferred-Identity header forwarding behavior from incoming to outgoing leg

preferred_id
 N/A
 N/A
 N/A

SIP:P-Preferred-Identity - userinfo

For example : The 'fluffy' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>

preferred_id_display_name
 N/A
 N/A
 N/A

SIP:P-Preferred-Identity - display name

For example : The 'Cullen Jennings' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>

preferred_id_sip_host
N/A
 N/A
 N/A

SIP:P-Preferred-Identity - host (domain or IP)

For example : The 'telcobridges.com' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>

preferred_id_sip_port
N/A
 N/A
 N/A

SIP:P-Preferred-Identity - port

For example : The '6060' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060>

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_sip_host
N/A
 N/A
 N/A
 SIP:To - host
For example : The 'telcobridges.com' in To: "Cullen Jennings" <sip:fluffy@telcobridges.com>

called_sip_port
N/A
 N/A
 N/A
 SIP:To - port number
For example : The '6060' in To: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060>

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_npdi
N/A
 N/A
 Q763: 'Generic number' IE - with qualifier=Ported number is present
 SIP:RequestURI - npdi=yes is present
 Only valid if SIP/SS7 supports LNP
ported_number
N/A
 N/A
 Q763: 'Generic number' IE - address signals with qualifier=Ported number
 SIP:RequestURI - to user part when rn is present
 rn is stored in the called number
ported_number_noa
N/A
 N/A
 Q763: 'Generic number' IE - nature of address indicator with qualifier=Ported number
 N/A
 Only valid if SIP/SS7 supports LNP
ported_number_npi
N/A
 N/A
 Q763: 'Generic number' IE - numbering plan indicator with qualifier=Ported number
 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 'Enable SIP 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
 A script needs to set this to true if it wants to overwrite MLPP information in the outgoing leg. Otherwise, profile relay 'outgoing mode' applies automatically.
 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
isub_forward_enabled
N/A
 N/A
 N/A
 N/A
 Overwrite default ISUB forwarding behavior from incoming to outgoing leg
3.0.138
called_isub
Q931: 'Called party subaddress' IE - subaddress information
 N/A
 Q763: 'Access transport' IE
 SIP:To - isub parameter
2.7
called_isub_type
 Q931: 'Called party subaddress' IE - type of subaddress
 N/A
 Q763: 'Access transport' IE
 SIP:To - isub-encoding parameter
2.7
calling_isub
Q931: 'Calling party subaddress' IE - subaddress information
 N/A
 Q763: 'Access transport' IE
 SIP:From - isub
2.7
calling_isub_type
 Q931: 'Calling party subaddress' IE - type of subaddress
 N/A
 Q763: 'Access transport' IE
 SIP:From - isub-encoding
2.7
ss7_fci_default
N/A
 N/A
 Default forward 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_forward_enabled
 N/A
 N/A
 N/A
 N/A
 Enable line service and timeslot selection to create the outgoing leg. tdm_ls_name and tdm_timeslot_nb must be defined along with tdm_ls_name_forward_enabled
 3.0
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
 if tdm_ls_name_forward_enabled is set, try to use this line service name to create outgoing leg
 2.7
tdm_timeslot_nb
 Incoming leg timeslot number
 Incoming leg timeslot number
 Incoming leg timeslot number
 N/A
 if tdm_ls_name_forward_enabled is set, try to use this timeslot number to create outgoing leg
 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
ss7_cot_enabled
N/A
 N/A
 Requests SS7 in-call continuity test for this outgoing SS7 call
 N/A
 Toolpack will request a continuity test on the timeslot before making the outgoing call. If COT fails, the call will be dropped (then another route may be attempted)
 2.8
reverse_charging_indication
 Incoming leg Reverse charging indication IE present
 N/A
 N/A
 N/A
 If set in routing script, will add Reverse charging indication IE in outgoing leg (also use reverse_charging_indication_forward_enabled)
 2.8.12
reverse_charging_indication_forward_enabled
 N/A
 N/A
 N/A
 N/A
 Enable forwarding of reverse charging indication from incoming to outgoing leg
 2.8.12
sip_call_id
 N/A
 N/A
 N/A
 Incoming leg SIP Call-Id
 (read-only)
 2.9.112 / 3.0.131
sip_local_addr
 N/A
 N/A
 N/A
 Incoming leg local SIP IP address
 (read-only)
 2.8.13
sip_local_port
 N/A
 N/A
 N/A
 Incoming leg local SIP port
 (read-only)
 2.8.13
sip_remote_addr
 N/A
 N/A
 N/A
 Incoming leg remote SIP IP address
 (read-only)
 2.8.13
sip_remote_port
 N/A
 N/A
 N/A
 Incoming leg remote SIP port
 (read-only)
 2.8.13
acli
 N/A
 N/A
 'Additional Calling Party Information' IE - address signals.

A new ISUP parameter is defined under national option to carry the actual calling party number of the ported subscriber (N2) in the IAM message across the Network.

 N/A
 (read-only)
 3.0.143.2
acli_nao
 N/A
 N/A
 'Additional Calling Party Information' IE - nature of address indicator.

A new ISUP parameter is defined under national option to carry the actual calling party number of the ported subscriber (N2) in the IAM message across the Network.

 N/A
 (read-only)
 3.0.143.2
acli_npi
 N/A
 N/A
 'Additional Calling Party Information' IE - numbering plan indicator.

A new ISUP parameter is defined under national option to carry the actual calling party number of the ported subscriber (N2) in the IAM message across the Network.

 N/A
 (read-only)
 3.0.143.2
acli_presentation
 N/A
 N/A
 'Additional Calling Party Information' IE - address presentation restricted indicator.

A new ISUP parameter is defined under national option to carry the actual calling party number of the ported subscriber (N2) in the IAM message across the Network.

 N/A
 (read-only)
 3.0.143.2
acli_screening
 N/A
 N/A
 'Additional Calling Party Information' IE - screening indicator.

A new ISUP parameter is defined under national option to carry the actual calling party number of the ported subscriber (N2) in the IAM message across the Network.

 N/A
 (read-only)
 3.0.143.2

New table

Routing Script Parameters
Script parameter name ISDN R2_CAS SS7 SIP Comment 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
original_session_id N/A N/A N/A N/A Original Session ID (before call transfer or redirections)
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_sip_host N/A N/A N/A SIP:From - host (domain or IP) For example : The 'telcobridges.com' in From: "Cullen Jennings" <sip:fluffy@telcobridges.com>
calling_sip_port N/A N/A N/A SIP:From - port For example : The '6060' in From: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060>
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 ITU97: 'Display information' IE - display information ANSI95: 'Generic name' 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 - 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 For example : The 'fluffy' in P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>
private_address_sip_host N/A N/A N/A SIP:P-asserted-identity - host (domain or IP) SIP:Remote-party-id - host (domain or IP) For example : The 'telcobridges.com' in P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>
private_address_sip_port N/A N/A N/A SIP:P-asserted-identity - port SIP:Remote-party-id - port For example : The '6060' in P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060>
supp_private_address_

forward_enabled

N/A N/A N/A N/A Overwrite default supplementary/second P-Asserted-Identity header forwarding behavior from incoming to outgoing leg
supp_private_address N/A N/A N/A SIP:P-Asserted-Identity - userinfo For example : The 'fluffy' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>
supp_private_address_

display_name

N/A N/A N/A SIP:P-Asserted-Identity - display name For example : The 'Cullen Jennings' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>
supp_private_address

_sip_host

N/A N/A N/A SIP:P-Asserted-Identity - host (domain or IP) For example : The 'telcobridges.com' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>
supp_private_address

_sip_port

N/A N/A N/A SIP:P-Asserted-Identity - port For example : The '6060' in supplementary/second P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060>
preferred_id_forward

_enabled

N/A N/A N/A N/A Overwrite default P-Preferred-Identity header forwarding behavior from incoming to outgoing leg
preferred_id N/A N/A N/A SIP:P-Preferred-Identity - userinfo For example : The 'fluffy' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>
preferred_id_display

_name

N/A N/A N/A SIP:P-Preferred-Identity - display name For example : The 'Cullen Jennings' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>
preferred_id_sip

_host

N/A N/A N/A SIP:P-Preferred-Identity - host (domain or IP) For example : The 'telcobridges.com' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com>
preferred_id_sip

_port

N/A N/A N/A SIP:P-Preferred-Identity - port For example : The '6060' in P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060>
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_sip_host N/A N/A N/A SIP:To - host For example : The 'telcobridges.com' in To: "Cullen Jennings" <sip:fluffy@telcobridges.com>
called_sip_port N/A N/A N/A SIP:To - port number For example : The '6060' in To: "Cullen Jennings" <sip:fluffy@telcobridges.com:6060>
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_npdi N/A N/A Q763: 'Generic number' IE - with qualifier = Ported number is present SIP: RequestURI - npdi = yes is present Only valid if SIP/SS7 supports LNP
ported_number N/A N/A Q763: 'Generic number' IE - address signals with qualifier = Ported number SIP: RequestURI - to user part when rn is present rn is stored in the called number
ported_number_noa N/A N/A Q763: 'Generic number' IE - nature of address indicator with qualifier = Ported number N/A Only valid if SIP/SS7 supports LNP
ported_number_npi N/A N/A Q763: 'Generic number' IE - numbering plan indicator with qualifier = Ported number 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 'Enable SIP 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 A script needs to set this to true if it wants to overwrite MLPP information in the outgoing leg. Otherwise, profile relay 'outgoing mode' applies automatically. 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
isub_forward_enabled N/A N/A N/A N/A Overwrite default ISUB forwarding behavior from incoming to outgoing leg 3.0.138
called_isub Q931: 'Called party subaddress' IE - subaddress information N/A Q763: 'Access transport' IE SIP: To - isub parameter 2.7
called_isub_type Q931: 'Called party subaddress' IE - type of subaddress N/A Q763: 'Access transport' IE SIP:To - isub-encoding parameter 2.7
calling_isub Q931: 'Calling party subaddress' IE - subaddress information N/A Q763: 'Access transport' IE SIP: From - isub 2.7
calling_isub_type Q931: 'Calling party subaddress' IE - type of subaddress N/A Q763: 'Access transport' IE SIP: From - isub-encoding 2.7
ss7_fci_default N/A N/A Default Forward 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 for which the corresponding bit in ss7_fci_force_mask is set, and no longer 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

_forward_enabled

N/A N/A N/A N/A Enable line service and timeslot selection to create the outgoing leg. tdm_ls_name and tdm_timeslot_nb must be defined along with tdm_ls_name_forward_enabled 3.0
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 If tdm_ls_name_forward_enabled is set, try to use this line service name to create outgoing leg 2.7

Mostly original tutorial guide text without table

Some of the stuff I started to move but this is practically all of it


Introduction

This Routing Script Tutorial provides you with essential information in managing the routing of your calls. Consult the sections below to learn more.

Accessing Routing Script Parameters

Learn how to access routing script parameters

Routing Script Parameter Mapping Table

To learn about how each Routing Script Parameter maps to varying protocols, consult the Routing Script Parameter Mapping Table

Script Parameters Definition

To learn about the definition of each script parameter, consult Script Parameters Definition


Noa values

The text below represents the value normally used by routing script.
Incase it's required to use a value that's not defined in the text values below, a integer can be provided and will be used "as-is" in the signaling message.
Example numeric values for the SS7 protocol are shown in parenthesis.

  • unknown_number (2 or 0x2)
  • international_number (4 or 0x4)
  • national_number (3 or 0x3)
  • subscriber_number (1 or 0x1)
  • network_specific (5 or 0x5)
  • network_routing_national_format (7 or 0x7)
  • network_routing_international_format (8 or 0x8)
  • abbreviated_number (6 or 0x6)
  • subscriber_number_operator_requested (113 or 0x71)
  • national_number_operator_requested (114 or 0x72)
  • international_number_operator_requested (115 or 0x73)
  • no_number_present_operator_requested (116 or 0x74)
  • no_number_present_cut_through_call_to_carrier (117 or 0x75)
  • test_line_test_code (119 or 0x77)
  • non_unique_subscriber_number (113 or 0x71)
  • non_unique_national_number (115 or 0x73)
  • non_unique_international_number (116 or 0x74)
  • call_950_number (118 or 0x76)
  • special_number (115 or 0x73)
  • national_number_with_transit_network_selection (116 or 0x74)
  • international_number_with_transit_network_selection (117 or 0x75)

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

  • call_params[:called_noa] = 0x70

or

  • call_params[:called_noa] = 112

Npi values

  • unknown_number
  • isdn
  • telephony
  • private
  • data
  • telex
  • national

Calling Display Type values

  • unspecified => Type is unspecified.
  • calling_party_name => Type is 0xB1.

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

  • call_params[:calling_display_type] = 0xB1

or

  • call_params[:calling_display_type] = 177

Calling Display value

  • call_params[:calling_display] = "Roger Fluffy"

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

The text below represents the value normally used by routing script.
Incase it's required to use a value that's not defined in the text values below, a integer can be provided and will be used "as-is" in the signaling message.
Example numeric values for the SS7 protocol are shown in parenthesis.

  • unspecified
  • not_available (0x2)
  • allowed (0x0)
  • restricted (0x1)
  • addr_restricted
  • name_restricted

Calling Party Category

The text below represents the value normally used by routing script.
In case it's required to use a value that's not defined in the text values below, a integer can be provided and will be used "as-is" in the signaling message.

Mapping from routing script to SS7/CAS R2/SIP

Routing Script string
SS7 raw value
R2 CAS scripts
 Default Rx CAS
 default Tx CAS
 SIP "cpc="
subscriber
 0xa
 CATEGORY_SUBSCRIBER
1 and 7
 7
 ordinary
subscriber_with_priority
 0xb
 CATEGORY_SUBSCRIBER_WITH_PRIORITY
2 and 9
2
priority
operator_french
 0x1
 CATEGORY_OPERATOR_FRENCH
5
5
operator
operator_english
 0x2
 CATEGORY_OPERATOR_ENGLISH (5)
 5
5
operator
operator_german
 0x3
 CATEGORY_OPERATOR_GERMAN (5)
 5
5
operator
operator_russian
 0x4
 CATEGORY_OPERATOR_RUSSIAN (5)
 5
5
operator
operator_spanish
0x5
 CATEGORY_OPERATOR_SPANISH (5)
 5
5
operator
data
 0xc
 CATEGORY_DATA
6 and 8
 6
datacall
test
 0xd
 CATEGORY_TEST
3
3
test
payphone
0xf
 CATEGORY_PAYPHONE
none
7
payphone
unknown
0x0
CATEGORY_UNKNOWN
 4, 11 to 15
 7
unknown
unspecified
0xa
invalid
none
none
invalid

Link to calling party categories used in CAS R2 scripts

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

The text below represents the value normally used by routing script.
In case it is required to use a value that is not defined in the text values below, an integer can be provided and will be used "as-is" in the signaling message.
Example numeric values for the SS7 protocol are shown in parenthesis.

  • unspecified
  • no (0x0)
  • pass (0x1)
  • fail (0x2)
  • network_provided (0x3)

Redirecting indicator values

SS7:

  • no_redirection
  • call_rerouted
  • call_rerouted_all_restricted
  • call_diverted
  • call_diverted_all_restricted
  • call_rerouted_restricted
  • call_diverted_restricted
  • spare

Redirecting number, Original Called Number and Diversion Reason

ISDN:

  • unknown
  • busy
  • no_reply
  • deflection
  • dte_out_of_order
  • forwarding_by_called_dte
  • unconditional

SS7:

  • unknown
  • busy (SIP: user-busy)
  • no_reply (SIP: no-answer)
  • unconditional
  • deflection
  • deflection_immediate
  • mobile_not_reachable

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:

  • digital
  • restricted_digital
  • digital_with_tones
  • speech
  • 3_1_khz_audio
  • video

redirecting_number_forward_enabled values

Controls forwarding or discarding of redirecting number (SIP: diversion header) to the 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 the input of the 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.

Note: To "insert" a new redirecting number value on the outgoing leg, redirecting_number_forward_enabled must also be set to true.

request_uri

Enables access to the Request-Line URI.

For example, if the Request-Line is: 

Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0

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:

    if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
       call_params[:called] = $1
    end

request_uri_forward_enabled

This call parameter 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 default value for this parameters is false.


sip_scheme

(Available in Toolpack 3.1+) This call parameter indicates the scheme (generally "sip" or "sips") of the incoming call.

This also allows the control of the scheme used for the outgoing call (regardless if request_uri_forward_enabled is used or not)

Note: sips scheme must only be used on TLS NAPs (will cause call routing failure if NAP has only UDP or TCP transport types).

sip_header values

Contains custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg:

Note:

The SIP header is in string format.

string format: 

call[ :sip_header ] = "P-my-custom-header:value1 \nP-my-custom-header2:value2 \nP-my-custom-header3:value3"

(Note: \n above are actual newline characters, not '\' followed by 'n')

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack: 

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

Note: Since version 3.0.57, Referred-By is now a SIP custom parameter

sip header parameters

The routing script can read (and modify) some SIP header parameters (user parameters, URI parameters or header parameters) from some SIP headers (To, From, P-Asserted-Identity, Remote-Party-ID, Contact).

Available parameters

  • call[ :calling_parameters ] (SIP "From" header)
  • call[ :called_parameters ] (SIP "To" header)
  • call[ :private_address_parameters ] (SIP "P-Asserted-Identity" or "Remote-Party-ID" header)
  • call[ :supp_private_address_parameters ] (SIP supplementary/second "P-Asserted-Identity" header)
  • call[ :preferred_id_parameters ] (SIP "P-Preferred-Identity" header)
  • call[ :contact_parameters ] (SIP "Contact" header)

These parameters (if present) contain a hash with 3 keys: user_param, uri_param and header_param. Each of this key points to a string that contains all the parameters found in the corresponding SIP header.

  • User parameters (parameters between the user name/number and the host). Example <sip:alice;param=value@somewhere.com>
  • URI parameters (parameters at the end of the URI). Example <sip:alice@somewhere.com;param=value>
  • Header parameters (outside the URI). Example <sip:alice@somewhere.com>;param=value

Example to print all parameters of SIP "To" header: 

 call[ :called_parameters ].inspect -> '{ :user_param => "name1=value1;name2=value2", :uri_param => "name=value", :header_param => "name=value;example_param_without_value" }'

Example to modify (replace) the URI parameters of SIP "To" header: 

 call[ :called_parameters ][ :uri_param ] = "user=phone"

Exceptions

Note: Some parameters are reported as their own call attribute (oli, isub, cpc, transport) so they have the same representation for all protocols (SS7, IDSN, SIP). They will not appear in the generic SIP header parameters structures above.

Forwarding from inbound to outbound call

Legacy behavior

(For base_routing version 1.32 or older) By default, the parameters are not forwarded in a SIP to SIP call flow. The parameters will be forwarded when:

  • accessed (read) from either the inbound or outbound call parameters
  • written in either the inbound or outbound call parameters

Current behavior

(For Toolpack 3.0.118+, with base_routing version 1.33+) SIP headers host and parameters are forwarded by default.

A route attribute "forward_sip_domain" (along with filter script "forward_sip_domain.rb") will control, per route, if SIP headers host+parameters must be forwarded.

Example usage

Example to print the user parameters: 

  if call[:calling_parameters]
    puts "user parameters = #{call[:calling_parameters][:user_param].inspect}"
  end

Example SIP "From" header: 

 From:<sip:123456782;test1=val1;test2=val2@something.com;test3=val3;test4=val4>;test5=val5;test6=val6

And the resulting content in the routing script: 

 call[:calling_parameters].inspect -> {:user_param=>"test1=val1;test2=val2", :uri_param=>"test3=val3;test4=val4", :header_param=>"test5=val5;test6=val6"}

Example to overwrite inbound leg calling parameters with new parameters for the outbound leg: 

call [:calling_parameters] = { 
  :user_param => "user_param7=7;user_param8=8",
  :uri_param => "uri_param9=value9",
  :header_param => "header_paramA=A" }

Example to add user=phone and keep all other uri parameters. 

  call[:calling_parameters] ||= {} # Create a hash if not already present
  call[:calling_parameters][:uri_param] ||= "" # Create a string if not already present
  call[:calling_parameters][:uri_param] += ";" if call[:calling_parameters][:uri_param] != ""
  call[:calling_parameters][:uri_param] += "user=phone"

MLPP Precedence values

mlpp_look_for_busy:

  • allowed
  • path_reserved
  • not_allowed


mlpp_precedence_level:

  • flash_override
  • flash
  • immediate
  • priority
  • routine


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:

  • nsap
  • nsap_ia5
  • nsap_bcd
  • user


called_isub: calling_isub:

Digits for the subaddress information.

Network Identification Plan

network_identification_plan:

  • Unknown (value 0)
  • cic (3 digits carrier identification code plus circuit code, value 1, SS7 or ISDN)
  • user (User, value 2, ISDN only)
  • cic4 (4 digits carrier identification code plus circuit code, value 2, SS7 only)
  • dnic (public Data Network ID, value 3, SS7 only)
  • mnic (public land mobile network, value 6, SS7 only)

Registered Users Information

Routing script can access information about registered users (when either the calling or called user is a known registered user). When these fields are empty, it means that the calling/called (SIP from/to) does not correspond to a known registered user (routing script may still decide to route the call based on static routes).

Information for the called user: 

 params[:registered_user]

Information for the calling user: 

 params[:calling_registered_user]

These parameters are a hash of key/values that provide information about the contact. 

 {
   :contact_list=>
   [
     {
       :contact=>"<sip:user_name_or_number@hostname:7070;transport=UDP>",    -> Full contact
       :expires=>"60",                   -> Contact expiry time (seconds)
       :host=>"hostname",                -> host name from the contact header
       :name=>"user_name_or_number",     -> user name from the contact header
       :nap_in=>"NAP_NAME",              -> NAP that the contact has registered from
       :port=>"7070",                    -> Port from the contact header
       :transport=>"UDP"                 -> Transport type from the contact header
       :q_value=>"0.00",                 -> Q-value for the contact (for contact ordering)
       :src_host=>"10.0.0.10",           -> Actual source IP address that the contact has registered from
       :src_port=>"7070",                -> Actual source port that the contact has registered from
       :src_transport=>"UDP",            -> Actual protocol that the contact has been registering with
      }
    ]
  }

Route parameters

All route may have these parameters:

  • calling
  • called
  • nap
  • remapped_calling
  • remapped_called
  • remapped_nap
  • remapped_destination_leg_profile (called remapped_profile prior to Toolpack 2.9)
  • remapped_source_leg_profile (called remapped_incoming_profile prior to Toolpack 2.9)

Example: 

 route[:remapped_nap]

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

  • priority
  • weight

Routing calls toward registered users

Static routes normally choose an outbound NAP to forward the call to. It is also possible to create routes from which the outbound NAP is dynamically chosen by matching a registered user (when using SIP registration forwarding).

More information can be found here about the way to control the priority of "dynamic" vs "static" routes.

More information can be found here about using routing scripts to access registered users information during call routing.

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 (audio files) in different states of the call flow.

  • announcement_tone (played before outgoing call is routed)
  • ring_tone (played after when waiting for outgoing call to answer)
  • busy_tone (played if outgoing call failed)
  • disconnect_tone (played after the call has reached it's maximum duration)

Example to play an announcement to incoming call (before routing outgoing call, regardless if a matching route is found or not): 

 bridge[:announcement_tone ] = "my_announcement.wav"

Example to play a ring-tone while the outgoing call is ringing: 

 bridge[:ring_tone] = "my_ring_tone.wav"

Example to play an audio file when outgoing call fails (no route, or outgoing call is refused): 

 bridge[:busy_tone] = "my_busy_tone.wav"

Example to play an audio file when call has reached the maximum allowed duration: 

 bridge[:disconnect_tone] = "your_account_balance_is_empty.wav"


Announcement file path format and options

All file plabyacks (:announcement_tone, :busy_tone, :ring_tone, :disconnect_tone) inside bridge parameters use this format. 

"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"

Optional parameters:

  • repeat: number of times to play the file (0 and 1 have the same result)
  • start_off: Start offset in milliseconds
  • end_off: End offset in milliseconds

Http and other path formats are described here: Path format

Example 1

The following example will play file1.wav once, and then play file2.wav in a loop: 

 "file1.wav,file2.wav:-1"

Example 2

The following example will play file1.wav from a start offset of 1 second to an end offset of 3 seconds, followed by file2.wav being played two times from second 5 to second 10. 

 "file1.wav:0:1000:3000,file2.wav:2:5000:10000"

Example 3

The following example will play file1.wav once, ending at an offset of 30 seconds. 

 "file1.wav:0:0:30000"

announcement_tone

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

Audio file played on the incoming call before any outgoing call is placed. The outgoing call occurs when the file finished playing.

announcement_tone options

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

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

announcement_code_detect

This option allows that the tone detection is enabled during the announcement play.

Collected digits can be inserted into the CDR logs (radius attribute "Telcob-CollectedDigits", or text CDR variable @{CollectedDigits}).

Collected digits can also be sent back to routing script, which is called again with the same call attributes, except that the called number is replaced by the collected digits.

Code detect has multiple options, as shown in the following code: 

 code_detect = {
   :type                   => :DTMF,   # :DTMF or :MFR1 tone detection.
                                       # Default is MFR1.
   :prefix                 => "",      # Prefix (digits) that is removed from collected digits.
                                       # Default is empty.
   :suffix                 => "",      # Suffix (digits) that is removed from collected digits
                                       # and causes routing script to be immediately called.
                                       # Default is empty.
   :suffix_removal         => false,   # Controls the removal of the suffix from the collected digit string that's reported to routing script.
                                       # Default is false
   :timeout                => 0,       # Inter-digit timeout (ms) after which collected digits are passed to the routing script.
                                       # Use 0 for "no timeout".
                                       # Default is 1000ms
   :barge_in_interruption  => true,    # When enabled, playing announcement is stopped as soon as first digit is collected.
                                       # Default is true.
   :proceed_on_play_done   => false,   # When true:  Outgoing call is made after announcement finishes playing.
                                       #             Routing script is not called again.
                                       # When false: Outgoing call is never made.
                                       #             Digits are collected until timeout or suffix match,
                                       #             then routing script is called again.
                                       # Default is false.
   :cas_on_hook            => false,   # Specific for CAS-R1 calls. Makes CAS bits switch to "on-hook" when announcement finished playing
                                       # (but the call is not "terminated" from Toolpack point of view)
                                       # Default is false.
   :cas_on_hook_delay      => 0,       # Duration of cas bits "on-hook" state.
                                       # Only effective if cas_on_hook is set to true.
                                       # Value of 0 stands for "infinite delay".
                                       # Default is 0.
   :repeat_delay           => 0,       # Delay between repetition of the announcement. The announcement will repeat
                                       # itself every "repeat_delay" until a code is detected (suffix match or timetout).
                                       # Value of 0 stands for "infinite delay" (no repeating).
                                       # Default is 0.
 }

Example 1: Collect DTMF digits, and call routing script again with collected digits upon timeout or suffix match. 

 code_detect = { :type => :DTMF, :suffix => "#", :timeout => 5000 }
 params[:bridge][:announcement_code_detect] = code_detect

Example 2: Collect digits during the announcement (for CDR logs), then proceed (make outgoing call) after announcement finishes playing 

 code_detect = { :type => :DTMF, :timeout => 0, :barge_in_interruption => false, :proceed_on_play_done => true }
 params[:bridge][:announcement_code_detect] = code_detect

Controlling what happens after announcement

The routing script can control what happens with the call after the announcement finishes playing:

  • An outgoing call is made
  • Incoming call is hung-up
  • Do nothing (wait for the incoming call to hang-up)
An outgoing call is made

This happens when the script has returned matching routes (and did not raise RoutingException)

Incoming call is hung-up

This happens when the script returns no routes (in which case base_routing will raise RoutingException with cause :no_route).

It also happens when the script explicitly raises RoutingException.

The incoming call will be terminated with the specified cause. For example 

   raise RoutingException, :temporary_failure

(See "Reason values" section in this page for list of available causes)

Do nothing (wait for the incoming call to hang-up)

If a filter raises RoutingException with code :ok, then the incoming call will not be terminated at the end of the announcement play. Announcement digit collection will remain active if appropriate. For example: 

   raise RoutingException, :ok



ring_tone

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

Audio file played on the incoming call while waiting for the outgoing call to be answered.

Ring tone playback can also be configured in the Web Portal, from the incoming call's profile (under "Tones and Call Progress Options").

Routing script has precedence over profile (a routing script that fills params[:bridge][:ring_tone] will override the profile's ring tone behavior).

ring_tone options

ring_tone_state
 params[:bridge][:ring_tone_state] = :alerted

Call state from which ring tone is being played. Available values are:

  • immediately: Ring tone starts playing immediately on the incoming leg
  • accepted: Ring tone starts playing as soon as outgoing call is accepted
  • callprogress: Ring tone starts playing as soon as "call progress" is received on the outgoing call
  • alerted (default): Ring tone starts playing only once outgoing call is alerted (but won't play if alert indicates early media from outgoing call)

This option also applies when params[:bridge][:ring_tone] are not used, because it also applies to ring tone playback configured in the Web Portal, from the incoming call's profile.

busy_tone

 Toolpack 2.8 and above:
   params[:bridge][:busy_tone] = "no_route.wav"

 Note: Obsolete name (toolpack 2.7.153 and earlier, but still supported in recent releases):
   params[:bridge][:call_progress_tone] = "no_route.wav"

Audio file played on the incoming call when outgoing call fails (never answered).

Note that announcement_tone, if used, is played before the outgoing call attempt is made, and thus before the busy_tone.

Busy tone playback can also be configured in the Web Portal, from the incoming call's profile (under "Tones and Call Progress Options").

Routing script has precedence over profile (a routing script that fills params[:bridge][:busy_tone] will override the profile's busy tone behavior).

Special value "none" can be used by routing script to force playing nothing (as empty string would default to profile's behavior)

busy_tone options

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

Forces an answer of the call before playing the busy tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

disconnect_tone

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

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

disconnect_tone options

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

Maximum call duration in millisecond. 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.

Managing audio prompts through Web Portal

Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal: 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.

The default (replicated) prompts folder

By default, when playing a prompt, Toolpack will look in the default prompts folder: 

/lib/tb/toolpack/pkg/prompts

The root of this "prompts" directory is automatically replicated to secondary unit of redundant setups (1+1, N+1, redundant hosts). Sub-folders won't be replicated.

Any prompt play request without explicit file path will map to this folder. For example: 

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

This will correspond to file /lib/tb/toolpack/pkg/prompts/no_route.wav

Relative file paths

Any file path that begins with "file://" is considered relative to the tbstreamserver application's working directory: 

/lib/tb/toolpack/setup/12358/2.8/apps/tbstreamserver/

(Where "2.8" may be replaced by the current major version of your system)

For example: 

 params[:bridge][:busy_tone] = "file://my_folder/no_route.wav"

This will correspond to file /lib/tb/toolpack/setup/12358/2.8/apps/tbstreamserver/my_folder/no_route.wav

Absolute file paths

Absolute paths can also be provided. For example: 

 params[:bridge][:busy_tone] = "file:///root/my_folder/no_route.wav"

This will correspond to file /root/my_folder/no_route.wav

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:
    • @{CURRENT_PKG}: Version of current package
      • Example: 2.6.45
    • @{DATE format}: Prints the date, where 'format' is expressed as described for the 'strftime' function
      • Example: @{DATE %Y-%m-%d} => 2013-01-28
    • @{DefaultName}: Replaced by the default file name for recording, which contains:
      • 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: Calling number
      • Called: Called number
      • Protocol: Protocol type of this call (SS7, ISDN, CASR2, SIP)
      • Media info: Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
      • 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}: Default recording folder and file name: "@{RECORD_PATH}/@{DATE %Y-%m-%d}/@{DefaultName}"
      • 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"
    • @{Direction}: Direction of current leg (IN our OUT)
      • Example: IN
    • @{LegId}: Current LegId (Unique Id for this leg)
      • Example: F3D67B4B
    • @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
      • Example: 73EBA698
    • @{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
    • @{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
    • @{Protocol}: Protocol of current leg
      • Example: SS7
    • @{RECORD_PATH}: Default recording folder: "@{TB_SETUP_HOME}/recorded_calls/"
    • @{TBX_GW_PORT}: Current "System Id" (also called "Gateway Port")
      • Example: 12358
    • And all variables listed here: Building play or record file path

Controlling UUI relay

UUI (user-to-user information) can be present in different messages received by either call leg during a call. For example, information can be carried during the initial invite, other information can be carried when the call is alerted, answered, or terminated.

Routing scripts can control if the UUI received from one leg through the call will be forwarded to the other call leg:

  • uui_forward_enabled

Routing scripts can also read and modify the UUI received with the incoming call leg, before it gets forwarded upon creation of the outgoing call leg:

  • uui

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 between call legs
  • 1/true: UUI is forwarded between call legs

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.

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 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.

ENUM Query

Starting with release 3.1, it is possible to issue ENUM Query requests to DNS servers from routing scripts. To do so, the params[:enum_query] object must be filled with the required ENUM Query attributes params[:enum_query][:fqdn] and an exception must be raised with reason :enum_query_required.

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

  • ok: The ENUM Query was successful.
  • timeout: The ENUM Query was not answered.

The params[:enum_query][:responses_list] field will contain a list of hash responses for each NAPTR records.

NAPTR records contain:

  • :uri
  • :order
  • :preference

Example: 

 params[:enum_query][:responses_list]
   [{:order=>"200", :preference=>"10", :uri=>"!^03111.*$!sip:123456782@example-2.com!"}, 
    {:order=>"100", :preference=>"1", :uri=>"!^03222.*$!sip:123456782@example-3.com!"}, 
    {:order=>"200", :preference=>"1", :uri=>"!^03111.*$!sip:123456782@example-1.com!"}]

Using enum_called_remap.rb before filter script allows handling of ENUM query requests/responses. The match and replace regular expression from ENUM query responses are applied to params[:call][:called] to get "new called". This script allows update of the call parameters according to "new called" value. Refer to enum_called_remap.rb before filter script to get instructions on how to integrate this script into the main routing script (i.e. simple_routing_sbc.rb): 

 ...
 require 'enum_called_remap' unless defined?(EnumCalledRemap)
 ...
 include EnumCalledRemap
 ...
 before_filter :method => :enum_called_remap
 ...

Resolve ENUM Query down to type A records

The ENUM query could also resolve uri from responses and get matching outgoing NAP, NAP proxy IP and port through a sequence of DNS queries (i.e. NAPTR, SRV down to type A records). This behavior could be requested using "dns_query" parameter: 

 params[:enum_query][:dns_query] = true

When ENUM and DNS Queries complete, the routing script is called again with the results. The params[:enum_query] and params[:dns_query] objects will be filled with the ENUM Query and the DNS Query attributes from the responses. The DNS query responses are available through params[:dns_query][:responses_list] call parameters: 

 params[:dns_query][:responses_list]
   [{:nap=>"NAP_UDP", :nap_proxy_ip=>"10.3.14.191", :nap_proxy_port=>"8080", :transport=>"UDP", :order=>"100",
     :preference=>"1", :priority=>"0", :weight=>"5"},
    {:nap=>"NAP_TCP", :nap_proxy_ip=>"10.3.14.192", :nap_proxy_port=>"8081", :transport=>"TCP", :order=>"100",
     :preference=>"2", :priority=>"1", :weight=>"10"}]

Add dynamic routes

The ENUM query could also add dynamic routes base on DNS query responses. This could be requested using the "add_dynamic_routes" call parameter: 

 params[:enum_query][:dns_query] = true
 params[:enum_query][:add_dynamic_routes] = true

Note that it is mandatary to send DNS query to add dynamic routes.

The "base_routing.rb" script version should be greater then 1.37 in order to allow dynamic routes creation base on DNS query responses.

When requesting to add_dynamic_routes, the dns_query responses are used to create routes. Make sure that your configuration includes a route with remapped_nap = "Registered or DNS users". A route will be created for each DNS query responses. The routes "remapped_nap" takes NAP value from DNS query responses.

It is required to modify main routing script (i.e. simple_routing_sbc.rb) to forward IP/port values from params[:routes] to params[:call] like we are doing for NAP. See following example: 

 ...
 # This will select the outgoing NAP for this call according to the "remapped_nap" route parameter
 route_remap :call_field_name => :nap, :route_field_name => :remapped_nap
 
 # This will select the outgoing NAP proxy ip address for this call according to the "remapped_nap_proxy_ip" route parameter
 route_remap :call_field_name => :nap_proxy_ip, :route_field_name => :remapped_nap_proxy_ip
 
 # This will select the outgoing NAP proxy port for this call according to the "remapped_nap_proxy_port" route parameter
 route_remap :call_field_name => :nap_proxy_port, :route_field_name => :remapped_nap_proxy_port
 ...

DNS Query

Similarly to ENUM query, starting with release 3.1, it is possible to issue DNS Query requests to DNS servers from routing scripts. This could be used to skip the ENUM Query part when the called uri is already known but still need to get the matching outgoing NAP, NAP proxy IP and port. To do so, the params[:dns_query] object must be filled with the required DNS Query attributes params[:dns_query][:fqdn] and an exception must be raised with reason :dns_query_required.

When DNS Query completes, the routing script is called again with the result. The params[:dns_query] object will be filled with the DNS Query attributes from the responses. The DNS query responses are available through params[:dns_query][:responses_list] call parameters: 

 params[:dns_query][:responses_list]
   [{:nap=>"NAP_UDP", :nap_proxy_ip=>"10.3.14.191", :nap_proxy_port=>"8080", :transport=>"UDP", :order=>"100",
     :preference=>"1", :priority=>"0", :weight=>"5"},
    {:nap=>"NAP_TCP", :nap_proxy_ip=>"10.3.14.192", :nap_proxy_port=>"8081", :transport=>"TCP", :order=>"100",
     :preference=>"2", :priority=>"1", :weight=>"10"}]

Add dynamic routes

Similarly to ENUM Query, the DNS query could also create dynamic routes base on DNS query responses. This could be requested using the "add_dynamic_routes" call parameter: 

 params[:dns_query][:add_dynamic_routes] = true

The "base_routing.rb" script version should be greater then 1.37 in order to allow dynamic routes creation base on DNS query responses.

When requesting to add_dynamic_routes, the dns_query responses are used to create routes. Make sure that your configuration include a route with remapped_nap = "Registered or DNS users". A route will be created for each DNS query responses. The routes "remapped_nap" takes NAP value from DNS query responses.

It is required to modify main routing script (i.e. simple_routing_sbc.rb) to forward IP/port values from params[:routes] to params[:call] like we are doing for NAP. See following example: 

 ...
 # This will select the outgoing NAP for this call according to the "remapped_nap" route parameter
 route_remap :call_field_name => :nap, :route_field_name => :remapped_nap
 
 # This will select the outgoing NAP proxy ip address for this call according to the "remapped_nap_proxy_ip" route parameter
 route_remap :call_field_name => :nap_proxy_ip, :route_field_name => :remapped_nap_proxy_ip
 
 # This will select the outgoing NAP proxy port for this call according to the "remapped_nap_proxy_port" route parameter
 route_remap :call_field_name => :nap_proxy_port, :route_field_name => :remapped_nap_proxy_port
 ...

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 ] = "0,1,2"

or 

 bridge[ :diversion_reason ] = "unknown,busy,no_reply"

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 Redirecting number reason values.

Call transfer requests

Toolpack allows that Call transfer requests are relayed 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 fields are 'read-only'. They will not be included in the outgoing call, as they represent the contents of the call transfer request, and not the outgoing call to be made.

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

Redirection

In release 2.8 and above, redirection contacts are obtained from the routing engine in the following format: 

 contacts = params[ :contacts ]
 contacts = {
     :index=>"3",
     :list=>[
        {:called_number=>"6660", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"", :raw_data=>"", :expiration=>"3600"},
        {:called_number=>"6661", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"sip:6661@192.168.215.127", :raw_data=>"<sip:6661@192.168.215.127>", :expiration=>"3600"}
        {:called_number=>"6662", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"sip:6662@192.168.215.128", :raw_data=>"<sip:6662@192.168.215.128>", :expiration=>"3600"},
        {:called_number=>"6663", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"sip:6663@192.168.215.129", :raw_data=>"<sip:6663@192.168.215.129>", :expiration=>"3600"},
        {:called_number=>"6664", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"sip:6664@192.168.215.150", :raw_data=>"<sip:6664@192.168.215.150>", :expiration=>"3600"}
     ],
     :source_indexes=>"nil,0,0,0,2"
 }
  • params[:contacts][:list] contains the contact log. Each contact within the list has the following fields:
    • :called_number - the called number
    • :is_number_ported - if the called number has been ported (for SIP: if the npdi parameter is present)
    • :ported_number - the called number that was ported (for SIP: the rn parameter value, if available)
    • :sip_uri - the SIP URI of the contact, without the contact-params section (without the expires and q contact parameters)
    • :raw_data - the raw data representing the contact in the signaling protocol. For SIP, this is the full SIP URI (including the expires and q contact parameters).
    • :priority - the priority of the contact [0-1000]
    • :expiration - the expiration time in seconds of the contact
  • params[:contacts][:index] contains the index of the contact that is currently being routed.
  • params[:contacts][:source_indexes] contains a comma-separated list of indexes from params[:contacts][:list]. Each index represents the contact from which the contact in the list was obtained from.


To get more information, see:


Connected number

Insert a connected number in the answer message of the call flow.

Routing script example: 

   bridge = params[ :bridge ]
   bridge [ :connected_number ] = "3335577"
   bridge [ :connected_number_noa ] = :national_number
   bridge [ :connected_number_npi ] = :private
   bridge [ :connected_number_presentation ] = :allowed
   bridge [ :connected_number_screening ] = :pass

Terminating calls

In release 2.8, it is now possible to terminate a call through the routing scripts. The reason code must be specified in params[:bridge][:reason]. The :terminate hash must be created and copied into params: 

 terminate = {}
 params[:terminate] = terminate

The following fields can then be set in :terminate:

  • :sip_header
  • :contacts # list of contacts as described in the redirection section
  • :isup_raw
  • :isup_raw_variant
  • :redirecting_number
  • :redirecting_number_noa
  • :redirecting_number_npi
  • :redirecting_number_presentation
  • :redirecting_number_reason
  • :redirecting_number_counter
  • :redirecting_number_indicator
  • :original_called_number
  • :original_called_number_noa
  • :original_called_number_npi
  • :original_called_number_presentation
  • :original_called_number_reason
  • :original_called_number_counter

Reason values

Check here for Termination Reason 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
 :qor_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
 :requested_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
 :message_not_compatible_with_call_state
 :ie_non_existent
 :invalid_ie_content
 :msg_not_compatible_with_call_state
 :recovery_on_timer_expiry
 :parameter_non_existent_passed_on
 :message_with_non_recognized_parameters_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:
Reason causes starting with a digit must use the following syntax (can't use : as prefix). 

 '300_multiple_choices'
 '301_moved_permanently'
 '302_moved_temporarily'
 '305_use_proxy'
 '380_alternative_service'
 '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 and other NAP information

All the status fields of the NAPs are provided for use by the routing scripts.
For developpers: 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
 --------------------------------------------------------------------------------------------
 "name"                                NAP name.
 "signaling_type"                      Signaling type (SS7, ISDN, CASR2, SIP)
 "profile"                             Profile name.
 "sip_destination_ip"                  Destination IP address.
 "sip_destination_port"                Destination IP port.
 "sip_transport_type"                  SIP transport type (:udp, :tcp, or :tls) (Toolpack 3.1 and more)
 "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.
 "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.
 "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
 "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
 "asr_stats_incoming_struct"           Detailed Answer-Seizure Rate incoming statistics.
 {
   "global_asr_percent"                Global calculated ASR percentage.
   "total_call_cnt"                    Total count of calls.
   "total_accepted_call_cnt"           Total count of accepted calls (not dropped due to congestion or rate-limiting).
   "total_answered_call_cnt"           Total count of answered calls.
   "last_24h_asr_percent"              Last 24 hours calculated ASR percentage.
   "last_24h_call_cnt"                 Last 24 hours count of calls.
   "current_hour_asr_percent"          Current hour calculated ASR percentage.
   "current_hour_call_cnt"             Current hour count of calls.
   "last_hour_asr_percent"             Last hour calculated ASR percentage.
   "last_hour_call_cnt"                Last hour count of calls.
 }
 "asr_stats_outgoing_struct"           Detailed Answer-Seizure Rate outgoing statistics.
 {
   "global_asr_percent"                Global calculated ASR percentage.
   "total_call_cnt"                    Total count of calls.
   "total_accepted_call_cnt"           Total count of accepted calls (not dropped due to congestion or rate-limiting).
   "total_answered_call_cnt"           Total count of answered calls.
   "last_24h_asr_percent"              Last 24 hours calculated ASR percentage.
   "last_24h_call_cnt"                 Last 24 hours count of calls.
   "current_hour_asr_percent"          Current hour calculated ASR percentage.
   "current_hour_call_cnt"             Current hour count of calls.
   "last_hour_asr_percent"             Last hour calculated ASR percentage.
   "last_hour_call_cnt"                Last hour count of calls.
 }
 "mos_struct"                          Detailed Mean Opinion Score statistics.
 {
   "last_24h_ingress"                  Last 24 hours calculated MOS for incoming RTP packets.
   "last_24h_egress"                   Last 24 hours calculated MOS for outgoing RTP packets.
   "current_hour_ingress"              Current hour calculated MOS for incoming RTP packets.
   "current_hour_egress"               Current hour calculated MOS for outgoing RTP packets.
   "last_hour_ingress"                 Last hour calculated MOS for incoming RTP packets.
   "last_hour_egress"                  Last hour calculated MOS for outgoing RTP packets.
 }
 "network_quality_struct"              Detailed network quality statistics.
 {
   "last_24h_ingress"                  Last 24 hours network quality percentage for incoming RTP packets.
   "last_24h_egress"                   Last 24 hours network quality percentage for outgoing RTP packets.
   "current_hour_ingress"              Current hour network quality percentage for incoming RTP packets.
   "current_hour_egress"               Current hour network quality percentage for outgoing RTP packets.
   "last_hour_ingress"                 Last hour network quality percentage for incoming RTP packets.
   "last_hour_egress"                  Last hour network quality percentage for outgoing RTP packets.
 }


The nap status is part of a substructure and will be a hash containing all subfield elements.

Example to access NAP information and NAP status of the current call


To find the incoming nap in a routing script, we can do this in before_filter or after_filter and use these lines to create a symbol: 

   incoming_nap = params[:call][:nap].to_sym
   log_trace 1, "incoming_nap = " + incoming_nap.inspect


To get the configured NAP list, you can do this: 

   nap_lists = params[:naps]
   log_trace 1, "nap_lists = " + nap_lists.inspect


From the list above, you can find how many calls you have on this NAP: 

   log_trace 1,"Incoming NAP call count=" + nap_lists[incoming_nap][:asr_stats_incoming_struct][:total_call_cnt].inspect


Or which network the call is coming from: 

   log_trace 1,"Incoming NAP signaling type=" + nap_lists[incoming_nap][:signaling_type].inspect


If you are using a "NAP Columns" custom parameter (Create New NAP Column), you can get the information (since incoming_nap is a symbol): 

   network_type = nap_lists[incoming_nap][:network_type]
   log_trace 1, "For incoming_nap = " + incoming_nap.inspect + " network_type is: " + network_type.inspect


If you want to modify something according to nap information, you may need to do a loop like this: 

   nap_lists.each do |nap_list,nap_info|
     log_trace 1, "NAP: " + nap_info[:name].inspect + " network_type: " + nap_info[:network_type].inspect
   end

Telephony Services

In release 2.10 and the above, telephony services (CNAM Request) can be manage from the routing engine in the following format: 

 params[:telephony_services].each do |service|  -> Array of telephony services
   service[:name]                               -> Customer telephony service name
   service[:type]                               -> For now only "CNAM Request"
   service[:enabled]                            -> Indicate if the service is enabled (true) or not (false)
                                                   (Only the telephony service define in the profile associated to the NAP is enabled)
                                                   (The others telephony services define in others profiles are disabled)
                                                   (If we are in the case where we return in the routing script with a response, it is important to set :enabled to false in order to avoid repeating the same query)
   serviceParams = service[:params]
   serviceParams[:return_to_script]             -> Indicates to Gateway if we must return to the routing script after receiving the CNAM response
                                                   (It is important to set back to false this field to avoid an infinite loop)
   serviceQuery = service[:query]
   serviceQuery[:phone]                         -> 10 digits of calling number from the incoming call to send to the CNAM server
   serviceQuery[:timeout]                       -> Timeout in millisecond to wait a CNAM response from CNAM server
                                                   (Default value from profile configuration)
   serviceResponse = service[:response]
   serviceResponse[:success]                    -> Indicates if we received a good CNAM response from the CNAM Server (Only present if :return_to_script is set to true)
   serviceResponse[:caller_name]                -> The caller name received in the CNAM response from the CNAM Server (Only present if :return_to_script is set to true)

Custom user context

The routing script may save per-call information within the call context, that will be available if routing is called again later during the call flow.

Cases where routing is called multiple times for the same call are: - Call transfer requests - SIP redirect requests - Radius Authorization result - Announcement server with digit collection

The routing script can save a recursive hash of attributes here: 

 params[:user_context]

For example 

 params[:user_context] = { "SomeKey" => "Some value I want to retrieve upon next routing for this call", "OtherVal" => { "subkey" => "subval" } }

Upon first call to routing script, params[:user_context] will be nil. Upon subsequent calls to routing script, it will contain whatever the script had stored upon previous call (or nil if it was not set)

Note: This feature is available starting from release 2.9.85, 2.10.31 and 3.0.15 (in respective branches 2.9, 2.10 or 3.0)

Routing Script Tests

The Web portal features a tool for Testing Scripts. The user must enter parameters to simulate the incoming call and after pressing the Test button, will output selected routes and numbers. You do not need to activate the new routes, or the new scripts to use this test tool: It can be used to test the routing scripts and routing table before activating it. This is available in the Routing Scripts section of the Web portal.

Test parameters

@call_params

That variable should contain a hash of call parameters that will be passed to the routing script. This is equivalent to the incoming call parameters.


@nap_list

A list of the hash containing the nap statuses. This is equivalent to the nap statuses at the time the call is to be routed.

The nap list is hashed by the nap names in UPPERCASE. It is important to consider this when creating new dynamic route or nap attributes that may nap names that will be used to fetch a status.


@params

A hash of hashes containing parameters. This hash contains bridge parameters and other kind of parameter groups may be added in the future. 

 @params = {
    :bridge => {:announcement_tone, "announcement.wav"},
    :contacts => {
      :index=>"1",
      :list=>[
         {:called_number=>"6660", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"",
          :raw_data=>"", :expiration=>"3600"},
         {:called_number=>"6661", :priority=>"1000", :is_number_ported=>"0", :sip_uri=>"sip:6661@192.168.215.127", 
          :raw_data=>"<sip:6661@192.168.215.127>", :expiration=>"3600"}
      ],
      :source_indexes=>"nil,0"
    }
 }
Retrieved from "https://docs.telcobridges.com/w/index.php?title=AllynSandbox&oldid=33439"