The event-processing model is the algorithm Sentinel uses to process events.

Event sources

Sentinel receives events from several sources:

Event source Received from Examples

SIP

an external SIP network element (such as an S-CSCF)

INVITE
SUBSCRIBE

HTTP

an external HTTP-enabled network element

an HTTP GET request that initiates a third-party call setup

Diameter

the Sentinel mediation layer (related to events from an external OCS)

Extension

external network elements for sessions initiated by features within Sentinel

Timer

timers that features raise using the ServiceTimerProvider

Local

raised internally by Sentinel, as a result of processing other events and instructions

EndSessionEvent, when the Sentinel session has ended (that is, no more SIP legs or charging instances remain active)

InstructionExecutionFailedEvent, when one or more event manager instruction failed during processing

LegEndEvent, when the Sentinel session continues, but one or more SIP legs have ended

What is an event manager?

While processing events, Sentinel delegates to and receives instruction from event managers. These are event-driven components that help process sessions within Sentinel. The most important event managers, from a feature-developer perspective, are:

  • Charging Manager — manages charging instances during the session

  • Leg Manager — manages all the SIP legs during the session.

An event manager is responsible for:

  • providing some core Sentinel behaviour

    For example: the Charging Manager manages all charging during the lifetime of the session; and the Leg Manager manages all the SIP legs during the lifetime of the session.

  • registering the set of events that the event manager should be triggered for

    For example, the Charging Manager is interested in events such as CreditControlAnswer, ReAuthRequest, and AbortSessionRequest.

  • determining the set of feature script execution points that are relevant for a particular event

    For example, the Charging Manager determines that the SipAccess_CreditAllocatedPostCC should be triggered when Sentinel receives a successful CreditControlAnswer in response to an initial credit reservation.

  • managing a set of pending instructions

    Note An “instruction” is a task that the event manager considers should be performed once all relevant feature script execution points have been processed.

    For example, the Charging Manager supports instructions such as CreditReservation, CreditFinalisation, and Refund. Instructions are queued as features execute, so a feature can make changes to the set of pending instructions.

Tip The Charging Manager and Leg Manager also provide an API for features to use. The actions features take may cause these managers to change their state (which includes adding, removing, and updating pending instructions). For example, a feature may create a new charging instance or create a new SIP leg.

Sentinel SIP event-processing algorithm

The following diagram is an overview of how Sentinel SIP processes events:

sip event model

As shown above:

1

Sentinel receives a real event, such as an INVITE request from the S-CSCF or a CreditControlAnswer from the Sentinel mediation layer. Sentinel starts an event loop:

Loop

Update Event Managers …​ Process Feature Script Execution Points …​ Process Event Manager Instructions

Until the local event queue is empty.

2

Event managers process the received event. They:

  • update their own state

    For example, the Leg Manager creates a new leg for an initial INVITE request; and the Charging Manager updates charging sessions on receipt of a CreditControlAnswer.

  • determine if one or more feature script execution points should be triggered for the event

    For example, the Leg Manager determines that the SipAccess_SessionAccept, SipAccess_SessionStart, SipAccess_NetworkCheck, SipAccess_SessionCheck, and SipAccess_SubscriberCheck execution points should be triggered in response to an initial INVITE request.

3

If there are any feature script execution points to trigger, then process them; otherwise see if event managers have any instructions to carry out.

4

Process each feature script execution point in turn. Features may update the state of the Charging and Leg Managers as they execute. For example, a feature might create a new SIP leg, or link two SIP legs.

Features may set timers or create sessions to external network elements. Related extension events and timer events may be received whilst Sentinel is processing feature script execution points.

Tip
See To learn how…​

Sentinel processes a feature script execution point

features may raise timers

features may receive extension events

Once all feature script execution points have been processed, then check if the event managers have any instructions to carry out.

5

Ask each event manager in turn to carry out any pending instructions that have accumulated while processing the event.

Each event manager manages a set of instructions while features are executing. For example, if a feature calls doRefund() on an ImmediateChargingInstance, then the charging instance will record a pending instruction of Refund.

Once all pending instructions have been processed, then see if there are any events in the local event queue. If the local event queue is empty, then wait for the next real event. Otherwise, de-queue a local event and process it.

6

Event processing ends once the session ends.
Previous page Next page