Jump to content

CDR Output


Bill H
 Share

Recommended Posts

We are using the Metropolis.com Office Watch CDR Call Accounting software.

 

It runs on the same server as PBXNSIP and receives its data from PBXNSIP via an IP Port

 

It can also display the Raw Data it recieves as a troubleshotting tool.

 

We currently use the string $w$5e$10c$5d$o$x$y which sends the following:

 

Date Extension Caller ID of Remote Party Duration of Call IN or Outbound Direction of Call Originating Trunk Destination Trunk

 

This works well for calls to Extensions.

 

We also have ACD Groups that answer calls when they come in on our T1 Gateway.

 

I have tried all the possible $(String) options in the WIKI and using the Raw Data Tool, can not seem to see any ACD related data out of PBXNSIP.

 

The ACD's are set up as Accounts in PBXNSIP as are the Extensions.

 

Does anyone have an idea as how to get the ACD info????

 

Thanks,

Bill H

Link to comment
Share on other sites

Can Metropolis show information like waiting time and that this call was a ACD call? How should it look like?

 

 

As we already know, Metropolis can't show any ACD info until it receives it from PBXNSIP.

 

I can not find a way to have PBXNSIP send any info about an incomming call answered by an ACD.

 

The $e string inserts the Extension number but not the ACD number in the CDR.

 

Of course the ACD is not an extension but rather an Account.

 

If I remember correctly, the older PBXNSIP CDR output would send (by UDP) the Account Number instead of the Extension Number.

 

I was able to work with that. But now the Account Number seems to been gone.

 

So the question is --- What String Character is used in the XML CDR String to get the ACD (Account Number?) that answered an incomming call???

 

 

Thanks,

 

Bill H

Link to comment
Share on other sites

  • 2 weeks later...

There is already a difference between the timestamp when a call was answered by and agent and the timestamp when the call was connected. The difference is the waiting time in the queue (if the queue connects the call immediately, which is programmable). See http://wiki.pbxnsip.com/index.php/Simple_CDR_Format.

 

But I must say I am also not 100 % satisfied with the statistics that we get on the ACD. I think the best would be to shoot an email for every call. The email per call has the big advantage that the load gets distributed over the day, and we don't have this huge email at midnight. Especially very busy call centers love to have these statistics, and then the huge email is a problem. Then the midnight email will really just summarize the day and for the details operators need to look into the emails.

Link to comment
Share on other sites

There is already a difference between the timestamp when a call was answered by and agent and the timestamp when the call was connected. The difference is the waiting time in the queue (if the queue connects the call immediately, which is programmable). See http://wiki.pbxnsip.com/index.php/Simple_CDR_Format.

 

But I must say I am also not 100 % satisfied with the statistics that we get on the ACD. I think the best would be to shoot an email for every call. The email per call has the big advantage that the load gets distributed over the day, and we don't have this huge email at midnight. Especially very busy call centers love to have these statistics, and then the huge email is a problem. Then the midnight email will really just summarize the day and for the details operators need to look into the emails.

 

 

I looked at http://wiki.pbxnsip.com/index.php/Simple_CDR_Format and I did not see any $String there that would indicate that the call was initially answered by an ACD.

Link to comment
Share on other sites

There is already a difference between the timestamp when a call was answered by and agent and the timestamp when the call was connected. The difference is the waiting time in the queue (if the queue connects the call immediately, which is programmable). See http://wiki.pbxnsip.com/index.php/Simple_CDR_Format.

 

But I must say I am also not 100 % satisfied with the statistics that we get on the ACD. I think the best would be to shoot an email for every call. The email per call has the big advantage that the load gets distributed over the day, and we don't have this huge email at midnight. Especially very busy call centers love to have these statistics, and then the huge email is a problem. Then the midnight email will really just summarize the day and for the details operators need to look into the emails.

 

 

I still would like a midnite email that summarizes all accounts - very useful call detail record. I can't think of one practical way of storing 695 emails on a daily basis for one heavy user. Please tell me you'll implement the daily summary cdr's.

 

Thanks

Link to comment
Share on other sites

I still would like a midnite email that summarizes all accounts - very useful call detail record. I can't think of one practical way of storing 695 emails on a daily basis for one heavy user. Please tell me you'll implement the daily summary cdr's.

 

Thanks

 

 

2 questions:

 

Do you understand my feature request fully?

Are you planning on enabling that feature soon?

 

I have several customers that would benefit from this ASAP.... I would be a hero.

 

Thank you very much in advance.

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.

 Share

×
×
  • Create New...