The Communication Waiting (CW) service lets a UE be informed that no resources are available for an incoming communication . The user then has the choice of accepting, rejecting, or ignoring the incoming communication (as per basic communication procedures).
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 |
|
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 |
FinalResponseChangedTo486 |
the feature changes a SIP response status code to |
FinalResponseChangedTo480 |
the feature changes a SIP response status code to |
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-RINGINGresponse to an initialINVITE, the response contains anAlert-Infoheader 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-BUSYresponse to an initialINVITE, the response contains a370warning header with the value set toinsufficient bandwidthif 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
486 Busy Response handling
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.
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
}
