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 Originating / Terminating Point in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature

MMTEL

Terminating

SipAccess_SubscriberPreCreditCheck

 
Yes

Yes

Stateless

POJO

Prerequisite features

These features must run before OIP:

Source Code

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

> create-module new-idpr-module opencloud#mmtel-id-presentation-restriction#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 relevant to this feature:

Module Name Description

mmtel-id-presentation-restriction

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

mmtel-id-presentation-restriction-library

Contains code shared by all ID presentation and restriction features.

mmtel-oip-profile

Contains the profile specification for the feature configuration profile table.

mmtel-oip

Contains the feature itself.

Statistics

MMTelOIP 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 → 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 can not 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 Privacy header including both the value critical and an unrecognised value.

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. In the profile table, there is one profile for each network operator.

Attribute Name Type Default Value Description 
AnonymizeFromPolicy

Enum (ANONYMIZE, DO_NOT_ANONYMIZE)

 
DO_NOT_ANONYMIZE

When set to ANONYMIZE the from header of the INVITE will always be anonymized if the OIP feature is not active for the subscriber.

 
PrivacyHeaderRemovalPolicy

Enum (USE_IETF, USE_3GPP)

 
USE_3GPP

This value is deprecated and no longer used by the feature.

 
Override

Enum (OVERRIDE_ACTIVE, OVERRIDE_NOT_ACTIVE)

 
OVERRIDE_NOT_ACTIVE

This value is deprecated and has been replaced by subscriber level data, see MMTelOIPServiceData.

 
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 
MMTelOIPServiceData

Complex

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:

  1. Increments an error statistic.

  2. Logs a message at the Fine level.

  3. Informs the Sentinel core that the feature is not configured appropriately (Invalid Configuration).

  4. 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 recognised by the OIP feature, it will assume that it can not fulfill the privacy request and refuse the incoming request with 500 Server Internal Error. If all of the Privacy header values are recognised by the feature, then the request will be handled as per normal behaviour.

Recognised 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

Table 1. SIP header manipulation when MMTelOIP is active

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

Table 2. SIP header manipulation when MMTelOIP is not active.

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 ANONYMIZE

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. Alternatively, the rules can be controlled per network operator by prefixing the network operator name followed by an underscore to the profile table name (e.g. Metaswitch_MMTelCustomHeaderPrivacyRules). Each profile in the profile table represents a single rule for the feature to evaluate. The profile name is cosmetic, it can be any 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: REQUEST, RESPONSE, or BOTH.

 
ApplicablePrivacyHeaderValues
 
String Array

A list of Privacy header values that will trigger this rule.
Note HeaderName matching is case-insensitive. Wildcards are not supported.

Black Listed SIP Headers

The following SIP headers can not 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 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.

2. 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.

3. 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.

1 Call-ID, Record-Route and Via headers are automatically anonymized by the B2BUA process
2 This is the equivalent of the Privacy Header not being present
3 History-Info header is only removed if AllowHistoryInfoDeletion is set to true
Previous page Next page
Sentinel VoLTE Version 2.7.0