Toolpack: Architecture, philosophy and evolution

From TBwiki
(Difference between revisions)
Jump to: navigation, search
(more content ideas from ken)
(Philosophy: added links)
Line 21: Line 21:
  
 
== Philosophy==
 
== Philosophy==
*Toolpack is designed as a series of services / components that can be modified, replaced, etc. ...
+
 
*Talk to how solution developers can replace components with their own
+
=== Overall ===
*Customers can add additional component support (some have done H.323 on their own), etc.
+
 
 +
Toolpack is very modular in nature. It is designed as a series of services / components that can be modified, replaced, etc., by a solution developer with the proper expertise.
 +
 
 +
=== Configurations ===
 +
 
 +
You should think of the configuration of the underlying [[Tmedia]] or [[Tdev]] device as a series of building blocks. This implies that there are certain blocks, or settings, that need to be put in place first before others can be laid on top of them.
 +
 
 +
In this case, you start with the most basic element, which is the actual physical interfaces; whether they are [[TDM]] interfaces such as E1/T1/J1 connections, DS-3 connections, optical or electrical STM-1 connections; Ethernet connections for the purpose of [[VoIP]]; or finally, when applicable, [[http://docs.telcobridges.com/mediawiki/index.php/Toolpack_v2.3:BITS_Ports|BITS]] interfaces for clocking.
 +
 
 +
Following that, you activate the different signaling protocol stacks, such as [[ISDN]], [[SIP]], [[CAS|CAS R2]], and, where applicable, [[SS7]] and [[SIGTRAN|SS7 SIGTRAN]], the latter two of which are available with a separate license.
 +
 
 +
You then build out [[Toolpack:Profile_SDP_Description|service description profiles]] that determine the supported [[Voice codecs|audio codecs]] for use with mobile and internet telephony.
 +
 
 +
Finally, you configure the trunk groups, or in Toolpack terminology, the [[NAP|Network Access Points]].
 +
 
 +
These settings are stored together as a single configuration. The [[Toolpack_Application:toolpack_engine|Toolpack Engine]], which runs as an application service, then takes the information provided in the active configuration settings and uses that to provide the [[Tandem switching|switching]], [[transcoding]] and [[Signaling_protocols|signaling]] conversion services that are required.
 +
 
 +
[[CallRouting|Call routes]], which are not handled by Toolpack Engine, can be defined only when the previous building blocks have been put in place. The actual call routing functionality can be provided by a 3rd party [[softswitch]] or by [[Toolpack_Application:gateway|TB Media Gateway Application]], which is bundled with all Tmedia devices.
  
 
== Architecture ==
 
== Architecture ==
 
schematic of toolpack with additional insight; some content may be on the current [[Toolpack]] page
 
schematic of toolpack with additional insight; some content may be on the current [[Toolpack]] page

Revision as of 11:02, 26 May 2010

content coming soon

Contents

Evolution

Software

  • basic API
  • toolpack API
  • toolpack web portal
  • moving up the stack
    • support for scripting

Other applications

TB Stream Server TB Media Gateway application (tentative name for the packaged version of the app to keep sales team happy)


Hardware

minor discussion about how we moved from blades to rackmount and what that implied from a system design perspective, and how the software changed to meet that reality


Philosophy

Overall

Toolpack is very modular in nature. It is designed as a series of services / components that can be modified, replaced, etc., by a solution developer with the proper expertise.

Configurations

You should think of the configuration of the underlying Tmedia or Tdev device as a series of building blocks. This implies that there are certain blocks, or settings, that need to be put in place first before others can be laid on top of them.

In this case, you start with the most basic element, which is the actual physical interfaces; whether they are TDM interfaces such as E1/T1/J1 connections, DS-3 connections, optical or electrical STM-1 connections; Ethernet connections for the purpose of VoIP; or finally, when applicable, [[1]] interfaces for clocking.

Following that, you activate the different signaling protocol stacks, such as ISDN, SIP, CAS R2, and, where applicable, SS7 and SS7 SIGTRAN, the latter two of which are available with a separate license.

You then build out service description profiles that determine the supported audio codecs for use with mobile and internet telephony.

Finally, you configure the trunk groups, or in Toolpack terminology, the Network Access Points.

These settings are stored together as a single configuration. The Toolpack Engine, which runs as an application service, then takes the information provided in the active configuration settings and uses that to provide the switching, transcoding and signaling conversion services that are required.

Call routes, which are not handled by Toolpack Engine, can be defined only when the previous building blocks have been put in place. The actual call routing functionality can be provided by a 3rd party softswitch or by TB Media Gateway Application, which is bundled with all Tmedia devices.

Architecture

schematic of toolpack with additional insight; some content may be on the current Toolpack page

Personal tools