Call authorization

On this panel you can add new authorization rules for call processing. This is useful when calls arrive from gateways which don't support digest authentication.

Click Add to define a new rule. Then click Save.

The order of rules is important. The topmost rule has the highest priority. Since the "first match" principle works here, arrange the more specific rules before the less specific ones. For example, move the "call comes from IP 5.6.7.8 and CLI starts with 44" rule to the top of the list and more generic ones such as "call comes from IP 5.6.7.8" to the bottom.

To re-sort the rules, drag the rows using Reorder to place them in the order you want.

If you set multiple conditions, this rule applies only if the call request meets all of them. For example, you set two conditions: "1.2.3.4" for the remote IP and "5789#" for the CLD. The rule applies only if both conditions are met: the call comes from IP address 1.2.3.4 and the destination phone number starts with 5789#.

If no rule works for a given call request, then digest authentication is used.

Manually added rules take precedence over auto-generated rules.

1. Call request is matched against IP, CLI and CLD if defined:

Type the IP address of the remote party. This can be an IP address or an IPv4 network prefix in CIDR notation (e.g., 192.168.99.0/24).

Note that the "signaling" address is used, e.g., the IP address from which PortaSIP receives the INVITE, not the information in the INVITE request itself, such as "Contact" or "From" headers.

This is the phone number of the calling party.

The field can contain:

• Digits;

• The "*" and "#" symbols;

• "%" – this wildcard is for any number of symbols;

• "_" or "x" – these are equivalent wildcards for one symbol.

For example, if you specify "1334#," the rule is applied only if the calling phone number starts with 1334#.

Note that the phone number in the "From" header of the INVITE request is used.

This is the phone number called.

The field can contain:

• Digits;

• The "*" and "#" symbols;

• "%" – this wildcard is for any number of symbols;

• "_" or "x" – these are equivalent wildcards for one symbol.

For example, if you specify "1234#," the rule is applied if the destination phone number starts with 1234# only.

Note that the phone number in the Request-URI is used, not the number in the "To" header of the INVITE request.

2. User name is defined with:

• CLD – the User-Name attribute is the phone number, called a CLD. The CLD is part of the Request-URI placed before @. Also, it is usually reflected in the "To" header field.

  Note that the CLD parameter for the User-Name attribute is always taken from the Request-URI.

• CLD Tech-Prefix – the User-Name attribute consists of the first part of the CLD parameter ending with # (including # itself.) For example, a call with the To header (CLD) equal to 77788#12125551234 is authorized as 77788#.

• CLD Tech-Prefix and IP – the User-Name attribute consists of the first part of the CLD parameter ending with # (including # itself) and the IP address prefixed with @. For example, a call from IP address 122.255.109.2 with the To header (CLD) equal to 080099#12125551234 is authorized as 080099#@122.255.109.2).

• CLI – the User-Name attribute is the phone number of the party calling.

• CLI (PAI if no CLI) – the User-Name attribute is the phone number of the party calling. If the CLI is not specified, the User-Name attribute contains the value from the PAI (P-Asserted-Identity) header.

• CLI (RPID if no CLI) – the User-Name attribute is the phone number of the party calling. If the CLI is not specified, the User-Name attribute is taken from the RPID (Remote-Party-ID) header.

• CLI Tech-Prefix – the User-Name attribute consists of the first part of the CLI parameter ending with # (including # itself). For example, a call with the From header (CLI) equal to 977#16045551234 is authorized as 977#).

• CLI Tech-Prefix and IP – the User-Name attribute consists of the first part of the CLI parameter ending with # (including # itself) and the IP address prefixed with @. For example, a call from IP address 122.255.109.2 with the From header (CLI) equal to 977#16045551234 is authorized as 977#@122.255.109.2).

• Digest – digest authentication is applied to obtain the User-Name attribute.

• IP – the User-Name attribute is the IP address from which PortaSIP receives the INVITE.

• PAI – the User Name attribute contains the value from the PAI header.

• PAI and IP – the User Name attribute consists of the value from the PAI header and the IP address from which PortaSIP® receives the INVITE prefixed with @. For example, a call from IP address 122.255.109.2 with the PAI header 12349874567 is authorized as 12349874567@122.255.109.2).

• PCI (P-Charge-Info) – the User-Name attribute consists of a number from the P-Charge-Info header and the IP address prefixed with @. For example, a call from IP address 122.255.109.2 with the P-Charge-Info header sip:+12349874567@example.com is authorized as +12349874567@122.255.109.2)

• PSU (P-Served-User) – the User Name attribute contains the value from the PSU header.

• Remote IP – the identity for authentication is an IP address taken from a custom Remoteip SIP header. Note that this IP address is used "as is," without validation.

• RPID – the User Name attribute contains the value from the RPID header.

• Trunk Group ID (TGRP) – the User-Name attribute contains the value from the "tgrp" part of the "Contact" header.

If you want to use any of these authorizations: PAI, RPID, PCI (P-Charge-Info), CLI (PAI if no CLI) or CLI (RPID if no CLI), make sure the privacy_incoming option is enabled on the Configuration server. Otherwise, B2BUA ignores SIP privacy headers such as "p-asserted-identity" (PAI), "remote-party-id" (RPID) and "p-charge-info."

To discuss creating other possible authorization methods, contact support@portaone.com.

3. Changes to user name and call settings before authorization:

This is the Python regular expression that adjusts the user-name that arrives in a call request to match the account ID in PortaBilling. The header from which PortaSIP retrieves the identity for translation is defined by the type of call authorization scenario. For example, for authentication by CLI, the number is taken from the From header.

Select a service policy to apply for every new call.

To create a service policy, go to Service catalog > Service policies.

Click Show to open the service policy on the new tab.

To delete a rule, click Delete .

A call authorization rule is automatically generated when you create:

• Accounts with an ID containing IP.

• Connections with the VoIP from Vendor type containing remote IP. Note that if vendor authorization is defined for the connection, a rule won't be generated.

• Nodes. By default, IP authentication is applied to all nodes in the given environment. To override an autogenerated rule, create your own one on the Manually added panel if, for example, you need to do authorization based on CLI/CLD for calls coming from your PSTN gateway.

When a new record is created, a new rule automatically appears at the top of the list.

Note that manually added rules always take precedence over autogenerated rules if the IP field for these rules is the same.

This is the IP address that is used for authorization.

This shows the entity such as account, vendor connection or node.

This is the entity name, which is also a link that redirects you to the Edit panel.

To delete a rule, click Delete .