What is OCB?

3GPP defines communication barring in TS 24.611, including Incoming Communication Barring (ICB), Anonymous Communication Rejection as a special case of ICB, and Outgoing Communication Barring (OCB):

The Outgoing Communication Barring (OCB) is a service that rejects outgoing communications that fulfil certain provisioned or configured conditions on behalf of the originating user.

The Outgoing Communication Barring (OCB) service makes it possible for a user to have barring of certain categories of outgoing communications according to a provisioned or user configured barring program and is valid for all outgoing communications. A barring program is expressed as a set of rules in which the rules have a conditional part and an action part. An example condition is whether the request uri matches a specific public user identity. The action part can specify for a rule that contains a matching condition that the specific outgoing communication it to be barred. The complete set of conditions and actions that apply to this service and their semantics is described in subclause 4.9.Incoming.

Feature cheat sheet

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

MMTEL

Yes

 
OriginatingSipAccess_SubscriberPreCreditCheck
 
SipAccess_SubscriberPreCreditCheck

Yes

Yes

Stateless

POJO

Prerequisite features

Note For announcements, SIPPlayAnnouncement is a dependent feature; but it is not a prerequisite.

Source Code

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

> create-module new-cb-module opencloud#mmtel-communication-barring#volte/2.8.0;2.8.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-communication-barring

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

mmtel-communication-barring-library

Contains code shared by both communication barring features.

mmtel-ocb-profile

Contains the profile specification for the feature configuration profile table.

mmtel-ocb

Contains the feature itself.

Network operator data

This data is stored in a JSLEE configuration profile table, called MMTelOCBConfigProfileTable.

Operator data is scoped according to a Sentinel selection key. There is one profile in the profile table for each network operator.

Attribute Name Type Description 
OCBPlayAnnouncement

Boolean

If true, MMTelOCB will request an announcement is played in the case that it bars the session setup.

 
OCBAnnouncementID

int

The ID for the announcement to be played. If set to zero there is no announcement.

Defaults for network operator data

Attribute Name Default Value 
OCBPlayAnnouncement
 
false
 
OCBAnnouncementID
 
0

Session input variables

Variable name

Type

Comments

 
MMTelOCBServiceData

Complex

 
RoamingIndicator

Boolean

 
International

Boolean

 
InternationalExHC

Boolean

Session output variables

Variable name Type Comments 
OCBBarred

Boolean

Set to true if the OCB feature bars the call. It exists so that feature execution scripts can read the variable and take action.

 
OCBBarredWithAnnouncement

Boolean

Set to true if the OCB feature bars the call, and the feature is configured to request an announcement as part of barring

 
AnnouncementID

int

The value of the announcement ID to be played. Zero has a special meaning — that no announcement is to be played.

 
EndSessionAfterAnnouncement

int

The status code used when ending the session — if barring has occurred and announcements are used.

 
RanOcb

Boolean

Signals to other features that OCB ran on this session.

Supported barring rule conditions

Roaming

This condition evaluates to true if the session state variable RoamingIndicator is true. This is set by the MMTel Determine International and Roaming Status feature.

Use this XML in the REM HSS Subscriber Data page to configure OCB for roaming calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="roaming">
        <cp:conditions>
            <roaming/>
        <cp:conditions/>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Media

This condition evaluates to true when the value of this condition matches the media field in one of the "m=" lines in the SDP message body offered in an INVITE request.

Use this XML in the REM HSS Subscriber Data Page to configure OCB for calls offering specific media:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm: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>

Combinations of media types may be expressed as multiple conditions within the same rule. For example:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="no_video_and_text">
        <cp:conditions>
            <media>video</media>
            <media>text</media>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Identity

This condition evaluates to true if the identity of the other party in the communication matches that which is expressed in the condition. Identities within the condition can be expressed in different ways:

  • a single, fully expressed identity (e.g. sip:alice@example.com)

  • a whole domain (e.g. example.com)

  • a whole domain, but with exceptional identities or domains (e.g. example.com except for alice@example.com)

  • all identities (may also have exceptions)

  • any combination of the above

In case of a single identity (i.e. a 'one' condition), or in case of an exception (i.e. an 'except' condition), the URI in the condition and the URI to match against are both normalized before they are compared. Normalization is done using the Normalization Component.

The following XML snippets show how to configure the user’s Subscriber data for each of the above cases.

A single, fully expressed identity (the identity 'sip:alice@example.com' is matched)

This example, without any other rule, blocks any session torwards 'sip:alice@example.com'.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm: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>
A domain (all identities at 'example.com' are matched)

This example, without any other rule, blocks any session torwards any user in the 'example.com' domain.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-domains">
        <cp:conditions>
            <cp:identity>
                <many domain="example.com"></many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
A whole domain with an exceptional identity (all identities at 'example.com' are matched except 'sip:alice@example.com')

This example, without any other rule, blocks any session torwards all users in the 'example.com' domain, except for 'sip:alice@example.com'.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-domains-with-exceptions">
        <cp:conditions>
            <cp:identity>
                <many domain="example.com">
                    <except id="sip:alice@example.com"/>
                </many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
A whole domain with an exceptional domain (all identities at 'example.com' are matched except 'sip:alice@example.com')

This example, without any other rule, blocks any session torwards all users in the 'example.com' domain, except for users within the domain 'callcentre.example.com'.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-domain-except-callcentre">
        <cp:conditions>
            <cp:identity>
                <many domain="example.com">
                    <except domain="callcentre.example.com"/>
                </many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
Important Note the attribute of the 'except' element is now 'domain'.
All identites (all identities are matched)

This example, without any other rule, blocks all sessions torwards any user.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-all">
        <cp:conditions>
            <cp:identity>
                <many />
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
A more complex Identity condition expression (all identies at 'example2.com' match except for 'sip:charlie@example2.com'. Also the identities 'sip:alice@example1.com' and 'sip:bob@example1.com' match.)

This example, without any other rule, blocks any session torwards all users registered in the domain 'example2.com', for 'sip:alice@example1.com' and sip:bob@example1.com, except for 'sip:charlie@example2.com.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="barr-some">
        <cp:conditions>
            <cp:identity>
                <one id="sip:alice@example1.com"/>
                <one id="sip:bob@example1.com"/>
                <many domain="example2.com">
                    <except id="sip:charlie@example2.com"/>
                </many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>
Another more complex Identity condition expression with more than one rule.

This example, always blocks some domains, always allow other domains and a set of sip URIs.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="always-allow-these-domains">
        <cp:conditions>
            <cp:identity>
                <many domain="emergency.org"></many>
                <many domain="police.org"></many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>true</allow>
        </cp:actions>
    </cp:rule>

    <cp:rule id="always-barr-these-domains">
        <cp:conditions>
            <cp:identity>
                <many domain="fakelotery.org"></many>
                <many domain="dhueb!.org"></many>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>

   <cp:rule id="always-barr-these-identities">
        <cp:conditions>
            <cp:identity>
                <one id="sip:john@example.com"/>
                <one id="sip:marc@example.com"/>
            </cp:identity>
        </cp:conditions>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>

</cp:ruleset>
Tip Depending on the value of the 'allow' element of the rule, the rule can essentially become a 'whitelist' or a 'blacklist'.

International

This condition evaluates to true if the session state variable International is true. This is set by the MMTel Determine International and Roaming Status feature.

Use this XML in the REM HSS Subscriber Data page to configure OCB for international calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="international">
        <cp:conditions>
            <international/>
        <cp:conditions/>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

International-exHC

This condition evaluates to true if the session state variable InternationalExHC is true. This is set by the MMTel Determine International and Roaming Status feature.

Use this XML in the REM HSS Subscriber Data page to configure OCB for international-exHC calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="international-exHC">
        <cp:conditions>
            <international-exHC/>
        <cp:conditions/>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

International when roaming

This condition evaluates to true if the session state variable International is true and RoamingIndicator is true. These are set by the MMTel Determine International and Roaming Status feature.

Use this XML in the REM HSS Subscriber Data page to configure OCB for international when roaming calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="international">
        <cp:conditions>
            <roaming/>
            <international/>
        <cp:conditions/>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Unconditional

Use this XML in the REM HSS Subscriber Data page to configure OCB for all calls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="all-calls">
        <cp:conditions/>
        <cp:actions>
            <allow>false</allow>
        </cp:actions>
    </cp:rule>
</cp:ruleset>

Validity

This condition evaluates to true if the current time is within the times specified by the validity period.

Time is based on the Home Network time (that is, the time of the MMTel Server).

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="all-calls">
        <cp:conditions>
            <cp:validity>
                <cp:from>1970-01-01T00:00:00</cp:from>
                <cp:until>1970-01-01T00:00:00</cp:until>
            </cp:validity>
        </cp:conditions>
    </cp:rule>
</cp:ruleset>

Rule deactivated

This condition always evaluates to false. Used to disable a rule without removing the rule entirely. The rule is re-enabled by removing this condition.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy">
    <cp:rule id="all-calls">
        <cp:conditions>
            <rule-deactivated/>
            <cp:validity>
                <cp:from>1970-01-01T00:00:00</cp:from>
                <cp:until>1970-01-01T00:00:00</cp:until>
            </cp:validity>
        </cp:conditions>
    </cp:rule>
</cp:ruleset>

Barring rule actions

Barring rule actions are a string. There could be many actions defined, but the only one that makes any sense is the allow action.

The allow action has a Boolean attribute, with meaning as follows:

  • true — allow session setup to proceed

  • false — deny session setup from proceeding.

Any other rule action (that is, an action that is not set to allow) will result in us treating the action as the following:

  • allow rule action with value of true.

Statistics

MMTelOCB statistics are tracked by the sentinel.volte.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.volte.sip service → sentinel.volte.sip SBB → feature → MMTelOCB
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.8.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=2.8.0].feature.MMTelOCB"

Statistic Type Incremented when…​ 
Started

Counter

the feature runs

 
FailedToStart

Counter

Sentinel VoLTE encounters an error while attempting to start the feature

 
IssuedWarning

Counter

a non-fatal problem is encountered and the feature and issues a warning

 
FailedDuringExecution

Counter

a fatal problem is encountered and the feature cannot execute correctly

 
TimedOut

Counter

the feature takes too long to complete and Sentinel VoLTE aborts execution

 
CallBarred

Counter

the feature bars a call

 
CallBarredByOdb

Counter

the feature bars a call by Operator Determined Barring rule

 
PlayAnnouncementTriggered

Counter

the feature requests that an announcement be played to the calling party

 
OdbRulesEvaluatedTrue

Counter

a rule was evaluated to be True

 
RulesEvaluatedTrue

Counter

incremented by the number of rules which evaluated true

Behaviour

If operator data is not present, the OCB 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.

If MMTelOCBServiceData.OperatorAuthorized or MMTelOCBServiceData.Active is false, the feature finishes execution without modifying any state.

If the rules do not parse, then the feature:

  • instructs Sentinel Core that the feature has failed due to configuration problems

  • finishes execution without modifying any state.

When the feature processes a set of rules, it does each in turn:

For each rule, if: then

  • the rule has no <conditions> element;

  • the rule has an empty <conditions> element; or

  • conditions are present and they all evaluate to true.

the rule matches

The actions from all matching rules are combined.

If…​ then the combined result for the rule set is:

any matching rules had the action allow=true

allow=true

all matching rules had the action allow=false

allow=false

no rules matched

allow=true
Tip When a rule contains multiple conditions, they all must match for the whole rule to match. This is essentially a logical 'AND' between the conditions. To express a logical 'OR' of conditions, the conditions must be placed in different rules.

If the combined result is allow=false, then the OCB feature sets the session output variable OCBBarred to true. Otherwise the OCB feature sets the session output variable OCBBarred to false and finishes without modifying any further state.

If THE network configuration has OCBPlayAnnouncement set to true, and OCB has decided to bar the communication, then the OCB feature sets the session output variable AnnouncementID to MmtelOCBConfig.OCBAnnouncementID.

Finally, if the communication is to be barred, OCB rejects the call with the appropriate SIP error response code: 603 Decline.

Roaming determination

The MMTelOCB feature does not compute whether or not the served user is roaming; rather it relies on a session input variable (RoamingIndicator). This is set by Sentinel’s DetermineIfRoaming feature.

Here is an example feature execution script fragment:

run DetermineIfRoaming
run MMTelOCB

Playing announcements

The MMTelOCB feature does not play announcements itself; rather it relies on setting session output variables (AnnouncementID, OCBBarredWithAnnouncement, EndSessionAfterAnnouncement). These are set by the MMTelOCB feature if an announcement is to be played. They are used by the out-of-the-box feature execution scripts such that if announcements are desired to be played prior to the barred call being terminated, it is played using the SIPPlayAnnouncement feature.

This is an example feature execution script, taken from a fragment of the out-of-the-box execution scripts.

run MMTelOCB
if (session.OCBBarredWithAnnouncement) {
   run SIPPlayAnnouncement
}

The SIPPlayAnnouncement feature checks session state for the AnnouncementID field, and if the value is non-zero will play an announcement. When the announcement is played using the SIPPlayAnnouncement feature, it is played to the calling party.

Finally, when the announcement is complete the SIPPlayAnnouncement feature ends the session with the appropriate SIP error response (provided by MMTelOCB during its execution). The SIP error response code is set in the EndSessionAfterAnnouncement session output variable.

Graceful handling of terminating access

MMTelOCB is an originating feature. It will finish execution without modifying any state if it is invoked in an terminating attempt.

Background information on format of barring rules

Each rule is expressed as an XCAP cp-rule — as an XML fragment:

<cp:rule id="rule66">
        <cp:conditions>
        condition1
        condition2
        </cp:conditions>
        <cp:actions>
          <allow>false</allow>
        </cp:actions>
 </cp:rule>

In case that the allow element is not found, the feature assumes allow = false.

Previous page Next page
Sentinel VoLTE Version 2.8.0