Toolpack: Architecture, philosophy and evolution

From TBwiki
(Difference between revisions)
Jump to: navigation, search
(Philosophy: added links)
(filled out philosophy section)
Line 2: Line 2:
  
 
== Evolution ==
 
== Evolution ==
 
+
*Under construction
=== 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
+
  
  
Line 41: Line 26:
  
 
[[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.
 
[[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
+
*Under construction
 +
 
 +
 
 +
[[category: Needs revising]]

Revision as of 11:06, 26 May 2010

content coming soon

Contents

Evolution

  • Under construction


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

  • Under construction
Personal tools