This section explains how to create, link and end TCAP legs.
Two methods of creating TCAP legs are available:
A feature establishes a new relation with an external network element by creating a new TCAP leg and calling
issueOpenRequest() on the newly created leg.
createLeg()on the TCAP Leg Manager. A new TCAP leg is immediately created (
MyLeg). Newly created legs don’t have a
ACIassociated with them yet.
MyFeaturecreates a new
DialogOpenRequestobject and calls
issueOpenRequest(openRequest)on the newly created TCAP leg. The TCAP Leg manager registers an instruction
sendTcapMessageand the open request is set as the pending message on the newly created leg. Features that execute after
MyFeaturecan make any changes to the pending message before the
sendTcapMessageinstruction is processed.
Once the currently executing feature script execution point is finished, the TCAP Leg Manager processes any instructions for all legs. In this case the TCAP Leg Manager will process
sendTcapMessagefor the open request by:
creating a new
Dialogand sending the open request
getting the associated
ActivityContextInterface(ACI) for the newly created Dialog
attaching to the ACI so all responses from the external network element will be receiv qed by the IPSMGW
The TCAP Leg Manager also provides a second, overloaded, variant of
The TCAP Leg Manager will set the
See: Feature Extension Events to learn more about Extension events.
See Operating on a TCAP Leg for more information about sending messages on TCAP legs.
A feature may create a TCAP leg from an
ActivityContextInterface that corresponds to an existing relation with an external network element.
importAsNewLeg(aci, "MyLeg") on the TCAP Leg Manager to create a new TCAP leg called
MyLeg that is associated with the ACI
In some cases it is convenient to be able to navigate from one TCAP leg to a related TCAP leg. A concrete example is the MAP proxy feature, which proxies messages between two related TCAP legs. You create a relation between two TCAP legs by linking them with the
A link between two legs is bi-directional. Calling
MyLeg will return
OtherLeg and calling
OtherLeg will return
MyLeg. You can break the link between two legs by calling
unlinkLeg() on either TCAP leg involved in a link.
detach from a TCAP leg when the leg is not needed anymore and the IPSMGW should not take any responsibility for further actions on the associated Dialog.
Detaching a TCAP leg removes the association between the TCAP leg manager and the TCAP leg. It is an action that takes place immediately. This means the leg cannot be used by any features that subsequently execute. The TCAP leg manager takes no action on the associated Dialog or ACI (if they exist).
Two methods for detaching a TCAP leg are available:
detachFromLeg(myLeg) on the TCAP Leg Manager. The TCAP leg
MyLeg is immediately removed. The IPSMGW detaches from the associated
ActivityContextInterface (if there is one). No pending instructions will be processed for the detached leg. The detached Leg cannot be accessed by any subsequent features that execute.
No actions are taken on the associated
Dialog so it is important that either the feature ensures the dialog ends properly before detaching, or that an alternate service with the Rhino TAS will take responsibility for any further actions on the Dialog.
detachAllLegs() on the TCAP Leg Manager. Each leg known by the leg manager is detached as described in section: Detach from a particular leg.
release a TCAP leg when the leg is not needed anymore and the IPSMGW should also make sure the associated Dialog is ended correctly.
releaseLeg(myLeg)on the TCAP Leg Manager.
MyLegis immediately unlinked (if it is linked). Any pending instructions are removed and a new instruction (
releaseLeg) is created. In this example a
sendTcapMessageinstruction is replaced with a
releaseLeginstruction. Any pending message on the leg is preserved and may be used while processing the
releaseLeginstruction. The leg can still be accessed by other features before the
releaseLeginstruction is processed.
Once the current feature script execution point finishes, the TCAP Leg Manager processes all pending instructions for all known legs. In this example the associated Dialog is ended, and then the TCAP leg
The method used to end the Dialog depends on the Dialog State.
|Dialog State||Action …|
If there is no pending message on the leg, then send a
If there is a pending message that is a
Features which need a more fine-grained control over the release process should use a combination of
Feature end a session (
endSession) when all existing TCAP legs are not needed anymore and the IPSMGW should also make sure all Dialogs associated with the existing legs are ended correctly.
endSession()on the TCAP Leg Manager.
All existing legs are released by unlinking them, removing any pending instructions and creating a
releaseLeginstruction for each leg.
Once the current feature script execution point finishes, the TCAP Leg Manager processes all pending instructions for all known legs. In this example the Dialogs associated with
OtherLegare ended (as described in Releasing a TCAP Leg) and both TCAP legs are removed.