« Back to IVR PG (GED-125) Questions

Need clarification on User Variable and ECC variables

Combination View Flat View Tree View
Threads [ Previous | Next ]
The following text is the extract from the GED125_v3.0.doc regarding the ECC variable.
 
¿Messages that contain a section for ECC variables must always include all registered ECC variables that have a non-empty value.  Omitting a registered ECC variable has the effect of setting its value to an empty string.¿
 
From the above statement, we understand that if VRU desn¿t send registered ECC variable in the message, then ICM shall make it empty. But we do not see this happening.
 
Please consider the following call where ICM script assigns the value for ECC variable(user.SessionId) to some value ¿1234¿. This is been given by ICM to VRU in the RUN_SCRIPT_REQ message. But VRU did not send this ECC variable in RUN_SCRIPT_RESULT message. So, it is expected from ICM that when it come back with another RUN_SCRIPT_REQ, the ICM shall empty the ECC variable. But this does not happen and it carries the same old value ¿1234¿.

So could you please let us know what the correct behavior is?  Also would like to know whether this functionality also applies with respect CallVariables(1 through 10)?

Yes it should apply to callvariables. Try passing a blank.


David Lender
Custom Application Engineer
Contact Center Developer Services
dlender@cisco.com
Phone: +1 404 607 0523
Mobile: +1 404 229 3664




Cisco Systems, Inc.
United States
Cisco.com <http://www.cisco.com/>
Cisco Developer Network <http://developer.cisco.com/>



Think before you print.

This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html



________________________________

From: Cisco Developer Community Forums
[mailto:cdicuser@developer.cisco.com]
Sent: Tuesday, August 10, 2010 12:24 PM
To: cdicuser@developer.cisco.com
Subject: New Message from Atul Edlabadkar in Contact Center
Enterprise/Hosted/ICM IVR PG (GED-125) - IVR PG (GED-125) Questions:
Need clarification on User Variable and ECC variables


Atul Edlabadkar has created a new message in the forum "IVR PG (GED-125)
Questions":
--------------------------------------------------------------
The following text is the extract from the GED125_v3.0.doc regarding the
ECC variable.

"Messages that contain a section for ECC variables must always include
all registered ECC variables that have a non-empty value. Omitting a
registered ECC variable has the effect of setting its value to an empty
string."

From the above statement, we understand that if VRU desn't send
registered ECC variable in the message, then ICM shall make it empty.
But we do not see this happening.

Please consider the following call where ICM script assigns the value
for ECC variable(user.SessionId) to some value "1234". This is been
given by ICM to VRU in the RUN_SCRIPT_REQ message. But VRU did not send
this ECC variable in RUN_SCRIPT_RESULT message. So, it is expected from
ICM that when it come back with another RUN_SCRIPT_REQ, the ICM shall
empty the ECC variable. But this does not happen and it carries the same
old value "1234".

So could you please let us know what the correct behavior is? Also
would like to know whether this functionality also applies with respect
CallVariables(1 through 10)?
--
To respond to this post, please click the following link:
<http://developer.cisco.com/web/ged-125/forums/-/message_boards/message/
2423548>
or simply reply to this email.

Hi David,
 
Thanks for your response. What we have found is that VRU-PG still send the ECC variables information in next message even through the VRU did not pass it and as per GED specs, the VRU-PG should omit this. Could you please comment on this deviation? If required I can provide PIM logs.
 
Regards
 
Yes it should apply to callvariables. Try passing a blank.


David Lender
Custom Application Engineer
Contact Center Developer Services
dlender@cisco.com
Phone: +1 404 607 0523
Mobile: +1 404 229 3664
From: Cisco Developer Community Forums
[mailto:cdicuser@developer.cisco.com]
Sent: Tuesday, August 10, 2010 12:24 PM
To: cdicuser@developer.cisco.com
Subject: New Message from Atul Edlabadkar in Contact Center
Enterprise/Hosted/ICM IVR PG (GED-125) - IVR PG (GED-125) Questions:
Need clarification on User Variable and ECC variables


Atul Edlabadkar has created a new message in the forum "IVR PG (GED-125)
Questions":
--------------------------------------------------------------
The following text is the extract from the GED125_v3.0.doc regarding the
ECC variable.

"Messages that contain a section for ECC variables must always include
all registered ECC variables that have a non-empty value. Omitting a
registered ECC variable has the effect of setting its value to an empty
string."

From the above statement, we understand that if VRU desn't send
registered ECC variable in the message, then ICM shall make it empty.
But we do not see this happening.

Please consider the following call where ICM script assigns the value
for ECC variable(user.SessionId) to some value "1234". This is been
given by ICM to VRU in the RUN_SCRIPT_REQ message. But VRU did not send
this ECC variable in RUN_SCRIPT_RESULT message. So, it is expected from
ICM that when it come back with another RUN_SCRIPT_REQ, the ICM shall
empty the ECC variable. But this does not happen and it carries the same
old value "1234".

So could you please let us know what the correct behavior is? Also
would like to know whether this functionality also applies with respect
CallVariables(1 through 10)?
--

What version of ICM are you using? If you open a Service Request and
attach the logs I can check with our Development Engineers to determine
if this is a documentation error or a IVR PG bug. I believe with CTI
Server you have to use a blank to clear the variable. I will have to
verify that not specifying the variable at all in IVR PG will or will
not cause it to be cleared.

Were you able to try a blank to see if that cleared it for you?

If you do decide to open a Service Request (SR) using your CDN
subscription, then please be sure to specify Other for Technology and
Cisco Developer Network - Contact Center Applications for SubTechnology.

Hi David,
 
I had opened service request (SR 615037251) sometime back but did not get satisfactory resolution. Hope you would be able to pull the information using the SR number.
 
Thanks,
Atul
 
What version of ICM are you using? If you open a Service Request and
attach the logs I can check with our Development Engineers to determine
if this is a documentation error or a IVR PG bug. I believe with CTI
Server you have to use a blank to clear the variable. I will have to
verify that not specifying the variable at all in IVR PG will or will
not cause it to be cleared.

Were you able to try a blank to see if that cleared it for you?

If you do decide to open a Service Request (SR) using your CDN
subscription, then please be sure to specify Other for Technology and
Cisco Developer Network - Contact Center Applications for SubTechnology.

I looked at your SR 615037251, it is in customer pending state by the
tac engineer. I can take ownership and verify the documentation with
our Development Engineers.

Please take the ownership of the SR and provide solution.
 
Thanks,
Atul
 
I looked at your SR 615037251, it is in customer pending state by the
tac engineer. I can take ownership and verify the documentation with
our Development Engineers.

Hi David,
 
Any further update on this?
 
Thanks,
Atul
 
Please take the ownership of the SR and provide solution.
 
Thanks,
Atul
 

I looked at your SR 615037251, it is in customer pending state by the
tac engineer. I can take ownership and verify the documentation with
our Development Engineers.


Atul, the CDN support forums are community supported and have no service level agreement

I have ownership of your SR. Please correspond via updating your SR 615037251 using the TAC case management tools as opposed to via the CDN forums.

Thanks.

David