...
...
...
...
...
...
...
Below is an extract of a CDR file as viewed in Edit Pad as well as Excel:
CDR File in EditPad Text Editor (click to display)
CDR File in Microsoft Excel (click to display)
...
...
For Example, reading the first call record from the extract above we can see the following:
| how long did the call last for | 3 seconds |
|---|---|
| when did the call start | 12:41 GMT |
| what phone number was called | 12896980000 |
CDR File in Microsoft Excel (click to display)
We must now figure out how each field (column) relates back toy our customer that we would like to charge the call to. We will do this in the next section Business Logic for Identifying Customer Calls.
| Anchor | ||||
|---|---|---|---|---|
|
Now that we have a clear understanding of the fields in our CDR file we can take a look at how we will determine the Business Logic that is needed to identify each CDR record to a customer.
| Info | ||
|---|---|---|
| ||
The information required for identifying calls from the CDR file to your customer will come directly from one of more fields in the CDR file. If your CDR file does not have enough information for you to identify your customers then you must go back to the PBX, SIP Server, etc and reconfigure the data that will be produced in the CDR file. |
One of the simplest and most common ways of identifying calls to your customers is to use the [Calling Number] field. In our sample CDR file extract above this would be the [from-uri] field. Simply put we are saying that we will identify our customer calls by using the number from which the call was made (or the Caller ID).
...
| Panel | ||
|---|---|---|
| ||
We will use the [Calling Number] to identity our customers calls. This means that if the [Calling Number] matches our Customers Caller-ID then we will assume the call was made by that Customer and therefore charge the call to the Customer. Our Customer John Doe makes calls from his mobile phone 647 865 5000, as such any record in our CDR file with the [Calling Number] = 647 865 5000 will be identified to John Doe. Taking a look at the CDR file extract (see image below), we can see that there are 2 calls that should be charged to John Doe based on our Business Logic. |
| Panel | ||
|---|---|---|
| ||
We will use the [Called Number] to identity our customers calls. This means that if the [Called Number] matches a specific number then we will assume the call was made by that Customer and therefore charge the call to the Customer. Our Customer John Doe makes calls to mobile phone 905 200 5998, as such any record in our CDR file with the [Called Number] = 905 200 5998 will be identified to John Doe. Taking a look at the CDR file extract (see image below), we can see that there are 4 calls that should be charged to John Doe based on our Business Logic.
|
| Panel | ||
|---|---|---|
| ||
We will use the [Source IP Address] to identity our customers calls. This means that if the Source IP Address] matches a specific IP Address then we will assume the call was made by that Customer and therefore charge the call to the Customer. Our Customer John Doe makes calls from his network which has a source IP Address of 60.20102.106, as such any record in our CDR file with an IP Address of 60.20102.106 will be identified to John Doe. Taking a look at the CDR file extract (see image below), we can see that there are 5 calls that should be charged to John Doe based on our Business Logic. |
...
| Anchor | ||||
|---|---|---|---|---|
|
Now that we understand the anatomy of CDR file and have defined our business logic for linking calls to our Customers, the last thing we have to do is convert this Logic into a format that the CDR2Cloud will understand.
We do this by adding the Business Logic to the Customers account and this is called the Writing the Authentication Code (or Auth Code) on the Customers Account.
| Info | ||
|---|---|---|
| ||
For more information on writing Authentication Code on a Customer Account please see the Writing Auth Code topic. |
Lets take a look at each of the 2 Examples above to see how they will translate into an Auth Code on he Customers Account
| Panel | ||
|---|---|---|
| ||
In this Example our Business Logic for associating a CDR record (call) to a Customer was based on the [Calling Number] matching our Customers Caller-ID 647 865 5000 If the [Calling Number] is equal to 647 865 5000 then we will assume the call was made by that Customer and charge the call to the Customer. SOLUTION #1
Authentication defined on Customer A/C using [Calling Number] field (click to display) Notice that because we are writing the matching expression in Regular Expression notation we write the telephone number enclosed in parentheses. This is the way to write a Regular Expression markup for matching a complete string, so we are saying the call should be charged to this customer if and only if the [Calling Number] field matches the entire string between the parentheses (6478655000) SOLUTION #2 You will notice that in the Brekeke CDR file the callers number is represented in SIP URI notation, i.e. However in Option #1 we were able to use the CDR2Cloud filed called [Calling Number]. This is because the CDR2Cloud system reads the Brekeke CDR files [from-uri] field and converts it from SIP Notation to a simple number format and places it in a CDR2Cloud field called [Calling Number]. This allowed us to ignore the [from-uri] and work with the [Calling Number] field. We could have used the [from-uri] field directly but it would require us to write a slightly more complicated Regular Expression as we now have to evaluate the name part of the SIP URI
Authentication defined on Customer A/C using [fromUri] field (click to display) Both Option#1 and Option#2 will yield the same results, i.e. associating a CDR record (call) to a Customer was based on the [Calling Number] matching our Customers Caller-ID 647 865 5000 |
| Panel | ||
|---|---|---|
| ||
In this Example our Business Logic for associating a CDR record (call) to a Customer was based on the [Called Number] matching specific number If the [Called Number] is equal to 905 200 5998 then we will assume the call was made by that Customer and charge the call to the Customer. SOLUTION #1
Authentication defined on Customer A/C using [Called Number] field (click to display) Notice that because we are writing the matching expression in Regular Expression notation we write the telephone number enclosed in parentheses. This is the way to write a Regular Expression markup for matching a complete string, so we are saying the call should be charged to this customer if and only if the [Called Number] field matches the entire string between the parentheses (9052005998) sip:19052005998@vitelity:15060 SOLUTION #2 You will notice that in the Brekeke CDR file the called number is represented in SIP URI notation, i.e. However in Option #1 we were able to use the CDR2Cloud filed called [Called Number]. This is because the CDR2Cloud system reads the Brekeke CDR files [to-uri] field and converts it from SIP Notation to a simple number format and places it in a CDR2Cloud field called [Called Number]. This allowed us to ignore the [to-uri] and work with the [Called Number] field. We could have used the [to-uri] field directly but it would require us to write a slightly more complicated Regular Expression as we now have to evaluate the name part of the SIP URI
Authentication defined on Customer A/C using [toUri] field (click to display) Both Option#1 and Option#2 will yield the same results, i.e. associating a CDR record (call) to a Customer was based on the [Called Number] matching 905 200 5998 |
| Panel | ||
|---|---|---|
| ||
In this Example our Business Logic for associating a CDR record (call) to a Customer was based on the [Source IP Address] matching our Customers IP. If the [Source IP Address] is equal to 60.20102.106 then we will assume the call was made by that Customer and charge the call to the Customer. You will notice that in the Brekeke CDR file the [from-uri] field is represented in SIP URI notation, i.e. We must instruct CDR2Cloud to check the IP Address of the [from-uri] for each record and compare it to the IP Address that we will define for the customer
Authentication defined on Customer A/C using [fromUri] field (click to display) |
...