29.198-04-33GPPOpen Service Access (OSA) Application Programming Interface (API)Part 4: Call controlRelease 9Subpart 3: Multi-party call control Service Capability Feature (SCF)TS
The following sequence diagram shows an advanced card service, initiated as a result of a prearranged event being received by the call control service. Before the call is made, the calling party is asked for an ID and PIN code. If the ID and PIN code are accepted, the calling party is prompted to enter the address of the destination party. A trigger of ‘#5’ is then set on the controlling leg (the calling party’s leg) such that if the calling party enters a ‘#5’ an event will be sent to the application. The call is then routed to the destination party. Sometime during the call the calling party enters ‘#5’ which causes the called leg to be released. The calling party is now prompted to enter the address of a new destination party, to which it is then routed.
1: This message is used by the application to create an object implementing the IpAppMultiPartyCallControlManager interface.
2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts a call barring service, it is likely that all new call events destined for a particular address or address range result in the caller being prompted for a password before the call is allowed to progress. When a new call, that matches the event criteria set in message 2, arrives a message (not shown) is directed to the object implementing the IpMultiPartyCallControlManager. Assuming that the criteria for creating an object implementing the IpMultiPartyCall interface (e.g. load control values not exceeded) is met, other messages (not shown) are used to create the call and associated call leg object.
3: This message is used to pass the new call event to the object implementing the IpAppMultiPartyCallControlManager interface.
4: This message is used to forward message 3 to the IpAppLogic.
5: This message is used by the application to create an object implementing the IpAppMultiPartyCall interface. The reference to this object is passed back to the object implementing the IpMultiPartyCallControlManager using the return parameter of message 3.
6: This message returns the call legs currently in the call. In principle a reference to the call leg of the calling party is already obtained by the application when it was notified of the new call event.
7: This message is used to associate a user interaction object with the calling party.
8: The initial card service dialogue is invoked using this message.
9: The result of the dialogue, which in this case is the ID and PIN code, is returned to its callback object using this message and eventually forwarded via another message (not shown) to the IpAppLogic.
10: Assuming the correct ID and PIN are entered, the final dialogue is invoked.
11: The result of the dialogue, which in this case is the destination address, is returned and eventually forwarded via another message (not shown) to the IpAppLogic.
12: This message is used to forward the address of the callback object.
13: The trigger for follow-on calls is set (on service code).
14: A new AppCallLeg is created to receive callbacks for another leg. Alternatively, the already existing AppCallLeg object could be passed in the subsequent createCallLeg(). In that case the application has to use the sessionIDs of the legs to distinguish between callbacks destined for the A-leg and callbacks destined for the B-leg.
15: This message is used to create a new call leg object. The object is created in the idle state and not yet routed in the network.
16: The application requests to be notified when the leg is answered.
17: The application routes the leg. As a result the network will try to reach the associated party.
18: When the B-party answers the call, the application is notified.
19: The event is forwarded to the application logic.
20: Legs that are created and routed explicitly are by default in state detached. This means that the media is not connected to the other parties in the call. In order to allow inband communication between the new party and the other parties in the call the media have to be explicitly attached.
21: At some time during the call the calling party enters ‘#5’. This causes this message to be sent to the object implementing the IpAppCallLeg interface, which forwards this event as a message (not shown) to the IpAppLogic.
22: The event is forwarded to the application.
23: This message releases the called party.
24: Another user interaction dialogue is invoked.
25: The result of the dialogue, which in this case is the new destination address is returned and eventually forwarded via another message (not shown) to the IpAppLogic.
26: A new AppCallLeg is created to receive callbacks for another leg.
27: The call is then forward routed to the new destination party.
28: As a result a new Callleg object is created.
29: This message passes the result of the call being answered to its callback object and is eventually forwarded via another message (not shown) to the IpAppLogic.
30: When the A-party terminates the application is informed.
31: The event is forwarded to the application logic.
32: Since the release of the A-party will in this case terminate the entire call, the application is also notified with this message.
33: The event is forwarded to the application logic.
34: Since the user interaction object were not released at the moment that the call terminated, the application receives this message to indicate that the UI resources are released in the gateway and no further communication is possible.
35: The event is forwarded to the application logic.
36: The application deassigns the call object.