Feature cheat sheet

B2BUA Instance SAS Support Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature Other notes

MMTEL

Yes

Terminating

  • SipAccess_SubscriberPreCreditCheck

  • SipAccess_PartyResponse

  • SipAccess_ServiceTimer

Yes

Yes, Active flag stored in the HSS

Stateless w/FSM in session state

POJO but with much stateful behaviour implemented by storing an FSM instance into session state

Raises session state flags to enable interaction with announcement playing (or other notification) features

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the mmtel-communication-waiting module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-cw-module opencloud#mmtel-communication-waiting#volte/4.0.0;4.0.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules:

Module Name Description

mmtel-communication-waiting

Group module for the feature that includes all of the modules listed below.

mmtel-cw-profile

Contains the profile specification for the feature configuration profile table.

mmtel-cw

Contains the feature itself.

Description

When a call arrives towards the destination user and the user is already involved in a call, the user is alerted and has a choice of either accepting, ignoring, or rejecting the communication. For example: the destination user is already on a call; notification for a new call is delivered; and the user can decide to put the existing call on hold or reject the new call.

A notification may be offered to the destination user if the network or UE has determined the Approaching Busy condition. Approaching Busy can be in the forms of:

  • Approaching Network Determined User Busy (A-NDUB) — the network (including the MMTEL AS) determines that the user is Approaching Busy, or

  • Approaching User Determined User Busy (A-UDUB) — the user equipment determines that the user is Approaching Busy.

This feature targets the IR.92 scope for Communication Waiting. Therefore, support for A-UDUB is included, and A-NDUB is not.

The calling user may be offered an in-band (audio) announcement, subject to network configuration.

Communication Waiting is a terminating feature.

User Determined User Busy (UDUB)

Communication arrived at the UE, and the UE has determined the Approaching User Busy condition, for any reason. For example, the user is on a call, and maximum number of waiting communications has been reached. The UE shall reject communication with an appropriate SIP response.

Approaching User Determined User Busy (A-UDUB)

Communication arrived at the UE, and the UE has determined Approaching User Busy condition, for any reason. For example, the user is on a call, and maximum number of waiting communications has not been reached. The UE shall reject communication with an appropriate SIP response.

Network data

Network operator data is stored in a JSLEE configuration profile with a profile table name of: MMTelCWConfigProfileTable.

Variable Name Type Constraint Default Default Value Interpretation Note
CWTimerCW

Integer

0, 30..120

0

Timer doesn’t apply

Time in seconds for Communication Waiting timer

CWAnnouncementID

Integer

0

CW calling user not notified

ID for an announcement to be played if Calling User Notifications are enabled

CWCallingUserNotification

Boolean

False

Do not notify the calling User

Session input variables

Field Type Default Interpretation Note
bxref:mmtel-subscriber-data-representation#mmtelcwservicedata[MMTelCWServiceData]

Complex

Read from the HSS or HLR in SubscriberDataLookupFromHSS or SubscriberDataLookupFromHLR

CWCallingUserNotification

Boolean

false

True

If calling user to receive announcement

Session output variables

Name Type Meaning
AnnouncementID

Int

The ID of the announcement to be played, or zero if no announcement if the feature did not request an announcement

CWAnnouncement

Boolean

If true, the MMTelCW feature has indicated that an announcement should be played. The AnnouncementID field will also be set if this flag is set. Otherwise no announcement should be played

RanCW

Boolean

Signals to other features that CW ran on this session.

If the calling user should be notified of an Approaching UDUB condition, the Communication Waiting feature sets the CWAnnouncement session state flag indicating that an announcement should be played. It also sets the AnnouncementID field, indicating that an announcement should be played.

Statistics

MMTelCW statistics are tracked by the sentinel.volte.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.volte.sip service → sentinel.volte.sip SBB → feature → MMTelCW
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.0.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.0.0].feature.MMTelCW"

Statistic Incremented when…​
 Started

the feature runs

 FailedToStart

Sentinel VoLTE encounters an error while attempting to start the feature

 IssuedWarning

a non-fatal problem is encountered and the feature issues a warning

 FailedDuringExecution

a fatal problem is encountered and the feature cannot execute correctly

 TimedOut

the feature takes too long to complete and Sentinel VoLTE aborts execution

 Misconfigured

a fatal error if the feature configuration can not be loaded

 TimerError

there is an error while trying to set a timer

 TimerCancelled

a timer is cancelled by the feature

 TimerSet

a timer is set by the feature

 ProcessingResponse

the feature is invoked on receiving a SIP response

 ProcessingTimerEvent

the feature is invoked on a timer firing

 OutgoingMessageContentChanged

the feature changes the contents of an outgoing SIP message

 ReattemptedCallSetup

the feature requests that call set up be reattempted

 Triggered180AUDUBResponse

the feature requests a 180 response be sent back to the original caller, indicating call waiting service

 PlayAnnouncementTriggered

the feature triggers an announcement to be played

 CancelledInviteRequest

the feature cancels an outgoing INVITE

 FinalResponseChangedTo486

the feature changes a SIP response status code to 486 before forwarding the response

 FinalResponseChangedTo480

the feature changes a SIP response status code to 480 before forwarding the response

FallbackToNetworkDefaultServiceConfig

incremented when the feature uses the network default service configuration as the session state does not contain the feature specific subscriber service data.

Feature interactions

When handling responses, CDIV No Answer and CDIV Busy must run after CW. CW may return a 480 (no answer condition) or 486 response (busy).

Behaviour

If MMTelCWServiceData.OperatorAuthorized or MMTelCWServiceData.Active is false, the feature finishes execution without modifying any state.

User equipment can signal an Approaching User Determined User Busy (A-UDUB) by placing certain headers in responses passed back.

The MMTelCW feature looks for these inside responses:

  • In the case of a 180-RINGING response to an initial INVITE, the response contains an Alert-Info header with the header’s value set to <urn:alert:service:call-waiting> if the UE wishes to communication A-UDUB.

  • In the case of a 486-BUSY response to an initial INVITE, the response contains a 370 warning header with the value set to insufficient bandwidth if the UE wishes to communicate A-UDUB.

As a simplification, consider Communication Waiting where there is no Announcement to the A-party. In this case, there are two main “modes of operation” for Communication Waiting:

  • a pure routing B2BUA that largely passes requests+responses between SIP dialogs

  • a routing B2BUA that initiates new transactions, sometimes acting like a UAC.

The differences in behaviour are best explained with a few key flows. In these flows we simplify the IMS signalling by showing three nodes, UE-A, the MMTEL-AS (AS), and UE-B.

180 Ringing Response handling

180 response — not due to A-UDUB

The 180 response from UE-B is forwarded onto the SIP dialog towards UE-A (that is, forwarded upstream).

180 response — due to A-UDUB

The CW feature forwards the 180 response upstream and arms a timer. If the timer fires before UE-B answers the call, the CW feature cancels the INVITE towards UE-B.

cw audub 180 timer cancel

486 Busy Response handling

486 response — not due to A-UDUB

The 486 response from UE-B is forwarded upstream.

cw no audub 486

486 response — due to A-UDUB

The 486 response indicates UDUB. The feature sends a 180-RINGING upstream indicating approaching-UDUB.

The AS then sends a new INVITE to UE-B. This new INVITE includes:

  • a MIME body according to the <communication-waiting-indication> element contained in the <ims-cw> root element

  • a content-type of application/vnd.3gpp.cw+xml.

An example is:

<?xml version="1.0"?>
<ims-cw xmlns="urn:3gpp:ns:cw:1.0">
    <communication-waiting-indication/>
</ims-cw>

The feature also starts a CW timer.

The following flow illustrates the signalling. In this example, the new INVITE is rejected.

cw audub 486 then rejected

Notifying the CallingParty of AUDUB via an in-band announcement

According to session output variables, the feature will set two session state fields to indicate that an announcement should be played.

The corresponding feature execution script can be written two ways:

run MMTelCW
run SIPPlayAnnouncement

This works because of a subtlety in SipPlayAnnouncement, it checks if the AnnouncementID field is not equal to zero.

However, the following is clearer and recommended:

run MMTelCW
if (CWAnnouncement) {
    run SIPPlayAnnouncement
}
Previous page Next page
Sentinel VoLTE Version 4.0.0