/rest/call/read minDate maxDate not filtering

Technical API
#21

Hi @steved after your recommendation I’ve discussed this with the IT team who have now upgraded the phone system to the latest version.

I’ve tried passing the extra scope through to the /rest/call/allcalls endpoint and it appears that the structure is slightly different for calls in and out. The ones in appear to be grouped by extension which also includes some huntgroup extension numbers.

Can you explain what the best way is to get the user from the extra data?

Is it tohdext and frhdext fields depending whether you’re going through the in or out objects?

#22

Hi,

Yes, all inbound call reports are keyed on the extension they are calling. All outbound calls are keyed on the device that makes the call… There isn’t a 1-to-1 relationship between handset and extension, so calling extension is not always meaningful, and called device is incidental data.

The closes you could get to marrying the two up would be to use extra.toch as the key for inbound calls that are actually answered, but an unanswered or voicemail call won’t have a ‘toch’ value set (which is partly why it is not the key for inbound)

To get the user from the extradata, use extra.frname and extra.toname respectively - As long as a PABX user is one of the parties involved, then that should be set. ‘frid’ and ‘toid’ are available for disambiguation of similar names.

‘frhdext’ and ‘tohdext’ indicate the effective from/to extension number for hotdesked users. Perhaps there is some merit in seeing if I can provide a ‘frext’ value for normal calls - I don’t know how easy that would be.

Hope that is of some help.

#23

Hi @steved,

Is there a way to reduce the all call data using a minId like the other call/read report. Or, is the smallest amount of data just using the day? It would also be useful to filter by company if that’s possible?

#24

Hi, I’ve been out of the office - I’ll try and answer this later today.

#25

At present the pre-precessed call reports can only be run for a whole day, or for days at a time. Also, company cannot be selected - This is because running the report for one company takes the same CPU/effort as running for a many companies so it is better for the PABX if one request is made. The ‘allcalls’ report is designed for bulk daily collection into an external reporting system where more complex reports can be run.

For slightly more granular data you need to combine the ‘incalls’ and ‘outcalls’ reports, which can be filtered by company.

I will make a note to consider adding filtering by ‘acctid’ in future, but the data is so heavily processed in the call reports that it has much less meaning, and is just a ‘key’ rather than being a sequence anymore.

#26

Hi @steved some of the inbound calls aren’t being matched to an extension with the extra info. It seems to be when a call is answered then forwarded. Is this when I’d need to use /admin/oak.whtm? Or would the Node integration provide better call data?

object(stdClass)#7743 (12) {
    ["acctid"]=>
    int(1034684)
    ["calldate"]=>
    int(1544115434)
    ["caller_info"]=>
    string(16) "Forward via 1065"
    ["caller"]=>
    string(11) "{REPLACED_MOBILE_NUMBER}"
    ["type"]=>
    string(8) "External"
    ["ringtime"]=>
    int(6)
    ["billsecs"]=>
    int(1006)
    ["detail"]=>
    string(28) "Answered : HDesk17"
    ["qtime"]=>
    string(0) ""
    ["qstatus"]=>
    string(0) ""
    ["ddi"]=>
    string(11) "{REPLACED_DDI}"
    ["extra"]=>
    object(stdClass)#7744 (8) {
    ["frch"]=>
    string(7) "SIP/Q20"
    ["toch"]=>
    string(21) "SIP/hdesk17"
    ["toint"]=>
    bool(true)
    ["frint"]=>
    bool(true)
    ["toname"]=>
    string(7) "Hotdesk"
    ["disposition"]=>
    string(8) "ANSWERED"
    ["frchname"]=>
    string(3) "Q20"
    ["tochname"]=>
    string(17) "HDesk17"
    }
}```
#27

Hi Rick,

I presume you mean “hdext” is missing?

Whether the node integration would provide better data depends on your use-case - I bet if you went to use it you would find a unique set of requirements and issues which would cause there own set of questions!

I doubt the oak.whtm query would help a great deal although it may patch-up the issue.

I seem to remember recently finding a bug in some SQL that might conceivably be causing this issue.

If you raise a support ticket then I can try to log in and patch it (perhaps include this text in the ticket?)

Regards,
Steve

#28

As a side thought - Do you know for sure that that handset (SIP/hdesk17) is currently hotdesked, and does not also have a static configuration that is routing the call? If that is the case then the “parent” of the object you posted contains the actual extension number that the call was sent to, rather then the pseudo extension number which is the user hotdesked onto that handset at the time.

#29

Perhaps it’s due to the setup then as the parent was 1060 which is a hunt group in this case? Please see below setup. The call came through to the main number which goes to one user and also Ext: 1060 using the DAY JUMP. The user who picked up the call is within 1060 hunt group and was using HDesk17.

Screenshot 2018-12-10 at 12.31.27.png1202×352 51.3 KB

Let me know what you think and whether this could be setup slightly different to avoid this issue?