Understanding Authentication

Last updated by FlySIP SoftSwitch on December 04, 2017 16:19

Authentication is the process of establishing association between the new incoming call and some particular account in the system. There are two basic methods for performing it in the FlySIP Softswitch: using secure SIP digest and using Authentication Rules. Those methods will be described in details below. Please note that both methods could be combined together to provide advanced features (see DID assigning example below).

Secure SIP Digest-based Authentication

For Authentication of this type the new call is mapped into particular Account by performing so-called secure SIP digest authentication. In practice that means that the device or software that originates the call has username and password configured in it and those parameters are matched against VoIP Login and VoIP Password parameters of all Accounts until the match is found.

Only this type of authentication allows SIP device to register itself with the Softswitch, providing facility necessary for receiving on-net calls.

Main application of this Authentication method is providing support for connecting various SIP phones and ATAs to the Softswitch.

Rules-based Authentication

For Authentication of this type the new call is mapped into particular Account by matching the following four parameters of the new incoming call against one or more Authentication Rules that can be associated with each Account:

IP address of the device or software that originates the call;

Calling Number (CLI);

Destination Number (CLD);

Protocol (SIP, H.323, IAX2, Calling Card PIN)

Whereas the first three protocols are pretty straight for the use, and simply check the match of the incoming traffic to their type when used in the rule, the Calling Card PIN is used only when IVR application is used, and the card number (PIN) is requested.

The system first check the match of the entered number to the username/voip login of any account within the system, case no match is found, the authentication rules, configured in the system with Protocol Calling Card PIN are checked for the match.

In order for the call to match the rule each of the four parameters of the call should match with appropriate parameters of least one Authentication Rule. When one or more parameters or Rule is empty only remaining parameters are matched against incoming calls (Protocol can not be empty at any condition)

For example the first rule will match any call originated from the IP address of 1.2.3.4 and having CLI 567890 and any CLD, while the second rule will match calls with CLD of 123456789 and any CLI coming from any IP.

#	Remote IP Address	Incoming CLI/ANI	Incoming CLD/DNIS
1	1.2.3.4	567890
2	123456789

In addition, wildcard form could be used in the Incoming CLI and Incoming CLD fields by putting asterisk (‘*’) after the number, which will result in prefix matching. For example the following modification of the first rule above will match any call originated from the IP address of 1.2.3.4 and having CLI starting with 567890 (e.g. 567890123).

#	Remote IP Address	Incoming CLI/ANI	Incoming CLD/DNIS
1	1.2.3.4	567890*

When performing the match against several concurrent Rules the Softswitch also calculates so-called weights for each matching Rule in order to determine the best match. The formula is as follows:

Matching IP address adds 1.0 to the resulting weight;

Matching non-wildcard CLD or CLI adds 1.5 to the resulting weight;

Matching wildcard CLD or CLI adds 1.0 to the resulting weight;

For any matching wildcard CLI or CLD resulting weight is increased by the length of the matching part divided by the 100.

For the example if the call from IP address of 1.2.3.4, CLI of 567890 and CLD of 123456789 comes the weights would be calculated as follows:

#	Remote IP Address	Incoming CLI/ANI	Incoming CLD/DNIS	Weight
1	1.2.3.4	567890	1.0+1.5=2.5
2	123456789	1.5
3	1.2.3.4	567890*	1.0+1.0+(6/100)=2.06

As a result, the rule 1 will be selected as the best match. Please note that when there are multiple rules with the same weight matching and they are belong to different accounts, the call will be rejected due to conflicting authentication rules.

Typical Applications for Rules-based Authentication

The Rules-based Authentication can accommodate different real-world scenarios. Some of them are listed below:

VoIP Peering. Put IP address of peer’s softswitch into the Remote IP Address field.

PSTN origination. Put IP address of gateway into the Remote IP Address field. If there are multiple gateways several rules with different IP addresses could be added.

Assigning DID numbers. The DID (Direct Inward Dialing) service could be implemented by combining secure SIP digest authentication with one or more Authentication Rule that contain DID number coming from the origination gateway as the Incoming CLD field. Optionally, Remote IP Address could be used to only allow calls coming from a specific gateway to be considered as DID calls. Also, it might be necessary to apply translation rule to ensure proper routing of the call to the registered account.

Accessing Authentication Rules

To access Authentication Rules for a particular account, navigate to the Accounts menu, click on the Actions for specific Account. Authentication Rules is an action relating to the Account.