3GPP specification

3GPP define a specification for the Communication Hold supplementary service running in the IMS, in 24.610.

CommunicationHold feature

OpenCloud’s CommunicationHold feature implements the capability of holding and resuming a session, according to the 3GPP spec.

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

MMTEL

Both Originating and Terminating

  • SipMidSession_PartyRequest

  • SipMidSession_PartyResponse

Yes

No

FSM state

POJO with FSM encoded into Session State

Prerequisite features

  • DetermineInitialLegNames

Source Code

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

> create-module new-hold-module opencloud#mmtel-communication-hold#volte/2.7.0;2.7.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-hold

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

mmtel-hold-profile

Contains the profile specification for the feature configuration profile table.

mmtel-hold

Contains the feature itself.

In scope

  • Hold/resume an established session

  • Adjusting bandwidth of responses to the Holding INVITE transaction

  • Interaction with MidCallPlayAnnouncement

XCAP provisioning

There is no XCAP Provisioning for Hold/Resume.

Subscriber data

There is no subscriber data.

Network operator data

Network operator data indicates:

  • whether or not bandwidth should be adjusted

  • what we should set each bandwidth attribute to

  • whether or not an announcement should be played to the held party.

Network operator data is in a JSLEE configuration profile table: MMTelHoldConfigProfileTable.

This data is scoped by Sentinel selection key.

Each configuration has its own profile in this profile table.

Attribute Name Type Description 
CHoldAdjustBandwidth

Boolean

Indicates whether or not (true/false) Communication Hold should lower or increase the bandwidth of responses during sessions being Held and Resumed.

 
CHoldB_AS

int

The value of this attribute corresponds to the value for the b=AS: parameter to use when processing a Hold response.

 
CHoldB_RR

int

The value of this attribute corresponds to the value for the b=RR: parameter to use when processing a Hold response.

 
CHoldB_RS

int

The value of this attribute corresponds to the value for the b=RS: parameter to use when processing a Hold response.

 
CHoldPlayAnnouncement

Boolean

Indicates whether or not (true/false) Communication Hold requests an Announcement to be played when a session is held.

 
CHoldAnnouncementID

int

The announcement ID to be used when an announcement is requested

Defaults for network operator data

Attribute name Default Value Meaning 
CHoldAdjustBandwidth

false

Hold does not adjust bandwidth

 
CHoldB_AS

0 (zero)

If CHoldAdjustBandwidth is true, b=AS: is set to this value

 
CHoldB_RR

800

If CHoldAdjustBandwidth is true, b=RR: is set to this value

 
CHoldB_RS

800

If CHoldAdjustBandwidth is true, b=RS: is set to this value

 
CHoldPlayAnnouncement

false

Hold does not request an announcement is played

 
CHoldAnnouncementID

0 (zero)

The announcementID of zero is a special ID meaning no announcement is to be played

Session input variables

There are no session input variables.

Session output variables

Attribute Name Type Comments 
RequestingLegCSeq

string

 
RespondingLegCSeq

string

 
AnnouncementID

int

 
MidCallAnnouncementPlayedParty

An enum with two fields: CallingParty and CalledParty

 
RanHOLD

Boolean

Signals to other features that HOLD ran on this session.

MidCallAnnouncementPlayedParty

package com.opencloud.sentinel.feature.announcement.midcall;

public enum PlayedParty {
    CallingParty, CalledParty
}

Statistics

MMTelHOLD statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB.

Statistic Incremented when…​ 
MMTelHoldFeatureStarted

the feature runs

 
MMTelHoldFeatureFailedToStart

sentinel VoLTE encounters an error while attempting to start the feature

 
MMTelHoldFeatureIssuedWarning

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

 
MMTelHoldFeatureFailedDuringExecution

a fatal problem is encountered and the feature cannot execute correctly

 
MMTelHoldFeatureTimedOut

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

 
MMTelHoldFeatureProcessingRequest

the feature is invoked on receiving a SIP request

 
MMTelHoldFeatureProcessingResponse

the feature is invoked on receiving a SIP response

 
MMTelHoldFeatureSipDataAccessError

an error occurs while trying to access a SIP leg or message

 
MMTelHoldFeatureSipMessageSDPUpdated

the feature changes the SDP content in a SIP message

 
MMTelHoldFeatureReceivedHoldRequest

the feature determines that an incoming message is a hold request

 
MMTelHoldFeatureReceivedResumeRequest

the feature determines that an incoming message is a resume request

 
MMTelHoldFeatureSessionBandwidthAdjusted

any bandwidth information is adjusted in an SDP body

 
MMTelHoldFeatureMediaStreamBandwidthAdjusted

bandwidth information is adjusted on a SDP media stream description

 
MMTelHoldFeatureMissingDataWarningTriggered

an operation on SDP data fails due to the data being unavailable

 
MMTelHoldFeatureReceivedMalformedMessage

the feature determines that an incoming message is mal formed

 
MMTelHoldFeaturePlayAnnouncementTriggered

the feature determines triggers the play announcement

Terminology

The UE invoking Hold/Resume is referred to as the invoking party.
The AS of this UE is referred to as the AS of the invoking party.

The UE that is being held/resumed is referred to as the receiving party.
The AS of this UE is referred to as the AS of the receiving party.

The invoking party makes an SDP offer. The receiving party responds with a SDP answer or rejects the offer with an error response. For each party, the SDP offer and corresponding answer from the other party need to be stored by the AS. The AS (B2BUA) refers to these as :

  • In the B2BUA instance of the invoking party:

    • local SDP offer from the invoking party

    • remote SDP answer from the receiving party

  • In the B2BUA instance of the receiving party:

    • remote SDP offer from the invoking party

    • local SDP answer from the receiving party.

THe SDP offer and answer are accompanied by sdp-session-id and sdp-session-version. Specifications mandate these parameters to change when the SDP changes.

Behaviour

General behaviour for the MMTEL AS for the invoking UE:

  • detecting if a Hold or Resume transaction is taking place:

    • The session-id or session-version of the SDP offer for the local or remote party has changed and follows the HOLD request rules:
      (sendrecv → sendonly, recvonly → inactive)

    • The session-id or session-version of the SDP answer for the local or remote party has changed and follows the HOLD request rules:
      (sendrecv → recvonly, sendonly → inactive)

  • adjusting SDP bandwidth parameters in an offer and answer to reflect increased or reduced bandwidth demand.

How these simple goals are achieved is the subject of the rest of the behaviour description.

B2BUA instances and invoking UE

When the call is first set up, the AS of each party stores local and remote SDP offers and answers. That is, the AS of calling party that makes the SDP offer stores the current set of local SDP offers and remote SDP answers (see Behaviour).

When the originating party is the invoking party (that is, the originating party performs HOLD) then the originating B2BUA instance is active and the terminating B2BUA instance is passive for this request and its associated response.

When the terminating party is the invoking party (that is, the terminating party performs HOLD) then the terminating B2BUA instance is active and the originating B2BUA instance is passive for this request and its associated response.

Request processing

If the request is not a Re-INVITE, the feature finishes execution without modifying any state.

The feature determines if it is active or passive for a particular request.

If it is passive, it forwards the request upstream.

If it is active, it classifies the following:

  • Session Refresh or not.

    • If Session Refresh, the feature finishes execution.

    • Otherwise, it classifies if the Re-INVITE should be an Op or a No-op.

      • If No-Op, it forwards the request.

      • Otherwise, if Op, it sets the session state field HoldResumeResponseIsOp to TRUE; then forwards the request.

Distinguishing hold requests from session refreshes

The AS of the invoking user stores the SDP session ID and version of the last successful offer or answer received from the invoking user. If a Re-INVITE received from the invoking user has both parameters unchanged, the Re-INVITE is a session audit (that is, session timer refresh). If either the session ID or version has changed, the SDP of the request must be inspected.

If the SDP session ID and session version are the same, then the Re-INVITE request represents a session refresh.

In case of a session refresh, both the originating and terminating B2BUA instance are passive.

Behaviour if the request is a session refresh

The feature does not alter any state, and finishes execution.

Hold request Op or No-op in the context of no announcements

Hold requests may be treated as an Op (short for Operation) or a No-op (short for No-Operation).

  • If a request is classified as a No-op request, then the request is passed through as is, and its associated response is passed through as is.

  • If a request is classified as an Op request, then the response’s bandwidth may be adjusted before being passed to the invoking UE.

  • If the B2BUA instance is passive for a given request, then the request is always classified as a No-Op.

  • If the B2BUA instance is active for a given request, then the request will be classified as either a No-Op or an Op.

If all of the streams within a request are treated as Stream No-Op, then the request is treated as a No-op request.

The following table shows how each stream within a request is treated as a No-Op or as an Op.

Most |normal case tables are taken from actions at the invoking UE 4.5.2.1

UE intention Current Stream State Requested State for Stream Stream Op or Stream No-Op Comments

Hold a media stream

stream is sendrecv (assume this means both UEs are in sendrecv)

UE1 sends offer sendonly, UE2 responds with recvonly

Op for B2BUA serving UE1,
No-Op for the other B2BUA

normal case for Hold where the session was fully active in both directions

Hold a media stream

stream is recvonly (assume this means UE1 is sendonly and UE2 is recvonly)

UE2 sends offer inactive, UE1 responds with inactive

Op for B2BUA serving UE2,
No-Op for the other B2BUA

normal case where your UE got put on hold and you want to put the other on hold

Resume a media stream

stream inactive (assume this means both UEs are inactive)

UE1 sends offer recvonly, UE2 responds with sendonly

Op for B2BUA serving UE1,
No-Op for the other B2BUA

normal case where both UEs had held each other, and one UE wants to resume

Resume a media stream

send only (assume this means UE1 is recvonly and UE2 is sendonly

UE2 offers sendrecv, UE1 response with sendrecv (or omitted because sendrecv is default)

Op for B2BUA serving UE2,
No-Op for the other B2BUA

normal case where stream is held by one UE, and it wants to be resumed

Hold all media streams using session-level direction attribute in SDP

media streams are sendrecv

UE1 sends SDP where session-level direction attribute is set (with new session version) with offer of sendonly, UE2 responds with session-level direction of recvonly

Op for UE1s B2BUA,
No-Op for other

normal case where all streams are to be held, and some are sendrecv

Hold all media streams using media-level direction attribute in SDP

at least one of the sessions media streams are in sendrecv

UE1 sends SDP with N direction attributes set to sendonly …​ (1 per media stream that is set to sendrecv), UE2 responds with recvonly at media level for each stream

Op for Invoking UE’s B2BUA,
No-Op for other

normal case where all streams are to be held, and some are sendrecv

single SDP offer can be sent combining this row and the next row

Hold all media streams using media-level direction attribute in SDP

at least one of the sessions media streams are in recvonly

invoking UE sends SDP with M direction attributes (1 per media stream that is set to recvonly), Other UE responds with inactive for each media stream

Op for invoking UE’s B2BUA,
No-Op for other B2BUA

normal case where all streams are to be held, and some are in recvonly

single SDP offer can be send combining this row and the previous row

Resume all media streams using session-level direction attribute in SDP

media streams are in inactive

invoking UE sends SDP offer where session-level direction attribute is recvonly, other UE responds with session-level direction attribute set to sendonly

Op for invoking UE’s B2BUA,
No-Op for other

normal resume-all case where media was inactive

Resume all media streams using session-level direction attribute in SDP

media streams are in sendonly

invoking UE sends SDP where session-level direction attribute is sendrecv (or this attribute is omitted as sendrecv is the default), other UE responds with session-level direction attribute of sendrecv (or attribute is omitted as this is the default)

Op for invoking UE’s B2BUA,
No-Op for other

normal resume-all case where session was held in one direction only, and the held UE wants to resume

Resume all, using Media level SDP

several possible states, one for each media stream; also similar to Hold all where there are different streams in different states

similar to the hold all cases, except the offer is to resume; that is, the media attributes are set to recvonly (if previously inactive), or sendrecv if previously sendonly

Op for invoking UE’s B2BUA,

No-Op for other normal resume-all case where some sessions are held and others aren’t

Response processing

If the response is not a response to a Re-INVITE, the feature finishes execution without modifying any state.

When processing a response, the feature detects if it is active or passive for the response.

  • Read the session state field HoldResumeResponseIsOp.

  • If TRUE, process the response in active manner

    • If the response is a final response (a 2xx or 4xx. response) set the session state field HoldResumeResponseIsOp to FALSE.

  • If FALSE, process the response in passive manner.

Passive processing of response

When processing the response (SDP answer) in a passive manner, the feature forwards the response without modifying it.

Active processing of response

If the Network Data’s AdjustBandwidth attribute is set to False, the feature then finishes execution without modifying any state.

Otherwise the following steps are then performed:

  • walks through each media stream in the answer, that is held

  • checks to see if the media stream is marked as recvonly, and if so (as a network option) performs the following on each held media stream:

    • lowers the bandwidth of the invoking UE (the UE that sent the SDP offer) to a small value, by setting the b=AS: parameter (for example, setting b=AS:0).

The b=RR: and b=RS: parameters are set to values large enough to enable continuation of the RTCP flow; for example, b=RR:800 and b=RS:800.

The values to be used for b=AS:, b=RR:, and b=RS: parameters are found in the network configuration’s B-AS, B-RR, and B-RS attributes respectively.

The adjusted response is then forwarded onwards.

Background on SIP Sentinel and SDP negotiation

Sentinel stores the current set of SDP offers and answers along with the sdp-session-id and sdp-session-version for the offers and answers (this is accessible through the Leg API). When a SIP dialog is set up (whether early or confirmed) the set of (local|remote)(offer, sdp-session-id, sdp-session-version) and (local|remote)(answer, sdp-session-id, sdp-session-version) are recorded.

When SDP is updated by means of n UPDATE or Re-INVITE transaction, the session-id and session-version will change. If the session-id and session-version remain unchanged ,this indicates the media is unchanged (this is typically a session refresh).

While a transaction is in progress, the current SDP offer and answer is available in the “latest” SDP pair.

Upon successful SIP transaction completion, the latest SDP offer and answer are copied into the “committed” set.

Upon transaction failure, the committed set is not modified.

Previous page Next page
Sentinel VoLTE Version 2.7.0