TBwiki - User contributions [en]

Toolpack:Protocol Stack Settings A

2016-01-26T16:40:41Z

Atremblay:

{{DISPLAYTITLE:Web Portal 2.8: Protocol Stacks}}

=Protocol Stacks=

==ISDN FAS and NFAS==

{| cellpadding="5" border="1" class="wikitable"
|-

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configure ISDN-PRI Signaling

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Modify NAP profile

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configure Network Access Points (NAPs)
|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface C|Create Line interfaces]]
*[[Toolpack:Creating_a_Line_Service C|Create Line Services]]

| valign="top" |
*[[Toolpack:Configuring_an_ISDN_Stack D|Configure an ISDN stack]]
OR 
*[[Toolpack:Configuraing_NFAS B|Configure NFAS]]

| valign="top" |
*[[Toolpack:Modify_NAP_profile C|Modify profile]]

| valign="top" |
*[[Toolpack:Allocating_an_ISDN_Network_Access_Point_(NAP) D|Allocate an ISDN NAP]]

|}

===''ISDN Advanced Features''===

<div class="mw-collapsible mw-collapsed" data-collapsetext="ISDN NFAS Overlap" data-expandtext="ISDN NFAS Overlap" style="width: 400px;">

{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |ISDN Overlap Sending
|-
| valign="top" |
*[[Toolpack:Configuring_Overlap B|''ISDN NFAS Overlap Parameters'']]
|}

</div>
 

==CAS==

{| cellpadding="5" border="1" class="wikitable"
|-

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring a CAS stack
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configure Network Access Points (NAPs)

|-
| valign="top" |
*[[Toolpack:Creating_a_Line_Interface C|Create Line Interfaces]]
*[[Toolpack:Creating_a_Line_Service C|Create Line services]]
| valign="top" |
*[[Toolpack:Copy variant script C|Copy variant script]]
*[[Toolpack:Create CAS R2 stack C|Create CAS stack]]
*Edit the [[CASr1_scripting|CAS R1]] or [[CAS R2 scripting|CAS R2]] script to adapt the variant
**[[CASr1_scripting#TONE_USE_DTMF|Select CAS R1 tone type]]
**[[Toolpack:Setting CAS R2 BACK DIGITS variable C|Set CAS R2 backward digits string]]
| valign="top" |
*[[Toolpack:Modify_NAP_profile C|Modify profile]]
| valign="top" |
*[[Toolpack:Creating_a_CAS_R2_NAP C|Create a CAS NAP]]

|}

==SIP==

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Configure IP port range
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configure SIP Signaling
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configure Network Access Points (NAPs)
|-
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range C|Create an IP port range]]

| valign="top" |
*[[Toolpack:Creating_a_SIP_Stack C|Create a SIP stack]]
*[[Toolpack:Creating_a_SIP_Transport_Server C|Create a SIP transport server]]

| valign="top" |
*[[Toolpack:Modify_NAP_profile C|Modify profile]]

| valign="top" |
*[[Toolpack:Allocating_a_SIP_Network_Access_Point_(NAP) C|Allocate a SIP NAP]]

|}

===SIP Advanced Features===
<div class="mw-collapsible mw-collapsed" data-collapsetext="SIP-I SIP-T" data-expandtext="SIP-I SIP-T" style="width: 400px;">
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | SIP-I SIP-T
|-
| valign="top" |
*[[Enabling_SIP_I_SIP_T_C|Enable SIP-I SIP-T]]
|}
</div>
<div class="mw-collapsible mw-collapsed" data-collapsetext="SIP Spiral" data-expandtext="SIP Spiral" style="width: 400px;">
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | SIP Spiral
|-
| valign="top" |
*[[Enabling_SIP_Spiral_C|Enable SIP Spiral]]
|}

</div>

<div class="mw-collapsible mw-collapsed" data-collapsetext="NAT traversal" data-expandtext="NAT traversal" style="width: 400px;">
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Remote NAT Traversal
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Local NAT Traversal
|-
| valign="top" |
*[[Enabling_Remote_NAT_Traversal_B|Enable Remote NAT Traversal]]

| valign="top" |
*[[Enabling_Local_NAT_Traversal_B|Enable Local NAT Traversal]]
|}
</div>

<div class="mw-collapsible mw-collapsed" data-collapsetext="DNS" data-expandtext="DNS" style="width: 400px;">
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | DNS
|-
| valign="top" |
*[[Toolpack:Configuring_DNS_Parameters_B|Enable DNS]]
|}
</div>

==SS7 ISUP==

===MTP2-MTP3-ISUP===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring the MTP2 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the MTP3 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configuring the ISUP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 6) Configure Network Access Points (NAPs)

|-
| valign="top" |
*[[Toolpack:Creating_a_Line_Interface C|Create a new line interface]]
*[[Toolpack:Creating_a_Line_Service C|Create a new line service]]

| valign="top" |
*[[Toolpack:Creating_an_MTP2_Configuration C|Create an MTP2 Configuration]]
*[[Toolpack:Creating_MTP2_Links B|Create an MTP2 Link]]

| valign="top" |
*[[Toolpack:Creating_an_MTP3_Configuration D|Create an MTP3 Configuration]]
*[[Toolpack:Creating_an_MTP3_Network B|Create an MTP3 Network]]
**[[Toolpack:Creating_SS7_Point_Codes C|Create an MTP3 Point Code]]
**[[Toolpack:Creating_an_MTP3_Linkset B|Create an MTP3 Linkset]]
***[[Toolpack:Creating_MTP3_Links B|Create MTP3 Links]]
**[[Toolpack:Creating_an_MTP3_Route B|Create an MTP3 Route]]

| valign="top" |
*[[Toolpack:Creating_an_ISUP_Stack C|Create an ISUP Stack]]
*[[Toolpack:Creating_an_ISUP_Network B|Create an ISUP Network]]
*[[Toolpack:Creating_an_ISUP_User_Part B|Create an ISUP User Part]]
*[[Toolpack:Creating_an_ISUP_Interface B|Create an ISUP Interface]]
*[[Toolpack:Creating ISUP CIC Groups B|Create ISUP CIC Groups]]

| valign="top" |
*[[Toolpack:Modify_NAP_profile C|Modify profile]]

| valign="top" |
*[[Toolpack:Creating_a_NAP_(SIGTRAN)_C|Create an ISUP NAP]]

|}

===M2PA-MTP3-ISUP===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring the M2PA Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the MTP3 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configuring the ISUP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 6) Configure Network Access Points (NAPs)

|-
| valign="top" |
*[[Toolpack:Creating_a_Line_Interface C|Create a line interface]]
*[[Toolpack:Creating_a_Line_Service C|Create a line service]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration C|Create the SCTP Configuration]]
*[[Toolpack:Creating the M2PA Configuration C|Create an M2PA Configuration]]
**[[Toolpack:Creating an M2PA SAP C|Create an M2PA SAP]]
**[[Toolpack:Adding M2PA Links B|Add M2PA Links]]

| valign="top" |
*[[Toolpack:Creating_an_MTP3_Configuration D|Create an MTP3 Configuration]]
*[[Toolpack:Creating_an_MTP3_Network B|Create an MTP3 Network]]
**[[Toolpack:Creating_SS7_Point_Codes C|Create an MTP3 Point Code]]
**[[Toolpack:Creating_an_MTP3_Linkset B|Create an MTP3 Linkset]]
***[[Toolpack:Creating_MTP3_Links B|Create MTP3 Links]]
**[[Toolpack:Creating_an_MTP3_Route B|Create an MTP3 Route]]

| valign="top" |
*[[Toolpack:Creating_an_ISUP_Stack C|Create an ISUP Stack]]
*[[Toolpack:Creating_an_ISUP_Network B|Create an ISUP Network]]
*[[Toolpack:Creating_an_ISUP_User_Part B|Create an ISUP User Part]]
*[[Toolpack:Creating_an_ISUP_Interface B|Create an ISUP Interface]]
*[[Toolpack:Creating ISUP CIC Groups B|Create ISUP CIC Groups]]

| valign="top" |
*[[Toolpack:Modify_NAP_profile C|Modify profile]]

| valign="top" |
*[[Toolpack:Creating_a_NAP_(SIGTRAN)_C|Create an ISUP NAP]]

|}

===M3UA-ISUP===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2a) Configuring the M3UA Layer - IPSP
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2b) Configuring the M3UA Layer - SGP
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the ISUP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Configure Network Access Points (NAPs)

|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface C|Create new line interface]]
*[[Toolpack:Creating_a_Line_Service C|Create new line service]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration C|Create the SCTP Configuration]]
*[[Toolpack:Creating SS7 Point Codes C|Create SS7 Point Codes]]
*[[Toolpack:Creating an M3UA Configuration (IPSP) C|Create an M3UA Configuration]]
**[[Toolpack:Creating an M3UA SAP (IPSP) B|Create an M3UA SAP]]
**[[Toolpack:Creating an M3UA Network (IPSP) B|Create an M3UA Network]]
**[[Toolpack:Creating_an_M3UA_User_Part_(IPSP)_B|Create an M3UA User Part]]
**[[Toolpack:Creating an M3UA Peer Signalling Process (IPSP) B|Create an M3UA Peer Signalling Process]]
**[[Toolpack:Creating_an_M3UA_Peer_Server_(IPSP)_B|Create an M3UA Peer Server]]
**[[Toolpack:Creating an M3UA Route (IPSP) B|Create an M3UA Route]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration C|Create the SCTP Configuration]]
*[[Toolpack:Creating SS7 Point Codes C|Create SS7 Point Codes]]
*[[Toolpack:Creating an M3UA Configuration SGP C|Create an M3UA Configuration]]
**[[Toolpack:Creating an M3UA SAP (SGP) B|Create an M3UA SAP]]
**[[Toolpack:Creating an M3UA Network (SGP) B|Create an M3UA Network]]
**[[Toolpack:Creating an M3UA User Part (SGP) B|Create an M3UA User Part]]
**[[Toolpack:Creating an M3UA Peer Signalling Process (SGP) B|Create an M3UA Peer Signalling Process]]
**[[Toolpack:Creating an M3UA Peer Server (SGP) B|Create an M3UA Peer Server]]
**[[Toolpack:Creating an M3UA Route (SGP) B|Create an M3UA Route]]

| valign="top" |
*[[Toolpack:Creating_an_ISUP_Stack C|Create an ISUP Stack]]
*[[Toolpack:Creating_an_ISUP_Network B|Create an ISUP Network]]
*[[Toolpack:Creating_an_ISUP_User_Part B|Create an ISUP User Part]]
*[[Toolpack:Creating_an_ISUP_Interface B|Create an ISUP Interface]]
*[[Toolpack:Creating ISUP CIC Groups B|Create ISUP CIC Groups]]

| valign="top" |
*[[Toolpack:Modify_NAP_profile C|Modify profile]]

| valign="top" |
*[[Toolpack:Creating_a_NAP_(SIGTRAN)_C|Create an ISUP NAP]]

|}

===SS7 Advanced Features===

<div class="mw-collapsible mw-collapsed" data-collapsetext="SS7 SPIROU configuration" data-expandtext="SS7 SPIROU configuration" style="width: 400px;">
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Configuring SPIROU
|-
| valign="top" |
*[[Toolpack:Modifying_Profile_for_SPIROU B|Modifying Profile]]
*[[Toolpack:Modifying_Gateway_Configurations_for_SPIROU B|Modifying Gateway Configurations]]
*[[Toolpack:Modifying_ISUP_Stack_for_SPIROU B|Modifying ISUP Stack]]
*[[Toolpack:Modifying_ISUP_Userpart_for_SPIROU B|Modifying ISUP Userpart]]
*[[Toolpack:Optional_configurations_for_SPIROU A|Optional modifications]]
|}

</div>

==SCCP-TCAP==

===MTP2-MTP3-SCCP-TCAP===

{| cellpadding="5" border="1" class="wikitable"

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring the MTP2 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the MTP3 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configuring the SCCP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Configuring the TCAP Layer (optional)

|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface C|Create new line interface]]
*[[Toolpack:Creating_a_Line_Service C|Create new line service]]

| valign="top" |
*[[Toolpack:Creating_an_MTP2_Configuration C|Create an MTP2 Configuration]]
*[[Toolpack:Creating_MTP2_Links B|Create an MTP2 Link]]

| valign="top" |
*[[Toolpack:Creating_an_MTP3_Configuration D|Create an MTP3 Configuration]]
*[[Toolpack:Creating_an_MTP3_Network B|Create an MTP3 Network]]
**[[Toolpack:Creating_SS7_Point_Codes C|Create an MTP3 Point Code]]
**[[Toolpack:Creating_an_MTP3_Linkset B|Create an MTP3 Linkset]]
***[[Toolpack:Creating_MTP3_Links B|Create MTP3 Links]]
**[[Toolpack:Creating_an_MTP3_Route B|Create an MTP3 Route]]

| valign="top" |
*[[Toolpack:Creating_an_SCCP_Stack B| Create an SCCP Stack]]
*[[Toolpack:Creating_an_SCCP_Network B|Create an SCCP Network]]
**[[Toolpack:Creating_an_SCCP_Userpart B|Create an SCCP Userpart]]
**[[Toolpack:Creating_an_SCCP_LSAP B|Create an SCCP LSAP]]
***[[Toolpack:Creating_an_SCCP_Route B|Create an SCCP Route]]
****[[Toolpack:Creating_an_SCCP_SSN B|Create an SCCP SSN]]
*[[Toolpack:Creating_an_SCCP_GTT_Association B|Create an SCCP GTT Association]]
**[[Toolpack:Creating_an_SCCP_GTT_Address_Map B|Create an SCCP GTT Address Map]]

| valign="top" |
*[[Toolpack:Creating_a_TCAP_Stack B|Create a TCAP Stack]]
**[[Toolpack:Creating_a_TCAP_Userpart B| Create a TCAP Userpart]]
*[[Toolpack:Activating_the_Configuration C|Activating the Configuration]]

|}

===M2PA-MTP3-SCCP-TCAP===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring the M2PA Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the MTP3 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configuring the SCCP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Configuring the TCAP Layer (optional)

|-
| valign="top" |
*[[Toolpack:Creating_a_Line_Interface C|Create a line interface]]
*[[Toolpack:Creating_a_Line_Service C|Create a line service]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration C|Create the SCTP Configuration]]
*[[Toolpack:Creating the M2PA Configuration c|Create an M2PA Configuration]]
**[[Toolpack:Creating an M2PA SAP C|Create an M2PA SAP]]
**[[Toolpack:Adding M2PA Links B|Add M2PA Links]]

| valign="top" |
*[[Toolpack:Creating_an_MTP3_Configuration D|Create an MTP3 Configuration]]
*[[Toolpack:Creating_an_MTP3_Network B|Create an MTP3 Network]]
**[[Toolpack:Creating_SS7_Point_Codes C|Create an MTP3 Point Code]]
**[[Toolpack:Creating_an_MTP3_Linkset B|Create an MTP3 Linkset]]
***[[Toolpack:Creating_MTP3_Links B|Create MTP3 Links]]
**[[Toolpack:Creating_an_MTP3_Route B|Create an MTP3 Route]]

| valign="top" |
*[[Toolpack:Creating_an_SCCP_Stack B| Create an SCCP Stack]]
*[[Toolpack:Creating_an_SCCP_Network B|Create an SCCP Network]]
**[[Toolpack:Creating_an_SCCP_Userpart B|Create an SCCP Userpart]]
**[[Toolpack:Creating_an_SCCP_LSAP B|Create an SCCP LSAP]]
***[[Toolpack:Creating_an_SCCP_Route B|Create an SCCP Route]]
****[[Toolpack:Creating_an_SCCP_SSN B|Create an SCCP SSN]]
*[[Toolpack:Creating_an_SCCP_GTT_Association B|Create an SCCP GTT Association]]
**[[Toolpack:Creating_an_SCCP_GTT_Address_Map B|Create an SCCP GTT Address Map]]

| valign="top" |
*[[Toolpack:Creating_a_TCAP_Stack B|Create a TCAP Stack]]
**[[Toolpack:Creating_a_TCAP_Userpart B| Create a TCAP Userpart]]
*[[Toolpack:Activating_the_Configuration C|Activating the Configuration]]

|}

===M3UA-SCCP-TCAP===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring the M3UA Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the SCCP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configuring the TCAP Layer (optional)

|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface C|Create a line interface]]
*[[Toolpack:Creating_a_Line_Service C|Create a line service]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration C|Create the SCTP Configuration]]
*[[Toolpack:Creating SS7 Point Codes C|Create SS7 Point Codes]]
*[[Toolpack:Creating an M3UA Configuration D|Create an M3UA Configuration]]
**[[Toolpack:Creating an M3UA SAP C|Create an M3UA SAP]]
**[[Toolpack:Creating an M3UA Network C|Create an M3UA Network]]
**[[Toolpack:Creating an M3UA User Part C|Create an M3UA User Part]]
**[[Toolpack:Creating an M3UA Peer Signalling Process C|Create an M3UA Peer Signalling Process]]
**[[Toolpack:Creating an M3UA Peer Server C|Create an M3UA Peer Server]]
**[[Toolpack:Creating an M3UA Route C|Create an M3UA Route]]

| valign="top" |
*[[Toolpack:Creating_an_SCCP_Stack B| Create an SCCP Stack]]
*[[Toolpack:Creating_an_SCCP_Network B|Create an SCCP Network]]
**[[Toolpack:Creating_an_SCCP_Userpart B|Create an SCCP Userpart]]
**[[Toolpack:Creating_an_SCCP_LSAP B|Create an SCCP LSAP]]
***[[Toolpack:Creating_an_SCCP_Route B|Create an SCCP Route]]
****[[Toolpack:Creating_an_SCCP_SSN B|Create an SCCP SSN]]
*[[Toolpack:Creating_an_SCCP_GTT_Association B|Create an SCCP GTT Association]]
**[[Toolpack:Creating_an_SCCP_GTT_Address_Map B|Create an SCCP GTT Address Map]]

| valign="top" |
*[[Toolpack:Creating_a_TCAP_Stack B|Create a TCAP Stack]]
**[[Toolpack:Creating_a_TCAP_Userpart B| Create a TCAP Userpart]]
*[[Toolpack:Activating_the_Configuration C|Activating the Configuration]]

|}

==H.248 MEGACO==

If the Tmedia is used to forward signalling messages to the SSW, you will require to configure M2UA, M3UA or IUA before configuring H.248.

If the Tmedia is used to connect media only, then you can go straight to [[#H.248|H.248 Configuration]]

===Signaling===
====M2UA====

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Create Line Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Create MTP2 links
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Create M2UA configuration

|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface C|Create a line interface]]
*[[Toolpack:Creating_a_Line_Service C|Create a line service]]

| valign="top" |

*[[Toolpack:Creating an MTP2 Configuration C|Create an MTP2 Configuration]]
**[[Toolpack:Creating MTP2 Links B|Create MTP2 Links]]

| valign="top" |

*[[Toolpack:Creating the SCTP Configuration C|Create the SCTP Configuration]]
*[[Toolpack:Creating the M2UA Configuration C|Create an M2UA Configuration]]
**[[Toolpack:Creating an M2UA SAP B|Create an M2UA SAP]]
**[[Toolpack:Creating an M2UA Cluster B|Create an M2UA Cluster]]
**[[Toolpack:Creating M2UA Links B|Create M2UA Links]]
**[[Toolpack:Creating M2UA Peers B|Create M2UA Peers]]

|}

====M3UA====

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Create Line Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Create MTP2 links
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Create MTP3 configuration
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Create M3UA configuration
|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface C|Create a line interface]]
*[[Toolpack:Creating_a_Line_Service C|Create a line service]]

| valign="top" |
*[[Toolpack:Creating an MTP2 Configuration C|Create an MTP2 Configuration]]
*[[Toolpack:Creating MTP2 Links B|Create MTP2 Links]]

| valign="top" |
*[[Toolpack:Creating SS7 Point Codes C|Create SS7 Point Codes]]
*[[Toolpack:Creating an MTP3 Configuration D|Create an MTP3 Configuration]]
**[[Toolpack:Creating an MTP3 Network B|Create an MTP3 Network]]
**[[Toolpack:Creating an MTP3 Linkset B|Create an MTP3 Linkset]]
**[[Toolpack:Creating MTP3 Links (M3UA) B|Create MTP3 Links]]
**[[Toolpack:Creating an MTP3 Route B|Create an MTP3 Route]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration C|Edit the SCTP Configuration]]
*[[Toolpack:Creating an M3UA Configuration D|Create an M3UA Configuration]]
**[[Toolpack:Creating an M3UA SAP C|Create an M3UA SAP]]
**[[Toolpack:Creating an M3UA Network C|Create an M3UA Network]]
**[[Toolpack:Creating an M3UA User Part C|Create an M3UA User Part]]
**[[Toolpack:Creating an M3UA Peer Signalling Process C|Create an M3UA Peer Signalling Process]]
**[[Toolpack:Creating an M3UA Peer Server C|Create an M3UA Peer Server]]
**[[Toolpack:Creating an M3UA Route C|Create an M3UA Route]] 

|}

====IUA====

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Create Line Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Create IUA Configuration

|-

| valign="top" |
*[[Toolpack:Creating a Line Interface C|Create a line interface]]
*[[Toolpack:Creating a Line Service C|Create a line service]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration C|Create the SCTP Configuration]]
*[[Toolpack:Creating the IUA Configuration C|Create an IUA Configuration]]
**[[Toolpack:Creating an IUA SAP B|Create an IUA SAP]]
**[[Toolpack:Creating an IUA Cluster B|Create an IUA Cluster]]
**[[Toolpack:Creating IUA Links B|Create IUA Links]]
**[[Toolpack:Creating IUA Peers B|Create IUA Peers]]

|}

===Media===

====TDM NAP (for ISUP/ISDN)====

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate TDM Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configure Network Access Points (NAPs)
|-
| valign="top" |
*[[Toolpack:Creating_a_Line_Interface C|Create a line interface]]
*[[Toolpack:Creating_a_Line_Service C|Create a line service]]
| valign="top" |
*[[Toolpack:Modify_NAP_profile C|Modify profile]]
| valign="top" |
*[[Toolpack:Allocating_a_TDM_Network_Access_Point_(NAP) C|Allocate a TDM NAP]]
|}

====VOIP NAP (for SIP)====

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Create IP Port Ranges
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configure Network Access Points (NAPs)
|-
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range C|Create IP port ranges]]
| valign="top" |
*[[Toolpack:Modify_NAP_profile C|Modify profile]]
| valign="top" |
*[[Toolpack:Allocating_a_VoIP_Network_Access_Point_(NAP) C|Allocate a VoIP NAP]]
|}

====CAS NAP====
{| cellpadding="5" border="1" class="wikitable"
|-

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring a CAS stack
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configure Network Access Points (NAPs)

|-
| valign="top" |
*[[Toolpack:Creating_a_Line_Interface C|Create a line interfaces]]
*[[Toolpack:Creating_a_Line_Service C|Create a line service]]
| valign="top" |
*[[Toolpack:Copy variant script C|Copy variant script]]
*[[Toolpack:Create CAS R2 stack C|Create CAS stack]]
*Edit the [[CASr1_scripting|CAS R1]] or [[CAS R2 scripting|CAS R2]] script to adapt the variant
**[[CASr1_scripting#TONE_USE_DTMF|Select CAS R1 tone type]]
**[[Toolpack:Setting CAS R2 BACK DIGITS variable C|Set CAS R2 backward digits string]]
| valign="top" |
*[[Toolpack:Modify_NAP_profile C|Modify profile]]
| valign="top" |
*[[Toolpack:Creating_a_CAS_R2_NAP C|Create a CAS NAP]]

|}

===Media Gateway===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Configure Media Gateway for H.248 mode
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Add a New Media Gateway Controller
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Associate NAPs Resources to H.248 Configuration

|-

| valign="top" |
*[[Toolpack:Configure the Media_Gateway_for_H248_Mode C|Configure the Media Gateway for H.248 mode]]
*[[Toolpack:Creating_an_H.248_Configuration C|Create a new H.248 configuration]]
| valign="top" |
*[[Toolpack:Adding_a_Media_Gateway_Controller_(MGC) B|Add a new media gateway controller (MGC)]]
| valign="top" |
*[[Toolpack:Associating_NAPs_with_an_H.248_Configuration C|Associate the NAPs with the H.248 configuration]]
*[[Toolpack:Selecting_Timeslots_for_TDM_Interfaces B|Select timeslots for the TDM interfaces]]

|}

=Protocol Interoperability=

===Early Media===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="240" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Q.1912.5 Profile A-B
|-
| valign="top" |
*[[Toolpack:Configure_Early_Media_Q1912_A_B_NAP_A|Configure NAP ]]
*[[Toolpack:Configure_Early_Media_Q1912_A_B_Profile_A|Configure Profile]]

|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="240" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Q.1912.5 Profile C (SIP-I)
|-
| valign="top" |
*[[Toolpack:Configure_Early_Media_Q1912_C_NAP_A|Configure NAP ]]
*[[Toolpack:Configure_Early_Media_Q1912_C_Profile_A|Configure Profile]]

|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="240" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | RFC3398
|-
| valign="top" |
*[[Toolpack:Configure_Early_Media_RFC3398_NAP_A|Configure NAP ]]
*[[Toolpack:Configure_Early_Media_RFC3398_Profile_A|Configure Profile]]

|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="240" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Q.699
|-
| valign="top" |
*[[Toolpack:Configure_Early_Media_Q699_NAP_A|Configure NAP ]]
*[[Toolpack:Configure_Early_Media_Q699_Profile_A|Configure Profile]]

|}
|}

=Redirection=

===General configuration===

When using SIP, ensure that the [[Parameter:_Allow_Recurse|Allow Recurse]] parameter in the [[Toolpack:Creating_a_SIP_Stack_C|SIP stack]] is '''unchecked''' so that Toolpack can handle redirections.

When configuring [[Termination_cause_codes|termination cause codes]], use the following table as a guide. The ''Drop'' column represents codes to use when redirection contents should be dropped and the call should be terminated with the specified code. The ''Forward'' column represents codes to use when redirection contents should be forwarded to the incoming leg with the specified code. If the redirection requests must be processed, the codes are not used.
{| class="wikitable"
|-
! rowspan="2" | Code !! colspan="2" | Drop !! colspan="2" | Forward
|-
! SS7 !! SIP !! SS7 !! SIP
|-
| 14 || 21 || 603 || 14 || 300
|-
| 22 || 21 || 410 || 22 || 301
|-
| 23 || 21 || 410 || 23 || 302
|-
| 300 || 21 || 603 || 23 || 300
|-
| 301 || 21 || 410 || 22 || 301
|-
| 302 || 21 || 410 || 23 || 302
|-
| 305 || 21 || 603 || 23 || 305
|-
| 380 || 21 || 603 || 23 || 380
|}
For each redirection cause code, choose '''Process''' to let the routing scripts process the redirection. Choose '''Stop''' to drop calls when receiving a redirection and use the above table to specify if the redirection contents should be dropped.

===Scenarios===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="240" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Process
|-
| valign="top" |
*[[Modify_LNP_profile_C|Modify LNP profile]]
*[[Termination_cause_codes|Edit termination cause codes]]
*[[Routing_script_tutorial:Mini_Development_Guide|Optional: configure the all_call_query.rb or query_on_release.rb routing script]]

|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="240" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Relay
|-
| valign="top" |
*[[Termination_cause_codes|Edit termination cause codes]]

|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="240" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Drop
|-
| valign="top" |
*[[Termination_cause_codes|Edit termination cause codes]]
*Uncheck [[Parameter:_Forward_SS7_raw_message_bytes|Forward SS7 raw message bytes]] in the gateway configuration

|}
|}

Text Call Detail Records

2015-11-27T21:38:05Z

Atremblay: /* Statistics */

Text [[call detail record|call detail records]] (CDR) can be used on the [[TMG800]], [[TMG3200]] or [[TMG7800]]. The Call Detail Records are saved in a log file on a local disk. There is an entry done for each call leg, at the start of a call and at the end of the call. In addition, the system can be configured to update the CDRs periodically.

The format of the CDR traces is defined by configuration, using variables that are replaced by the Gateway application when writing to the log.

For example, the following variable will be replaced by the called number:
@{CalledNumber}

In order to save disk space and simplify the archiving and backup of CDR log files, this log file is automatically archived (gzipped) and rotated every N seconds, as specified by the system configuration.

== Enabling text CDR ==
The enabling of Text CDR is described in [[Toolpack:Enabling CDR A|Enabling CDR]].

== Available variables ==
The following variables exist and can be used to define the CDR log format.

=== Variables used for identifying call (or call leg) in general ===
*@{StatusType}: Indicates the type of record ("Start", "Update" or "End").
*@{LegId}: Unique Id for this leg (32 bits value, but may eventually be upgraded to 64 bits value).
*@{OtherLegId}: Id of the other call leg joined with current call leg.
*@{SessionId}: Unique call identifier for two joined and answered call legs, including failed outgoing call attempts (route retry)
Formatted as 4 values of 32 bits, printed as 4 blocks of 8 hexadecimal characters separated by a space
Ex: a939d169 299ffcd0 00000000 00000000
Note: Call Transfer Target legs have separate SessionId. If you need an id to correlate a transferred call
to the original call, use @{OriginalSessionId}.
*@{OriginalSessionId}: Refers to @{SessionId} of the original legs for this call, in case of call transfer.
In fact, Transfer Target leg has a different value for @{SessionId}, but can be linked with the original call
legs through @{OriginalSessionId}.
*@{LinkId}: Same meaning as @{OriginalSessionId}, but presented as a 32 bits integer value.
For all Ids above, please see [[Text_Call_Detail_Records_(CDR)#Known_limitations|Known Limitations]] below for notes about uniqueness of these values.

=== Timestamps ===
*@{AlertTime}: Time where the call has started ringing.
Note: Supported on release 2.7 and up only.
*@{ConnectedTime}: Time where the call was answered (and connected with another leg) (in number of seconds since epoch)
*@{ConnectedTime:format}: Same as @{ConnectedTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{ConnectedTimeUtc:format}:Same as @{ConnectedTime:format} but printed in UTC time, rather than local time zone.
*@{CallDuration}: Call duration in seconds (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{CallDurationMs}: Call duration in milliseconds (end - connected time) (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{EndTime}: Time where the call has started terminating (in number of seconds since epoch).
Note that slightly differs from the @{Timestamp}, since the 'End' CDR trace is printed once the call has
finished terminating,
while @{EndTime} reports the time where the call has started terminating (upon hangup for example).
*@{EndTime:format}: Same as @{EndTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{EndTimeUtc:format}: Same as @{EndTime:format} but printed in UTC time, rather than local time zone.
*@{RingingDuration}: Ringing duration in seconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{RingingDurationMs}: Ringing duration in milliseconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{StartTime}: Time where the call was created (in number of seconds since epoch)
*@{StartTime:format}: Same as @{StartTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{StartTimeUtc:format}: Same as @{StartTime:format} but printed in UTC time, rather than local time zone.
*@{Timestamp}: Time where this CDR log entry was written.
Should not be used for billing purposes. Use @{EndTime} for billing @{EndTime} reports the time where
the call has started terminating (hangup), while *@{Timestamp} the time where signaling confirmed the termination.
*@{Timestamp:format}: Same as @{Timestamp} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{TimestampUtc:format}: Same as @{Timestamp:format} but printed in UTC time, rather than local time zone.

=== Information related to signaling ===
*@{CalledNumber}: Called number
*@{CallingNumber}: Calling number
*@{CallingPresentation}: Calling presentation: "Unspecified", "NotAvailable", "Allowed", "Restricted", "AddressRestricted" or "NameRestricted"
Note: Supported on release 2.7 and up only.
*@{CallingSubscriberNumber}: Second calling number (ISDN) or Generic number of type "additional calling party number" (SS7)
Note: Supported on release 2.7.43 and up only.
*@{CallType}: Call type ("Telephony" or "VOIP")
*@{IncomingNAP}: Name of the NAP that originated this call (incoming call leg's NAP name).
Note: Supported on release 2.7 and up only.
*@{NAP}: Name of the NAP this call leg is from
*@{OriginatorName}: Direction of the call:
- "answer" (incoming call leg) - "originate" (outgoing call leg)
Note: In release 2.6 and earlier, the direction of the call is as follows:
- "originate" (incoming call leg) - "answer" (outgoing call leg)
In release 2.7, the CDR option "Reverse CDR call origin" in Gateway configuration provide the same values as in release 2.6.
*@{OriginalCalledNumber}: Original called number
Note: Supported on release 2.7 and up only.
*@{Protocol}: Type of protocol used ("SS7", "ISDN", or "SIP")
*@{RedirectingNumber}: Redirecting number
Note: Supported on release 2.7 and up only.
*@{TerminationCause}: Cause of the call termination, printed as an integer value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationCauseString}: Cause of the call termination, printed as a string value
*@{OriginalCause}: Original cause of the call termination, printed as a string value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationSource}: Identifies the cause of the leg termination:
- "TermInd": Terminating indication has been received on this leg
- "JoinedTermInd": Terminating indication has been received on the leg joined to current leg,
and has been forwarded to current leg
- "App": Call control application has asked to drop the call
- "Engine": Toolpack engine has decided to terminate this call
(generally due to local errors like disconnected TMedia)
*@{UserName}: Static value: 100.
*@{SipCallId}: Content of the "call-id" SIP header
*@{ChargeIndicator}: For TDM (SS7 and CAS R2); received charge indicator in Alert message.

=== Information related to media ===
*@{Codec}: Codec used for this call ("G711" for example)
*@{LocalMediaInfo}: Protocol type dependent information on the call leg (local information for SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port locally used for receiving RTP)
*@{LocalMediaIP}: For VOIP calls, RTP IP address locally used for this call leg.
*@{LocalMediaPort}: For VOIP calls, RTP UDP port locally used for this call leg.
*@{RemoteMediaInfo}: Protocol type dependent information on the call leg (remote information SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port TMedia is sending RTP to)
*@{RemoteMediaIP}: For VOIP calls, RTP IP address of the remote peer for this call leg.
*@{RemoteMediaPort}: For VOIP calls, RTP UDP port of the remote peer for this call leg.
*@{TimeslotNumber}: For TDM (Telephony) calls, timeslot number that this call was using for audio.
*@{TrunkName}: For TDM (Telephony) calls, name of the trunk that this call was using for audio.

=== Statistics ===
The following variables allow to print call statistics in the text CDR logs.

There are some restrictions, however:
* Available '''only in the "end" CDR entry'''
* Available in release 2.7.103 and above only

Example:
* Pkt=@{Stat:Rtp:Rx:Packets}/@{Stat:Rtp:Tx:Packets}, Err=@{Stat:Rtp:Rx:Errors}/@{Stat:Rtp:Tx:Errors}

Refer to the following pages for the list of statistics:
* [[Call_statistics_format_B|Call statistics format for Toolpack 2.9 or later]]
* [[Call_statistics_format_A|Call statistics format for Toolpack 2.8]]

=== Information related to routing ===
*@{ApplicationName}: Name of the application that has written this log ("Gateway")
*@{RouteAttribute:attr}: Replaced by the value of a custom route attribute, for the selected
route. This will apply only to outgoing call legs that were made from routing.
Eligible route attributes are:
Route name: Use attribute "route_name". Ex: @{RouteAttribute:route_name}
Route set name: Use attribute "routeset_name". Ex: @{RouteAttribute:routeset_name}
Custom route attribute column: Use the custom attribute name. Ex: @{RouteAttribute:priority}
Routing script parameters: Use the route attribute name provided by routing script.
Ex: If script provides: route[:my_param]="myval"
Then it's included in CDR with @{RouteAttribute:my_param}]
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.
*@{ScriptAttribute:attr}: Replaced by the value of a routing script attribute stored in params[:bridge].
This will apply for incoming and outgoing call legs.
Eligible script attributes are:
Custom CDR value: Use attribute "CustomCdrValue". Ex: @{ScriptAttribute:CustomCdrValue}
Script parameters: Use the attribute name provided by routing script.
Ex: If script provides: params[:bridge][:my_param]="myval"
Then it's included in CDR with @{ScriptAttribute:my_param}
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.

=== Deprecated values: ===
*@{MediaInfo}: Same as @{RemoteMediaInfo}
*@{RemoteIP}: Same as @{RemoteMediaIP}
*@{RemotePort}: Same as @{RemoteMediaPort}

== CDR sample ==
=== Text CDR sample ===
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP',Protocol='SIP',Direction='answer'
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP2',Protocol='SIP',Direction='originate'
2013-02-07 10:19:07.562-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',TerminationSource='App',Calling='',Called='123',NAP='NAP_SIP2',Direction='originate'
2013-02-07 10:19:07.656-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',Termination Source='App',Calling='',Called='123',NAP='NAP_SIP',Direction='answer'

=== Radius AAA sample ===
* [[File:TelcoBridges_RADIUS_Auth&Acct.pcap|TelcoBridges_RADIUS_Auth&Acct.pcap]]
* [[File:TelcoBridges_RADIUS_Auth&Acct.txt|TelcoBridges_RADIUS_Auth&Acct.txt]]

== Redundancy ==

In a [[TMG7800]] configuration, with redundant TMG-Control servers, or [[TMG3200]]/[[TMG800]] in 1+1 configuration, only the active server writes the CDR logs. Since the active server may change over time, CDR parsing must take into account that CDR logs may be found in files from the two servers.

The analysis of the logs for the purpose of extracting billing information must be done after combining the two logs, from both TMG-Control servers, sorting the entries by timestamp for example. See how to [[TMG:Retrieve_Text_CDR|Retrieve Text CDR here]].

== CDR entry loss due to switchover ==
In some situations (during HA switchover for example), some CDR entries may be lost.

The following guide lines provide information on how to deal with these corner cases:

[[Call_Detail_Records_Entry_Loss|Deal with CDR entries loss]]

== Retrieving Text CDRs ==

There are 2 ways to retrieve the text CDR manually or automatically. The procedures are described in [[TMG:Retrieve_Text_CDR|Retrieve Text CDR]].

== Notes ==
*This mode of operation is not recommended for [[TMG800]] or [[TMG3200]] with a flash disk (last shipment January 2011). However, the [[TMG800]] or [[TMG3200]] with SATA or SSD disk option is OK (use command tbproduct: if the command can be executed, the disk is SATA or SSD).
*TelcoBridges does not recommend storing CDR logs via network file systems (NFS or other). We highly recommend writing to a local hard drive and have developed a background script that moves the gzipped log segments for backup or analysis.

== Related actions ==

'''Refer to the appropriate Toolpack release:'''
*[[Web_Portal_Tutorial_Guide_v2.7#CDR_.28Call_Detail_Record.29|Web Portal v2.7: CDR Configuration]]
*[[Web_Portal_Tutorial_Guide_v2.6#CDR_.28Call_Detail_Record.29|Web Portal v2.6: CDR Configuration]]

[[category:Needs revising]]

Text Call Detail Records

2015-11-27T21:37:48Z

Atremblay: /* Statistics */

Text [[call detail record|call detail records]] (CDR) can be used on the [[TMG800]], [[TMG3200]] or [[TMG7800]]. The Call Detail Records are saved in a log file on a local disk. There is an entry done for each call leg, at the start of a call and at the end of the call. In addition, the system can be configured to update the CDRs periodically.

The format of the CDR traces is defined by configuration, using variables that are replaced by the Gateway application when writing to the log.

For example, the following variable will be replaced by the called number:
@{CalledNumber}

In order to save disk space and simplify the archiving and backup of CDR log files, this log file is automatically archived (gzipped) and rotated every N seconds, as specified by the system configuration.

== Enabling text CDR ==
The enabling of Text CDR is described in [[Toolpack:Enabling CDR A|Enabling CDR]].

== Available variables ==
The following variables exist and can be used to define the CDR log format.

=== Variables used for identifying call (or call leg) in general ===
*@{StatusType}: Indicates the type of record ("Start", "Update" or "End").
*@{LegId}: Unique Id for this leg (32 bits value, but may eventually be upgraded to 64 bits value).
*@{OtherLegId}: Id of the other call leg joined with current call leg.
*@{SessionId}: Unique call identifier for two joined and answered call legs, including failed outgoing call attempts (route retry)
Formatted as 4 values of 32 bits, printed as 4 blocks of 8 hexadecimal characters separated by a space
Ex: a939d169 299ffcd0 00000000 00000000
Note: Call Transfer Target legs have separate SessionId. If you need an id to correlate a transferred call
to the original call, use @{OriginalSessionId}.
*@{OriginalSessionId}: Refers to @{SessionId} of the original legs for this call, in case of call transfer.
In fact, Transfer Target leg has a different value for @{SessionId}, but can be linked with the original call
legs through @{OriginalSessionId}.
*@{LinkId}: Same meaning as @{OriginalSessionId}, but presented as a 32 bits integer value.
For all Ids above, please see [[Text_Call_Detail_Records_(CDR)#Known_limitations|Known Limitations]] below for notes about uniqueness of these values.

=== Timestamps ===
*@{AlertTime}: Time where the call has started ringing.
Note: Supported on release 2.7 and up only.
*@{ConnectedTime}: Time where the call was answered (and connected with another leg) (in number of seconds since epoch)
*@{ConnectedTime:format}: Same as @{ConnectedTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{ConnectedTimeUtc:format}:Same as @{ConnectedTime:format} but printed in UTC time, rather than local time zone.
*@{CallDuration}: Call duration in seconds (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{CallDurationMs}: Call duration in milliseconds (end - connected time) (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{EndTime}: Time where the call has started terminating (in number of seconds since epoch).
Note that slightly differs from the @{Timestamp}, since the 'End' CDR trace is printed once the call has
finished terminating,
while @{EndTime} reports the time where the call has started terminating (upon hangup for example).
*@{EndTime:format}: Same as @{EndTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{EndTimeUtc:format}: Same as @{EndTime:format} but printed in UTC time, rather than local time zone.
*@{RingingDuration}: Ringing duration in seconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{RingingDurationMs}: Ringing duration in milliseconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{StartTime}: Time where the call was created (in number of seconds since epoch)
*@{StartTime:format}: Same as @{StartTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{StartTimeUtc:format}: Same as @{StartTime:format} but printed in UTC time, rather than local time zone.
*@{Timestamp}: Time where this CDR log entry was written.
Should not be used for billing purposes. Use @{EndTime} for billing @{EndTime} reports the time where
the call has started terminating (hangup), while *@{Timestamp} the time where signaling confirmed the termination.
*@{Timestamp:format}: Same as @{Timestamp} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{TimestampUtc:format}: Same as @{Timestamp:format} but printed in UTC time, rather than local time zone.

=== Information related to signaling ===
*@{CalledNumber}: Called number
*@{CallingNumber}: Calling number
*@{CallingPresentation}: Calling presentation: "Unspecified", "NotAvailable", "Allowed", "Restricted", "AddressRestricted" or "NameRestricted"
Note: Supported on release 2.7 and up only.
*@{CallingSubscriberNumber}: Second calling number (ISDN) or Generic number of type "additional calling party number" (SS7)
Note: Supported on release 2.7.43 and up only.
*@{CallType}: Call type ("Telephony" or "VOIP")
*@{IncomingNAP}: Name of the NAP that originated this call (incoming call leg's NAP name).
Note: Supported on release 2.7 and up only.
*@{NAP}: Name of the NAP this call leg is from
*@{OriginatorName}: Direction of the call:
- "answer" (incoming call leg) - "originate" (outgoing call leg)
Note: In release 2.6 and earlier, the direction of the call is as follows:
- "originate" (incoming call leg) - "answer" (outgoing call leg)
In release 2.7, the CDR option "Reverse CDR call origin" in Gateway configuration provide the same values as in release 2.6.
*@{OriginalCalledNumber}: Original called number
Note: Supported on release 2.7 and up only.
*@{Protocol}: Type of protocol used ("SS7", "ISDN", or "SIP")
*@{RedirectingNumber}: Redirecting number
Note: Supported on release 2.7 and up only.
*@{TerminationCause}: Cause of the call termination, printed as an integer value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationCauseString}: Cause of the call termination, printed as a string value
*@{OriginalCause}: Original cause of the call termination, printed as a string value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationSource}: Identifies the cause of the leg termination:
- "TermInd": Terminating indication has been received on this leg
- "JoinedTermInd": Terminating indication has been received on the leg joined to current leg,
and has been forwarded to current leg
- "App": Call control application has asked to drop the call
- "Engine": Toolpack engine has decided to terminate this call
(generally due to local errors like disconnected TMedia)
*@{UserName}: Static value: 100.
*@{SipCallId}: Content of the "call-id" SIP header
*@{ChargeIndicator}: For TDM (SS7 and CAS R2); received charge indicator in Alert message.

=== Information related to media ===
*@{Codec}: Codec used for this call ("G711" for example)
*@{LocalMediaInfo}: Protocol type dependent information on the call leg (local information for SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port locally used for receiving RTP)
*@{LocalMediaIP}: For VOIP calls, RTP IP address locally used for this call leg.
*@{LocalMediaPort}: For VOIP calls, RTP UDP port locally used for this call leg.
*@{RemoteMediaInfo}: Protocol type dependent information on the call leg (remote information SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port TMedia is sending RTP to)
*@{RemoteMediaIP}: For VOIP calls, RTP IP address of the remote peer for this call leg.
*@{RemoteMediaPort}: For VOIP calls, RTP UDP port of the remote peer for this call leg.
*@{TimeslotNumber}: For TDM (Telephony) calls, timeslot number that this call was using for audio.
*@{TrunkName}: For TDM (Telephony) calls, name of the trunk that this call was using for audio.

=== Statistics ===
The following variables allow to print call statistics in the text CDR logs.

There are some restrictions, however:
* Available '''only in the "end" CDR entry'''
* Available in release 2.7.103 and above only

Example:
* Pkt=@{Stat:Rtp:Rx:Packets}/@{Stat:Rtp:Tx:Packets}, Err=@{Stat:Rtp:Rx:Errors}/@{Stat:Rtp:Tx:Errors}

Refer to the following pages for the list of statistics:
* [[Call_statistics_format_B|Call statistics format for Toolpack 2.8]]
* [[Call_statistics_format_A|Call statistics format for Toolpack 2.9 or later]]

=== Information related to routing ===
*@{ApplicationName}: Name of the application that has written this log ("Gateway")
*@{RouteAttribute:attr}: Replaced by the value of a custom route attribute, for the selected
route. This will apply only to outgoing call legs that were made from routing.
Eligible route attributes are:
Route name: Use attribute "route_name". Ex: @{RouteAttribute:route_name}
Route set name: Use attribute "routeset_name". Ex: @{RouteAttribute:routeset_name}
Custom route attribute column: Use the custom attribute name. Ex: @{RouteAttribute:priority}
Routing script parameters: Use the route attribute name provided by routing script.
Ex: If script provides: route[:my_param]="myval"
Then it's included in CDR with @{RouteAttribute:my_param}]
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.
*@{ScriptAttribute:attr}: Replaced by the value of a routing script attribute stored in params[:bridge].
This will apply for incoming and outgoing call legs.
Eligible script attributes are:
Custom CDR value: Use attribute "CustomCdrValue". Ex: @{ScriptAttribute:CustomCdrValue}
Script parameters: Use the attribute name provided by routing script.
Ex: If script provides: params[:bridge][:my_param]="myval"
Then it's included in CDR with @{ScriptAttribute:my_param}
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.

=== Deprecated values: ===
*@{MediaInfo}: Same as @{RemoteMediaInfo}
*@{RemoteIP}: Same as @{RemoteMediaIP}
*@{RemotePort}: Same as @{RemoteMediaPort}

== CDR sample ==
=== Text CDR sample ===
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP',Protocol='SIP',Direction='answer'
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP2',Protocol='SIP',Direction='originate'
2013-02-07 10:19:07.562-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',TerminationSource='App',Calling='',Called='123',NAP='NAP_SIP2',Direction='originate'
2013-02-07 10:19:07.656-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',Termination Source='App',Calling='',Called='123',NAP='NAP_SIP',Direction='answer'

=== Radius AAA sample ===
* [[File:TelcoBridges_RADIUS_Auth&Acct.pcap|TelcoBridges_RADIUS_Auth&Acct.pcap]]
* [[File:TelcoBridges_RADIUS_Auth&Acct.txt|TelcoBridges_RADIUS_Auth&Acct.txt]]

== Redundancy ==

In a [[TMG7800]] configuration, with redundant TMG-Control servers, or [[TMG3200]]/[[TMG800]] in 1+1 configuration, only the active server writes the CDR logs. Since the active server may change over time, CDR parsing must take into account that CDR logs may be found in files from the two servers.

The analysis of the logs for the purpose of extracting billing information must be done after combining the two logs, from both TMG-Control servers, sorting the entries by timestamp for example. See how to [[TMG:Retrieve_Text_CDR|Retrieve Text CDR here]].

== CDR entry loss due to switchover ==
In some situations (during HA switchover for example), some CDR entries may be lost.

The following guide lines provide information on how to deal with these corner cases:

[[Call_Detail_Records_Entry_Loss|Deal with CDR entries loss]]

== Retrieving Text CDRs ==

There are 2 ways to retrieve the text CDR manually or automatically. The procedures are described in [[TMG:Retrieve_Text_CDR|Retrieve Text CDR]].

== Notes ==
*This mode of operation is not recommended for [[TMG800]] or [[TMG3200]] with a flash disk (last shipment January 2011). However, the [[TMG800]] or [[TMG3200]] with SATA or SSD disk option is OK (use command tbproduct: if the command can be executed, the disk is SATA or SSD).
*TelcoBridges does not recommend storing CDR logs via network file systems (NFS or other). We highly recommend writing to a local hard drive and have developed a background script that moves the gzipped log segments for backup or analysis.

== Related actions ==

'''Refer to the appropriate Toolpack release:'''
*[[Web_Portal_Tutorial_Guide_v2.7#CDR_.28Call_Detail_Record.29|Web Portal v2.7: CDR Configuration]]
*[[Web_Portal_Tutorial_Guide_v2.6#CDR_.28Call_Detail_Record.29|Web Portal v2.6: CDR Configuration]]

[[category:Needs revising]]

Text Call Detail Records

2015-11-27T21:36:56Z

Atremblay: /* Statistics */

Text [[call detail record|call detail records]] (CDR) can be used on the [[TMG800]], [[TMG3200]] or [[TMG7800]]. The Call Detail Records are saved in a log file on a local disk. There is an entry done for each call leg, at the start of a call and at the end of the call. In addition, the system can be configured to update the CDRs periodically.

The format of the CDR traces is defined by configuration, using variables that are replaced by the Gateway application when writing to the log.

For example, the following variable will be replaced by the called number:
@{CalledNumber}

In order to save disk space and simplify the archiving and backup of CDR log files, this log file is automatically archived (gzipped) and rotated every N seconds, as specified by the system configuration.

== Enabling text CDR ==
The enabling of Text CDR is described in [[Toolpack:Enabling CDR A|Enabling CDR]].

== Available variables ==
The following variables exist and can be used to define the CDR log format.

=== Variables used for identifying call (or call leg) in general ===
*@{StatusType}: Indicates the type of record ("Start", "Update" or "End").
*@{LegId}: Unique Id for this leg (32 bits value, but may eventually be upgraded to 64 bits value).
*@{OtherLegId}: Id of the other call leg joined with current call leg.
*@{SessionId}: Unique call identifier for two joined and answered call legs, including failed outgoing call attempts (route retry)
Formatted as 4 values of 32 bits, printed as 4 blocks of 8 hexadecimal characters separated by a space
Ex: a939d169 299ffcd0 00000000 00000000
Note: Call Transfer Target legs have separate SessionId. If you need an id to correlate a transferred call
to the original call, use @{OriginalSessionId}.
*@{OriginalSessionId}: Refers to @{SessionId} of the original legs for this call, in case of call transfer.
In fact, Transfer Target leg has a different value for @{SessionId}, but can be linked with the original call
legs through @{OriginalSessionId}.
*@{LinkId}: Same meaning as @{OriginalSessionId}, but presented as a 32 bits integer value.
For all Ids above, please see [[Text_Call_Detail_Records_(CDR)#Known_limitations|Known Limitations]] below for notes about uniqueness of these values.

=== Timestamps ===
*@{AlertTime}: Time where the call has started ringing.
Note: Supported on release 2.7 and up only.
*@{ConnectedTime}: Time where the call was answered (and connected with another leg) (in number of seconds since epoch)
*@{ConnectedTime:format}: Same as @{ConnectedTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{ConnectedTimeUtc:format}:Same as @{ConnectedTime:format} but printed in UTC time, rather than local time zone.
*@{CallDuration}: Call duration in seconds (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{CallDurationMs}: Call duration in milliseconds (end - connected time) (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{EndTime}: Time where the call has started terminating (in number of seconds since epoch).
Note that slightly differs from the @{Timestamp}, since the 'End' CDR trace is printed once the call has
finished terminating,
while @{EndTime} reports the time where the call has started terminating (upon hangup for example).
*@{EndTime:format}: Same as @{EndTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{EndTimeUtc:format}: Same as @{EndTime:format} but printed in UTC time, rather than local time zone.
*@{RingingDuration}: Ringing duration in seconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{RingingDurationMs}: Ringing duration in milliseconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{StartTime}: Time where the call was created (in number of seconds since epoch)
*@{StartTime:format}: Same as @{StartTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{StartTimeUtc:format}: Same as @{StartTime:format} but printed in UTC time, rather than local time zone.
*@{Timestamp}: Time where this CDR log entry was written.
Should not be used for billing purposes. Use @{EndTime} for billing @{EndTime} reports the time where
the call has started terminating (hangup), while *@{Timestamp} the time where signaling confirmed the termination.
*@{Timestamp:format}: Same as @{Timestamp} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{TimestampUtc:format}: Same as @{Timestamp:format} but printed in UTC time, rather than local time zone.

=== Information related to signaling ===
*@{CalledNumber}: Called number
*@{CallingNumber}: Calling number
*@{CallingPresentation}: Calling presentation: "Unspecified", "NotAvailable", "Allowed", "Restricted", "AddressRestricted" or "NameRestricted"
Note: Supported on release 2.7 and up only.
*@{CallingSubscriberNumber}: Second calling number (ISDN) or Generic number of type "additional calling party number" (SS7)
Note: Supported on release 2.7.43 and up only.
*@{CallType}: Call type ("Telephony" or "VOIP")
*@{IncomingNAP}: Name of the NAP that originated this call (incoming call leg's NAP name).
Note: Supported on release 2.7 and up only.
*@{NAP}: Name of the NAP this call leg is from
*@{OriginatorName}: Direction of the call:
- "answer" (incoming call leg) - "originate" (outgoing call leg)
Note: In release 2.6 and earlier, the direction of the call is as follows:
- "originate" (incoming call leg) - "answer" (outgoing call leg)
In release 2.7, the CDR option "Reverse CDR call origin" in Gateway configuration provide the same values as in release 2.6.
*@{OriginalCalledNumber}: Original called number
Note: Supported on release 2.7 and up only.
*@{Protocol}: Type of protocol used ("SS7", "ISDN", or "SIP")
*@{RedirectingNumber}: Redirecting number
Note: Supported on release 2.7 and up only.
*@{TerminationCause}: Cause of the call termination, printed as an integer value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationCauseString}: Cause of the call termination, printed as a string value
*@{OriginalCause}: Original cause of the call termination, printed as a string value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationSource}: Identifies the cause of the leg termination:
- "TermInd": Terminating indication has been received on this leg
- "JoinedTermInd": Terminating indication has been received on the leg joined to current leg,
and has been forwarded to current leg
- "App": Call control application has asked to drop the call
- "Engine": Toolpack engine has decided to terminate this call
(generally due to local errors like disconnected TMedia)
*@{UserName}: Static value: 100.
*@{SipCallId}: Content of the "call-id" SIP header
*@{ChargeIndicator}: For TDM (SS7 and CAS R2); received charge indicator in Alert message.

=== Information related to media ===
*@{Codec}: Codec used for this call ("G711" for example)
*@{LocalMediaInfo}: Protocol type dependent information on the call leg (local information for SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port locally used for receiving RTP)
*@{LocalMediaIP}: For VOIP calls, RTP IP address locally used for this call leg.
*@{LocalMediaPort}: For VOIP calls, RTP UDP port locally used for this call leg.
*@{RemoteMediaInfo}: Protocol type dependent information on the call leg (remote information SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port TMedia is sending RTP to)
*@{RemoteMediaIP}: For VOIP calls, RTP IP address of the remote peer for this call leg.
*@{RemoteMediaPort}: For VOIP calls, RTP UDP port of the remote peer for this call leg.
*@{TimeslotNumber}: For TDM (Telephony) calls, timeslot number that this call was using for audio.
*@{TrunkName}: For TDM (Telephony) calls, name of the trunk that this call was using for audio.

=== Statistics ===
The following variables allow to print call statistics in the text CDR logs.

There are some restrictions, however:
* Available '''only in the "end" CDR entry'''
* Available in release 2.7.103 and above only

Example:
* Pkt=@{Stat:Rtp:Rx:Packets}/@{Stat:Rtp:Tx:Packets}, Err=@{Stat:Rtp:Rx:Errors}/@{Stat:Rtp:Tx:Errors}

Refer to the following page for the list of statistics: [[Call_statistics_format_B|Call statistics format]]

=== Information related to routing ===
*@{ApplicationName}: Name of the application that has written this log ("Gateway")
*@{RouteAttribute:attr}: Replaced by the value of a custom route attribute, for the selected
route. This will apply only to outgoing call legs that were made from routing.
Eligible route attributes are:
Route name: Use attribute "route_name". Ex: @{RouteAttribute:route_name}
Route set name: Use attribute "routeset_name". Ex: @{RouteAttribute:routeset_name}
Custom route attribute column: Use the custom attribute name. Ex: @{RouteAttribute:priority}
Routing script parameters: Use the route attribute name provided by routing script.
Ex: If script provides: route[:my_param]="myval"
Then it's included in CDR with @{RouteAttribute:my_param}]
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.
*@{ScriptAttribute:attr}: Replaced by the value of a routing script attribute stored in params[:bridge].
This will apply for incoming and outgoing call legs.
Eligible script attributes are:
Custom CDR value: Use attribute "CustomCdrValue". Ex: @{ScriptAttribute:CustomCdrValue}
Script parameters: Use the attribute name provided by routing script.
Ex: If script provides: params[:bridge][:my_param]="myval"
Then it's included in CDR with @{ScriptAttribute:my_param}
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.

=== Deprecated values: ===
*@{MediaInfo}: Same as @{RemoteMediaInfo}
*@{RemoteIP}: Same as @{RemoteMediaIP}
*@{RemotePort}: Same as @{RemoteMediaPort}

== CDR sample ==
=== Text CDR sample ===
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP',Protocol='SIP',Direction='answer'
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP2',Protocol='SIP',Direction='originate'
2013-02-07 10:19:07.562-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',TerminationSource='App',Calling='',Called='123',NAP='NAP_SIP2',Direction='originate'
2013-02-07 10:19:07.656-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',Termination Source='App',Calling='',Called='123',NAP='NAP_SIP',Direction='answer'

=== Radius AAA sample ===
* [[File:TelcoBridges_RADIUS_Auth&Acct.pcap|TelcoBridges_RADIUS_Auth&Acct.pcap]]
* [[File:TelcoBridges_RADIUS_Auth&Acct.txt|TelcoBridges_RADIUS_Auth&Acct.txt]]

== Redundancy ==

In a [[TMG7800]] configuration, with redundant TMG-Control servers, or [[TMG3200]]/[[TMG800]] in 1+1 configuration, only the active server writes the CDR logs. Since the active server may change over time, CDR parsing must take into account that CDR logs may be found in files from the two servers.

The analysis of the logs for the purpose of extracting billing information must be done after combining the two logs, from both TMG-Control servers, sorting the entries by timestamp for example. See how to [[TMG:Retrieve_Text_CDR|Retrieve Text CDR here]].

== CDR entry loss due to switchover ==
In some situations (during HA switchover for example), some CDR entries may be lost.

The following guide lines provide information on how to deal with these corner cases:

[[Call_Detail_Records_Entry_Loss|Deal with CDR entries loss]]

== Retrieving Text CDRs ==

There are 2 ways to retrieve the text CDR manually or automatically. The procedures are described in [[TMG:Retrieve_Text_CDR|Retrieve Text CDR]].

== Notes ==
*This mode of operation is not recommended for [[TMG800]] or [[TMG3200]] with a flash disk (last shipment January 2011). However, the [[TMG800]] or [[TMG3200]] with SATA or SSD disk option is OK (use command tbproduct: if the command can be executed, the disk is SATA or SSD).
*TelcoBridges does not recommend storing CDR logs via network file systems (NFS or other). We highly recommend writing to a local hard drive and have developed a background script that moves the gzipped log segments for backup or analysis.

== Related actions ==

'''Refer to the appropriate Toolpack release:'''
*[[Web_Portal_Tutorial_Guide_v2.7#CDR_.28Call_Detail_Record.29|Web Portal v2.7: CDR Configuration]]
*[[Web_Portal_Tutorial_Guide_v2.6#CDR_.28Call_Detail_Record.29|Web Portal v2.6: CDR Configuration]]

[[category:Needs revising]]

Custom SIP BYE headers format B

2015-11-27T21:34:58Z

Atremblay:

The custom SIP BYE headers field is formatted similarly to [[Text_Call_Detail_Records|Text CDR records]]. For example, the following content:

X-Test: This is a test.
P-RTP-Stat: PL=@{Stat:Rtp:Rx:Error:LostPackets}, DU=@{CallDuration}

Would put the following SIP headers in the BYE packet:

X-Test: This is a test.
P-RTP-Stat: PL=0, DU=12

For a call which lasted 12 seconds and had no packet loss.

For '''P-RTP-Stat''' SIP BYE headers, it is recommended to use the following content in release 2.9 and later:

P-RTP-Stat: PS=@{Stat:Rtp:Tx:IPPackets}, OS=@{Stat:Rtp:Tx:IPBytes}, PR=@{Stat:Rtp:Rx:IPPackets}, OR=@{Stat:Rtp:Rx:IPBytes}, PL=@{Stat:Rtp:Rx:Error:LostPackets}, JI=@{Stat:Rtcp:Jitter}, LA=@{Stat:Rtcp:RoundTripDelay}, DU=@{CallDuration}

The following link provides the statistics format: [[Call_statistics_format_B|Call statistics format]].

Here is the list of fields specific to SIP BYE headers:

{| class="wikitable"
|-
! Field name !! Description
|-
| @{CallDuration} || Call duration, in seconds
|-
| @{CallDurationMs} || Call duration, in milliseconds
|}

Custom SIP BYE headers format A

2015-11-27T21:34:11Z

Atremblay:

The custom SIP BYE headers field is formatted similarly to [[Text_Call_Detail_Records|Text CDR records]]. For example, the following content:

X-Test: This is a test.
P-RTP-Stat: PL=@{Stat:Rtp:Rx:Error:LostPackets}, DU=@{CallDuration}

Would put the following SIP headers in the BYE packet:

X-Test: This is a test.
P-RTP-Stat: PL=0, DU=12

For a call which lasted 12 seconds and had no packet loss.

For '''P-RTP-Stat''' SIP BYE headers, it is recommended to use the following content in release 2.8:

P-RTP-Stat: PS=@{Stat:Rtp:Tx:VoicePackets}, PR=@{Stat:Rtp:Rx:VoicePackets}, OR=@{Stat:Rtp:Rx:VoiceBytes}, PL=@{Stat:Rtp:Rx:Error:LostPackets}, JI=@{Stat:Rtcp:Jitter}, DU=@{CallDuration}

The following link provides the statistics format: [[Call_statistics_format_A|Call statistics format]].

Here is the list of fields specific to SIP BYE headers:

{| class="wikitable"
|-
! Field name !! Description
|-
| @{CallDuration} || Call duration, in seconds
|-
| @{CallDurationMs} || Call duration, in milliseconds
|}

Custom SIP BYE headers format A

2015-11-27T21:33:50Z

Atremblay:

The custom SIP BYE headers field is formatted similarly to [[Text_Call_Detail_Records|Text CDR records]]. For example, the following content:

X-Test: This is a test.
P-RTP-Stat: PL=@{Stat:Rtp:Rx:Error:LostPackets}, DU=@{CallDuration}

Would put the following SIP headers in the BYE packet:

X-Test: This is a test.
P-RTP-Stat: PL=0, DU=12

For a call which lasted 12 seconds and had no packet loss.

For P-RTP-Stat, it is recommended to use the following content in release 2.8:

P-RTP-Stat: PS=@{Stat:Rtp:Tx:VoicePackets}, PR=@{Stat:Rtp:Rx:VoicePackets}, OR=@{Stat:Rtp:Rx:VoiceBytes}, PL=@{Stat:Rtp:Rx:Error:LostPackets}, JI=@{Stat:Rtcp:Jitter}, DU=@{CallDuration}

The following link provides the statistics format: [[Call_statistics_format_A|Call statistics format]].

Here is the list of fields specific to SIP BYE headers:

{| class="wikitable"
|-
! Field name !! Description
|-
| @{CallDuration} || Call duration, in seconds
|-
| @{CallDurationMs} || Call duration, in milliseconds
|}

Call statistics format A

2015-11-27T21:31:48Z

Atremblay:

{| class="wikitable"
|-
! Field name !! Description
|-
| colspan="2" style="text-align: center;" | '''Receive statistics'''
|-
| @{Stat:Rtp:Rx} || Summary of the Rx stats (Packets;CNPackets;SignalingPackets;Errors)
|-
| @{Stat:Rtp:Rx:Packets} || Number of packets received from the IP network (audio + comfort noise + signaling)
|-
| @{Stat:Rtp:Rx:VoicePackets} || Number of voice (audio) packets received from the IP network
|-
| @{Stat:Rtp:Rx:VoiceBytes} || Number of payload bytes from voice (audio) packets received from the IP network
|-
| @{Stat:Rtp:Rx:CNPackets} || Number of comfort noise packets received from the IP network
|-
| @{Stat:Rtp:Rx:SignalingPackets} || Number of signaling packets (like "Telephony events") received from the IP network
|-
| @{Stat:Rtp:Rx:RFC2833Tones} || Number of RFC2833 tones received from the IP network, and played back to TDM
|-
| @{Stat:Rtp:Rx:RedundantPackets} || Number of redundant packets received from the IP network (same sequence number received more than once)
|-
| @{Stat:Rtp:Rx:MeanPower} || Mean audio power (from IP to TDM direction), in dBov (0 the loudest, negative is softer level). Available only for calls with Echo cancellation enabled, thus only TDM<->IP calls.
|-
| @{Stat:Rtp:Rx:VoiceDuration} || Duration (in seconds) of voice (audio), from IP to TDM direction
|-
| @{Stat:Rtp:Rx:PlayoutDelay} || Current IP to TDM audio delay in millisecond (adaptive jitter buffer delay)
|-
| @{Stat:Rtp:Rx:MaxPlayoutDelay} || Maximum (for the whole call) IP to TDM audio delay in millisecond (adaptive jitter buffer delay)
|-
| @{Stat:Rtp:Rx:SsrcChanges} || Number of changes of "SSRC" RTP header value (counting initial SSRC received as one)
|-
| @{Stat:Rtp:Rx:Concealments} || Number of times decoder made audio concealment to preserve audio continuity (frequent upon first packet of a call, or after RFC2833 tones)
|-
| @{Stat:Rtp:Rx:Echo:ERLLevel} || Attenuation of a signal from the received-out port to the send-in port of an echo canceller
|-
| @{Stat:Rtp:Rx:Error:BufOverflows} || Number of packets dropped due to jitter buffer adaptation (to keep play-out delay low)
|-
| @{Stat:Rtp:Rx:Error:SeqErrors} || Number of sequence errors detected among packets received from the IP network
|-
| @{Stat:Rtp:Rx:Error:BadPackets} || Number of packets received with invalid header, or other error preventing proper audio decoding
|-
| @{Stat:Rtp:Rx:Error:RFC2833BadPackets: || Number of RFC2833 signaling packets that could not be properly decoded
|-
| @{Stat:Rtp:Rx:Error:LatePackets} || Number of packets that arrived after the moment they should have started to be played-out to TDM
|-
| @{Stat:Rtp:Rx:Error:LostPackets} || Number of packets considered "lost" (never received for play-out to TDM)
|-
| @{Stat:Rtp:Rx:Errors} || Total of all "Rtp:Rx:Error:" statistics above
|-
| colspan="2" style="text-align: center;" | '''Transmit statistics'''
|-
| @{Stat:Rtp:Tx} || Summary of the Tx stats (Packets;CNPackets;SignalingPackets;Errors)
|-
| @{Stat:Rtp:Tx:Packets} || Number of packets sent to the IP network (audio + comfort noise + signaling)
|-
| @{Stat:Rtp:Tx:VoicePackets} || Number of voice (audio) packets sent to the IP network
|-
| @{Stat:Rtp:Tx:CNPackets} || Number of comfort noise packets sent to the IP network
|-
| @{Stat:Rtp:Tx:SignalingPackets} || Number of signaling packets (like "Telephony events") sent to the IP network
|-
| @{Stat:Rtp:Tx:RFC2833Tones} || Number of RFC2833 tones sent to the IP network (relaying corresponding detected TDM tones)
|-
| @{Stat:Rtp:Tx:MeanPower} || Mean audio power (from TDM to IP direction), in dBov (0 the loudest, negative is softer level). Available only for calls with Echo cancellation enabled, thus only TDM<->IP calls.
|-
| @{Stat:Rtp:Tx:VoiceDuration} || Duration (in seconds) of voice (audio), from TDM to IP direction
|-
| @{Stat:Rtp:Tx:Echo:ACOMLevel} || Attenuation of a signal from the receive-out port to the send-out port of an echo canceller
|-
| @{Stat:Rtp:Tx:Error:LostPackets} || Number of packets considered "lost" by remote side (only available if RTCP is used)
|-
| @{Stat:Rtp:Tx:Error:ArpFailure} || Number of failures to ARP remote IP address to send RTP packets to (preventing sending any packets)
|-
| @{Stat:Rtp:Tx:Errors} || Total of all "Rtp:Tx:Error:" statistics above
|-
| colspan="2" style="text-align: center;" | '''RTCP statistics (only if RTCP is enabled on the profile)'''
|-
| @{Stat:Rtcp} || Summary of the Rtcp stats (Packets;LostPackets;Jitter)
|-
| @{Stat:Rtcp:Packets} || Number of packets reported as received by remote equipment
|-
| @{Stat:Rtcp:LostPackets} || Number of packets reported as lost by remote equipment
|-
| @{Stat:Rtcp:Jitter} || Inter-packet interval jitter, in millisecond
|-
| colspan="2" style="text-align: center;" | '''T38 statistics'''
|-
| @{Stat:T38:StateChanges} || Number of T.38 state changes, through T.30 negotiation between FAX machines
|-
| @{Stat:T38:Rx || Summary of the Rx stats (Pages;Packets;Errors)
|-
| @{Stat:T38:Rx:Pages} || Number of FAX pages received from T.38 packets from the IP network
|-
| @{Stat:T38:Rx:Packets} || Number of T.38 packets received from the IP network
|-
| @{Stat:T38:Rx:Bytes} || Number of T.38 payload bytes from T.38 packets received from the IP network
|-
| @{Stat:T38:Rx:Duration} || Duration of the T.38 session from IP to TDM
|-
| @{Stat:T38:Rx:PlayoutDelay} || Current IP to TDM audio delay in millisecond (re-modulation and jitter buffer delay)
|-
| @{Stat:T38:Rx:MaxPlayoutDelay} || Maximum IP to TDM audio delay in millisecond (re-modulation and jitter buffer delay)
|-
| @{Stat:T38:Rx:Error:BufOverflows} || Number of packets dropped because "from IP" jitter buffer is full
|-
| @{Stat:T38:Rx:Error:BufUnderflows} || Number of times T.38 re-modulation to TDM had no data (received from IP) to re-modulate
|-
| @{Stat:T38:Rx:Error:SeqErrors} || Number of sequence errors detected among packets received from the IP network
|-
| @{Stat:T38:Rx:Error:BadPackets} || Number of packets received with invalid header, or other error preventing proper audio decoding
|-
| @{Stat:T38:Rx:Errors} || Total of all "T38:Rx:Error:" statistics above
|-
| @{Stat:T38:Tx} || Summary of the Tx stats (Pages;Packets)
|-
| @{Stat:T38:Tx:Pages} || Number of FAX pages received from TDM, sent to T.38 packets to the IP network
|-
| @{Stat:T38:Tx:Packets} || Number of T.38 packets sent to the IP network
|-
| @{Stat:T38:Tx:Bytes} || Number of T.38 payload bytes from T.38 packets sent to the IP network
|-
| @{Stat:T38:Tx:Duration} || Duration of the T.38 session from TDM to IP
|-
| @{Stat:T38:FromTdm:MeanPower} || Mean audio power received from TDM side, in dBov (0 the loudest, negative is softer level)
|-
| colspan="2" style="text-align: center;" | '''TMS-IP statistics (only for calls joined to a call leg on another adapter, and that used TMS-IP to carry audio from one adapter to the other)'''
|-
| @{Stat:TmsIp} || Summary of the TMS-IP stats (Packets;Errors)
|-
| @{Stat:TmsIp:Packets || Number of TMS-IP packets received from the other joined call leg
|-
| @{Stat:TmsIp:Bytes || Number of TMS-IP bytes received from the other joined call leg
|-
| @{Stat:TmsIp:Duration || Duration (in seconds) of the TMS-IP connection
|-
| @{Stat:TmsIp:Error:BufOverflows || Number of TMS-IP packets dropped due to jitter buffer overflow
|-
| @{Stat:TmsIp:Error:SeqErrors || Number of TMS-IP packet sequence errors detected among packets received from the IP network
|-
| @{Stat:TmsIp:Error:BadPackets || Number of TMS-IP packets received with invalid header, or other error preventing proper audio decoding
|-
| @{Stat:TmsIp:Error:LatePackets || Number of TMS-IP packets that arrived too late, causing jitter buffer underrun
|-
| @{Stat:TmsIp:Error:LostPackets || Number of TMS-IP packets considered "lost" (never received)
|-
| @{Stat:TmsIp:Errors} || Total of all "TmsIp:Error:" statistics above
|}

Call statistics format B

2015-11-27T21:31:16Z

Atremblay: Created page with "{| class="wikitable" |- ! Field name !! Description |- | colspan="2" style="text-align: center;" | '''Receive statistics''' |- | @{Stat:Rtp:Rx} || Sum..."

{| class="wikitable"
|-
! Field name !! Description
|-
| colspan="2" style="text-align: center;" | '''Receive statistics'''
|-
| @{Stat:Rtp:Rx} || Summary of the Rx stats (Packets;CNPackets;SignalingPackets;Errors)
|-
| @{Stat:Rtp:Rx:Packets} || Number of packets received from the IP network (audio + comfort noise + signaling)
|-
| @{Stat:Rtp:Rx:VoicePackets} || Number of voice (audio) packets received from the IP network
|-
| @{Stat:Rtp:Rx:VoiceBytes} || Number of payload bytes from voice (audio) packets received from the IP network
|-
| @{Stat:Rtp:Rx:CNPackets} || Number of comfort noise packets received from the IP network
|-
| @{Stat:Rtp:Rx:SignalingPackets} || Number of signaling packets (like "Telephony events") received from the IP network
|-
| @{Stat:Rtp:Rx:IPPackets} || Number of packets received from the IP network
|-
| @{Stat:Rtp:Rx:IPBytes} || Number of bytes received from the IP network
|-
| @{Stat:Rtp:Rx:RFC2833Tones} || Number of RFC2833 tones received from the IP network, and played back to TDM
|-
| @{Stat:Rtp:Rx:RedundantPackets} || Number of redundant packets received from the IP network (same sequence number received more than once)
|-
| @{Stat:Rtp:Rx:MeanPower} || Mean audio power (from IP to TDM direction), in dBov (0 the loudest, negative is softer level). Available only for calls with Echo cancellation enabled, thus only TDM<->IP calls.
|-
| @{Stat:Rtp:Rx:VoiceDuration} || Duration (in seconds) of voice (audio), from IP to TDM direction
|-
| @{Stat:Rtp:Rx:PlayoutDelay} || Current IP to TDM audio delay in millisecond (adaptive jitter buffer delay)
|-
| @{Stat:Rtp:Rx:MaxPlayoutDelay} || Maximum (for the whole call) IP to TDM audio delay in millisecond (adaptive jitter buffer delay)
|-
| @{Stat:Rtp:Rx:SsrcChanges} || Number of changes of "SSRC" RTP header value (counting initial SSRC received as one)
|-
| @{Stat:Rtp:Rx:Concealments} || Number of times decoder made audio concealment to preserve audio continuity (frequent upon first packet of a call, or after RFC2833 tones)
|-
| @{Stat:Rtp:Rx:Echo:ERLLevel} || Attenuation of a signal from the received-out port to the send-in port of an echo canceller
|-
| @{Stat:Rtp:Rx:Error:BufOverflows} || Number of packets dropped due to jitter buffer adaptation (to keep play-out delay low)
|-
| @{Stat:Rtp:Rx:Error:SeqErrors} || Number of sequence errors detected among packets received from the IP network
|-
| @{Stat:Rtp:Rx:Error:BadPackets} || Number of packets received with invalid header, or other error preventing proper audio decoding
|-
| @{Stat:Rtp:Rx:Error:RFC2833BadPackets: || Number of RFC2833 signaling packets that could not be properly decoded
|-
| @{Stat:Rtp:Rx:Error:LatePackets} || Number of packets that arrived after the moment they should have started to be played-out to TDM
|-
| @{Stat:Rtp:Rx:Error:LostPackets} || Number of packets considered "lost" (never received for play-out to TDM)
|-
| @{Stat:Rtp:Rx:Errors} || Total of all "Rtp:Rx:Error:" statistics above
|-
| colspan="2" style="text-align: center;" | '''Transmit statistics'''
|-
| @{Stat:Rtp:Tx} || Summary of the Tx stats (Packets;CNPackets;SignalingPackets;Errors)
|-
| @{Stat:Rtp:Tx:Packets} || Number of packets sent to the IP network (audio + comfort noise + signaling)
|-
| @{Stat:Rtp:Tx:VoicePackets} || Number of voice (audio) packets sent to the IP network
|-
| @{Stat:Rtp:Tx:CNPackets} || Number of comfort noise packets sent to the IP network
|-
| @{Stat:Rtp:Tx:SignalingPackets} || Number of signaling packets (like "Telephony events") sent to the IP network
|-
| @{Stat:Rtp:Tx:IPPackets} || Number of packets sent to the IP network
|-
| @{Stat:Rtp:Tx:IPBytes} || Number of bytes sent to the IP network
|-
| @{Stat:Rtp:Tx:RFC2833Tones} || Number of RFC2833 tones sent to the IP network (relaying corresponding detected TDM tones)
|-
| @{Stat:Rtp:Tx:MeanPower} || Mean audio power (from TDM to IP direction), in dBov (0 the loudest, negative is softer level). Available only for calls with Echo cancellation enabled, thus only TDM<->IP calls.
|-
| @{Stat:Rtp:Tx:VoiceDuration} || Duration (in seconds) of voice (audio), from TDM to IP direction
|-
| @{Stat:Rtp:Tx:Echo:ACOMLevel} || Attenuation of a signal from the receive-out port to the send-out port of an echo canceller
|-
| @{Stat:Rtp:Tx:Error:LostPackets} || Number of packets considered "lost" by remote side (only available if RTCP is used)
|-
| @{Stat:Rtp:Tx:Error:ArpFailure} || Number of failures to ARP remote IP address to send RTP packets to (preventing sending any packets)
|-
| @{Stat:Rtp:Tx:Errors} || Total of all "Rtp:Tx:Error:" statistics above
|-
| colspan="2" style="text-align: center;" | '''RTCP statistics (only if RTCP is enabled on the profile)'''
|-
| @{Stat:Rtcp} || Summary of the Rtcp stats (Packets;LostPackets;Jitter)
|-
| @{Stat:Rtcp:Packets} || Number of packets reported as received by remote equipment
|-
| @{Stat:Rtcp:LostPackets} || Number of packets reported as lost by remote equipment
|-
| @{Stat:Rtcp:Jitter} || Inter-packet interval jitter, in millisecond
|-
| @{Stat:Rtcp:RoundTripDelay} || Round-trip delay in milliseconds. Requires extended RTCP (XRTCP) to be enabled.
|-
| colspan="2" style="text-align: center;" | '''T38 statistics'''
|-
| @{Stat:T38:StateChanges} || Number of T.38 state changes, through T.30 negotiation between FAX machines
|-
| @{Stat:T38:Rx || Summary of the Rx stats (Pages;Packets;Errors)
|-
| @{Stat:T38:Rx:Pages} || Number of FAX pages received from T.38 packets from the IP network
|-
| @{Stat:T38:Rx:Packets} || Number of T.38 packets received from the IP network
|-
| @{Stat:T38:Rx:Bytes} || Number of T.38 payload bytes from T.38 packets received from the IP network
|-
| @{Stat:T38:Rx:Duration} || Duration of the T.38 session from IP to TDM
|-
| @{Stat:T38:Rx:PlayoutDelay} || Current IP to TDM audio delay in millisecond (re-modulation and jitter buffer delay)
|-
| @{Stat:T38:Rx:MaxPlayoutDelay} || Maximum IP to TDM audio delay in millisecond (re-modulation and jitter buffer delay)
|-
| @{Stat:T38:Rx:Error:BufOverflows} || Number of packets dropped because "from IP" jitter buffer is full
|-
| @{Stat:T38:Rx:Error:BufUnderflows} || Number of times T.38 re-modulation to TDM had no data (received from IP) to re-modulate
|-
| @{Stat:T38:Rx:Error:SeqErrors} || Number of sequence errors detected among packets received from the IP network
|-
| @{Stat:T38:Rx:Error:BadPackets} || Number of packets received with invalid header, or other error preventing proper audio decoding
|-
| @{Stat:T38:Rx:Errors} || Total of all "T38:Rx:Error:" statistics above
|-
| @{Stat:T38:Tx} || Summary of the Tx stats (Pages;Packets)
|-
| @{Stat:T38:Tx:Pages} || Number of FAX pages received from TDM, sent to T.38 packets to the IP network
|-
| @{Stat:T38:Tx:Packets} || Number of T.38 packets sent to the IP network
|-
| @{Stat:T38:Tx:Bytes} || Number of T.38 payload bytes from T.38 packets sent to the IP network
|-
| @{Stat:T38:Tx:Duration} || Duration of the T.38 session from TDM to IP
|-
| @{Stat:T38:FromTdm:MeanPower} || Mean audio power received from TDM side, in dBov (0 the loudest, negative is softer level)
|-
| colspan="2" style="text-align: center;" | '''TMS-IP statistics (only for calls joined to a call leg on another adapter, and that used TMS-IP to carry audio from one adapter to the other)'''
|-
| @{Stat:TmsIp} || Summary of the TMS-IP stats (Packets;Errors)
|-
| @{Stat:TmsIp:Packets || Number of TMS-IP packets received from the other joined call leg
|-
| @{Stat:TmsIp:Bytes || Number of TMS-IP bytes received from the other joined call leg
|-
| @{Stat:TmsIp:Duration || Duration (in seconds) of the TMS-IP connection
|-
| @{Stat:TmsIp:Error:BufOverflows || Number of TMS-IP packets dropped due to jitter buffer overflow
|-
| @{Stat:TmsIp:Error:SeqErrors || Number of TMS-IP packet sequence errors detected among packets received from the IP network
|-
| @{Stat:TmsIp:Error:BadPackets || Number of TMS-IP packets received with invalid header, or other error preventing proper audio decoding
|-
| @{Stat:TmsIp:Error:LatePackets || Number of TMS-IP packets that arrived too late, causing jitter buffer underrun
|-
| @{Stat:TmsIp:Error:LostPackets || Number of TMS-IP packets considered "lost" (never received)
|-
| @{Stat:TmsIp:Errors} || Total of all "TmsIp:Error:" statistics above
|}

Custom SIP BYE headers format B

2015-11-27T21:12:43Z

Atremblay: Created page with "The custom SIP BYE headers field is formatted similarly to Text CDR records. For example, the following content: X-Test: This is a test. P-RTP-..."

Modify SIP profile C

2015-11-27T21:12:23Z

Atremblay: /* List of Parameters */

=== '''''Applies to version v2.8''''' ===

{{DISPLAYTITLE:Modifying SIP Profile Settings}}
 

'''To configure SIP settings, do the following:'''

 

1- Click '''SIP''' in the Editing Profile window, to display the customizable options.

[[Image:ProfilesVoipSip_0.png]]

2- Modify settings as required.
* Click '''Save'''

[[Image:ProfilesVoipSip_1.png]]

==List of Parameters==
SIP
* [[Parameter: SIP: Use SIP strict routing|Use SIP strict routing]]
* [[Parameter: SIP: Detect 180 with SDP as early media|Detect 180 with SDP as early media]]
* [[Parameter: SIP: Send 180 with SDP|Send 180 with SDP]]
* [[Parameter: SIP: Don't forward 183 progress|Don't forward 183 progress]]
* [[Parameter: SIP: Use non ambiguous From tag|Use non ambiguous From tag]]
* [[Parameter: SIP: Use reason header|Use reason header]]
* [[Parameter: SIP: Use isup-oli format|Use isup-oli format]]
* [[Parameter: SIP: Enable SIP Custom Headers|Enable SIP Custom Headers]]
* [[Parameter: SIP: Forward SS7 suspend/resume|Forward SS7 suspend/resume]]
* [[Parameter: SIP: Forward SS7 CPG hold/retrieval|Forward SS7 CPG hold/retrieval]]
* [[Parameter: SIP: Forward SIP hold type|Forward SIP hold type]]
* [[Parameter: SIP: Max Forwards header handling|Max Forwards header handling]]
* [[Parameter: SIP: User-to-User encoding|User-to-User encoding]]
* [[Parameter: SIP: SDP generation options|SDP generation options]]
* [[Parameter: SIP: SDP combining options|SDP combining options]]
* [[Parameter: SIP: Insert custom SIP BYE headers|Insert custom SIP BYE headers]]

Call statistics format A

2015-11-27T21:10:11Z

Atremblay:

{| class="wikitable"
|-
! Field name !! Description
|-
| @{Stat:Rtp:Rx} || Summary of the Rx stats (Packets;CNPackets;SignalingPackets;Errors)
|-
| @{Stat:Rtp:Rx:Packets} || Number of packets received from the IP network (audio + comfort noise + signaling)
|-
| @{Stat:Rtp:Rx:VoicePackets} || Number of voice (audio) packets received from the IP network
|-
| @{Stat:Rtp:Rx:VoiceBytes} || Number of payload bytes from voice (audio) packets received from the IP network
|-
| @{Stat:Rtp:Rx:CNPackets} || Number of comfort noise packets received from the IP network
|-
| @{Stat:Rtp:Rx:SignalingPackets} || Number of signaling packets (like "Telephony events") received from the IP network
|-
| @{Stat:Rtp:Rx:RFC2833Tones} || Number of RFC2833 tones received from the IP network, and played back to TDM
|-
| @{Stat:Rtp:Rx:RedundantPackets} || Number of redundant packets received from the IP network (same sequence number received more than once)
|-
| @{Stat:Rtp:Rx:MeanPower} || Mean audio power (from IP to TDM direction), in dBov (0 the loudest, negative is softer level). Available only for calls with Echo cancellation enabled, thus only TDM<->IP calls.
|-
| @{Stat:Rtp:Rx:VoiceDuration} || Duration (in seconds) of voice (audio), from IP to TDM direction
|-
| @{Stat:Rtp:Rx:PlayoutDelay} || Current IP to TDM audio delay in millisecond (adaptive jitter buffer delay)
|-
| @{Stat:Rtp:Rx:MaxPlayoutDelay} || Maximum (for the whole call) IP to TDM audio delay in millisecond (adaptive jitter buffer delay)
|-
| @{Stat:Rtp:Rx:SsrcChanges} || Number of changes of "SSRC" RTP header value (counting initial SSRC received as one)
|-
| @{Stat:Rtp:Rx:Concealments} || Number of times decoder made audio concealment to preserve audio continuity (frequent upon first packet of a call, or after RFC2833 tones)
|-
| @{Stat:Rtp:Rx:Echo:ERLLevel} || Attenuation of a signal from the received-out port to the send-in port of an echo canceller
|-
| @{Stat:Rtp:Rx:Error:BufOverflows} || Number of packets dropped due to jitter buffer adaptation (to keep play-out delay low)
|-
| @{Stat:Rtp:Rx:Error:SeqErrors} || Number of sequence errors detected among packets received from the IP network
|-
| @{Stat:Rtp:Rx:Error:BadPackets} || Number of packets received with invalid header, or other error preventing proper audio decoding
|-
| @{Stat:Rtp:Rx:Error:RFC2833BadPackets: || Number of RFC2833 signaling packets that could not be properly decoded
|-
| @{Stat:Rtp:Rx:Error:LatePackets} || Number of packets that arrived after the moment they should have started to be played-out to TDM
|-
| @{Stat:Rtp:Rx:Error:LostPackets} || Number of packets considered "lost" (never received for play-out to TDM)
|-
| @{Stat:Rtp:Rx:Errors} || Total of all "Rtp:Rx:Error:" statistics above
|-
| @{Stat:Rtp:Tx} || Summary of the Tx stats (Packets;CNPackets;SignalingPackets;Errors)
|-
| @{Stat:Rtp:Tx:Packets} || Number of packets sent to the IP network (audio + comfort noise + signaling)
|-
| @{Stat:Rtp:Tx:VoicePackets} || Number of voice (audio) packets sent to the IP network
|-
| @{Stat:Rtp:Tx:CNPackets} || Number of comfort noise packets sent to the IP network
|-
| @{Stat:Rtp:Tx:SignalingPackets} || Number of signaling packets (like "Telephony events") sent to the IP network
|-
| @{Stat:Rtp:Tx:RFC2833Tones} || Number of RFC2833 tones sent to the IP network (relaying corresponding detected TDM tones)
|-
| @{Stat:Rtp:Tx:MeanPower} || Mean audio power (from TDM to IP direction), in dBov (0 the loudest, negative is softer level). Available only for calls with Echo cancellation enabled, thus only TDM<->IP calls.
|-
| @{Stat:Rtp:Tx:VoiceDuration} || Duration (in seconds) of voice (audio), from TDM to IP direction
|-
| @{Stat:Rtp:Tx:Echo:ACOMLevel} || Attenuation of a signal from the receive-out port to the send-out port of an echo canceller
|-
| @{Stat:Rtp:Tx:Error:LostPackets} || Number of packets considered "lost" by remote side (only available if RTCP is used)
|-
| @{Stat:Rtp:Tx:Error:ArpFailure} || Number of failures to ARP remote IP address to send RTP packets to (preventing sending any packets)
|-
| @{Stat:Rtp:Tx:Errors} || Total of all "Rtp:Tx:Error:" statistics above
|-
| @{Stat:Rtcp} || Summary of the Rtcp stats (Packets;LostPackets;Jitter)
|-
| @{Stat:Rtcp:Packets} || Number of packets reported as received by remote equipment
|-
| @{Stat:Rtcp:LostPackets} || Number of packets reported as lost by remote equipment
|-
| @{Stat:Rtcp:Jitter} || Inter-packet interval jitter, in millisecond
|-
| @{Stat:T38:StateChanges} || Number of T.38 state changes, through T.30 negotiation between FAX machines
|-
| @{Stat:T38:Rx || Summary of the Rx stats (Pages;Packets;Errors)
|-
| @{Stat:T38:Rx:Pages} || Number of FAX pages received from T.38 packets from the IP network
|-
| @{Stat:T38:Rx:Packets} || Number of T.38 packets received from the IP network
|-
| @{Stat:T38:Rx:Bytes} || Number of T.38 payload bytes from T.38 packets received from the IP network
|-
| @{Stat:T38:Rx:Duration} || Duration of the T.38 session from IP to TDM
|-
| @{Stat:T38:Rx:PlayoutDelay} || Current IP to TDM audio delay in millisecond (re-modulation and jitter buffer delay)
|-
| @{Stat:T38:Rx:MaxPlayoutDelay} || Maximum IP to TDM audio delay in millisecond (re-modulation and jitter buffer delay)
|-
| @{Stat:T38:Rx:Error:BufOverflows} || Number of packets dropped because "from IP" jitter buffer is full
|-
| @{Stat:T38:Rx:Error:BufUnderflows} || Number of times T.38 re-modulation to TDM had no data (received from IP) to re-modulate
|-
| @{Stat:T38:Rx:Error:SeqErrors} || Number of sequence errors detected among packets received from the IP network
|-
| @{Stat:T38:Rx:Error:BadPackets} || Number of packets received with invalid header, or other error preventing proper audio decoding
|-
| @{Stat:T38:Rx:Errors} || Total of all "T38:Rx:Error:" statistics above
|-
| @{Stat:T38:Tx} || Summary of the Tx stats (Pages;Packets)
|-
| @{Stat:T38:Tx:Pages} || Number of FAX pages received from TDM, sent to T.38 packets to the IP network
|-
| @{Stat:T38:Tx:Packets} || Number of T.38 packets sent to the IP network
|-
| @{Stat:T38:Tx:Bytes} || Number of T.38 payload bytes from T.38 packets sent to the IP network
|-
| @{Stat:T38:Tx:Duration} || Duration of the T.38 session from TDM to IP
|-
| @{Stat:T38:FromTdm:MeanPower} || Mean audio power received from TDM side, in dBov (0 the loudest, negative is softer level)
|-
| @{Stat:TmsIp} || Summary of the TMS-IP stats (Packets;Errors)
|-
| @{Stat:TmsIp:Packets || Number of TMS-IP packets received from the other joined call leg
|-
| @{Stat:TmsIp:Bytes || Number of TMS-IP bytes received from the other joined call leg
|-
| @{Stat:TmsIp:Duration || Duration (in seconds) of the TMS-IP connection
|-
| @{Stat:TmsIp:Error:BufOverflows || Number of TMS-IP packets dropped due to jitter buffer overflow
|-
| @{Stat:TmsIp:Error:SeqErrors || Number of TMS-IP packet sequence errors detected among packets received from the IP network
|-
| @{Stat:TmsIp:Error:BadPackets || Number of TMS-IP packets received with invalid header, or other error preventing proper audio decoding
|-
| @{Stat:TmsIp:Error:LatePackets || Number of TMS-IP packets that arrived too late, causing jitter buffer underrun
|-
| @{Stat:TmsIp:Error:LostPackets || Number of TMS-IP packets considered "lost" (never received)
|-
| @{Stat:TmsIp:Errors} || Total of all "TmsIp:Error:" statistics above
|}

Call statistics format A

2015-11-27T21:10:00Z

Atremblay: Created page with "{| class="wikitable" |- ! Field name !! Description |- | @{Stat:Rtp:Rx || Summary of the Rx stats (Packets;CNPackets;SignalingPackets;Errors) |- | @{..."

{| class="wikitable"
|-
! Field name !! Description
|-
| @{Stat:Rtp:Rx || Summary of the Rx stats (Packets;CNPackets;SignalingPackets;Errors)
|-
| @{Stat:Rtp:Rx:Packets} || Number of packets received from the IP network (audio + comfort noise + signaling)
|-
| @{Stat:Rtp:Rx:VoicePackets} || Number of voice (audio) packets received from the IP network
|-
| @{Stat:Rtp:Rx:VoiceBytes} || Number of payload bytes from voice (audio) packets received from the IP network
|-
| @{Stat:Rtp:Rx:CNPackets} || Number of comfort noise packets received from the IP network
|-
| @{Stat:Rtp:Rx:SignalingPackets} || Number of signaling packets (like "Telephony events") received from the IP network
|-
| @{Stat:Rtp:Rx:RFC2833Tones} || Number of RFC2833 tones received from the IP network, and played back to TDM
|-
| @{Stat:Rtp:Rx:RedundantPackets} || Number of redundant packets received from the IP network (same sequence number received more than once)
|-
| @{Stat:Rtp:Rx:MeanPower} || Mean audio power (from IP to TDM direction), in dBov (0 the loudest, negative is softer level). Available only for calls with Echo cancellation enabled, thus only TDM<->IP calls.
|-
| @{Stat:Rtp:Rx:VoiceDuration} || Duration (in seconds) of voice (audio), from IP to TDM direction
|-
| @{Stat:Rtp:Rx:PlayoutDelay} || Current IP to TDM audio delay in millisecond (adaptive jitter buffer delay)
|-
| @{Stat:Rtp:Rx:MaxPlayoutDelay} || Maximum (for the whole call) IP to TDM audio delay in millisecond (adaptive jitter buffer delay)
|-
| @{Stat:Rtp:Rx:SsrcChanges} || Number of changes of "SSRC" RTP header value (counting initial SSRC received as one)
|-
| @{Stat:Rtp:Rx:Concealments} || Number of times decoder made audio concealment to preserve audio continuity (frequent upon first packet of a call, or after RFC2833 tones)
|-
| @{Stat:Rtp:Rx:Echo:ERLLevel} || Attenuation of a signal from the received-out port to the send-in port of an echo canceller
|-
| @{Stat:Rtp:Rx:Error:BufOverflows} || Number of packets dropped due to jitter buffer adaptation (to keep play-out delay low)
|-
| @{Stat:Rtp:Rx:Error:SeqErrors} || Number of sequence errors detected among packets received from the IP network
|-
| @{Stat:Rtp:Rx:Error:BadPackets} || Number of packets received with invalid header, or other error preventing proper audio decoding
|-
| @{Stat:Rtp:Rx:Error:RFC2833BadPackets: || Number of RFC2833 signaling packets that could not be properly decoded
|-
| @{Stat:Rtp:Rx:Error:LatePackets} || Number of packets that arrived after the moment they should have started to be played-out to TDM
|-
| @{Stat:Rtp:Rx:Error:LostPackets} || Number of packets considered "lost" (never received for play-out to TDM)
|-
| @{Stat:Rtp:Rx:Errors} || Total of all "Rtp:Rx:Error:" statistics above
|-
| @{Stat:Rtp:Tx} || Summary of the Tx stats (Packets;CNPackets;SignalingPackets;Errors)
|-
| @{Stat:Rtp:Tx:Packets} || Number of packets sent to the IP network (audio + comfort noise + signaling)
|-
| @{Stat:Rtp:Tx:VoicePackets} || Number of voice (audio) packets sent to the IP network
|-
| @{Stat:Rtp:Tx:CNPackets} || Number of comfort noise packets sent to the IP network
|-
| @{Stat:Rtp:Tx:SignalingPackets} || Number of signaling packets (like "Telephony events") sent to the IP network
|-
| @{Stat:Rtp:Tx:RFC2833Tones} || Number of RFC2833 tones sent to the IP network (relaying corresponding detected TDM tones)
|-
| @{Stat:Rtp:Tx:MeanPower} || Mean audio power (from TDM to IP direction), in dBov (0 the loudest, negative is softer level). Available only for calls with Echo cancellation enabled, thus only TDM<->IP calls.
|-
| @{Stat:Rtp:Tx:VoiceDuration} || Duration (in seconds) of voice (audio), from TDM to IP direction
|-
| @{Stat:Rtp:Tx:Echo:ACOMLevel} || Attenuation of a signal from the receive-out port to the send-out port of an echo canceller
|-
| @{Stat:Rtp:Tx:Error:LostPackets} || Number of packets considered "lost" by remote side (only available if RTCP is used)
|-
| @{Stat:Rtp:Tx:Error:ArpFailure} || Number of failures to ARP remote IP address to send RTP packets to (preventing sending any packets)
|-
| @{Stat:Rtp:Tx:Errors} || Total of all "Rtp:Tx:Error:" statistics above
|-
| @{Stat:Rtcp} || Summary of the Rtcp stats (Packets;LostPackets;Jitter)
|-
| @{Stat:Rtcp:Packets} || Number of packets reported as received by remote equipment
|-
| @{Stat:Rtcp:LostPackets} || Number of packets reported as lost by remote equipment
|-
| @{Stat:Rtcp:Jitter} || Inter-packet interval jitter, in millisecond
|-
| @{Stat:T38:StateChanges} || Number of T.38 state changes, through T.30 negotiation between FAX machines
|-
| @{Stat:T38:Rx || Summary of the Rx stats (Pages;Packets;Errors)
|-
| @{Stat:T38:Rx:Pages} || Number of FAX pages received from T.38 packets from the IP network
|-
| @{Stat:T38:Rx:Packets} || Number of T.38 packets received from the IP network
|-
| @{Stat:T38:Rx:Bytes} || Number of T.38 payload bytes from T.38 packets received from the IP network
|-
| @{Stat:T38:Rx:Duration} || Duration of the T.38 session from IP to TDM
|-
| @{Stat:T38:Rx:PlayoutDelay} || Current IP to TDM audio delay in millisecond (re-modulation and jitter buffer delay)
|-
| @{Stat:T38:Rx:MaxPlayoutDelay} || Maximum IP to TDM audio delay in millisecond (re-modulation and jitter buffer delay)
|-
| @{Stat:T38:Rx:Error:BufOverflows} || Number of packets dropped because "from IP" jitter buffer is full
|-
| @{Stat:T38:Rx:Error:BufUnderflows} || Number of times T.38 re-modulation to TDM had no data (received from IP) to re-modulate
|-
| @{Stat:T38:Rx:Error:SeqErrors} || Number of sequence errors detected among packets received from the IP network
|-
| @{Stat:T38:Rx:Error:BadPackets} || Number of packets received with invalid header, or other error preventing proper audio decoding
|-
| @{Stat:T38:Rx:Errors} || Total of all "T38:Rx:Error:" statistics above
|-
| @{Stat:T38:Tx} || Summary of the Tx stats (Pages;Packets)
|-
| @{Stat:T38:Tx:Pages} || Number of FAX pages received from TDM, sent to T.38 packets to the IP network
|-
| @{Stat:T38:Tx:Packets} || Number of T.38 packets sent to the IP network
|-
| @{Stat:T38:Tx:Bytes} || Number of T.38 payload bytes from T.38 packets sent to the IP network
|-
| @{Stat:T38:Tx:Duration} || Duration of the T.38 session from TDM to IP
|-
| @{Stat:T38:FromTdm:MeanPower} || Mean audio power received from TDM side, in dBov (0 the loudest, negative is softer level)
|-
| @{Stat:TmsIp} || Summary of the TMS-IP stats (Packets;Errors)
|-
| @{Stat:TmsIp:Packets || Number of TMS-IP packets received from the other joined call leg
|-
| @{Stat:TmsIp:Bytes || Number of TMS-IP bytes received from the other joined call leg
|-
| @{Stat:TmsIp:Duration || Duration (in seconds) of the TMS-IP connection
|-
| @{Stat:TmsIp:Error:BufOverflows || Number of TMS-IP packets dropped due to jitter buffer overflow
|-
| @{Stat:TmsIp:Error:SeqErrors || Number of TMS-IP packet sequence errors detected among packets received from the IP network
|-
| @{Stat:TmsIp:Error:BadPackets || Number of TMS-IP packets received with invalid header, or other error preventing proper audio decoding
|-
| @{Stat:TmsIp:Error:LatePackets || Number of TMS-IP packets that arrived too late, causing jitter buffer underrun
|-
| @{Stat:TmsIp:Error:LostPackets || Number of TMS-IP packets considered "lost" (never received)
|-
| @{Stat:TmsIp:Errors} || Total of all "TmsIp:Error:" statistics above
|}

Custom SIP BYE headers format A

2015-11-27T21:03:41Z

Atremblay: Created page with "The custom SIP BYE headers field is formatted similarly to Text CDR records. For example, the following content: X-Test: This is a test. P-RTP-..."

Parameter: SIP: Insert custom SIP BYE headers

2015-11-27T20:50:46Z

Atremblay: Created page with "Insert custom SIP BYE headers as defined by the following ''Custom SIP BYE headers''. The ''Custom SIP BYE headers'' can be customized in order to send custom SIP BYE headers ..."

Insert custom SIP BYE headers as defined by the following ''Custom SIP BYE headers''. The ''Custom SIP BYE headers'' can be customized in order to send custom SIP BYE headers with statistics and call information.

* [[Custom_SIP_BYE_headers_format_B|Custom SIP BYE headers format for Toolpack Web Portal Version 2.9]]
* [[Custom_SIP_BYE_headers_format_A|Custom SIP BYE headers format for Toolpack Web Portal Version 2.8]]

[[Category:Parameters]]

Routing script tutorial:Mini Development Guide

2015-10-16T12:51:04Z

Atremblay: Added better description of contact fields

== Call object ==

=== Get ===

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

called_number = caf_call.get :called

=== List_params ===

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

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

=== Accept ===

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

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

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

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

caf_call.refuse :reason => :temporary_failure

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

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "[[Routing_script_tutorial:Mini_Development_Guide#Reason_values|Reason values]]".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object. For example

called_number = call[:called]

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

SIP:Remote-party-id - privacy 

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

SIP:P-asserted-identity - cpc 

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

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

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

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

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

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

SIP:Remote-party-id - display-name 

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

SIP:Remote-party-id - user-info 

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

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| 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 
|-
| called_isub 
| Q931: 'Called party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - subaddress information 
| SIP:To - isub parameter 
| 
| 2.7 
|-
| called_isub_type 
| Q931: 'Called party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - type of subaddress 
| SIP:To - isub-encoding parameter 
| 
| 2.7 
|-
| calling_isub 
| Q931: 'Calling party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - subaddress information 
| SIP:From - isub 
| 
| 2.7 
|-
| calling_isub_type 
| Q931: 'Callinf party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - type of subaddress 
| SIP:From - isub-encoding 
| 
| 2.7 
|-
| ss7_fci_default 
| N/A 
| N/A 
| Default 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
(Line Service or T1/E1 trunk) 
| Incoming leg line service name 
| Incoming leg line service name 
| Incoming leg line service name 
| N/A 
| (read-only) 
| 2.7 
|-
| tdm_timeslot_nb 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| N/A 
| (read-only) 
| 2.7 
|-
| rtp_local_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_local_port 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP port 
| (read-only) 
| 2.7 
|-
| rtp_remote_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_remote_port 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP port 
| (read-only) 
| 2.7 
|-
| ss7_cot_enabled 
| N/A 
| N/A 
| Requests SS7 in-call continuity test for this outgoing SS7 call 
| N/A 
| Toolpack will request 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_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 UDP 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 UDP port 
| (read-only) 
| 2.8.13 
|}

 

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

=== Noa values ===

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

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

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

or

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

=== Npi values ===

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

=== Calling Display Type values ===

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

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

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

or

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

=== Calling Display value ===

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

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

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

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

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

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

=== Redirecting indicator values ===

SS7:

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

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

ISDN:

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

SS7:

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

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

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

=== Information Transfer Capability values ===

information_transfer_capability:

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

=== redirecting_number_forward_enabled values ===

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

Values for this parameter are "0", "1", "false" or "true.
*0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg
*1/true: Redirecting number (and original called number) is forwarded to outgoing call leg

The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

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:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

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

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

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

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

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

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

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

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

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

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

=== MLPP Precedence values ===

mlpp_look_for_busy:

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

mlpp_precedence_level:

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

mlpp_network_identity:

3 digits value from 0 to 999

mlpp_service_domain:

24 bits value from 0 to 16777215

=== ISUB subaddress information values ===

called_isub_type:
calling_isub_type:

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

called_isub:
calling_isub:

Digits for the subaddress information.

== Route parameters ==

All route may have these parameters:

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

Example:

route[:remapped_nap]

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

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts (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)

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

=== Tone string format ===

All tone strings (:announcement_tone, :busy_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
Optional 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: [[Customer_application_framework:play_audio_files#Play_path_format|Path format]]

==== Example 1 ====
The following example will play file1.wav once, and then play file2.wav in loop:
"file1.wav,file2.wav:-1"

==== Example 2 ====
The following example will play file1.wav from start offset of 1 second to end offset of 3 seconds, then twice file2.wav from second 5 to second 10.
"file1.wav:0:1000:3000,file2.wav:2:5000:10000"

==== Example 3 ====
The following example will play file1.wav once, ending at 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 to enable tone detection 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

=== 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 apply when params[:bridge][:ring_tone] is not used, because it also apply to ring tone playback configured in the Web Portal, from the incoming call's profile.

=== 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 ====
===== disconnect_tone_answer =====
params[:bridge][:disconnect_tone_answer] = "yes"

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

===== 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:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

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

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

==== 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: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Controlling UUI (user-to-user information) 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 or not 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 [[#Refuse|an exception must be raised]] with reason :authorization_required.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Redirection ==
In release 2.8, redirection contacts are obtained from the routing engine in the following format:
* <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. For instance: <code>"nil,0,0,2"</code> describes the following example contact hierarchy:
* 1234 <sip:1234@test.com>
|- 1234 <sip:1234@other.com>
`- 5555 <sip:5555@test.com>
`- 5555 <sip:5555@final.com>

== Terminating calls ==
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>:
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>

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

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

Reason cause strings available inside routing scripts:

List of Q.850 reason causes:
:unallocated_number
:no_route_to_network
:no_route_to_destination
:send_special_tone
:misdialled_trunk_prefix
:channel_unacceptable
:call_awarded_in_established_channel
:preemption
:reattempt
:ported_number
:normal_call_clearing
:user_busy
:no_user_responding
:no_answer_from_user
:subscriber_absent
:call_rejected
:number_changed
:redirection
:exchange_routing_error
:non_selected_user_clearing
:destination_out_of_order
:address_incomplete
:facility_rejected
:response_to_status_enquiry
:normal_unspecified
:no_circuit_available
:network_out_of_order
:frame_mode_out_of_service
:frame_mode_connection_operational
:temporary_failure
:switching_equipment_congestion
:access_information_discarded
: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
:not_compatible_with_call_state
:ie_non_existent
:invalid_ie_content
:message_not_compatible
:recovery_on_timer_expiry
:parameter_non_existent_passed_on
:msg_with_non_recognized_param_discarded
:protocol_error
:interworking_unspecified

List of toolpack reason causes:

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

List of SIP reason causes: 
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 ==

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

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

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

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

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

asr_statistics_struct_global_asr_percent

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

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

=== Test parameters ===
==== @call_params ====

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

 

==== @nap_list ====

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

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

 

==== @params ====

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

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

 

----

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

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2015-10-16T12:26:50Z

Atremblay: Added missing SIP reason causes

== Call object ==

=== Get ===

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

called_number = caf_call.get :called

=== List_params ===

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

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

=== Accept ===

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

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

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

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

caf_call.refuse :reason => :temporary_failure

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

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "[[Routing_script_tutorial:Mini_Development_Guide#Reason_values|Reason values]]".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object. For example

called_number = call[:called]

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

SIP:Remote-party-id - privacy 

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

SIP:P-asserted-identity - cpc 

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

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

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

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

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

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

SIP:Remote-party-id - display-name 

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

SIP:Remote-party-id - user-info 

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

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| 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 
|-
| called_isub 
| Q931: 'Called party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - subaddress information 
| SIP:To - isub parameter 
| 
| 2.7 
|-
| called_isub_type 
| Q931: 'Called party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - type of subaddress 
| SIP:To - isub-encoding parameter 
| 
| 2.7 
|-
| calling_isub 
| Q931: 'Calling party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - subaddress information 
| SIP:From - isub 
| 
| 2.7 
|-
| calling_isub_type 
| Q931: 'Callinf party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - type of subaddress 
| SIP:From - isub-encoding 
| 
| 2.7 
|-
| ss7_fci_default 
| N/A 
| N/A 
| Default 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
(Line Service or T1/E1 trunk) 
| Incoming leg line service name 
| Incoming leg line service name 
| Incoming leg line service name 
| N/A 
| (read-only) 
| 2.7 
|-
| tdm_timeslot_nb 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| N/A 
| (read-only) 
| 2.7 
|-
| rtp_local_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_local_port 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP port 
| (read-only) 
| 2.7 
|-
| rtp_remote_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_remote_port 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP port 
| (read-only) 
| 2.7 
|-
| ss7_cot_enabled 
| N/A 
| N/A 
| Requests SS7 in-call continuity test for this outgoing SS7 call 
| N/A 
| Toolpack will request 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_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 UDP 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 UDP port 
| (read-only) 
| 2.8.13 
|}

 

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

=== Noa values ===

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

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

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

or

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

=== Npi values ===

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

=== Calling Display Type values ===

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

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

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

or

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

=== Calling Display value ===

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

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

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

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

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

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

=== Redirecting indicator values ===

SS7:

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

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

ISDN:

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

SS7:

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

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

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

=== Information Transfer Capability values ===

information_transfer_capability:

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

=== redirecting_number_forward_enabled values ===

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

Values for this parameter are "0", "1", "false" or "true.
*0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg
*1/true: Redirecting number (and original called number) is forwarded to outgoing call leg

The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

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:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

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

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

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

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

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

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

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

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

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

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

=== MLPP Precedence values ===

mlpp_look_for_busy:

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

mlpp_precedence_level:

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

mlpp_network_identity:

3 digits value from 0 to 999

mlpp_service_domain:

24 bits value from 0 to 16777215

=== ISUB subaddress information values ===

called_isub_type:
calling_isub_type:

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

called_isub:
calling_isub:

Digits for the subaddress information.

== Route parameters ==

All route may have these parameters:

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

Example:

route[:remapped_nap]

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

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts (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)

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

=== Tone string format ===

All tone strings (:announcement_tone, :busy_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
Optional 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: [[Customer_application_framework:play_audio_files#Play_path_format|Path format]]

==== Example 1 ====
The following example will play file1.wav once, and then play file2.wav in loop:
"file1.wav,file2.wav:-1"

==== Example 2 ====
The following example will play file1.wav from start offset of 1 second to end offset of 3 seconds, then twice file2.wav from second 5 to second 10.
"file1.wav:0:1000:3000,file2.wav:2:5000:10000"

==== Example 3 ====
The following example will play file1.wav once, ending at 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 to enable tone detection 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

=== 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 apply when params[:bridge][:ring_tone] is not used, because it also apply to ring tone playback configured in the Web Portal, from the incoming call's profile.

=== 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 ====
===== disconnect_tone_answer =====
params[:bridge][:disconnect_tone_answer] = "yes"

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

===== 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:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

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

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

==== 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: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Controlling UUI (user-to-user information) 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 or not 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 [[#Refuse|an exception must be raised]] with reason :authorization_required.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Redirection ==
In release 2.8, redirection contacts are obtained from the routing engine in the following format:
* <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
** <code>:ported_number</code> - the called number that was ported (if available)
** <code>:sip_uri</code> - the SIP URI of the contact (if available)
** <code>:raw_data</code> - the raw data representing the contact in the signaling protocol
** <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. For instance: <code>"nil,0,0,2"</code> describes the following example contact hierarchy:
* 1234 <sip:1234@test.com>
|- 1234 <sip:1234@other.com>
`- 5555 <sip:5555@test.com>
`- 5555 <sip:5555@final.com>

== Terminating calls ==
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>:
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>

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

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

Reason cause strings available inside routing scripts:

List of Q.850 reason causes:
:unallocated_number
:no_route_to_network
:no_route_to_destination
:send_special_tone
:misdialled_trunk_prefix
:channel_unacceptable
:call_awarded_in_established_channel
:preemption
:reattempt
:ported_number
:normal_call_clearing
:user_busy
:no_user_responding
:no_answer_from_user
:subscriber_absent
:call_rejected
:number_changed
:redirection
:exchange_routing_error
:non_selected_user_clearing
:destination_out_of_order
:address_incomplete
:facility_rejected
:response_to_status_enquiry
:normal_unspecified
:no_circuit_available
:network_out_of_order
:frame_mode_out_of_service
:frame_mode_connection_operational
:temporary_failure
:switching_equipment_congestion
:access_information_discarded
: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
:not_compatible_with_call_state
:ie_non_existent
:invalid_ie_content
:message_not_compatible
:recovery_on_timer_expiry
:parameter_non_existent_passed_on
:msg_with_non_recognized_param_discarded
:protocol_error
:interworking_unspecified

List of toolpack reason causes:

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

List of SIP reason causes: 
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 ==

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

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

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

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

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

asr_statistics_struct_global_asr_percent

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

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

=== Test parameters ===
==== @call_params ====

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

 

==== @nap_list ====

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

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

 

==== @params ====

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

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

 

----

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

[[category:Needs revising]]

Toolpack prerequisite CentOS5 A

2015-09-04T18:31:22Z

Atremblay: /* CentOS update */

This page shows the prerequisites to install Toolpack 2-5, 2-6, 2-7 or 2-8 for a 64 bits CentOS 5.5 to 5.11 with the use of TelcoBridges repository.


''WARNING'': The host MUST have at least CentOS 5.5 installed. If you don't want to update your CentOS version to the latest version or want to install the prerequisites for a I386 (32 bits) platform, please follow the [[Toolpack prerequisite CentOS5 2-5 manual| manual procedure]] instead.



''WARNING'': If you followed the [[Toolpack prerequisite CentOS5 2-5 manual| manual procedure]] on the system before, you '''MUST NOT''' use the steps on this page before doing a cleanup of the previously installed files. You should ask Telcobridges support for help with the cleanup.



''WARNING'': This procedure requires internet access and a DNS configured on your unit.


== Stop toolpack system (if it is running) ==

tbtoolpack stop

== TelcoBridges repository ==

Add TelcoBridges repository file

vim /etc/yum.repos.d/TB-Base.repo

Paste the following information in that file:

# TelcoBridges-Base.repo
#
# This repository is using TelcoBridges frozen version of CentOS
# to help client installing the required version of the
# applications required to run Toolpack
#

[tb-base]
name=TelcoBridges-$releasever - Base
baseurl=http://repo.telcobridges.com/centos/5/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5-tb

#released updates
[tb-updates]
name=TelcoBridges-$releasever - Updates
baseurl=http://repo.telcobridges.com/centos/5/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5-tb

== Get TelcoBridges repository key ==

cd /etc/pki/rpm-gpg/
wget http://repo.telcobridges.com/centos/RPM-GPG-KEY-CentOS-5
rpm --import RPM-GPG-KEY-CentOS-5
wget http://repo.telcobridges.com/centos/RPM-GPG-KEY-CentOS-5-tb
rpm --import RPM-GPG-KEY-CentOS-5-tb

== CentOS update ==

Update your system to the latest CentOS 5 version.

yum clean metadata
yum update

If you have the following error:

warning: rpmts_HdrFromFdno: Header V4 DSA signature: NOKEY, key ID c8bf9d3a
Public key for package.rpm is not installed

Make sure that you have the correct gpgkey lines in /etc/yum.repos.d/TB-Base.repo and that the TelcoBridges keys are properly imported.

=== Reply to ARP only on local interfaces ===

Modify the file /etc/sysctl.conf to add the following lines:

net.ipv4.conf.default.arp_ignore=1
net.ipv4.conf.all.arp_ignore=1

Then restart network interfaces using the following command:

/etc/init.d/network restart

=== Disabling SELinux ===

Check SELinux status

sestatus

If SELinux is enable, see the [[SELinux_management|Disabling SELinux]] article to disable it.

== Install Toolpack Prerequisites ==

When asked to 'Importing GPG key', answer yes.

yum groupinstall Toolpack-Prerequisites

==== Possible Dependencies Issue ====
If you meet an issue which blocks the installation with error that is related to "dovecot". Do the following and retry the "groupinstall" command to restart installation.

yum remove dovecot

=== Install Gem ===

wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/bin/linux/bundler-1.2.3.gem
gem install --local ./bundler-1.2.3.gem

wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/bin/linux/json-1.7.7.gem
gem install --local ./json-1.7.7.gem

== Apply kernel patches (if any) ==

shutdown -r now

Once rebooted, be sure that Toolpack system is stopped before manipulating MySQL.

tbtoolpack stop

=== Configure ODBC ===

vim /etc/odbcinst.ini

Remove the '#' in front of each lines of the [MySQL] section Modify the 'Driver' line to set the correct driver

Example for 32 bits system:

[MySQL]
Description = ODBC for MySQL
Driver = /usr/lib/libmyodbc5.so
Setup = /usr/lib/libodbcmyS.so
FileUsage = 1

 Example for 64 bits system:

[MySQL]
Description = ODBC for MySQL
Driver = /usr/lib64/libmyodbc5.so
Setup = /usr/lib64/libodbcmyS.so
FileUsage = 1

=== Configure MySQL ===

vim /etc/my.cnf

Add these variables in the file under the [mysqld] section:

*log-bin
*server-id=''[UniqueId]''

The server-id needs to be a non-zero unique value (do not use 0). If you use the host redundancy feature, the value needs to be different on each host .

 Add max_allowed_packet to increase the maximum size of binary blobs in the database. Make sure it is in the [mysqld] section AND [mysqldump] section

max_allowed_packet = 200MB

 Add below to remove database dependencies with DNS servers '''(**Applicable to TMG users only)'''

skip-name-resolve

 Add this to make sure the mysql logs don't get too big

expire_logs_days=60

Example:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
log-bin
server-id=5876
max_allowed_packet = 200MB
expire_logs_days=60

# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# Added so that problems with DNS servers don't cause problems with the mysql DB
# Note: This is applicable only if you are using a TMG
skip-name-resolve

[mysqldump]
max_allowed_packet = 200MB

=== Start MySQL ===

service mysqld start

=== Configure MySQL Users ===

*Set password for the root user to 'tbdbpw' (TelcoBridges recommends that you set your own password for root)
*Enable root connection from localhost only
*Create a tbdb user (required by Toolpack)
*Remove anonymous connection

Example:

/usr/bin/mysqladmin -u root password tbdbpw

mysql -uroot -ptbdbpw
DELETE FROM mysql.user WHERE !(Host = 'localhost' AND User = 'root');
FLUSH PRIVILEGES;
CREATE USER 'tbdb'@'%' IDENTIFIED BY 'tbdbpw';
GRANT ALL PRIVILEGES ON *.* TO 'tbdb'@'%' IDENTIFIED BY 'tbdbpw';
FLUSH PRIVILEGES;
exit

== Toolpack Development Prerequisite (Optional) ==

The Toolpack System Development prerequisite section is only required for customers that will develop their own application using the Toolpack API:

yum install gcc-c++ libxml2-devel libpcap-devel unixODBC-devel libaio libaio-devel

== Validation Guide (highly recommended) ==

If you would like to verify your installation go to the [[Toolpack Installation:Validate Toolpack Installation 2-5|Toolpack Validation Guide]]

 

== Toolpack System installation ==

Now that the prerequisite are installed, now it is time to install the [[Toolpack installer 2-4|Toolpack system]]

Toolpack prerequisite CentOS5 A

2015-09-04T18:30:46Z

Atremblay: Import the keys immediately

This page shows the prerequisites to install Toolpack 2-5, 2-6, 2-7 or 2-8 for a 64 bits CentOS 5.5 to 5.11 with the use of TelcoBridges repository.


''WARNING'': The host MUST have at least CentOS 5.5 installed. If you don't want to update your CentOS version to the latest version or want to install the prerequisites for a I386 (32 bits) platform, please follow the [[Toolpack prerequisite CentOS5 2-5 manual| manual procedure]] instead.



''WARNING'': If you followed the [[Toolpack prerequisite CentOS5 2-5 manual| manual procedure]] on the system before, you '''MUST NOT''' use the steps on this page before doing a cleanup of the previously installed files. You should ask Telcobridges support for help with the cleanup.



''WARNING'': This procedure requires internet access and a DNS configured on your unit.


== Stop toolpack system (if it is running) ==

tbtoolpack stop

== TelcoBridges repository ==

Add TelcoBridges repository file

vim /etc/yum.repos.d/TB-Base.repo

Paste the following information in that file:

# TelcoBridges-Base.repo
#
# This repository is using TelcoBridges frozen version of CentOS
# to help client installing the required version of the
# applications required to run Toolpack
#

[tb-base]
name=TelcoBridges-$releasever - Base
baseurl=http://repo.telcobridges.com/centos/5/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5-tb

#released updates
[tb-updates]
name=TelcoBridges-$releasever - Updates
baseurl=http://repo.telcobridges.com/centos/5/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5-tb

== Get TelcoBridges repository key ==

cd /etc/pki/rpm-gpg/
wget http://repo.telcobridges.com/centos/RPM-GPG-KEY-CentOS-5
rpm --import RPM-GPG-KEY-CentOS-5
wget http://repo.telcobridges.com/centos/RPM-GPG-KEY-CentOS-5-tb
rpm --import RPM-GPG-KEY-CentOS-5-tb

== CentOS update ==

Update your system to the latest CentOS 5 version.

yum clean metadata
yum update

If you have the following error:

warning: rpmts_HdrFromFdno: Header V4 DSA signature: NOKEY, key ID c8bf9d3a
Public key for package.rpm is not installed

Make sure that you have the correct gpgkey lines in /etc/yum.repos.d/TB-Base.repo

=== Reply to ARP only on local interfaces ===

Modify the file /etc/sysctl.conf to add the following lines:

net.ipv4.conf.default.arp_ignore=1
net.ipv4.conf.all.arp_ignore=1

Then restart network interfaces using the following command:

/etc/init.d/network restart

=== Disabling SELinux ===

Check SELinux status

sestatus

If SELinux is enable, see the [[SELinux_management|Disabling SELinux]] article to disable it.

== Install Toolpack Prerequisites ==

When asked to 'Importing GPG key', answer yes.

yum groupinstall Toolpack-Prerequisites

==== Possible Dependencies Issue ====
If you meet an issue which blocks the installation with error that is related to "dovecot". Do the following and retry the "groupinstall" command to restart installation.

yum remove dovecot

=== Install Gem ===

wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/bin/linux/bundler-1.2.3.gem
gem install --local ./bundler-1.2.3.gem

wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/bin/linux/json-1.7.7.gem
gem install --local ./json-1.7.7.gem

== Apply kernel patches (if any) ==

shutdown -r now

Once rebooted, be sure that Toolpack system is stopped before manipulating MySQL.

tbtoolpack stop

=== Configure ODBC ===

vim /etc/odbcinst.ini

Remove the '#' in front of each lines of the [MySQL] section Modify the 'Driver' line to set the correct driver

Example for 32 bits system:

[MySQL]
Description = ODBC for MySQL
Driver = /usr/lib/libmyodbc5.so
Setup = /usr/lib/libodbcmyS.so
FileUsage = 1

 Example for 64 bits system:

[MySQL]
Description = ODBC for MySQL
Driver = /usr/lib64/libmyodbc5.so
Setup = /usr/lib64/libodbcmyS.so
FileUsage = 1

=== Configure MySQL ===

vim /etc/my.cnf

Add these variables in the file under the [mysqld] section:

*log-bin
*server-id=''[UniqueId]''

The server-id needs to be a non-zero unique value (do not use 0). If you use the host redundancy feature, the value needs to be different on each host .

 Add max_allowed_packet to increase the maximum size of binary blobs in the database. Make sure it is in the [mysqld] section AND [mysqldump] section

max_allowed_packet = 200MB

 Add below to remove database dependencies with DNS servers '''(**Applicable to TMG users only)'''

skip-name-resolve

 Add this to make sure the mysql logs don't get too big

expire_logs_days=60

Example:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
log-bin
server-id=5876
max_allowed_packet = 200MB
expire_logs_days=60

# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# Added so that problems with DNS servers don't cause problems with the mysql DB
# Note: This is applicable only if you are using a TMG
skip-name-resolve

[mysqldump]
max_allowed_packet = 200MB

=== Start MySQL ===

service mysqld start

=== Configure MySQL Users ===

*Set password for the root user to 'tbdbpw' (TelcoBridges recommends that you set your own password for root)
*Enable root connection from localhost only
*Create a tbdb user (required by Toolpack)
*Remove anonymous connection

Example:

/usr/bin/mysqladmin -u root password tbdbpw

mysql -uroot -ptbdbpw
DELETE FROM mysql.user WHERE !(Host = 'localhost' AND User = 'root');
FLUSH PRIVILEGES;
CREATE USER 'tbdb'@'%' IDENTIFIED BY 'tbdbpw';
GRANT ALL PRIVILEGES ON *.* TO 'tbdb'@'%' IDENTIFIED BY 'tbdbpw';
FLUSH PRIVILEGES;
exit

== Toolpack Development Prerequisite (Optional) ==

The Toolpack System Development prerequisite section is only required for customers that will develop their own application using the Toolpack API:

yum install gcc-c++ libxml2-devel libpcap-devel unixODBC-devel libaio libaio-devel

== Validation Guide (highly recommended) ==

If you would like to verify your installation go to the [[Toolpack Installation:Validate Toolpack Installation 2-5|Toolpack Validation Guide]]

 

== Toolpack System installation ==

Now that the prerequisite are installed, now it is time to install the [[Toolpack installer 2-4|Toolpack system]]

Toolpack prerequisite CentOS5 A

2015-09-04T18:22:45Z

Atremblay: Changed GPG key path for the 'os' directory in TB-Base.repo because of internal infrastructure changes

This page shows the prerequisites to install Toolpack 2-5, 2-6, 2-7 or 2-8 for a 64 bits CentOS 5.5 to 5.11 with the use of TelcoBridges repository.


''WARNING'': The host MUST have at least CentOS 5.5 installed. If you don't want to update your CentOS version to the latest version or want to install the prerequisites for a I386 (32 bits) platform, please follow the [[Toolpack prerequisite CentOS5 2-5 manual| manual procedure]] instead.



''WARNING'': If you followed the [[Toolpack prerequisite CentOS5 2-5 manual| manual procedure]] on the system before, you '''MUST NOT''' use the steps on this page before doing a cleanup of the previously installed files. You should ask Telcobridges support for help with the cleanup.



''WARNING'': This procedure requires internet access and a DNS configured on your unit.


== Stop toolpack system (if it is running) ==

tbtoolpack stop

== TelcoBridges repository ==

Add TelcoBridges repository file

vim /etc/yum.repos.d/TB-Base.repo

Paste the following information in that file:

# TelcoBridges-Base.repo
#
# This repository is using TelcoBridges frozen version of CentOS
# to help client installing the required version of the
# applications required to run Toolpack
#

[tb-base]
name=TelcoBridges-$releasever - Base
baseurl=http://repo.telcobridges.com/centos/5/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5-tb

#released updates
[tb-updates]
name=TelcoBridges-$releasever - Updates
baseurl=http://repo.telcobridges.com/centos/5/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5-tb

== Get TelcoBridges repository key ==

cd /etc/pki/rpm-gpg/
wget http://repo.telcobridges.com/centos/RPM-GPG-KEY-CentOS-5
wget http://repo.telcobridges.com/centos/RPM-GPG-KEY-CentOS-5-tb

== CentOS update ==

Update your system to the latest CentOS 5 version.

yum clean metadata
yum update

If you have the following error:

warning: rpmts_HdrFromFdno: Header V4 DSA signature: NOKEY, key ID c8bf9d3a
Public key for package.rpm is not installed

Make sure that you have the correct gpgkey lines in /etc/yum.repos.d/TB-Base.repo

=== Reply to ARP only on local interfaces ===

Modify the file /etc/sysctl.conf to add the following lines:

net.ipv4.conf.default.arp_ignore=1
net.ipv4.conf.all.arp_ignore=1

Then restart network interfaces using the following command:

/etc/init.d/network restart

=== Disabling SELinux ===

Check SELinux status

sestatus

If SELinux is enable, see the [[SELinux_management|Disabling SELinux]] article to disable it.

== Install Toolpack Prerequisites ==

When asked to 'Importing GPG key', answer yes.

yum groupinstall Toolpack-Prerequisites

==== Possible Dependencies Issue ====
If you meet an issue which blocks the installation with error that is related to "dovecot". Do the following and retry the "groupinstall" command to restart installation.

yum remove dovecot

=== Install Gem ===

wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/bin/linux/bundler-1.2.3.gem
gem install --local ./bundler-1.2.3.gem

wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/bin/linux/json-1.7.7.gem
gem install --local ./json-1.7.7.gem

== Apply kernel patches (if any) ==

shutdown -r now

Once rebooted, be sure that Toolpack system is stopped before manipulating MySQL.

tbtoolpack stop

=== Configure ODBC ===

vim /etc/odbcinst.ini

Remove the '#' in front of each lines of the [MySQL] section Modify the 'Driver' line to set the correct driver

Example for 32 bits system:

[MySQL]
Description = ODBC for MySQL
Driver = /usr/lib/libmyodbc5.so
Setup = /usr/lib/libodbcmyS.so
FileUsage = 1

 Example for 64 bits system:

[MySQL]
Description = ODBC for MySQL
Driver = /usr/lib64/libmyodbc5.so
Setup = /usr/lib64/libodbcmyS.so
FileUsage = 1

=== Configure MySQL ===

vim /etc/my.cnf

Add these variables in the file under the [mysqld] section:

*log-bin
*server-id=''[UniqueId]''

The server-id needs to be a non-zero unique value (do not use 0). If you use the host redundancy feature, the value needs to be different on each host .

 Add max_allowed_packet to increase the maximum size of binary blobs in the database. Make sure it is in the [mysqld] section AND [mysqldump] section

max_allowed_packet = 200MB

 Add below to remove database dependencies with DNS servers '''(**Applicable to TMG users only)'''

skip-name-resolve

 Add this to make sure the mysql logs don't get too big

expire_logs_days=60

Example:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
log-bin
server-id=5876
max_allowed_packet = 200MB
expire_logs_days=60

# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# Added so that problems with DNS servers don't cause problems with the mysql DB
# Note: This is applicable only if you are using a TMG
skip-name-resolve

[mysqldump]
max_allowed_packet = 200MB

=== Start MySQL ===

service mysqld start

=== Configure MySQL Users ===

*Set password for the root user to 'tbdbpw' (TelcoBridges recommends that you set your own password for root)
*Enable root connection from localhost only
*Create a tbdb user (required by Toolpack)
*Remove anonymous connection

Example:

/usr/bin/mysqladmin -u root password tbdbpw

mysql -uroot -ptbdbpw
DELETE FROM mysql.user WHERE !(Host = 'localhost' AND User = 'root');
FLUSH PRIVILEGES;
CREATE USER 'tbdb'@'%' IDENTIFIED BY 'tbdbpw';
GRANT ALL PRIVILEGES ON *.* TO 'tbdb'@'%' IDENTIFIED BY 'tbdbpw';
FLUSH PRIVILEGES;
exit

== Toolpack Development Prerequisite (Optional) ==

The Toolpack System Development prerequisite section is only required for customers that will develop their own application using the Toolpack API:

yum install gcc-c++ libxml2-devel libpcap-devel unixODBC-devel libaio libaio-devel

== Validation Guide (highly recommended) ==

If you would like to verify your installation go to the [[Toolpack Installation:Validate Toolpack Installation 2-5|Toolpack Validation Guide]]

 

== Toolpack System installation ==

Now that the prerequisite are installed, now it is time to install the [[Toolpack installer 2-4|Toolpack system]]

Routing script tutorial:Mini Development Guide

2015-04-28T18:51:44Z

Atremblay: Added redirection and terminating calls sections

== Call object ==

=== Get ===

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

called_number = caf_call.get :called

=== List_params ===

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

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

=== Accept ===

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

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

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

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

caf_call.refuse :reason => :temporary_failure

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

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "[[Routing_script_tutorial:Mini_Development_Guide#Reason_values|Reason values]]".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object. For example

called_number = call[:called]

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

SIP:Remote-party-id - privacy 

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

SIP:P-asserted-identity - cpc 

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

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

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

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

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

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

SIP:Remote-party-id - display-name 

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

SIP:Remote-party-id - user-info 

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

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| 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 
|-
| called_isub 
| Q931: 'Called party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - subaddress information 
| SIP:To - isub parameter 
| 
| 2.7 
|-
| called_isub_type 
| Q931: 'Called party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - type of subaddress 
| SIP:To - isub-encoding parameter 
| 
| 2.7 
|-
| calling_isub 
| Q931: 'Calling party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - subaddress information 
| SIP:From - isub 
| 
| 2.7 
|-
| calling_isub_type 
| Q931: 'Callinf party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - type of subaddress 
| SIP:From - isub-encoding 
| 
| 2.7 
|-
| ss7_fci_default 
| N/A 
| N/A 
| Default 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
(Line Service or T1/E1 trunk) 
| Incoming leg line service name 
| Incoming leg line service name 
| Incoming leg line service name 
| N/A 
| (read-only) 
| 2.7 
|-
| tdm_timeslot_nb 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| N/A 
| (read-only) 
| 2.7 
|-
| rtp_local_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_local_port 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP port 
| (read-only) 
| 2.7 
|-
| rtp_remote_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_remote_port 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP port 
| (read-only) 
| 2.7 
|-
| ss7_cot_enabled 
| N/A 
| N/A 
| Requests SS7 in-call continuity test for this outgoing SS7 call 
| N/A 
| Toolpack will request 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_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 UDP 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 UDP port 
| (read-only) 
| 2.8.13 
|}

 

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

=== Noa values ===

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

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

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

or

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

=== Npi values ===

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

=== Calling Display Type values ===

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

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

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

or

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

=== Calling Display value ===

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

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

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

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

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

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

=== Redirecting indicator values ===

SS7:

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

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

ISDN:

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

SS7:

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

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

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

=== Information Transfer Capability values ===

information_transfer_capability:

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

=== redirecting_number_forward_enabled values ===

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

Values for this parameter are "0", "1", "false" or "true.
*0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg
*1/true: Redirecting number (and original called number) is forwarded to outgoing call leg

The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

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:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

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

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

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

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

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

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

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

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

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

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

=== MLPP Precedence values ===

mlpp_look_for_busy:

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

mlpp_precedence_level:

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

mlpp_network_identity:

3 digits value from 0 to 999

mlpp_service_domain:

24 bits value from 0 to 16777215

=== ISUB subaddress information values ===

called_isub_type:
calling_isub_type:

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

called_isub:
calling_isub:

Digits for the subaddress information.

== Route parameters ==

All route may have these parameters:

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

Example:

route[:remapped_nap]

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

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts (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)

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

=== Tone string format ===

All tone strings (:announcement_tone, :busy_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
Optional 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: [[Customer_application_framework:play_audio_files#Play_path_format|Path format]]

==== Example 1 ====
The following example will play file1.wav once, and then play file2.wav in loop:
"file1.wav,file2.wav:-1"

==== Example 2 ====
The following example will play file1.wav from start offset of 1 second to end offset of 3 seconds, then twice file2.wav from second 5 to second 10.
"file1.wav:0:1000:3000,file2.wav:2:5000:10000"

==== Example 3 ====
The following example will play file1.wav once, ending at 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.

=== 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 apply when params[:bridge][:ring_tone] is not used, because it also apply to ring tone playback configured in the Web Portal, from the incoming call's profile.

=== 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 ====
===== disconnect_tone_answer =====
params[:bridge][:disconnect_tone_answer] = "yes"

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

===== 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:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

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

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

==== 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:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** And all variables listed here: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Controlling UUI (user-to-user information) 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 or not 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 [[#Refuse|an exception must be raised]] with reason :authorization_required.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Redirection ==
In release 2.8, redirection contacts are obtained from the routing engine in the following format:
* <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
** <code>:ported_number</code> - the called number that was ported (if available)
** <code>:sip_uri</code> - the SIP URI of the contact (if available)
** <code>:raw_data</code> - the raw data representing the contact in the signaling protocol
** <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. For instance: <code>"nil,0,0,2"</code> describes the following example contact hierarchy:
* 1234 <sip:1234@test.com>
|- 1234 <sip:1234@other.com>
`- 5555 <sip:5555@test.com>
`- 5555 <sip:5555@final.com>

== Terminating calls ==
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>:
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>

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

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

Reason cause strings available inside routing scripts:

List of Q.850 reason causes:
:unallocated_number
:no_route_to_network
:no_route_to_destination
:send_special_tone
:misdialled_trunk_prefix
:channel_unacceptable
:call_awarded_in_established_channel
:preemption
:reattempt
:ported_number
:normal_call_clearing
:user_busy
:no_user_responding
:no_answer_from_user
:subscriber_absent
:call_rejected
:number_changed
:redirection
:exchange_routing_error
:non_selected_user_clearing
:destination_out_of_order
:address_incomplete
:facility_rejected
:response_to_status_enquiry
:normal_unspecified
:no_circuit_available
:network_out_of_order
:frame_mode_out_of_service
:frame_mode_connection_operational
:temporary_failure
:switching_equipment_congestion
:access_information_discarded
: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
:not_compatible_with_call_state
:ie_non_existent
:invalid_ie_content
:message_not_compatible
:recovery_on_timer_expiry
:parameter_non_existent_passed_on
:msg_with_non_recognized_param_discarded
:protocol_error
:interworking_unspecified

List of toolpack reason causes:

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

List of SIP reason causes: 
Reason causes starting with a digit must use the following syntax (can't use : as prefix).

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

== Nap status ==

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

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

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

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

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

asr_statistics_struct_global_asr_percent

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

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

=== Test parameters ===
==== @call_params ====

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

 

==== @nap_list ====

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

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

 

==== @params ====

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

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

 

----

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

[[category:Needs revising]]

Local Number Portability

2015-04-28T17:51:49Z

Atremblay: Updated page with regards to redirections

== Local Number Portability (LNP) ==

=== History and overview ===
Since the beginning of modern telephony, the phone number has been composed of series of digits representing the address of the final destination (i.e. the callee). This is actually what the end-user believed actually. But in reality, the signification of these digits has changed over the decades sometimes partially representing the actual route from one switch to the other or the rural region where the callee actually lives.

Traditionally, every switches was assigned an NPA-NXX (where NPA means "Numbering Plan Area"), meaning that a phone number with the format NPA-NXX-XXXX was actually refering to a specific geographical switch. As the number of end-user was growing in geographical regions, the set of available numbers in a specific NPA-NXX-XXXX was reducing forcing the telecommunication authorities to allocate more regional codes. At some point, the switches themselves were provisioned at their maximum capacity which forces the operators to include other switches not necessarily to the same geographical locations thus making the NPA-NXX less and less relevant to geography. However, the real changes came when the normative authorities decided that a end-user has the right to keep his assigned phone number regardless of which carrier he's chose as long as it kept to the same local geographical region. This change had to be supported by the ISUP switching/terminating equipment to decouple the actual phone number from the carrier/switching equipment and link it to the end-user. However, for routing purposes, these equipments still needed a way to deduce the routing to reach that end-customer number. This mechanism is referred to as "Local Number Portability" (LNP).

With LNP now active, a new number called the LRN (Location routing number) is introduced in the routing mechanism. It is formatted as NPA-NXX-XXXX and points '''logically''' to a particular switching equipment: it is the switch permanent address. The DNIS (end-user called number) is now a “virtual number” that only the last end-switch knows how to route to the subscriber. It is the role of the originating switch and intermediate switches to translate the DNIS into an LRN (consulting a regional databases using SS7 or SIP) and route the call to the final switch responsible for that subscriber. Then, and only then, the last switch uses the original DNIS to route it to the end-user.

When the first subscriber within an NPA-NXX group changes service providers, the entire NPA-NXX is considered “ported” (all 10k numbers) which means that this particular NPA-NXX combination has become a portable number and no longer represents a specific exchange. Every call to that NPA-NXX will trigger a query to a database to determine the LRN of the number of the switch responsible for the NPA-NXX-XXXX being called.

=== LNP and TelcoBridges ===

TelcoBridges products support the LNP use cases described by the following table.

{| cellpadding="5" border="1" class="wikitable"
! Scenario
! Description
! TelcoBridges support
|-
| All Call Query
| Before every call, obtain the routing number corresponding to the called number from a centralized database.
| The routing scripts can be configured to query the database through RADIUS, or using a SS7/SIP call.
|-
| Query on Release
| Route calls normally. If a remote operator returns a redirection response without any destination specified, obtain the routing number corresponding to the called number from a centralized database.
| The routing scripts can be configured to query the database through RADIUS, or using a SS7/SIP call.
|-
| Call Dropback
| Route calls normally. A remote operator may provide a routing number to use to route the call somewhere else.
| TelcoBridges products can process, relay or drop redirections.
|-
| Onward Routing
| Route calls normally. A remote operator may choose to re-route the call by itself or provide a routing number.
| TelcoBridges products can process, relay or drop redirections. They also handle call transfers.
|}

==== Relaying ====
Most carriers and operators exposing ISUP interfaces to CLECs detects if an incoming call is in the 'translated' mode or not by looking at the content of the ISUP message. If the ISUP call does not contain any LRN number, then the carrier/operator switch does a query to the SS7 database to figure out the LRN and adjust the call information accordingly. The TelcoBridges' [[Toolpack]] framework is able to terminate or relay a call from SIP to SS7 providing the LRN information is contained in the SIP body. What is relayed and how it is relayed depends on the profile configuration options.

==== Processing ====
TelcoBridges' [[Toolpack]] framework allows to route calls based on both the called number or the LRN based on the profile configuration options.

[[Toolpack]] can query an external LNP database using [[RADIUS]] authorizations or SS7 or SIP [[Redirect|redirections]]. This operation is also commonly referred as LNP/LRN "dipping".

=== Configuration ===

Toolpack processes sequentially the incoming call by parsing the content of the signalling protocol and mapping it to "protocol-agnostic" internal variables that are accessible by the routing scripts. Through all the [[Routing_script_tutorial:Mini_Development_Guide#Script_parameters_protocol_mapping|routing script variables]] accessible to scripts are some related to LNP such as 'ported_number'. The mapping of the information found in the incoming call depends on the option selected in the "incoming" parameters of the LNP section in the profile associated with the incoming NAP. Then its mapping to the outgoing call depends on configuration parameters of the profile for the outgoing NAP.

[[Toolpack:Modify_NAP_profile_A|Configuring LNP in v2.6]]

Redirect

2015-04-28T17:37:16Z

Atremblay: Fixed link for LNP

Some signaling protocols support redirecting calls from one location to another. This is usually done by a redirect server which analyzes incoming call information and then terminates the call while specifying another destination.

Redirections are usually triggered by the following call termination reason codes:
* SIP
** 300 Multiple Choices
** 301 Moved Permanently
** 302 Moved Temporarily
** 305 Use Proxy
** 380 Alternative Service
* SS7
** Q.850 Ported Number (14)
** Q.850 Number Changed (22)
** Q.850 Redirection (23)

== TelcoBridges and redirections ==

[[Web_Portal_Tutorial_Guide_v2.7|TMG-CONTROL 2.7]] and earlier provides basic support for SIP redirection on the NAP from where the outgoing call originated.

[[Web_Portal_Tutorial_Guide_v2.8|TMG-CONTROL 2.8]] and later provides support for various redirection behaviors on signaling protocols that support it. These behaviors are:
*Redirection emission: [[TMG-CONTROL]] can forge a redirection response instead of routing an incoming call using routing scripts.
*Redirection processing: [[TMG-CONTROL]] can process redirection requests through its routing scripts using the specified called or routing numbers. This feature can be used for [[Local Number Portability|LNP]] "dipping".
*Relay: The [[Tmedia]] or [[Tdev]] unit can be configured automatically relay redirection requests from the outgoing call to the incoming call.
*Drop: The unit can also be configured to drop the request altogether.

== Configuration ==

*[[Web_Portal_Tutorial_Guide_v2.8|Toolpack v2.8]]

Redirect

2015-04-28T17:34:35Z

Atremblay: Initial version

Some signaling protocols support redirecting calls from one location to another. This is usually done by a redirect server which analyzes incoming call information and then terminates the call while specifying another destination.

Redirections are usually triggered by the following call termination reason codes:
* SIP
** 300 Multiple Choices
** 301 Moved Permanently
** 302 Moved Temporarily
** 305 Use Proxy
** 380 Alternative Service
* SS7
** Q.850 Ported Number (14)
** Q.850 Number Changed (22)
** Q.850 Redirection (23)

== TelcoBridges and redirections ==

[[Web_Portal_Tutorial_Guide_v2.7|TMG-CONTROL 2.7]] and earlier provides basic support for SIP redirection on the NAP from where the outgoing call originated.

[[Web_Portal_Tutorial_Guide_v2.8|TMG-CONTROL 2.8]] and later provides support for various redirection behaviors on signaling protocols that support it. These behaviors are:
*Redirection emission: [[TMG-CONTROL]] can forge a redirection response instead of routing an incoming call using routing scripts.
*Redirection processing: [[TMG-CONTROL]] can process redirection requests through its routing scripts using the specified called or routing numbers. This feature can be used for [[LNP]] "dipping".
*Relay: The [[Tmedia]] or [[Tdev]] unit can be configured automatically relay redirection requests from the outgoing call to the incoming call.
*Drop: The unit can also be configured to drop the request altogether.

== Configuration ==

*[[Web_Portal_Tutorial_Guide_v2.8|Toolpack v2.8]]

VoIP Ethernet Capture

2015-02-04T21:49:35Z

Atremblay: /* Start the capture */

The [[Tmedia]] product can configure one of its VoIP Ethernet ports to do [http://en.wikipedia.org/wiki/Port_mirroring Port Mirroring]. This is useful when investigating RTP, Codecs or IP Tones issues.

=== Preparing the Tmedia for capture (enable ports mirroring) ===
*If the traffic to be captured is on a 802.1Q VLAN and the TMG-CONTROL version is >= 2.8, an IP interface with the 'MANAGEMENT' service must be created through the Web Portal. The IP interface must be assigned to a virtual port that is assigned to the capture port and uses the 802.1Q VLAN ID that is targeted by the capture.
*Access the [[Tmedia]] unit using SSH.
*Access the telecom baseboard from the [[Tmedia]] using telnet.
telnet 172.31.1.1
*Type in the mv88eMonitor command to get the list of ports on the unit:
mv88eMonitor
*A list (such as the one below) should appear:
Port Mapping:
PortDesc : eth0 eth1 voip0 voip1 mspeedsw1 mspeedsw2 fpga0 fpga1 host cpu
PortNumber : 0 1 2 3 4 5 6 7 8 9
PortMask : 0x1 0x2 0x4 0x8 0x10 0x20 0x40 0x80 0x100 0x200
*The 'PortNumber' is the '''destination''' port for the capture.
**If the traffic is to be captured on the '''internal host''' of the TMG unit, use the number below the '''host''' port (in the above example, 8).
**If the traffic is to be captured on an '''external host''' (laptop, PC, or specialized equipment), choose the number below the desired target port (for example, 0 for eth0).
*The 'PortMask' is the '''source''' mask for the capture. On the above example, traffic going through the voip0 port would be captured using the 0x4 mask.
*Use the mv88eMonitor command in order to mirror traffic as desired. Here is the syntax:
mv88eMonitor <IngressPortMask> <EgressPortMask> <PortNumber> <TimeoutInSeconds>
**The 'IngressPortMask' is the mask used for capturing traffic that is sent to the TMG.
**The 'EgressPortMask' is the mask used for capturing traffic that is sent from the TMG.
**The 'PortNumber' is where the captured traffic should be mirrored to.
**The 'TimeoutInSeconds' is the time the mirror operation is active before being automatically stopped.
*Here is an example to mirror all the voip0 traffic to a TMG3200's internal host, for 60 seconds:
mv88eMonitor 0x4 0x4 8 60
*Here is an example to mirror the incoming voip0 traffic on a TMG3200 to an external host connected to the eth1 port:
mv88eMonitor 0x4 0 1 60

=== Start the capture ===
*Exit the telecom baseboard's shell (type "exit")
*If the capture is to be done on an external host, use a tool such as 'Wireshark' to capture and analyze the mirrored traffic.
**When configuring a port as a mirror, it is important to connect that Ethernet port directly to a host (like a laptop). Otherwise, it could cause issues such as an Ethernet loop.
**If capturing 802.1Q tagged traffic, make sure the receiving equipment is actually configured to process 802.1Q tagged traffic.
*If the capture is to be done on the TMG's internal host:
**Use the '''tbproduct''' command to find out which product is currently used.
**Use the following table to know on which Linux interface to capture the traffic:
{| class="wikitable"
|-
! TMG800 !! TMG3200 !! 802.1Q capture
|-
| '''mgmt0''' || '''int0''' || '''vlanXXXX''', where XXXX is the VLAN ID (e.g. vlan333)
|}
*Use the "tcpdump" tool to capture mirrored packets:
tcpdump -i mgmt0 -s 1500 -w capture_file.cap
*To capture 802.1Q tagged traffic, use the correct VLAN interface:
tcpdump -i vlan333 -s 1500 -w capture_file.cap

=== Stop the Capture ===
When you're ready, stop the capture by
*pressing control-C on the shell that was running tcpdump command
*Access the telecom baseboard from the [[Tmedia]] using telnet.
telnet 172.31.1.1
*Stop the capture
mv88eMonitor 0 0 0

=== Download the Capture ===
To download the capture, use SSH secure copy ("sftp") to the Tmedia management port. This can be done on Windows using tools like Filezilla.

VoIP Ethernet Capture

2015-02-04T21:48:17Z

Atremblay: Updated for future platforms (different port IDs for TMLv4), added 802.1Q

The [[Tmedia]] product can configure one of its VoIP Ethernet ports to do [http://en.wikipedia.org/wiki/Port_mirroring Port Mirroring]. This is useful when investigating RTP, Codecs or IP Tones issues.

=== Preparing the Tmedia for capture (enable ports mirroring) ===
*If the traffic to be captured is on a 802.1Q VLAN and the TMG-CONTROL version is >= 2.8, an IP interface with the 'MANAGEMENT' service must be created through the Web Portal. The IP interface must be assigned to a virtual port that is assigned to the capture port and uses the 802.1Q VLAN ID that is targeted by the capture.
*Access the [[Tmedia]] unit using SSH.
*Access the telecom baseboard from the [[Tmedia]] using telnet.
telnet 172.31.1.1
*Type in the mv88eMonitor command to get the list of ports on the unit:
mv88eMonitor
*A list (such as the one below) should appear:
Port Mapping:
PortDesc : eth0 eth1 voip0 voip1 mspeedsw1 mspeedsw2 fpga0 fpga1 host cpu
PortNumber : 0 1 2 3 4 5 6 7 8 9
PortMask : 0x1 0x2 0x4 0x8 0x10 0x20 0x40 0x80 0x100 0x200
*The 'PortNumber' is the '''destination''' port for the capture.
**If the traffic is to be captured on the '''internal host''' of the TMG unit, use the number below the '''host''' port (in the above example, 8).
**If the traffic is to be captured on an '''external host''' (laptop, PC, or specialized equipment), choose the number below the desired target port (for example, 0 for eth0).
*The 'PortMask' is the '''source''' mask for the capture. On the above example, traffic going through the voip0 port would be captured using the 0x4 mask.
*Use the mv88eMonitor command in order to mirror traffic as desired. Here is the syntax:
mv88eMonitor <IngressPortMask> <EgressPortMask> <PortNumber> <TimeoutInSeconds>
**The 'IngressPortMask' is the mask used for capturing traffic that is sent to the TMG.
**The 'EgressPortMask' is the mask used for capturing traffic that is sent from the TMG.
**The 'PortNumber' is where the captured traffic should be mirrored to.
**The 'TimeoutInSeconds' is the time the mirror operation is active before being automatically stopped.
*Here is an example to mirror all the voip0 traffic to a TMG3200's internal host, for 60 seconds:
mv88eMonitor 0x4 0x4 8 60
*Here is an example to mirror the incoming voip0 traffic on a TMG3200 to an external host connected to the eth1 port:
mv88eMonitor 0x4 0 1 60

=== Start the capture ===
*Exit the telecom baseboard's shell (type "exit")
*If the capture is to be done on an external host, use a tool such as 'Wireshark' to capture and analyze the mirrored traffic.
**When configuring a port as a mirror, it is important to connect that Ethernet port directly to a host (like a laptop). Otherwise, it could cause issues such as an Ethernet loop.
*If the capture is to be done on the TMG's internal host:
**Use the '''tbproduct''' command to find out which product is currently used.
**Use the following table to know on which Linux interface to capture the traffic:
{| class="wikitable"
|-
! TMG800 !! TMG3200 !! 802.1Q capture
|-
| '''mgmt0''' || '''int0''' || '''vlanXXXX''', where XXXX is the VLAN ID (e.g. vlan333)
|}
*Use the "tcpdump" tool to capture mirrored packets:
tcpdump -i mgmt0 -s 1500 -w capture_file.cap
*To capture 802.1Q tagged traffic, use the correct VLAN interface:
tcpdump -i vlan333 -s 1500 -w capture_file.cap

=== Stop the Capture ===
When you're ready, stop the capture by
*pressing control-C on the shell that was running tcpdump command
*Access the telecom baseboard from the [[Tmedia]] using telnet.
telnet 172.31.1.1
*Stop the capture
mv88eMonitor 0 0 0

=== Download the Capture ===
To download the capture, use SSH secure copy ("sftp") to the Tmedia management port. This can be done on Windows using tools like Filezilla.

VoIP Ethernet Capture

2015-02-04T20:23:49Z

Atremblay:

The [[Tmedia]] product can configure one of its VoIP Ethernet ports to do [http://en.wikipedia.org/wiki/Port_mirroring Port Mirroring]. This is useful when investigating RTP, Codecs or IP Tones issues.

== Capturing using the TMG's internal host ==
The TMG's internal host can be used for capturing packets that are mirrored from the VOIP0 and/or VOIP1 physical ports.

=== Physical Setup ===
No specific physical setup is required

=== Preparing Tmedia for Capture (enable ports mirroring) ===
*Access the [[Tmedia]] unit using SSH.
*Access the telecom baseboard from the [[Tmedia]] using telnet.
telnet 172.31.1.1
*If the traffic to be captured is on a 802.1Q VLAN and the TMG-CONTROL version is >= 2.8, an IP interface with the 'MANAGEMENT' service must be created through the Web Portal. The IP interface must be assigned to a virtual port that is assigned to the capture port and uses the 802.1Q VLAN ID that is targeted by the capture.

==== TMG800 ====
Do one of the following command to capture packets according to your setup, to mirror packets toward the linux host CPU, for a configurable duration (in the following example the duration is 600 seconds, thus 10 minutes):
*For capturing all Ethernet packets from VOIP0
mv88eMonitor 0x1 0x1 2 600
*For capturing all Ethernet packets from VOIP1
mv88eMonitor 0x2 0x2 2 600
*For capturing all Ethernet packets from VOIP0 and VOIP1
mv88eMonitor 0x3 0x3 2 600

==== TMG3200 ====
Do one of the following command to capture packets according to your setup, to mirror packets toward the linux host CPU, for a configurable duration (in the following example the duration is 600 seconds, thus 10 minutes):
*For capturing all Ethernet packets from VOIP0
mv88eMonitor 0x4 0x4 8 600
*For capturing all Ethernet packets from VOIP1
mv88eMonitor 0x8 0x8 8 600
*For capturing all Ethernet packets from VOIP0 and VOIP1
mv88eMonitor 0xC 0xC 8 600

=== Start the Capture ===
*Exit the telecom baseboard's shell (type "exit")
*Use the "tcpdump" tool on linux to capture mirrored packets (received on the "mgmt0" interface):
'''Note''': If the captured traffic is on a 802.1Q VLAN, use the "vlanXXXX" interface instead of "mgmt0" or "int0", where "XXXX" is the identifier of the VLAN to capture on (e.g. vlan152).
==== TMG800 ====
tcpdump -i mgmt0 -s 1500 -w capture_file.cap
==== TMG3200 ====
tcpdump -i int0 -s 1500 -w capture_file.cap
'''Note''': The interface name "int0" could be different on older TMG3200. Use "ifconfig" command to find which interface has the IP address 172.31.1.2

=== Stop the Capture ===
When you're ready, stop the capture by
*pressing control-C on the shell that was running tcpdump command
*Access the telecom baseboard from the [[Tmedia]] using telnet.
telnet 172.31.1.1
*Stop the capture
mv88eMonitor 0 0 1

=== Download the Capture ===
To download the capture, use SSH secure copy ("sftp") to the Tmedia management port. This can be done on Windows using tools like Filezilla.

== Capturing from an external host (laptop) ==
'''Warning''': When configuring a port as a mirror, it is important to connect that Ethernet port directly to a host (like a laptop). Otherwise, it will create problem with to the Ethernet switch

=== Physical Setup ===
To do a VoIP capture it is required to:
*Connect one of the VoIP Ethernet port to a laptop with [http://www.wireshark.org/ Wireshark] installed and 1Gbs Network card.

Once the physical setup is ready. It is possible to start capturing all packets received and sent from VOIP0 or VOIP1 using the other interface (VOIP1 or VOIP0).

=== Preparing Tmedia for Capture ===
*Access the [[Tmedia]] unit using SSH.
*Access the telecom baseboard from the [[Tmedia]] using telnet.
telnet 172.31.1.1
*Start Wireshark to capture the Ethernet packets with the connected laptop.
*Do one of the following command to capture packets according to your setup.

==== TMG800 ====
For capturing all Ethernet packets that goes through VoIP0 with VoIP1, for a configurable duration (in the following example the duration is 600 seconds, thus 10 minutes)
mv88eMonitor 0x1 0x1 1 600

For capturing all Ethernet packets that goes through VoIP1 with VoIP0, for a configurable duration (in the following example the duration is 600 seconds, thus 10 minutes)
mv88eMonitor 0x2 0x2 0 600

==== TMG3200 ====
For capturing all Ethernet packets that goes through VoIP0 with VoIP1, for a configurable duration (in the following example the duration is 600 seconds, thus 10 minutes)
mv88eMonitor 0x4 0x4 3 600

For capturing all Ethernet packets that goes through VoIP1 with VoIP0, for a configurable duration (in the following example the duration is 600 seconds, thus 10 minutes)
mv88eMonitor 0x8 0x8 2 600

=== Stop the Capture ===
mv88eMonitor 0 0 0

== TMG7800 ==
=== Physical Setup ===
To do a VoIP capture it is required to:
*Connect one of the VoIP Ethernet port to a laptop with [http://www.wireshark.org/ Wireshark] installed and 1Gbs Network card.

Once the physical setup is ready. It is possible to start capturing the RTP.

=== Preparing Tmedia for Capture ===
*Access the telecom unit ([[TMG7800|TMG7800-TE]], [[TMG7800|TMG7800-DS3]] or [[TMG7800|TMG7800-STM1]]) you want to capture using telnet.
telnet [eth0 IP address of the telecom unit]
*Start Wireshark to capture the Ethernet packets with the connected laptop.
*Do one of the following command to capture packets according to your setup.

=== Start the Capture ===
For capturing all Ethernet packets that goes through VoIP0 with VoIP1
mv88eMonitor 0x4 0x4 3

For capturing all Ethernet packets that goes through VoIP1 with VoIP0
mv88eMonitor 0x8 0x8 2

=== Stop the Capture ===
mv88eMonitor 0 0 3

GHOST

2015-02-03T15:49:06Z

Atremblay: /* WebPortal - TMG unit or Linux server with access to Internet (i.e. with DNS configured) */

{{DISPLAYTITLE:GHOST: The glibc's gethostbyname vulnerability}}

On January 27, 2015, a vulnerability named "GHOST" in the glibc library was publicly announced. GHOST is also referred as '''CVE-2015-0235'''. The vulnerability is a buffer overflow in the gethostbyname family of functions that can allow arbitrary code execution.

= Affected Products =
* TMG800, TMG3200, TMG7800-CTRL
* Tdev Linux server with (CentOS, RedHat, etc) running Toolpack software

= Details =
The impact of this vulnerability on TelcoBridges products depends on their configuration. The vulnerability may only be triggered through requests for domain name resolution. Therefore, only units that enable such services may be exposed to the issue.

= Software Versions and Fixes =
The TelcoBridges CentOS 5 repository has been updated with the latest glibc version. Services that use glibc must be restarted. Because glibc is thoroughly used in the Linux operating system, it is highly recommended to reboot the unit.

= Update procedure =
The operator can use one of the two methods available: GUI/WebPortal or command line interface.

== WebPortal - TMG unit or Linux server '''with access to Internet''' (i.e. with DNS configured) ==
* login onto the WebPortal
* Select the 'Hosts' section
* Click on the hostname
* Click on the 'Status' tab
* Select 'Upgrade Linux packages' into the host 'Action'
* Click on the 'Apply action' button
* Refresh the page until the packages are updated as indicated in the 'Action Log' (you may use the 'Now' button to update the page). The results should appear within a minute.
* Select 'Shutdown' into the host 'Action'
* Select 'Reboot' into the 'Shutdown Type'
* Click on the 'Apply action' button
* Repeat the process for all hosts listed

== Command line interface ==

* login with root account
[root@TB011107 ~]# uname -m
x86_64
* If the result is not "x86_64", [[Support:Contacting TelcoBridges technical support|please contact TelcoBridges]] support, otherwise you can proceed with either method below.
* Follow one of the two options depending if Internet is accessible from the unit

=== Option #1 - TMG unit or Linux server '''with access to Internet''' (i.e. with DNS configured) ===

* update OS packages with yum
yum clean all
yum update
* reboot the unit
reboot

=== Option #2 - TMG unit or Linux server '''without access to Internet''' ===
* download the following packages to your PC:
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-common-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-devel-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-headers-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/nscd-2.5-123.el5_11.1.x86_64.rpm
* Using WinSCP or similar tool, upload the files to the TMG unit using the root account
* login with root account
* Install packages
yum localinstall glibc-2.5-123.el5_11.1.x86_64.rpm \
glibc-common-2.5-123.el5_11.1.x86_64.rpm \
glibc-devel-2.5-123.el5_11.1.x86_64.rpm \
glibc-headers-2.5-123.el5_11.1.x86_64.rpm \
nscd-2.5-123.el5_11.1.x86_64.rpm
* '''Note''': that operation might take a long time since yum will probably experience timeouts when trying to access the external repositories.
* Reboot the unit
reboot

= How to verify if the vulnerability is fixed? =
* login with root account
* execute the following to create a test script
cat > rhel-GHOST-test.sh << FOF
#!/bin/bash
# rhel-GHOST-test.sh - GHOST vulnerability tester. Only for CentOS/RHEL based servers. #
# Version 3
# Credit : Red Hat, Inc - https://access.redhat.com/labs/ghost/ #
echo "Installed glibc version(s)"

rv=0
for glibc_nvr in \$( rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc ); do
glibc_ver=\$( echo "\$glibc_nvr" | awk -F- '{ print \$2 }' )
glibc_maj=\$( echo "\$glibc_ver" | awk -F. '{ print \$1 }')
glibc_min=\$( echo "\$glibc_ver" | awk -F. '{ print \$2 }')

echo -n "- \$glibc_nvr: "
if [ "\$glibc_maj" -gt 2 -o $ "\$glibc_maj" -eq 2 -a "\$glibc_min" -ge 18 $ ]; then
# fixed upstream version
echo 'not vulnerable'
else
# all RHEL updates include CVE in rpm %changelog
if rpm -q --changelog "\$glibc_nvr" | grep -q 'CVE-2015-0235'; then
echo "not vulnerable"
else
echo "vulnerable"
rv=1
fi
fi
done

if [ \$rv -ne 0 ]; then
cat <<EOF

This system is vulnerable to CVE-2015-0235. <https://access.redhat.com/security/cve/CVE-2015-0235>
Please refer to <https://access.redhat.com/articles/1332213> for remediation steps
EOF
fi

exit \$rv

FOF
* Execute the script
chmod +x rhel-GHOST-test.sh
./rhel-GHOST-test.sh
* '''You should not see the 'vulnerable' string displayed'''

= References =
* https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt
* https://access.redhat.com/articles/1332213
* http://www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/

GHOST

2015-02-03T15:29:13Z

Atremblay: Updated with reboot

{{DISPLAYTITLE:GHOST: The glibc's gethostbyname vulnerability}}

On January 27, 2015, a vulnerability named "GHOST" in the glibc library was publicly announced. GHOST is also referred as '''CVE-2015-0235'''. The vulnerability is a buffer overflow in the gethostbyname family of functions that can allow arbitrary code execution.

= Affected Products =
* TMG800, TMG3200, TMG7800-CTRL
* Tdev Linux server with (CentOS, RedHat, etc) running Toolpack software

= Details =
The impact of this vulnerability on TelcoBridges products depends on their configuration. The vulnerability may only be triggered through requests for domain name resolution. Therefore, only units that enable such services may be exposed to the issue.

= Software Versions and Fixes =
The TelcoBridges CentOS 5 repository has been updated with the latest glibc version. Services that use glibc must be restarted. Because glibc is thoroughly used in the Linux operating system, it is highly recommended to reboot the unit.

= Update procedure =
The operator can use one of the two methods available: GUI/WebPortal or command line interface.

== WebPortal - TMG unit or Linux server '''with access to Internet''' (i.e. with DNS configured) ==
* login onto the WebPortal
* Select the 'Hosts' section
* Click on the hostname
* Click on the 'Status' tab
* Select 'Upgrade Linux packages' into the host 'Action'
* Click on the 'Apply action' button
* Select 'Shutdown' into the host 'Action'
* Select 'Reboot' into the 'Shutdown Type'
* Click on the 'Apply action' button
* Repeat the process for all hosts listed

== Command line interface ==

* login with root account
[root@TB011107 ~]# uname -m
x86_64
* If the result is not "x86_64", [[Support:Contacting TelcoBridges technical support|please contact TelcoBridges]] support, otherwise you can proceed with either method below.
* Follow one of the two options depending if Internet is accessible from the unit

=== Option #1 - TMG unit or Linux server '''with access to Internet''' (i.e. with DNS configured) ===

* update OS packages with yum
yum clean all
yum update
* reboot the unit
reboot

=== Option #2 - TMG unit or Linux server '''without access to Internet''' ===
* download the following packages to your PC:
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-common-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-devel-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-headers-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/nscd-2.5-123.el5_11.1.x86_64.rpm
* Using WinSCP or similar tool, upload the files to the TMG unit using the root account
* login with root account
* Install packages
yum localinstall glibc-2.5-123.el5_11.1.x86_64.rpm \
glibc-common-2.5-123.el5_11.1.x86_64.rpm \
glibc-devel-2.5-123.el5_11.1.x86_64.rpm \
glibc-headers-2.5-123.el5_11.1.x86_64.rpm \
nscd-2.5-123.el5_11.1.x86_64.rpm
* '''Note''': that operation might take a long time since yum will probably experience timeouts when trying to access the external repositories.
* Reboot the unit
reboot

= How to verify if the vulnerability is fixed? =
* login with root account
* execute the following to create a test script
cat > rhel-GHOST-test.sh << FOF
#!/bin/bash
# rhel-GHOST-test.sh - GHOST vulnerability tester. Only for CentOS/RHEL based servers. #
# Version 3
# Credit : Red Hat, Inc - https://access.redhat.com/labs/ghost/ #
echo "Installed glibc version(s)"

rv=0
for glibc_nvr in \$( rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc ); do
glibc_ver=\$( echo "\$glibc_nvr" | awk -F- '{ print \$2 }' )
glibc_maj=\$( echo "\$glibc_ver" | awk -F. '{ print \$1 }')
glibc_min=\$( echo "\$glibc_ver" | awk -F. '{ print \$2 }')

echo -n "- \$glibc_nvr: "
if [ "\$glibc_maj" -gt 2 -o $ "\$glibc_maj" -eq 2 -a "\$glibc_min" -ge 18 $ ]; then
# fixed upstream version
echo 'not vulnerable'
else
# all RHEL updates include CVE in rpm %changelog
if rpm -q --changelog "\$glibc_nvr" | grep -q 'CVE-2015-0235'; then
echo "not vulnerable"
else
echo "vulnerable"
rv=1
fi
fi
done

if [ \$rv -ne 0 ]; then
cat <<EOF

This system is vulnerable to CVE-2015-0235. <https://access.redhat.com/security/cve/CVE-2015-0235>
Please refer to <https://access.redhat.com/articles/1332213> for remediation steps
EOF
fi

exit \$rv

FOF
* Execute the script
chmod +x rhel-GHOST-test.sh
./rhel-GHOST-test.sh
* '''You should not see the 'vulnerable' string displayed'''

= References =
* https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt
* https://access.redhat.com/articles/1332213
* http://www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/

GHOST

2015-02-03T14:56:15Z

Atremblay: Fixed vulnerability script

{{DISPLAYTITLE:GHOST: The glibc's gethostbyname vulnerability}}

On January 27, 2015, a vulnerability named "GHOST" in the glibc library was publicly announced. GHOST is also referred as '''CVE-2015-0235'''. The vulnerability is a buffer overflow in the gethostbyname family of functions that can allow arbitrary code execution.

= Affected Products =
* TMG800, TMG3200, TMG7800-CTRL
* Tdev Linux server with (CentOS, RedHat, etc) running Toolpack software

= Details =
The impact of this vulnerability on TelcoBridges products depends on their configuration. The vulnerability may only be triggered through requests for domain name resolution. Therefore, only units that enable such services may be exposed to the issue.

= Software Versions and Fixes =
The TelcoBridges CentOS 5 repository has been updated with the latest glibc version. Services that use glibc must be restarted. Because glibc is thoroughly used in the Linux operating system, it is highly recommended to reboot the unit.

= Update procedure =
* login with root account
[root@TB011107 ~]# uname -m
x86_64
* If the result is not "x86_64", [[Support:Contacting TelcoBridges technical support|please contact TelcoBridges]] support, otherwise you can proceed with either method below.

== Command line interface - TMG unit or Linux server '''with access to Internet''' (i.e. with DNS configured) ==
* login with root account
* update OS packages with yum
yum clean all
yum update
* reboot the unit
reboot

== TMG unit or Linux server '''without access to Internet''' ==
* download the following packages to your PC:
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-common-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-devel-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-headers-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/nscd-2.5-123.el5_11.1.x86_64.rpm
* Using WinSCP or similar tool, upload the files to the TMG unit using the root account
* login with root account
* Install packages
yum localinstall glibc-2.5-123.el5_11.1.x86_64.rpm \
glibc-common-2.5-123.el5_11.1.x86_64.rpm \
glibc-devel-2.5-123.el5_11.1.x86_64.rpm \
glibc-headers-2.5-123.el5_11.1.x86_64.rpm \
nscd-2.5-123.el5_11.1.x86_64.rpm
* '''Note''': that operation might take a long time since yum will probably experience timeouts when trying to access the external repositories.
* Reboot the unit
reboot

= How to verify if the vulnerability is fixed? =
* login with root account
* execute the following to create a test script
cat > rhel-GHOST-test.sh << FOF
#!/bin/bash
# rhel-GHOST-test.sh - GHOST vulnerability tester. Only for CentOS/RHEL based servers. #
# Version 3
# Credit : Red Hat, Inc - https://access.redhat.com/labs/ghost/ #
echo "Installed glibc version(s)"

rv=0
for glibc_nvr in \$( rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc ); do
glibc_ver=\$( echo "\$glibc_nvr" | awk -F- '{ print \$2 }' )
glibc_maj=\$( echo "\$glibc_ver" | awk -F. '{ print \$1 }')
glibc_min=\$( echo "\$glibc_ver" | awk -F. '{ print \$2 }')

echo -n "- \$glibc_nvr: "
if [ "\$glibc_maj" -gt 2 -o $ "\$glibc_maj" -eq 2 -a "\$glibc_min" -ge 18 $ ]; then
# fixed upstream version
echo 'not vulnerable'
else
# all RHEL updates include CVE in rpm %changelog
if rpm -q --changelog "\$glibc_nvr" | grep -q 'CVE-2015-0235'; then
echo "not vulnerable"
else
echo "vulnerable"
rv=1
fi
fi
done

if [ \$rv -ne 0 ]; then
cat <<EOF

This system is vulnerable to CVE-2015-0235. <https://access.redhat.com/security/cve/CVE-2015-0235>
Please refer to <https://access.redhat.com/articles/1332213> for remediation steps
EOF
fi

exit \$rv

FOF
* Execute the script
chmod +x rhel-GHOST-test.sh
./rhel-GHOST-test.sh
* '''You should not see the 'vulnerable' string displayed'''

= References =
* https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt
* https://access.redhat.com/articles/1332213
* http://www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/

Security advisories

2015-02-03T14:29:31Z

Atremblay: Added GHOST

{{DISPLAYTITLE:Security Advisories}}
The purpose of this page is to provide information on important high-profile vulnerabilities and their impact on TelcoBridges products. The vulnerabilities are presented in chronological order.

'''January 27th, 2015'''
* [[GHOST|GHOST - glibc gethostbyname vulnerability (CVE-2015-0235)]]

'''September 24th, 2014'''
* [[ShellShock|ShellShock - GNU Bash Injection Vulnerability (CVE-2014-6271, CVE-2014-7169)]]

'''April 4th, 2014'''
* [[Heartbleed | Heartbleed - OpenSSL Heartbeat Extension Vulnerability (CVE-2014-0160)]]

[[category:FAQ]]

GHOST

2015-02-03T14:28:23Z

Atremblay: Initial page

{{DISPLAYTITLE:GHOST: The glibc's gethostbyname vulnerability}}

On January 27, 2015, a vulnerability named "GHOST" in the glibc library was publicly announced. GHOST is also referred as '''CVE-2015-0235'''. The vulnerability is a buffer overflow in the gethostbyname family of functions that can allow arbitrary code execution.

= Affected Products =
* TMG800, TMG3200, TMG7800-CTRL
* Tdev Linux server with (CentOS, RedHat, etc) running Toolpack software

= Details =
The impact of this vulnerability on TelcoBridges products depends on their configuration. The vulnerability may only be triggered through requests for domain name resolution. Therefore, only units that enable such services may be exposed to the issue.

= Software Versions and Fixes =
The TelcoBridges CentOS 5 repository has been updated with the latest glibc version. Services that use glibc must be restarted. Because glibc is thoroughly used in the Linux operating system, it is highly recommended to reboot the unit.

= Update procedure =
* login with root account
[root@TB011107 ~]# uname -m
x86_64
* If the result is not "x86_64", [[Support:Contacting TelcoBridges technical support|please contact TelcoBridges]] support, otherwise you can proceed with either method below.

== Command line interface - TMG unit or Linux server '''with access to Internet''' (i.e. with DNS configured) ==
* login with root account
* update OS packages with yum
yum clean all
yum update
* reboot the unit
reboot

== TMG unit or Linux server '''without access to Internet''' ==
* download the following packages to your PC:
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-common-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-devel-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/glibc-headers-2.5-123.el5_11.1.x86_64.rpm
** http://repo.telcobridges.com/centos/5.7/updates/x86_64/RPMS/nscd-2.5-123.el5_11.1.x86_64.rpm
* Using WinSCP or similar tool, upload the files to the TMG unit using the root account
* login with root account
* Install packages
yum localinstall glibc-2.5-123.el5_11.1.x86_64.rpm \
glibc-common-2.5-123.el5_11.1.x86_64.rpm \
glibc-devel-2.5-123.el5_11.1.x86_64.rpm \
glibc-headers-2.5-123.el5_11.1.x86_64.rpm \
nscd-2.5-123.el5_11.1.x86_64.rpm
* '''Note''': that operation might take a long time since yum will probably experience timeouts when trying to access the external repositories.
* Reboot the unit
reboot

= How to verify if the vulnerability is fixed? =
* login with root account
* execute the following to create a test script
cat >> rhel-GHOST-test.sh << FOF
#!/bin/bash
# rhel-GHOST-test.sh - GHOST vulnerability tester. Only for CentOS/RHEL based servers. #
# Version 3
# Credit : Red Hat, Inc - https://access.redhat.com/labs/ghost/ #
echo "Installed glibc version(s)"

rv=0
for glibc_nvr in $( rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc ); do
glibc_ver=$( echo "$glibc_nvr" | awk -F- '{ print $2 }' )
glibc_maj=$( echo "$glibc_ver" | awk -F. '{ print $1 }')
glibc_min=$( echo "$glibc_ver" | awk -F. '{ print $2 }')

echo -n "- $glibc_nvr: "
if [ "$glibc_maj" -gt 2 -o \
$ "$glibc_maj" -eq 2 -a "$glibc_min" -ge 18 $ ]; then
# fixed upstream version
echo 'not vulnerable'
else
# all RHEL updates include CVE in rpm %changelog
if rpm -q --changelog "$glibc_nvr" | grep -q 'CVE-2015-0235'; then
echo "not vulnerable"
else
echo "vulnerable"
rv=1
fi
fi
done

if [ $rv -ne 0 ]; then
cat <<EOF

This system is vulnerable to CVE-2015-0235. <https://access.redhat.com/security/cve/CVE-2015-0235>
Please refer to <https://access.redhat.com/articles/1332213> for remediation steps
EOF
fi

exit $rv
FOF
* Execute the script
chmod +x rhel-GHOST-test.sh
./rhel-GHOST-test.sh
* '''You should not see the 'vulnerable' string displayed'''

= References =
* https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt
* https://access.redhat.com/articles/1332213
* http://www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/

Toolpack prerequisite Debian6 2-6

2012-04-02T15:12:34Z

Atremblay: Added make/g++ prerequisite for Toolpack

This page shows the prerequisites required for compiling and running TelcoBridges applications on Debian 6. Most procedures assume supervisor (root) access on the system.

== Debian 6 OS installation ==

The configuration used for redacting this page was installed using the debian-6.0.4-amd64-CD-1.iso CD image (http://cdimage.debian.org/debian-cd/6.0.4/amd64/iso-cd/debian-6.0.4-amd64-CD-1.iso). Only the SSH server and standard utilities were installed. No network packages were used.

Make sure sources.list has squeeze in the sources package list (it will not be present if the installation did not use the network packages). If you have problems with apt-get, edit /etc/apt/sources.list and make sure to add these lines (and comment everything else):

vi /etc/apt/sources.list

deb http://ftp.debian.org/debian/ squeeze main contrib
deb-src http://ftp.debian.org/debian/ squeeze main contrib
deb http://security.debian.org/ squeeze/updates main contrib
deb-src http://security.debian.org/ squeeze/updates main contrib

== Prerequisites for compiling TelcoBridges packages ==

Get build tools (zlib and libxml2 are required for higher level applications):
apt-get install make g++ libxml2-dev zlib1g-dev libmysqlclient-dev unixodbc-dev libssl-dev

Install ruby 1.8.7-p174:
wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/src/centos/ruby-1.8.7-p174.tar.gz
tar -zxf ruby-1.8.7-p174.tar.gz
cd ruby-1.8.7-p174
./configure --libdir=/usr/local/lib64 --enable-shared
make
make install
cd ext/openssl
ruby extconf.rb
make
make install
ln -s /usr/local/bin/ruby /usr/bin/ruby
ln -s /usr/local/lib64/libruby.so.1.8 /lib64/libruby.so.1.8

TelcoBridges only support 64-bit applications on Debian 6. When compiling, use the '''X86_64=1''' flag. For example:
make all X86_64=1 DBG=1

== Prerequisites for running custom TelcoBridges applications ==

Make sure all prerequisites are already installed:
apt-get install libxml2 zlib1g

The following prerequisites may be required if the applications use MySQL:
apt-get install libmysqlclient unixodbc

== Prerequisites for running Toolpack ==

Make sure all prerequisites are already installed. An older version of the MySQL server is required in order to be compatible with the Ruby version. Make and g++ are required to build the custom version of Ruby.
apt-get install make g++ libxml2 zlib1g libmysqlclient unixodbc libmyodbc libfcgi libfcgi-dev lighttpd sysv-rc-conf
apt-get install mysql-server-core-5.1=5.1.49-3
apt-get install mysql-server-5.1=5.1.49-3

Install ruby 1.8.7-p174 (same procedure as mentioned above):
cd ~
wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/src/centos/ruby-1.8.7-p174.tar.gz
tar -zxf ruby-1.8.7-p174.tar.gz
cd ruby-1.8.7-p174
./configure --libdir=/usr/local/lib64 --enable-shared
make
make install
cd ext/openssl
ruby extconf.rb
make
make install
ln -s /usr/local/bin/ruby /usr/bin/ruby
ln -s /usr/local/lib64/libruby.so.1.8 /lib64/libruby.so.1.8

Install ODBC driver:
odbcinst -i -f /usr/share/libmyodbc/odbcinst.ini -d

Set up mysql:
mysql -u root -p
CREATE USER 'tbdb'@'%' IDENTIFIED BY 'tbdbpw';
GRANT ALL PRIVILEGES ON *.* TO 'tbdb'@'%' IDENTIFIED BY 'tbdbpw';
FLUSH PRIVILEGES;
exit

Set up my.cnf:
vi /etc/mysql/my.cnf
* Uncomment the '''server-id''' and '''log_bin''' lines
* Change '''max_allowed_packet''' to 200M
* Add '''max_allowed_packet=200M''' in the '''[mysqldump]''' section
Restart MySQL server:
service mysql restart

Remove lighttpd from init scripts (remove X's in the lighttpd line):
sysv-rc-conf
service lighttpd stop

Install ruby gems:
cd ~
wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/src/centos/rubygems-1.3.5.tgz
tar -zxf rubygems-1.3.5.tgz
cd rubygems-1.3.5
ruby setup.rb

Install fcgi gem:
gem install fcgi

== Toolpack System installation ==

Now that the prerequisite are installed, now it is time to install the [[toolpack_installer_2-6|Toolpack system]]

Toolpack prerequisite Debian6 2-6

2012-04-02T14:43:26Z

Atremblay:

This page shows the prerequisites required for compiling and running TelcoBridges applications on Debian 6. Most procedures assume supervisor (root) access on the system.

== Debian 6 OS installation ==

The configuration used for redacting this page was installed using the debian-6.0.4-amd64-CD-1.iso CD image (http://cdimage.debian.org/debian-cd/6.0.4/amd64/iso-cd/debian-6.0.4-amd64-CD-1.iso). Only the SSH server and standard utilities were installed. No network packages were used.

Make sure sources.list has squeeze in the sources package list (it will not be present if the installation did not use the network packages). If you have problems with apt-get, edit /etc/apt/sources.list and make sure to add these lines (and comment everything else):

vi /etc/apt/sources.list

deb http://ftp.debian.org/debian/ squeeze main contrib
deb-src http://ftp.debian.org/debian/ squeeze main contrib
deb http://security.debian.org/ squeeze/updates main contrib
deb-src http://security.debian.org/ squeeze/updates main contrib

== Prerequisites for compiling TelcoBridges packages ==

Get build tools (zlib and libxml2 are required for higher level applications):
apt-get install make g++ libxml2-dev zlib1g-dev libmysqlclient-dev unixodbc-dev libssl-dev

Install ruby 1.8.7-p174:
wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/src/centos/ruby-1.8.7-p174.tar.gz
tar -zxf ruby-1.8.7-p174.tar.gz
cd ruby-1.8.7-p174
./configure --libdir=/usr/local/lib64 --enable-shared
make
make install
cd ext/openssl
ruby extconf.rb
make
make install
ln -s /usr/local/bin/ruby /usr/bin/ruby
ln -s /usr/local/lib64/libruby.so.1.8 /lib64/libruby.so.1.8

TelcoBridges only support 64-bit applications on Debian 6. When compiling, use the '''X86_64=1''' flag. For example:
make all X86_64=1 DBG=1

== Prerequisites for running custom TelcoBridges applications ==

Make sure all prerequisites are already installed:
apt-get install libxml2 zlib1g

The following prerequisites may be required if the applications use MySQL:
apt-get install libmysqlclient unixodbc

== Prerequisites for running Toolpack ==

Make sure all prerequisites are already installed. An older version of the MySQL server is required in order to be compatible with the Ruby version.
apt-get install libxml2 zlib1g libmysqlclient unixodbc libmyodbc libfcgi libfcgi-dev lighttpd sysv-rc-conf
apt-get install mysql-server-core-5.1=5.1.49-3
apt-get install mysql-server-5.1=5.1.49-3

Install ruby 1.8.7-p174 (same procedure as mentioned above):
cd ~
wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/src/centos/ruby-1.8.7-p174.tar.gz
tar -zxf ruby-1.8.7-p174.tar.gz
cd ruby-1.8.7-p174
./configure --libdir=/usr/local/lib64 --enable-shared
make
make install
cd ext/openssl
ruby extconf.rb
make
make install
ln -s /usr/local/bin/ruby /usr/bin/ruby
ln -s /usr/local/lib64/libruby.so.1.8 /lib64/libruby.so.1.8

Install ODBC driver:
odbcinst -i -f /usr/share/libmyodbc/odbcinst.ini -d

Set up mysql:
mysql -u root -p
CREATE USER 'tbdb'@'%' IDENTIFIED BY 'tbdbpw';
GRANT ALL PRIVILEGES ON *.* TO 'tbdb'@'%' IDENTIFIED BY 'tbdbpw';
FLUSH PRIVILEGES;
exit

Set up my.cnf:
vi /etc/mysql/my.cnf
* Uncomment the '''server-id''' and '''log_bin''' lines
* Change '''max_allowed_packet''' to 200M
* Add '''max_allowed_packet=200M''' in the '''[mysqldump]''' section
Restart MySQL server:
service mysql restart

Remove lighttpd from init scripts (remove X's in the lighttpd line):
sysv-rc-conf
service lighttpd stop

Install ruby gems:
cd ~
wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/src/centos/rubygems-1.3.5.tgz
tar -zxf rubygems-1.3.5.tgz
cd rubygems-1.3.5
ruby setup.rb

Install fcgi gem:
gem install fcgi

== Toolpack System installation ==

Now that the prerequisite are installed, now it is time to install the [[toolpack_installer_2-6|Toolpack system]]

Toolpack prerequisite Debian6 2-6

2012-04-02T14:39:55Z

Atremblay: Created page with 'This page shows the prerequisites required for compiling and running TelcoBridges applications on Debian 6. Most procedures assume supervisor (root) access on the system. == Deb…'

This page shows the prerequisites required for compiling and running TelcoBridges applications on Debian 6. Most procedures assume supervisor (root) access on the system.

== Debian 6 OS installation ==

The configuration used for redacting this page was installed using the debian-6.0.4-amd64-CD-1.iso CD image (http://cdimage.debian.org/debian-cd/6.0.4/amd64/iso-cd/debian-6.0.4-amd64-CD-1.iso). Only the SSH server and standard utilities were installed. No network packages were used.

Make sure sources.list has squeeze in the sources package list (it will not be present if the installation did not use the network packages). If you have problems with apt-get, edit /etc/apt/sources.list and make sure to add these lines (and comment everything else):

vi /etc/apt/sources.list

deb http://ftp.debian.org/debian/ squeeze main contrib
deb-src http://ftp.debian.org/debian/ squeeze main contrib
deb http://security.debian.org/ squeeze/updates main contrib
deb-src http://security.debian.org/ squeeze/updates main contrib

== Prerequisites for compiling TelcoBridges packages ==

Get build tools (zlib and libxml2 are required for higher level applications):
apt-get install make g++ libxml2-dev zlib1g-dev libmysqlclient-dev unixodbc-dev libssl-dev

Install ruby 1.8.7-p174:
wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/src/centos/ruby-1.8.7-p174.tar.gz
tar -zxf ruby-1.8.7-p174.tar.gz
cd ruby-1.8.7-p174
./configure --libdir=/usr/local/lib64 --enable-shared
make
make install
cd ext/openssl
ruby extconf.rb
make
make install
ln -s /usr/local/bin/ruby /usr/bin/ruby
ln -s /usr/local/lib64/libruby.so.1.8 /lib64/libruby.so.1.8

TelcoBridges only support 64-bit applications on Debian 6. When compiling, use the '''X86_64=1''' flag. For example:
make all X86_64=1 DBG=1

== Prerequisites for running custom TelcoBridges applications ==

Make sure all prerequisites are already installed:
apt-get install libxml2 zlib1g

The following prerequisites may be required if the applications use MySQL:
apt-get install libmysqlclient unixodbc

== Prerequisites for running Toolpack ==

Make sure all prerequisites are already installed. An older version of the MySQL server is required in order to be compatible with the Ruby version.
apt-get install libxml2 zlib1g libmysqlclient unixodbc libmyodbc libfcgi libfcgi-dev lighttpd sysv-rc-conf
apt-get install mysql-server-core-5.1=5.1.49-3
apt-get install mysql-server-5.1=5.1.49-3

Install ruby 1.8.7-p174 (same procedure as mentioned above):
cd ~
wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/src/centos/ruby-1.8.7-p174.tar.gz
tar -zxf ruby-1.8.7-p174.tar.gz
cd ruby-1.8.7-p174
./configure --libdir=/usr/local/lib64 --enable-shared
make
make install
cd ext/openssl
ruby extconf.rb
make
make install
ln -s /usr/local/bin/ruby /usr/bin/ruby
ln -s /usr/local/lib64/libruby.so.1.8 /lib64/libruby.so.1.8

Install ODBC driver:
odbcinst -i -f /usr/share/libmyodbc/odbcinst.ini -d

Set up mysql:
mysql -u root -p
CREATE USER 'tbdb'@'%' IDENTIFIED BY 'tbdbpw';
GRANT ALL PRIVILEGES ON *.* TO 'tbdb'@'%' IDENTIFIED BY 'tbdbpw';
FLUSH PRIVILEGES;
exit

Set up my.cnf:
vi /etc/mysql/my.cnf
Uncomment the '''server-id''' and '''log_bin''' lines
Change '''max_allowed_packet''' to 200M
Add '''max_allowed_packet=200M''' in the '''[mysqldump]''' section
service mysql restart

Remove lighttpd from init scripts (remove X's in the lighttpd line):
sysv-rc-conf
service lighttpd stop

Install ruby gems:
cd ~
wget http://download.distribution.telcobridges.com/3rdparty/prerequisite/src/centos/rubygems-1.3.5.tgz
tar -zxf rubygems-1.3.5.tgz
cd rubygems-1.3.5
ruby setup.rb

Install fcgi gem:
gem install fcgi

== Toolpack System installation ==

Now that the prerequisite are installed, now it is time to install the [[toolpack_installer_2-6|Toolpack system]]

Web Portal Tutorial Guide v2.5

2012-01-18T21:39:17Z

Atremblay: Added RADIUS section

=Introduction=
This guide is designed to provide users with a scenario-based approach to installing [[Tmedia]] and [[Tdev]] systems, using the Web Portal configuration tool. This means that users must first go through the steps that are general to all installations, and subsequently follow the instructions that are specific to their particular application scenario (this corresponds to the type of service, and hardware system being set up).

==Prerequisites==
This document assumes that the [[Tmedia]] or [[Tdev]] devices are installed as described in their Quick Reference Guides, and in the case of the Tmedia system communication has been established with the control network.

(Note: Tmedia devices are shipped with the Tmedia Web Portal pre-installed, while Tdev devices require that Toolpack be installed as described in the [http://download.distribution.telcobridges.com/documentation/TMP6400_Installation_Guide.pdf TMP6400 Installation Guide].)

Furthermore, in the case of a Tdev device and the initial configuration of the [[Toolpack]] application server, the following will have been provided:
*The Tdev device to which the Web Portal will first connect.
*The Tdev device will have been pre-configured with its physical TDM interface.
*The serial number of the Tdev device will have been entered into the configuration file.
*The application software for the Tdev device will have been pre-installed on the Toolpack application server, as described in the [http://download.distribution.telcobridges.com/documentation/TMP6400_Installation_Guide.pdf TMP6400 Installation Guide].

This document also assumes familiarity with topics, such as [[ISDN]] signaling, [[SIP]] signaling, [[SS7]], [[CAS|CAS R2]] signaling, and [[SIGTRAN]] signaling.

==Key Concepts==
*'''System:''' A system is defined as the complete solution that is designed for a network. If a system solution is comprised of 4 TMP6400’s and a TMS1600, then the combination of these TelcoBridges devices is termed a system.
*'''Hardware:''' Each TelcoBridges devices, whether it is a TMP6400, TMG3200, or TMS1600 is referred to as a hardware device or hardware adapter.
*'''Line Interface:''' The physical TDM module installed on the TelcoBridges device is referred to as a line interface.

== General Web Portal Applications ==

'''''IMPORTANT!''''' The Topics covered in the following table are common to all TMedia installations. Therefore, this section should be consulted before moving on to any other.

 '''Topics covered here:'''

*The basic knowledge needed to properly navigate through the Web Portal '''(A)'''.
*The fundamentals of user account management and permission masks '''(B)'''.
*The initial steps required for first starting the Web Portal, and verifying that it is functioning properly '''(C)'''.
*The process involved in backing up your database for the first time '''(D)'''.
*The process involved in first configuring your IP interfaces '''(E)'''.

 

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | (Topic A) Web Portal Basics
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | (Topic B) Log-on and User Access Levels
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | (Topic C) Application Start-up and Verification
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | (Topic D) Database Backup
|-
| valign="top" |
*[[Toolpack v2.5:Navigating the Web Portal|Navigating the Web Portal]]
*[[Typographic conventions|Typographic Conventions]]

 

| valign="top" |
*[[Toolpack v2.5:Connecting to the Web Server and logging on to the web portal|Connect to the web server and log on to the Web Portal]]
*[[Toolpack:User access|User Access]]
**[[Toolpack v2.5:Viewing the User List|Viewing the User List]]
**[[Toolpack v2.5:Creating a New User|Creating a New User]]
**[[Toolpack v2.5:Deleting a User|Deleting a User]]
**[[Toolpack v2.5:Logging Off Toolpack|Logging Off]]
*[https://forums.telcobridges.com/viewtopic.php?f=12&t=248&p=1101&hilit=privilege#p1101 User privilege level]

| valign="top" |
*[[Toolpack v2.5:Viewing the List of Installed Applications|Viewing the List of Installed Applications]]
*[[Toolpack v2.5:Starting an Application|Starting an Application]]
*[[Toolpack:Verifying that an Application is Operating|Verifying that an Application is Operating]]
**[[Toolpack v2.5:Verifying the Application Path|Verifying the Application Path]]
*[[Toolpack v2.5:Activating the Configuration|Activating the Configuration]]
**[[Toolpack v2.5:Status Menus:Applications|Verifying status]]

| valign="top" |
*[[Toolpack v2.5:Database Backup|Carrying out a First Database Backup]]
*[[Toolpack v2.5:Downloading a Database Backup|Downloading a Database Backup]]
*[[Toolpack v2.5:Uploading a Database Backup|Uploading a Database Backup]]
*[[Toolpack v2.5:Restoring a Database Backup|Restoring a Database Backup]]

|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | (Topic E) Configure IP Interfaces
|-
| valign="top" |
*[[Toolpack v2.5:Configuring IP Interfaces|Configure IP Interfaces]]

|}

=ISDN-SIP Gateway Configuration=

The following tables contain a typical configuration scenario for an [[ISDN]] to [[SIP]] gateway. This type of installation allows for the transfer of information from traditional [[ISDN]] signaling to [[SIP]] protocol for [[VoIP]] applications. Please follow each step one after another as these are listed in logical order.

'''The steps are as follows:'''

*1) Log On and Create a New Configuration
*2) Allocate Physical Interfaces
*3) Configure ISDN-PRI Signaling
*4) Configure Clocking Source
*5) Configure SIP Signaling
*6) Configure Codecs and Tone Detection
*7) Configure Network Access Points (NAPs)
*8) Create Call Routing Rules

'''IMPORTANT!''' After completing the setup process, remember to '''activate the configuration''', as outlined in the [[Web_Portal_Tutorial_Guide_v2.5#General_Web_Portal_Applications|General Web Portal Applications section]].

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Log On and Create a New Configuration

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Allocate Physical Interfaces

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configure ISDN-PRI Signaling

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configure Clocking Source

|-
| valign="top" |
*[[Toolpack_v2.5:Connecting_to_the_Web_Server_and logging on to the web portal|Connect to the web server and log on to the Web Portal]]
*[[Toolpack_v2.5:Copying_the_Default_Configuration|Copy the default configuration]]

| valign="top" |
*[[Toolpack_v2.5:Creating_a_Line_Interface|Create a new line interface]]
*[[Toolpack_v2.5:Creating_a_Line_Service|Create a new line service]]

| valign="top" |
*[[Toolpack_v2.5:Configuring_an_ISDN_Stack|Configure an ISDN stack]]
OR 
*[[Configure NFAS]]

| valign="top" |
*[[Toolpack_v2.5:Defining_a_Clocking_Source|Define a clocking source]]

|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Configure SIP Signaling

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 6) Configure Codecs and Tone Detection

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 7) Configure Network Access Points (NAPs)

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 8) Create Call Routing Rules

|-
| valign="top" |
*[[Toolpack_v2.5:Creating_an_IP_Port_Range|Create an IP port range]]
*[[Toolpack_v2.5:Creating_a_SIP_Stack|Create a SIP stack]]
*[[Toolpack_v2.5:Creating_a_SIP_Transport_Server|Create a SIP transport server]]
*[[Toolpack_v2.5:Creating_a_Service_Access_Point_(SAP)|Create a service access point (SAP)]]

| valign="top" |
*[[Toolpack_v2.5:Accessing_Codec_and_Tone_Detection_Profiles_and_Validating_Settings|Access profiles and validate settings]]

| valign="top" |
*[[Toolpack_v2.5:Allocating_an_ISDN_Network_Access_Point_(NAP)|Allocate an ISDN NAP]]
*[[Toolpack_v2.5:Allocating_a_SIP_Network_Access_Point_(NAP)|Allocate a SIP NAP]]

| valign="top" |
*[[Toolpack_v2.5:Creating_a_First_Call_Route|Create a first call route]]
|}

=Configuring SS7=

The following table contains information on configuring the [[SS7]] signaling protocol.
The various control layers of the [[SS7]] protocol are listed individually in each column. These layers are:

* [[MTP2_Layer|MTP2]] layer '''(Step 1)'''
* [[MTP3_Layer|MTP3]] layer '''(Step 2)'''
* [[ISUP]] layer '''(Step 3)'''
* [[SCCP]] layer '''(Step 4)'''
* [[TCAP]] layer '''(Step 5)'''

'''Follow the topics listed in each column from left to right in order to configure an SS7 protocol stack.'''

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Configuring the MTP2 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring the MTP3 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the ISUP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configuring the SCCP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Configuring the TCAP Layer

|-
| valign="top" |
*[[Toolpack_v2.5:Creating_an_MTP2_Configuration|Create an MTP2 Configuration]]
*[[Toolpack_v2.5:Creating_MTP2_Links|Create an MTP2 Link]]

| valign="top" |
*[[Toolpack_v2.5:Creating_an_MTP3_Configuration|Create an MTP3 Configuration]]
*[[Toolpack_v2.5:Creating_an_MTP3_Network|Create an MTP3 Network]]
**[[Toolpack_v2.5:Creating_SS7_Point_Codes|Create an MTP3 Point Code]]
**[[Toolpack_v2.5:Creating_an_MTP3_Linkset|Create an MTP3 Linkset]]
***[[Toolpack_v2.5:Creating_MTP3_Links|Create MTP3 Links]]
**[[Toolpack_v2.5:Creating_an_MTP3_Route|Create an MTP3 Route]]

| valign="top" |
*[[Toolpack_v2.5:Creating_an_ISUP_Stack|Create an ISUP Stack]]
*[[Toolpack_v2.5:Creating_an_ISUP_Network|Create an ISUP Network]]
*[[Toolpack_v2.5:Creating_an_ISUP_User_Part|Create an ISUP User Part]]
*[[Toolpack_v2.5:Creating_an_ISUP_Interface|Create an ISUP Interface]]

| valign="top" |
*[[Toolpack_v2.5:Creating_an_SCCP_Stack| Create an SCCP Stack]]
*[[Toolpack_v2.5:Creating_an_SCCP_Network|Create an SCCP Network]]
**[[Toolpack_v2.5:Creating_an_SCCP_Userpart|Create an SCCP Userpart]]
**[[Toolpack_v2.5:Creating_an_SCCP_LSAP|Create an SCCP LSAP]]
***[[Toolpack_v2.5:Creating_an_SCCP_Route|Create an SCCP Route]]
****[[Toolpack_v2.5:Creating_an_SCCP_SSN|Create an SCCP SSN]]
*[[Toolpack_v2.5:Creating_an_SCCP_GTT_Association|Create an SCCP GTT Association]]
**[[Toolpack_v2.5:Creating_an_SCCP_GTT_Address_Map|Create an SCCP GTT Address Map]]

| valign="top" |
*[[Toolpack_v2.5:Creating_a_TCAP_Stack|Create a TCAP Stack]]
**[[Toolpack_v2.5:Creating_a_TCAP_Userpart| Create a TCAP Userpart]]
*[[Toolpack_v2.5:Activating_the_Configuration|Activating the Configuration]]

|}

=SIGTRAN Application Scenarios=

Toolpack version 2.5 enables you to configure SIGTRAN and thereby extend SS7 signalling functionality to the IP network. Toolpack enables you to configure a number of SIGTRAN applications based upon your requirements. These applications are listed below as follows: 

*[[M2PA]] system. See column '''(A)''' below. In this configuration the SS7 MTP2 layer is replaced by the SIGTRAN M2PA layer which extends MTP2 signalling functionality into the IP network. This application is typically used between a Signalling Gateway and an IP Signalling Point, or between two IP Signalling Points.

*[[M2UA]] system. See columns '''(B)''' and '''(C)''' below. An M2UA system on a Signalling Gateway Controller interfaces with an M2UA system on a Media Gateway Controller. In this configuration, M2UA bridges the SS7 MTP2 layer of a Signalling Gateway, across an IP network, with the SS7 MTP3 layer of a Media Gateway Controller.

*[[IUA]] system. See column '''(D)''' below. An IUA system on a Signalling Gateway Controller interfaces with an IUA system on a Media Gateway Controller. In this configuration, IUA bridges the SS7 MTP2 layer of a Signalling Gateway, across an IP network, with the SS7 MTP3 layer of a Media Gateway Controller.

*[[M3UA]] system on two IP signalling points. See column '''(E''') below. In this configuration the SS7 MTP2 and MTP3 layers are replaced entirely by the SIGTRAN M3UA layer. This application is typically used between two IP Signalling Points.

*[[M3UA]] system. See columns '''(F)''' and '''(G)''' below. An M3UA system on a Signalling Gateway Process interfaces with an M3UA system on an Application Server Process. In this configuration, the MTP3 links are extended across the IP network.

 '''A SIGTRAN scenario walkthrough is provided in the table columns below, to illustrate the order that must be followed when configuring SIGTRAN.''' 

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Scenario A) Configuring an M2PA System
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Scenario B) Configuring an M2UA System on a Signalling Gateway
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Scenario C) Configuring an M2UA System on a Media Gateway Controller
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Scenario D) Configuring an IUA System on a Signalling Gateway
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Scenario E) Configuring an M3UA System on IP Signalling Points
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Scenario F) Configuring an M3UA System on a Signalling Gateway
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Scenario G) Configuring an M3UA System on an Application Server
|-
|
*[[Toolpack v2.5:Adding an Adapter|Adding an Adapter]]
*[[Toolpack v2.5:Creating a Line Interface|Create Line Interfaces]]
*[[Toolpack v2.5:Creating a Line Service|Create Line services]]
*[[Toolpack v2.5:Editing the SCTP Configuration|Edit the SCTP Configuration]]
*[[Toolpack v2.5:Creating the M2PA Configuration|Create an M2PA Configuration]]
**[[Toolpack v2.5:Creating an M2PA SAP|Create an M2PA SAP]]
**[[Toolpack v2.5:Adding M2PA Links|Add M2PA Links]]
*[[Toolpack v2.5:Creating SS7 Point Codes|Create SS7 Point Codes]]
*[[Toolpack v2.5:Creating an MTP3 Configuration|Create an MTP3 Configuration]]
**[[Toolpack v2.5:Creating an MTP3 Network|Create an MTP3 Network]]
**[[Toolpack v2.5:Creating an MTP3 Linkset|Create an MTP3 Linkset]]
***[[Toolpack v2.5:Creating MTP3 Links (M2PA)|Create MTP3 Links]]
**[[Toolpack v2.5:Creating an MTP3 Route|Create an MTP3 Route]]
*[[Toolpack v2.5:Creating an ISUP Stack|Create an ISUP Stack]]
**[[Toolpack v2.5:Creating an ISUP Network|Create an ISUP Network]]
**[[Toolpack v2.5:Creating an ISUP User Part|Create an ISUP User Part]]
**[[Toolpack v2.5:Creating an ISUP Interface|Create an ISUP Interface]]
***[[Toolpack v2.5:Creating ISUP CIC Groups|Create ISUP CIC Groups]]
**[[Toolpack v2.5:Creating a NAP (SIGTRAN)|Create a NAP]]

| valign="top" |
*[[Toolpack v2.5:Adding an Adapter|Adding an Adapter]]
*[[Toolpack v2.5:Creating a Line Interface|Create Line Interfaces]]
*[[Toolpack v2.5:Creating a Line Service|Create Line services]]
*[[Toolpack v2.5:Creating an MTP2 Configuration|Create an MTP2 Configuration]]
**[[Toolpack v2.5:Creating MTP2 Links|Create MTP2 Links]]
*[[Toolpack v2.5:Creating the SCTP Configuration|Edit the SCTP Configuration]]
*[[Toolpack v2.5:Creating the M2UA Configuration|Create an M2UA Configuration]]
**[[Toolpack v2.5:Creating an M2UA SAP|Create an M2UA SAP]]
**[[Toolpack v2.5:Creating an M2UA Cluster|Create an M2UA Cluster]]
**[[Toolpack v2.5:Creating M2UA Links|Create M2UA Links]]
**[[Toolpack v2.5:Creating M2UA Peers|Create M2UA Peers]]

 

| valign="top" |
*[[Toolpack v2.5:Adding an Adapter|Adding an Adapter]]
*[[Toolpack v2.5:Editing the SCTP Configuration|Edit the SCTP Configuration]]
*[[Toolpack v2.5:Creating the M2UA Configuration|Create an M2UA Configuration]]
**[[Toolpack v2.5:Creating an M2UA SAP|Create an M2UA SAP]]
**[[Toolpack v2.5:Creating an M2UA Cluster|Create an M2UA Cluster]]
**[[Toolpack v2.5:Creating M2UA Links|Create M2UA Links]]
**[[Toolpack v2.5:Creating M2UA Peers|Create M2UA Peers]]
*[[Toolpack v2.5:Creating SS7 Point Codes|Create SS7 Point Codes]]
*[[Toolpack v2.5:Creating an MTP3 Configuration|Create an MTP3 Configuration]]
**[[Toolpack v2.5:Creating an MTP3 Network|Create an MTP3 Network]]
**[[Toolpack v2.5:Creating an MTP3 Linkset|Create an MTP3 Linkset]]
**[[Toolpack v2.5:Creating MTP3 Links (M2UA)|Create MTP3 Links]]
**[[Toolpack v2.5:Creating an MTP3 Route|Create an MTP3 Route]]
*[[Toolpack v2.5:Creating an ISUP Stack|Create an ISUP Stack]]
**[[Toolpack v2.5:Creating an ISUP Network|Create an ISUP Network]]
**[[Toolpack v2.5:Creating an ISUP User Part|Create an ISUP User Part]]
**[[Toolpack v2.5:Creating an ISUP Interface|Create an ISUP Interface]]
***[[Toolpack v2.5:Creating ISUP CIC Groups|Create ISUP CIC Groups]]
**[[Toolpack v2.5:Creating a NAP (SIGTRAN)|Create a NAP]]

| valign="top" |
*[[Toolpack v2.5:Adding an Adapter|Adding an Adapter]]
*[[Toolpack v2.5:Creating a Line Interface|Create Line Interfaces]]
*[[Toolpack v2.5:Creating a Line Service|Create Line services]]
*[[Toolpack v2.5:Creating the SCTP Configuration|Edit the SCTP Configuration]]
*[[Toolpack v2.5:Creating the IUA Configuration|Create an IUA Configuration]]
**[[Toolpack v2.5:Creating an IUA SAP|Create an IUA SAP]]
**[[Toolpack v2.5:Creating an IUA Cluster|Create an IUA Cluster]]
**[[Toolpack v2.5:Creating IUA Links|Create IUA Links]]
**[[Toolpack v2.5:Creating IUA Peers|Create IUA Peers]]

 

| valign="top" |
*[[Toolpack v2.5:Adding an Adapter|Adding an Adapter]]
*[[Toolpack v2.5:Editing the SCTP Configuration|Edit the SCTP Configuration]]
*[[Toolpack v2.5:Creating SS7 Point Codes|Create SS7 Point Codes]]
*[[Toolpack v2.5:Creating an M3UA Configuration (IPSP)|Create an M3UA Configuration]]
**[[Toolpack v2.5:Creating an M3UA SAP|Create an M3UA SAP]]
**[[Toolpack v2.5:Creating an M3UA Network|Create an M3UA Network]]
**[[Toolpack v2.5:Creating an M3UA User Part|Create an M3UA User Part]]
**[[Toolpack v2.5:Creating an M3UA Peer Signalling Process (IPSP)|Create an M3UA Peer Signalling Process]]
**[[Toolpack v2.5:Creating an M3UA Peer Server|Create an M3UA Peer Server]]
**[[Toolpack v2.5:Creating an M3UA Route|Create an M3UA Route]]
*[[Toolpack v2.5:Creating an ISUP Stack|Create an ISUP Stack]]
**[[Toolpack v2.5:Creating an ISUP Network|Create an ISUP Network]]
**[[Toolpack v2.5:Creating an ISUP User Part|Create an ISUP User Part]]
**[[Toolpack v2.5:Creating an ISUP Interface|Create an ISUP Interface]]
***[[Toolpack v2.5:Creating ISUP CIC Groups|Create ISUP CIC Groups]]
**[[Toolpack v2.5:Creating a NAP (SIGTRAN)|Create a NAP]]

| valign="top" |
*[[Toolpack v2.5:Adding an Adapter|Adding an Adapter]]
*[[Toolpack v2.5:Creating a Line Interface|Create Line Interfaces]]
*[[Toolpack v2.5:Creating an MTP2 Configuration|Create an MTP2 Configuration]]
*[[Toolpack v2.5:Creating MTP2 Links|Create MTP2 Links]]
*[[Toolpack v2.5:Editing the SCTP Configuration|Edit the SCTP Configuration]]
*[[Toolpack v2.5:Creating SS7 Point Codes|Create SS7 Point Codes]]
*[[Toolpack v2.5:Creating an MTP3 Configuration|Create an MTP3 Configuration]]
**[[Toolpack v2.5:Creating an MTP3 Network|Create an MTP3 Network]]
**[[Toolpack v2.5:Creating an MTP3 Linkset|Create an MTP3 Linkset]]
**[[Toolpack v2.5:Creating MTP3 Links (M3UA)|Create MTP3 Links]]
**[[Toolpack v2.5:Creating an MTP3 Route|Create an MTP3 Route]]
*[[Toolpack v2.5:Creating an M3UA Configuration (SGP)|Create an M3UA Configuration]]
**[[Toolpack v2.5:Creating an M3UA SAP|Create an M3UA SAP]]
**[[Toolpack v2.5:Creating an M3UA Network|Create an M3UA Network]]
**[[Toolpack v2.5:Creating an M3UA User Part|Create an M3UA User Part]]
**[[Toolpack v2.5:Creating an M3UA Peer Signalling Process (SGP)|Create an M3UA Peer Signalling Process]]
**[[Toolpack v2.5:Creating an M3UA Peer Server|Create an M3UA Peer Server]]
**[[Toolpack v2.5:Creating an M3UA Route (SGP)|Create an M3UA Route]] 

| valign="top" |
*[[Toolpack v2.5:Adding an Adapter|Adding an Adapter]]
*[[Toolpack v2.5:Editing the SCTP Configuration|Edit the SCTP Configuration]]
*[[Toolpack v2.5:Creating SS7 Point Codes|Create SS7 Point Codes]]
*[[Toolpack v2.5:Creating an M3UA Configuration (ASP)|Create an M3UA Configuration]]
**[[Toolpack v2.5:Creating an M3UA SAP|Create an M3UA SAP]]
**[[Toolpack v2.5:Creating an M3UA Network|Create an M3UA Network]]
**[[Toolpack v2.5:Creating an M3UA User Part|Create an M3UA User Part]]
**[[Toolpack v2.5:Creating an M3UA Peer Signalling Process (ASP)|Create an M3UA Peer Signalling Process]]
**[[Toolpack v2.5:Creating an M3UA Peer Server|Create an M3UA Peer Server]]
**[[Toolpack v2.5:Creating an M3UA Route|Create an M3UA Route]]
*[[Toolpack v2.5:Creating an ISUP Stack|Create an ISUP Stack]]
**[[Toolpack v2.5:Creating an M3UA ISUP Network|Create an M3UA ISUP Network]]
**[[Toolpack v2.5:Creating an ISUP User Part|Create an ISUP User Part]]
**[[Toolpack v2.5:Creating an ISUP Interface|Create an ISUP Interface]]
***[[Toolpack v2.5:Creating ISUP CIC Groups|Create ISUP CIC Groups]]
**[[Toolpack v2.5:Creating a NAP (SIGTRAN)|Create a NAP]]

|}

=Configuring CAS R2=

Toolpack v2.5 allows you to configure CAS R2 signaling stacks. The following table lists the basic steps that must be followed in order to configure CAS R2.

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Configuring a CAS R2 stack

|-
| valign="top" |
*[[Toolpack v2.5:Adding an Adapter|Adding an Adapter]]
*[[Toolpack_v2.5:Creating_a_Line_Interface|Create Line Interfaces]]
*[[Toolpack_v2.5:Creating_a_Line_Service|Create Line services]]
*[[Toolpack v2.5:Copy variant script|Copy variant script]]
*[[Toolpack v2.5:Create CAS R2 stack|Create CAS R2 stack]]
*[[Toolpack v2.5:Setting CAS R2 BACK DIGITS variable|Set backward digits string]]
*[[Toolpack_v2.5:Creating_a_CAS_R2_NAP|Create a NAP]]

|}

=Configuring H.248=

The following table contains steps for configuring an H.248 media gateway control protocol

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Add a Hardware Adapter
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Create IP Port Ranges
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configure Network Access Points (NAPs)

|-
| valign="top" |
*[[Toolpack_v2.5:Adding_an_Adapter|Adding an Adapter]]

| valign="top" |
*[[Toolpack_v2.5:Creating_a_Line_Interface|Create line interfaces]]
*[[Toolpack_v2.5:Creating_a_Line_Service|Create line services]]

| valign="top" |
*[[Toolpack_v2.5:Creating_an_IP_Port_Range|Create IP port ranges]]

| valign="top" |
*[[Toolpack_v2.5:Allocating_a_VoIP_Network_Access_Point_(NAP)|Allocate a VoIP network access point (NAP)]]
*[[Toolpack_v2.5:Allocating_a_TDM_Network_Access_Point_(NAP)|Allocate a TDM network access point (NAP)]]

|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Configure the Media Gateway for H.248 mode
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 6) Create an H.248 Configuration
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 7) Add a New Media Gateway Controller
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 8) Associate NAPs with the H.248 Configuration

|-
| valign="top" |
*[[Toolpack_v2.5:Configure the Media_Gateway_for_H248_Mode|Configure the Media Gateway for H.248 mode]]

| valign="top" |
*[[Toolpack_v2.5:Creating_an_H.248_Configuration|Create a new H.248 configuration]]

| valign="top" |
*[[Toolpack_v2.5:Adding_a_Media_Gateway_Controller_(MGC)|Add a new media gateway controller (MGC)]]

| valign="top" |
*[[Toolpack_v2.5:Associating_NAPs_with_an_H.248_Configuration|Associate the NAPs with the H.248 configuration]]

|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 9) Select Timeslots for TDM Terminations

|-
| valign="top" |
*[[Toolpack_v2.5:Selecting_Timeslots_for_TDM_Interfaces|Select timeslots for the TDM interfaces]]
|}

=Configuring an H.323 to SIP Converter=

The following table contains steps for configuring NAPs that wil allow an interface between the web portal and a YATE H.323 to SIP signal converter:

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Configuring an H.323 to SIP Signal Converter

|-
| valign="top" |

* [[Toolpack_v2.5:Creating_H.323_NAP_Columns|Create H.323 NAP columns]]
*[[Toolpack_v2.5:Creating_an_IP_Port_Range|Create an IP port range]]
*[[Toolpack_v2.5:Creating_a_SIP_Stack|Create a SIP stack]]
*[[Toolpack_v2.5:Creating_a_SIP_Transport_Server|Create a SIP transport server]]
*[[Toolpack_v2.5:Creating_a_Service_Access_Point_(SAP)|Create a service access point (SAP)]]
* [[Toolpack_v2.5:Creating_SIP_NAPs_(H.323)|Create SIP NAPs]]
|}

=Configuring SNMP=

To use the Simple Network Management Protocol (SNMP)on your machine, you must first configure the '''tbSnmpAgent'''.
 The '''tbSnmpAgent''' is a software application that interfaces between the TMedia system hardware and the [http://www.net-snmp.org NetSnmp] implementation of the SNMP that is supported by TelcoBridges.
By default, tbSnmpAgent is '''disabled'''. In order to use the SNMP protocol to monitor and manage your hardware, complete the following tasks:
 
* Activate the tbSnmpAgent
* Configure the tbSnmpAgent as required
 
These tasks can be completed using the [[Web Portal]]:
 
#[[Activating tbSnmpAgent|Activate tbSnmpAgent]]
#[[Configuring tbSnmpAgent|Configure tbSNMPAGENT to suit your needs]]
 
Once these tasks are completed, your TMedia platform is ready to expose system variables for polling with the Simple Network management Protocol (SNMP).

=Configuring RADIUS=

Toolpack v2.5 can send accounting requests containing CDR data to a remote RADIUS server. In order to do so, refer to the [[Toolpack_v2.5:Configuring_RADIUS|Configuring RADIUS]] page.

=Status Menus=

The Web Portal configuration tool will guide you through a number of status menus, each of which indicate the current state of a certain hardware service (assuming said service has been configured).
The following table contains the general conventions of the Web Portal's display '''(A)''', as well as a variety of specific status menus '''(B)'''.

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (A) Menus Overview
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (B) Individual Menu Descriptions

|-
| valign="top" |

*[[Toolpack_v2.5:Tmedia_Status_Menus|Tmedia Status Menus]]
**[[Toolpack_v2.5:Status_Menus:Navigation|Navigation]]
**[[Toolpack_v2.5:Status_Menus:Screen_Conventions|Status Screen Conventions]]

| valign="top" |

*[[Toolpack_v2.5:Status_Menus:System|System]]
*[[Toolpack_v2.5:Status_Menus:Adapters_and_IP_Interfaces|Adapters and IP Interfaces]]
*[[Toolpack_v2.5:Status_Menus:Hosts|Hosts]]
*[[Toolpack_v2.5:Status_Menus:Applications|Applications]]
*[[Toolpack_v2.5:Status_Menus:TDM_Lines|TDM Lines]]
*[[Toolpack_v2.5:Status_Menus:SCTP|SCTP]]
*[[Toolpack_v2.5:Status_Menus:SS7_MTP2|SS7 MTP2]]
*[[Toolpack_v2.5:Status_Menus:SS7_M2UA|SS7 M2UA]]
*[[Toolpack_v2.5:Status_Menus:SS7_IUA|SS7 IUA]]
*[[Toolpack_v2.5:Status_Menus:SS7_M2PA|SS7 M2PA]]
*[[Toolpack_v2.5:Status_Menus:SS7_M3UA|SS7 M3UA]]
*[[Toolpack_v2.5:Status_Menus:SS7_MTP3|SS7 MTP3]]
*[[Toolpack_v2.5:Status_Menus:SS7_ISUP|SS7 ISUP]]
*[[Toolpack_v2.5:Status_Menus:SS7_SCCP|SS7 SCCP]]
*[[Toolpack_v2.5:Status_Menus:SS7_TCAP|SS7 TCAP]]
*[[Toolpack_v2.5:Status_Menus:ISDN|ISDN]]
**[[Toolpack_v2.5:Status_Menus:NFAS|NFAS]]
*[[Toolpack_v2.5:Status_Menus:CAS R2|CAS R2]]
*[[Toolpack_v2.5:Status_Menus:SIP|SIP]]
*[[Toolpack_v2.5:Status_Menus:Clock|Clock]]
*[[Toolpack_v2.5:Status_Menus:TMS|TMS]]
*[[Toolpack_v2.5:Status_Menus:NAP|NAP]]
*[[Toolpack_v2.5:Status_Menus:H.248|H.248]]
*[[Toolpack_v2.5:Status_Menus:CDR|CDR]]

|}

=Further Reading=
For further information, refer to the following reading list. Please note that all guides listed below are in portable document format (*.PDF), and can be downloaded:

*[[media:TMedia System Architecture Description.pdf|TMedia System Architecture Overview for Developers of VoIP and TDM Solutions]]
*[[Media:Tb640 user's guide.pdf|TB640 User's Guide]]
*[[media:SS7 user's guide.pdf|TelcoBridges SS7 User's Guide]]
*[[media:Tb640 sip user's guide.pdf|SIP User’s Guide]]

[[category:Toolpack]]

File:RADIUS v2 6 server create success.png

2012-01-18T21:32:46Z

Atremblay:

File:RADIUS v2 6 server create new.png

2012-01-18T21:32:40Z

Atremblay:

File:RADIUS v2 6 server cfg.png

2012-01-18T21:32:32Z

Atremblay:

File:RADIUS v2 6 gw menu radius.png

2012-01-18T21:32:25Z

Atremblay:

File:RADIUS v2 6 gw menu configurations.png

2012-01-18T21:32:17Z

Atremblay:

File:RADIUS v2 6 gw cdr mode.png

2012-01-18T21:32:09Z

Atremblay:

File:RADIUS v2 6 gw cdr check.png

2012-01-18T21:32:03Z

Atremblay:

File:RADIUS v2 6 client cfg create success.png

2012-01-18T21:31:55Z

Atremblay:

File:RADIUS v2 6 client cfg create.png

2012-01-18T21:31:47Z

Atremblay:

Toolpack v2.6:Configuring RADIUS

2012-01-18T21:31:31Z

Atremblay: Created RADIUS configuration page for Toolpack v2.6

This page describes how to configure a RADIUS server for accounting in Toolpack v2.6.

1- Select '''Gateway -> Configurations''' from the navigation panel.

[[Image:RADIUS_v2_6_gw_menu_configurations.png|border]]

2- Verify that the box '''Use CDR behavior''' is checked.

[[Image:RADIUS_v2_6_gw_cdr_check.png|border]]

3- Configure the CDR behavior in the '''CDR Options''' section:
* Select the desired '''CDR Mode''':
** '''RADIUS CDR only''': send RADIUS accounting requests
** '''Text and RADIUS CDR''': send RADIUS accounting requests and also save the same CDRs in text files
** '''RADIUS CDR with text CDR fallback''': send RADIUS accounting requests, and if they fail, save the CDRs in text files
* Click '''Save''' to save your changes.

[[Image:RADIUS_v2_6_gw_cdr_mode.png|border]]

4- Verify that the '''Gateway configuration was successfully updated.''' message appears.

[[Image:RADIUS_v2_5_gw_cfg_success.png|border]]

5- Select '''Gateway -> RADIUS''' from the navigation panel.

[[Image:RADIUS_v2_6_gw_menu_radius.png|border]]

6- Configure the RADIUS client:
* In the '''Advanced Parameters''' section, verify that the settings correspond to your desired setup. The '''Maximum accounting concurrent records''' field specifies the number of RADIUS requests that can be simultaneously sent to the RADIUS server. The '''Maximum accounting queued records''' specifies the number of CDR records that can be queued by the RADIUS client when no more simultaneous requests can be sent. When the queue is full, records are discarded (unless text CDR fallback is configured).
* Click '''Create''' to create the RADIUS client.

[[Image:RADIUS_v2_6_client_cfg_create.png|border]]

7- Verify that the '''RADIUS client configuration successfully created.''' message appears.

[[Image:RADIUS_v2_6_client_cfg_create_success.png|border]]

8- In the '''Radius servers''' section, click '''Create new RADIUS server'''.

[[Image:RADIUS_v2_6_server_create_new.png|border]]

9- Configure the RADIUS server configuration:
* Set the server '''Name'''. It can be anything as it is only used in the Web Portal.
* Set the '''Radius server address and port'''.
* Set the '''Server secret'''.
* Click the '''Create''' button to create the RADIUS server configuration.

[[Image:RADIUS_v2_6_server_cfg.png|border]]

10- Verify that the '''RADIUS server was successfully created.''' message appears.

[[Image:RADIUS_v2_6_server_create_success.png|border]]

Toolpack:Configuring RADIUS A

2012-01-18T21:06:20Z

Atremblay: Added borders

This page describes how to configure a RADIUS server for accounting in Toolpack v2.5 or earlier.

1- Select '''Gateway -> Configurations''' from the navigation panel.

[[Image:RADIUS_v2_5_gw_menu_configurations.png|border]]

2- Verify that the box '''Use CDR behavior''' is checked.

[[Image:RADIUS_v2_5_gw_cdr_check.png|border]]

3- Configure the CDR behavior in the '''CDR Options''' section:
* Select '''Radius CDR''' in the '''CDR Mode''' combo box.
* In the '''Radius server parameters''' section, set the '''Radius server address and port''' and '''Server secret''' fields.
* Click '''Save''' to save your changes.

[[Image:RADIUS_v2_5_gw_cdr_configuration.png|border]]

4- Verify that the '''Gateway configuration was successfully updated.''' message appears.

[[Image:RADIUS_v2_5_gw_cfg_success.png|border]]

File:RADIUS v2 5 gw cfg success.png

2012-01-18T21:01:49Z

Atremblay:

File:RADIUS v2 5 gw cdr configuration.png

2012-01-18T20:59:03Z

Atremblay:

File:RADIUS v2 5 gw cdr check.png

2012-01-18T20:58:51Z

Atremblay:

File:RADIUS v2 5 gw menu configurations.png

2012-01-18T20:43:42Z

Atremblay: