CAF Call interface

From TBwiki
(Difference between revisions)
Jump to: navigation, search
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.).
+
  
  

Revision as of 09:34, 8 May 2009

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

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 inherit 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 of ALL events since a given application (such as Telephony Application) may not work without them.




Return to the Toolpack User Guide

Personal tools