Jump to content

FILE CDR for Inbound Calls


jawaid

Recommended Posts

I have configured and use File CDR for outbound call billing, and that is working a treat. I would now like to take the next step and log inbound calls, but looking at the output, there does not seem to be a column/field that shows the extension number of the person who actually answered the call. (Even logged in as admin into the admin web portal, and viewing Call Log, does not show the actual extension which took a call). I do get the DDI number that the call came in on, but that does not help when a calls comes into the IVR/queue and gets answered by a single extension. Is there something I am missing on the config side, or has it not been included in this format. Is there anything I can change to get this?

The reason why I am using 'file' format, is that I had initially tried using CDR and JSON options, but when my logging server was either rebooted or the services shutdown, the data was lost. So using file method, the cdr is stored locally on the Vodia PBX, and then I just use sftp to download the files to my cdr server. Usually the CDR server will always be on, but I always like to test the worst case scenario.

 

Link to comment
Share on other sites

Yes. When you use any of  file, filet, fileto, fileti options, there seems to be a standard format for it.  These are the fields that are given:

domain,primary_cid,call_id,from,to,dir,type,start,connect,end,trunk,local,remote,recloc,cmc,ipadr,cqdr,ivr_ext,ivr_user

on an outbound call the local and remote fields show the correct data - in local is the extension number making the call, the remote is the number dialled.

but for an inbound call the local field shows the name attached to the extension number and the sip address, the remote field shows the number and sip address of the person ringing in. I made a test call from my mobile directly to an extension via the DDI number, and local shows my name and the sip address, in the remote shows my mobile bumber and sip address. However the call type is showing as attendant. Not sure this is relevant, but there are no IVR, ring groups setup for the DDI number. This is just set against the extension. I would have expected this type of call to just be something like incall.

Link to comment
Share on other sites

Here are examples of an outbound and inbound call:

domain,primary_cid,call_id,from,to,dir,type,start,connect,end,trunk,local,remote,recloc,cmc,ipadr,cqdr,ivr_ext,ivr_user
pbx.domain.co.uk,98021128623c1a633e-30042158,daf20cc5@pbx,Jawaid (3501),07768 114xxx,O,extcall,20220324071341,20220324071344,20220324071351,Outbound Trunk,3501,+447768114xxx,recordings/pbx.domain.co.uk/3501/20220324-071344-o-3501.wav,,udp:51.68.195.71:5060,,1,1
pbx.domain.co.uk,614c40702d66f6017a6ee5ba5d3b8a2b@51.68.195.71:5060,614c40702d66f6017a6ee5ba5d3b8a2b@51.xx.xxx.xx:5060,07768 114xxx,Jawaid (44128257xxxx),I,attendant,20220324071434,20220324071437,20220324071445,Inbound Trunk,"Jawaid" <sip:44128257xxxx@pbx.pathwaytelecom.co.uk>,"07768 114xxx" <sip:+447768114xxx@pbx.domain.co.uk>,,,udp:51.xx.xxx.xx:5060,,1,

 

I have changed some of the values to make the calls anonymous, but the important information is still shown. The first call is an outbound call and the local field is correctly showing the extension 3501. The second call is an inbound call is an inbound call from my mobile number (starting with 07768) which is ringing the extension 3501 directly, not via any ivr/ring groups.. The local field in this case is showing my name with the sip address rather than the local extension number answering the call.

Even if it showed my name and extension number, I could extract the number from it.

Hope this helps. Once this is hopefully working, I will then try calls via auto attendant/ivr/ring groups. 

Link to comment
Share on other sites

I think the problem is that you are using the file: scheme. That scheme has hard coded fields. Could you try the cdr: scheme instead? Then you can control what is being written. In 68.0.13.beta (currently available for CentOS64 and Debian64) we have added the $(ivr_ext) field that should explicitly contain the extension.

Link to comment
Share on other sites

Yes that is a totally valid point. When testing this here, it did work however:

  • You might have to write all records. Filtering by trunk does not work because that the CDR generation is leg based, and the leg that is associated with the might not have the extension. At least try to write all records.
  • The other practical problem that we found is that the account number is written as index number. This Is not very helpful, and we'll change that to the extension number in the next build.
Link to comment
Share on other sites

15 hours ago, jawaid said:

Could you not in the next build add the $(ivr_ext) to the file format?

We will include that possibility in the next major release. In the 68 branch we will just change the ivr_ext field so that this will contain the extension number, if available. This should solve your problem. This will be in 68.0.14 once it is released.

Link to comment
Share on other sites

  • 4 weeks later...

Hi,

I have tested v68.0.14 and the ivr_ext field is now being properly populated with the extension number. Thanks.

My only slight issue now, is that if an inbound call is answered on extension A, then transferred to Extension B, the filet method, only gives the cdr for the last person who dealt with the call, rather than a cdr for the call to Extension A as well as a cdr for Extension B. 

I have test the same transfer for an outbound call and just get the single cdr.

Any ideas if there is a way of getting a cdr, per leg of the call using the 'file' cdr option? My cdr reporting solution can log these calls and I can report on inbound/outbound calls, however I cannot provide an accurate report when calls are transferred between extensions.  

Link to comment
Share on other sites

Well, there are several ways to report the CDR. The "simple" CDR might not be sufficient for your needs any more. If you are just interested in some calls for investigation purposes, you can just in the tenant CDR click on the CDR record where you can see more details about the call. If you want to collect the duration of each call leg, I would suggest that you take a look at the JSON-based call records which report each call leg with a lot more detail. That would require some external scripting, though. 

Link to comment
Share on other sites

I have tried the various methods, and found the 'file' method to be the best, as if the call accounting/cdr server goes down, then I can still get the CDR when it comes back up, ensuring that I do not lose any data for charging customers for outbound calls. With the other methods this is not possible as the data is not stored locally. 

Unless the other methods could store to a local folder, I can then ftp/sftp the records to my accounting server. I don't require anything more complicated, just the fact that when a call is transferred a record is sent for that leg, so that the call can be attributed to the correct extension.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...