Sippy's PIN-Less dialling relates to our Trusted CLI Authentication feature. Trusted CLI corresponds with an Account's 'Trusted Numbers' list, that is either entered manually by the customer through their personal portal, or through the Automatic CLI Registration extension. Configuration of PIN-Less dialling complements your Calling Card IVR Application setup.


To configure the Pinless calling card application in Sippy, you have to create the following steps:

1. Create the basic configuration:
  • create vendor/connection;
  • destination sets;
  • routing group;
  • tariff;
  • service plan;
  • account with different Username and Voip login for the security reason (use username with letters);

See our video tutorials how to make a basic configuration:

2. Create IVR application:

  • open the IVR applications page;
  • create the appropriate application with Calling Card type;
  • Save&Close your application;
  • Open it again and add the advanced parameters for your application;

See how it could look by default:

Here it is the list of useful options for Pinless scenario that you can easily add to your application:




Enable CLI Registration

If the 'CLI Registration' sub application is enabled, then the corresponding IVR prompt will be played and the user will be asked to link its <ANI\CLI> number as the 'Trusted Number' to the used <Calling Card\PIN> for further possible PINless dialing.


Automatic CLI Registration

After calling card has been entered successfully, add the current CLI to the list of trusted CLIs for this calling card.


Silent Automatic CLI Registration

When this option is set to False the user will be prompted if he wishes to register his phone number (new in 1.7.1).


CLI Registration Menu Extension Number

Extension number for the CLI Registration Subapplication



Trusted CLI Authentication

CLI mapping is trusted so the PIN is never asked


Minimum Valid CLI Length

Minimum CLI length that is allowed to trigger the Automatic CLI Registration.


Allow Own Accounts Only

Option applicable for any IVR application since 4.4, if enabled then only accounts of the customer that has created this IVR application would be allowed to use it.


PIN-less CLI Authentication 

Option applicable for any IVR application since 4.4, if any kind of CLI authentication has succeeded then do not ask for PIN even if it is set. The CLI authentication includes CLI As Card Number, Trusted Numbers and Smart Dial.


CLI As Card Number

Try to use CLI as card number first before other methods


Use VoIP Login As Card Number

Look for a calling card in the accounts table by the authname field (normally the username field is used). It is very important option when you need to hide the card number in the SIP trace. In such case it is usefule to use different Voip Login and Username for the account.


 3. Prepare the DID number for incoming calls to Sippy and tie it with IVR application:

  • order the DID number from some DID provider;
  • point calls from DID provider to the IP of your SIPPY environment (it should be made from the DID provider side).
  • in SIPPY environment you will authorize the incoming calls via DID pool section.  
  • create the appropriate  DID number in the DID Pool with INCOMING_DID/CLD that system will use for the authorization purposes. That means that the number in field TO of the INVITE request from DID provider, should match INCOMING_DID/CLD.
  • create VENDOR/Connection with IP of your DID provider they'll be sending you the calls from and assign this vendor/connection in the properties of the created DID number.
  • Assign Calling Card application to the DID number;

Where numbers are meaning the following:
  • 1,2,3  - mandatory fields.
  • 4,5 - not mandatory, but important in scope of security reason on step of authorization;
  • 6,7- in case of demand only;

4. Tying Charging Groups with DID numbers

If you want to charge your accounts for the incoming calls additionally. You can create selling charging group and assign it under you DID number that is located in section DID pool.


Parameters explanations for Selling charging group:
  • Setup Fee: commission that is applied at the end or beginning of billing period depending on billing type configured in service plan (post-paid or pre-paid) to the account that has the DID assigned;
  • Monthly Fee: commission that is applied on monthly basis to the account that has the DID assigned;
  • Free Seconds: amount of free seconds that are given to the caller after Interval 1 before first Interval N, between Interval 1 and first Interval N;
  • Grace Period: period in scope of Interval 1 that the caller won't be charged for the call. In case the call lasts longer then Grace Period, the regular charge of Interval 1 is applied to cover the Grace Period;
  • Connect Fee: fixed commission that is taken from the balance of an account after every single call made;
  • Post Call Surcharge %: extra charge that is applied to the cost of the call. It's extra % added to the final cost charged from account's balance;

See the additional information about charging groups in the following documentation:

5. Adding/Deleting Trusted Numbers to Account


  • Simply add Source Phone Number, select Voice Menu Language to nominate IVR Language relating to CLI, and enter Description as required for user identification purposes.
  • Sippy supports 12 IVR Languages for this application as can be seen in the following image.
  • Save Trusted Number by selecting the green "+" Action, or by clicking "Save".
  • Additional Numbers can now be recorded on the Account following the above steps.

  • Deleting Trusted Numbers from Account is done by locating assigned number and selecting the Delete icon
  • Editing Trusted Numbers can be achieved through selecting the Edit icon

6. Adding/Deleting Trusted Numbers from Personal Portal

  • Manually entering Trusted Numbers from the User's own Account portal. Account Web Interface includes the same operation to add Trusted Number to Account as through Account's Action menu, listed above.

Note: Account Menu options as viewed above can be enabled or restricted as operator requires through the use of Account Classes.