7.2 Generic Call Control

29.1983GPPOpen Service Architecture (OSA) Application Programming Interface (API) - Part 1Release 1999TS

7.2.1 Call Control Manager

Figure 7-11: State Transition Diagram for the CallControlManager

7.2.1.1 Active state

In this state a relation between the Application and the Generic Call Control Service Capability Feature has been established. It allows the application to indicate that it is interested in call related events. In case such an event occurs, the Call Control Manager will create a Call object and inform the application by invoking the method callEventNotify() on the IpAppCallControlManager interface. The application can also indicate it is no longer interested in certain call related events by calling disableCallNotification().

7.2.1.2 Notification terminated state

When the Call Control manager is in the Notification terminated state, events requested with enableCallNotification() will not be forwarded to the application. There can be multiple reasons for this: for instance it might be that the application receives more notifications than defined in the Service Level Agreement. Another example is that the SCS has detected it receives no notifications from the network due to e.g. a link failure. In this state no requests for new notifications will be accepted.

7.2.2 Call

Figure 7-12: State Transition Diagram for Call

7.2.2.1 Active state

In this state a call between two parties is being setup or present. Refer to the substates for more details

The application can request the gateway for a certain type of charging of the call by calling setCallChargePlan(). The application can request for charging related information by calling getCallInfoReq(). Furthermore the application can request supervision of the call by calling superviseCallReq(). It is also allowed to send Advice Of Charge information by calling setAdviceOfCharge().

7.2.2.1.1 1 Party in Call state

When the Call is in this state a calling party is present. The application can now request that a connection to a called party be established by calling the method routeReq(). When the calling party abandons the call before the application has invoked the routeReq() operation, the gateway informs the application by invoking callFaultDetected() and also the operation callEnded() will be invoked. When the calling party abandons the call after the application has invoked routeReq() but before the call has actually been established, the gateway informs the application by invoking callEnded().

When the calling party answers the call, a transition will be made to the 2 Parties in Call state. In case the call can not be established because the application supplied an invalid address or the connection to the called party was unsuccessful while the application was monitoring for the latter in interrupt mode, the Call object will stay in this state

In this state user interaction is possible unless there is an outstanding routing request.

7.2.2.1.2 2 Parties in Call state

A connection between two parties has been established.

In case the calling party disconnects, the gateway informs the application by invoking callEnded().

When the called party disconnects different situations apply:

1. the application is monitoring for this event in interrupt mode: a transition is made to the 1 Party in Call state, the application is informed with routeRes with indication that the called party has disconnected and all requested reports are sent to the application. The application now again has control of the call.

2. the application is monitoring for this event but not in interrupt mode. In this case a transition is made to the Network Released state and the gateway informs the application by invoking the operation routeRes() and callEnded().

3. the application is not monitoring for this event. In this case the application is informed by the gateway invoking the callEnded() operation and a transition is made to the Network Released state.

7.2.2.3 Network released state

In this state the call has ended and the Gateway collects the possible call information requested with getCallInfoReq() and / or superviseCallReq(). The information will be returned to the application by invoking the methods getCallInfoRes() and / or superviseCallRes() on the application. Also when a call was unsuccessful these methods are used.In case the application has not requested additional call related information immediately a transition is made to state Idle.

7.2.2.4 Finished state

In this state the call has ended and no call related information is to be send to the application. The application can only release the Call object. Calling the deassingCall() method has the same effect. Note that the application has to release the object itself as good OO practice requires that when an object was created on behalf of a certain entity, this entity is also responsible for destroying it when the object is no longer needed.

7.2.2.5 Application released state.

In this state the application has requested to release the Call object and the Gateway collects the possible call information requested with getCallInfoReq(). In case the application has not requested additional call related information immediately the Call object is destroyed.