API "obsolete"

Discussion in '3CX Phone System - General' started by asmith3006, Sep 12, 2016.

Thread Status:
Not open for further replies.
  1. asmith3006

    Joined:
    Mar 5, 2014
    Messages:
    94
    Likes Received:
    5
    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?
     
  2. asmith3006

    Joined:
    Mar 5, 2014
    Messages:
    94
    Likes Received:
    5
    Does anyone have any insight into this?
     
  3. YiannisH_3CX

    YiannisH_3CX Support Team
    Staff Member 3CX Support

    Joined:
    May 10, 2016
    Messages:
    4,443
    Likes Received:
    282
  4. asmith3006

    Joined:
    Mar 5, 2014
    Messages:
    94
    Likes Received:
    5
    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
     

    Attached Files:

  5. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,255
    Likes Received:
    63
    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".
     
  6. asmith3006

    Joined:
    Mar 5, 2014
    Messages:
    94
    Likes Received:
    5
    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?
     
  7. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,255
    Likes Received:
    63
    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.
     
  8. speek

    Joined:
    Feb 27, 2014
    Messages:
    3
    Likes Received:
    0
    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
     
  9. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,255
    Likes Received:
    63
    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.
     
Thread Status:
Not open for further replies.