GVP 8 - attached data not updated correctly

[bandorka]

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 [b]testkey=beforeGVP[/b]
------------------------------------------------------------------------------------------------------
2. 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 [[b]AppState.testkey;AppState.testkey='afterGVP'[/b];]
------------------------------------------------------------------------------------------------------
3. 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 [b]Sending INFO: testkey=afterGVP&testkey2=EnterValue[/b]
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: [b]testkey=afterGVP&testkey2=EnterValue[/b]
MCP: 13:36:36.263 Trc 33009 INFO 00000000-00000000 3024 02800FA1 [b][i]Response received: SIP/2.0 200 OK[/i][/b]
------------------------------------------------------------------------------------------------------
4. Logging the new value:
MCP: 13:36:36.294 Int 50035 007700DD-10003A9C 2384 log [b]testkey=afterGVP[/b]
------------------------------------------------------------------------------------------------------
5. 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: [b]testkey=afterGVP&testkey2=EnterValue[/b]

Distribute EventAttachedDataChanged
SIP: [b]Message EventAttachedDataChanged[/b]
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: [b] 'testkey' 'afterGVP'[/b]
SIP: 'testkey2' 'EnterValue'
SIP: AttributeCallUUID 'TI24M9BAG571V8QRK6STLBPH3G000004'
SIP: AttributeConnID 007001ed66dec004
SIP: AttributeCallID 4
SIP: AttributePropagatedCallType 1
SIP: AttributeCallType 1
------------------------------------------------------------------------------------------------------
6. 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
------------------------------------------------------------------------------------------------------
7. Distribute EventAttachedDataChanged

SIP: [b]Message EventAttachedDataChanged[/b]
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: [b] 'testkey' 'beforeGVP'[/b]
SIP: '__reason' 'exit'
SIP: AttributeCallUUID 'TI24M9BAG571V8QRK6STLBPH3G000004'
SIP: AttributeConnID 007001ed66dec004
SIP: AttributeCallID 4
SIP: AttributePropagatedCallType 1
SIP: AttributeCallType 1

[Fra]

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?

[size=8pt][font=verdana]
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)
[/font][/size]
Can you post the INVITE received by RM?

[bandorka]

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]

SIP version is 8.0.400.59 (hotfix)

[cavagnaro]

At the moment of 7, what does URS says?

[bandorka]

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]

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?

[IF]

Hi,

In your description you wrote "[i]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[/i]".

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

[René]

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.

[IF]

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:test@test.com>;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:test@test.com>;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]

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]

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]

[quote author=Kubig link=topic=6439.msg34773#msg34773 date=1375878336]
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.
[/quote]
why don't use separate block for update attached data only?

[Kubig]

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

1. Attach data test=123 and call is on RP
2. Call is diverted to GVP with KVP test=123
3. In GVP I update KVP test=321
4. SIP generates EventAttachedDataChanged with new value - is ok
5. The VXML app ends and send reason=_exit and test=123
6. 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]

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?