I'm not sure if this is relevant or if you are still looking for a solution to this, but I will go ahead an post as I recently had to resolve this issue for a client. This is working in UCCX release 10.6.
The answer is, "YES!" You can obtain Account Number info from the Import Contacts data. It is found on the Get Session Info step, under the Context tab, using the system variable "BAAccountNumber." You can also obtain "BACallResult" and "BACampaign" for the dialer result and associated outbound campaign application. In your script, just assign these to variable type: String.
I know this is an older thread but make sure you are aware of the following. My guess this is what will trip up most folks as it's not documented anywhere. Especially since UCCX allows you to use a dialing prefix, but that will cause the variables to come in as null as it modifies the session information. Your outbound call to the customer must not be modified in anyway (translation or digit strips).
UCCX: Outbound BA Call Variables Return 'null' If Gateway Dialpeers Append and Strip Digits CSCve40147 Description Symptom: 1. The UCCX script uses the Get Contact Info step to get the session ID of the call.
2. The UCCX script then uses the Get Contact Info step for that session to populate the outbound BA variable.
3. The BA variable names assigned are the proper case since case matters.
4. Even though the above steps are followed properly, the BA call variables are populating as 'null' in the script as seen from the Engine (MIVR) logs and/or the UCCX Script Editor debug mode.
Conditions: Once the gateway determines the call result of the call (after live voice or voicemail is detected, etc), UCCX writes the BA variables and the dialing contact to memory in the IVROutboundContactKey table. See the engine logs for example:
If the gateway dialpeer inbound from UCCX appends digits to the UCCX campaign's called number and then removes the digits on the outbound dialpeer to the UCCX CTI port, UCCX will not be able to return the BA call variables to the call since the number that is written in memory has appended digits, while the call presented to UCCX does not.
In the UCCX Engine log snip-it above, the digits 91 where appended to the dialed contact 8765309 to give 876530991. The 876530991 number is the number associated with the BA variables.
When the call comes back to a CTI route point after stripping the 91 digits, UCCX will use the original number 8765309 and will not be able to find that number in the IVROutboundContactKey table.
Workaround: Do not use gateway dialpeers to append and strip digits for UCCX outbound calls.
This is a documentation defect to add this information to the UCCX Administration guide.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...