Multiple entries for same call in Call History

In the UCP’s Call History, every call is duplicated 3 or 4 times. How do I fix that?

The “calls” are like 5 to 15 secs, and the last entry is the real call.
Does anyone have a clue or lead here? This happens for all extensions. I think maybe it is in Asterisk, because they also show on the call history list on my polycom phones.

Apparently, this is an issue with Asterisk. Here, they speak of it being a CDR issue in Asterisk, and even a patch was submitted.

But is there a way to fix it in FreePBX 14 (Asterisk 13.22.0 )? Is there some setting I can tweak?

Are your referring to the UCP call history or the CDR call listing?
If the CDR, I agree it is pretty useless as written. I was the one that started that posting. Basically the response from 1 or 2 people was that it was great as is. I have 20-25 duplicate entries for each call.
The UCP shortfall is only calls to that one extension are listed.
I wish that the old CDR was available or at least a check box to eliminate all of those duplicate entries.

I’m talking about the UCP Call History.

Why would we ever want multiple entries for the same call in our call history? It doesn’t make any sense to the users.

Because it’s not the same call. It’s a bunch of related, bridged calls.

Asterisk is a Back to Back User Agent. This means that the call comes in, gets handled by the PBX, and then new calls are spawned in response to the requirements of that call. Those calls to the extensions are then managed individually and bridged (at the last second) to complete what appears to be a single call.

This change was initiated around Asterisk 1.8.

I hope that helps it make sense.

The UCP is for the users. When they look in their Call History, they expect to see, “ah, Bob called me yesterday at 3pm” - not “oh look, those 8 calls from Bob are really the same call, I’ll scroll down the next 50 calls so I can see who the last 6 people were who called me, and then I’ll guess which one of those entries really means something to me”.

Maybe I should just disable Call History in the UCP because it’s next to useless to present to any user. (I don’t mean to be offensive, but that is the general feeling); having Call History for users where they can’t just look at it and see things is not useful to them.

However, I also use PhonerLite, and it’s Call History is just what you expect it to be - just calls accepted or received. Why can’t it be that way in the UCP? If it isn’t designed that way, then I wonder why anyone would want to present this to the user.

I don’t know that anyone has actually asked.

The point of the feature isn’t to piss you off (which it clearly does), but if it isn’t working the way you want it to, you need to work with the developers and get it so it does what you expect.

There may be a reason why some specific call is getting presented in a way that violates the rule of least astonishment. My expectation is that UCP should only report calls that were delivered to this extension, so if you are getting 8 different presentations, it could be a problem with your configuration, a problem with the way UCP interacts with CDR, or simply a problem in the way UCP displays the information.

Maybe you should start working with the developers instead of being passive aggressive. This is largely an open-source system. You can fix a lot of it, and what you can’t can be changed through interaction with the Feature Request process. Stomping your feet and throwing a tantrum is definitely the wrong way to approach what you see as a problem.

Haha - I can’t be the first person to complain about it! We’re up to version 14.

I like that clever “rule of least astonishment” bit - I think I’ll keep it (thanks!).

My original post was to ask if someone had a solution for it. I have the problem with all calls in everybody’s UCP Call History for the entire system. I don’t remember it being this way in version 13.

It might just be a problem in my configuration - which is the reason I was posting here and hoping for answers rather than submitting a bug. I don’t know that it’s a bug yet. The foot stomping was in response to being told UCP is supposed to work that way - I don’t believe that it is.

Okay, enough of that.

Are there any settings I might check or any configuration that might cause this to happen where there is something I might change?

What version of the UCP are you running and when did this start to happen?

Hi, Mr. Ray!
I’m using UCP version 14.0.3.3 - the most latest stable version.
In fact, I think I’ve had this problem ever since I upgraded from FreePBX 12 to FreePBX 14.
Right now my FreePBX is at version 14.0.13.4.

Well that is because Asterisk CDRs changed in Asterisk 12, so like 6 years ago. Since that change a single call can have multiple CDR entries. However, I have used the UCP in both v13 and v14 and all of the entries for the call showing up in the CDR/Call History wasn’t a thing. So this could be a bug because this isn’t something that is a common thing.

Thanks. I can place a bug report, but is there any details I can add to make the report better besides screenshots of the UCP?

When you look at the CDR report, do the result show the same call just like the UCP or does this happen only in the UCP?

Yes, they show in both the UCP and in the CDR exactly the same.

Maybe this is caused by FollowMe?

For example, I just received an external call and it shows in my UCP and in the CDR three times.
NO ANSWER
ANSWERED
ANSWERED

In my FollowMe, when someone dials my extension, both my phone and my softphone (with a different extension) ring simultaneously. I normally answer with my softphone. The UCP Call History for my softphone’s extension does not have multiple entries in it.

Right because the softphone isn’t the one being called multiple times. Yes, FollowMe would do that since each call is its own call. You have the initial call to the extension, then you are calling the followme list. If your extension is in the followme list, it’s another call to your extension.

Hmmm… That would still be confusing for a common user, I think. They would not understand that there is an entry in UCP for FollowMe to call another extension; they would only understand calls sent and received by their own extension.

Would it be unusual to anticipate (or to think there ought to be) a setting where you can not record FollowMe rings in the UCP? Call Forwarding, I can see the use for, but when FollowMe is set to ring first extension for 0 seconds and followme list for 20, seeing the extra entries in UCP doesn’t make sense for a user unless they have a certain amount of tech-saavy.

For me, (even being administrator), I prefer not to see calls made by my FollowMe when it is configured to ring simultaneously. It adds a bunch of 4 and 5 second entries to the call history that I never really made. I don’t need to know that and it crowds the history. I can see the use of it in Call Events, however, and in the CDR, but not in the Call History. For me it’s a matter of usability for the Call History.

I’m not saying that it couldn’t be improved but the question becomes is this really a bug or does this need to be a feature request to link/ignore FM calls of the extension if said extension is in the list?

At this point, to me, it doesn’t look like a bug where the system is doing something it isn’t supposed to. I think it’s really working the way it was designed; the multiple entires do not occur on extensions without FollowMe configured. However, I think, maybe (?) this aspect was just never yet considered before, which would make it a feature request. What do you think?

(I really hate how the threads in this forum close automatically so soon)

Personally, I think that FollowMe calls should not register as calls in UCP’s call history - because there it should be a call history of the user, not the extension. In CDR, I understand that. And in UCP’s Call Events - I can understand that too; but not in the user’s Call History where they go to see what calls he or she has made.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.