The following diagram explains how a feature (the Map Proxy) uses the TCAP leg manager. The sequence of steps shown are related to the receipt of a new Open Request for a new Dialog that is received by the IPSMGW.
Figure 1. Map Proxy TCAP Leg Manager Scenario
1 |
The IPSMGW is triggered by a Open Request on a dialog with a supported TCAP Application Context
|
2 |
The TCAP leg manager is registered to process Open Requests. It takes two actions:
-
Creates a new TCAP Leg that represents the new dialog ("incoming").
-
Decides what feature script execution points should be run by the IPSMGW
|
3 |
The IPSMGW starts running feature script execution points. One of the scripts runs the MAP Proxy feature
|
4 |
-
uses the TCAP leg manager to find the TCAP Leg related to the triggering Open Request ("incoming")
-
creates a new TCAP Leg called "proxied"
-
links the two TCAP Legs together. The MAP Proxy follows the link to find the "incoming" leg on a trigger related to the "proxied" leg and to find the "proxied" leg on a trigger related to the "incoming" leg
-
creates a new Open Request message and issues it on the new "proxied" leg. The new Open Request is not send immediately; a feature instruction of sendTcapMessage is registered in the TCAP Leg Manager and the new Open Request is pending on the "proxied" leg
|
5 |
Once all feature script execution points have finished, the TCAP Leg Manager processes any outstanding instructions. At this point a new Dialog is created, and the Open Request is sent to the external network element.
|
