CAF: Working With Call Legs
| Line 1: | Line 1: | ||
| − | = | + | == Call Leg Definition == |
The main mechanism through which the customer application controls the Toolpack system, is via the management of call legs. The application creates a call leg (or more than one for conferencing and bridging) at the beginning of call, then control it through a simple, protocol-agnostic API. When a call is terminated, the call leg can be destroyed. | The main mechanism through which the customer application controls the Toolpack system, is via the management of call legs. The application creates a call leg (or more than one for conferencing and bridging) at the beginning of call, then control it through a simple, protocol-agnostic API. When a call is terminated, the call leg can be destroyed. | ||
| − | + | A call leg is respresented by an instance of the class CTBCMCLeg. It represents a full-duplex media resource and/or its associated | |
| − | signalling entity. Typical examples would be an SS7 ISUP call with its associated CIC (mapped to a TDM | + | signalling entity. Typical examples of call leg with signaling would be an SS7 ISUP call with its associated CIC (mapped to a TDM |
| − | interface such as a T1 timeslot) or a SIP call with its associated Voip codec resource (attached to an IP/UDP endpoint). | + | interface such as a T1 timeslot) or a SIP call with its associated Voip codec resource (attached to an IP/UDP endpoint). A media-only call leg would represent a standalone TDM endpoint (such as a T1 timeslot) or a VOIP endpoint (Voip codec resource attached to an IP/UDP endpoint). Section [[Customer_Application_Framework_:_Working_With_Call_Legs#Creating Call Legs | Creating Call Legs ]] will show how different types of leg can be created. |
| − | + | ||
| + | The CTBCMCLeg class allows a programmer to easily act upon the call leg to influence the signaling portion (e.g. accept, answer, | ||
terminate, etc) and to use the media portion as well (e.g play prompts, record voice, play or collect digits and tones). | terminate, etc) and to use the media portion as well (e.g play prompts, record voice, play or collect digits and tones). | ||
| Line 16: | Line 17: | ||
===== Caveats ===== | ===== Caveats ===== | ||
| − | * Do not confuse a call leg with a call . A call leg represents one full-duplex link to a party while a call represents | + | * Do not confuse a ''call leg'' with a ''call''. A ''call leg'' represents one full-duplex link to a party while a ''call'' represents |
| − | the agglomeration of multiple (two or more) call legs. For example, a bridge is a form of call that uses two call | + | the agglomeration of multiple (two or more) call legs. For example, a ''bridge'' is a form of ''call'' that uses two ''call |
| − | + | leg''s. | |
| − | * Do not confuse the base class | + | * Do not confuse the base class CTBCMCLeg with the class CTBCAFCallLeg. The later is an implementation class specialized to be used by |
the ITBCAFCall interface when dealing with multiple legs. It is designed to represent a leg within a call. It | the ITBCAFCall interface when dealing with multiple legs. It is designed to represent a leg within a call. It | ||
| − | cannot be instanciated as a standalone object | + | cannot be instanciated as a standalone object without modifications to make it independent from the ITBCAFCall interface. |
* If the overall goal is to bridge two or more call legs together, then the programmer would be advised to use the | * If the overall goal is to bridge two or more call legs together, then the programmer would be advised to use the | ||
| − | + | CTBCAFCallFlow class for leg creation instead of creating call legs manually. This class already deals with the issues of handling multiple legs simultaneously. | |
| + | |||
| + | == Creating Call Legs == | ||
| + | Creating a leg is always done through the definition of a ''call leg attribute''. The values entered in the ''call leg attribute'' will define the type of call leg created and it's parameters. The following sections describe several scenarios in which you build a ''call leg''. Instruction will be given on how to fill the leg attributes and how to use them to create the ''call leg''. | ||
| + | |||
| + | TODO Present call flow for leg creation. | ||
| + | |||
| + | === Leg Creation Scenario === | ||
| + | ==== Creating a Standalone Outgoing Call ==== | ||
| + | |||
| + | ==== Bridging an Incoming Call (manual method)==== | ||
| + | ==== Bridging an Incoming Call (using CTBCAFCallFlow )==== | ||
| + | ==== Creating a Media-only Leg ==== | ||
| + | === Caveats === | ||
* The call leg attribute is an object containing the call leg information (called/calling numbers, etc) that needs | * The call leg attribute is an object containing the call leg information (called/calling numbers, etc) that needs | ||
to be allocated by the caller (in this example the ’main’) and given to the call leg object. It will be freed | to be allocated by the caller (in this example the ’main’) and given to the call leg object. It will be freed | ||
| Line 36: | Line 50: | ||
an object could also self-delete if it is given its own ’freeListener’ interface pointer. This all depends on the | an object could also self-delete if it is given its own ’freeListener’ interface pointer. This all depends on the | ||
hierarchy of object owership the application designer wants to do. | hierarchy of object owership the application designer wants to do. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 15:18, 15 October 2009
Contents |
Call Leg Definition
The main mechanism through which the customer application controls the Toolpack system, is via the management of call legs. The application creates a call leg (or more than one for conferencing and bridging) at the beginning of call, then control it through a simple, protocol-agnostic API. When a call is terminated, the call leg can be destroyed.
A call leg is respresented by an instance of the class CTBCMCLeg. It represents a full-duplex media resource and/or its associated signalling entity. Typical examples of call leg with signaling would be an SS7 ISUP call with its associated CIC (mapped to a TDM interface such as a T1 timeslot) or a SIP call with its associated Voip codec resource (attached to an IP/UDP endpoint). A media-only call leg would represent a standalone TDM endpoint (such as a T1 timeslot) or a VOIP endpoint (Voip codec resource attached to an IP/UDP endpoint). Section Creating Call Legs will show how different types of leg can be created.
The CTBCMCLeg class allows a programmer to easily act upon the call leg to influence the signaling portion (e.g. accept, answer, terminate, etc) and to use the media portion as well (e.g play prompts, record voice, play or collect digits and tones).
Other member functions are available to retrieve (and change in some cases) the call leg attributes including the media profile (e.g. parameters to the media resource) or signaling information (e.g. protocol type, called and calling party numbers, etc). Joining/unjoining (connection/disconnection) of call legs is also a typical action handled by this class for ’gateway-type’ applications. It is important to note that this class is protocol-agnostic and can handle any type of supported call legs (e.g. SIP/Voip, ISDN, SS7, Media only, etc).
Caveats
- Do not confuse a call leg with a call. A call leg represents one full-duplex link to a party while a call represents
the agglomeration of multiple (two or more) call legs. For example, a bridge is a form of call that uses two call legs.
- Do not confuse the base class CTBCMCLeg with the class CTBCAFCallLeg. The later is an implementation class specialized to be used by
the ITBCAFCall interface when dealing with multiple legs. It is designed to represent a leg within a call. It cannot be instanciated as a standalone object without modifications to make it independent from the ITBCAFCall interface.
- If the overall goal is to bridge two or more call legs together, then the programmer would be advised to use the
CTBCAFCallFlow class for leg creation instead of creating call legs manually. This class already deals with the issues of handling multiple legs simultaneously.
Creating Call Legs
Creating a leg is always done through the definition of a call leg attribute. The values entered in the call leg attribute will define the type of call leg created and it's parameters. The following sections describe several scenarios in which you build a call leg. Instruction will be given on how to fill the leg attributes and how to use them to create the call leg.
TODO Present call flow for leg creation.
Leg Creation Scenario
Creating a Standalone Outgoing Call
Bridging an Incoming Call (manual method)
Bridging an Incoming Call (using CTBCAFCallFlow )
Creating a Media-only Leg
Caveats
- The call leg attribute is an object containing the call leg information (called/calling numbers, etc) that needs
to be allocated by the caller (in this example the ’main’) and given to the call leg object. It will be freed automatically when the leg is destroyed.
- The base class does not automatically free itself. This is why the member function OnCallTerminated() was
overloaded to actually instruct the base class to start the freeing operation once the signaling call is done. In CMC User’s Guide another type of application, some steps could be required before the actual leg free is desired (such as logging, DB access, etc).
- The ’delete’ operation on the call leg is eventually done by the object exposing the ’freeListener’ interface. This
allows the application to centralize (if required) the ownership of objects to a single entity. This means that an object could also self-delete if it is given its own ’freeListener’ interface pointer. This all depends on the hierarchy of object owership the application designer wants to do.
