API "obsolete"

[asmith3006]

I'm currently working on upgrading our custom app from v12 API to v15 and have noticed the following in the documentation:

HistoryIDOfTheCall:

Obsolete.
Each call has unique history ID.
It is persistent unique ID of the call in call history database.
(obsolete) v14 - call history database does use this ID.

We make extensive use of this as we follow a call from when it first arrives in our system and then as it's transferred between multiple IVR / receptionists.

Is there a suitable replacement which allows us to go all the way through the system?

 

[asmith3006]

Does anyone have any insight into this?

 

[YiannisH_3CX]

Hello @asmith3006
Do you have the latest API for V15? you can download the latest version from the link below
http://downloads.3cx.com/downloads/misc/callcontrolapi/3CXCallControlAPI_v15.zip

Also you can find the article in the following link
http://www.3cx.com/blog/docs/call-control-api/

 

[asmith3006]

YiannisH,

Thanks for the reply. I've attached the screenshot of the API portion I'm referring to, upon re-reading it I'm seeing a slight discrepancy in the descriptions ("Call history database does use this ID" and "This ID is not stored in the call history database")

Could you clarify on if this is "safe" to use and if it will appear in the API in future versions, please?

Thank you

 

[NickD_3CX]

But the time it is flagged as obsolete I would not recommend using it. What you could try, although I do not know exactly what your application checks, and most importantly how, is to use the ActiveConnection class, then track the calls using the CallID. From the Samples, check out "DNmonitor.cs".

 

[asmith3006]

NickD,

Thanks for the update, that's what I thought. In our testing when a call is received into an IVR it has CallID X, when it's then transferred to a hunt group it gets call ID Y and when it's then passed to an agent it's given call id Z, if that agent then transfers the call it gets CallID A, is this the intended behaviour?

For our situation we need to have a persistent call ID through each stage of the call's journey, is this possible?

 

[NickD_3CX]

Although it has been a while since I was playing with this part of the API, if memory serves that's not quite accurate.

In a:
ActiveConnection ac

there are 2 values
ac.CallID
and
ac.CallConnectionID

The first is constant throughout the same call while the second increments while the call progresses though the system.

 

[speek]

Hello,

What about queues?
We're running extensive tests of replacing current Queue system with 3CX Queues.
In the called number before sending to 3CX we provide 5 digit client id number (taken from external database, 3rd party IVR) as a prefix to queue number, we then in 3CX replace called number with the actual queue when call enters the queuing system so client number disappears.
We need to match CallID of the SIP Trunk site and CallID of the agent's call
What should we do?
64SC Enterprise sale depends on whether it's possible

Best regards,
Krzysztof

 

[NickD_3CX]

Again, I haven't used this in some time, but I believe your are right, Queues will spawn a new CallID, so it will not be immediately apparent which matches.
The way Queues work is that the call from the external number to the Queue gets a CallID X. Then while the Queue polls the various agents, it will spawn new CallIDs for each polling attempt. When someone answers though, if you have Replaces and Re-Invites enabled for the extensions (which you should), the call will merge into the original CallID X.

This means that you must find a way to identify which the original CallID is of the call that came into the Queue, and separate that from the CallIDs the Queue spawns to poll agents.