These features are MMTel specific.
| Feature | What it does |
|---|---|
a logical representation of supplementary service data as a group of POJO objects. It allows MMTel services/features to execute independently of any concrete schema for the supplementary service data. Therefore it can be loaded from the HSS or the HLR using the MMTel-Services XML schema or 3GPP MAP ASN.1 schema. |
|
lets users create multi-party sessions between two or more parties |
|
provides a means for UEs to subscribe to “conference” event package notifications for a conference |
|
enables a ‘diverting user’ to divert communications addressed to the ‘diverting user’ to another destination |
|
lets a UE be informed that no resources are available for an incoming communication |
|
lets a user suspend reception of the media stream(s) of an established IP multimedia session, and resume the media stream(s) at a later time |
|
implements incoming communication barring and anonymous communication rejection |
|
implements outgoing communication barring and operator determined retargeting |
|
provides call barring rules determined by the operator that take precedence over MMTelICB and MMTelOCB |
|
implements the Originating Identification Presentation (OIP) service |
|
implements the Originating Identification Restriction (OIR) service |
|
implements the Terminating Identification Presentation (TIP) service |
|
implements the Terminating Identification Restriction (TIR) service |
|
handles the finalisation of charging when a call is answered over WiFi. |
|
records charging information about MMTel supplementary services invoked on a call. |
|
determines if and how the Flexible Alerting features will execute based on feature configuration and the HSS Subscriber Data. |
|
implements the Flexible Alerting service, by alerting the group members in parallel |
|
implements the Flexible Alerting service, by sequentially alerting the group members. |
|
connects the IMPU acquired from the subscriber registration to the existing ACI for the session transfer |
|
checks if the subscriber has the STOD service provisioned |
|
handles the transfer request and route it to the previous bound session |
|
intercepts the transfer INVITE routed by the MMTelStodTriggerAnchor feature and connects the existing called led to the new calling leg and releases the previous calling leg |
|
enables a party involved in a communication to transfer their role in that communication to a third party |
|
adds the |
|
uses information from a SIP |
|
replaces the undisclosed identity with the shared identity for an originating call from a companion device where such hiding has been requested |
|
is responsible for reading subscriber location data from the HLR and writing it into Sentinel session state variable fields. |
|
determines whether a received SIP INVITE corresponds to a PSAP callback, and stops any other features that could potentially prevent the call being set up. |
|
The two features here are responsible for identifying appropriate calls as PSAP callbacks and (if required) recording that a PSAP call has occurred. |
|
sets the companion device headers to the initial INVITE when the subscriber has been provisioned with companion devices. |
Additionally the MMTel AS provides support for a number of Vertical Service Code Features.
| Feature | What it does |
|---|---|
updates the Request URI of a SIP INVITE, based on the location of the calling party and the dialled number |
|
redirects the calling party to their voicemail server. |
|
performs a list of predefined HTTP PUT operations to update subscriber data in an XCAP server. |
