CAF Call interface - Revision history

Allyntree at 15:17, 6 September 2022

2022-09-06T15:17:12Z

← Older revision		Revision as of 10:17, 6 September 2022
Line 1:		Line 1:
	This interface is used as the API to an object that can handle multiple call legs. It is primarily used by other CAF modules such as Behaviors to interact with the call management object without explicitly knowing its class definition. This interface is particularly useful since a system designer can completely replace the default call handling class (GRP_DOC_CALL_MANAGEMENT_CAF_CALL) '''(LINK?)''' by a custom class ~~but~~ still ~~benefits~~ from all the behaviors from the Toolpack modules (e.g., ring-back-tone, voicemail-fallback, etc.).		{{DISPLAYTITLE:CAF Call interface}}
			This interface is used as the API to an object that can handle multiple call legs. It is primarily used by other CAF modules such as Behaviors to interact with the call management object without explicitly knowing its class definition. This interface is particularly useful since a system designer can completely replace the default call handling class (GRP_DOC_CALL_MANAGEMENT_CAF_CALL) '''(LINK?)''' by a custom class, and still benefit from all the behaviors from the Toolpack modules (e.g., ring-back-tone, voicemail-fallback, etc.).

	== Usage ==		== Usage ==
	This interface does not define the behavior of the class ~~nor~~ its implementation. This is specifically what makes this interface so useful since applications such as Telephony Application could be easily modified by providing a new, custom-made, call handling class by simply changing one line in the application. All remaining code of the application does not need to be altered as it never makes any reference to the class since it always uses interface pointers.		This interface does not define the behavior of the class or its implementation. This is specifically what makes this interface so useful, since applications such as Telephony Application could be easily be modified by providing a new, custom-made, call handling class by simply changing one line in the application. All remaining code of the application does not need to be altered as it never makes any reference to the class since it always uses interface pointers.

	~~== Caveats ==~~



	~~----~~

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

10.0.0.240: /* Caveats */

2009-05-26T11:44:03Z

Caveats

← Older revision		Revision as of 06:44, 26 May 2009
Line 5:		Line 5:

	== Caveats ==		== Caveats ==
	*A class implementation of this interface needs to provide an implementation of ALL events since a given application (such as [[Telephony Application]]) may not work without them.

10.0.0.240: /* Caveats */

2009-05-26T11:43:54Z

Caveats

← Older revision		Revision as of 06:43, 26 May 2009
Line 5:		Line 5:

	== Caveats ==		== Caveats ==
	*A class implementation of this interface will usually be sized to support a known maximum number of calls. It is recommended to inherit from the [[TBCAF::CTBCAFPoolOfBuffers\|CTBCAFPoolOfBuffers]] in addition to this interface to provide a memory manager call implementation.
	*A class implementation of this interface needs to provide an implementation of ALL events since a given application (such as [[Telephony Application]]) may not work without them.		*A class implementation of this interface needs to provide an implementation of ALL events since a given application (such as [[Telephony Application]]) may not work without them.

Ktrueman at 14:34, 8 May 2009

2009-05-08T14:34:27Z

← Older revision		Revision as of 09:34, 8 May 2009
Line 1:		Line 1:
	This interface is used as the API to an object that can handle multiple call legs. It is primarily used by other CAF modules such as Behaviors to interact with the call management object without explicitly knowing its class definition. This interface is particularly useful since a system designer can completely replace the default call handling class (GRP_DOC_CALL_MANAGEMENT_CAF_CALL) '''(LINK?)''' by a custom class but still benefits from all the behaviors from the Toolpack modules (e.g., ring-back-tone, voicemail-fallback, etc.).		This interface is used as the API to an object that can handle multiple call legs. It is primarily used by other CAF modules such as Behaviors to interact with the call management object without explicitly knowing its class definition. This interface is particularly useful since a system designer can completely replace the default call handling class (GRP_DOC_CALL_MANAGEMENT_CAF_CALL) '''(LINK?)''' by a custom class but still benefits from all the behaviors from the Toolpack modules (e.g., ring-back-tone, voicemail-fallback, etc.).


	== Usage ==		== Usage ==

Ktrueman at 14:34, 8 May 2009

2009-05-08T14:34:16Z

← Older revision		Revision as of 09:34, 8 May 2009
Line 1:		Line 1:
	This interface is used as the API to an object that can handle multiple call legs. It is primarily used by other CAF		This interface is used as the API to an object that can handle multiple call legs. It is primarily used by other CAF modules such as Behaviors to interact with the call management object without explicitly knowing its class definition. This interface is particularly useful since a system designer can completely replace the default call handling class (GRP_DOC_CALL_MANAGEMENT_CAF_CALL) '''(LINK?)''' by a custom class but still benefits from all the behaviors from the Toolpack modules (e.g., ring-back-tone, voicemail-fallback, etc.).
	modules such as Behaviors to interact with the call management object without explicitly knowing its class definition.
	This interface is particularly useful since a system designer can completely replace the default call handling class
	(GRP_DOC_CALL_MANAGEMENT_CAF_CALL) '''(LINK?)''' by a custom class but still benefits from all the behaviors from
	the Toolpack modules (e.g., ring-back-tone, voicemail-fallback, etc.).

Ktrueman at 14:34, 8 May 2009

2009-05-08T14:34:03Z

← Older revision		Revision as of 09:34, 8 May 2009
Line 2:		Line 2:
	modules such as Behaviors to interact with the call management object without explicitly knowing its class definition.		modules such as Behaviors to interact with the call management object without explicitly knowing its class definition.
	This interface is particularly useful since a system designer can completely replace the default call handling class		This interface is particularly useful since a system designer can completely replace the default call handling class
	(GRP_DOC_CALL_MANAGEMENT_CAF_CALL) by a custom class but still benefits from all the behaviors from		(GRP_DOC_CALL_MANAGEMENT_CAF_CALL) '''(LINK?)''' by a custom class but still benefits from all the behaviors from
	the Toolpack modules (e.g., ring-back-tone, voicemail-fallback, etc.).		the Toolpack modules (e.g., ring-back-tone, voicemail-fallback, etc.).

Ktrueman at 14:33, 8 May 2009

2009-05-08T14:33:23Z

← Older revision		Revision as of 09:33, 8 May 2009
Line 1:		Line 1:
	This interface is used as the API to an object that can handle multiple call legs. It is primarily used by other CAF		This interface is used as the API to an object that can handle multiple call legs. It is primarily used by other CAF
	modules such as Behaviors to interact with the call management object without ~~explicitely~~ knowing its class definition.		modules such as Behaviors to interact with the call management object without explicitly knowing its class definition.
	This interface is ~~particularily~~ useful since a system designer can completely replace the default call handling class		This interface is particularly useful since a system designer can completely replace the default call handling class
	(GRP_DOC_CALL_MANAGEMENT_CAF_CALL) by a custom class but still benefits from all the behaviors from		(GRP_DOC_CALL_MANAGEMENT_CAF_CALL) by a custom class but still benefits from all the behaviors from
	the ~~ToolPack~~ modules (e.g. ring-back-tone, voicemail-fallback, etc).		the Toolpack modules (e.g., ring-back-tone, voicemail-fallback, etc.).


Line 12:		Line 12:
	*A class implementation of this interface will usually be sized to support a known maximum number of calls. It is recommended to inherit from the [[TBCAF::CTBCAFPoolOfBuffers\|CTBCAFPoolOfBuffers]] in addition to this interface to provide a memory manager call implementation.		*A class implementation of this interface will usually be sized to support a known maximum number of calls. It is recommended to inherit from the [[TBCAF::CTBCAFPoolOfBuffers\|CTBCAFPoolOfBuffers]] in addition to this interface to provide a memory manager call implementation.
	*A class implementation of this interface needs to provide an implementation of ALL events since a given application (such as [[Telephony Application]]) may not work without them.		*A class implementation of this interface needs to provide an implementation of ALL events since a given application (such as [[Telephony Application]]) may not work without them.





			----

			Return to the Toolpack [[User Guide]]

Ktrueman: /* Caveats */

2009-05-08T14:32:34Z

Caveats

← Older revision		Revision as of 09:32, 8 May 2009
Line 10:		Line 10:

	== Caveats ==		== Caveats ==
	*A class implementation of this interface will usually be sized to support a known maximum number of calls. It is recommended to ~~inherite~~ from the CTBCAFPoolOfBuffers in addition to this interface to provide a memory manager call implementation.		*A class implementation of this interface will usually be sized to support a known maximum number of calls. It is recommended to inherit from the [[TBCAF::CTBCAFPoolOfBuffers\|CTBCAFPoolOfBuffers]] in addition to this interface to provide a memory manager call implementation.
	*A class implementation of this interface needs to provide an implementation ~~all~~ ALL events since a ~~particular~~ application (such as Telephony Application) may not work without them.		*A class implementation of this interface needs to provide an implementation of ALL events since a given application (such as [[Telephony Application]]) may not work without them.

Ktrueman: /* Caveats */

2009-05-08T14:30:33Z

Caveats

← Older revision		Revision as of 09:30, 8 May 2009
Line 11:		Line 11:
	== Caveats ==		== Caveats ==
	*A class implementation of this interface will usually be sized to support a known maximum number of calls. It is recommended to inherite from the CTBCAFPoolOfBuffers in addition to this interface to provide a memory manager call implementation.		*A class implementation of this interface will usually be sized to support a known maximum number of calls. It is recommended to inherite from the CTBCAFPoolOfBuffers in addition to this interface to provide a memory manager call implementation.
	*A class implementation of this interface needs to provide an implementation		*A class implementation of this interface needs to provide an implementation all ALL events since a particular application (such as Telephony Application) may not work without them.

Ktrueman: New page: This interface is used as the API to an object that can handle multiple call legs. It is primarily used by other CAF modules such as Behaviors to interact with the call management object w...

2009-05-08T14:24:30Z

New page: This interface is used as the API to an object that can handle multiple call legs. It is primarily used by other CAF modules such as Behaviors to interact with the call management object w...

New page

This interface is used as the API to an object that can handle multiple call legs. It is primarily used by other CAF
modules such as Behaviors to interact with the call management object without explicitely knowing its class definition.
This interface is particularily useful since a system designer can completely replace the default call handling class
(GRP_DOC_CALL_MANAGEMENT_CAF_CALL) by a custom class but still benefits from all the behaviors from
the ToolPack modules (e.g. ring-back-tone, voicemail-fallback, etc).

== Usage ==
This interface does not define the behavior of the class nor its implementation. This is specifically what makes this interface so useful since applications such as Telephony Application could be easily modified by providing a new, custom-made, call handling class by simply changing one line in the application. All remaining code of the application does not need to be altered as it never makes any reference to the class since it always uses interface pointers.

== Caveats ==
*A class implementation of this interface will usually be sized to support a known maximum number of calls. It is recommended to inherite from the CTBCAFPoolOfBuffers in addition to this interface to provide a memory manager call implementation.
*A class implementation of this interface needs to provide an implementation