7.3 State Transition Diagrams for IpCallLeg

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 IpCallLeg State Transition Diagram is divided in two State Transition Diagrams, one for the originating call leg and one for the terminating call leg.

Call Leg State Model General Objectives:

  1. Events in backwards direction (upstream), coming from terminating leg, are not directly visible in originating leg model. NOTE1
  2. Events in forwards direction (downstream), coming from originating leg, are not directly visible in terminating leg model. NOTE1
  3. States are as seen from the application: if there is no change in the method an application is permitted to apply on the IpCallLeg object, then there is no state change. Therefore receipt of e.g. answer or alerting events on terminating leg do not change state. NOTE 2
  4. Call processing is suspended if for a leg a network event is met, which was requested to be monitored in the P_CALL_MONITOR_MODE_INTERRUPT. The application shallsend a request to continue processing (using an appropriate method like continueProcessing, deassign, release or routeReq) for each leg and event reported in monitor mode ‘interrupt’.
    If the event leads to a state transition, the call processing is suspended when entering the state.
  5. In case on a leg more than one network event (for example a mid-call event ‘service_code’ and a disconnection event) is to be reported to the application at quasi the same time, then the events are to be reported one by one to the application in the order received from the network. When for a leg an event is reported in interrupt mode, a next pending event is not to be reported to the application until a request to resume call processing for the current reported event has been received on the leg.

NOTE1: Although events coming from a specific party will always be tied to the callLeg related to that party, these events might lead to state transitions of other callLegs. Examples of such events are terminating release, where also the originating leg might transit to the releasing state and originating_release where the terminating leg might transit to the releasing state.

NOTE2: Even though there in the Originating Call Leg STD is no change in the methods the application is permitted to apply to the IpCallLeg object for the states Analysing and Active, separate states are maintained. The states may therefore from an application viewpoint appear as just one state that may be have substates like Analysing and Active. The digit collection task in state Analysing state may be viewed as a specialised task that may not at all be applicable in some networks and therefore here described as being a state on its own.

7.3.1 Originating Call Leg

Figure : Originating Leg

7.3.1.1 Initiating State

Entry events:

– Sending of a reportNotification() method by the IpMultiPartyCallControlManager for an ‘Originating_Call_Attempt’ initial notification criterion.

– Sending of a reportNotification() method by the IpMultiPartyCallControlManager for an ‘Originating_Call_Attempt_Authorised’ initial notification criterion.

Functions:

In this state the network checks the authority/ability of the party to place the connection to the remote (destination) party with the given properties, e.g. based on the originating party’s identity and service profile.

The setup of the connection for the party has been initiated and the application activity timer is being provided.

The figure below shows the order in which network events may be detected in the Initiating state and depending on the monitor mode be reported to the application.

Note 1: Event oCA only applicable as an initial notification .

Note 2: The release event (oREL) can occur in any state resulting in a transition to Releasing state.

Abbreviations used for the events:

oCA: originating Call Attempt;

oCAA originating Call Attempt Authorized;

AC: Address Collected;

oREL originating RELease.

Figure : Application view on event reporting order in Initiating State

In this state the following functions are applicable:

– The detection of a ‘Originating_Call_Attempt’ initial notification criterion.

– The detection of an ‘Originating_Call_Attempt_Authorised’ initial notification criterion as a result that the call attempt authorisation is successful.

– The report of the ‘Originating_Call_Attempt_Authorised’ event indication whereby the following functions are performed:

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event P_CALL_EVENT_CALL_ATTEMPT_AUTHORISED then the event is reported and call leg processing is suspended.

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event P_CALL_EVENT_CALL_ATTEMPT_AUTHORISED then the event is notified and call leg processing continues.

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event P_CALL_EVENT_CALL_ATTEMPT_AUTHORISED then no monitoring is performed.

– The receipt of destination address information, i.e. initial information package/dialling string as received from calling party.

– Resumption of suspended call leg processing occurs on receipt of a continueProcessing() method.

Exit events:

– Availability of destination address information, i.e. the initial information package/dialling string received from the calling party.

– Application activity timer expiry indicating that no requests from the application have been received during a certain period while processing is suspended for the leg.

– Receipt of a deassign() method.

  • Receipt of a release() method.

– Detection of a ‘originating release’ indication as a result of a premature disconnect from the calling party.

7.3.1.2 Analysing State

Entry events:

– Availability of an ‘Address_Collected’ event indication as a result of the receipt of the (complete) initial information package/dialling string from the calling party.

– Availability of an ‘Address_Collected’ event indication as a result of additional digits received from the calling party as requested by the application (with eventReportReq).

– Sending of a reportNotification() method by the IpMultiPartyCallControlManager for an ‘Address_Collected’ initial notification criterion.

Functions:

In this state the destination address provided by the calling party is collected and analysed.

The received information (dialled address string from the calling party) is being collected and examined in accordance to the dialling plan in order to determine end of address information (digit) collection. Additional address digits can be collected. Upon completion of address collection the address is analysed.

The address analysis is being made according to the dialling plan in force to determine the routing address of the call leg connection and the connection type (e.g. local, transit, gateway).

The request (with eventReportReq method) to collect a variable number of more address digits and report them to the application (within eventReportRes method) is handled within this state. The collection of more digits as requested and the reporting of received digits to the application (when the digit collect criteria is met) is done in this state. This action can be repeated, e.g. the application may request first for 3 digits to be collected and when reported request further digits.

The figure below shows the order in which network events may be detected in the Analysing state and depending on the monitor mode be reported to the application.

Note 1: The release event (oREL) can occur in any state resulting in a transition to Releasing state.

Abbreviations used for the events:

oCAA: originating Call Attempt Authorized;

AC: Address Collected;

AA: Address Analysed;

oREL: originating RELease.

Figure : Application view on event reporting order in Analysing State

In this state the following functions are applicable:

– The detection of an ‘Address_Collected’ initial notification criterion.

– On receipt of the ‘Address_Collected’ indication the following functions are performed:

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event P_CALL_EVENT_ADDRESS_COLLECTED then the event is reported and call leg processing is suspended.

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event P_CALL_EVENT_ADDRESS_COLLECTED then the event is notified and call leg processing continues.

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event P_CALL_EVENT_ADDRESS_COLLECTED then no monitoring is performed.

– Receipt of an eventReportReq() method defining the criteria for the events the call leg object is to observe.

– Resumption of suspended call leg processing occurs on receipt of a continueProcessing() or a routeReq() method.

Exit events:

– Detection of an ‘Address_Analysed’ indication as a result of the availability of the routing address and nature of address.

– Receipt of a deassign() method.

– Receipt of a release() method.

– Application activity timer expiry indicating that no requests from the application have been received during a certain period while processing is suspended for the leg.

– Detection of a ‘originating release’ indication as a result of a premature disconnect from the calling party.

7.3.1.3 Active State

Entry events:

– Receipt of an ‘Address_Analysed’ indication as a result of the availability of the routing address and nature of address.

– Sending of a reportNotification() method by the IpMultiPartyCallControlManager for an ‘Address_Analysed’ initial indication criterion.

Functions:

In this state the call leg connection to the calling party exists and originating mid call events can be received.

The figure below shows the order in which network events may be detected in the Active state and depending on the monitor mode be reported to the application.

Note 1: Only the detected service code or the range to which the service code belongs is disarmed as the service code is reported to the application.

Note 2: The release event (oREL) can occur in any state resulting in a transition to Releasing state.

Abbreviations used for the events:

AC: Address Collected;

AA: Address Analysed;

oSC: originating Service Code;

oREL: originating RELease.

Figure : Application view on event reporting order Active State

In this state the following functions are applicable:

– The detection of an Address_Analysed initial indication criterion.

– On receipt of the ‘Address_Analysed’ indication the following functions are performed:

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event P_CALL_EVENT_ADDRESS_ANALYSED then the event is reported and call leg processing is suspended.

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event P_CALL_EVENT_ADDRESS_ANALYSED then the event is notified and call leg processing continues.

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event P_CALL_EVENT_ADDRESS_ANALYSED then no monitoring is performed.

– Resumption of suspended call leg processing occurs on receipt of a continueProcessing() method.

– When entering this state the routing information is interpreted, the authority of the calling party to establish this connection is verified. Note that no call leg connection is set up to the remote party at this point when the application is still in control. The application explicitly has to create and route the terminating leg, optionally using the address information from the Address_Analysed event. Only in case the call is deassigned (the application relinquishes control) in this state, the network will setup the connection to terminating leg automatically based on the received information.

– In this state a connection to the calling party is established.

– On receipt of the ‘originating_service code’ indication the following functions are performed:

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event P_CALL_EVENT_ORIGINATING_SERVICE_CODE then the event is reported and call leg processing is suspended.

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event P_CALL_EVENT_ORIGINATING_SERVICE_CODED then the event is notified and call leg processing continues.

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event P_CALL_EVENT_ORIGINATING_SERVICE_CODE then no monitoring is performed.

– Resumption of suspended call leg processing occurs on receipt of a continueProcessing() method.

Exit events:

– Detection of an ‘originating release’ indication as a result of a disconnect from the calling party.

– Detection of a propagated disconnect from the called party

– Receipt of a deassign() method.

– Receipt of a release() method from the application.

– Application activity timer expiry indicating that no requests from the application have been received during a certain period while call processing is suspended.

7.3.1.4 Releasing State

Entry events:

– Detection of an ‘Originating_Release’ indication as a result of the network release initiated by calling party.

– Propagated release from called party.

– Release of the entire call (e.g., after invoking IpCall.release())

– Reception of the release() method from the application.

– A transition due to fault detection to this state is made when the Call leg object is in a state and no requests from the application have been received during a certain time period (timer expiry).

Functions:

In this state the connection to the call party is released as requested by the network or by the application and the reports are processed and sent to the application if requested.

When the Releasing state is entered the order of actions to be performed is as follows:

i) The network release event handling is performed.

ii) The possible call leg information requested with getInfoReq() and/ or superviseReq() is collected and send to the application.

iii) The callLegEnded() method is sent to the application to inform that the call leg object is destroyed.

In this state the following functions are applicable:

  • The detection of an ‘originating_release’ initial indication criterion..

– On receipt of the ‘originating_release’ indication the following functions are performed:

– The network release event handling is performed as follows:

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event P_CALL_EVENT_RELEASE then the event is reported and call leg processing is suspended.

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event P_CALL_EVENT_RELEASE then the event is notified and call leg processing continues.

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event P_CALL_EVENT_RELEASE then no monitoring is performed.

Note that this handling is not performed for propagated releases from the called party.

  • Resumption of suspended call leg processing occurs on receipt of a continueProcessing() method.
  • The possible call leg information requested with the getInfoReq() and/or superviseReq() is collected and sent to the application with respectively the getInfoRes() and/or superviseRes() methods.
  • The callLegEnded() method is sent to the application after all information has been sent. In case that the application has not requested additional call leg related information the call leg object is destroyed immediately and additionally the application will also be informed that the connection has ended
  • In case of abnormal termination due to a fault and the application requested for call leg related information previously, the application will be informed that this information is not available and additionally the application is informed that the call leg object is destroyed (callLegEnded) and the leg is released in the network.

Note: the call in the network may continue or be released, depending e.g. on the call state.

– In case the release() method is received in Releasing state it will be discarded. The request from the application to release the leg is ignored in this case because release of the leg is already ongoing.

Exit events:

– In case that the application has not requested additional call leg related information the call leg object is destroyed immediately and additionally the application is informed that the call leg connection has ended, by sending the callLegEnded() method.

– After the sending of the last call leg information to the application the Call Leg object is destroyed and additionally the application is informed that the call leg connection has ended, by sending the callLegEnded() method.

– Application activity timer expiry indicating that no requests from the application have been received during a certain period while processing is suspended for the leg (re-enter releasing state).

– Receipt of a deassign() method. The leg will be released and call leg object destroyed, but no reports will be sent to the application anymore. Also no CallLegEnded will be invoked.

7.3.1.5 Overview of allowed methods, Originating Call Leg STD

State

Methods allowed

Initiating

getProperties
setProperties
attachMediaReq (as a request),
detachMediaReq, (as a request)

getCall ,
continueProcessing,
release (call leg),
deassign

eventReportReq,
getInfoReq,
setChargePlan,
setAdviceOfCharge,
superviseReq

Analysing

getProperties
setProperties
attachMediaReq (as a request),
detachMediaReq, (as a request)

getCall ,
continueProcessing,
release (call leg),
deassign

eventReportReq,
getInfoReq,
setChargePlan,
setAdviceOfCharge,
superviseReq

Active

getProperties
setProperties
attachMediaReq,
detachMediaReq,

getCall,
continueProcessing,
release
deassign

eventReportReq,
getInfoReq,
setChargePlan,
setAdviceOfCharge,
superviseReq

Releasing

getCall ,
continueProcessing,
release
deassign

7.3.2 Terminating Call Leg

Figure : Terminating Leg

7.3.2.1 Idle (terminating) State

Entry events:

– Receipt of a createCallLeg() method to start an application initiated call leg connection.

Functions:

In this state the call leg object is created and the interface connection is idled.

The application activity timer is being provided.

In this state the following functions are applicable:

– Invoking routeReq will result in a request to actually route the call leg object and resumption of call processing.

Exit events:

– Receipt of a routeReq() method from the application.

– Application activity timer expiry indicating that no requests from the application have been received during a certain period to continue processing.

– Receipt of a deassign() method.

– Receipt of a release() method.

– Propagation ofa network release event as a result of a disconnect from the calling party.

– Application activity timer expiry indicating that no requests from the application have been received during a certain period while processing is suspended for the leg.

7.3.2.2 Active (terminating) State

Entry events:

  • Receipt of a routeReq will result in actually routing the call leg object.
  • Receipt of a createAndRouteCallLegReq() method to start an application initiated call leg connection.
  • Sending of a reportNotification() method by the IpMultiPartyCallControlManager for the following trigger criteria: ‘Terminating_Call_Attempt’, ‘Terminating_Call_Attempt_Authorised’, ‘Alerting’, ‘Answer’, ‘Terminating service code’, ‘Redirected’ and ‘Queued’.

Functions:

In this state the routing information is interpreted, the authority of the called party to establish this connection is verified for the call leg connection. In this state a connection to the call party is established whereby events from the network may indicate to the application when the party is alerted (acknowledge connection setup) and when the party answer (confirmation of connection setup).

Furthermore, in this state terminating service code events can be received.

The figure below shows the order in which network events may be detected in the Active state and depending on the monitor mode be reported to the application.

Note 1: Event tCA applicable as initial notification.

Note 2: Only the detected service code or the range to which the service code belongs is disarmed as the service code is reported to the application.

Note 3: The release event (tREL) can occur in any state resulting in a transition to Releasing state.

Abbreviations used for the events:

tCA: Terminating Call Attempt;

tCAA: terminating Call Attempt Authorized;

AL: Alerting;

ANS: Answer;

tREL: terminating RELease;

Q: Queued;

RD: ReDirected;

tSC: terminating Service Code.

Figure : Application view on event reporting order in Active State

In this state the following functions are applicable:

– The detection and report of the ‘Terminating_Call_Attempt_Authorised’ event indication whereby the following functions are performed:

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED then the event is reported and call leg processing is suspended.

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED then the event is notified and call leg processing continues.

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event P_CALL_EVENT_CALL_TERMINATING_ATTEMPT_AUTHORISED then no monitoring is performed.

  • Detection of an ‘Queued’ indication as a result of the terminating call being queued.

– On receipt of the ‘Queued’ indication the following functions are performed:

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event P_CALL_EVENT_QUEUED then the event is reported and call leg processing is suspended.

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event P_CALL_EVENT_QUEUED then the event is notified and call leg processing continues.

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event P_CALL_EVENT_QUEUED then no monitoring is performed.

– On receipt of the ‘Alerting’ indication the following functions are performed:

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event P_CALL_EVENT_ALERTING then the event is reported and call leg processing is suspended.

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event P_CALL_EVENT_ALERTING then the event is notified and call leg processing continues.

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event P_CALL_EVENT_ALERTING then no monitoring is performed.

  • Detection of an ‘Answer’ indication as a result of the remote party being connected (answered).

– On receipt of the ‘Answer’ indication the following functions are performed:

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event P_CALL_EVENT_ANSWER then the event is reported and call leg processing is suspended.

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event P_CALL_EVENT_ANSWER then the event is notified and call leg processing continues.

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event P_CALL_EVENT_ANSWER then no monitoring is performed.

– The detection of a ‘service_code’ trigger criterion suspends call leg processing.

– On receipt of the ‘service code’ indication the following functions are performed:

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event P_CALL_EVENT_TERMINATING_SERVICE_CODE then the event is reported and call leg processing is suspended.

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event P_CALL_EVENT_TERMINATING_SERVICE_CODE then this is not a valid event (that event is not notified) and call leg processing continues.

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event P_CALL_EVENT_TERMINATING_SERVICE_CODE then no monitoring is performed.

– On receipt of the ‘redirected’ indication the following functions are performed:

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event P_CALL_EVENT_REDIRECTED then the event is reported and call leg processing is suspended.

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event P_CALL_EVENT_REDIRECTED then the event is notified and call leg processing continues.

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event P_CALL_EVENT_REDIRECTED then no monitoring is performed.

– Resumption of call leg processing occurs on receipt of a continueProcessing() method.

Exit events:

– Detection of a network release event being a ‘terminating release’ indication as a result of the following events:

i) Unable to select a route or indication from the remote party of the call leg connection cannot be presented (this is the network determined busy condition).

ii) Occurrence of an authorisation failure when the authority to place the call leg connection was denied (e.g. business group restriction mismatch).

iii) Detection of a route busy condition received from the remote call leg connection portion.

iv) Detection of a no-answer condition received from the remote call leg connection portion.

v) Detection that the remote party was not reachable.

– Propagation of a network release event as a result of the following events:

– Detection of a premature disconnect from the calling party.

– Receipt of a deassign() method.

– Receipt of a release() method from the application.

– Propagation of network release event as a result of a disconnect from the calling party .

– Detection of a network release event being a ‘terminating release’ indication as a result of a disconnect from the called party.

– Application activity timer expiry indicating that no requests from the application have been received during a certain period while processing is suspended for the leg.

7.3.2.3 Releasing (terminating) State

Entry events:

– Propagation ofa network release disconnect from the calling party.

– Detection of a network release event being a ‘terminating release’ indication as a result of the network release initiated by called party.

– Release of the entire call (e.g. after invoking IpCall.release())

– Sending of the release() method by the application.

  • A transition due to fault detection to this state is made when the Call leg object awaits a request from the application and this is not received within a certain time period.

– Detection of a network event being a ‘terminating release’ indication as a result of the following events:

i) Unable to select a route or indication from the remote party of the call leg connection cannot be presented (this is the network determined busy condition).

ii) Occurrence of an authorisation failure when the authority to place the call leg connection was denied (e.g. business group restriction mismatch).

iii) Detection of a route busy condition received from the remote call leg connection portion.

iv) Detection of a no-answer condition received from the remote call leg connection portion.

v) Detection that the remote party was not reachable.

– Propagation of a network release event as a result of the following events:

– Detection of a premature disconnect from the calling party.

Functions:

In this state the connection to the call party is released as requested by the network or by the application
and the reports are processed and sent to the application if requested .

When the Releasing state is entered the order of actions to be performed is as follows:

i) The release event handling is performed.

ii) The possible call leg information requested with getInfoReq() and/ or superviseReq() is collected and send to the application.

iii) The callLegEnded() method is sent to the application to inform that the call leg object is destroyed.

Where the entry to this state is caused by the application, for example because the application has requested the leg to be released or deassigned or a fault (e.g. timer expiry, no response from application) has been detected, then i) is not applicable. In the fault case for action ii) error report methods are sent to the application for any possible requested reports.

In this state the following functions are applicable:

  • The detection of a ‘Terminating Release’ trigger criterion.

– On receipt of the network release event being a ‘Terminating Release’ indication the following functions are performed:

– The network release event handling is performed as follows:

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event P_CALL_EVENT_TERMINATING_RELEASE then the event is reported and call leg processing is suspended.

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event P_CALL_EVENT_TERMINATING_RELEASE then the event is notified and call leg processing continues.

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event P_CALL_EVENT_TERMINATING_RELEASE then no monitoring is performed.

Note that this handling is not performed for propagated releases from the calling party.

  • Resumption of suspended call leg processing occurs on receipt of a continueProcessing() method.

– The possible call leg information requested with the getInfoReq() and/or superviseReq() is collected and sent to the application with respectively the getInfoRes() and/or superviseRes() methods.

– The callLegEnded() method is sent to the application after all information has been sent. In case that the application has not requested additional call leg related information the call leg object is destroyed immediately and additionally the application will also be informed that the connection has ended

– In case of abnormal termination due to a fault and the application requested for call leg related information previously, the application will be informed that this information is not available and additionally the application is informed that the call leg object is destroyed (callLegEnded) and the leg is released in the network.

NOTE: The call in the network may continue or be released, depending e.g. on the call state.

  • In case the release() method is received in Releasing state it will be discarded. The request from the application to release the leg is ignored in this case because release of the leg is already ongoing.

Exit events:

– In case that the application has not requested additional call leg related information the call leg object is destroyed immediately and additionally the application is informed that the call leg connection has ended, by sending the callLegEnded() method.

– After the sending of the last call leg information to the application the Call Leg object is destroyed and additionally the application is informed that the call leg connection has ended, by sending the callLegEnded() method.

– Application activity timer expiry indicating that no requests from the application have been received during a certain period while processing is suspended for the leg (re-enter releasing state).

– Receipt of a deassign() method. The leg will be released and call leg object destroyed, but no reports will be sent to the application anymore. Also no CallLegEnded will be invoked.

7.3.2.4 Overview of allowed methods and trigger events, Terminating Call Leg STD

State

Methods allowed

Idle

routeReq,

getCall ,
getCurrentDestinationAddress,
release,
deassign

eventReportReq,
getInfoReq,
setChargePlan,
setAdviceOfCharge,
superviseReq

Active

getProperties
setProperties
attachMediaReq
detachMediaReq
getCall ,
getCurrentDestinationAddress,
continueProcessing,
release,
deassign

eventReportReq,
getInfoReq,
setChargePlan,
setAdviceOfCharge,
superviseReq

Releasing

getCall ,
getCurrentDestinationAddress,
continueProcessing,
release,
deassign