Concurrent call inaccuracy

[lgaetz]

In doing extensive testing with dahdi trunks, I have noticed more than once that concurrent calls rarely reports one more call than the number of channels would otherwise allow. i.e. on a dahdi card with max 4 channels, it will very rarely report 5 concurrent calls.

I am not sure at this point, but when I do a debug of concurrent calls, a report is generated showing the call date/time rounded to full minutes. If two very short calls are placed successively in the same minute, I wonder is it possible that concurrent calls would report that as two concurrent calls? I will update as I get more info.

[wrender]

I guess for this reason it might make sense to round to nearest second, or ms? I am a very basic programmer, so not sure if this would be possible...

[boolah]

I haven't looked at the code in a while, but from recollection (which isn't saying much) I believe it's rounded to the nearest second. That's because it uses the CDRs to generate the reports and duration of calls are stored in seconds in MySQL.

@lgaetz - can you send me a DB dump of dahdi calls showing the issue and I'll see if I can figure out what's going on.

[lgaetz]

I assumed as much @boolah, but when enabling debug output from cc report, a csv file is created with call time/date truncated to minutes. When I have done more testing and can reproduce, I will follow up with DB dump.

[boolah]

How are you opening the CSV file? If you're opening it with Excel (or similar program) is the number format for the column set to display hh:mm:ss?

[lgaetz]

Yep, confirmed it was a display issue with Excel, not the first time I have learned this the hard way. To confirm, CSV file does have call times in seconds.

Back to square one tho with the reporting issue, I will play some more.

[wrender]

I can confirm on the system I am testing on, it appears to report Maximum Concurrent Calls 1 over what you would expect.

For example on the machine I tested on it has G5 which has one fax line/channel. It is showing for some time periods that max concurrent calls is 2. Most of the time says 1 though which is what you would expect.

[lgaetz]

I have another clue. There are situations where a single outbound call generates more than 1 entry in the CDR. You can see below, the uniqueid is the same for all 4 entries, but 2 entries show channel open for 2 seconds and the 2 entries are 142 seconds.

Data from CSV file:

4:35:31 PM  1   1   1902xxxxxxx L Gaetz" <1902yyyyyyy>" Local/103@from-internal-00000009;1  zzzzzzz from-internal   DAHDI/4-1   173 142 1386275731.22
4:35:40 PM  2   2   1902xxxxxxx L Gaetz" <1902yyyyyyy>" SIP/103-00000001                    zzzzzzz from-internal   DAHDI/4-1   5   2   1386275731.20
4:35:40 PM  1   2   1902xxxxxxx L Gaetz" <1902yyyyyyy>" SIP/103-00000001                    zzzzzzz from-internal   DAHDI/4-1   5   2   1386275731.20
4:35:31 PM  0   2   1902xxxxxxx L Gaetz" <1902yyyyyyy>" Local/103@from-internal-00000009;1  zzzzzzz from-internal   DAHDI/4-1   173 142 1386275731.22

edit 1
fixed uniqueid decimals

[lgaetz]

I have isolated the trouble entry in the CDR. In one case it looks like a call was transferred to voicemail, and in the process triggered a short 2 second cdr entry that appears concurrent with the call but is more of a virtual housekeeping entry. I can't see any information that could be used in the query to filter these 'virtual' calls out other than by throwing out all calls that are shorter than 3-4 seconds, or perhaps giving the user the ability to set minimum call length. @boolah if you email me at lgaetz 'at' gmail 'dot' com, I will send you the offending entries so you can see what I am talking about.

email sent.

[boolah]

Looking over the SQL dump provided, the uniqueID is not the same for all four entries. This is another Excel formatting issue (you need to format the column to show decimals). The uniqueID for the 142 second call is 1386275731.22, while the uniqueID for the 2 second call is 1386275731.20

The two second call uses a SIP channel whereas the 142 second call is using the Local channel. Perhaps this has something to do with the way the call was routed? The CDRs do seem to indicate that there are [technically] two distinct calls; one SIP and one Local.

I do know that the way a call is routed can significantly skew the results. For example, if you have a call come into a ring group and then the call is transferred to an individual extension, the call stats module will incorrectly count this as two calls. I say "incorrectly" here because even though these are two separate calls, they posses the same uniqueID as well as the same channel. The module should really account for this and "flatten" the result to a single call, but it doesn't and incorrectly reports two concurrent calls. However, this is not the case with the CDRs provided for the dadhi call as the two calls have separate uniqueIDs and channels.

[lgaetz]

Yeah, after posting above, I did later notice that the uniqueid didn't match.

This call was probably initiated by a web click to dial application which used the AMI to 'originate' a call to local/103@from-internal. Instead of answering extension 103, I hit cancel which then sent the call to extension voicemail and the AMI originate command then bridged the external DID to my voicemail.

But really the how & why doesn't matter a lot. The point is that, at least with dahdi channels, it seems like these phantom calls do periodically appear and I don't see any way of filtering them out of the query. This may just be a shortcoming of the algorithm used to determine concurrency.