For some time now we’ve enabled named trunks to be configured via the API, allowing service providers to create dedicated trunks for individual customers.
Where the customer has direct control over their own outbound settings (e.g. an on-site IP-PBX or Hosted vPBX solution) it is common for invalid CLIs (from mis-configured handsets presenting internal extension numbers, for example) to be presented.
We’ve introduced a number of new options, which can be configured via the API, for trunks, to allow better control and to attempt to alleviate the above problem.
All trunks can now be configured with a Default CLI which will be presented where no CLI, or an invalid CLI, is received. We would recommend this is set to the ‘switchboard’ or ‘main presentation number’ for all of your customers – avoiding any invalid CLIs, whilst still allowing the flexibility to set your own CLIs as required (e.g. for DDIs) and pass the CLI of a caller when a call is forwarded.
Additionally, we provide the ability to force the default CLI for all calls. This is ideal where a trunk is being used directly on an end-user device or on an IP-PBX outside of your own control and ensures that the customer cannot present an invalid number or use the service to “spoof” caller ID.
Another use of this is with our IDA Services – as an IDA user is a trunk like any other, you can set a custom CLI on calls made from the IDA. For example, this could be used to allow your customers’ home workers based where reliable VoIP services are unavailable (perhaps in a rural area) to make outbound calls billed to your customer and presenting the company CLI rather than their home number.
We enable these functions in the API for our customers, but for obvious reasons stipulate such functionality should not be exposed directly to an and user in their own portals or interfaces.
As we now offer registration of SIP endpoints for inbound calls (which, again, are associated with a trunk) it is now possible to disable the inbound element of a trunk separately from the outbound – thus providing more flexibility to provide ‘inbound only’ services or for credit control (disabling a customer’s outbound service without impacting their inbound calls).
To make use of these new features please see the updated API documentation.