TBwiki - User contributions [en]

RADIUS

2010-11-11T19:21:09Z

Ktrueman: /* References */ fixed name of web site

Remote Authentication Dial In User Service, more popularly known as RADIUS, is used by telecom service providers for the purpose of authenticating, authorizing, and accounting for the use of services by subscribers. A RADIUS server is an application server that provides this functionality. It can take as input as well as output [[call detail record]] (CDR) data.

== TelcoBridges and RADIUS==
Starting with release [[Version 2.3|v2.3]] of [[Toolpack]], explicit support for the accounting function of RADIUS is now offered. Previously, Toolpack stored [[call detail record]] (CDR) data in a local database. Starting with Toolpack v2.3, CDR data is stored on a dedicated, external server running an implementation of the RADIUS standard. Configuration of the location of the RADIUS server is performed through the Toolpack web portal. For this initial release, Toolpack only supports the Accounting functionality of RADIUS; it does not support the Administration or Authentication options. That type of functionality can be performed outside of RADIUS using Toolpack.'

=== Prerequisites ===
In order to enable this function in Toolpack v2.3, you must have a RADIUS server already up and running. It is highly recommended that the RADIUS server software being running on a separate machine from the one running the Toolpack software. Before configuring Toolpack, you will need the names and IP address of the RADIUS server. You will need to specify a ‘secret key’ which will authenticate the Toolpack server so that it can send CDR data to the RADIUS server and the RADIUS server will accept it.

=== Steps ===
Assuming that you have already set up and configured a RADIUS server, you will now need to configure Toolpack.

*To configure RADIUS support in Toolpack, first go to '''Global > Gateway > Configurations'''. In the Configuration List, click on '''Create New Configuration'''. This is where you will create a RADIUS configuration.
*In the new configuration, click on '''Use CDR Behaviour'''. Up until now, this is the same approach you would use where CDRs are written to the Toolpack database.
*Now click on the '''CDR options''' section header, then click on '''Use RADIUS''' checkbox.
*Next, fill in the information in the '''RADIUS server parameters''' section. Please note that the '''port''' for the RADIUS Server must be set to 1813 (i.e., hostname:1813);. For the '''Server secret''' field, set it to the same authentication key that is configured on the RADIUS server.

=== Testing this feature ===
Testing this feature is as simple as activating the functionality in Toolpack and validating that CDR data is being properly received by the RADIUS server. If you have the ability to simulate calling data, you might find it worthwhile to gradually increase call volumes over time to identify and understand any limitations experienced with your RADIUS application server (see Known issues below for more on this.)

=== Toolpack to Radius CDR attributes remapping ===

{| class="wikitable" border="1" cellpadding="5"
!width="210" style="background:#efefef;" |Radius IETF param name
!width="210" style="background:#efefef;" |Toolpack param
!width="610" style="background:#efefef;" |Description
|-
| NAS-Identifier || Application Name || Application name of the CDR provider
|-
| Acct-Session-Id || Leg Id || Call Leg Identifier
|-
|Telcob-Other-Leg-Id || Other Leg Id || Call Leg Identifier of the other call leg joined with current call leg
|-
| h323-setup-time || Start Time || Represent the call leg setup time - Coordinated Universal Time (UTC)
|-
| Cisco-NAS-Port || NAP name || Network Access Point name for the call leg
|-
| Called-Sation-Id || Called Number || Called party number
|-
| Calling-Station-Id || Calling Number || Calling party number
|-
| h323-call-origin || Originator Name || "answer" for an outgoing leg - "originate" for an incoming leg
|-
| h323-connect-time || Answer Time || Represent the call leg answer time (connect time) - Coordinated Universal Time (UTC)
|-
| h323-conf-id || Unique Call Id || Unique call Identifier - Link Id formated as xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx (~Linkid ~Linkid<<4 ~Linkid<<12 ~Linkid<<20)
|-
| User-Name || - || For now this value is hardcoded to "100"; this field was asked by portaOne
|-
| h323-call-type || Protocol Type || If protocol is SIP the value is "VOIP", otherwise it is "Telephony"
|-
| h323-disconnect-time || Stop Time || Represent the call leg disconnect time - Coordinated Universal Time (UTC)
|-
| h323-disconnect-cause || Termination Reason || Q.931 disconnect (1 to 160) cause, TB Toolpack system cause (200 to 300) and SIP cause (400 to 600)
|-
| release-source || Termination Source || "localLeg" if this leg terminate the call or "connectedLeg" if its the connected leg - We use a Cisco string field with our own value definition
|-
| Acct-Status-Type || - || Start or Stop
|-
|}

=== Known issues ===

*There appears to be a limit to the rate and quantity at which RADIUS accepts CDRs. Using a copy of FreeRADIUS on Windows XP Server, we are currently working to determine the maximum rate that RADIUS accepts CDRs for that specific configuration. While it may not be broadly representative—it is an open source solution compared to commercial software solutions—it should provide us with a benchmark or order of magnitude.
*Our experience with FreeRADIUS to date has shown that by the time you attain 110 calls/second for a duration of 3 seconds, the buffer in Toolpack is soon overflowed.
*Should RADIUS stop accepting CDRs (i.e., after a certain number per second (quantity / frequency)), Toolpack will then begin buffering to a maximum of 250 CDRs; over and above that buffer, Toolpack will drop CDR information

== References ==
*[http://en.wikipedia.org/wiki/RADIUS Wikipedia article]
*[http://www.freeradius.net FreeRADIUS website]

[[category:Glossary]]

File:DATA SHEET TM1000.pdf

2010-11-10T18:23:22Z

Ktrueman: uploaded a new version of "File:DATA SHEET TM1000.pdf": revised to inlcude mention of Cross-Connect Wire with High-Z and Isolation

Data sheet for the TM1000

File:Interoperability report - Xener.pdf

2010-11-10T18:08:35Z

Ktrueman: uploaded a new version of "File:Interoperability report - Xener.pdf": changed site of Xener softswith

Report summary the results of interoperability testing between TelcoBridges Tmedia VOIP gateway platform and Xener Systems softswitch.

Interoperability:Vendors

2010-11-10T15:46:29Z

Ktrueman: clean up

TelcoBridges equipment has been successfully deployed by customers and partners in over 50 countries in a broad range of scenarios, involving hardware and software from other providers. While not exhaustive, here is a list of providers (in alphabetical order) of technology with which TelcoBridges' products have been deployed or certified:

'''Softswitch/Session Border Controllers (SBC)'''
*ALOE Systems (softswitch; [http://www.telcobridges.com/afficher02.aspx?page=800&langue=en&modeAffichage=0&forceMode=0 certified])
*Asterisk
*Denwa
*FreeSWITCH
*MetaSwitch 
*NetSapiens (softswitch)
*OpenMethods
*Phoenixsoft Cirrus (softswitch)
*PortaOne (softswitch; [http://www.telcobridges.com/afficher02.aspx?page=839&langue=en&modeAffichage=0&forceMode=0 certified])
*Samsung
*Sansay (softswitch/SBC)
*Teles (softswitch; [http://www.telcobridges.com/afficher02.aspx?page=825&langue=en&modeAffichage=2 certified])
*Xener Systems (softswitch; certification in progress as of July 2010)
*YATE

'''Switches'''
*Alcatel-Lucent
**4ESS
**5ESS
**Various MSC models
*Ericsson
**various MSC models
*Huawei
*Nokia-Siemens
**various MSC models
*Nortel
**various DMS models
*Tekelec

'''Media gateways / telecommunications hardware'''
*Adtran
**Various models
*AudioCodes
**Mediant 1000
**Mediant 2000
**Mediant 3000
*Cisco
**AS5300
**AS5400
*Dialogic
**IMG1010
*Genband
**Various models
*Mediatrix
**Various models
*Squire Technologies
**Various models

'''Other'''
*Faxback
*Interact SoftSPOT
*Voxpilot

[[Category:Needs_revising]]

File:Interoperability report - Xener.pdf

2010-11-10T14:54:09Z

Ktrueman: Report summary the results of interoperability testing between TelcoBridges Tmedia VOIP gateway platform and Xener Systems softswitch.

Report summary the results of interoperability testing between TelcoBridges Tmedia VOIP gateway platform and Xener Systems softswitch.

File:FINAL - DATA SHEET TMP7950.pdf

2010-11-04T20:18:09Z

Ktrueman: uploaded a new version of "File:FINAL - DATA SHEET TMP7950.pdf": changed number of network ports to 3 from 2

data sheet for the TMP7950

File:FINAL - DATA SHEET TMP5900.pdf

2010-10-26T12:25:54Z

Ktrueman: uploaded a new version of "File:FINAL - DATA SHEET TMP5900.pdf": revised power requirements downward

data sheet for the TMP5900

File:FINAL - DATA SHEET TMG5800.pdf

2010-10-26T12:19:59Z

Ktrueman: uploaded a new version of "File:FINAL - DATA SHEET TMG5800.pdf": revised power requirements downward.

TMG5800 data sheet - new

File:DATA SHEET TMG8300.pdf

2010-10-12T18:04:59Z

Ktrueman: uploaded a new version of "File:DATA SHEET TMG8300.pdf": fixed network schematic

Data sheet for the TMG8300 H.323 Signaling Converter device

File:DATA SHEET TMG8300.pdf

2010-10-12T16:10:09Z

Ktrueman: Data sheet for the TMG8300 H.323 Signaling Converter device

Data sheet for the TMG8300 H.323 Signaling Converter device

File:Product brief - Tmedia Call Routing Platform v4.pdf

2010-10-06T14:57:45Z

Ktrueman: uploaded a new version of "File:Product brief - Tmedia Call Routing Platform v4.pdf": Corrected reference to the language used to provide CAS R2 scripting. That language is Lua and not Ruby.

Product brief describing the call routing functionality available with Tmedia and its Media Gateway Application. Discussion of both static and dynamic routing, including the new routeset routing approach introduced in Toolpack v2.5

File:FINAL - DATA SHEET TMG5800.pdf

2010-09-23T17:54:00Z

Ktrueman: uploaded a new version of "File:FINAL - DATA SHEET TMG5800.pdf": correct version of the data sheet

TMG5800 data sheet - new

User talk:Vince Beskangy

2010-09-20T15:50:41Z

Ktrueman: Welcome!

'''Welcome to ''TBwiki''!''' We hope you will contribute much and well.
You'll probably want to read [[TBwiki:Getting started|Getting started]]. Again, welcome and have fun!
[[User:Ktrueman|Kenneth Trueman]] 15:50, 20 September 2010 (UTC)

User:Vince Beskangy

2010-09-20T15:50:41Z

Ktrueman: Creating user page with biography of new user.

20 yrs in Telcom industry as support engineer. Both SS7 and inbamnd signalling trunk groups and OSI architecture implimentation of ancillary systems. Specific to cellular indusrtry. CUrrently Senior SS7 network Enineer at Interop Technologies in Irving, Texas. Former employment 5 years at VeriSign corporation. Prior employer in Dallas Texas 15 years with NTC corporation.

File:TMG8300 network schematic with softswitch.jpg

2010-09-16T16:41:43Z

Ktrueman: Network schematic showing TMG8300 in use with a softswitch

Network schematic showing TMG8300 in use with a softswitch

File:TMG8300 network schematic voip and tdm.jpg

2010-09-16T16:39:53Z

Ktrueman: Network schematic showing TMG8300 in a VOIP-TDM converged network context

Network schematic showing TMG8300 in a VOIP-TDM converged network context

File:TMG8300 network schematic voip only.jpg

2010-09-16T16:37:08Z

Ktrueman: Network schematic showing TMG8300 in a VOIP-only context

Network schematic showing TMG8300 in a VOIP-only context

Call routing

2010-09-15T14:00:29Z

Ktrueman: added link to new product brief

Call routing refers to the ability to route calls based on criteria such as origin, destination, time of day, service provider rates, etc.

== TelcoBridges and Call routing ==
TelcoBridges supports call routing across all of its Tmedia and Tdev devices. It offers two approaches to routing. The first is via the Toolpack Media Gateway application where you can manually define [[Toolpack:Creating Called Number Routes|called number routes]]. The second approach, introduced in [[Version 2.3|version 2.3]] of [[Toolpack]], leverages the Ruby scripting language to provide a [[Scriptable Routing Engine|scriptable routing engine]].

== Related actions ==
*Creating called number routes (refer to the appropriate Toolpack release):
**[[Toolpack_v2.2:Creating_Called_Number_Routes|Toolpack v2.2]]
**[[Toolpack_v2.3:Creating_Called_Number_Routes|Toolpack v2.3]]
*[[Scriptable Routing Engine|Configure routing via the Toolpack scriptable routing engine]]

== References ==
*[[Media:Product brief - Tmedia Call Routing Platform v4.pdf|Product brief]]

[[category:Glossary]]
[[category:Needs revising]]

File:Product brief - Tmedia Call Routing Platform v4.pdf

2010-09-15T13:57:24Z

Ktrueman: Product brief describing the call routing functionality available with Tmedia and its Media Gateway Application. Discussion of both static and dynamic routing, including the new routeset routing approach introduced in Toolpack v2.5

SNMP

2010-09-13T14:26:11Z

Ktrueman: updated information

Simple Network Management Protocol (SNMP) is, according to Wikipedia, "used in network management systems to monitor network-attached devices for conditions that warrant administrative attention."

== TelcoBridges and SNMP ==
TelcoBridges offers basic SNMP support (SNMP v1). Specifically, this is the ability to remotely poll or “GET” system variables known as Managed Objects, which are represented in files known as MIBs. TelcoBridges currently offers polling on a limited number of well-known MIBs (RTP, Sonet, Trunk etc.) as well as some proprietary MIBs (SW version, release, temperature sensors), etc.). However, SNMP 'traps' (i.e., alarms) are not supported in the current release, nor is the ability to 'SET' system variables (defined in SNMP v2).

As of September 2010, TelcoBridges is actively investigating the implementation SNMP v2 support, including GET support as well as alarms/traps at the level of Toolpack.

== References ==
*[http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol Wikipedia article]

[[category:Glossary]]
[[category:Needs revising]]

Interoperability:Vendors

2010-09-10T19:53:44Z

Ktrueman: updated with info from Marc.

TelcoBridges equipment has been successfully deployed by customers and partners in over 50 countries in a broad range of scenarios, involving hardware and software from other providers. While not exhaustive, here is a list of providers (in alphabetical order) of technology with which TelcoBridges' products have been deployed or certified:

'''Softswitch/Session Border Controllers (SBC)'''
*ALOE Systems (softswitch; [http://www.telcobridges.com/afficher02.aspx?page=800&langue=en&modeAffichage=0&forceMode=0 certified]
*Asterisk
*Denwa
*FreeSWITCH
*MetaSwitch 
*NetSapiens (softswitch)
*OpenMethods
*Phoenixsoft Cirrus (softswitch)
*PortaOne (softswitch; [http://www.telcobridges.com/afficher02.aspx?page=839&langue=en&modeAffichage=0&forceMode=0 certified])
*Samsung
*Sansay (softswitch/SBC)
*Teles (softswitch; [http://www.telcobridges.com/afficher02.aspx?page=825&langue=en&modeAffichage=2 certified])
*Xener Systems (softswitch; certification in progress as of July 2010)
*YATE

'''Switches'''
*Alcatel-Lucent
**4ESS
**5ESS
**Various MSC models
*Ericsson
**various MSC models
*Huawei
*Nokia-Siemens
**various MSC models
*Nortel
**various DMS models
*Tekelec

'''Media gateways / telecommunications hardware'''
*Adtran
**Various models
*AudioCodes
**Mediant 1000
**Mediant 2000
**Mediant 3000
*Cisco
**AS5300
**AS5400
*Dialogic
**IMG1010
*Genband
**Various models
*Mediatrix
**Various models
*Squire Technologies
**Various models

'''Other'''
*Faxback
*Interact SoftSPOT
*Voxpilot

[[Category:Needs_revising]]

EOL:chassis

2010-09-10T18:55:14Z

Ktrueman: initial content

Previously, TelcoBridges offered a 2U CompactPCI chassis from Kaparel, a Canadian manufacturer that was bought by the another organization named Rittal. The Kaparel brand name and Canadian factory (located in Ontario) have since been wound down. All 2U chassis run under Rittal part number. Customers requiring parts or servicing for a Kaparel-brand chassis should contact [http://www.rittal.com/ Rittal Corp.].

For customers requiring new CompactPCI chassis, TelcoBridges suggests one of the [http://www.cpcidintek.com.cn/photo/ShowPhoto.asp-PhotoID=25.htm 2U models] from [http://www.cpcidintek.com.cn/ DINTEK]

End-of-Life (EOL) policy

2010-09-10T18:48:38Z

Ktrueman: updated dates and added link to Kaparel chassis

==Overview==

TelcoBridges recognizes the desire of its business partners and their customers to both preserve their investments in TelcoBridges products and to reduce the uncertainty associated with new expenditures or with long-term planning.

However, it is the nature of technology and of the marketplace for change to occur, resulting in the appearance of new products and conversely the eventual disappearance of older products. This change is not always in a predictable, linear fashion and can be disruptive to organizations as they plan their operations and investments.

Recognizing this, TelcoBridges has developed an end-of-life (EOL) policy that is designed to provide the company’s business partners and their customers with predictability as well as peace of mind as one product life cycle ends and another begins. This end-of-life policy seeks to minimize and mitigate the effects of changes to product offerings and to assure business partners and their customers that they will be taken care of while availability and support for a given product are eventually phased out.

==TelcoBridges’ approach to managing technological change==
TelcoBridges’ commitment to preserve the investment that its partners and their customers have made in its products starts with an overall product design philosophy that is conscious of continuing changes in the marketplace.

This is borne out by the choice of third-party components that are included in TelcoBridges’ hardware products during their design phase. While designing its products, TelcoBridges takes into account the susceptibility of such components to be subject to end-of-life announcements themselves, as well as the ability of TelcoBridges to secure functionally equivalent alternatives from the same or alternate suppliers, such that the underlying functionality of the company’s products could remain sensibly unchanged following a modification of components.

Should it become necessary to declare end-of-life status for a TelcoBridges product, the company has developed an end-of-life policy that outlines the commitments that TelcoBridges’ business partners and their customers can expect. That elements and milestones of policy are described below.

==End-of-Life process and phases==

The TelcoBridges EOL policy generally follows the following process, as described in the table below. The process begins with the End of Life announcement, the date for which is indicated by the letter X. All subsequent milestones occur within the indicated number of calendar months from that date (X). Definitions of milestones are provided in the following section.

{| class="wikitable" border="1" cellpadding="5"
!width="70" style="background:#efefef;" |Milestone
!width="120" |End-of-Life (EOL) announcement
!width="120" |End of Sale (EOS) announcement
!width="120" |End of production
!width="120" |End of hardware (HW) maintenance
!width="120" |End of software (SW) maintenance
!width="120" |End of service contracts for EOL product(s)
|-
!width="70" style="background:#efefef;" |Date
!width="120" |X
!width="120" |X + 12 months
!width="120" |X + 15 months
!width="120" |X + 48 months
!width="120" |X + 48 months
!width="120" |X + 72 months
|}

==Milestones and definitions==

*'''End of Life (EOL) announcement:''' Date when a formal announcement is made by TelcoBridges and published on its web site at [http://www.telcobridges.com/ www.telcobridges.com]. The end of life announcement lists the product(s) that is (are) to be discontinued and outlines the milestones (or timeframes) for the availability of follow-on purchases, technical support, repairs, etc.

*'''End of Sale (EOS) announcement:''' Date when EOL products are no longer orderable or visible on TelcoBridges’ price lists.
*'''End of production:''' Date when TelcoBridges no longer builds EOL products. The TelcoBridges customer support department will maintain stocks to fulfill Return Material Authorization (RMA) requirements.
*'''End of hardware (HW) maintenance:''' Date when TelcoBridges no longer provides bug fixes to hardware.
*'''End of software (SW) maintenance:''' Date when TelcoBridges no longer provides bug fixes to software.
*'''End of service contracts:''' Date when service contracts are no longer available for products covered by an EOL notice. Service contracts may be renewed to a period equivalent to the end-of-service contract milestone.

==Applicability==
This policy applies to all TelcoBridges products from January 1, 2010 onwards.

==Status==
As of September 2010, TelcoBridges has not declared end-of-life status on any of *its* products and has no intention to do so for the foreseeable future.

While the company offers two core hardware platforms, based on CompactPCI and rackmount form factors, it remains committed to providing products based on both platforms to the marketplace.

Though TelcoBridges has stated publicly that it is focused on rackmount hardware as its platform of choice for new product development--since only that platform allows TelcoBridges to deliver on its goals of performance and system density--the fact that the vast majority of rackmount system components are shared with the company’s CompactPCI-based devices is a strong argument for the continued availability of CompactPCI offerings from TelcoBridges.

From a software application and development toolkit and perspective, both CompactPCI and rackmount platforms are equal citizens and will continue to benefit from advances made in the coming years. The company’s current software roadmap foresees the introduction of new features on both hardware platforms.

== Notices ==
*[[EOL:chassis|Compact PCI Chassis (Kaparel)]]

== References ==
*[[media:TelcoBridges -- End of Life Policy.pdf |PDF version]]

File:FINAL - DATA SHEET TMP5900.pdf

2010-09-10T15:59:03Z

Ktrueman: uploaded a new version of "File:FINAL - DATA SHEET TMP5900.pdf": updated with new product imagery

data sheet for the TMP5900

File:DATA SHEET TMP6400.pdf

2010-09-10T15:58:27Z

Ktrueman: uploaded a new version of "File:DATA SHEET TMP6400.pdf": updated with new product imagery

Data sheet for the TMP6400

File:DATA SHEET TMP6400.pdf

2010-09-10T15:57:05Z

Ktrueman: uploaded a new version of "File:DATA SHEET TMP6400.pdf": updated with new product imagery

Data sheet for the TMP6400

File:DATA SHEET TMP800.pdf

2010-09-10T15:56:15Z

Ktrueman: uploaded a new version of "File:DATA SHEET TMP800.pdf": updated with new product imagery

TMP800 data sheet

File:FINAL - DATA SHEET TMG5800.pdf

2010-09-10T15:55:03Z

Ktrueman: uploaded a new version of "File:FINAL - DATA SHEET TMG5800.pdf": updated with new product shots

TMG5800 data sheet - new

File:DATA SHEET TMG800.pdf

2010-09-10T15:53:05Z

Ktrueman: uploaded a new version of "File:DATA SHEET TMG800.pdf": updated

Data sheet for TMG800

File:DATA SHEET TMG3200.pdf

2010-09-10T15:52:19Z

Ktrueman: uploaded a new version of "File:DATA SHEET TMG3200.pdf": updated

Data sheet for the TMG3200

Licensing

2010-08-30T15:31:46Z

Ktrueman: added spacing to make easier to read...

=TMG3200=
License options for the TMG3200 family. Software upgrades consisting of installing a license key file on the system.

==Trunks==
=== 64 E1/T1/J1 TDM mezzanine ===
*E1/T1/J1: From 16 to 64 E1/T1/J1 in steps of 8 trunks, software upgradeable.
When upgrading over 32, installation of an additional patch panel is required.

=== 16 RJ48 E1/T1/J1 TDM mezzanine ===
* E1/T1/J1: From 4 to 16 with 4 trunks steps, software upgradeable.

=== STM1 TDM mezzanine ===
*T1/J1 : From 16 to 84 in steps of 8 trunks, software upgradeable.
*E1 : From 16 to 63 in steps of 8 trunks, software upgradeable.

==Signaling Protocol==
ISUP, SIP, R2, ISDN and SIGTRAN are all software upgradeable.

===SS7 MTP2 Links===
From 1 to 64 links per TMG unit. Up to 256 SS7 links per system.

===SIGTRAN M3UA/M2PA/M2UA association===
*M3UA : From 1 to 20 associations, in step of 1 association, software upgradeable.
*M2UA : From 1 to 64 associations, in step of 1 association, software upgradeable.
*M2PA : From 1 to 64 associations, in step of 1 association, software upgradeable.

==VoIP==
Hardware upgrades, field upgradable.
The TMG3200 have 4 VoIP mezzanine slots.
We have four different VoIP mezzanine capacity available:
* VoIP-1 equals 128 universal channels.
* VoIP-2 equals 256 universal channels.
* VoIP-3 equals 384 universal channels.
* VoIP-4 equals 512 universal channels.
Any mix of the different VoIP mezzanine is possible. We recommend the use of VoIP 4 to better protect the end-user investment (at least when using 32 E1 and more).

==IVR==
Hardware and software upgradeable, field upgradable.
We have four different IVR mezzanine capacity available:
* IVR-512: 512 IVR channels.
* IVR-1024: 1024 IVR channels, from 512 to 1024 channels, software upgradeable.
* IVR-1536: 1536 IVR channels, from 512 to 1536 channels, software upgradeable.
* IVR-2048: 2048 IVR channels, from 512 to 2048 channels, software upgradeable.

Tmonitor

2010-08-30T15:20:06Z

Ktrueman: fixed image size

Tmonitor is the trade name for TelcoBridges' family of products for [[Network monitoring|network monitoring]] (including [[GSM-R]]), [[Lawful intercept|lawful intercept]], and real-time [[Location-based services|location-based services]].

The following products are part of the Tmedia product line:

*[[TM1000]]: A high-performance, non-intrusive voice and data traffic monitoring solution with support for TDM (T1/E1) and GSM networks
*[[TM2000]]: A high-capacity version of the TM-1000 with IVR support for audio recording
*[[TM3000]]: A high-performance, non-intrusive voice and data traffic monitoring and recording solution for TDM, GSM and ATM (OC3/STM-1) networks

'''Comparison of the Tmonitor family of products'''

[[Image:Comparison-tmonitor-family-of-products.jpg|550px]]

== Other notes ==
*The TM1000 and the TM2000 both require the use the TelcoBridges-designed [[Isolation patch panel|isolation patch panel]] in order to connect non-intrusively to the networks to be monitored.
*The TM1000 and the TM2000 both require the use of a TelcoBridges-designed [[Monitoring patch panel|monitoring patch panel]] for higher capacity installations using T1/E1/J1 interfaces (up to 64 in all).

Tmonitor

2010-08-30T15:19:08Z

Ktrueman: link to GSM-R

Tmonitor is the trade name for TelcoBridges' family of products for [[Network monitoring|network monitoring]] (including [[GSM-R]]), [[Lawful intercept|lawful intercept]], and real-time [[Location-based services|location-based services]].

The following products are part of the Tmedia product line:

*[[TM1000]]: A high-performance, non-intrusive voice and data traffic monitoring solution with support for TDM (T1/E1) and GSM networks
*[[TM2000]]: A high-capacity version of the TM-1000 with IVR support for audio recording
*[[TM3000]]: A high-performance, non-intrusive voice and data traffic monitoring and recording solution for TDM, GSM and ATM (OC3/STM-1) networks

'''Comparison of the Tmonitor family of products'''

[[Image:Comparison-tmonitor-family-of-products.jpg|450px]]

== Other notes ==
*The TM1000 and the TM2000 both require the use the TelcoBridges-designed [[Isolation patch panel|isolation patch panel]] in order to connect non-intrusively to the networks to be monitored.
*The TM1000 and the TM2000 both require the use of a TelcoBridges-designed [[Monitoring patch panel|monitoring patch panel]] for higher capacity installations using T1/E1/J1 interfaces (up to 64 in all).

GSM-R

2010-08-30T15:17:15Z

Ktrueman: /* References */ more reference links

GSM-Railway (or GSM-R) refers to a variant of GSM used with railways. Wikipedia describes it as "A sub-system of European Rail Traffic Management System (ERTMS), it is used for communication between train and railway regulation control centers. The system is based on GSM and EIRENE - MORANE specifications which guarantee performance at speeds up to 500 km/h (310 mph), without any communication loss."

== TelcoBridges and GSM-R ==
TelcoBridges supports GSM-R with its [[Tmonitor]] line of network monitoring solutions. These have been adopted by various national railways in Europe.

== References ==
*[http://en.wikipedia.org/wiki/GSM-R Wikipedia article]
*[http://www.gsm-rail.com/ GSM-R Industry Group]

GSM-R

2010-08-30T15:16:19Z

Ktrueman: initial content

ISUP:Specification

2010-08-26T12:54:51Z

Ktrueman: spelling error

The ISUP protocol layer conforms to the following standards:
*Common Channel Signaling System N.7 (National), Singapore Telecom, 1988
*EN 300 356-1 v3.2.2, ISUP Version 3 for the International Interfaces Basic Services, 1998
*ETS 300 356 ISDN User Part (ISUP), Version 2 for the International Interface, 1995
*GR-317 -- CORE, Generic Requirement for Call Control Using ISDNUP. Issue 2, December 1997
*GR-394 -- CORE, Generic Requirement for ICI Using ISDNUP. Issue 2, December 1997. Revision 1, November 1998
*IS 7498 - Open Systems Interconnection - Basic Reference Model, ISO
*IS 7498 DAD 1 - Open Systems Interconnection - Basic Reference Model Addendum 1: Connectionless Data Transmission, ISO
*I.200 Guidance to the I.200 Series of Recommendations, ITU
*I.220 Common Dynamic Description of Basic Telecommunications Services, ITU
*I.221 Common Specific Characteristics of Services, ITU
*I.230 Definition of Bearer Service Categories, ITU
*I.231 Circuit Mode Bearer Service Categories, ITU
*I.232 Packet Mode Bearer Service Categories, ITU
*I.240 Definition of Teleservices, ITU
*I.250 Definition of Supplementary Services, ITU
*I.251 Number Identification Supplementary Services, ITU
*I.320 ISDN Protocol Reference Model, ITU
*Q.210 Principles of Telecommunication Services Supported by an ISDN and the Means to Describe Them, ITU
*Q.700 – Introduction to ITU Signaling System No. 7, 1993
*Q.730 - ISDN Supplementary Services, 1993
*Q.752 - Specifications of Signaling System No. 7 - Signaling System No. 7 Management, ITU
*Q.761 - Functional Description of the ISDN User Part of Signaling System No. 7, ITU, 1993 and 1997
*Q.762 - General Function of Messages and Signals, ITU, 1993 and 1997
*Q.763 - Formats and Codes, ITU, 1993 and 1997
*Q.763 - Formats and Codes, ITU, Addendum 1, 1998
*Q.764 - Signaling Procedures, ITU, 1993 and 1997
*Q.765 - Application Transport Mechanism, ISUP ASE Module, 1998
*Q.766 - Performance Objectives in the Integrated Services Digital Network Application, ITU
*Q.767 - Application of the ISUP of ITU SS7 for International ISDN Interconnections, ITU, 1991
*SS7 Integrated Services Digital Network User Part, ANSI T1.113.1-1995
*SS7 Integrated Services Digital Network User Part, ANSI T1.113.2-1995
*SS7 Integrated Services Digital Network User Part, ANSI T1.113.3-1995
*SS7 Integrated Services Digital Network User Part, ANSI T1.113.4-1995
*T1.113 - Signaling System Number 7 - Integrated Services Digital Network (ISDN) User Part, 1988
*T1.113 - Signaling System Number 7 - Integrated Services Digital Network (ISDN) User Part, 1992

TelcoBridges' implementation of ISUP supports the following switch variants:
*ANSI 88, T1.113 (1998)
*ANSI 92, T1.113 (1992)
*ANSI 95, T1.113.1 – T1.113.4 (1995)
*ITU 92, Q.761 - Q.764 (1993)
*ITU 97, Q.761 – Q.764 (1997), Q.763 Addendum 1 (05/1998), Q.765 ISUP ASE module (05/1998)
*Q.767, ITU 1991
*Singapore Telecom, Common Channel Signaling System N.7, Singapore Telecom, 1988
*Telcordia 97, GR-317, GR-394
*CHINA ISUP - Technical Specification for national No. 7 Signalling - IntegratedService DigitalNetwork User Part (ISUP) - YDN038.1-1999
*CHINA ISUP - Technical Specification for national No. 7 Signalling – Integrated Service Digital Network User Part (ISUP) (supplementary) – Supplementary Amendment YDN 038-1997
*ETSIv2 - ETS 300 356 (1995)
*ETSIv3 - EN 300 356-1 V3.2.2 (1998)
*UK ISUP - ND 1007:2006/04 TSG/SPEC/007
*Others - Please contact TelcoBridges [mailto:support@telcobridges.com technical support] for variants not listed here

ISUP:Specification

2010-08-26T12:54:25Z

Ktrueman: fixed spelling error and added e-mail link

Scriptable Routing Engine

2010-08-25T12:27:32Z

Ktrueman: clean up

[[Toolpack]] [[Version 2.3|v2.3]] introduces a scriptable routing engine that complements the existing approach to building [[Call routing|call routes]]. This new approach is based on the [http://www.ruby-lang.org/en/ Ruby] programming language, which offers a high-level, natural language-like approach to programming known as [http://en.wikipedia.org/wiki/Scripting_language scripting]. With Ruby, no code compilation is required to use routing scripts; in fact, you write scripts within your web browser. A high-level overview of how to write scripts is available upon request by contacting the TelcoBridges [mailto:support@telcobridges.com support team].

As part of the initial release, TelcoBridges is providing a number of ready-to-use scripts such as percentage routing, round-robin routing, least-cost routing, [[SIP trunking]], PRI reselling with over-subscription, etc., with additional scripts to be made available as we go forward. This new approach is meant to supplement the current approach to building routes. It should also make it possible for your service provider customers, once properly trained by you, to modify routing tables on their own.

== Prerequisites ==
There is no additional software required to use the scriptable routing engine. All necessary software is installed by the [[Toolpack]] installer application. While the Ruby language is natural language-like and easily approachable, some understanding of programming or Ruby is required in order to modify existing scripts. The Ruby scripts provided with Toolpack essentially consist of a series of mini scripts or sub-scripts (akin to classes in C++); therefore creating a script from scratch does require more experience. Please see the [http://www.ruby-lang.org/ Ruby site] for additional information on Ruby. That site features a helpful tutorial called “Ruby in 20 minutes”. There is also a section called “Ruby from Other Languages” which will help you understand Ruby if your frame of reference is C++, Java, or a scripting language such as Perl, PHP, or Python.

The Toolpack scriptable routing engine is based on the 1.8.x branch of Ruby.

== Script routing overview ==
The Scriptable Routing Engine is asked, for every incoming call leg, to take a routing decision which indicates how the outgoing call leg must be created.
The script will match one or multiple routes based on information from the incoming call leg
*calling number
*called number
*NAP
Each route determines NAP to use to make outgoing call, and may modify some of the call parameters:
*calling number
*called number
*nature of address
*numbering plan
*calling presentation
*etc.

Multiple routes can match a given incoming call, in which case routes can be sorted using various criteria:
*round robin
*least cost
*availability percent
*etc.

An outgoing call will be made based on the first matching route.
If this call fails with that route (maximum capacity reached, network or protocol error), another outgoing call attempt will be made using the next matching route.
Note: This route retry feature is available only in Toolpack version 2.5 and up.

== Steps ==
You access the Scriptable Routing Engine via the Toolpack [[Web Portal|web portal]]. After logging into the Toolpack web portal with your web browser, do the following steps to either modify or create a script and to then activate it.

*To modify a bundled script or to create a script from scratch, go to '''Gateway > Routing Scripts''' in the navigation menu on the left hand side of the web page.
**Select '''Create New Script''' to generate a default script. Here you will name your script. There is a checkbox called ‘Create default script files’ that is checked by default. If left checked, it will add the default scripts elements to your script.
**In the '''Editing NAPS''' section, you are initially presented with a list of NAPS configured on the system. Via the '''Create New NAP Column''' item, you have the ability to add custom fields for the purposes of adding weights or other variables that your scripts should take into account.
***The list of available [[NAP|NAPs]] is accessed via '''Global > NAPS'''.
**In addition to authoring scripts in the web browser, Ruby scripts can be authored in any application that offers text editing functionality. Importing a Ruby script into Toolpack is as simple as copying it from the source application document and paste it in to the editing window of the web browser.
*To assign and activate a script, go to '''Gateway > Configurations''' at the bottom of the navigation menu on the left hand side of the web page. If you are already satisfied with your gateway configuration, then click on '''Edit Configuration''' to edit your existing gateway configuration. If you want to create a new gateway configuration, click on '''Create New Configuration'''. A new window will open. Locate the '''Use Script''' sub-menu underneath the '''Use script''' section. ('''''See Figure 1'''''). You then click on the pop-up menu and choose the script you want.
**The list of available scripts is determined via the Routing Scripts menu item we saw in the previous bullet. They are:
***base_routing
***simple_routing
***simple_least_cost_routing
***least_cost_routing
***simple_routing_selector
***percentage_routing
***asr_routing
***noa_npi_remap_routing_example

'''Figure 1: Use Script sub-menu'''

[[Image:script-sub-menu.jpg]]

*Once you have selected a script, you need to create routes and network access points (NAPs).
**The '''Editing Routes''' section is where you create new routes. In addition to the standard route parameters, you can add new custom parameters as well. These parameters and their values can be accessed in the scripts.
**The '''Editing Naps''' section is where you manage NAPs. In addition to the standard NAP parameters, you can add new custom parameters as well. These parameters and their values can be accessed in the scripts.
***This is used to add NAP-specific parameters to the routing scripts.
***The list of NAPs is always populated with the NAPs of your current configurations.
*In order to activate a new script or a modified script, you must force a reload of the gateway’s configuration.
**If you have created a new gateway configuration, you need to change the current configuration of the gateway instance. This can be done by accessing the Instance menu, editing the gateway instance and changing its configuration to your new one. If you have modified an existing gateway configuration, you do need to change anything. In both cases however, you need to activate the configuration in '''Global > Systems'''. There you select the system to which you want to apply the configuration, clicking '''Edit''' besides its name. In the new page that opens, click '''Activate''' in the '''Active Configuration''' section.

== Tutorial guide ==
To learn how to use the Scriptable Routing Engine, click the following link to go to the [[routing_script_tutorial|Script Routing Tutorial]].

== Mini development guide ==
To learn about the parameters available in for each object go read the [[Routing_script_tutorial:Mini_Development_Guide|Script Routing Mini Development Guide]].

== Testing this feature ==
To test this feature, you will want to modify some of the provided scripts by changing variables such as route costing or NAP targets.

== Known limitations ==
The following are known limitations with the Scriptable Routing Engine as of version 2.5:
*Scripts (including script sub-components provided by TelcoBridges) are not updated when Toolpack is upgraded to new version (for example, to the release version of v2.3.0, v2.3.1, etc.). This means that if there is an update (bug fix) of the basic script, you will need to manually update any existing scripts.
*If you are using dynamic fields (using the '''Creating New Route Column '''or the '''Create New Nap Column''' option) with routing scripts and you plan to use NAP names, those NAP names need to be '''''all capital''''' letters (i.e.: not just the first letter needs to be capitalized.)

== References ==
*[[Routing script tutorial]]

Label Routing

2010-08-24T20:51:11Z

Ktrueman: /* Add the routeset definition NAP dynamic column */ clean-up

Routeset Routing is an algorithm that combines [[Digit Analyzer|Digit Analyzer]] and the concept of [[RouteSet|RouteSet]]. It is implemented as a [[Scriptable Routing Engine|RoutingScript]] in Toolpack Gateway.  This algorithm allows complex routing rules, as normally available with [[Scriptable Routing Engine|RoutingScript]], but on a very large number of destination numbers.

== Concept ==

The concept behind routeset routing is quite simple.

#A list of numbers (NPA-NXX) for a specific destination is assigned a [[RouteSet|RouteSet]] name. This list can be very large
##i.e., 514201,514202,514203, ... -> "Montreal, Qc"
#The list of routes for the destination is assigned the same [[RouteSet|RouteSet]] name. This list usually is limited to the number of [[NAP|network access points (NAP)]] in the system.
##i.e., Bell, Rogers, Videotron -> "Montreal, Qc"

Note: No matter how many destination numbers lead to a given destination, only a limited list of routes are selected. At this point, complex, yet efficient, routing rules can take place.

== Implementation ==

As previously mentioned, Routeset Routing is implemented as a [[Scriptable Routing Engine|RoutingScript]]. It was written as an optional filter, and can be used in any existing scripts. This filter is a before_filter, and reduces the amount of routes the routing script will work with.

== Provisioning ==

Provisioning of large amounts of Routeset Definition and Routeset Digitmap is accomplished by importing [http://en.wikipedia.org/wiki/Comma-separated_values CSV] files using the WebPortal.  Those files are being saved in the HA Database.

=== Routeset Definition ===

Each [[NAP]] in the system must be assigned a routesets_definition [http://en.wikipedia.org/wiki/Comma-separated_values CSV] file. A routesets_definition file gives the association between [[NAP|NAP]] and [[RouteSet|RouteSet]] names. The association between a [[NAP]] and a [[RouteSet|RouteSet]] name is in fact a route! ie: Rogers->"Montreal, Qc" Thus, for each [[RouteSet]] name<->[[NAP]] association, a dynamic route entry gets created.

The Routeset Definition file defines a list of [[RouteSet|RouteSet]] names, with optional attributes. 

*One mandatory column: routeset_name
*Supplementary columns are used to provide optional and custom attributes to dynamically created routes

routeset_name, cost, custom_1
"Montreal, Qc", "0.24", "custom_val"

In the above example, routes are created with custom attributes found in the second and third columns. Each custom attribute must be defined by adding a custom column in the gateway Route table.

 The [[NAP]] <-> Routeset Definition association is done by setting the [[NAP]] dynamic columns named 'routesets_definition'.  More than one [[NAP]] can point to the same 'routesets_definition' file. This file must be imported in the database using the File Db view in the Toolpack Web Portal. 

==== Add the routeset definition NAP dynamic column ====

*Click the Gateway->Configurations->Naps menu 
*Click the 'Create New Nap Column' link 
*Complete the form as follows: 
**Name = routesets_definition 
**Type attributes = dbfile 
**Default = 
*Click 'Create' to save

 

=== Routeset Digitmap ===

Each [[NAP]] in the system can be assigned a routesets_digitmap [http://en.wikipedia.org/wiki/Comma-separated_values CSV] file. It is usual that all NAP uses the same routesets_digitmap file. A routesets_digitmap file gives the association between numbers and [[RouteSet|RouteSet]] names.

*Three mandatory columns: route_set_name, called and calling

called,calling,routeset_name
403200, ,"Calgary, AB"
514201, ,"Montreal, Qc"
514202, ,"Montreal, Qc"
514203, ,"Montreal, Qc"

The [[NAP]] <-> Routeset Digitmap association is done by setting the [[NAP]] dynamic columns named 'routesets_digitmap'.   This file must be imported in the database using the File Db view in the Toolpack Web Portal.

==== Add the routesets digitmap NAP dynamic column ====

*Click the Gateway->Configurations->Naps menu 
*Click the 'Create New Nap Column' link 
*Fill the form as follow: 
*Name = routesets_digitmap 
*Type attributes = dbfile 
*Default = 
*Click create to save

 

== Dynamic Routes ==

When provisioning is complete, dynamic routes can be generated by going in the Routetsets menu item, under Gateway menu Item.

{| width="200" cellspacing="1" cellpadding="1" border="0"
|-
| valign="top" | [[Image:Routesets.png|left]]
| valign="top" | [[Image:Generate routes.png|left]]
|}

 

== Using routeset routing==

RouteSet routing can be implemented by following these 3 simple steps:

#Add a the following line on top of your script file:
#;<pre>require 'routesets_digit_analyzer'</pre>
#Include the module in your routing class:
#;<pre> class MyRoutingClass < BaseRouting
</pre>

#;;include RoutesetsDigitAnalyzer

#;;...

#;;end
#Add a before_filter with 'routesets_digit_analyzer' method:
#;<pre>before_filter :method => :routesets_digit_analyzer, :trie_order => :called</pre>

=== Complete Example ===
<pre> require 'base_routing'
require 'routesets_digit_analyzer'

class MyRoutingClass < BaseRouting
include RoutesetsDigitAnalyzer

before_filter :method => :routesets_digit_analyzer, :trie_order => :called

route_match :call_field_name => :called
route_match :call_field_name => :calling
route_match :call_field_name => :nap
route_match :method => :match_nap_availability
route_remap :call_field_name => :called, :route_field_name => :remapped_called
route_remap :call_field_name => :calling, :route_field_name => :remapped_calling
route_remap :call_field_name => :nap, :route_field_name => :remapped_nap
end
</pre>

Label Routing

2010-08-24T20:37:07Z

Ktrueman: some more clean-up

Routeset Routing is an algorithm that combines [[Digit Analyzer|Digit Analyzer]] and the concept of [[RouteSet|RouteSet]]. It is implemented as a [[Scriptable Routing Engine|RoutingScript]] in Toolpack Gateway.  This algorithm allows complex routing rules, as normally available with [[Scriptable Routing Engine|RoutingScript]], but on a very large number of destination numbers.

== Concept ==

The concept behind routeset routing is quite simple.

#A list of numbers (NPA-NXX) for a specific destination is assigned a [[RouteSet|RouteSet]] name. This list can be very large
##i.e., 514201,514202,514203, ... -> "Montreal, Qc"
#The list of routes for the destination is assigned the same [[RouteSet|RouteSet]] name. This list usually is limited to the number of [[NAP|network access points (NAP)]] in the system.
##i.e., Bell, Rogers, Videotron -> "Montreal, Qc"

Note: No matter how many destination numbers lead to a given destination, only a limited list of routes are selected. At this point, complex, yet efficient, routing rules can take place.

== Implementation ==

As previously mentioned, Routeset Routing is implemented as a [[Scriptable Routing Engine|RoutingScript]]. It was written as an optional filter, and can be used in any existing scripts. This filter is a before_filter, and reduces the amount of routes the routing script will work with.

== Provisioning ==

Provisioning of large amounts of Routeset Definition and Routeset Digitmap is accomplished by importing [http://en.wikipedia.org/wiki/Comma-separated_values CSV] files using the WebPortal.  Those files are being saved in the HA Database.

=== Routeset Definition ===

Each [[NAP]] in the system must be assigned a routesets_definition [http://en.wikipedia.org/wiki/Comma-separated_values CSV] file. A routesets_definition file gives the association between [[NAP|NAP]] and [[RouteSet|RouteSet]] names. The association between a [[NAP]] and a [[RouteSet|RouteSet]] name is in fact a route! ie: Rogers->"Montreal, Qc" Thus, for each [[RouteSet]] name<->[[NAP]] association, a dynamic route entry gets created.

The Routeset Definition file defines a list of [[RouteSet|RouteSet]] names, with optional attributes. 

*One mandatory column: routeset_name
*Supplementary columns are used to provide optional and custom attributes to dynamically created routes

routeset_name, cost, custom_1
"Montreal, Qc", "0.24", "custom_val"

In the above example, routes are created with custom attributes found in the second and third columns. Each custom attribute must be defined by adding a custom column in the gateway Route table.

 The [[NAP]] <-> Routeset Definition association is done by setting the [[NAP]] dynamic columns named 'routesets_definition'.  More than one [[NAP]] can point to the same 'routesets_definition' file. This file must be imported in the database using the File Db view in the Toolpack Web Portal. 

==== Add the routeset definition NAP dynamic column ====

*Click the Gateway->Configurations->Naps menu 
*Click the 'Create New Nap Column' link 
*Fill the form as follow: 
*Name = routesets_definition 
*Type attributes = dbfile 
*Default = 
*Click create to save

 

=== Routeset Digitmap ===

Each [[NAP]] in the system can be assigned a routesets_digitmap [http://en.wikipedia.org/wiki/Comma-separated_values CSV] file. It is usual that all NAP uses the same routesets_digitmap file. A routesets_digitmap file gives the association between numbers and [[RouteSet|RouteSet]] names.

*Three mandatory columns: route_set_name, called and calling

called,calling,routeset_name
403200, ,"Calgary, AB"
514201, ,"Montreal, Qc"
514202, ,"Montreal, Qc"
514203, ,"Montreal, Qc"

The [[NAP]] <-> Routeset Digitmap association is done by setting the [[NAP]] dynamic columns named 'routesets_digitmap'.   This file must be imported in the database using the File Db view in the Toolpack Web Portal.

==== Add the routesets digitmap NAP dynamic column ====

*Click the Gateway->Configurations->Naps menu 
*Click the 'Create New Nap Column' link 
*Fill the form as follow: 
*Name = routesets_digitmap 
*Type attributes = dbfile 
*Default = 
*Click create to save

 

== Dynamic Routes ==

When provisioning is complete, dynamic routes can be generated by going in the Routetsets menu item, under Gateway menu Item.

{| width="200" cellspacing="1" cellpadding="1" border="0"
|-
| valign="top" | [[Image:Routesets.png|left]]
| valign="top" | [[Image:Generate routes.png|left]]
|}

 

== Using routeset routing==

RouteSet routing can be implemented by following these 3 simple steps:

#Add a the following line on top of your script file:
#;<pre>require 'routesets_digit_analyzer'</pre>
#Include the module in your routing class:
#;<pre> class MyRoutingClass < BaseRouting
</pre>

#;;include RoutesetsDigitAnalyzer

#;;...

#;;end
#Add a before_filter with 'routesets_digit_analyzer' method:
#;<pre>before_filter :method => :routesets_digit_analyzer, :trie_order => :called</pre>

=== Complete Example ===
<pre> require 'base_routing'
require 'routesets_digit_analyzer'

class MyRoutingClass < BaseRouting
include RoutesetsDigitAnalyzer

before_filter :method => :routesets_digit_analyzer, :trie_order => :called

route_match :call_field_name => :called
route_match :call_field_name => :calling
route_match :call_field_name => :nap
route_match :method => :match_nap_availability
route_remap :call_field_name => :called, :route_field_name => :remapped_called
route_remap :call_field_name => :calling, :route_field_name => :remapped_calling
route_remap :call_field_name => :nap, :route_field_name => :remapped_nap
end
</pre>

Label Routing

2010-08-24T20:35:43Z

Ktrueman: /* Concept */ clean up

Routeset Routing is an algorithm that combines [[Digit Analyzer|Digit Analyzer]] and the concept of [[RouteSet|RouteSet]]. It is implemented as a [[Scriptable Routing Engine|RoutingScript]] in Toolpack Gateway.  This algorithm allows complex routing rules, as normally available with [[Scriptable Routing Engine|RoutingScript]], but on a very large number of destination numbers.

== Concept ==

The concept behind routeset routing is quite simple.

#A list of numbers (NPA-NXX) for a specific destination is assigned a [[RouteSet|RouteSet]] name. This list can be very large
##i.e., 514201,514202,514203, ... -> "Montreal, Qc"
#The list of routes for the destination is assigned the same [[RouteSet|RouteSet]] name. This list usually is limited to the number of [[NAP|network access points (NAP)]] in the system.
##i.e., Bell, Rogers, Videotron -> "Montreal, Qc"

Note: No matter how many destination numbers lead to a given destination, only a limited list of routes are selected. At this point, complex, yet efficient, routing rules can take place.

== Implementation ==

As previously mentioned, Routeset Routing is implemented as a [[Scriptable Routing Engine|RoutingScript]]. It was written as an optional filter, and can be used in any existing scripts. This filter is a before_filter, and reduces the amount of routes the routing script will work with.

== Provisioning ==

Provisioning of large amounts of Routeset Definition and Routeset Digitmap is accomplished by importing [http://en.wikipedia.org/wiki/Comma-separated_values CSV] files using the WebPortal.  Those files are being saved in the HA Database.

=== Routeset Definition ===

Each [[NAP]] in the system must be assigned a routesets_definition [http://en.wikipedia.org/wiki/Comma-separated_values CSV] file. A routesets_definition file gives the association between [[NAP|NAP]] and [[RouteSet|RouteSet]] names. The association between a [[NAP]] and a [[RouteSet|RouteSet]] name is in fact a route! ie: Rogers->"Montreal, Qc" Thus, for each [[RouteSet]] name<->[[NAP]] association, a dynamic route entry gets created.

 

The Routeset Definition file defines a list of [[RouteSet|RouteSet]] names, with optional attributes. 

*One mandatory column: routeset_name
*Supplementary columns are used to provide optional and custom attributes to dynamically created routes

routeset_name, cost, custom_1
"Montreal, Qc", "0.24", "custom_val"

In the above example, routes are created with custom attributes found in the second and third columns. Each custom attribute must be defined by adding a custom column in the gateway Route table.

 The [[NAP]] <-> Routeset Definition association is done by setting the [[NAP]] dynamic columns named 'routesets_definition'.  More than one [[NAP]] can point to the same 'routesets_definition' file. This file must be imported in the database using the File Db view in the Toolpack Web Portal. 

==== Add the routeset definition NAP dynamic column ====

*Click the Gateway->Configurations->Naps menu 
*Click the 'Create New Nap Column' link 
*Fill the form as follow: 
*Name = routesets_definition 
*Type attributes = dbfile 
*Default = 
*Click create to save

 

=== Routeset Digitmap ===

Each [[NAP]] in the system can be assigned a routesets_digitmap [http://en.wikipedia.org/wiki/Comma-separated_values CSV] file. It is usual that all NAP uses the same routesets_digitmap file. A routesets_digitmap file gives the association between numbers and [[RouteSet|RouteSet]] names.

*Three mandatory columns: route_set_name, called and calling

called,calling,routeset_name
403200, ,"Calgary, AB"
514201, ,"Montreal, Qc"
514202, ,"Montreal, Qc"
514203, ,"Montreal, Qc"

The [[NAP]] <-> Routeset Digitmap association is done by setting the [[NAP]] dynamic columns named 'routesets_digitmap'.   This file must be imported in the database using the File Db view in the Toolpack Web Portal.

==== Add the routesets digitmap NAP dynamic column ====

*Click the Gateway->Configurations->Naps menu 
*Click the 'Create New Nap Column' link 
*Fill the form as follow: 
*Name = routesets_digitmap 
*Type attributes = dbfile 
*Default = 
*Click create to save

 

== Dynamic Routes ==

When provisioning is complete, dynamic routes can be generated by going in the Routetsets menu item, under Gateway menu Item.

{| width="200" cellspacing="1" cellpadding="1" border="0"
|-
| valign="top" | [[Image:Routesets.png|left]]
| valign="top" | [[Image:Generate routes.png|left]]
|}

 

== Using ==

Using RouteSet Routing is done by following the 3 simple steps:

#Add a the following line on top of your script file:
#;<pre>require 'routesets_digit_analyzer'</pre>
#Include the module in your routing class:
#;<pre> class MyRoutingClass < BaseRouting
</pre>

#;;include RoutesetsDigitAnalyzer

#;;...

#;;end
#Add a before_filter with 'routesets_digit_analyzer' method:
#;<pre>before_filter :method => :routesets_digit_analyzer, :trie_order => :called</pre>

=== Complete Example ===
<pre> require 'base_routing'
require 'routesets_digit_analyzer'

class MyRoutingClass < BaseRouting
include RoutesetsDigitAnalyzer

before_filter :method => :routesets_digit_analyzer, :trie_order => :called

route_match :call_field_name => :called
route_match :call_field_name => :calling
route_match :call_field_name => :nap
route_match :method => :match_nap_availability
route_remap :call_field_name => :called, :route_field_name => :remapped_called
route_remap :call_field_name => :calling, :route_field_name => :remapped_calling
route_remap :call_field_name => :nap, :route_field_name => :remapped_nap
end
</pre>

RouteLabel

2010-08-24T20:30:42Z

Ktrueman: clean up

A RouteSet is a group of possible routes for a given destination. Routes are associated with a RouteSet by referring to its name. And each route in the RouteSet refers to a different [[NAP]] that can be used to reach the destination. Here is an example:

{| width="200" border="1" cellpadding="1" cellspacing="1"
|-
! scope="col" | Nap
! scope="col" | RouteSet
|-
| Bell
| Montreal, Qc
|-
| Videotron
| Montreal, Qc
|-
| Rogers
| Montreal, Qc
|}

In this routing table, we have three routes in a RouteSet named "Montreal, Qc". In order words, we have three routes for Montreal, Qc.

With the routing table in place, the association between a called number and a destination is done by the [[Digit Analyzer]].

Routing script tutorial:Mini Development Guide

2010-08-24T20:28:21Z

Ktrueman: /* Reason values */ clean up

== 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 takes 2 arguments, the call parameters (hash) and the route parameters (hash).

Apply route remapping rules
caf_call.accept out_call, route

=== Refuse ===

This function is used to refuse a call with a reason code argument parameters :
caf_call.refuse :reason => :temporary_failure

The supported values are described in the section "Reason values".

== Call parameters ==

The following call parameters are available in the call object:

* calling
* calling_noa
* calling_npi
* calling_display_type
* calling_display
* calling_presentation
* calling_screening
* called
* called_noa
* called_npi
* nap

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

=== Noa values ===
* <tt>unknown_number</tt>
* <tt>international_number</tt>
* <tt>national_number</tt>
* <tt>subscriber_number</tt>
* <tt>network_specific</tt>
* <tt>network_routing_national_format</tt>
* <tt>network_routing_international_format</tt>
* <tt>abbreviated_number</tt>
* <tt>subscriber_number_operator_requested</tt>
* <tt>national_number_operator_requested</tt>
* <tt>international_number_operator_requested</tt>
* <tt>no_number_present_operator_requested</tt>
* <tt>no_number_present_cut_through_call_to_carrier</tt>
* <tt>test_line_test_code</tt>
* <tt>non_unique_subscriber_number</tt>
* <tt>non_unique_national_number</tt>
* <tt>non_unique_international_number</tt>
* <tt>call_950_number</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:
* <tt>call_params[:called_noa] = 0x70</tt>
or
* <tt>call_params[:called_noa] = 112</tt>

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

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

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:
* <tt>call_params[:calling_display_type] = 0xB1</tt>
or
* <tt>call_params[:calling_display_type] = 177</tt>

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

=== Calling Presentation values ===
* <tt>unspecified</tt>
* <tt>not_available</tt>
* <tt>allowed</tt>
* <tt>restricted</tt>
* <tt>addr_restricted</tt>
* <tt>name_restricted</tt>

=== Calling Screening values ===
* <tt>unspecified</tt>
* <tt>no</tt>
* <tt>pass</tt>
* <tt>fail</tt>
* <tt>network_provided</tt>

== Route parameters ==

All route may have these parameters:

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

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

== Reason values ==

All CMC reason codes are available for use by the routing scripts. See the TBCMC_CALL_REASON_CODE enum in the tbcmc_call.h file.

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

/* isdn/ss7 reason code style */
/* Toolpack engine will convert reason code from sip to isdn/ss7 or isdn/ss7 to sip according to RFC3398 */
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
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_CONN_OPERATIONAL
TEMPORARY_FAILURE
SWITCHING_EQUIP_CONGESTION
ACCESS_INFO_DISCARDED
REQUESTED_CIRCUIT_NOT_AVAILABLE
PRECEDENCE_CALL_BLOCKED
RESOURCE_UNAVAILABLE
QOS_NOT_AVAILABLE
REQUESTED_FACILITY_NOT_SUBSCRIBED
OUTGOING_CALLS_BARRED
OUTGOING_CALLS_BARRED_WITHIN_CUG
INCOMING_CALLS_BARRED
INCOMING_CALLS_BARRED_WITHIN_CUG
BEARER_CAP_NOT_AUTHORIZED
BEARER_CAP_NOT_AVAILABLE
INCONSISTENCY_ACCESS_INFO
SERVICE_NOT_AVAILABLE
BEARER_CAP_NOT_IMPLEMENTED
CHANNEL_TYPE_NOT_IMPLEMENTED
REQUESTED_FACILITY_NOT_IMPLEMENTED
ONLY_RESTRICTED_DIGITAL_INFO
SERVICE_NOT_IMPLEMENTED
INVALID_CALL_REFERENCE
CHANNEL_DOES_NOT_EXIST
CALL_IDENTITY_DOES_NOT_EXIST
CALL_IDENTITY_IN_USE
NO_CALL_SUSPENDED
CALL_HAS_BEEN_CLEARED
USER_NOT_MEMBER_OF_CUG
INCOMPATIBLE_DESTINATION
NON_EXISTANT_CUG
INVALID_TRANSIT_NETWORK
INVALID_MESSAGE_UNSPECIFIED
MANDATORY_IE_MISSING
MESSAGE_TYPE_NON_EXISTENT
MESSAGE_NOT_COMPATIBLE_WITH_CALL_STATE
IE_NON_EXISTENT
INVALID_IE_CONTENT
MSG_NOT_COMPATIBLE_WITH_CALL_STATE
RECOVERY_ON_TIMER_EXPIRY
PARAMETER_NON_EXISTENT_PASSED_ON
MESSAGE_WITH_NON_RECOGNIZED_PARAMETERS_DISCARDED
PROTOCOL_ERROR
INTERWORKING_UNSPECIFIED

/* Toolpack specific errors */
NORMAL
RESOURCE_ERROR
TIMEOUT
NO_ROUTE
CALL_COLLISION
SYNC_DROP
SIGNALING_ERROR
LOCALLY_REJECTED
INTERFACE_NOT_AVAILABLE
RESET_IN_PROGRESS
ADAPTER_REJECT
MISSING_INVALID_IE
INCOMING_ONLY
SYSTEM_CONFIGURATION_CHANGED
RESOURCE_NO_MORE_AVAILABLE
INCOMPATIBLE_MEDIA
RES_ALLOC_FAILED
DATA_PATH_NOT_AVAILABLE

 

== Nap status ==

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

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

#define NAP_STATS_FIELDS \
/* Field, szName, szDescription, szOptions */ \
( SIGNALING_TYPE, "signaling_type", "Signaling type.", "" ) \
( INCOMING_CALL_CNT, "inst_incoming_call_cnt", "Instantaneous Count of incoming calls.", "" ) \
( OUTGOING_CALL_CNT, "inst_outgoing_call_cnt", "Instantaneous Count of outgoing calls.", "" ) \
( AVAILABLE_CNT, "available_cnt", "Number of available circuits or channels.", "" ) \
( UNAVAILABLE_CNT, "unavailable_cnt", "Number of unavailable circuits or channels.", "" ) \
( AVAILABILITY_PCT, "availability_percent", "Percentage of available circuits or channels.", "" ) \
( USAGE_PCT, "usage_percent", "Percentage of used circuits or channels.", "" ) \
( TOTAL_INCOMING_CALL_CNT, "total_incoming_call_cnt", "Total Count of incoming calls.", "" ) \
( ASR_STRUCT, "asr_statistics_struct", "Detailed Answer-Seizure Rate Statistics.", "" ) \
( GLOBAL_ASR_PCT, "global_asr_percent", "Global calculated ASR percentage.", "" ) \
( TOTAL_OUTGOING_CALL_CNT, "total_outgoing_call_cnt", "Total Count of outgoing calls.", "" ) \
( LAST_24H_ASR_PCT, "last_24h_asr_percent", "Last 24 hours calculated ASR percentage.", "" ) \
( LAST_24H_OUTGOING_CALL_CNT, "last_24h_outgoing_call_cnt", "Last 24 hours outgoing calls.", "" ) \
( HOUR_ASR_PCT, "current_hour_asr_percent", "Current hour calculated ASR percentage.", "" ) \
( HOUR_OUTGOING_CALL_CNT, "current_hour_outgoing_call_cnt", "Current hour outgoing calls.", "" ) \
( LAST_HOUR_ASR_PCT, "last_hour_asr_percent", "Last hour calculated ASR percentage.", "" ) \
( LAST_HOUR_OUTGOING_CALL_CNT, "last_hour_outgoing_call_cnt", "Last hour outgoing calls.", "" ) \
( AVAILABILITY_DETECTION_STRUCT, "availability_detection_struct", "Detailed availibility detection Statistics", "" ) \
( POLL_REMOTE_PROXY, "poll_remote_proxy", "Remote proxy polling enabled", "" ) \
( IS_AVAILABLE, "is_available", "Remote proxy actually available or not", "" ) \
( TIME_SINCE_POLLING, "time_since_polling", "Time since the last availibility polling", "" ) \
( TIME_AVAILABLE_SECONDS, "time_available_seconds", "Number of seconds since the NAP is available", "x" ) \
( TIME_UNAVAILABLE_SECONDS, "time_unavailable_seconds", "Number of seconds since the NAP is unavailable", "x" ) \
( REGISTRATION_STRUCT, "registration_struct", "Detailed registration Statistics", "" ) \
( REGISTER_TO_PROXY, "register_to_proxy", "Register to proxy enabled", "" ) \
( IS_REGISTERED, "registered", "Actually registered or not", "" ) \
( TIME_SINCE_REFRESH, "time_since_refresh", "Time since the last refresh", "" ) \
( TIME_REGISTERED_SECONDS, "time_registered_seconds", "Number of seconds since the NAP is registered", "x" ) \
( TIME_NOT_REGISTERED_SECONDS, "time_not_registered_seconds", "Number of seconds since the NAP is not registered", "x" ) \
/*!< Nap Status Fields */

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

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

asr_statistics_struct_global_asr_percent

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

== Test parameters ==

=== @call_params ===

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

 

=== @nap_list ===

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

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

----

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

Routing script tutorial:Mini Development Guide

2010-08-24T20:27:25Z

Ktrueman: /* Route parameters */ fixed spelling

== 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 takes 2 arguments, the call parameters (hash) and the route parameters (hash).

Apply route remapping rules
caf_call.accept out_call, route

=== Refuse ===

This function is used to refuse a call with a reason code argument parameters :
caf_call.refuse :reason => :temporary_failure

The supported values are described in the section "Reason values".

== Call parameters ==

The following call parameters are available in the call object:

* calling
* calling_noa
* calling_npi
* calling_display_type
* calling_display
* calling_presentation
* calling_screening
* called
* called_noa
* called_npi
* nap

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

=== Noa values ===
* <tt>unknown_number</tt>
* <tt>international_number</tt>
* <tt>national_number</tt>
* <tt>subscriber_number</tt>
* <tt>network_specific</tt>
* <tt>network_routing_national_format</tt>
* <tt>network_routing_international_format</tt>
* <tt>abbreviated_number</tt>
* <tt>subscriber_number_operator_requested</tt>
* <tt>national_number_operator_requested</tt>
* <tt>international_number_operator_requested</tt>
* <tt>no_number_present_operator_requested</tt>
* <tt>no_number_present_cut_through_call_to_carrier</tt>
* <tt>test_line_test_code</tt>
* <tt>non_unique_subscriber_number</tt>
* <tt>non_unique_national_number</tt>
* <tt>non_unique_international_number</tt>
* <tt>call_950_number</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:
* <tt>call_params[:called_noa] = 0x70</tt>
or
* <tt>call_params[:called_noa] = 112</tt>

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

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

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:
* <tt>call_params[:calling_display_type] = 0xB1</tt>
or
* <tt>call_params[:calling_display_type] = 177</tt>

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

=== Calling Presentation values ===
* <tt>unspecified</tt>
* <tt>not_available</tt>
* <tt>allowed</tt>
* <tt>restricted</tt>
* <tt>addr_restricted</tt>
* <tt>name_restricted</tt>

=== Calling Screening values ===
* <tt>unspecified</tt>
* <tt>no</tt>
* <tt>pass</tt>
* <tt>fail</tt>
* <tt>network_provided</tt>

== Route parameters ==

All route may have these parameters:

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

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

== Reason values ==

All the CMC reason code are provide for use by the routing scripts . See the TBCMC_CALL_REASON_CODE enum in the tbcmc_call.h file.

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

/* isdn/ss7 reason code style */
/* Toolpack engine will convert reason code from sip to isdn/ss7 or isdn/ss7 to sip according to RFC3398 */
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
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_CONN_OPERATIONAL
TEMPORARY_FAILURE
SWITCHING_EQUIP_CONGESTION
ACCESS_INFO_DISCARDED
REQUESTED_CIRCUIT_NOT_AVAILABLE
PRECEDENCE_CALL_BLOCKED
RESOURCE_UNAVAILABLE
QOS_NOT_AVAILABLE
REQUESTED_FACILITY_NOT_SUBSCRIBED
OUTGOING_CALLS_BARRED
OUTGOING_CALLS_BARRED_WITHIN_CUG
INCOMING_CALLS_BARRED
INCOMING_CALLS_BARRED_WITHIN_CUG
BEARER_CAP_NOT_AUTHORIZED
BEARER_CAP_NOT_AVAILABLE
INCONSISTENCY_ACCESS_INFO
SERVICE_NOT_AVAILABLE
BEARER_CAP_NOT_IMPLEMENTED
CHANNEL_TYPE_NOT_IMPLEMENTED
REQUESTED_FACILITY_NOT_IMPLEMENTED
ONLY_RESTRICTED_DIGITAL_INFO
SERVICE_NOT_IMPLEMENTED
INVALID_CALL_REFERENCE
CHANNEL_DOES_NOT_EXIST
CALL_IDENTITY_DOES_NOT_EXIST
CALL_IDENTITY_IN_USE
NO_CALL_SUSPENDED
CALL_HAS_BEEN_CLEARED
USER_NOT_MEMBER_OF_CUG
INCOMPATIBLE_DESTINATION
NON_EXISTANT_CUG
INVALID_TRANSIT_NETWORK
INVALID_MESSAGE_UNSPECIFIED
MANDATORY_IE_MISSING
MESSAGE_TYPE_NON_EXISTENT
MESSAGE_NOT_COMPATIBLE_WITH_CALL_STATE
IE_NON_EXISTENT
INVALID_IE_CONTENT
MSG_NOT_COMPATIBLE_WITH_CALL_STATE
RECOVERY_ON_TIMER_EXPIRY
PARAMETER_NON_EXISTENT_PASSED_ON
MESSAGE_WITH_NON_RECOGNIZED_PARAMETERS_DISCARDED
PROTOCOL_ERROR
INTERWORKING_UNSPECIFIED

/* Toolpack specific errors */
NORMAL
RESOURCE_ERROR
TIMEOUT
NO_ROUTE
CALL_COLLISION
SYNC_DROP
SIGNALING_ERROR
LOCALLY_REJECTED
INTERFACE_NOT_AVAILABLE
RESET_IN_PROGRESS
ADAPTER_REJECT
MISSING_INVALID_IE
INCOMING_ONLY
SYSTEM_CONFIGURATION_CHANGED
RESOURCE_NO_MORE_AVAILABLE
INCOMPATIBLE_MEDIA
RES_ALLOC_FAILED
DATA_PATH_NOT_AVAILABLE

 

== Nap status ==

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

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

#define NAP_STATS_FIELDS \
/* Field, szName, szDescription, szOptions */ \
( SIGNALING_TYPE, "signaling_type", "Signaling type.", "" ) \
( INCOMING_CALL_CNT, "inst_incoming_call_cnt", "Instantaneous Count of incoming calls.", "" ) \
( OUTGOING_CALL_CNT, "inst_outgoing_call_cnt", "Instantaneous Count of outgoing calls.", "" ) \
( AVAILABLE_CNT, "available_cnt", "Number of available circuits or channels.", "" ) \
( UNAVAILABLE_CNT, "unavailable_cnt", "Number of unavailable circuits or channels.", "" ) \
( AVAILABILITY_PCT, "availability_percent", "Percentage of available circuits or channels.", "" ) \
( USAGE_PCT, "usage_percent", "Percentage of used circuits or channels.", "" ) \
( TOTAL_INCOMING_CALL_CNT, "total_incoming_call_cnt", "Total Count of incoming calls.", "" ) \
( ASR_STRUCT, "asr_statistics_struct", "Detailed Answer-Seizure Rate Statistics.", "" ) \
( GLOBAL_ASR_PCT, "global_asr_percent", "Global calculated ASR percentage.", "" ) \
( TOTAL_OUTGOING_CALL_CNT, "total_outgoing_call_cnt", "Total Count of outgoing calls.", "" ) \
( LAST_24H_ASR_PCT, "last_24h_asr_percent", "Last 24 hours calculated ASR percentage.", "" ) \
( LAST_24H_OUTGOING_CALL_CNT, "last_24h_outgoing_call_cnt", "Last 24 hours outgoing calls.", "" ) \
( HOUR_ASR_PCT, "current_hour_asr_percent", "Current hour calculated ASR percentage.", "" ) \
( HOUR_OUTGOING_CALL_CNT, "current_hour_outgoing_call_cnt", "Current hour outgoing calls.", "" ) \
( LAST_HOUR_ASR_PCT, "last_hour_asr_percent", "Last hour calculated ASR percentage.", "" ) \
( LAST_HOUR_OUTGOING_CALL_CNT, "last_hour_outgoing_call_cnt", "Last hour outgoing calls.", "" ) \
( AVAILABILITY_DETECTION_STRUCT, "availability_detection_struct", "Detailed availibility detection Statistics", "" ) \
( POLL_REMOTE_PROXY, "poll_remote_proxy", "Remote proxy polling enabled", "" ) \
( IS_AVAILABLE, "is_available", "Remote proxy actually available or not", "" ) \
( TIME_SINCE_POLLING, "time_since_polling", "Time since the last availibility polling", "" ) \
( TIME_AVAILABLE_SECONDS, "time_available_seconds", "Number of seconds since the NAP is available", "x" ) \
( TIME_UNAVAILABLE_SECONDS, "time_unavailable_seconds", "Number of seconds since the NAP is unavailable", "x" ) \
( REGISTRATION_STRUCT, "registration_struct", "Detailed registration Statistics", "" ) \
( REGISTER_TO_PROXY, "register_to_proxy", "Register to proxy enabled", "" ) \
( IS_REGISTERED, "registered", "Actually registered or not", "" ) \
( TIME_SINCE_REFRESH, "time_since_refresh", "Time since the last refresh", "" ) \
( TIME_REGISTERED_SECONDS, "time_registered_seconds", "Number of seconds since the NAP is registered", "x" ) \
( TIME_NOT_REGISTERED_SECONDS, "time_not_registered_seconds", "Number of seconds since the NAP is not registered", "x" ) \
/*!< Nap Status Fields */

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

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

asr_statistics_struct_global_asr_percent

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

== Test parameters ==

=== @call_params ===

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

 

=== @nap_list ===

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

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

----

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

Talk:Call routing

2010-08-24T20:13:59Z

Ktrueman: mentioned product brief

Not sure what to do with the following items:
*Route selection
*Using Network Access Point (NAP)
*Using ANI with regular expressions (libpcre)
*Using DNIS with regular expressions
*Post-routing modification to ANI and DNIS with regular expressions
*Enhance routing using scripts
*Programmable
*Pre-design script for %, sequential and ASR
[[User:Ktrueman|Kenneth Trueman]] 14:40, 17 July 2009 (EDT)

We should look at combining these two pages together
http://docs.telcobridges.com/mediawiki/index.php/CallRouting
[[User:Ktrueman|Kenneth Trueman]] 20:10, 24 August 2010 (UTC)

We also need to update to take into account new routing functionality introduced with v2.5 of Toolpack. I will provide some content from my upcoming product brief... [[User:Ktrueman|Kenneth Trueman]] 20:13, 24 August 2010 (UTC)

Talk:Call routing

2010-08-24T20:10:12Z

Ktrueman: combining call routing content

CallRouting

2010-08-24T20:07:34Z

Ktrueman: added category

Routing is important for gateway applications in general. The routing block is in charge of giving routes for incoming
call attributes and/or depending on external factors like the time of the day or congestion. The routes are responsible
of providing call attributes for incoming and outgoing legs; they contain common routing information like the called
number, the calling number and the network access point.

The media profile may be changed by a route so that a route can also change the media of a leg. This can be used
to force specific codecs to be used for certain routes or to specify the transcoding type. The transcoding type is only
important for VOIP calls since it indicates when the adapter should include itself in the media path. Transcoding is
limited limited to the following type:

<ul>
<li>Forced: always transcode.
<li>Only as a fallback: to try to save hardware resources.
<li>Disabled: if the the hardware resources are not available.
</ul>

== Usage ==

The default routing implementation routes on only three optional criteria (there must be at least one per rule):
<ul>
<li>Called number.
<li>Calling number.
<li>Incoming network access point.
</ul>

When it finds a route matching the call attribute’s criteria, it applies remapping on the desired fields and creates a
route that is returned to the application. Remapping can be done on:
<ul>
<li>Called number
<li>Calling number
<li>Destination network access point
</ul>

In the default route implementation, the media profile is also changed depending on the transcoding type. This is done
by the route in GetIncomingAttributes and GetOutgoingAttributes which will instantiate the attribute based on the
transcoding type. This works fine for this initial profile but the leg’s profile may be changed during the call’s life and
that change must be handled depending on the transcoding type. The attribute class is the one that is aware of the
transcoding type because it is stored in the leg, and will be queried (through SetMediaProfile) when a profile change
occurs.

<code>
{
switch( mRoutingEntry.TranscodingType )
{
case TBCAF_ROUTING_TRANSCODING_TYPE_NORMAL:
{
pAttributes = tbnew CTBCMC_CALL_LEG_ATTRIBUTE;
}break;
case TBCAF_ROUTING_TRANSCODING_TYPE_FORCED:
{
pAttributes = tbnew CTBCMC_CALL_LEG_FT_ATTRIBUTE;
}break;
case TBCAF_ROUTING_TRANSCODING_TYPE_NEVER:
{
pAttributes = tbnew CTBCMC_CALL_LEG_NT_ATTRIBUTE;
}break;

default:
{
TBX_EXIT_ERROR( TBX_RESULT_INVALID_STATE, 0, "Invalid transcoding type." );
}
}
}</code>

== Caveats ==
For now only forced transcoding is supported by the CMC server but this might change in the future. Video support in CMC might force the issue because video transcoding is not cheap.

[[category: Needs revising]]

Main Page

2010-08-20T14:37:36Z

Ktrueman: /* Using TBwiki */ fixed spelling

__NoToC__'''Welcome to TBwiki, the [http://www.telcobridges.com TelcoBridges] wiki.'''

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

!width="210" style="background:#efefef;" |SOFTWARE
!width="210" style="background:#efefef;" |HARDWARE
!width="210" style="background:#efefef;" |USE CASES
!width="210" style="background:#efefef;" |OTHER
|-
| valign="top" | '''[[Toolpack]]'''

*[[Web Portal]]
*[[Toolpack API]]
*[[Application components]]
*[[Supported operating systems]]
*[[Toolpack version history|Version history]]
*[[Toolpack: Architecture, philosophy and evolution|Architecture, philosophy and evolution]]

'''Using Toolpack'''
*[[Installing Toolpack]]
*[[Upgrading Toolpack]]
*[[Troubleshooting Toolpack]]
*[[Develop Using Toolpack]]
*[[Best practices]]

----

'''Other'''
*TB Media Gateway
*[[TB StreamServer]]

| valign="top" | '''[[Tmedia]] VOIP gateways'''
*[[TMG800]] series
*[[TMG3200]] series
*[[TMG5800]] series
*[[TMG7800]] series
*[[TMG8300|TMG8300: H.323 Signaling Converter]]

'''[[Tdev]] development platforms'''
*[[TMP800]] series
*[[TMP5900]] series
*[[TMP6400]] series
*[[TMP7900]] series
*[[TMP7950]]
*[[TMS1600]]

'''[[Tmonitor]] network monitoring'''
*[[TM1000]] series
*[[TM2000]] series
*[[TM3000]] series

'''[http://docs.telcobridges.com/mediawiki/index.php/Category:Hardware All hardware]'''

| valign="top" | '''Tmedia and Tdev'''
*Background music injection
*[[Call routing]]
*[[Conferencing]]
*[[Fax over IP]]
*[[Prepaid & postpaid calling]]
*[[Ringback tones]]
*Signaling gateway
*[[Tandem switching]]
*[[Transcoding]]
*[[Trunking]]
*[[Unified communications]]
*[[Video]]
*Voicemail

'''Tmonitor'''
*[[Network monitoring]]
*[[Lawful intercept]]
*[[Location-based services|Location-based services (LBS)]]

| valign="top" | '''Technical support'''
*[[Support:Contacting TelcoBridges technical support|Contacting support]]
*[http://docs.telcobridges.com/mediawiki/index.php/Category:FAQ Frequently Asked Questions]
*[[Troubleshooting]]
*[http://forums.telcobridges.com Support forums]
*[[Support:How To Submit A Problem|Submitting a problem]]

'''Repairs and replacements'''
*[[RMA process]]
*[[Warranty]]

'''Interoperability'''
*[[Interoperability:Deployments|Deployments]]
*[[Interoperability:Certifications|Certifications]]
*[[Partners]]
*Best interoperability practices

'''Other'''
*[[End-of-Life (EOL) policy]]
*[[Regulatory compliance]]

|}

== Using TBwiki ==
*Please note that TBwiki is, by its nature, a 'living document' thus navigation and naming conventions are apt to evolve over time
*While we have provided a table above that categorizes content, you may want to consult the [http://docs.telcobridges.com/mediawiki/index.php/Category:Glossary glossary] which is where to find information on specific industry standards supported (or not) by TelcoBridges. A link to the glossary is available on all pages in the navigation bar on the left-hand side of the page
*The 'Search' box on the left hand-side of this page should enable you to efficiently locate content at all times. Clicking 'Go' will attempt to locate an article of the same name as your search term or one containing that term in the article name; clicking 'Search' will take a broader approach, looking for the presence of your term in all article contents

== Contributing to TBwiki ==
*TelcoBridges employees, partners, and customers, are invited to '''[[TBwiki:Getting started|contribute]]''' so as to expand and improve the content of TBwiki. There is a list of [http://docs.telcobridges.com/mediawiki/index.php/Special:Wantedpages wanted pages], which refers to empty pages requiring content, as well as a page for [[Suggested articles|suggesting new articles]]. Finally, there is a list of [http://docs.telcobridges.com/mediawiki/index.php/Category:Needs_revising articles requiring revision].
*Please note that anonymous editing has been disabled on this site. You must therefore [http://docs.telcobridges.com/mediawiki/index.php/Special:RequestAccount register] before you can edit any content. A 'log in / register' link can be found at the top of each page.

== Disclaimer ==
*The information on the TBwiki web site is subject to change without notice. No part of this web site may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of TelcoBridges Inc. TelcoBridges may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this web site or associated documents. The furnishing of access to this web site does not give you license to these patents, trademarks, copyrights, or other intellectual property except as expressly provided in any written license agreement from TelcoBridges.
*The information provided in this web site is intended as a guide only. No responsibility is implied and the terms of your license agreement with TelcoBridges will continue to claim precedence. For the latest detailed engineering specifications, please contact your TelcoBridges Application Engineer. TelcoBridges is committed to continually improving product designs, as a result, product specifications may be subject to change without notification.

== Copyright ==
*This web site and its content, as well as any external links to content on TelcoBridges servers, is ©2003-2010 TelcoBridges Inc. All rights reserved.

Routing script tutorial:Mini Development Guide

2010-08-20T14:23:22Z

Ktrueman: /* @nap_list */ clean up

== 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 takes 2 arguments, the call parameters (hash) and the route parameters (hash).

Apply route remapping rules
caf_call.accept out_call, route

=== Refuse ===

This function is used to refuse a call with a reason code argument parameters :
caf_call.refuse :reason => :temporary_failure

The supported values are described in the section "Reason values".

== Call parameters ==

The following call parameters are available in the call object:

* calling
* calling_noa
* calling_npi
* calling_display_type
* calling_display
* calling_presentation
* calling_screening
* called
* called_noa
* called_npi
* nap

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

=== Noa values ===
* <tt>unknown_number</tt>
* <tt>international_number</tt>
* <tt>national_number</tt>
* <tt>subscriber_number</tt>
* <tt>network_specific</tt>
* <tt>network_routing_national_format</tt>
* <tt>network_routing_international_format</tt>
* <tt>abbreviated_number</tt>
* <tt>subscriber_number_operator_requested</tt>
* <tt>national_number_operator_requested</tt>
* <tt>international_number_operator_requested</tt>
* <tt>no_number_present_operator_requested</tt>
* <tt>no_number_present_cut_through_call_to_carrier</tt>
* <tt>test_line_test_code</tt>
* <tt>non_unique_subscriber_number</tt>
* <tt>non_unique_national_number</tt>
* <tt>non_unique_international_number</tt>
* <tt>call_950_number</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:
* <tt>call_params[:called_noa] = 0x70</tt>
or
* <tt>call_params[:called_noa] = 112</tt>

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

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

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:
* <tt>call_params[:calling_display_type] = 0xB1</tt>
or
* <tt>call_params[:calling_display_type] = 177</tt>

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

=== Calling Presentation values ===
* <tt>unspecified</tt>
* <tt>not_available</tt>
* <tt>allowed</tt>
* <tt>restricted</tt>
* <tt>addr_restricted</tt>
* <tt>name_restricted</tt>

=== Calling Screening values ===
* <tt>unspecified</tt>
* <tt>no</tt>
* <tt>pass</tt>
* <tt>fail</tt>
* <tt>network_provided</tt>

== Route parameters ==

All route may have these parameters:

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

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

== Reason values ==

All the CMC reason code are provide for use by the routing scripts . See the TBCMC_CALL_REASON_CODE enum in the tbcmc_call.h file.

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

/* isdn/ss7 reason code style */
/* Toolpack engine will convert reason code from sip to isdn/ss7 or isdn/ss7 to sip according to RFC3398 */
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
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_CONN_OPERATIONAL
TEMPORARY_FAILURE
SWITCHING_EQUIP_CONGESTION
ACCESS_INFO_DISCARDED
REQUESTED_CIRCUIT_NOT_AVAILABLE
PRECEDENCE_CALL_BLOCKED
RESOURCE_UNAVAILABLE
QOS_NOT_AVAILABLE
REQUESTED_FACILITY_NOT_SUBSCRIBED
OUTGOING_CALLS_BARRED
OUTGOING_CALLS_BARRED_WITHIN_CUG
INCOMING_CALLS_BARRED
INCOMING_CALLS_BARRED_WITHIN_CUG
BEARER_CAP_NOT_AUTHORIZED
BEARER_CAP_NOT_AVAILABLE
INCONSISTENCY_ACCESS_INFO
SERVICE_NOT_AVAILABLE
BEARER_CAP_NOT_IMPLEMENTED
CHANNEL_TYPE_NOT_IMPLEMENTED
REQUESTED_FACILITY_NOT_IMPLEMENTED
ONLY_RESTRICTED_DIGITAL_INFO
SERVICE_NOT_IMPLEMENTED
INVALID_CALL_REFERENCE
CHANNEL_DOES_NOT_EXIST
CALL_IDENTITY_DOES_NOT_EXIST
CALL_IDENTITY_IN_USE
NO_CALL_SUSPENDED
CALL_HAS_BEEN_CLEARED
USER_NOT_MEMBER_OF_CUG
INCOMPATIBLE_DESTINATION
NON_EXISTANT_CUG
INVALID_TRANSIT_NETWORK
INVALID_MESSAGE_UNSPECIFIED
MANDATORY_IE_MISSING
MESSAGE_TYPE_NON_EXISTENT
MESSAGE_NOT_COMPATIBLE_WITH_CALL_STATE
IE_NON_EXISTENT
INVALID_IE_CONTENT
MSG_NOT_COMPATIBLE_WITH_CALL_STATE
RECOVERY_ON_TIMER_EXPIRY
PARAMETER_NON_EXISTENT_PASSED_ON
MESSAGE_WITH_NON_RECOGNIZED_PARAMETERS_DISCARDED
PROTOCOL_ERROR
INTERWORKING_UNSPECIFIED

/* Toolpack specific errors */
NORMAL
RESOURCE_ERROR
TIMEOUT
NO_ROUTE
CALL_COLLISION
SYNC_DROP
SIGNALING_ERROR
LOCALLY_REJECTED
INTERFACE_NOT_AVAILABLE
RESET_IN_PROGRESS
ADAPTER_REJECT
MISSING_INVALID_IE
INCOMING_ONLY
SYSTEM_CONFIGURATION_CHANGED
RESOURCE_NO_MORE_AVAILABLE
INCOMPATIBLE_MEDIA
RES_ALLOC_FAILED
DATA_PATH_NOT_AVAILABLE

 

== Nap status ==

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

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

#define NAP_STATS_FIELDS \
/* Field, szName, szDescription, szOptions */ \
( SIGNALING_TYPE, "signaling_type", "Signaling type.", "" ) \
( INCOMING_CALL_CNT, "inst_incoming_call_cnt", "Instantaneous Count of incoming calls.", "" ) \
( OUTGOING_CALL_CNT, "inst_outgoing_call_cnt", "Instantaneous Count of outgoing calls.", "" ) \
( AVAILABLE_CNT, "available_cnt", "Number of available circuits or channels.", "" ) \
( UNAVAILABLE_CNT, "unavailable_cnt", "Number of unavailable circuits or channels.", "" ) \
( AVAILABILITY_PCT, "availability_percent", "Percentage of available circuits or channels.", "" ) \
( USAGE_PCT, "usage_percent", "Percentage of used circuits or channels.", "" ) \
( TOTAL_INCOMING_CALL_CNT, "total_incoming_call_cnt", "Total Count of incoming calls.", "" ) \
( ASR_STRUCT, "asr_statistics_struct", "Detailed Answer-Seizure Rate Statistics.", "" ) \
( GLOBAL_ASR_PCT, "global_asr_percent", "Global calculated ASR percentage.", "" ) \
( TOTAL_OUTGOING_CALL_CNT, "total_outgoing_call_cnt", "Total Count of outgoing calls.", "" ) \
( LAST_24H_ASR_PCT, "last_24h_asr_percent", "Last 24 hours calculated ASR percentage.", "" ) \
( LAST_24H_OUTGOING_CALL_CNT, "last_24h_outgoing_call_cnt", "Last 24 hours outgoing calls.", "" ) \
( HOUR_ASR_PCT, "current_hour_asr_percent", "Current hour calculated ASR percentage.", "" ) \
( HOUR_OUTGOING_CALL_CNT, "current_hour_outgoing_call_cnt", "Current hour outgoing calls.", "" ) \
( LAST_HOUR_ASR_PCT, "last_hour_asr_percent", "Last hour calculated ASR percentage.", "" ) \
( LAST_HOUR_OUTGOING_CALL_CNT, "last_hour_outgoing_call_cnt", "Last hour outgoing calls.", "" ) \
( AVAILABILITY_DETECTION_STRUCT, "availability_detection_struct", "Detailed availibility detection Statistics", "" ) \
( POLL_REMOTE_PROXY, "poll_remote_proxy", "Remote proxy polling enabled", "" ) \
( IS_AVAILABLE, "is_available", "Remote proxy actually available or not", "" ) \
( TIME_SINCE_POLLING, "time_since_polling", "Time since the last availibility polling", "" ) \
( TIME_AVAILABLE_SECONDS, "time_available_seconds", "Number of seconds since the NAP is available", "x" ) \
( TIME_UNAVAILABLE_SECONDS, "time_unavailable_seconds", "Number of seconds since the NAP is unavailable", "x" ) \
( REGISTRATION_STRUCT, "registration_struct", "Detailed registration Statistics", "" ) \
( REGISTER_TO_PROXY, "register_to_proxy", "Register to proxy enabled", "" ) \
( IS_REGISTERED, "registered", "Actually registered or not", "" ) \
( TIME_SINCE_REFRESH, "time_since_refresh", "Time since the last refresh", "" ) \
( TIME_REGISTERED_SECONDS, "time_registered_seconds", "Number of seconds since the NAP is registered", "x" ) \
( TIME_NOT_REGISTERED_SECONDS, "time_not_registered_seconds", "Number of seconds since the NAP is not registered", "x" ) \
/*!< Nap Status Fields */

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

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

asr_statistics_struct_global_asr_percent

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

== Test parameters ==

=== @call_params ===

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

 

=== @nap_list ===

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

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

----

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

Routing script tutorial:Mini Development Guide

2010-08-20T14:22:57Z

Ktrueman: link to ASR

== 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 takes 2 arguments, the call parameters (hash) and the route parameters (hash).

Apply route remapping rules
caf_call.accept out_call, route

=== Refuse ===

This function is used to refuse a call with a reason code argument parameters :
caf_call.refuse :reason => :temporary_failure

The supported values are described in the section "Reason values".

== Call parameters ==

The following call parameters are available in the call object:

* calling
* calling_noa
* calling_npi
* calling_display_type
* calling_display
* calling_presentation
* calling_screening
* called
* called_noa
* called_npi
* nap

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

=== Noa values ===
* <tt>unknown_number</tt>
* <tt>international_number</tt>
* <tt>national_number</tt>
* <tt>subscriber_number</tt>
* <tt>network_specific</tt>
* <tt>network_routing_national_format</tt>
* <tt>network_routing_international_format</tt>
* <tt>abbreviated_number</tt>
* <tt>subscriber_number_operator_requested</tt>
* <tt>national_number_operator_requested</tt>
* <tt>international_number_operator_requested</tt>
* <tt>no_number_present_operator_requested</tt>
* <tt>no_number_present_cut_through_call_to_carrier</tt>
* <tt>test_line_test_code</tt>
* <tt>non_unique_subscriber_number</tt>
* <tt>non_unique_national_number</tt>
* <tt>non_unique_international_number</tt>
* <tt>call_950_number</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:
* <tt>call_params[:called_noa] = 0x70</tt>
or
* <tt>call_params[:called_noa] = 112</tt>

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

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

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:
* <tt>call_params[:calling_display_type] = 0xB1</tt>
or
* <tt>call_params[:calling_display_type] = 177</tt>

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

=== Calling Presentation values ===
* <tt>unspecified</tt>
* <tt>not_available</tt>
* <tt>allowed</tt>
* <tt>restricted</tt>
* <tt>addr_restricted</tt>
* <tt>name_restricted</tt>

=== Calling Screening values ===
* <tt>unspecified</tt>
* <tt>no</tt>
* <tt>pass</tt>
* <tt>fail</tt>
* <tt>network_provided</tt>

== Route parameters ==

All route may have these parameters:

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

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

== Reason values ==

All the CMC reason code are provide for use by the routing scripts . See the TBCMC_CALL_REASON_CODE enum in the tbcmc_call.h file.

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

/* isdn/ss7 reason code style */
/* Toolpack engine will convert reason code from sip to isdn/ss7 or isdn/ss7 to sip according to RFC3398 */
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
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_CONN_OPERATIONAL
TEMPORARY_FAILURE
SWITCHING_EQUIP_CONGESTION
ACCESS_INFO_DISCARDED
REQUESTED_CIRCUIT_NOT_AVAILABLE
PRECEDENCE_CALL_BLOCKED
RESOURCE_UNAVAILABLE
QOS_NOT_AVAILABLE
REQUESTED_FACILITY_NOT_SUBSCRIBED
OUTGOING_CALLS_BARRED
OUTGOING_CALLS_BARRED_WITHIN_CUG
INCOMING_CALLS_BARRED
INCOMING_CALLS_BARRED_WITHIN_CUG
BEARER_CAP_NOT_AUTHORIZED
BEARER_CAP_NOT_AVAILABLE
INCONSISTENCY_ACCESS_INFO
SERVICE_NOT_AVAILABLE
BEARER_CAP_NOT_IMPLEMENTED
CHANNEL_TYPE_NOT_IMPLEMENTED
REQUESTED_FACILITY_NOT_IMPLEMENTED
ONLY_RESTRICTED_DIGITAL_INFO
SERVICE_NOT_IMPLEMENTED
INVALID_CALL_REFERENCE
CHANNEL_DOES_NOT_EXIST
CALL_IDENTITY_DOES_NOT_EXIST
CALL_IDENTITY_IN_USE
NO_CALL_SUSPENDED
CALL_HAS_BEEN_CLEARED
USER_NOT_MEMBER_OF_CUG
INCOMPATIBLE_DESTINATION
NON_EXISTANT_CUG
INVALID_TRANSIT_NETWORK
INVALID_MESSAGE_UNSPECIFIED
MANDATORY_IE_MISSING
MESSAGE_TYPE_NON_EXISTENT
MESSAGE_NOT_COMPATIBLE_WITH_CALL_STATE
IE_NON_EXISTENT
INVALID_IE_CONTENT
MSG_NOT_COMPATIBLE_WITH_CALL_STATE
RECOVERY_ON_TIMER_EXPIRY
PARAMETER_NON_EXISTENT_PASSED_ON
MESSAGE_WITH_NON_RECOGNIZED_PARAMETERS_DISCARDED
PROTOCOL_ERROR
INTERWORKING_UNSPECIFIED

/* Toolpack specific errors */
NORMAL
RESOURCE_ERROR
TIMEOUT
NO_ROUTE
CALL_COLLISION
SYNC_DROP
SIGNALING_ERROR
LOCALLY_REJECTED
INTERFACE_NOT_AVAILABLE
RESET_IN_PROGRESS
ADAPTER_REJECT
MISSING_INVALID_IE
INCOMING_ONLY
SYSTEM_CONFIGURATION_CHANGED
RESOURCE_NO_MORE_AVAILABLE
INCOMPATIBLE_MEDIA
RES_ALLOC_FAILED
DATA_PATH_NOT_AVAILABLE

 

== Nap status ==

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

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

#define NAP_STATS_FIELDS \
/* Field, szName, szDescription, szOptions */ \
( SIGNALING_TYPE, "signaling_type", "Signaling type.", "" ) \
( INCOMING_CALL_CNT, "inst_incoming_call_cnt", "Instantaneous Count of incoming calls.", "" ) \
( OUTGOING_CALL_CNT, "inst_outgoing_call_cnt", "Instantaneous Count of outgoing calls.", "" ) \
( AVAILABLE_CNT, "available_cnt", "Number of available circuits or channels.", "" ) \
( UNAVAILABLE_CNT, "unavailable_cnt", "Number of unavailable circuits or channels.", "" ) \
( AVAILABILITY_PCT, "availability_percent", "Percentage of available circuits or channels.", "" ) \
( USAGE_PCT, "usage_percent", "Percentage of used circuits or channels.", "" ) \
( TOTAL_INCOMING_CALL_CNT, "total_incoming_call_cnt", "Total Count of incoming calls.", "" ) \
( ASR_STRUCT, "asr_statistics_struct", "Detailed Answer-Seizure Rate Statistics.", "" ) \
( GLOBAL_ASR_PCT, "global_asr_percent", "Global calculated ASR percentage.", "" ) \
( TOTAL_OUTGOING_CALL_CNT, "total_outgoing_call_cnt", "Total Count of outgoing calls.", "" ) \
( LAST_24H_ASR_PCT, "last_24h_asr_percent", "Last 24 hours calculated ASR percentage.", "" ) \
( LAST_24H_OUTGOING_CALL_CNT, "last_24h_outgoing_call_cnt", "Last 24 hours outgoing calls.", "" ) \
( HOUR_ASR_PCT, "current_hour_asr_percent", "Current hour calculated ASR percentage.", "" ) \
( HOUR_OUTGOING_CALL_CNT, "current_hour_outgoing_call_cnt", "Current hour outgoing calls.", "" ) \
( LAST_HOUR_ASR_PCT, "last_hour_asr_percent", "Last hour calculated ASR percentage.", "" ) \
( LAST_HOUR_OUTGOING_CALL_CNT, "last_hour_outgoing_call_cnt", "Last hour outgoing calls.", "" ) \
( AVAILABILITY_DETECTION_STRUCT, "availability_detection_struct", "Detailed availibility detection Statistics", "" ) \
( POLL_REMOTE_PROXY, "poll_remote_proxy", "Remote proxy polling enabled", "" ) \
( IS_AVAILABLE, "is_available", "Remote proxy actually available or not", "" ) \
( TIME_SINCE_POLLING, "time_since_polling", "Time since the last availibility polling", "" ) \
( TIME_AVAILABLE_SECONDS, "time_available_seconds", "Number of seconds since the NAP is available", "x" ) \
( TIME_UNAVAILABLE_SECONDS, "time_unavailable_seconds", "Number of seconds since the NAP is unavailable", "x" ) \
( REGISTRATION_STRUCT, "registration_struct", "Detailed registration Statistics", "" ) \
( REGISTER_TO_PROXY, "register_to_proxy", "Register to proxy enabled", "" ) \
( IS_REGISTERED, "registered", "Actually registered or not", "" ) \
( TIME_SINCE_REFRESH, "time_since_refresh", "Time since the last refresh", "" ) \
( TIME_REGISTERED_SECONDS, "time_registered_seconds", "Number of seconds since the NAP is registered", "x" ) \
( TIME_NOT_REGISTERED_SECONDS, "time_not_registered_seconds", "Number of seconds since the NAP is not registered", "x" ) \
/*!< Nap Status Fields */

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

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

asr_statistics_struct_global_asr_percent

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

== Test parameters ==

=== @call_params ===

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

 

=== @nap_list ===

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

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

----

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