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 is 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

Feature Script Name

MMTelOCB

MMTel or SCC

MMTel

Call-Type

Originating

Session Plan

mmtel-orig

Execution Points

SipAccess_SubscriberCheck, SubscriptionSipRequest

Network Operator Config

Yes

Subscriber Config

Yes

POJO or SBB

POJO

Feature FSMs

None

Feature Parameters

None

SAS Support

Yes

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/3.1.0;3.1.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-prefix-address-list

Contains the address list specification for prefix based barring.

mmtel-ocb-prefix-classification-profile

Contains the prefix classification profile specification for prefix based barring.

mmtel-ocb

Contains the feature itself.

Network Operator Data

The MMTelOCB feature retrieves configuration from three profile tables and an address list:

  • The MMTelOCBConfigProfileTable provides the basic configuration for the feature.

  • The MMTelOdbOperatorSpecificTypeRuleProfileTable provides operator-specific ODB rule configuration.

  • The ${platform.operator.name}_PrefixBarring_AddressListEntryTable maps dialled numbers to prefix barring classifications.

  • The PrefixBarringClassificationsTable defines matching criteria and the barring treatment for classes of dialled prefixes.

MMTelOCBConfigProfileTable

Basic feature configuration is stored on a profile table called MMTelOCBConfigProfileTable.

Operator data is scoped according to a Sentinel selection key.

Attribute Name Type Default Description 
PlayAnnouncement

boolean

false

If true, MMTelOCB will request an announcement is played when it bars a call.

 
AnnouncementID

int

0

The ID for the announcement to be played. If set to 0 no announcement will be played.

MMTelOdbOperatorSpecificTypeRuleProfileTable

Operator specific ODB rule configuration is stored on a profile table called MMTelOdbOperatorSpecificTypeRuleProfileTable.

See How to Provision the Operator Specific Barring Rules for details of this profile table.

${platform.operator.name}_PrefixBarring_AddressListEntryTable

An address list called ${platform.operator.name}_PrefixBarring_AddressListEntryTable is used to classify the called number for prefix based barring.

See How to Configure Prefix Based Barring.

PrefixBarringClassificationsTable

The prefix barring address list references one or more classifications for calls to addresses that match the prefix.

Details of how each classification is treated are stored in PrefixBarringClassificationsTable profile table.

See How to Configure Prefix Based Barring.

Session Input Variables

Variable name Type Comments

MMTelOCBServiceData

Complex

OdbServiceData

Complex

Read from the HSS in SubscriberDataLookupFromHSS

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.

 
EarlyMediaAnnouncementInfoQueue

List<SipAnnouncementInformation>

Feature adds an entry with the value of the announcement ID to be played.

 
EndSessionAfterAnnouncement

int

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

 
RanOcb

boolean

Signal to other features that OCB ran on this session.

 
MonitorCallOnly

boolean

Set to true if the feature determines that charging should be disabled for the call.

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=3.1.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=3.1.0].feature.MMTelOCB"

Statistic Type Description 
Started

Counter

Incremented when the feature is invoked.

 
FailedToStart

Counter

Incremented when Sentinel VoLTE encounters an error while attempting to start the feature.

 
IssuedWarning

Counter

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

 
FailedDuringExecution

Counter

Incremented when a fatal problem is encountered and the feature cannot execute correctly.

 
TimedOut

Counter

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

 
CallBarred

Counter

Incremented when the feature bars a call.

 
CallExplicitlyAllowed

Counter

Incremented when the feature finds a rule that explicitly allows the call to go through, thus preventing any barring.

 
ODBRuleApplied

Counter

Incremented when an ODB rule’s conditions were met and its action was executed.

 
OCBRuleApplied

Counter

Incremented when an OCB rule’s conditions were met and its action was executed.

 
PrefixBasedRuleApplied

Counter

Incremented when a rule was applied due to prefix barring. Either CallBarred, CallExplicitlyAllowed or RedirectionRequested will be incremented in tandem. ODBRuleApplied will not be incremented, even when the treatment is an OSBType rule.

 
PlayAnnouncementTriggered

Counter

Incremented when the feature requests that an announcement be played to the calling party.

 
RedirectionRequested

Counter

Incremented when an operator specific ODB rule’s conditions were met and it has been configured to redirect the call.

 
RedirectionFailed

Counter

Incremented when an attempt to redirect the outbound INVITE fails.

 
RedirectionSuccessful

Counter

Incremented when an attempt to redirect the outbound INVITE is successful.

 
OdbSpecificTypeRulesNotFound

Counter

Incremented when the subscriber data for the served user indicates that an operator specific ODB rule should be applied, but no configuration could be found for the specified rule.

 
ClassifiedNumberByPrefix

Counter

Incremented when prefix barring classifies the dialled number as triggering some barring treatment(s).

 
FoundMultipleNonConflictingPrefixBarringClassifications

Counter

Incremented when prefix barring classifies the dialled number and selects multiple classifications, all with separate treatments.

 
FoundConflictingPrefixBarringClassifications

Counter

Incremented when prefix barring classifies the dialled number and selects multiple classifications, with some duplicate treatments. Such as

  • classification1

    • BarringTreatment=OperatorBar

    • OverrideOCBAnnouncement=true

    • announcementID=1

  • classification2

    • BarringTreatment=OperatorBar

    • OverrideOCBAnnouncement=true

    • announcementID=0

Supported Barring Rule Conditions

Roaming

This condition evaluates to true if the session state variable RoamingIndicator is true. This is set by the 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 URI to match against although normalized comes from the inbound request. This means that the URI will not have had number translation features such as SIP Short Code applied. Therefore any condition intended to match a shortcode should take this into account.

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 towards '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 towards 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 towards any user 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 towards any user 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 identities (all identities are matched)

This example, without any other rule, blocks all sessions towards 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 identities 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 towards any user registered in the domain 'example2.com' except for 'sip:charlie@example2.com, for 'sip:alice@example1.com' and sip:bob@example1.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 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 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 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.

Behaviour

Initial Checks

When triggered the feature first undergoes a series of checks to ensure that the conditions for the feature to run are met. The feature enforces the following conditions:

  • The call-type is Originating or Forwarded.

  • OCB service data for the subscriber has been successfully loaded and the OperatorAuthorized flag in the data is set to true.

  • Network operator configuration for the feature is present and has been successfully loaded.

  • The invoking trigger for the feature is an inbound SIP INVITE or REFER request.

If any of those conditions are not met, the feature will terminate immediately and the OCB service will not run.

Barring Rule Evaluation

If all checks passed, then the feature will move on to carry out barring rule evaluation. This occurs in three phases, one for each type of rule:

  1. All operator specific type rules are evaluated. If any of them apply (be they a barring, retarget or explicit allow action), then the feature will execute the appropriate action and then skip the following phases. Prefix barring interacts with this step as described in Prefix Based Barring Behaviour

  2. The remaining ODB rules are evaluated, again if any of the rules apply, their action will be executed and the final evaluation phase skipped.

  3. Prefix based premium-rate communication barring options are evaluated as described in Prefix Based Barring Behaviour

  4. Standard OCB rules will be evaluated and the appropriate action applied if one is matched. This final phase will be skipped if the MMTel OCB Active flag is set to false in the service data.

When deciding whether a rule should be applied, the feature will check the set of conditions provided by the rule. The feature will apply the rule if any of the following statements are true:

  • The rule has no set of conditions, i.e. the <conditions> element is absent in the rule definition.

  • The set of conditions for the rule is empty.

  • All of the conditions within the set defined in the rule are met.

If none of those statements are true for any rule, the feature will complete execution and the call will be allowed to continue.

Rule Format

Each rule is expressed as an XCAP cp:rule XML fragment, for example:

<cp:rule id="rule66">
    <cp:conditions>
        <roaming/>
        <media>video</media>
    </cp:conditions>
    <cp:actions>
        <allow>false</allow>
    </cp:actions>
 </cp:rule>

When the allow element is not found, the feature assumes allow is false.

Rule Actions

When a rule is applied, there are three possible actions the feature may have to carry out:

  1. Whitelisting (i.e. call is explicitly allowed to continue)

  2. Call barring

  3. Retargeting (only available with operator specified ODB rules)

Whitelisting

If the action of an applicable rule indicates the call should be allowed, then the feature immediately stops evaluating other rules and allows the call to proceed.

Call Barring

If the action of an applicable rule indicates that the call should be barred, the feature won’t act immediately. It will first evaluate the other rules of the same type to ensure that none of them indicate that the call should be whitelisted. If the call is not whitelisted by another rule, then the feature will execute the call barring procedure as follows:

  1. Set the OCBBarred session state flag to true to limit which features will run after MMTelOCB.

  2. Increment appropriate stats to indicate the call was barred.

  3. Check whether the method for the incoming message is INVITE or REFER, and execute the appropriate procedure as described below.

INVITE barring procedure:

  1. Check the feature configuration to determine if an announcement needs to played.

  2. Depending on the outcome:

    1. If an announcement does not need to be played, instruct sentinel to immediately terminate the call with a 603 Decline response for the INVITE request.

    2. If an announcement is to be played:

      1. Suppress online charging for the call (if applicable).

      2. Queue an announcement for the SipPlayAnnouncement feature, using the announcement ID provided in the feature configuration.

      3. Set the EndSessionAfterAnnouncement session state field to indicate to the SipPlayAnnouncement that it should terminate the session with a 603 Decline response for the original INVITE request after the announcement has been played.

REFER barring procedure:

  1. Send a SIP 403 Forbidden response for the REFER request.

  2. Search for the outbound REFER on the outbound leg’s message queue, and then remove it.

Retargeting

Only operator-specific ODB rules can be used to retarget a call. In the rule XML, the action is still listed with allow being false (i.e. bar the call), but additional configuration on the MMTelOdbOperatorSpecificTypeRuleProfileTable is used to transform the rule action into a retarget. If there are multiple applicable operator-specific ODB rules for a call, and they retarget to different destinations, or one retargets and another bars the call, then the rule with the lowest Type number will take precedence (e.g. the Type2 rule will take precedence over the Type3 rule). However, as always, an operator-specific ODB rule that explicitly whitelists the call will take precedence regardless of its number.

When it is determined that a call should be retargeted, the procedure is as follows:

  1. Retrieve the new target URI from the rule’s configuration profile on the MMTelOdbOperatorSpecificTypeRuleProfileTable.

  2. Release the original outbound leg towards the called party (at this point no signalling should have occurred on this leg, so no message is sent to do this).

  3. Generate a new outbound INVITE request from the original inbound request.

  4. Update the newly created request to retarget it, the procedure for doing this is similar to the one used by unconditional forwarding (CFU) in the MMTelCDIV feature:

    1. The Request-URI is set to the value of the new target URI and a cause=302 parameter is added.

    2. The To header is set to the value of the new target URI.

    3. The History-Info header is modified/added to indicate a diversion has occurred, the original target URI is given the 'privacy=history' parameter.

  5. Create a new outbound leg (named MMTelOCBRetargetedLeg) to send the new INVITE request, and link this leg to the calling party leg.

  6. If the rule’s configuration profile indicates that the redirected call should not be subject to online charging, then suppress online charging for the call.

  7. If the rule’s configuration profile indicates that a retarget announcement should be played, then queue an announcement with the announcement ID provided in the rule’s configuration (note that the standard barring announcement as configured on the MMTelOCBConfigProfileTable will not be played on a retarget action).

If at any point in the procedure there is a problem that prevents retargeting from working, then the feature will fall back to standard call barring behaviour (including playing the standard barring announcement if applicable).

Rule Priority

The behavior described above gives rise to a natural priority that rules will follow when multiple rules with different actions are applicable to a call.

To summarise:

  • There are different types of rules: Prefix based OperatorAllow , Prefix based OperatorBar, Operator-specific ODB rules, Prefix based premium-rate communication barring, standard ODB rules, and OCB rules.

  • The overall priority is

    • Prefix based OperatorAllow

    • Operator-specific ODB rules that whitelist a call, regardless whether applied by matching their defined condition, or by prefix based treatment

    • Prefix based OperatorBar

    • Operator-specific ODB rules that bar a call, regardless whether applied by matching their defined condition, or by prefix based treatment

    • Prefix based premium-rate communication barring

    • Standard ODB rules

    • OCB rules

  • Within rules of the same type, a whitelisting action will always take precedence over a barring or retargeting action.

  • If multiple operator-specific ODB rules apply and have conflicting retarget or barring actions, then the rule with the lower number will take precedence. (there are four slots available for operator-specific ODB rules, numbered one through four).

Roaming and International Determination

The MMTelOCB feature does not compute whether or not the served user is roaming or international; rather it relies on a session input fields (RoamingIndicator, International, and InternationalExHC). These fields are set by the DetermineInternationalAndRoamingStatus feature. For this reason the DetermineInternationalAndRoamingStatus feature must run before MMTelOCB in the feature execution scripts if international and roaming status need to be considered.

Playing Announcements

The MMTelOCB feature does not play announcements itself; rather it relies on setting data in session output fields (EarlyMediaAnnouncementInfoQueue and EndSessionAfterAnnouncement) if an announcement is to be played. These fields are read by the SipPlayAnnouncement feature.

Based on the the data in the fields that feature will:

  • Handle the signalling required to play the announcement to the calling party.

  • Terminate the call after the announcement if instructed to do so.

For this reason the SipPlayAnnouncement feature must run after MMTelOCB in the feature execution scripts if announcements are required.

Previous page Next page
Sentinel VoLTE Version 3.1.0