The Operator Specific Barring Types are 4 operator defined rules that are stored in the AS. The ODB data indicates which of them should be evaluated and, like all others ODB conditions, they take precedence over MMTelICB and MMTelOCB .
What is Operator Specific Barring?
The 3GPP specifications TS 24.315 defines:
The Operator specific barring definition for type 1, type 2, type 3, and type 4 is locally configured in the AS providing the ODB service. For operator specific barring the criteria that can be used by the operator to define conditions that are used to determine whether the category applies may be based on any signalling information from the incoming request. Examples of such criteria are: 1) destination type e.g. international numbers or specific numbers; 2) media used in the communication, e.g. audio, video, or text. |
The scope definition of what kind of conditions can be present in those rules is not specified. The OpenCloud implementation of those rules follows the simservs RuleSet definition (TS 29.364 ) for MMTelICB Supported Barring Rule Conditions and MMTelOCB Supported Barring Rule Conditions. This way the operator can define the same MMTel barring conditions supported by the MMTelOCB and MMTelICB features.
The Sentinel VoLTE TAS provides an extension to standard Operator Specific Barring that allows the operator to retarget outbound calls to an arbitrary destination. See How to provision the Operator Specific Barring rules for details of how to enable this functionality, and MMTelOCB Behaviour for details of how it is executed.
ODB-Specific Conditions
There are conditions that are unique to ODB. These are:
Incoming Communications
To make a rule match on any communications that are 'incoming', add the <incoming /> element to its set of conditions.
Example:
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<cp:rule id="barr-alice-incoming">
<cp:conditions>
<incoming />
<cp:identity>
<one id="sip:alice@example.com"/>
</cp:identity>
</cp:conditions>
<cp:actions>
<allow>false</allow>
</cp:actions>
</cp:rule>
</cp:ruleset>
Outgoing Communications
To make a rule match on any communications that are 'outgoing', add the <outgoing /> element to its set of conditions.
Example:
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<cp:rule id="barr-alice-outgoing">
<cp:conditions>
<outgoing />
<cp:identity>
<one id="sip:alice@example.com"/>
</cp:identity>
</cp:conditions>
<cp:actions>
<allow>false</allow>
</cp:actions>
</cp:rule>
</cp:ruleset>
How to Provision the Operator Specific Barring Rules
Definitions for each of the four allowed operator specific barring rules are provided on the MMTelOdbOperatorSpecificTypeRuleProfileTable.
Each profile on the table corresponds to one of the four types.
Profiles are named with the format: {sentinel-selection-key}:{rule-type}, for example:
Metaswitch:Metaswitch::::Type1
Each profile has the following fields:
| Name | Type | Default Value | Description |
|---|---|---|---|
OperatorSpecificType |
String (Enum) |
null |
Identifies the type of the rule, should match the profile name, must be equal to one of: |
Rule |
String |
null |
The |
Retarget |
boolean |
false |
A flag to indicate whether this rule should retarget the call when the result of evaluating the |
RetargetURI |
String |
null |
The new target URI that should be used when retargeting a call. If the |
PlayRetargetAnnouncement |
boolean |
false |
A flag that indicates whether an announcement should be played if this rule triggers retargeting. This only applies if the |
RetargetAnnouncementID |
int |
0 |
The ID of the announcement that should be played if the retarget announcement is triggered. If this is |
DisableOnlineChargingOnRetarget |
boolean |
false |
A flag that indicates whether online charging should be suppressed if this rule retargets the call. |
Note that redirection behaviour only applies to outbound calls on an originating or forwarded TAS instance. When applied to inbound calls on a terminating TAS instance, Operator Specific Barring rules will execute standard barring behavior regardless of any retarget configuration on this profile table.
Examples
The sections below show XML data stored in the Rule field of each profile on the MMTelOdbOperatorSpecificTypeRuleConfigProfileTable.
The values can be applied for type 1 to type 4. The fact that the <incoming\> and <outgoing\> are not present, means that those rules will
be applied to both directions.
Bar Video
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<cp:rule id="no_video">
<cp:conditions>
<media>video</media>
</cp:conditions>
<cp:actions>
<allow>false</allow>
</cp:actions>
</cp:rule>
</cp:ruleset>
Bar Identity
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<cp:rule id="barr-alice">
<cp:conditions>
<cp:identity>
<one id="sip:alice@example.com"/>
</cp:identity>
</cp:conditions>
<cp:actions>
<allow>false</allow>
</cp:actions>
</cp:rule>
</cp:ruleset>
Bar Specific Domain for a One Month Period
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<cp:rule id="barr-domain">
<cp:conditions>
<cp:identity>
<many domain="example.com"></many>
</cp:identity>
<cp:validity>
<cp:from>2016-01-01T00:00:00</cp:from>
<cp:until>2016-01-31T23:59:59</cp:until>
</cp:validity>
</cp:conditions>
<cp:actions>
<allow>false</allow>
</cp:actions>
</cp:rule>
</cp:ruleset>
