Programmable SIP Trunking

  • updated 1 yr ago

The VSXi can be used to provide authenticated (pilot registration) and un-authenticated (peering) SIP trunks with features such as:

  • Extension to Extension dialing
  • Call Forward Always (CFA)
  • Call Forwarding Not Reachable (CFNR)
  • Failover/Redundant Trunk

This guide provides GUI and API guidance to streamline the on-boarding of new customers. As of this moment this guide is scalable for up to 10,000 customer SIP trunks.

This guide assumes the following:

  • Every customer has one Trunk ID with one or more IPs.
  • Every customer will be assigned their dedicated Route Table.
  • Every customer will be assigned their dedicated Digit Mapping Table.
  • All customers will use a universal Stop Route Profile.
  • All customers may use a universal Call Forward Not Reachable mechanism.
  • All customers may share the same Service Port.
  • While not required it is best practice to keep Trunk/Resource, Route Tables and Digit Mapping Table IDs the same (e.g. Trunk ID 5000, Route Table 5000 and Digit Mapping Table 5000).

For API guidance specific examples are included in this article, however, if you need to refer to our complete API guide please go here.

Authenticated or Non-Authenticated

A SIP trunk can be configured with SIP registration or without SIP registration. SIP registration is required if a customer's PBX IP address is not static (i.e. it may unexpectedly change).

An Authenticated trunk uses the VSXi "Dynamic Peering" Resource Type. A non-Authanticated trunk will use "Peering" Resource Type.


For authenticated trunks only it will be required to add SIP user credentials the customer will use to register their equipment. This is done under Resources > Registrar. It is highly encouraged to specify the customer's Trunk ID with their SIP credentials for the strongest security.


API calls

Create or update resource/Trunk ID

curl -u $user:$pass -X POST -k -T file.xml

Create or update user credentials

curl -u $user:$pass -X POST -k -T file.xml

Delete resource/Trunk ID

curl -u $user:$pass -X DELETE -k -T file.xml

Delete user credentails:

curl -u $user:$pass -X DELETE -k -T file.xml

Extension to Extension dialing

To enable extension dialing within a SIP trunk all that is needed is that the customer's SIP trunk is configured with a dedicated routing table. Upon establishing the customer's extension pattern (e.g. 3-digit, 4-digit, 5-digit) a short-length default route pointing to the customer's SIP trunk can facilitate this traffic.


API Calls

Create route table

curl -u $user:$pass -X POST -k -T file.xml

Add or Update route

curl -u $user:$pass -X POST -k -T file.xml

Delete route table

curl -u $user:$pass -X POST -k -T file.xml

Delete route

curl -u $user:$pass -X DELETE -k -T file.xml

Call Forward Always

CFA is accomplished by translating all DIDs or DID-per-DID received calls to on-net or off-net numbers. This is accomplished by assigning a Digit Mapping Table (DMT) per customer. While it is possible to share a DMT for many customers, assigning a DMT per customer will give you the flexibility to customize the desired forward triggers per customer such as (forward all received calls instead of to specific DIDs).


or all calls:

API calls

Create customer DMT table

curl -u $user:$pass -X POST -k -T file.xml

Create DMT entries for CFA

curl -u $user:$pass -X POST -k -T file.xml

Delete DMT entries for CFA

curl -u $user:$pass -X DELETE -k -T file.xml

Delete customer DMT table

curl -u $user:$pass -X DELETE -k -T file.xml "https://SERVER_IP:8888/SSConfig/webresources/delete/digit_mapping_index"

Call Forward Not Reachable

CFNR is an event that will occur if the customer's SIP trunk is down for some reason. An example could be that the customer ISP or on-prem network is currently experiencing an outage. In those cases it is desired to use an offnet number such as a wireless number.

CNFR can be used in combination with a failover trunk. If the customer supports both locations then only if both locations/SIP trunks are unreachable then try an offnet number.

CNFR is accomplished via a universal loop trunk many customers can use which has access to a preferred list of downstream carriers. As CNFR occur, the customer trunk will then reach a PSTN access to complete CNFR. The customer's Trunk ID will need the following:

  • Policy: top-down.
  • OPTIONS Polling: enabled
  • Stop Route Profile: SIP Trunking Only is an arbitrary Virtual IP for this example only and would need to match a real Virtual IP address on your VSXi that also has the same VIP in the FQDN/IP section.

Failover/Redundant Trunk

For customers with redundant locations / ISPs the configuration will be similar to the CNFR scenario where the customer's Trunk ID is configured with a top-down policy. In this scheme the preferred/primary site will occupy FQDN/IP #1. The secondary/backup site will occupy FQDN/IP #2. Lastly if CNFR is enabled the looparound IP will be last.

Additional Questions

If you were previously using the Digit Mapping Table to serve other functionalities like digit normalization, our team suggests using the in-resource ingress translation or a SMC profile. Please reach out to us with your specific needs.

Reply Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
Like Follow
  • 1 yr agoLast active
  • 267Views
  • 2 Following