This feature updates session state when a session’s held status changes .
Feature cheat sheet
B2BUA Instance | Originating / Terminating | Point(s) in Session Plan | Network Operator Data | Subscriber Data | Stateful or Stateless | POJO or SBB Feature | Other notes |
---|---|---|---|---|---|---|---|
SCC |
Both Originating and Terminating |
SIP Mid Session Party Request, SIP Mid Session Party Response |
None |
None |
Stateless |
POJO |
Session input and output variables
Session output variables
Session State variable name | Type | Comments |
---|---|---|
HeldStatusChanged |
Boolean |
Indicates that the current message has changed the held status of the session. |
SessionIsHeld |
Boolean |
Indicates whether the session is currently on hold. |
LastActiveTime |
Long |
The time that the session last changed from held to active. |
LastHeldTime |
Long |
The time that the session last changed from active to held. |
Statistics
DetectHoldResume statistics are tracked by the volte.sentinel.sip SBB
and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → DetectHoldResume
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].feature.DetectHoldResume"
Name | Description |
---|---|
Started |
Incremented each time the feature runs |
FailedToStart |
Incremented when a fatal error occurs before feature execution |
IssuedWarning |
Incremented when a non-fatal error occurs during feature execution |
FailedDuringExecution |
Incremented when a fatal error occurs during feature execution |
TimedOut |
Incremented when feature execution does not complete within a reasonable time frame |
DetectSessionHold |
Incremented when the feature detects a transition from active to held |
DetectSessionResume |
Incremented when the feature detects a transition from held to active |
Behaviour
The DetectHoldResume
feature updates session state when the session’s held status changes.
The feature runs on the SIP Mid-Session Party Request and SIP Mid-Session Party Response execution points. If a message containing an SDP offer arrives, the SDP is compared to the session’s previous SDP.
The feature looks for changes in directionality attribute in the session description, for example a=sendrecv
or a=sendonly
,
to determine if the session is being put on hold or resumed.
If the held status has changed, session state is updated with the new held status.