CMC library - Revision history

Allyntree at 14:22, 7 September 2022

2022-09-07T14:22:45Z

← Older revision		Revision as of 10:22, 7 September 2022
Line 1:		Line 1:
			{{DISPLAYTITLE:CMC library}}

	CMC Library – CMC stands for Call & Media Control – is a C-based message-driven [[API]] that was designed to enable object-oriented, asynchronous event handling of call legs. It removes the complexity of media resource management while easing the bridging of call legs that employ different protocols ([[SS7]], [[ISDN]], [[CAS]], [[SIP]], etc.). Through the use of a [[Signaling protocols\|signaling]]-agnostic message API, CMC Library simplifies the requirement for the customer’s application to control signaling along with the associated media.		CMC Library – CMC stands for Call & Media Control – is a C-based message-driven [[API]] that was designed to enable object-oriented, asynchronous event handling of call legs. It removes the complexity of media resource management while easing the bridging of call legs that employ different protocols ([[SS7]], [[ISDN]], [[CAS]], [[SIP]], etc.). Through the use of a [[Signaling protocols\|signaling]]-agnostic message API, CMC Library simplifies the requirement for the customer’s application to control signaling along with the associated media.

Line 59:		Line 61:
	[[CAF:_Leg_Creation_Samples]]		[[CAF:_Leg_Creation_Samples]]

	Below is an example that ~~show~~ how to initialize and terminate the ''CTBCMCLib'' module:		Below is an example that demonstrates how to initialize and terminate the ''CTBCMCLib'' module:

	class MyApplication : public CTBCMCLibUser		class MyApplication : public CTBCMCLibUser

Abrassard: Adding example code

2011-05-30T15:21:25Z

Adding example code

@@ Line 52: / Line 52: @@
 == Example usage ==
 Documentation on how to use CMC Library can be found here:
 [[CAF:_Working_With_Caf_Call_Legs]]
 and here
 [[CAF:_Leg_Creation_Samples]]

Abrassard at 15:18, 30 May 2011

2011-05-30T15:18:33Z

@@ Line 8: / Line 8: @@
 A typical example is for an application to send proprietary information into a SS7 primitive using the user-to-user information elements (IE) or to fill a specific IE with network-specific information. The CMC Library API also removes the responsibility of the customer’s application for creating and managing resources (e.g., resource allocation for [[IVR]] functions, resource allocation for [[VoIP]] functions, [[Toolpack Application:tbstreamserver|TB StreamServer]] access). These high-level functions enable the user to focus on value-added features and services instead of creating adaptation layer software. (e.g., an API ’CMD_PLAY’ that automatically allocated the IVR resources and tells the stream server to play an audio or video file onto a call leg). Although the protocols and resources handling are simplified, event driven handling of call legs is still required.
 == Key features ==
@@ Line 44: / Line 49: @@
 **Digit collected
 **Error report

Cbilodeau: fix link

2011-02-15T20:43:16Z

fix link

← Older revision		Revision as of 16:43, 15 February 2011
Line 1:		Line 1:
	CMC Library – CMC stands for Call & Media Control – is a C-based message-driven [[API]] that was designed to enable object-oriented, asynchronous event handling of call legs. It removes the complexity of media resource management while easing the bridging of call legs that employ different protocols ([[SS7]], [[ISDN]], [[CAS]], [[SIP]], etc.). Through the use of a [[Signaling protocols\|signaling]]-agnostic message API, CMC Library simplifies the requirement for the customer’s application to control signaling along with the associated media.		CMC Library – CMC stands for Call & Media Control – is a C-based message-driven [[API]] that was designed to enable object-oriented, asynchronous event handling of call legs. It removes the complexity of media resource management while easing the bridging of call legs that employ different protocols ([[SS7]], [[ISDN]], [[CAS]], [[SIP]], etc.). Through the use of a [[Signaling protocols\|signaling]]-agnostic message API, CMC Library simplifies the requirement for the customer’s application to control signaling along with the associated media.

	CMC Library sits between [[Toolpack Engine]] and the customer application. It provides the customer application with a message-based API to communicate with Toolpack Engine. CMC Library forwards requests from the customer application to Toolpack Engine and returns response/event messages from Toolpack Engine to the customer application and is responsible for thread management.		CMC Library sits between [[Toolpack_Application:toolpack_engine\|Toolpack Engine]] and the customer application. It provides the customer application with a message-based API to communicate with Toolpack Engine. CMC Library forwards requests from the customer application to Toolpack Engine and returns response/event messages from Toolpack Engine to the customer application and is responsible for thread management.

	CMC Library is an asynchronous framework used by the [[Customer Application Framework]] (CAF) and is not normally accessed by developers who would usually interact with the [[CAF Call API\|CAFClass library]]. The CAFClass library provides C++ wrapper classes that ease the handling of call leg state machines and remove the burden of creating an asynchronous framework while allowing synchronous operations within a call flow (e.g., access to a database) to work without affecting other legs. However, if an existing application already has its own asynchronous framework for handling call states, the software developer might choose to use CMC Library API directly.		CMC Library is an asynchronous framework used by the [[Customer Application Framework]] (CAF) and is not normally accessed by developers who would usually interact with the [[CAF Call API\|CAFClass library]]. The CAFClass library provides C++ wrapper classes that ease the handling of call leg state machines and remove the burden of creating an asynchronous framework while allowing synchronous operations within a call flow (e.g., access to a database) to work without affecting other legs. However, if an existing application already has its own asynchronous framework for handling call states, the software developer might choose to use CMC Library API directly.

Ktrueman: fixed signaling link

2009-08-07T15:44:55Z

fixed signaling link

← Older revision		Revision as of 11:44, 7 August 2009
Line 1:		Line 1:
	CMC Library – CMC stands for Call & Media Control – is a C-based message-driven [[API]] that was designed to enable object-oriented, asynchronous event handling of call legs. It removes the complexity of media resource management while easing the bridging of call legs that employ different protocols ([[SS7]], [[ISDN]], [[CAS]], [[SIP]], etc.). Through the use of a [[Signaling\|signaling]]-agnostic message API, CMC Library simplifies the requirement for the customer’s application to control signaling along with the associated media.		CMC Library – CMC stands for Call & Media Control – is a C-based message-driven [[API]] that was designed to enable object-oriented, asynchronous event handling of call legs. It removes the complexity of media resource management while easing the bridging of call legs that employ different protocols ([[SS7]], [[ISDN]], [[CAS]], [[SIP]], etc.). Through the use of a [[Signaling protocols\|signaling]]-agnostic message API, CMC Library simplifies the requirement for the customer’s application to control signaling along with the associated media.

	CMC Library sits between [[Toolpack Engine]] and the customer application. It provides the customer application with a message-based API to communicate with Toolpack Engine. CMC Library forwards requests from the customer application to Toolpack Engine and returns response/event messages from Toolpack Engine to the customer application and is responsible for thread management.		CMC Library sits between [[Toolpack Engine]] and the customer application. It provides the customer application with a message-based API to communicate with Toolpack Engine. CMC Library forwards requests from the customer application to Toolpack Engine and returns response/event messages from Toolpack Engine to the customer application and is responsible for thread management.

Ktrueman: fixed CAF link

2009-07-24T16:01:31Z

fixed CAF link

← Older revision		Revision as of 12:01, 24 July 2009
Line 3:		Line 3:
	CMC Library sits between [[Toolpack Engine]] and the customer application. It provides the customer application with a message-based API to communicate with Toolpack Engine. CMC Library forwards requests from the customer application to Toolpack Engine and returns response/event messages from Toolpack Engine to the customer application and is responsible for thread management.		CMC Library sits between [[Toolpack Engine]] and the customer application. It provides the customer application with a message-based API to communicate with Toolpack Engine. CMC Library forwards requests from the customer application to Toolpack Engine and returns response/event messages from Toolpack Engine to the customer application and is responsible for thread management.

	CMC Library is an asynchronous framework used by the [[Customer Application Framework]] (CAF) and is not normally accessed by developers who would usually interact with the [[CAF ~~call~~ API\|CAFClass library]]. The CAFClass library provides C++ wrapper classes that ease the handling of call leg state machines and remove the burden of creating an asynchronous framework while allowing synchronous operations within a call flow (e.g., access to a database) to work without affecting other legs. However, if an existing application already has its own asynchronous framework for handling call states, the software developer might choose to use CMC Library API directly.		CMC Library is an asynchronous framework used by the [[Customer Application Framework]] (CAF) and is not normally accessed by developers who would usually interact with the [[CAF Call API\|CAFClass library]]. The CAFClass library provides C++ wrapper classes that ease the handling of call leg state machines and remove the burden of creating an asynchronous framework while allowing synchronous operations within a call flow (e.g., access to a database) to work without affecting other legs. However, if an existing application already has its own asynchronous framework for handling call states, the software developer might choose to use CMC Library API directly.

	Although it is still possible to ‘tweak’ parameters (i.e., information elements, SDPs, etc.) with CMC Library, doing so is optional. Therefore, applications requiring special control over signaling will still be able to do their things as long as they do not affect the system state.		Although it is still possible to ‘tweak’ parameters (i.e., information elements, SDPs, etc.) with CMC Library, doing so is optional. Therefore, applications requiring special control over signaling will still be able to do their things as long as they do not affect the system state.

Ktrueman: merged content from two different CMC Library pages

2009-07-23T19:01:24Z

merged content from two different CMC Library pages

← Older revision		Revision as of 15:01, 23 July 2009
Line 1:		Line 1:
	~~The~~ CMC ~~library~~ is a C message-driven API that removes the complexity of media resource management ~~and eases~~ the bridging of call legs of different protocols. Through the use of signaling-agnostic message API, ~~this creates a simpler~~ customer’s application to control signaling along with the associated media. Although it is still possible to ’tweak’ parameters (i.e., information elements, SDPs, etc), it is optional to do so. Therefore, applications requiring special control over the signaling will still be able to do their things as long as it is not state affecting.		CMC Library – CMC stands for Call & Media Control – is a C-based message-driven [[API]] that was designed to enable object-oriented, asynchronous event handling of call legs. It removes the complexity of media resource management while easing the bridging of call legs that employ different protocols ([[SS7]], [[ISDN]], [[CAS]], [[SIP]], etc.). Through the use of a [[Signaling\|signaling]]-agnostic message API, CMC Library simplifies the requirement for the customer’s application to control signaling along with the associated media.

	A typical example is for an application to send proprietary information into a [[SS7]] primitive using the user-to-user information elements or fill a specific IE with network-specific information. ~~This~~ API also removes the responsibility of the customer’s application of creating and managing resources (e.g., ~~resources~~ allocation for [[IVR]] functions, ~~resources~~ allocation for [[VoIP]] functions, ~~Stream server~~ access). ~~The~~ high-level functions ~~provided allow~~ the user to focus on value-added features and services instead of creating adaptation layer software. (e.g., an API ’CMD_PLAY’ that automatically allocated the IVR resources and ~~control~~ the stream server to play an audio or video file onto a call leg). Although the protocols and resources handling are simplified, event driven handling of call legs is required.		CMC Library sits between [[Toolpack Engine]] and the customer application. It provides the customer application with a message-based API to communicate with Toolpack Engine. CMC Library forwards requests from the customer application to Toolpack Engine and returns response/event messages from Toolpack Engine to the customer application and is responsible for thread management.

			CMC Library is an asynchronous framework used by the [[Customer Application Framework]] (CAF) and is not normally accessed by developers who would usually interact with the [[CAF call API\|CAFClass library]]. The CAFClass library provides C++ wrapper classes that ease the handling of call leg state machines and remove the burden of creating an asynchronous framework while allowing synchronous operations within a call flow (e.g., access to a database) to work without affecting other legs. However, if an existing application already has its own asynchronous framework for handling call states, the software developer might choose to use CMC Library API directly.

			Although it is still possible to ‘tweak’ parameters (i.e., information elements, SDPs, etc.) with CMC Library, doing so is optional. Therefore, applications requiring special control over signaling will still be able to do their things as long as they do not affect the system state.
			A typical example is for an application to send proprietary information into a SS7 primitive using the user-to-user information elements (IE) or to fill a specific IE with network-specific information. The CMC Library API also removes the responsibility of the customer’s application for creating and managing resources (e.g., resource allocation for [[IVR]] functions, resource allocation for [[VoIP]] functions, [[Toolpack Application:tbstreamserver\|TB StreamServer]] access). These high-level functions enable the user to focus on value-added features and services instead of creating adaptation layer software. (e.g., an API ’CMD_PLAY’ that automatically allocated the IVR resources and tells the stream server to play an audio or video file onto a call leg). Although the protocols and resources handling are simplified, event driven handling of call legs is still required.


	== Key features ==		== Key features ==
			Key features of CMC Library include:
			*Automatic CMC Server detection
			*Automatic resynchronization of already created call legs and associated media.
			*Providing automatic High Availability (HA) resynchronization capabilities in case of application failure/restart
			*Automatic load sharing among running instances of CMC Server
			*Thread pooling and call context serialization
			*Enables more efficient use of CPU resources (thread, semaphores, etc).
			*Synchronous operations on one call leg without affecting other legs.


	~~Key features of the CMC library include:~~		== High availability applications ==
	*Automatic [[CMC ~~Server]] detection~~		CMC Library supports the high availability capabilities of Toolpack. This includes:
	*Automatic resynchronization of ~~already created call legs and associated media~~.		*Application can register as a backup application
	*~~Providing automatic [[High Availability]] (HA) resynchronization capabilities in case of~~ application ~~failure/restart~~		*Automatic takeover of the service in the event an application goes down
	*Automatic ~~load sharing among running instances~~ of ~~CMC Server~~
	*Thread pooling and call context serialization
	~~:*Allowing a more efficient use of CPU resources (thread, semaphores, etc).~~
	~~:*Synchronous operations on one call leg without affecting other legs.~~


	==~~=HA applications=~~==		== Message types ==
			CMC Library handles both request messages and event messages sent by the application to Toolpack engine through the CMC library.
			*'''Request messages'''
			**Make call
			**Alert/Accept/Answer call
			**Join / unjoin legs
			**Play Stream, Record Stream, Stop Stream
			**Start/stop digit collection
			**Play digits

	*~~Application can register as a backup application~~		*'''Event messages'''
	*~~Automatic takeover of the service in the event an application goes down~~		**Incoming call present
			**Leg resync
			**Call terminating indication
			**Call alerting/accepted/answered
			**Stream play done, record stream done
			**Digit collected
			**Error report

Ktrueman: added links and some clean-up

2009-07-21T14:28:09Z

added links and some clean-up

← Older revision		Revision as of 10:28, 21 July 2009
Line 1:		Line 1:
	The CMC library is a C message-driven API that removes the complexity of media resource management and eases the bridging of call legs of different protocols. Through the use of signaling-agnostic message API, this creates a simpler customer’s application to control signaling along with the associated media. Although it is still possible to ’tweak’ parameters (i.e., information elements, SDPs, etc), it is optional to do so. Therefore, applications requiring special control over the signaling will still be able to do their things as long as it is not state affecting.		The CMC library is a C message-driven API that removes the complexity of media resource management and eases the bridging of call legs of different protocols. Through the use of signaling-agnostic message API, this creates a simpler customer’s application to control signaling along with the associated media. Although it is still possible to ’tweak’ parameters (i.e., information elements, SDPs, etc), it is optional to do so. Therefore, applications requiring special control over the signaling will still be able to do their things as long as it is not state affecting.

	A typical example is for an application to send proprietary information into a SS7 primitive using the user-to-user information elements or fill a specific IE with network-specific information. This API also removes the responsibility of the customer’s application of creating and managing resources (e.g., resources allocation for IVR functions, resources allocation for ~~Voip~~ functions, Stream server access). The high-level functions provided allow the user to focus on value-added features and services instead of creating adaptation layer software. (e.g., an API ’CMD_PLAY’ that automatically allocated the IVR resources and control the stream server to play an audio or video file onto a call leg). Although the protocols and resources handling are simplified, event driven handling of call legs is required~~. This users guide will later show in details the different wrapper C++ classes available to create an easy to read code while retaining all the versatility of a complex API~~.		A typical example is for an application to send proprietary information into a [[SS7]] primitive using the user-to-user information elements or fill a specific IE with network-specific information. This API also removes the responsibility of the customer’s application of creating and managing resources (e.g., resources allocation for [[IVR]] functions, resources allocation for [[VoIP]] functions, Stream server access). The high-level functions provided allow the user to focus on value-added features and services instead of creating adaptation layer software. (e.g., an API ’CMD_PLAY’ that automatically allocated the IVR resources and control the stream server to play an audio or video file onto a call leg). Although the protocols and resources handling are simplified, event driven handling of call legs is required.


Line 16:		Line 16:


	~~'''~~HA applications~~'''~~		===HA applications===

	~~<ul>~~		*Application can register as a backup application
	~~<li>~~Application can register as a backup application		*Automatic takeover of the service in the event an application goes down
	~~<li>~~Automatic takeover of the service in the event an application goes down
	~~</ul>~~


	~~----~~

	~~Return to the Toolpack [[User Guide]]~~

Ktrueman: new links

2009-07-06T18:07:42Z

new links

← Older revision		Revision as of 14:07, 6 July 2009
Line 9:		Line 9:
	*Automatic [[CMC Server]] detection		*Automatic [[CMC Server]] detection
	*Automatic resynchronization of already created call legs and associated media.		*Automatic resynchronization of already created call legs and associated media.
	*Providing automatic High Availability (HA) resynchronization capabilities in case of application failure/restart		*Providing automatic [[High Availability]] (HA) resynchronization capabilities in case of application failure/restart
	*Automatic load sharing among running instances of CMC Server		*Automatic load sharing among running instances of CMC Server
	*Thread pooling and call context serialization		*Thread pooling and call context serialization

Ktrueman at 20:54, 7 May 2009

2009-05-07T20:54:17Z

← Older revision		Revision as of 16:54, 7 May 2009
Line 1:		Line 1:
	The CMC library is a C message-driven API that removes the complexity of media resource management and eases the bridging of call legs of different protocols. Through the use of signaling-agnostic message API, this creates a simpler customer’s application to control signaling along with the associated media. Although it is still possible to ’tweak’ parameters (i.e. information elements, SDPs, etc), it is optional to do so. Therefore, applications requiring special control over the signaling will still be able to do their things as long as it is not state affecting.		The CMC library is a C message-driven API that removes the complexity of media resource management and eases the bridging of call legs of different protocols. Through the use of signaling-agnostic message API, this creates a simpler customer’s application to control signaling along with the associated media. Although it is still possible to ’tweak’ parameters (i.e., information elements, SDPs, etc), it is optional to do so. Therefore, applications requiring special control over the signaling will still be able to do their things as long as it is not state affecting.

	A typical example is for an application to send proprietary information into a SS7 primitive using the user-to-user information elements or fill a specific IE with network-specific information. This API also removes the responsibility of the customer’s application of creating and managing resources (e.g., resources allocation for IVR functions, resources allocation for Voip functions, Stream server access). The high-level functions provided allow the user to focus on value-added features and services instead of creating adaptation layer software. (e.g., an API ’CMD_PLAY’ that automatically allocated the IVR resources and control the stream server to play an audio or video file onto a call leg). Although the protocols and resources handling are simplified, event driven handling of call legs is required. This users guide will later show in details the different wrapper C++ classes available to create an easy to read code while retaining all the versatility of a complex API.		A typical example is for an application to send proprietary information into a SS7 primitive using the user-to-user information elements or fill a specific IE with network-specific information. This API also removes the responsibility of the customer’s application of creating and managing resources (e.g., resources allocation for IVR functions, resources allocation for Voip functions, Stream server access). The high-level functions provided allow the user to focus on value-added features and services instead of creating adaptation layer software. (e.g., an API ’CMD_PLAY’ that automatically allocated the IVR resources and control the stream server to play an audio or video file onto a call leg). Although the protocols and resources handling are simplified, event driven handling of call legs is required. This users guide will later show in details the different wrapper C++ classes available to create an easy to read code while retaining all the versatility of a complex API.