Feature cheat-sheet

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




  • SipAccess_PartyRequest

  • SipAccess_PartyResponse

  • SipAccess_SubscriberCheck

  • SipAccess_ServiceTimer

  • SipMidSession_PartyRequest

  • SipMidSession_PartyResponse

  • SubscriptionSipRequest

  • SubscriptionSipResponse

  • SipMidSession_CreditAllocatedPostCC

  • SipMidSession_CreditLimitReachedPostCC

  • SipMidSession_OCSFailurePostCC

  • SipLegEnd

  • SipEndSession




SBB with multiple FSMs encoded into session state

Subscriber data

Not applicable; the feature is generally available unless disabled at the network level.

Network data

Data is stored in the MMTelCONFConfigProfileTable profile.

Parameter Type Description Default Note


SIP or TEL URI for the MRF




SIP or TEL URI for the I-SCSCF


Mandatory when the IsMrfRoutableViaIMS option is set to True.



Set of non-standard SIP or TEL URI that are recognised as a conferencing factory PSI



Integer {0, 3, or greater}

Maximum number of participants; 0 = disabled




Allow other conference participants to cascade conferencing


Reserved. Current implementation ignores it. Cascading is not explicitly disabled.



Removal delay for cleaning up the conference view state in Cassandra once the conference has ended.


Delay allowing all outstanding conference subscriptions to end



Policy setting that allows a video conference to be created or not




Policy setting that specifies if calls to the MRF should be routed via IMS


If set to true, then the ICSCFURI has to be set



Indicates whether or not to add the orig URI parameter to the Route header for initiating calls to participants




Decides whether the 'root' element will be a child of the 'selector' element, otherwise will be a child of 'videolayout'




Bandwidth value to be used as an attribute of the 'root' element if not specified in INVITE SDP


Required for integration with Radisys MRF



Mpi value to be used as an attribute of the 'root' element if not specified in INVITE SDP


Required for integration with Radisys MRF



Bpp value to be used as an attribute of the 'root' element if not specified in INVITE SDP


Required for integration with Radisys MRF



Framesize value to be used as an attribute of the 'root' element if not specified in INVITE SDP


Required for integration with Radisys MRF



ProfileLevelId value to be used as an attribute of the 'root' element if not specified in INVITE SDP


Required for integration with Radisys MRF


Feature name


Applicable contexts

SIP service

Prerequisite features

This feature allows a user to create a multi-party session between two or more parties. The feature is initially triggered when a subscriber (conference moderator) makes a call to the conference factory PSI that points towards a media server (MRFC/MRFP). Subsequently, the conference moderator joins one or more participants into the conference by creating a call leg between the media server and every participant. For every participant added to the conference the feature instructs the media server to join (or mix) media of the new participant with the conference session media. The feature enables n-way voice communication between all conference participants by mixing media from each participant session.

Conference moderator is a special role that allows adding and removing participants to and from a conference. Charging is correlated to the moderator session. Accordingly, all participants' sessions are terminated when the moderator disconnects.

The MMTel Conference View Update feature maintains a representation of the conference view state in Cassandra. This is then read by the MMTel Conference Subscription feature. Together these features render the conference state to arbitrary endpoints subscribed to the conference event package.

Specification compliance

Conferencing between three participants

three party conference

Conference setup begins when the conference moderator establishes a session with the media server using the conferencing feature. Although not strictly a precondition, the conference moderator would have established sessions with party B and C (dialogs x and y). These are established outside the scope of the conferencing feature. The moderator dials a destination that is translated into a conference factory URI by the feature, and routed to the media server.

Additionally, when the moderator sets up a connection to the media server, the feature allocates a conference focus URI. It is an opaque SIP URI that identifies the conference instance, and essentially the multi-party session. The conference focus URI is used as a SIP target by all participants including the moderator for all subsequent SIP messaging.

Having set up the initial connection, the conference moderator creates a conference object and begins adding participants to the conference. It is a multi-step process that involves setting up new sessions with the new participants and interaction with the media server, using the MSML protocol over SIP/INFO as the protocol transaction transport. See Interaction with Media Server for details.

Three-party conference setup overview

When the moderator establishes the session with the media server (control connection) the conferencing feature:

  • creates the MSML conferencing object and the first MSML connection for the moderator.

The moderator can then join a participant by creating a SIP REFER transaction on dialog A, where the REFER request has a Refer-to header with a URI header Replaces that references an existing call x between the moderator (user A) and prospective participant (user B).

The conferencing feature then:

  • acknowledges the REFER request with a 202 response

  • performs a charging authorization check

  • if charging authorization check is successful, creates and links two SIP sessions:

    • the conferencing server and the media server (dialog B1)

    • the new participant and the conferencing server (dialog B)

Note After dialog B has been successfully created, the corresponding call x is terminated by the UA of the user B, as a part of processing of the INVITE request with the Replaces header copied from the corresponding REFER request.
  • re-uses the MSML conferencing object, and joins the participant into the conference.

Once successful, the first two participants are joined into the conference. Adding subsequent participants is an identical process.

three party conference sequence

Routing SIP traffic towards Media Server (MRF) through the IMS

The MMTelCONF feature may directly contact a Media Server/Media Resource Function. This means that any INVITE from the feature is sent directly to the MRF. The Request URI of the outbound INVITE is set to the URI of the MRF.

This feature also supports routing INVITEs destined for the MRF through the IMS. In order to route through the IMS, the network configuration attribute IsMrfRoutableViaIMS must be set to true in the MMTelCONFConfigProfileTable

When this attribute is set to true and the initial INVITE from the conference moderator is received via the S-CSCF, the feature stores the Record-route SIP URI in the Session State attribute named SCSCFRouteAddress. In order to route the INVITE through the IMS, the feature retrieves the SIP URI (of the S-CSCF) from Session State, and places it as the topmost route header of the outbound INVITE.

The feature will also add a header parameter specified in configuration attribute RouteOrigUrlParameter to the Route header. For example, if parameter is set to value "orig" it will enable originating services to be run on outbound sessions from the conference server towards the conference participants.

Conference media

Every conference participant establishes signalling and media sessions with Media Server. Media Server performs mixing of media of all participants and enables all participants to hear each other (audio conference) and see each other (video conference).

Conference audio mixer

Loudest participants Optional MSML element <n-loudest> determines the number of participants from which audio is mixed based on their audio energy. MMTelCONF doesn’t define this element and relies on the default behaviour that causes Media Server to mix audio from all participants.

Audio sampling rate

Optional attribute samplerate determines the sample rate for the audio mixer. MMTelCONF doesn’t define this attribute leaving to the default 8000 kHz.

Active speaker notification

Active speaker notification enables active speaker to be notified with appropriate type of MSML event. MMTelCONF doesn’t define this attribute leaving to the default behaviour where notification is not supported.

DTMF and in-band tone clamping

When enabled Media Server blocks DTMF and in-band tones from being mixed. MMTelCONF doesn’t define this attribute leaving to the default where clamping is not performed.

Video layout

MMTelCONF implements a simple video layout where a single region over the root window displays the most active speaker. The same video output is offered to all conference participants.

Video resolution

Range of video resolutions are supported and configurable at a feature level. Media Server must support the values configured.

Abbreviation MSML schema v1.1 compliant Value Note



352 × 288

Supported; Default



176 × 144




704 × 576

Not supported



1408 × 1152

Not supported



128 × 96

Proprietary support only



640 x 480

Proprietary support only



320 x 240

Proprietary support only



1280 x 720

Proprietary support only



960 x 720

Proprietary support only

Degrading from and upgrading to video media

Video conference is triggered when:

Video conferencing is administratively enabled (IsVideoConferenceAllowed=true), and Conference moderator makes a video media offer that is acceptable to Media Server If one of these preconditions is not met the conference shall have only audio media mixed irrespective if all or some participants have successfully negotiated video session with Media Server. This is because the feature will not instruct the Media Server to mix video media.

When the feature has determined a video conference session state field IsVideoConference will be set to true. The conference will remain marked as video conference regardless of whether some or all participants downgrade their media to audio only.

If a conference has been determined as a video conference any one participant including the moderator can downgrade/upgrade the media to/from video by sending re-INVITE with video media description IP port set to zero (downgrade) or non-zero (upgrade). Alternatively, conference participant can re-INVITE with video media description excluded or included achieving the same result.

Video only conference

Video only communication may occur on any one participant leg provided this is acceptable to both Media Server and the participant. Video only communication can occur when a participant or media server didn’t have matching audio codecs or have mismatching parameters.

Terminating conference

The conference is considered to be terminated when the conference moderator, either:

  • has disconnected, which will trigger the feature to remove all remaining participants

  • is the last participant remaining after all other participants have disconnected.

Removing participants

The conference moderator can eject any participant at will by creating a REFER transaction with a request that contains a Refer-to header with a URI parameter method=BYE and a URI referencing the participant to be ejected. This feature removes the participant by terminating both call legs for that participant.

Re-INVITE Based Three-party conference setup overview

There is an alternative flow when setting up a conference. Under this flow, participants receive a re-INVITE on the consulting call rather than an INVITE with Replaces. This means that releasing the consulting call between the moderator and the participant is now the responsibility of the AS, rather than the UE.

In order for the re-INVITE based flow to function:

  1. SCC Conference Handling configuration must be toggled on (set the EnableSCCConfHandling attribute to true)

  2. originating and terminating SCC-AS must be implemented

  3. the INVITE with Replaces sent by conferencing must trigger originating SCC processing

  4. all sessions are subject to Session Tracking (this is automatically enabled when the EnableSCCConfHandling attribute is set to true)

Once the requirements are met the originating SCC-AS can implement the re-INVITE based flow. For a reference to the features used to implement this in the SCC-AS please refer to Reuse of access transfer procedures for conferencing. Configuration and flows for this capability are described in the following portion.

The MMTel Conference feature uses the X-MSW-Original-Refer-To header in preference to the Refer-To header in the Re-INVITE based conference setup. This is to facilitate conference moderator Access Transfer where an originating SCC-AS must be present between the moderator UE and the call to the Conference Factory.

SCC Conference Handling Configuration

SCC Conference handling configuration data is stored in the SCCConfHandlingConfigProfileTable profile table. Each profile is scoped according to a Sentinel Selection Key and by default there is one profile in the table. Each profile contains the following attributes.

Parameter Type Description Default Note


Enables SCC conf handling




Enables codec dropping on clash


During conferencing, different commponents can end up assigning the same payload type to different codecs. This results in a clash. When this attribute is set to true, the feature will drop the clashing codecs from outgoing SDP. When set to false, the feature will disable the original media description and append the new media in the next available position. See SDP Conflict Management for more information.


The first flow shows standard treatment where the INVITE with Replaces is passed and translated all the way through to the participant.

scc orig conference invite with replaces no orig conf trigger

The second flow shows the re-INVITE based alternative enabled by the originating SCC where the INVITE with Replaces is converted to a re-INVITE on the participant’s consulting call.

scc orig conference invite with replaces scc orig reinvite

Interaction with MMTel Conference View Update and Subscription feature

Both the MMTel Conference View Update feature and MMTel Conference Subscription feature ensure the UE remain informed of the conference state throughout the call (joined participants, participant status etc.). The MMTel Conference View Update feature reads the conference state from session state fields updated by the MMTel Conference feature and writes this state to a table in Cassandra. It gets executed following each invocation of the MMTel Conference feature, ensuring that any time the conference state is modified, a corresponding update is also made to the view state in Cassandra. The MMTel Conference Subscription feature then polls the conference state in Cassandra periodically, notifying subscribers of any state changes.

The ConferenceViewRemovalDelay in the MMTel Conference feature’s configuration provides a mechanism to allow all subscription sessions associated with the MMTel Conference Subscription feature for the ended conference to complete before the conference state is cleaned up in Cassandra.

Conference Privacy

During a standard conference call, outbound INVITEs to conference participants after the REFER message include a Referred-By header with the conference moderator’s SIP identity.

If the conference moderator includes a Privacy header with value User or Header in either the initial INVITE to the conference focus or the REFER message to participants, then the Referred-By header is excluded from the INVITE to participants.

If the moderator or participants include a Privacy header with value Id or User, then the subscriber’s identity in conference subscription notifications is anonymized.

Feature interaction

An initial INVITE with a Replaces header must be exempted from processing by a feature that performs call re-targeting, call barring, call rejection, or early session announcements.


Online charging uses a single OCS session for all legs of the conference:

  • The OCS Session begins when the conference creator sets up a call with the conference server (MT instance).

  • A credit check is performed before each participant is joined (event-based charging).

  • A credit check/reservation is performed on the MO instance of every participant leg.

  • The icid value of the P-Charging-Vector header in the received INVITE from the conference creator is copied into the P-Charging-Vector of every INVITE sent towards a participant, as a way of charging correlation.

Inputs and outputs

Session state and leg manager data


Name Type Format Description Behaviour if null/invalid Note

Sentinel Selection Key


selection key (for example, <platform>::::)

For selecting configuration data

Feature not executed

Session State Data

Conference Factory PSI



The conference factory PSI used for this session


Session State Data set by feature DetermineVoltePlanId

Sentinel Script Execution Point

enum com.opencloud.sentinel.feature.SipFeatureScriptExecutionPoint

Determination of context of execution, such as credit check, early session, mid-dialog session

No execution

Session State Data

Call Type

enum com.opencloud.sentinel.common.CallType

Determination of context of execution, such as MobileTerminating


Session State Data

Call Leg


Determination of leg that receives an event

Call terminated

Leg Manager API



Read from the HSS or HLR in SubscriberDataLookupFromHSSor SubscriberDataLookupFromHLR

Feature not executed

Session State Data


Name Type Format Description Note


A 16-character alpha-numeric string prefixed with mmtel-conf-

Generated by the feature when setting up moderator connection




URI derived from conference ID used to address the conference UA instance, such as <sip:mmtel-conf-VdvxbG3LUjb-CzwXAHnCqQ@;oc-node=101;lr>;isfocus

Session State Data



Control leg name, participant side

Session State Data



Control leg name, Media server side

Session State Data


com.opencloud.volte.sentinel.mmtel.feature.conf MMTelCONFConnectionRequest

Value object that represent request data and state of processing for joining a new participant; request that is being processed currently

Session State Data


com.opencloud.volte.sentinel.mmtel.feature.conf MMTelCONFConnectionRequestQueue

Pending requests to join new participants

Session State Data


com.opencloud.volte.sentinel.mmtel.feature.conf MMTelCONFConnectionRequestQueue

Requests for which media bridging is in progress (MSML transaction is in progress)

Session State Data


com.opencloud.volte.sentinel.mmtel.feature.conf MMTelCONFConnectionRequestQueue

Value objects that represent that participants that have been joined into conference including those already disconnected

Session State Data


com.opencloud.volte.sentinel.mmtel.feature.conf VideoConferencePolicyType.VideoConferenceResolution

Value to represent the video conference resolution used for control MRF session

Session State Data



Bandwidth value to use for control MRF session

Session State Data



Mpi value to use for control MRF session

Session State Data



Bpp value to use for control MRF session

Session State Data



Framesize value to use for control MRF session

Session State Data



Profile-level-id value to use for control MRF session

Session State Data



Codec value to use for control MRF session

Session State Data

Execution of this feature can also affect the conference view during execution if a participant is added or their status has changed.


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

Statistic Incremented when...

the conference feature runs


the main conference FSM reaches its end state


Sentinel VoLTE instructs the conference feature to abort execution


a non-fatal error occurs while attempting to read the information in a SIP message


a problem occurs while trying to access a SIP leg or message


a BYE request is received on an active (join operation complete) participant connection


a BYE request is received on an inactive (join operation incomplete) participant connection


a BYE request is received on an active (join operation complete) media server connection.


a BYE request is received on an inactive (join operation incomplete) media server connection


a problem occurs while trying to load the conference feature’s network-level configuration data


a fatal error occurs in the core conference feature FSM


a fatal error occurs in the conference feature’s non-control connection management FSM


a non-control connection is successfully established between a conference participant and the MRF


a non-control leg to the MRF is successfully established


a fully established non-control conference connection is terminated


the conference feature triggers a credit check


a participant has indicated that they support video in an SDP answer


a fatal error occurs in the conference feature’s control connection management FSM


a control connection is successfully established between a conference moderator and the MRF.


a fully established conference control connection is terminated.


a badly formed REFER request is received from the conference moderator.


a NOTIFY is queued on the control connection


a NOTIFY is sent to the conference moderator


the moderator has indicated they want privacy applied to the outgoing INVITE


the moderator sets the conference up as a video session


the feature makes a call to the MRF via the S-CSCF

Error scenarios

Scenario Handling

Second initial request received towards conference PSI

Report featureFailedToExecute

Non MT request received by conference PSI

Report featureFailedToExecute


This feature uses two different sets of mappers that conform to:

Mapping Mapper Execution Point

MMTelCONFConfigWrapper.class → CreateConferenceMSML.class

MMTelCONFConnectionRequestQueue.class → JoinConferenceMSML.class

IncomingSipResponse.class → ResponseMSML.class

Mapper Configuration

As mentioned in the previous section this feature uses two different sets of mappers. The set to configure depends on the media server in use with the feature. Configuring mappers can be done in the SentinelMapperSetEntryTable. The following yaml excerpts outline which profiles should be configured for each vendor.


        MapperSetName: '${platform.operator.name}:'
        SessionType: sipcall
        PlanId: ''
        MapperExecutionPoint: ''
        MappingName: MMTelConfMSML-CreateConference-Dialogic
        MapperSetName: '${platform.operator.name}:'
        SessionType: sipcall
        PlanId: ''
        MapperExecutionPoint: ''
        MappingName: MMTelConfMSML-JoinConference-Dialogic
        MapperSetName: '${platform.operator.name}:'
        SessionType: sipcall
        PlanId: ''
        MapperExecutionPoint: ''
        MappingName: MMTelConfMSML-Response-Dialogic


        MapperSetName: '${platform.operator.name}:'
        SessionType: sipcall
        PlanId: ''
        MapperExecutionPoint: ''
        MappingName: MMTelConfMSML-CreateConference-Radisys
        MapperSetName: '${platform.operator.name}:'
        SessionType: sipcall
        PlanId: ''
        MapperExecutionPoint: ''
        MappingName: MMTelConfMSML-JoinConference-Radisys
        MapperSetName: '${platform.operator.name}:'
        SessionType: sipcall
        PlanId: ''
        MapperExecutionPoint: ''
        MappingName: MMTelConfMSML-Response-Radisys

Feature responses

Response Reason

Max number of participants < 3, or MMTelCONFServiceData.OperatorAuthorized is false.


Multiple initial requests or non MT initial request received towards conference PSI


Feature has finished

Configuration profile naming

Configuration Profile Table Name Description Profile Naming

See Network Data for a detailed description of parameters

gxref:<{sentineldocgxref}>sentinel-overview-and-concepts/sentinel-selection-key[Sentinel Selection Key^]

Example configuration for conference feature where localhost:5260 is the address of the MMTel TAS:

ConfFactoryPSI ConfMaxParticipants ConfCascadingEnabled ConferenceViewRemovalDelay

Conference event package

A UE may attempt to subscribe to notifications for the conference event package. Subscriptions for the conference event package are handled by the MMTel Conference Subscription.

Provisioning interfaces

The feature is provisioned using the Sentinel REST API or web interface.

Previous page Next page
Sentinel VoLTE Version 4.1