4.4 Call Information Collect Service

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 application monitoring a call between party A and a party B in order to collect call information at the end of the call for e.g. charging and/or statistic information collection purposes. The service may apply to ordinary two-party calls, but could also include a number translation of the dialled number and special charging (e.g. a premium rate service).

Additional call leg related information is requested with the getInfoReq and superviseReq methods.

The answer and call release events are in this service example requested to be reported in notify mode and additional call leg related information is requested with the getInfoReq and superviseReq methods in order to illustrate the information that can be collected and sent to the application at the end of the call.

Furthermore the diagram shows the order in which information is sent to the application: network release event followed by possible requested call leg information, then the destruction of the call leg object (callLegEnded) and finally the destruction of the call object (callEnded).

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.

4: When a new call, that matches the event criteria, arrives a message ("analysed information") is directed to the object implementing the IpMultiPartyCallControlManager. Assuming that the criteria for creating an object implementing the IpMultiPartyCall interface is met, other messages are used to create the call and associated call leg object

6: A new MultiPartyCall object is created to handle this particular call.

7: A new CallLeg object corresponding to Party A is created.

8: The new Call Leg instance transits to state Active.

9: This message is used to pass the new call event to the object implementing the IpAppMultiPartyCallControlManager interface. Applied monitor mode is "interrupt"

10: This message is used to forward message 9 to the IpAppLogic.

11: 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 the reportNotification.

12: A new AppCallLeg is created to receive callbacks for the Leg corresponding to party A.

13: A new AppCallLeg is created to receive callbacks for another leg.

14: 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.

15: A new CallLeg corresponding to party B is created.

16: A transition to state Idle is made after the Call leg has been created.

17: The application requests to be notified (monitor mode "NOTIFY") when party B answers the call and when the leg to B-party is released.

18: The application requests to supervise the call leg to party B.

19: The application requests information associated with the call leg to party B for example to calculate charging.

20: The application requests a specific charge plan to be set for the call leg to party B.

21: The application requests to route the terminating leg to reach the associated party B.

22: The Call Leg instance transits to state Active.

24: The application requests to be notified (monitor mode "Notify") when the leg to A-party is released.

25: The application requests information associated with the call leg to party A for example to calculate charging.

26: The application requests to resume call processing for the originating call leg. As a result call processing is resumed in the network that will try to reach the associated party B.

29: When the B-party answers the call, the termination call leg is notified.

30: Assuming the call is answered, the object implementing party B’s IpCallLeg interface passes the result of the call being answered back to its callback object (monitor mode "NOTIFY").

31: This answer message is then forwarded.

32: When the A-party releases the call, the originating call leg is notified (monitor mode "NOTIFY") and makes a transition to "releasing state".

34: The application IpAppLeg A is notified, as the release event has been requested to be reported in Notify mode.

35: The event is forwarded to the application logic

36: The call leg information is reported.

37: The event is forwarded to the application logic.

38: The origination call leg is destroyed, the AppLeg A is notified.

39: The event is forwarded to the application logic

41: When the B-party releases the call or the call is released as a result of the release request from party A, i.e. an "originating release" indication, the terminating call leg is notified and makes a transition to "releasing state".

43: If a network release event is received being a "terminating release" indication from called party B, the application IpAppLeg B is notified, as the release event from party B has been requested to be reported in NOTIFY mode.

Note that no report is sent if the release is caused by propagation of network release event being an "originating release" indication coming from calling party A.

44: The event is forwarded to the application logic.

45: The call leg information is reported.

46: The event is forwarded to the application logic.

47: The supervised call leg information is reported.

48: The event is forwarded to the application logic.

49: The terminating call leg is destroyed, the AppLeg B is notified.

50: The event is forwarded to the application logic.

52: Assuming the IpCall object has been informed that the legs have been destroyed, the IpAppMultiPartyCall is notified that the call is ended .

53: The event is forwarded to the application logic.