Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: bandorka on May 25, 2011, 12:44:01 PM
-
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
-
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? :D
[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?
-
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
---------------------------------------------------------------
-
SIP version is 8.0.400.59 (hotfix)
-
At the moment of 7, what does URS says?
-
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...
-
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?
-
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
-
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.
-
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
-
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
-
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 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?
-
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
-
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?
-
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)
-
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.
-
I have following "test" script:
[code]
<?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>
[/code]
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.
-
Kubig, i can check your code in my lab tomorrow if this issue still actual for you.
-
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 ..
-
Hi Kubig,
If you set "userdata-map-trans-prefix" to empty value then you lost possibility to pass any User Data to GVP (SIP -> GVP direction).
Correct solution is not updating User Data key(s) passed to GVP from routing but attaching new key(s). Reason for this is missing possibility to update User Data when using CTI via SIP Server.
R.
-
Hi René,
you are partly right, but I can say that all works fine with GVP8.1.7 without userdata-map-trans-prefix :-) I know that older version muset be configured with this option on SIP server side and as I understand the comments above, update KVP from GVP without CTI is possible.
-
On my test env (GVP 8.1.7 and SIP 8.1.1) update works as follow:
- With configured userdata-map-trans-prefix to any string (def. X-Genesys-)
[list]
[li]Add attached data from vxml app is possible[/li]
[li]Update is partly possible - until the vxml app ends. At the end, is INFO message send with output values like a reason, configured attached data in namelist parameter, etc. BUT, these attach data are not updated,but "only" added. During the run of vxml application update works fine, but the end rewrite it[/li]
[/list]
[code]
16:32:18.560: SIPTR: Received [0,UDP] 1413 bytes from 192.168.152.128:5160 <<<<<
INFO sip:6200@192.168.152.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.152.128:5160;branch=z9hG4bK00000000116A64A00a4372abcdef09
Via: SIP/2.0/UDP 192.168.152.128:5070;branch=z9hG4bK000000001CB083F00a4372
From: <sip:MediaServer@192.168.152.128:5060>;tag=0981799B-0806-4F90-679A-4EDC851DE4C9
To: "6200" <sip:6200@192.168.152.128>;tag=794DD231-276F-4589-BBC5-DE7CCE8AE5C8-1135
Max-Forwards: 69
CSeq: 5 INFO
Call-ID: E521A842-0830-45DA-AECD-D909F97CA8FA-1132@192.168.152.128
Content-Length: 310
Content-Type: application/vnd.radisys.msml+xml
X-Genesys-GVP-Session-ID: 33367761-DE23-4645-39BD-6951C95E7683;gvp.rm.datanodes=2;gvp.rm.tenant-id=101_OCS_Profile
X-Genesys-UD1: UD1DefaultValue
X-Genesys-UD2: UD2DefaultValue
X-Genesys-IW_OverrideOptions: ROUTING_PARAMS
X-Genesys-MediaType: voice
X-Genesys-Language: Czech
X-Genesys-ServiceType: Helpdesk
X-Genesys-Product: Service
User-Agent: X-Lite release 4.5.3 stamp 70569
Min-SE: 90
X-Genesys-GVP-Session-Data: callsession=33367761-DE23-4645-39BD-6951C95E7683;2;0;sip:192.168.152.128:5060;;;Resources;OCS_Profile;
Supported: timer, uui
<?xml version="1.0" encoding="UTF-8"?>
<msml version="1.1">
<event name="msml.dialog.exit" id="conn:0981799B-0806-4F90-679A-4EDC851DE4C9/dialog:ivr_application">
<name>UD1</name>
<value>4th value</value>
<name>UD2</name>
<value>UD2DefaultValue</value>
<name>__reason</name>
<value>exit</value>
</event>
</msml>
@16:32:18.5600 [0] 8.1.100.81 distribute_event: message EventAttachedDataChanged
AttributeEventSequenceNumber 0000000000000068
AttributeTimeinuSecs 560000
AttributeTimeinSecs 1376404338 (16:32:18)
AttributeThirdPartyDN '5502'
AttributeThisDNRole 2
AttributeThisDN '5502'
AttributeANI '6200'
AttributeDNIS '5502'
AttributeUserData [487] 00 0e 00 00..
'FirstName' 'Alfa'
'LastName' 'Beta'
'GVP-Session-ID' '33367761-DE23-4645-39BD-6951C95E7683;gvp.rm.datanodes=2;gvp.rm.tenant-id=101_OCS_Profile'
'UD1' 'UD1DefaultValue'
'UD2' 'UD2DefaultValue'
'IW_OverrideOptions' 'ROUTING_PARAMS'
'MediaType' 'voice'
'Language' 'Czech'
'ServiceType' 'Helpdesk'
'Product' 'Service'
'GVP-Session-Data' 'callsession=33367761-DE23-4645-39BD-6951C95E7683;2;0;sip:192.168.152.128:5060;;;Resources;OCS_Profile;'
'UD1' '4th value'
'UD2' 'UD2DefaultValue'
'__reason' 'exit'
AttributeCallUUID 'Q4M2P2G1T50CT4BKG5SQEALJG4000003'
AttributeConnID 007002303e14f003
AttributeCallID 3
AttributePropagatedCallType 2
AttributeCallType 2
[/code]
- With configured userdata-map-trans-prefix to empty value
[list]
[li]Add attached data from vxml app is possible[/li]
[li]Update attached data is possible. At the end the attached data are not rewrited[/li]
[/list]
[code]Via: SIP/2.0/UDP 192.168.152.128:5070;branch=z9hG4bK000000001CC7EFD00a46a2
From: <sip:MediaServer@192.168.152.128:5060>;tag=D3F60031-588D-4433-69B5-159A4B207323
To: "6200" <sip:6200@192.168.152.128>;tag=794DD231-276F-4589-BBC5-DE7CCE8AE5C8-1662
Max-Forwards: 69
CSeq: 5 INFO
Call-ID: E521A842-0830-45DA-AECD-D909F97CA8FA-1655@192.168.152.128
Content-Length: 295
Content-Type: application/vnd.radisys.msml+xml
X-Genesys-GVP-Session-ID: 2F70E6CC-6149-4581-52BB-9A4FD2EFD59C;gvp.rm.datanodes=2;gvp.rm.tenant-id=101_OCS_Profile
UD1: UD1DefaultValue
UD2: UD2DefaultValue
IW_OverrideOptions: ROUTING_PARAMS
MediaType: voice
Language: Czech
ServiceType: Helpdesk
Product: Service
User-Agent: X-Lite release 4.5.3 stamp 70569
Min-SE: 90
X-Genesys-GVP-Session-Data: callsession=2F70E6CC-6149-4581-52BB-9A4FD2EFD59C;2;0;sip:192.168.152.128:5060;;;Resources;OCS_Profile;
Supported: timer, uui
<?xml version="1.0" encoding="UTF-8"?>
<msml version="1.1">
<event name="msml.dialog.exit" id="conn:D3F60031-588D-4433-69B5-159A4B207323/dialog:ivr_application">
<name>UD1</name>
<value>4th value</value>
<name>UD2</name>
<value></value>
<name>__reason</name>
<value>exit</value>
</event>
</msml>
@16:45:54.4200 [0] 8.1.100.81 distribute_event: message EventAttachedDataChanged
AttributeEventSequenceNumber 0000000000000089
AttributeTimeinuSecs 420000
AttributeTimeinSecs 1376405154 (16:45:54)
AttributeThirdPartyDN '5502'
AttributeThisDNRole 2
AttributeThisDN '5502'
AttributeANI '6200'
AttributeDNIS '5502'
AttributeUserData [205] 00 0a 00 00..
'IW_OverrideOptions' 'ROUTING_PARAMS'
'MediaType' 'voice'
'Language' 'Czech'
'ServiceType' 'Helpdesk'
'Product' 'Service'
'FirstName' 'Alfa'
'LastName' 'Beta'
'UD2' 'undefined'
'UD1' '4th value'
'__reason' 'exit'
AttributeCallUUID 'Q4M2P2G1T50CT4BKG5SQEALJG4000007'
AttributeConnID 007002303e14f007
AttributeCallID 7
AttributePropagatedCallType 2
AttributeCallType 2
[/code]
Any help will be appreciated.
-
Hi Kubig,
Please add User Data keys that were updated by GVP app to Return Values parameter on Exit block.
R.
-
Hi René,
vxml app has returned values to update on exit block in both examples. From my point of view it seems like SIP server does not map KVP without configured prefix and MCP does not add to custom value any prefix, which can be matched. I do not know if the behavior is only for latest version of GVP, because I have received information from colleague, that in older version it works as expected (ie. with X-Genesys- prefix configured). So, I am little bit confused :-)
--K--
-
Nobody knows or has same experience? :-(
-
Kubig, if this issue still actual for you i'm planing to upgrade mcp to latest version on lab at next week. And then will able to test your scenario. It looks like feature/bug in 8.1.7, now i have 8.1.5 and can test on it if you like.
-
It is not "critical" for me, I am just testing new version of Genesys components on my lab env. So it is not related to real-life needs or issue. But for wonder, I would like to know how it works and if it is standard designed behavior. My colleague test it on his lab with GVP 8.1.4 and SIP 8.1.0, and it works. This makes me a little confused. According to my test, it seems like strange behavior of SIP, not GVP. But I am not sure of course.
-
I had a similar issue while testing MSML on GVP 8.1.5 in an URS-centric setup (no cti connector). In fact, it worked as designed.
When SIP Server initiates the INVITE msml to GVP it uses x-Headers ‘X-Genesys-<YourKey>: <Value1>’ (if you have the option "userdata-map-trans-prefix" set to X-Genesys-)
From this moment GVP will always add these x-headers in all responses.
As you are using msml, SIP Server sends INFO <dialogstart> to GVP and info is passed in the message body
<?xml version="1.0" encoding="UTF-8"?>
<msml version="1.1">
<gvp:param name="X-Genesys-<YourKey>">Value1</gvp:param>
on the (all) response you will always see the X-headers
<gvp:param name="X-Genesys-<YourKey>">Value1</gvp:param>
Then GVP can send INFO with several keys in body ( message will also contains all the X-headers) ... and if there are no user data in body of INFO then SIP Server will take the values from x-headers which contains old values.
If your are using NETANN then you don't have this problematic.
So you can
- adjust your vxml application that it send in INFO body all the keys you want to see updated (for all subsequent INFO messages).
- adapt the exit of your vxml app so that on the BYE you will have X-headers with the updated values.
- Maybe play around with the options copyxgenesysheaders to filter user data (?)
-
Thanks for your input and hints, but you are just partly right. The main problem/issue is in different behavior between version and I am little bit confused what is the properly behavior of it.