Often calls arrive to the network from gateways which do not support digest authentication. In this case, it is necessary to engage different modes of billing (by tech-prefix, by IP address, etc.) on the PortaSwitch® side. The Call Handling screen provides administrators with an easy way of defining a list of rules allowing PortaSIP® servers to handle incoming calls in the desired manner. It gives them a flexible choice of several authorization methods and the ability to configure rules directly from the interface, instead of time-consuming manual configuration. Rules are listed in order of priority, with the topmost rule having top priority. If no rule works for a given call request, digest authentication will be used.
An authentication rule combines an authorization method and call parameters. The different methods of user authentication are described in the Voice Calls Processing section of the PortaSIP Administrator Guide. When adding a rule, you can choose one of the following methods:
NOTE: The CLD parameter for the User-Name attribute is always taken from the Request-URI.
NOTE: To discuss creating other possible authorization methods, contact the support@portaone.com.
Let’s take an example:
The PortaSIP® server receives a call initiation (INVITE) request from IP address 11.22.33.45. This INVITE request contains call information, including the caller’s phone number (often referred to as CLI or ANI) 977#197800065 and the called phone number (referred to as CLD or DNIS) 12065551234.
The administrator has defined the list of authentication rules. The rules are checked in sequence and, when the first match is found, the corresponding rule is used to handle the call.
In this case, the first rule will be skipped (since although there is a match by IP address, CLD does not match), and the second rule will be used. As a result, PortaSIP® will perform authentication based on CLI, using 977#197800065 as the identification string.
Due to this “first match” principle, it is important to rank more specific rules before less specific ones. If, in our example, we were to swap the third and second rules, then the IP 11.22.33.45 CLI 977#% rule would never be used, since the processing of every such call would stop at the second rule.
Please consult the Call Handling Rules section of the PortaSIP® Administrator Guide for more details on how PortaSIP® processes the call if multiple call handling rules satisfy the call request.
NOTE: IP authentication is applied by default for all nodes in the given environment. Think of it as if these rules were being added to the bottom of the list automatically in order to save you time. You can still override this by creating your own rule; for instance, if you need to do authorization based on CLI / DNIS for calls coming from your PSTN gateway. Since this rule is ranked higher, it will take precedence.
This tab allows you to view the list of all manually specified rules and to create new ones.
To add a new authorization rule on the Call Handling page, click Add, then fill in the required information and click Save. The newly added rule will appear at the top of the list.
Field | Description |
---|---|
IP |
Remote IP from which a call request is received. This field can contain an IP address or an IPv4 network prefix in CIDR notation (e.g. 192.168.99.0/24). |
CLI (ANI) |
CLI (ANI) pattern. This field can contain:
If this field is empty in the rule, no filtering by CLI (ANI) is done. |
CLD (DNIS) |
CLD (DNIS) pattern that can contain the same symbols as in the field above. If this field is empty in the rule, no filtering by CLD (DNIS) is done. |
Translation rule |
The Python regular expressions that are used to adjust a user-name arriving in a call request for authorization. |
Authorize By |
Select one of the authorization methods.
Please note that 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), the privacy_incoming option must be enabled on the configuration server web interface. Otherwise, B2BUA ignores the SIP privacy headers (i.e. “p-asserted-identity ” (PAI), “remote-party-id” (RPID), “p-charge-info” in this case). |
You can manage rules using the following controls:
Control | Description |
---|---|
Edit this rule. |
|
Insert a new rule above this one. |
|
Move this rule one level up. |
|
Move this rule one level down. |
All changes made to this list (e.g. rule added or changed, changed order of priority) are automatically provisioned by the system. This means that updated authentication information is sent to all PortaSIP® nodes in this environment (those which have PortaOne in the Manufacturer field and PortaSIP® in the Type field). Note that the call handling rules update may take several minutes.
NOTE: Manually added rules have a higher priority than autogenerated rules, in case the IP field for these rules is the same.
On this tab you can view the list of rules that were generated automatically while creating accounts with an IP address in the ID field. When a new account is created, the list of rules is updated accordingly (a new rule is created at the top of the list). You can also delete selected rules using this tab.
Using this tab, you can view the list of rules that were generated automatically while creating a connection (VoIP from Vendor type) with the specified remote IP.
NOTE: If a vendor authorization has been defined for the connection, a rule will not be generated.
Using this tab, you can view the list of rules that were generated automatically while creating nodes.
By default, IP authentication is applied to all nodes in a given environment. You can still override an autogenerated rule by creating your own one; for example, if you need to do authorization based on CLI / DNIS for calls coming from your PSTN gateway. Since the manually specified rule is ranked higher, it takes precedence.