cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1381
Views
25
Helpful
4
Replies

UCCX - Assigning the active CTI Port to a variable

halo_levi
Level 1
Level 1

Hello,

I've been rigorously searching the forums here and have been unable to find a way to assign the active CTI port to a variable.

I'm wanting to assign the active CTI port during a supervised transfer to a variable that we will then be using for an exterior reporting application to narrow down call records.

I've found the information I'm looking for in the db_Cra under destinationDN in the  ContactCallDetail Table, but cannot find anywhere in the CCX editor that I can assign it to a variable.

Any information someone can provide on the issue would be very appreciated.  

Halo Levi 

UCCX Version 8.5

UCM Version 8.6           

1 Accepted Solution

Accepted Solutions

Tanner Ezell
Level 4
Level 4

Halo,

What you are looking for is certainly possible, though a bit outside the scope of UCCX. I will try to clearly explain what you need to do to accomplish your goal.

Firstly, the UCCX to my knowledge does not store a record of which CTI Port answered a call nor does it need to. When a caller calls in to a UCCX Script it first hits the CTI Route Point associated with the trigger, the system does an internal lookup to find an available port and redirects the call there where a CTI Port will answer the caller. This leaves a CDR record on the CUCM.

What you need to do, at a high level, is find a way to associate a caller to the record on the UCCX. The easiest and most accurate way to do this is via SessionID. From there, you want to find the appropriate record in the ContactCallDetail table. This record will contain the information that will allow you to find the appropriate CDR record on the CUCM.

To get the SessionID:

Create a session variable, sSession

Create an int variable, iSessionID

Using the Get Contact Info step, set the sSession variable to the callers session as seen below.

From here, using the Set step, assign the variable iSessionID a value of

int.valueOf(sSession.toString().substring(17,25), 16) as seen below


Once you have completed this, you will have a variable with the decimal version of the SessionID, this will directly map to the SessionID field on the ContactCallDetail table. How you store and retreive this information I will leave to you.

Once you have the decimal SessionID you will want to find the appropriate record. For your purposes, you only need one field, destProtocolCallRef.  For this example, I am using the CLI on the UCCX to issue the query, and a SessionID of

2000000047:

admin:run uccx sql db_cra select destProtocolCallRef from ContactCallDetail where SessionID = '2000000047'

This returns a string of value "0000000000000493013A44F200000000".

With this information we can now look into the CDR data to find the information we want. I will not go into how you acquire CDR information, just note that in CUCM 8.x and beyond you cannot directly query the CDR data via AXL. You can however query it via the command line as demonstrated below.

The field we are looking for, to identify the CTI Port is the destDeviceName field. We will filter for the call based on the outgoingProtocolCallRef field which has the value as returned by the destProtocolCallRef query we issued previously.

admin:run sql car select destDeviceName from tbl_billing_data where outgoingProtocolCallRef = '0000000000000493013A44F200000000'

destdevicename

==============

CCG_5108

Finally, the CTI Port device name is revealed to us. From here you can do whatever you need to with the data. I hope you find this information useful, if you do please consider to rate the post appropriately. If you need further assistance please feel free to contact my directly.

Note, you'll notice I am not using the destinationDN information from the ContactCallDetail table you had previously mentioned in your post. The reasoning for this is long term accuracy. While it is not common for CTI Ports to change numbers it can certainly happen. Call Control Groups are often reprovisioned as business needs change. By using the destProtocolCallRef field and CDR data you will forever be able to look this information up (presuming CDR data is not purged), where as if you choose to query the CUCM for devices with the DN from destinationDN, you may not get accurate data in the future. Contact centers are built and sold on the premise of accurate reporting data.

Thanks,

Tanner Ezell

Tanner Ezell www.ctilogic.com

View solution in original post

4 Replies 4

Tanner Ezell
Level 4
Level 4

Halo,

What you are looking for is certainly possible, though a bit outside the scope of UCCX. I will try to clearly explain what you need to do to accomplish your goal.

Firstly, the UCCX to my knowledge does not store a record of which CTI Port answered a call nor does it need to. When a caller calls in to a UCCX Script it first hits the CTI Route Point associated with the trigger, the system does an internal lookup to find an available port and redirects the call there where a CTI Port will answer the caller. This leaves a CDR record on the CUCM.

What you need to do, at a high level, is find a way to associate a caller to the record on the UCCX. The easiest and most accurate way to do this is via SessionID. From there, you want to find the appropriate record in the ContactCallDetail table. This record will contain the information that will allow you to find the appropriate CDR record on the CUCM.

To get the SessionID:

Create a session variable, sSession

Create an int variable, iSessionID

Using the Get Contact Info step, set the sSession variable to the callers session as seen below.

From here, using the Set step, assign the variable iSessionID a value of

int.valueOf(sSession.toString().substring(17,25), 16) as seen below


Once you have completed this, you will have a variable with the decimal version of the SessionID, this will directly map to the SessionID field on the ContactCallDetail table. How you store and retreive this information I will leave to you.

Once you have the decimal SessionID you will want to find the appropriate record. For your purposes, you only need one field, destProtocolCallRef.  For this example, I am using the CLI on the UCCX to issue the query, and a SessionID of

2000000047:

admin:run uccx sql db_cra select destProtocolCallRef from ContactCallDetail where SessionID = '2000000047'

This returns a string of value "0000000000000493013A44F200000000".

With this information we can now look into the CDR data to find the information we want. I will not go into how you acquire CDR information, just note that in CUCM 8.x and beyond you cannot directly query the CDR data via AXL. You can however query it via the command line as demonstrated below.

The field we are looking for, to identify the CTI Port is the destDeviceName field. We will filter for the call based on the outgoingProtocolCallRef field which has the value as returned by the destProtocolCallRef query we issued previously.

admin:run sql car select destDeviceName from tbl_billing_data where outgoingProtocolCallRef = '0000000000000493013A44F200000000'

destdevicename

==============

CCG_5108

Finally, the CTI Port device name is revealed to us. From here you can do whatever you need to with the data. I hope you find this information useful, if you do please consider to rate the post appropriately. If you need further assistance please feel free to contact my directly.

Note, you'll notice I am not using the destinationDN information from the ContactCallDetail table you had previously mentioned in your post. The reasoning for this is long term accuracy. While it is not common for CTI Ports to change numbers it can certainly happen. Call Control Groups are often reprovisioned as business needs change. By using the destProtocolCallRef field and CDR data you will forever be able to look this information up (presuming CDR data is not purged), where as if you choose to query the CUCM for devices with the DN from destinationDN, you may not get accurate data in the future. Contact centers are built and sold on the premise of accurate reporting data.

Thanks,

Tanner Ezell

Tanner Ezell www.ctilogic.com

Tanner,

Thank you for the detailed and thoughtful response!

Levi,

A simpler way would be to use a Get Trigger Info step to grab the active Contact object.  Then execute a "toString()" call and extract the current CTI-Port from it.  In the string is a plethora of comma delimted information about the call so all you have to do is look for the CTI-Port number.  It is prefixed by 'TP=" and is usually at the end of the string.

Below is an example of what to look for.  I've already captured the Contact object into cntTriggeringContact.  I just call cntTriggeringContact.toString() and the output below is what you get.  Those who've used UCCX for awhile will notice that the content is strikingly similar to a MIVR log entry.   Anyway, the TP=03009996230 was the CTI-Port directory number for this particular system.

Hope this helps.

-Steven

Please help us make the communities better. Rate helpful posts!

Thank you!  I'm going to try to work this solution into my script.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: