The MMTelOIP feature implements the Originating Identification Presentation (OIP) service .
What is OIP?
From 3GPP 24.607:
The Originating Identification Presentation (OIP) service provides the terminating user with the possibility of receiving identity information in order to identify the originating user. The OIP service provides the terminating user with the possibility of receiving trusted (i.e. network provided) identity information in order to identify the originating user. In addition to the trusted identity information, the identity information from the originating user can include identity information generated by the originating user and in general transparently transported by the network. In the particular case where the “no screening” special arrangement does not apply, the originating network shall verify the content of this user generated identity information. The terminating network cannot be responsible for the content of this user generated identity information. |
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 |
|---|---|---|---|---|---|---|---|
MMTEL |
Yes |
Terminating |
SipAccess_SubscriberPreCreditCheck |
Yes |
Yes |
Stateless |
POJO |
Statistics
MMTelOIP statistics are tracked by the sentinel.volte.sip SBB and can be found under the following parameter set:
SLEE-Usage → sentinel.volte.sip service → sentinel.volte.sip SBB → feature → MMTelOIP
| Name | Type | Description |
|---|---|---|
Started |
Counter |
Incremented when the feature is triggered. |
FailedToStart |
Counter |
Incremented when the feature fails to start. |
FailedDuringExecution |
Counter |
Incremented when the feature fails while executing. |
IssuedWarning |
Counter |
Incremented when the feature issues a warning. |
TimedOut |
Counter |
Incremented when the feature times out during execution. |
Misconfigured |
Counter |
Incremented when a fatal error if the feature configuration cannot be loaded. |
ReceivedMalformedPrivacyHeader |
Counter |
Incremented when a non-standard ‘Privacy’ header is found in an incoming SIP message. |
FromHeaderAnonymized |
Counter |
Incremented when the feature anonymizes the ‘From’ header in an outgoing SIP request. |
ContactHeaderAnonymized |
Counter |
Incremented when the feature anonymizes the ‘Contact’ header in an outgoing SIP message. |
ReferredByHeaderAnonymized |
Counter |
Incremented when the feature anonymizes the ‘Referred-By’ header in an outgoing SIP message. |
PerformedUserLevelAnonymization |
Counter |
Incremented when the feature applies user-level privacy to an outgoing SIP message. |
PerformedHeaderLevelAnonymization |
Counter |
Incremented when the feature applies header-level privacy to an outgoing SIP message. |
PerformedSessionLevelAnonymization |
Counter |
Incremented when the feature applies session-level privacy to an outgoing SIP message. |
PerformedCustomHeaderAnonymization |
Counter |
Incremented when the feature finds and evaluates custom header privacy rules for a message. |
OverrideCategoryTriggered |
Counter |
Incremented when the feature disregards requested privacy settings on an incoming SIP message (due to the subscriber having override category status). |
CriticalPrivacyCannotBeFulfilled |
Counter |
Incremented when the feature refuses an incoming request due to a |
FallbackToNetworkDefaultServiceConfig |
Counter |
Incremented when the feature uses the network default service configuration as the session state does not contain the feature specific subscriber service data. |
Network Operator Data
This data is stored in a JSLEE Configuration Profile table called MMTelOIPConfigProfileTable.
The operator data is scoped according to a Sentinel selection key.
| Attribute Name | Type | Default Value | Description |
|---|---|---|---|
[[anonymize-from-policy]]AnonymizeFromPolicy |
Enum ( |
DO_NOT_ANONYMIZE |
When set to |
PrivacyHeaderRemovalPolicy |
Enum ( |
USE_3GPP |
This value is deprecated and no longer used by the feature. |
Override |
Enum ( |
OVERRIDE_NOT_ACTIVE |
This value is deprecated and has been replaced by subscriber level data; see MMTelOIPServiceData. |
[[allow-history-info-deletion]]AllowHistoryInfoDeletion |
boolean |
false |
Flag to allow History-Info header deletion. |
Additionally, the feature reads a second profile table that contains custom rules for removing additional headers under specified circumstances. See Custom Header Privacy Rules below.
Session input variables
| Variable name | Type | Comments |
|---|---|---|
bxref:mmtel-subscriber-data-representation#mmteloipservicedata[MMTelOIPServiceData] |
Complex |
Read from the HSS or HLR in SubscriberDataLookupFromHSS or SubscriberDataLookupFromHLR |
Session output variables
| Variable name | Type | Comments |
|---|---|---|
RanOip |
boolean |
Signals to other features that OIP ran on this session. |
Behaviour
If operator data is not present, the OIP feature:
-
Increments an error statistic.
-
Logs a message at the
Finelevel. -
Informs the Sentinel core that the feature is not configured appropriately (
Invalid Configuration). -
Exits.
Graceful handling of originating access
As OIP is a terminating feature. It will finish execution without modifying any state if it is invoked in an originating attempt.
OIP Override Category
The OIP override category overrides OIR’s requests for privacy, and provides as much identity information as is available to the terminating party.
It is extracted from the operator data in HSS or from HLR field ClipData.OverrideCategory field in ASN.1.
Critical Privacy Request
If the incoming request includes a Privacy header with the value critical, then the OIP feature will check to ensure that it can fulfill the privacy request.
If another Privacy header value is present in the request that is not recognized by the OIP feature, it will assume that it cannot fulfill the privacy request and refuse the incoming request with 500 Server Internal Error.
If all of the Privacy header values are recognized by the feature, then the request will be handled as per normal behaviour.
Recognized privacy header values are: header, user, session, history, id, none, critical.
SIP Header Manipulation
The primary purpose of MMTelOIP is to remove and anonymize headers that the originating UE and the OIR service requested to be removed or anonymized.
MMTelOIP Active
MMTel OIP is treated as active when MMTelOIPServiceData.OperatorAuthorized and MMTelOIPServiceData.Active are true
SIP Header [1] |
Originating Subscriber’s Privacy Setting |
|||||
|---|---|---|---|---|---|---|
User |
Header |
Session |
Id |
History |
None [2] |
|
Outgoing Requests to the Terminating Subscriber |
||||||
Call-Info |
Removed |
|||||
Contact |
Anonymized |
|||||
From |
Anonymized |
|||||
History-Info [3] |
Removed |
Removed |
Removed |
|||
In-Reply-To |
Removed |
|||||
Organization |
Removed |
|||||
Privacy |
Preserved |
Preserved |
Preserved |
Preserved |
Preserved |
Preserved |
Reply-To |
Removed |
|||||
Subject |
Removed |
|||||
User-Agent |
Removed |
|||||
Outgoing Responses to the Terminating Subscriber |
||||||
Call-Info |
Removed |
|||||
History-Info [3] |
Removed |
Removed |
Removed |
|||
Organization |
Removed |
|||||
Privacy |
Preserved |
Preserved |
Preserved |
Preserved |
Preserved |
Preserved |
Reply-To |
Removed |
|||||
Server |
Removed |
|||||
Warning |
Anonymized |
|||||
MMTelOIP Not Active
MMTel OIP is treated as not active when MMTelOIPServiceData.OperatorAuthorized or MMTelOIPServiceData.Active is false
SIP Header [1] |
Originating Subscriber’s Privacy Setting |
|||||
|---|---|---|---|---|---|---|
User |
Header |
Session |
Id |
History |
None [2] |
|
Outgoing Requests to the Terminating Subscriber |
||||||
Call-Info |
Removed |
|||||
Contact |
Anonymized |
|||||
From |
Anonymized |
Anonymized if the Network Operator Setting AnonymizeFromPolicy is set to |
||||
History-Info [3] |
Removed |
Removed |
Removed |
|||
In-Reply-To |
Removed |
|||||
Organization |
Removed |
|||||
Privacy |
Removed |
Removed |
Removed |
Removed |
Removed |
Removed |
Reply-To |
Removed |
|||||
Subject |
Removed |
|||||
User-Agent |
Removed |
|||||
Outgoing Responses to the Terminating Subscriber |
||||||
Call-Info |
Removed |
|||||
History-Info [3] |
Removed |
Removed |
Removed |
|||
Organization |
Removed |
|||||
Privacy |
Removed |
Removed |
Removed |
Removed |
Removed |
Removed |
Reply-To |
Removed |
|||||
Server |
Removed |
|||||
Warning |
Anonymized |
|||||
Custom Header Privacy Rules
The MMTelOIP feature has support for configuring custom rules that instruct the feature to remove additional headers depending on the message type and the value of the Privacy header.
These rules are defined in a profile table called MMTelCustomHeaderPrivacyRules.
Rules are created on the MMTel Custom Header Privacy Rules tab on the MMTelOIP Feature Configuration page in REM.
Each profile in the profile table represents a single rule for the feature to evaluate.
The profile Rule ID is cosmetic; it can be any unique string.
The profiles have the following fields:
| Field Name | Type | Description |
|---|---|---|
HeaderName |
String |
The name of the header that should be removed when this rule is applied to a message. |
ApplicableMessageTypeAsString |
Enumeration |
One of three values based on what type of message this rule should be applied to. Value must be one of: |
ApplicablePrivacyHeaderValues |
String Array |
A list of |
NetworkOperator |
String |
The name of the Network Operator this rule will be applied to. An empty string applies the rule to the platform overall. |
|
HeaderName matching is case-insensitive. Wildcards are not supported. |
Immutable SIP Headers
The following SIP headers cannot be removed by MMTelOIP custom header privacy rules:
-
From
-
Call-ID
-
Contact
-
Content-Length
-
CSeq
-
Max-Forwards
-
Record-Route
-
Request-URI
-
Route
-
To
-
Via
Rule Evaluation
Whenever the feature is processing a message, it will look for this profile table and check if there are any rules defined. If it finds rules, it will iterate through them and evaluate each one to determine if it should be applied to the message. For each rule, the evaluation process is as follows:
1. Check the Network Operator
The NetworkOperator field is compared to the Network Operator for the install. If it matches, the rule is applied.
If NetworkOperator is an empty string, the rule is always applied.
2. Check the Message Type
The ApplicableMessageType field indicates what type of SIP message the rule should be applied to:
REQUEST indicates the rule should be applied to SIP requests.
RESPONSE indicates the rule should be applied to SIP responses.
BOTH indicates the rule should be applied to all SIP messages.
3. Check the Privacy Header
The feature will look at the value(s) of the Privacy header on the message and compare them to the ApplicablePrivacyHeaderValues for the rule.
If any one value of the Privacy header matches any one value in the ApplicablePrivacyHeaderValues field, the rule applies.
4. Apply Rule
If the previous two checks both indicate the rule should be applied, the feature will strip all headers from the message that match the HeaderName field of the rule.
