Change the tariff and routing after authentication

An authentication rule can override the tariff and routing group of an account, but only for calls it authenticates. Calls of registered devices, which log in with SIP digest, and calls that arrive through the DID Pool never pass an authentication rule of the account. Post-authentication rules close that gap: they apply after the account is known, however it was found, and pick the calls by remote IP, CLI and CLD. This tutorial sends one account’s calls to the UK through a separate routing group and tariff. Allow about 20 minutes.

The example account office-pbx (ID 3092) registers with digest credentials. Its calls to numbers starting with 44 should use the tariff UK premium (ID 12) and the routing group UK premium (ID 7).

Before you start

• The tariff and the routing group exist, and you know their IDs: the i_tariff and i_routing_group in the panel’s URL when you open them, or from the API.
• You can call the XML-RPC API, as described in API overview. The examples use the call() helper from Call the API from Python.

Note

The panel has no screen for post-authentication rules. You create, change and delete them through the API only.

Step 1: Understand when the rule applies

After the switch has authenticated a call and applied the translation rules of the authentication rule, it looks for a post-authentication rule of the account that matches the call:

Field	Matches	Pattern syntax
remote_ip	IP address the call comes from	exact
cli	Calling number	wildcards
cld	Called number	wildcards

A rule needs at least one of the three fields; a field you leave empty matches any call. In cli and cld:

• * matches any sequence of characters: 0038* matches 0038943794.
• ? matches one character: 0?7834 matches 007834 and 017834.
• [1-5] matches one character of a range, [^p] one character that is not p.
• \ makes the next character literal: \* is a star.

abc?_[1-5][2]0* matches abcd_1201234567 but not abcde_1201234567.

When a rule matches, the call gets the rule’s tariff and routing group instead of the account’s, and the rule’s CLI and CLD translation rules rewrite the numbers. The account’s own translation rules run after that. See Number translation for the full order.

Result: you know which fields to fill for your case.

Step 2: Add the rule

Call addPostAuthRule with the account and the CLD pattern:

call("addPostAuthRule", {
    "i_account": 3092,
    "cld": "44*",
    "i_tariff": 12,
    "i_routing_group": 7,
})

response

{"result": "OK", "i_post_auth_rule": 418}

Add "remote_ip": "198.51.100.20" to apply the rule only to calls from the office IP. Add "cld_translation_rule" or "cli_translation_rule" when the new routing group expects another number format, for example s/^44/0/.

Result: the account has a post-authentication rule with ID 418.

Caution

The tariff must have rates for the numbers the rule selects. A call that matches the rule and finds no rate in the rule’s tariff is rejected with 403 No Rates Found, even if the account’s own tariff has a rate.

Step 3: Test it

1. Call listPostAuthRules with {"i_account": 3092} and check the fields of the rule.
2. Make a test call from a device registered as office-pbx to a number starting with 44.
3. Open Reports → Call Records (CDRs) and the call’s details. I-Post-Auth-Rule under Call Authentication shows 418, and the price and the vendor come from UK premium.
4. Make a call to another destination. I-Post-Auth-Rule is empty, and the account’s tariff and routing group apply.

To change the rule later, call updatePostAuthRule with i_post_auth_rule and the fields you change; to remove it, call deletePostAuthRule.

What’s next

• Manage post-authentication rules: every method and field.
• Route and price calls by CLI or CLD: the same idea with authentication rules, for IP trunks.
• Authentication and Routing.