|
Our current application uses UUI information to pass EDU ID to CM/AES and the agent desktop. Now, we are trying to set one additional data element in the UUI. It is causing issue with the agent desktop application. The issue seems to be somewhere in CM or AES where it is not taking the 32 bytes of EDU ID based on the length set. This results in the new EDU ID getting generated for the agent leg of the transferred call. The CM side UUI treatment is set to shared UUI. As long as we only have EDU ID set in the UUI, the pop works fine and the same EDU ID is used in the call all the way. I am hoping someone in this forum from Avaya has answer or can get the right information. Hate to get bounced around between different forums.
Here is the string that IVR is setting in the UUI information to pass EDU ID as well as one additional custom data element.
04C8203537653533366566303030303030303030613037643764373233333030303032DD0B3030333237343737393536;encoding=hex
Here is how the above string is encoded:
First element in UUI:
04C8203537653533366566303030303030303030613037643764373233333030303032
04 (first two hex octets) – Protocol discriminator UUI_IA5_ASCII. This means that the entire string is in hex encoded ASCII.
C8 (next two hex octets) – op code, shared UUI application identifier for ASAI data
20 (next two hex octets) – length of the first element. Hex value for 32 bytes.
3537653533366566303030303030303030613037643764373233333030303032 – EDU ID, 32 bytes of EDU ID [57e536ef000000000a07d7d723300002]
Second element:
DD – custom op code for receiving application data.
0B – length of second element (11 bytes encoded in hex)
3030333237343737393536
If we don’t put the second element in UUI, the agent desktop screen pop works fine and the EDU ID is correctly handled.
If we add the second element, the screen pop doesn’t work. We are getting different EDU ID in the agent desktop.
As an alternate solution, we tried using P-Intrinsic to pass the customer application data. Everything is showing fine in the OD log and session slot log. However, when we look at the SIP header (using tcpdump), we don't see any P-Intrinsic header.
We are using AEP 6.0.
|
