Toolpack: Architecture, philosophy and evolution - Revision history

Allyntree at 17:03, 1 May 2018

2018-05-01T17:03:46Z

← Older revision		Revision as of 13:03, 1 May 2018
Line 2:		Line 2:
	TelcoBridges products are very modular in nature. From a hardware perspective, they are designed as a general motherboard or main circuit board containing core device logic, with a series of modules or [[Mezzanines\|mezzanines]] available to provide auxiliary capabilities such as various network interfaces, support for different audio codecs, or support for tone or fax detection (as well as IVR).		TelcoBridges products are very modular in nature. From a hardware perspective, they are designed as a general motherboard or main circuit board containing core device logic, with a series of modules or [[Mezzanines\|mezzanines]] available to provide auxiliary capabilities such as various network interfaces, support for different audio codecs, or support for tone or fax detection (as well as IVR).

	On the software front, the [[Toolpack software]] is designed as a series of services / components that can be modified, replaced~~, etc.~~, by a solution developer with the proper expertise.		On the software front, the Toolpack software is designed as a series of services / components that can be modified or replaced, by a solution developer with the proper expertise.


	== Philosophy==		== Philosophy==
	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.		You can 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, [[Toolpack_v2.3:BITS_Ports\|BITS]] interfaces for clocking.		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, [[Toolpack_v2.3:BITS_Ports\|BITS]] interfaces for clocking.
Line 27:		Line 27:

	A key source of the technological advantage of TelcoBridges and its products is its in-house R&D team. By designing its own hardware logic via integrated circuits known as FPGAs, TelcoBridges has been able to pack a significant amount of functionality into a small form factor, enabling it to combine support for multiple industry standards and protocols in a single, very dense device.		A key source of the technological advantage of TelcoBridges and its products is its in-house R&D team. By designing its own hardware logic via integrated circuits known as FPGAs, TelcoBridges has been able to pack a significant amount of functionality into a small form factor, enabling it to combine support for multiple industry standards and protocols in a single, very dense device.




	[[Category:Tdev_Features\|Architecture, Philosophy and Evolution]]		[[Category:Tdev_Features\|Architecture, Philosophy and Evolution]]
	~~[[category: Needs revising]]~~

Cbilodeau: fix link

2011-02-14T19:47:55Z

fix link

← Older revision		Revision as of 15:47, 14 February 2011
Line 8:		Line 8:
	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.		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.		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, [[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.		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.

Cbilodeau: fix category link

2011-02-14T19:42:52Z

fix category link

← Older revision		Revision as of 15:42, 14 February 2011
Line 31:		Line 31:


	[[Category:Tdev_Features]]		[[Category:Tdev_Features\|Architecture, Philosophy and Evolution]]
	[[category: Needs revising]]		[[category: Needs revising]]

Cbilodeau: add category

2011-02-14T19:40:28Z

add category

← Older revision		Revision as of 15:40, 14 February 2011
Line 31:		Line 31:


			[[Category:Tdev_Features]]
	[[category: Needs revising]]		[[category: Needs revising]]

Ktrueman: added link to mezzanines

2010-08-10T13:22:53Z

added link to mezzanines

← Older revision		Revision as of 09:22, 10 August 2010
Line 1:		Line 1:
	== Architecture ==		== Architecture ==
	TelcoBridges products are very modular in nature. From a hardware perspective, they are designed as a general motherboard or main circuit board containing core device logic, with a series of modules or mezzanines available to provide auxiliary capabilities such as various network interfaces, support for different audio codecs, or support for tone or fax detection (as well as IVR).		TelcoBridges products are very modular in nature. From a hardware perspective, they are designed as a general motherboard or main circuit board containing core device logic, with a series of modules or [[Mezzanines\|mezzanines]] available to provide auxiliary capabilities such as various network interfaces, support for different audio codecs, or support for tone or fax detection (as well as IVR).

	On the software front, the [[Toolpack software]] is designed as a series of services / components that can be modified, replaced, etc., by a solution developer with the proper expertise.		On the software front, the [[Toolpack software]] is designed as a series of services / components that can be modified, replaced, etc., by a solution developer with the proper expertise.

Ktrueman: added architecture info and moved things around.

2010-05-26T19:09:12Z

added architecture info and moved things around.

← Older revision		Revision as of 15:09, 26 May 2010
Line 1:		Line 1:
	~~content coming soon~~		== Architecture ==
			TelcoBridges products are very modular in nature. From a hardware perspective, they are designed as a general motherboard or main circuit board containing core device logic, with a series of modules or mezzanines available to provide auxiliary capabilities such as various network interfaces, support for different audio codecs, or support for tone or fax detection (as well as IVR).

	~~== Evolution ==~~		On the software front, the [[Toolpack software]] is designed as a series of services / components that can be modified, replaced, etc., by a solution developer with the proper expertise.
	*Under construction


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

Line 28:		Line 21:


	== ~~Architecture~~ ==		== Evolution ==
	*Under construction		TelcoBridges’ first family of products were [[TB640\|hardware blades]] featuring support for [[SIP]], [[SS7]] and [[ISDN]] signalling. Targeted at the computer telephony integration (or CTI) marketplace, these were based on the CompactPCI form factor.

			In 2007, TelcoBridges introduced new lines of products based on a rack-mount form factor of 1U or 2U enclosures. This has allowed TelcoBridges to continue adding functionality, capacity and performance to its products, something that the CompactPCI form factor did not easily permit.

			A key source of the technological advantage of TelcoBridges and its products is its in-house R&D team. By designing its own hardware logic via integrated circuits known as FPGAs, TelcoBridges has been able to pack a significant amount of functionality into a small form factor, enabling it to combine support for multiple industry standards and protocols in a single, very dense device.





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

Ktrueman: filled out philosophy section

2010-05-26T16:06:27Z

filled out philosophy section

@@ Line 2: / Line 2: @@
 == Evolution ==
+*Under construction
@@ 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.
 == Architecture ==
-schematic of toolpack with additional insight; some content may be on the current [[Toolpack]] page
+*Under construction

Ktrueman: /* Philosophy */ added links

2010-05-26T16:02:22Z

Philosophy: added links

← Older revision		Revision as of 12:02, 26 May 2010
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

Ktrueman: more content ideas from ken

2009-08-21T15:50:56Z

Ktrueman: placeholder

2009-08-21T15:40:58Z

placeholder

New page

content coming soon

← Older revision		Revision as of 11:50, 21 August 2009
Line 1:		Line 1:
	content coming soon		content coming soon

			== 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==
			*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
			*Customers can add additional component support (some have done H.323 on their own), etc.

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