by Ross McKillop
Some of you may think I rant about nothing other than CLI from reading this blog however, as my colleagues would confirm, I rant about plenty of things.
However, our support team regularly gets asked about ‘unexpected’ CLIs in our CDRs and I’d like to take this opportunity to clarify a couple of things;
A CLI IS NOT A BILLING REFERENCE
Many of our customers, and their billing providers, use the CLI to tie a call to a particular customer. However, as a wholesale provider, we allow our customers to set the CLI they require on a per-call basis.
There are, therefore, a number of cases where the CLI does not reflect the party making the call; the most common example being where a phone has a divert configured, or you’re offering an NTS service, and you present the CLI of the calling party (hence why mobile numbers often appear as the ‘from’ in CDRs), these are generally known as Type 4 CLIs.
Ultimately the CLI you send in your INVITE is the one that will appear in the CDR; this is the Presentation Number.
Types of CLI
There are ultimately several types of CLI Presentation Number;
Type 1 – Generated by the subscriber’s network provider, no need to verify further.
Type 2 – A presentation number which identifies a caller’s extension number behind a DDI switchboard. The network provider typically checks it is allocated to the subscriber.
Type 3 – A presentation number which may represent a different location to where the call originated. Verification is based on a contract between the subscriber and the network provider in which the subscriber gives an undertaking that only authentic calling party numbers will be generated.
Type 4 – A presentation number which is the onward transmission of an originating number where a call passes through a private network, e.g. DISA or NTS services. Again, the verification is based on a contractual commitment that only CLIs received from the public network will be passed.
Type 5 – A presentation number used where more than one CLI can be presented (e.g. by a call centre calling on behalf of a third party). One again, verification is based on contractual commitment that they are entitled to use the numbers they have selected.
(cf. http://stakeholders.ofcom.org.uk/telecoms/policy/calling-line-id/caller-line-id/)
We do not currently differentiate between these CLI types, as there’s no universally accepted way to do so in the SIP standard, however our own MSA requires that CLI is valid, and the customer has a right to present it. This covers all of the above use cases.
Billing Reconciliation
So, having determined that CLI is not the best way to reconcile calls, what is?
We provide two easy means to do this – trunks, and a custom ‘tag’ header;
Trunks
Simwood trunks provide granular control of individual customers; allowing you to set channel limits, rate limits, destination ACLs and even a default CLI where a valid one is not presented.
You can also use trunks to bill calls against a specific customer, as the trunk is shown in the CDRs. For customers using IP authentication for their multi-tenanted platform, you can simply set the X-simwood-trunk header on any calls to have that call associated with, and subject to any limits of, that trunk.
Trunks can be easily managed via the portal or API.
X-simwood-tag
This is a custom header for ‘tagging’ calls in the CDR, you can use this in whatever way suits you best but commonly customers put their own internal customer account reference in here; allowing them to easily filter their CDRs by a particular customer, irrespective of the CLI presented for the call.
X-simwood-tag: A000458 X-simwood-tag: Acme Products, Inc.
If you are accustomed to using CLI for billing, you may also choose to use the X-simwood-tag header to send your customers’ normal CLI, even where the From or P-Asserted-Identity headers contain something else to present to the called party, then simply instruct your billing software to treat the “tag” column as the CLI, and it will work without any further changes.
X-simwood-tag: 01632960100
CDRs
We make our CDRs available via the portal and API, and however you consume them, the Trunk and Tag are both shown on every call.
As always, we are looking to improve the service we offer, and welcome any feedback on our services, including the API and CDR formats. However, with something as critical as CDRs, we would be reluctant to introduce significant changes as maintaining compatibility with our customers’ existing applications is of the utmost importance.
