CMC library - Revision history

Abrassard: Adding example code

2011-05-30T15:21:25Z

Adding example code

Abrassard at 15:18, 30 May 2011

2011-05-30T15:18:33Z

Cbilodeau: fix link

2011-02-15T20:43:16Z

fix link

Ktrueman: fixed signaling link

2009-08-07T15:44:55Z

fixed signaling link

Ktrueman: fixed CAF link

2009-07-24T16:01:31Z

fixed CAF link

Ktrueman: merged content from two different CMC Library pages

2009-07-23T19:01:24Z

merged content from two different CMC Library pages

Ktrueman: added links and some clean-up

2009-07-21T14:28:09Z

added links and some clean-up

Ktrueman: new links

2009-07-06T18:07:42Z

new links

Ktrueman at 20:54, 7 May 2009

2009-05-07T20:54:17Z

Ktrueman at 20:53, 7 May 2009

2009-05-07T20:53:58Z

@@ 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]]

@@ 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

@@ 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 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.

← Older revision		Revision as of 15: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.

@@ 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 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.

@@ 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.
 == Key features ==
-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 ==
-*Application can register as a backup application
+*'''Event messages'''
-*Automatic takeover of the service in the event an application goes down
+**Incoming call present

← Older revision		Revision as of 20: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.

@@ Line 1: / Line 1: @@
-The CMC library is a C message-driven API that removes the complexity of media resource management and eases the
+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.
 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’
+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.
 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.