GVP 8 - attached data not updated correctly

bandorka · May 25, 2011, 12:44pm

Hi all,

The question is: Why doesn’t work the userdata update correctly? Why update tvice the userdata (for the second time with the original value)?

And thanks for the answers!
Bandorka

Versions:
SIP: 8.0.400.59
URS: 8.0.100.17
RM: 8.1.201.93
MCP: 8.1.202.13

SIP connected to RM and RM connected to SIP

Resource Groups:
MCP
Monitoring method: SIP OPTIONS

VOIP service on a SIP_SWITCH:
[TServer]
contact=192.168.0.93:5060 (RM IP:PORT)
service-type=application
userdata-map-filter=*

Trunk group on a SIP_SWITCH (8000):
[TServer]
contact=192.168.0.93:5060 (RM IP:PORT)
userdata-map-filter=*

URS centric application, in a “Playapplication” block APP_ID points to the trunk group(8000) (and DID group on GVP side)
Before “Playapplication” block there is an Update(‘testkey’, ‘beforeGVP’) in a routing strategy

In a GVP side:
1.get Interaction data block, then logging:

MCP: 13:36:36.247 Int 50035 007700DD-10003A9C 532 log testkey=beforeGVP

Assign block (change the value of “testkey”):
MCP: 2011-05-25 13:36:36.247 DBUG 007700DD-10003A9C 532 0C000000 AssignRuntime.cxx:48 Execute(): Script [AppState.testkey;AppState.testkey=‘afterGVP’;]

put Interaction data block:
Sending the new value via an SIP INFO
MCP: 2011-05-25 13:36:36.263 DBUG 00000000-00000000 3152 0C000000 AppEventBase.h:60 app.VXML-NG AMEVENT_VXML_SEND_MESSAGE - nRequestID=0;strTarget=;strContent=;strContentType=text/plain;strEventName=;nTimeout=10000;bAsync=0
MCP: 2011-05-25 13:36:36.263 DBUG 007700DD-10003A9C 3152 0C000000 VXMLInstance.cxx:1746 SendMessage encoded namelist as application/x-www-form-urlencoded;charset=utf-8 content: testkey=afterGVP&testkey2=EnterValue
MCP: 2011-05-25 13:36:36.263 DBUG 007700DD-10003A9C 3152 0C000000 AppCallLeg.h:173 Call Leg Application Event
MCP: 2011-05-25 13:36:36.263 DBUG 00000000-00000000 1628 01F00000 main.C:298 007700DD-10003A9C-00000020 .\FMThreadQueue.cxx:981 Processing ReleaseRequest
MCP: 2011-05-25 13:36:36.263 DBUG 00000000-00000000 1628 01F00000 main.C:298 007700DD-10003A9C-00000020 .\FMUserRequest.cxx:108 Deleting Request
MCP: 2011-05-25 13:36:36.263 DBUG 00000000-00000000 768 01C00000 CMMsgBase.h:181 cmapi.msg: CM_MSG_CALLLEG_APP_EVENT - StrEventInfo == testkey=afterGVP&testkey2=EnterValue
MCP: 2011-05-25 13:36:36.263 DBUG 007700DD-10003A9C 2564 02800000 LMCallSIP.C:2398 Sending INFO: testkey=afterGVP&testkey2=EnterValue
MCP: 2011-05-25 13:36:36.263 DBUG 007700DD-10003A9C 2564 02800000 LMCallSIP.C:2400 ApplicationEvent - m_nState=9
MCP: 2011-05-25 13:36:36.263 DBUG 007700DD-10003A9C 2564 02800000 LMCallSIPStack.C:164 LMCallSIP::SendRequest for X-Genesys-GVP-Session-ID
MCP: 2011-05-25 13:36:36.263 DBUG 007700DD-10003A9C 2564 02800000 LMCallSIPStack.C:187 LMCallSIP::SendRequest - X-Genesys-GVP-Session-ID: E8CBD025-2430-41B5-8B93-177B2810CF8F;gvp.rm.datanodes=1;gvp.rm.tenant-id=101_BAA_TEST_IVRPR
MCP: 13:36:36.263 Trc 33009 INFO 00000000-00000000 2564 02800FA1 Request sent: INFO sip:6000@192.168.0.93:15060 SIP/2.0
MCP: Via: SIP/2.0/UDP 192.168.0.93:5070;branch=z9hG4bK1d333a60dce9c4
MCP: From: sip:GVP@192.168.0.93:15060;tag=F0F6295C-38EE-4FC3-6A9A-D237F7ED752F
MCP: To: sip:6000@192.168.0.93:15060;tag=B56AD420-2B83-4858-8909-7C07CBE8E487-9
MCP: Max-Forwards: 70
MCP: CSeq: 1 INFO
MCP: Call-ID: E636BB72-B269-485C-BB8C-271A2569401B-4@192.168.0.93
MCP: Content-Length: 36
MCP: Content-Type: application/x-www-form-urlencoded;charset=utf-8
MCP: Route: sip:81e5d28@192.168.0.93:5060;transport=TCP;lr;gvp.rm.datanodes=1
MCP: X-Genesys-GVP-Session-ID: E8CBD025-2430-41B5-8B93-177B2810CF8F;gvp.rm.datanodes=1;gvp.rm.tenant-id=101_BAA_TEST_IVRPR
MCP: X-Genesys-testkey: beforeGVP
MCP: User-Agent: X-Lite release 1011s stamp 41150
MCP: Min-SE: 90
MCP: Supported: timer

MCP: testkey=afterGVP&testkey2=EnterValue
MCP: 13:36:36.263 Trc 33009 INFO 00000000-00000000 3024 02800FA1 Response received: SIP/2.0 200 OK

Logging the new value:
MCP: 13:36:36.294 Int 50035 007700DD-10003A9C 2384 log testkey=afterGVP

At the same time in the SIP log:

Receiving SIP INFO:
SIP: INFO sip:6000@192.168.0.93:15060 SIP/2.0
SIP: Via: SIP/2.0/UDP 192.168.0.93:5060;branch=z9hG4bK0a5e5f80dce9c4abcdef09
SIP: Via: SIP/2.0/UDP 192.168.0.93:5070;branch=z9hG4bK1d333a60dce9c4
SIP: From: sip:GVP@192.168.0.93:15060;tag=F0F6295C-38EE-4FC3-6A9A-D237F7ED752F
SIP: To: sip:6000@192.168.0.93:15060;tag=B56AD420-2B83-4858-8909-7C07CBE8E487-9
SIP: Max-Forwards: 69
SIP: CSeq: 1 INFO
SIP: Call-ID: E636BB72-B269-485C-BB8C-271A2569401B-4@192.168.0.93
SIP: Content-Length: 36
SIP: Content-Type: application/x-www-form-urlencoded;charset=utf-8
SIP: X-Genesys-GVP-Session-ID: E8CBD025-2430-41B5-8B93-177B2810CF8F;gvp.rm.datanodes=1;gvp.rm.tenant-id=101_BAA_TEST_IVRPR
SIP: X-Genesys-testkey: beforeGVP
SIP: User-Agent: X-Lite release 1011s stamp 41150
SIP: Min-SE: 90
SIP: Supported: timer

SIP: testkey=afterGVP&testkey2=EnterValue

Distribute EventAttachedDataChanged
SIP: Message EventAttachedDataChanged
SIP: AttributeEventSequenceNumber 000000000000006d
SIP: AttributeTimeinuSecs 263000
SIP: AttributeTimeinSecs 1306323396 (13:36:36)
SIP: AttributeThirdPartyDN ‘7000’
SIP: AttributeThisDNRole 1
SIP: AttributeThisDN ‘6000’
SIP: AttributeANI ‘6000’
SIP: AttributeDNIS ‘7000’
SIP: AttributeUserData [155] 00 03 00 00..
SIP: ‘GVP-Session-ID’ ‘E8CBD025-2430-41B5-8B93-177B2810CF8F;gvp.rm.datanodes=1;gvp.rm.tenant-id=101_BAA_TEST_IVRPR’
SIP: ‘testkey’ ‘afterGVP’
SIP: ‘testkey2’ ‘EnterValue’
SIP: AttributeCallUUID ‘TI24M9BAG571V8QRK6STLBPH3G000004’
SIP: AttributeConnID 007001ed66dec004
SIP: AttributeCallID 4
SIP: AttributePropagatedCallType 1
SIP: AttributeCallType 1

Receiving SIP BYE:

BYE sip:6000@192.168.0.93:15060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.93:5060;branch=z9hG4bK0a5f0f88dce9c7abcdef09
Via: SIP/2.0/UDP 192.168.0.93:5070;branch=z9hG4bK1d33b800dce9c7
From: sip:GVP@192.168.0.93:15060;tag=F0F6295C-38EE-4FC3-6A9A-D237F7ED752F
To: sip:6000@192.168.0.93:15060;tag=B56AD420-2B83-4858-8909-7C07CBE8E487-9
Max-Forwards: 69
CSeq: 2 BYE
Call-ID: E636BB72-B269-485C-BB8C-271A2569401B-4@192.168.0.93
Content-Length: 13
Content-Type: application/x-www-form-urlencoded;charset=utf-8
Reason: SIP
X-Genesys-GVP-Session-ID: E8CBD025-2430-41B5-8B93-177B2810CF8F;gvp.rm.datanodes=1;gvp.rm.tenant-id=101_BAA_TEST_IVRPR
X-Genesys-testkey: beforeGVP
User-Agent: X-Lite release 1011s stamp 41150
Min-SE: 90
Supported: timer

__reason=exit

Distribute EventAttachedDataChanged

SIP: Message EventAttachedDataChanged
SIP: AttributeEventSequenceNumber 000000000000006f
SIP: AttributeTimeinuSecs 966000
SIP: AttributeTimeinSecs 1306323399 (13:36:39)
SIP: AttributeThirdPartyDN ‘7000’
SIP: AttributeThisDNRole 1
SIP: AttributeThisDN ‘6000’
SIP: AttributeANI ‘6000’
SIP: AttributeDNIS ‘7000’
SIP: AttributeUserData [173] 00 04 00 00..
SIP: ‘testkey2’ ‘EnterValue’
SIP: ‘GVP-Session-ID’ ‘E8CBD025-2430-41B5-8B93-177B2810CF8F;gvp.rm.datanodes=1;gvp.rm.tenant-id=101_BAA_TEST_IVRPR’
SIP: ‘testkey’ ‘beforeGVP’
SIP: ‘__reason’ ‘exit’
SIP: AttributeCallUUID ‘TI24M9BAG571V8QRK6STLBPH3G000004’
SIP: AttributeConnID 007001ed66dec004
SIP: AttributeCallID 4
SIP: AttributePropagatedCallType 1
SIP: AttributeCallType 1

Fra · May 25, 2011, 1:27pm

I had the same issue, but it’s bizarre in your case, as seems to be a known issue that is resolved in SIP Server 8.0.400.25. You are running SIP Server 8.0.400.59, can you triple check that?

From SIPS RN:

SIP Server now correctly processes the following scenario:

An inbound call is routed to a Routing Point, then to GVP. UserData is attached to the call. The userdata-map-filter option is set to pass UserData in the SIP message.

SIP Server sends an INVITE message to GVP containing UserData attribute values in the X-Genesys custom headers.

While interacting with the caller, GVP collects some information and sends the collected data to SIP Server in the BYE message.

SIP Server attaches the key-value pair from the BYE message as UserData. If same key is repeated in the header as well as in the BYE message, then preference will be given to the BYE message and the original key-value pair will be replaced in the UserData.

(ER# 240493431)

Can you post the INVITE received by RM?

bandorka · May 25, 2011, 2:01pm

thanks for the answer, here is the invite:
But, in my case, there is no any information in the BYE message as you see from the log. The info is in the INFO message only. Maybe downgrade to the version mentioned by you?

INVITE sip:8000@192.168.0.93:5060 SIP/2.0
From: sip:6000@192.168.0.93:15060;tag=B56AD420-2B83-4858-8909-7C07CBE8E487-9
To: sip:GVP@192.168.0.93:15060
Call-ID: E636BB72-B269-485C-BB8C-271A2569401B-4@192.168.0.93
CSeq: 1 INVITE
Content-Length: 530
Content-Type: application/sdp
Via: SIP/2.0/UDP 192.168.0.93:15060;branch=z9hG4bKA62CC4D9-9856-4CBB-8BD8-ECA89CBC9554-10
Contact: sip:6000@192.168.0.93:15060
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE
X-Genesys-testkey: beforeGVP
User-Agent: X-Lite release 1011s stamp 41150
Max-Forwards: 69
X-Genesys-CallUUID: TI24M9BAG571V8QRK6STLBPH3G000004
Session-Expires: 1800;refresher=uac
Min-SE: 90
Supported: uui,timer

v=0
o=- 1306316594 1 IN IP4 192.168.0.92
s=CounterPath X-Lite 3.0
c=IN IP4 192.168.0.92
t=0 0
m=audio 65400 RTP/AVP 107 119 100 106 0 105 98 8 101
a=alt:1 3 : Tcx6K0xL VS4JiWdF 192.168.0.92 65400
a=alt:2 2 : Ajk+VHOe Np2WLNYH 192.168.163.1 65400
a=alt:3 1 : /OVIyNTW qHV9Ka8z 192.168.28.1 65400
a=sendrecv
a=fmtp:101 0-15
a=rtpmap:107 BV32/16000
a=rtpmap:119 BV32-FEC/16000
a=rtpmap:100 SPEEX/16000
a=rtpmap:106 SPEEX-FEC/16000
a=rtpmap:105 SPEEX-FEC/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000

bandorka · May 25, 2011, 2:05pm

SIP version is 8.0.400.59 (hotfix)

cavagnaro · May 25, 2011, 3:33pm

At the moment of 7, what does URS says?

bandorka · May 26, 2011, 8:20am

Nothing interesting in the URS log. I’ve just downgraded version .25 and the behavior is the same. The atached data exchange is in the INFO messages, not in the BYE massage. Maybe this is the problem, but I don’t know yet why…

cavagnaro · May 26, 2011, 4:45pm

Well even if not interesting would be good to have it. For what i understand as long as the interaction is on gvp the KVP is the one you want but when goes to urs again the KVP is updated again with original value, correct?

IF1 · May 26, 2011, 5:51pm

Hi,

In your description you wrote “URS centric application, in a “Playapplication” block APP_ID points to the trunk group(8000) (and DID group on GVP side)
Before “Playapplication” block there is an Update(‘testkey’, ‘beforeGVP’) in a routing strategy”.

In the URS centric application you don’t need any Trunk Group DN, or Trunk DN neither DID mappings but only the VOIP DN you already have. You just need to create a Default IVR Profile in your Tenant (Resources in Single Tenant and Environment in Multi Tenant). Then in the PlayApplicaiton button of your routing strategy just put APP_ID=1 and {s}APP_URI=http://something.vxml…or file:///something.vxml. If you are interested for GVP reporting then you just have to add then ;gvp-tenant-id=YourProfileHere in your URL.

Give it a try in this way if you want and let us know.

Kind Regards,
IF

Rene · May 27, 2011, 6:22am

Hi,

Composer’s help clearly states that update of User Data is not supported when CTI integration is done via SIP Server (mapping User Data to SIP headers). I know that you’re using SIP INFO to update the value but final BYE still contains old value so updated value is overwritten by original (old) one.

R.

IF1 · May 27, 2011, 9:32am

Hi,

Update os a variable by using the InteractioData block is not supported when CTI Connector is not in use - correct. But our friend here does not try to use the Update functionality of this Block. Below you can see outcome of a quick test - it works.

Routing strategy that updates the test_data=before_GVP
Play Application button with URL that appears in the INVITE to RM below
GVP APP
Entry block with variable test_data
Interaction block which makes a get to the test_data
Assign block with test_data=‘After_GVP’
Interaction block which makes a put to the test_data
Exit block with return value=test_data

Even if we don’t include the InteractionData block (to send the INFO), the “update” of the test_data works ok in the EXIT block.

See some snippets below (SIP Server version 8.0.400.45):

10:01:34.374:(1) Sending [412,UDP] 1405 bytes to 192.168.204.138:5060 >>>>>
INVITE sip:dialog@192.168.204.138:5060;voicexml=file:///C:/GCTI/xxxxxx_Workspace/UserdataTest/src-gen/main.vxml SIP/2.0
From: “Test_Account” <sip:[email removed]>;tag=09C151A1-A716-4572-83A0-8F54FBC7E8A3-1116
To: sip:GVP_PlayAppButton@192.168.204.137:5060
X-Genesys-test_data: before_GVP

10:01:34.718:(1) Received [412,UDP] 929 bytes from 192.168.204.138:5060 <<<<<
INFO sip:test@192.168.204.137:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.204.138:5060;branch=z9hG4bK0b613888df686eabcdef09
Via: SIP/2.0/TCP 192.168.204.137:5070;branch=z9hG4bK1d3447b0df686e
From: sip:GVP_PlayAppButton@192.168.204.137:5060;tag=335BCEB5-3CFA-4669-E1A1-B09615607ED1
To: “Test_Account” <sip:[email removed]>;tag=09C151A1-A716-4572-83A0-8F54FBC7E8A3-1116
Max-Forwards: 69
X-Genesys-test_data: before_GVP
Min-SE: 90
Supported: timer, uui

test_data=After_GVP

@10:01:34.7180 [0] 8.0.400.45 distribute_event: message EventAttachedDataChanged
AttributeThirdPartyDN ‘10000’
‘Content-Length’ ‘427’
‘test_data’ ‘After_GVP’

10:01:35.671:(1) Received [412,UDP] 941 bytes from 192.168.204.138:5060 <<<<<
BYE sip:test@192.168.204.137:5060 SIP/2.0
X-Genesys-test_data: before_GVP
Min-SE: 90
Supported: timer, uui

test_data=After_GVP&__reason=exit

@10:01:35.6710 [0] 8.0.400.45 distribute_event: message EventAttachedDataChanged
AttributeUserData [183] 00 05 00 00..
‘GVP-Session-ID’ ‘6A1649E4-72DB-4420-B79E-3A78D0932F14;gvp.rm.datanodes=1;gvp.rm.tenant-id=1_DefaultIVR’
‘Allow’ ’ INFO’
‘Content-Length’ ‘427’
‘test_data’ ‘After_GVP’
‘__reason’ ‘exit’

@10:01:35.6710 [0] 8.0.400.45 distribute_response: message EventTreatmentEnd
AttributeEventSequenceNumber 00000000000002b0
AttributeUserData [183] 00 05 00 00..
‘GVP-Session-ID’ ‘6A1649E4-72DB-4420-B79E-3A78D0932F14;gvp.rm.datanodes=1;gvp.rm.tenant-id=1_DefaultIVR’
‘Allow’ ’ INFO’
‘Content-Length’ ‘427’
‘test_data’ ‘After_GVP’
‘__reason’ ‘exit’

Please use the method that is documented in Genesys integration guide in order to use properly the URS centric call flow (my previous post).

Kind Regards,
IF

bandorka · May 27, 2011, 1:17pm

First, thanks all efforts and help to solve this issue. I only changed one thing in my Composer script: add a return value to the EXIT block. In this way the update is working correctly!!! I don’t know, why just in this situation, but it’s ok at least.
Thanks again,
Bandorka

Kubig · August 7, 2013, 12:25pm

I know, that this topic is old, but I tried to use exit block with return values, but the KVP are double, not updated. Could somebody helps to me? It must be a penny things, what I cannot see.

smile · August 7, 2013, 12:54pm

why don’t use separate block for update attached data only?

Kubig · August 7, 2013, 12:59pm

I did it, but on exit of VXML app are listed old values and rewrite my values. Call-flow is following:

Attach data test=123 and call is on RP
Call is diverted to GVP with KVP test=123
In GVP I update KVP test=321
SIP generates EventAttachedDataChanged with new value - is ok
The VXML app ends and send reason=_exit and test=123
It rewrites KVP test on SIP server to old value

If I tried to use return value in exit block, test KVP was added, unfortunately twice - one with old value, second with new value

smile · August 7, 2013, 1:09pm

cool never faced with such behaviour
i can offer you to check exit block and check generated vxml code, probably somewhere is defined attaching KVP. sometimes it’s easy to find error in vxml rather than in callflow.
btw, of course you have variable ‘test’ in project and of course you update its value to 312 before you’re doing update interaction data?

Kubig · August 7, 2013, 1:15pm

As first, I did not use Composer And not use CTI connector, so I cannot use Interaction block for update. I updated data via “gvp:send” with namelist, it works, But all values are rewrited if the GVP app ends (in exit list are still old values)

smile · August 7, 2013, 1:22pm

extremely cool
well, my idea was in that gvp using application state variable which is mapped into userdata values. probably (imho) it’s possible to change userdata value but doesn’t change internal variable. It looks like you do it this way. try to change value of variable before you call gvp:send.

Kubig · August 7, 2013, 1:28pm

I have following “test” script:


<?xml version="1.0"?>
<vxml version="2.1" xmlns="http://www.w3.org/2001/vxml" xmlns:gvp="http://www.genesyslab.com/2006/vxml21-extension">
	<form id="Welcome">
		<block name="Hello">
			<script>
				var ServiceType ='default';
			</script>
			<audio src="prompts/brand.vox" />
			<audio src="prompts/welcometogenesys.vox" />
			<gvp:send namelist="ServiceType" />
			<audio src="prompts/goodbye.vox" />
			<exit namelist="ServiceType"/>
		</block>
		
	</form>
</vxml>

From SIP to GVP is send KVP “ServiceType” with value “Helpdesk”. GVP rewrites, via INFO SIP message, this value to “default”. In exit tag is too send value “default”, but list with “X-Genesys-” still contain old value, which rewrite my value from GVP.

smile · August 7, 2013, 8:31pm

Kubig, i can check your code in my lab tomorrow if this issue still actual for you.

Kubig · August 8, 2013, 7:09am

It works now, my fall.. I have configured “userdata-map-trans-prefix” to “X-Genesys” value and than SIP server used the “old” values from BYE message. If I set this option to empty value, all worked fine.So, I remember, that in older version than 8.1.7 were sometimes problem if this option was empty or not configured properly. Thanks for your effort and help, smile ..