Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Cisco Community
- Technology and Support
- DevNet
- DevNet Collaboration
- Collaboration Knowledge Base
- Error while accessing UUI
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
538
Views
0
Helpful
0
Comments
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 01-24-2014 05:52 PM
This document was generated from CDN thread
Created by: Vladimir Lozano Martinez on 23-09-2013 02:38:12 PM
I currently are sending UUI over ISDN, but when I'm trying to retrieve the value from UUI the call drops.
This is a vxml section where I retrieve the UUI:
<form id="start">
<var name="vloz_gtd" expr="new com.cisco.objclass.gtd(com.cisco.signal.gtdlist['setup_indication'])" />
<var name="UUI" expr="vloz_gtd.UUS[0].dat" />
The VXML Gw debug say these:
*Sep 23 19:06:19.071: ccGTDExtractParm: GTD Parm CPC obtained
*Sep 23 19:06:19.071: ccGTDExtractParm: GTD Parm TMR obtained
*Sep 23 19:06:19.071: ccGTDExtractParm: GTD Parm PRN obtained*Sep 23 19:06:19.071: ccMapGCItoGUID: GTD Parm GCI present: 1000e5a323ba11e3835c7cad74cf36d0
*Sep 23 19:06:19.071: Have gtd msg, length=227:
*Sep 23 19:06:19.071: gtd msg ="IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,1000e5a323ba11e3835c7cad74cf36d0"
*Sep 23 19:06:19.087: //2757/1000E5A3835C/VXML:/vxml_jse_add_gtd_obj_to_list:
Sig-event name = setup_indication, gtd-len = 227, gtd-buf = IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,1000e5a323ba11e3835c7cad74cf36d0
*Sep 23 19:06:19.547: //2757/1000E5A3835C/VXML:/vxml_com_cisco_objclass_gtd_constructor: Entered. argc = 1
*Sep 23 19:06:19.547: //2757/1000E5A3835C/VXML:/vxml_com_cisco_objclass_gtd_constructor: Constructor for 'com.cisco.objclass.gtd' with object
*Sep 23 19:06:19.547: //2757/1000E5A3835C/VXML:/vxml_com_cisco_objclass_gtd_constructor: Done. New GTD object = 0xC0308B54*Sep 23 19:06:19.547: //2757/1000E5A3835C/VXML:/vxml_gtd_get_callback: Param name , param-id [117]
*Sep 23 19:06:19.547: //2757/1000E5A3835C/VXML:/vxml_gtd_parm_get_callback: Property is an instance number [0]. Param name
*Sep 23 19:06:19.547: //2757/1000E5A3835C/VXML:/vxml_get_gtd_parm_field: Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 23 19:06:19.547: //-1//VXML:/vxml_hexadecimal_to_ascii: ERROR: Invalid hex char [0x61]
I'll appretiate any suggestion.
Subject: RE: Error while accessing UUI
Replied by: Paul Tindall on 23-09-2013 03:04:48 PM
As it's objecting to lower case 'a', try sending an uppercase hex string with only A-F, 0-9
Subject: RE: Error while accessing UUI
Replied by: Vladimir Lozano Martinez on 23-09-2013 06:18:23 PM
Hi Paul
Since this value is stored into a gtd object and thinking that the error comes when the UUI is assingning, I did this:
<form id="start">
<script><![CDATA[function getInfo(){
var vloz_gtd = new com.cisco.objclass.gtd(com.cisco.signal.gtdlist['setup_indication']);
return vloz_gtd.UUS[0].dat.toUpperCase();
}]]></script>
<var name="UUI" expr="getInfo()" />
<block>
<submit next="/CVP/Server" method="post" namelist="UUI audium_vxmlLog" />
</block>
</form>
but the error remains the same.
Now, I noted that when I send UUI seting vloz_gtd.UUS[0].pd to 0 I can not read the UUI in the other endpoint
VXML
<var name="vloz_gtd" expr="new com.cisco.objclass.gtd()" />
<var name="vloz_gtd.message_type" expr="'IAM'" />
<var name="vloz_gtd.UUS[0].pd" expr="0" />
<var name="vloz_gtd.UUS[0].dat" expr="'B B B B B B B B2B3B B B B B B GCB!B B CB7B4B3B!'" />
GW debug
*Sep 19 18:44:31.182: gtd msg = "IAM,
UUS,0,42204220422042204220422042204232423342204220422042204220422047431742214220422043024237423442334221GCI,557bfa02209211e383297cad74cf36d0"
When I set vloz_gtd.UUS[0].pd to 3 I can read whitout any problem in the other end point.
VXML
<var name="vloz_gtd" expr="new com.cisco.objclass.gtd()" />
<var name="vloz_gtd.message_type" expr="'IAM'" />
<var name="vloz_gtd.UUS[0].pd" expr="3" />
<var name="vloz_gtd.UUS[0].dat" expr="'B B B B B B B B2B3B B B B B B GCB!B B CB7B4B3B!'" />
GW debug
*Sep 20 00:13:46.253: gtd msg = "IAM,
UUS,3,422042204220422042204220422042353D4304422143072E75434220422042204220422042204220422042314222"
So, when the Gateway is reading the UUI comes in the same fotmat that setting vloz_gtd.UUS[0].pd to 3.
Subject: RE: Error while accessing UUI
Replied by: Paul Tindall on 23-09-2013 07:29:44 PM
Vladimir,
I'm not quite 100% sure what your scenario is. Are you communicating UUI between 2 Cisco gateways over ISDN?
The protocol discriminator indicates what type of data is encoded in the hex data. pd = 0 specifies undefined format, pd = 3 specifies IA5 character string. Either should work. When you set UUS[0].dat, what encoding do you see in debug gtd detail? What do you then see at the receiving end in debug? Are you seeing the same content? What do you see in the ISDN Q931 debug?
Subject: RE: Error while accessing UUI
Replied by: Vladimir Lozano Martinez on 24-09-2013 12:26:17 PM
Hi Paul,
I'm not sure what's the other endpoint device, it seems to be an Avaya PBX (I will confirm it). These are the debugs I have collected a few days ago.
*Sep 19 19:02:31.730: //2597/DED6B414832B/VXML:/vxml_jse_add_gtd_obj_to_list:
Sig-event name = setup_indication, gtd-len = 227, gtd-buf =
IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,ded6b414209411e3832b7cad74cf36d0
*Sep 19 19:02:31.730: //2597/DED6B414832B/VXML:/vxml_jse_add_gtd_obj_to_list:
gtd_obj for sig-event [setup_indication] added to session/shadow
var array [0x40459AE8]
*Sep 19 19:02:31.730: //2597/DED6B414832B/VXML:/vxml_create_gtd_sess_vars:
Created object chain for com.cisco.signal.gtdlistGWINB01#
*Sep 19 19:02:31.738: **CVP**DED6B414209411E3832B7CAD74CF36D0**pruebaInbursa**Starting Application...
*Sep 19 19:02:32.386: //2597/DED6B414832B/VXML:/vxml_gtd_get_callback:
Param name , param-id [117]
*Sep 19 19:02:32.386: //2597/DED6B414832B/VXML:/vxml_gtd_parm_get_callback:
Property is an instance number [0]. Param name
*Sep 19 19:02:32.386: //2597/DED6B414832B/VXML:/vxml_get_gtd_parm_field:
Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 19 19:02:32.386: //-1//VXML:/vxml_hexadecimal_to_ascii:
ERROR: Invalid hex char [0x61]
*Sep 19 19:02:32.390: //2597/DED6B414832B/VXML:/vxml_gtd_get_callback:
Param name , param-id [117]
*Sep 19 19:02:32.390: //2597/DED6B414832B/VXML:/vxml_gtd_parm_get_callback:
Property is an instance number [0]. Param name
*Sep 19 19:02:32.390: //2597/DED6B414832B/VXML:/vxml_get_gtd_parm_field:
Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 19 19:02:32.394: //-1//VXML:/vxml_hexadecimal_to_ascii:
ERROR: Invalid hex char [0x61]
*Sep 19 19:02:32.398: //2597/DED6B414832B/VXML:/vxml_gtd_get_callback:
Param name , param-id [117]
*Sep 19 19:02:32.398: //2597/DED6B414832B/VXML:/vxml_gtd_parm_get_callback:
Property is an instance number [0]. Param name
*Sep 19 19:02:32.398: //2597/DED6B414832B/VXML:/vxml_get_gtd_parm_field:
Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 19 19:02:32.398: //-1//VXML:/vxml_hexadecimal_to_ascii:
ERROR: Invalid hex char [0x61]
*Sep 19 19:02:32.402: //2597/DED6B414832B/VXML:/vxml_gtd_get_callback:
Param name , param-id [117]
*Sep 19 19:02:32.402: //2597/DED6B414832B/VXML:/vxml_gtd_parm_get_callback:
Property is an instance number [0]. Param name
*Sep 19 19:02:32.402: //2597/DED6B414832B/VXML:/vxml_get_gtd_parm_field:
Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 19 19:02:32.402: //-1//VXML:/vxml_hexadecimal_to_ascii:
ERROR: Invalid hex char [0x61]
*Sep 19 19:02:32.406: //2597/DED6B414832B/VXML:/vxml_gtd_get_callback:
Param name , param-id [117]
*Sep 19 19:02:32.406: //2597/DED6B414832B/VXML:/vxml_gtd_parm_get_callback:
Property is an instance number [0]. Param name
*Sep 19 19:02:32.406: //2597/DED6B414832B/VXML:/vxml_get_gtd_parm_field: GWINB01#
Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 19 19:02:32.406: //-1//VXML:/vxml_hexadecimal_to_ascii:
ERROR: Invalid hex char [0x61]
When I send information, at the receiving end point the information received is the same as I sent. The problem becomes only when I try to read the received information. It seems that the values is readed correctly from GTD, but then fails when the GW is passing the value to VXML var, as shown in the previous debugs. I'll be collecting the suggested debugs.
Thanks.
Subject: RE: Error while accessing UUI
Replied by: Vladimir Lozano Martinez on 24-09-2013 07:18:43 PM
Hi Paul,
I confirmed and the gateway is connected to an Avaya PBX. These are the results for the debug that you has suggested:
*Sep 24 23:56:27.439: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x3C0B
Sending Complete
Bearer Capability i = 0x9090A3
Standard = CCITT
Transfer Capability = 3.1kHz Audio
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA18381
Preferred, Channel 1
Facility i = 0x9FAA068001008201008B0100A1180202B327020100800F454A4543555449564F2043414C4C43
Progress Ind i = 0x8183 - Origination address is non-ISDN
Calling Party Number i = 0x0080, '6043'
Plan:Unknown, Type:Unknown
Called Party Number i = 0xA1, '5817001'
Plan:ISDN, Type:National
User-User i = 0x04A0A0A0A0A0A0A0B5, '=', 0xC4A1C7, '.uC', 0xA0A0A0A0A0A0A0A0B1A200
Locking Shift to Codeset 4
Codeset 4 IE 0x31 i = 0x80
*Sep 24 23:56:27.439: ISDN Se0/0/0:15: Built a GTD of size 227 octets for ISDN message type 0x5
*Sep 24 23:56:27.439: tsp_ccrawmsg_encap: calling cdapi_find_tsm
*Sep 24 23:56:27.439: cdapi_find_tsm: Found Tunnelled Signaling Msg with GTD: PROT_PTYPE_GTD
*Sep 24 23:56:27.439: cdapi_find_tsm: Found a gtd msg of length 227:
*Sep 24 23:56:27.439: gtd msg = "IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,c29e257024ab11e383897cad74cf36d0"
*Sep 24 23:56:27.443: ccGTDExtractParm: Starting
*Sep 24 23:56:27.443: tunnelledPtype = 2
*Sep 24 23:56:27.443: gtdInstance = 0
*Sep 24 23:56:27.443: gtdBitMap = 0xFFFFFFFF
*Sep 24 23:56:27.443: ccGTDExtractParm: TunnelledContent has GTD message
*Sep 24 23:56:27.443: gtd msg = "IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,c29e257024ab11e383897cad74cf36d0"
*Sep 24 23:56:27.443: ccGTDExtractParm: GTD Parm CPC obtained
*Sep 24 23:56:27.443: ccGTDExtractParm: GTD Parm TMR obtained
*Sep 24 23:56:27.443: ccGTDExtractParm: GTD Parm PRN obtained
*Sep 24 23:56:27.443: ccMapGCItoGUID: GTD Parm GCI present: c29e257024ab11e383897cad74cf36d0
*Sep 24 23:56:27.447: Have gtd msg, length=227:*Sep 24 23:56:27.447: gtd msg = "IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,c29e257024ab11e383897cad74cf36d0"
*Sep 24 23:56:27.451: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xBC0B
Channel ID i = 0xA98381
Exclusive, Channel 1
*Sep 24 23:56:27.451: ISDN Se0/0/0:15 Q931: TX -> CONNECT pd = 8 callref = 0xBC0B
Connected Number i = 0x80, '5817001'
*Sep 24 23:56:27.471: ISDN Se0/0/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x3C0B
*Sep 24 23:56:28.135: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0xBC0B Cause i = 0x8090 - Normal call clearing
*Sep 24 23:56:28.143: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x3C0B
*Sep 24 23:56:28.143: ISDN Se0/0/0:15: Built a GTD of size 27 octets for ISDN message type 0x5A
GWINB01#
*Sep 24 23:56:28.143: tsp_ccrawmsg_encap: calling cdapi_find_tsm
*Sep 24 23:56:28.143: cdapi_find_tsm: Found Tunnelled Signaling Msg with GTD: PROT_PTYPE_GTD
*Sep 24 23:56:28.143: cdapi_find_tsm: Found a gtd msg of length 27:
*Sep 24 23:56:28.143: gtd msg = "RLC,PRN,isdn*,,QSIG*,"
*Sep 24 23:56:28.143: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xBC0B
Subject: RE: Error while accessing UUI
Replied by: Paul Tindall on 25-09-2013 07:04:29 AM
It does look very much like reading UUS from VoiceXML has a problem with lowercase hex. Try the attached custom element just to check that it gives the same behaviour. If so, we could try a workaround by handing-off to TCL to retrieve the GTD.
Subject: RE: Error while accessing UUI
Replied by: Vladimir Lozano Martinez on 25-09-2013 05:09:53 PM
Hi Paul,
The result is the same. Here are som debugs:
<form id="start">
<var name="gtd" expr="com.cisco.signal.gtdlist['setup_indication']" />
<var name="gtdval" expr="gtd.UUS[0].dat" />
<block>
<submit next="/CVP/Server" method="post" namelist="audium_vxmlLog gtdval" />
</block>
...............................................................................................................................................................
*Sep 25 21:42:56.142: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x3D1B
Sending Complete
Bearer Capability i = 0x9090A3
Standard = CCITT
Transfer Capability = 3.1kHz Audio
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s Channel ID i = 0xA18381 Preferred, Channel 1
Facility i = 0x9FAA068001008201008B0100A1180202FDBC020100800F454A4543555449564F2043414C4C43
Progress Ind i = 0x8183 - Origination address is non-ISDN
Calling Party Number i = 0x0080, '6043'
Plan:Unknown, Type:Unknown
Called Party Number i = 0xA1, '5817001'ç
Plan:ISDN, Type:National
User-User i = 0x04A0A0A0A0A0A0A0B5, '=', 0xC4A1C7, '.uC', 0xA0A0A0A0A0A0A0A0B1A200
Locking Shift to Codeset 4
Codeset 4 IE 0x31 i = 0x80
*Sep 25 21:42:56.142: ISDN Se0/0/0:15: Built a GTD of size 227 octets for ISDN message type 0x5
*Sep 25 21:42:56.142: tsp_ccrawmsg_encap: calling cdapi_find_tsm*Sep 25 21:42:56.142: cdapi_find_tsm: Found Tunnelled Signaling Msg with GTD: PROT_PTYPE_GTD
*Sep 25 21:42:56.142: cdapi_find_tsm: Found a gtd msg of length 227:
*Sep 25 21:42:56.142: gtd msg = "IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,45ececff256211e383a67cad74cf36d0"
*Sep 25 21:42:56.146: ccGTDExtractParm: Starting
*Sep 25 21:42:56.146: tunnelledPtype = 2
*Sep 25 21:42:56.146: gtdInstance = 0
*Sep 25 21:42:56.146: gtdBitMap = 0xFFFFFFFF
*Sep 25 21:42:56.146: ccGTDExtractParm: TunnelledContent has GTD message
*Sep 25 21:42:56.146: gtd msg = "IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,45ececff256211e383a67cad74cf36d0"
*Sep 25 21:42:56.146: ccGTDExtractParm: GTD Parm CPC obtained
*Sep 25 21:42:56.146: ccGTDExtractParm: GTD Parm TMR obtained
*Sep 25 21:42:56.146: ccGTDExtractParm: GTD Parm PRN obtained
*Sep 25 21:42:56.146: ccMapGCItoGUID: GTD Parm GCI present: 45ececff256211e383a67cad74cf36d0*Sep 25 21:42:56.146: Have gtd msg, length=227:
*Sep 25 21:42:56.146: gtd msg = "IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,GCI,45ececff256211e383a67cad74cf36d0"
*Sep 25 21:42:56.162: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xBD1B
Channel ID i = 0xA98381 Exclusive, Channel 1
*Sep 25 21:42:56.162: ISDN Se0/0/0:15 Q931: TX -> CONNECT pd = 8 callref = 0xBD1B Connected Number i = 0x80, '5817001'
*Sep 25 21:42:56.166: //2976/45ECECFF83A6/VXML:/vxml_jse_add_gtd_obj_to_list: Sig-event name = setup_indication, gtd-len = 227, gtd-buf = IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,45ececff256211e383a67cad74cf36d0
*Sep 25 21:42:56.166: //2976/45ECECFF83A6/VXML:/vxml_jse_add_gtd_obj_to_list:
gtd_obj for sig-event [setup_indication] added to session/shadow var array [0x404546F0]
*Sep 25 21:42:56.166: //2976/45ECECFF83A6/VXML:/vxml_create_gtd_sess_vars:
Created object chain for com.cisco.signal.gtdlist
*Sep 25 21:42:56.186: ISDN Se0/0/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x3D1B
*Sep 25 21:42:56.234: ISDN Se0/0/0:15 Q931: RX <- FACILITY pd = 8 callref = 0x3D1B Facility i = 0x9FAA068001008201008B0100A1180202FDBD02010C30800A0101810080067072756562610000
*Sep 25 21:42:56.234: ISDN Se0/0/0:15: Built a GTD of size 27 octets for ISDN message type 0x62
*Sep 25 21:42:56.234: tsp_ccrawmsg_encap: calling cdapi_find_tsm
*Sep 25 21:42:56.234: cdapi_find_tsm: Found Tunnelled Signaling Msg with GTD: PROT_PTYPE_GTD
*Sep 25 21:42:56.234: cdapi_find_tsm: Found a gtd msg of length 27:
*Sep 25 21:42:56.234: gtd msg = "FAC,PRN,isdn*,,QSIG*,"
*Sep 25 21:42:56.514: //2976/45ECECFF83A6/VXML:/vxml_gtd_get_callback:
Param name , param-id [117]
*Sep 25 21:42:56.514: //2976/45ECECFF83A6/VXML:/vxml_gtd_parm_get_callback:
Property is an instance number [0]. Param name
*Sep 25 21:42:56.514: //2976/45ECECFF83A6/VXML:/vxml_get_gtd_parm_field:
GWINB01#
Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 25 21:42:56.514: //-1//VXML:/vxml_hexadecimal_to_ascii:
ERROR: Invalid hex char [0x61]
*Sep 25 21:42:56.530: //2976/45ECECFF83A6/VXML:/vxml_disconnect_proc: GTD not present in <disconnect>
GWINB01#
*Sep 25 21:43:05.030: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0xBD1B
Cause i = 0x80BF - Service/option not available, unspecified
*Sep 25 21:43:05.050: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x3D1B
*Sep 25 21:43:05.050: ISDN Se0/0/0:15: Built a GTD of size 27 octets for ISDN message type 0x5A
*Sep 25 21:43:05.050: tsp_ccrawmsg_encap: calling cdapi_find_tsm
*Sep 25 21:43:05.050: cdapi_find_tsm: Found Tunnelled Signaling Msg with GTD: PROT_PTYPE_GTD
*Sep 25 21:43:05.050: cdapi_find_tsm: Found a gtd msg of length 27:*Sep 25 21:43:05.050: gtd msg = "RLC,PRN,isdn*,,QSIG*,"
GWINB01#
*Sep 25 21:43:05.054: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xBD1B
GWINB01#
GWINB01#
GWINB01#
*Sep 25 21:46:37.686: ISDN Se0/0/0:15 Q931: RX <- STATUS_ENQ pd = 8 callref = 0x3E42
*Sep 25 21:46:37.686: ISDN Se0/0/0:15 **ERROR**: L3_BadPeerMsg: event 0x75 cr 0xBE42 callid 0x0
*Sep 25 21:46:37.686: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xBE42 Cause i = 0x80D1 - Invalid call reference value
Greetings
Subject: RE: Error while accessing UUI
Replied by: Paul Tindall on 26-09-2013 09:23:29 AM
Vladimir,
I think we should assume you've hit a possible defect here and the workaround I'd suggest to try is handing-off to TCL to retrieve the GTD UUS content. If you need help to do that I can send you something to try but it's unlikely to be today.
One more thing to try -- just as a test, can you get the sending end to simply send a user-user data string that only translates to numeric hex digits? Second thing could be to try only including standard ascii 7 bit characters in the source data so the hex values are less than 0x80.
Paul
Subject: RE: Error while accessing UUI
Replied by: Vladimir Lozano Martinez on 26-09-2013 12:41:55 PM
Hi Paul,
I don't have any experience working with handoff, I'll apreciate any help. Meanwhile I will be reviewing what can I do from the sending side.
Greetings.
Subject: RE: Error while accessing UUI
Replied by: Paul Tindall on 03-10-2013 10:28:04 PM
Vladimir,
Unfortunately the approach of handing-off to TCL doesn't work as the GTD setup object isn't accessible when processing a handoff event. The only alternative I can suggest is to modify the boostrap code and pass UUI up to the CVP application when it's invoked. The downside of that approach is that you'd have to deploy a customised CVPSelfService.tcl application (assuming this is standalone model).
Paul
Subject: RE: Error while accessing UUI
Replied by: Vladimir Lozano Martinez on 07-10-2013 12:45:18 PM
Hi Paul,
Actually this is a Standalone model. I run some additional test regarding to send UUI in binary and Ascii, and the behaivor is the same. The UUI is arriving in the same format:
Subject: RE: Error while accessing UUI
Replied by: Paul Tindall on 07-10-2013 02:04:35 PM
In this example the UUI still has characters greater than 7f hex, for example, the string of a0's at the beginning. As a test, can you send some UUI that maybe just has IA5 content, perhaps, the hex translation of "12345" or similar that would have only 7 bit characters? It may not be the issue but I can see from your original traces that the hex translation failed on the first digit being 'a' (non-IA5) as not a valid hex value. It's the first time I've seen any problems with UUI but I've never sent non-IA5 content.
Created by: Vladimir Lozano Martinez on 23-09-2013 02:38:12 PM
I currently are sending UUI over ISDN, but when I'm trying to retrieve the value from UUI the call drops.
This is a vxml section where I retrieve the UUI:
<form id="start">
<var name="vloz_gtd" expr="new com.cisco.objclass.gtd(com.cisco.signal.gtdlist['setup_indication'])" />
<var name="UUI" expr="vloz_gtd.UUS[0].dat" />
The VXML Gw debug say these:
*Sep 23 19:06:19.071: ccGTDExtractParm: GTD Parm CPC obtained
*Sep 23 19:06:19.071: ccGTDExtractParm: GTD Parm TMR obtained
*Sep 23 19:06:19.071: ccGTDExtractParm: GTD Parm PRN obtained*Sep 23 19:06:19.071: ccMapGCItoGUID: GTD Parm GCI present: 1000e5a323ba11e3835c7cad74cf36d0
*Sep 23 19:06:19.071: Have gtd msg, length=227:
*Sep 23 19:06:19.071: gtd msg ="IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,1000e5a323ba11e3835c7cad74cf36d0"
*Sep 23 19:06:19.087: //2757/1000E5A3835C/VXML:/vxml_jse_add_gtd_obj_to_list:
Sig-event name = setup_indication, gtd-len = 227, gtd-buf = IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,1000e5a323ba11e3835c7cad74cf36d0
*Sep 23 19:06:19.547: //2757/1000E5A3835C/VXML:/vxml_com_cisco_objclass_gtd_constructor: Entered. argc = 1
*Sep 23 19:06:19.547: //2757/1000E5A3835C/VXML:/vxml_com_cisco_objclass_gtd_constructor: Constructor for 'com.cisco.objclass.gtd' with object
*Sep 23 19:06:19.547: //2757/1000E5A3835C/VXML:/vxml_com_cisco_objclass_gtd_constructor: Done. New GTD object = 0xC0308B54*Sep 23 19:06:19.547: //2757/1000E5A3835C/VXML:/vxml_gtd_get_callback: Param name , param-id [117]
*Sep 23 19:06:19.547: //2757/1000E5A3835C/VXML:/vxml_gtd_parm_get_callback: Property is an instance number [0]. Param name
*Sep 23 19:06:19.547: //2757/1000E5A3835C/VXML:/vxml_get_gtd_parm_field: Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 23 19:06:19.547: //-1//VXML:/vxml_hexadecimal_to_ascii: ERROR: Invalid hex char [0x61]
I'll appretiate any suggestion.
Subject: RE: Error while accessing UUI
Replied by: Paul Tindall on 23-09-2013 03:04:48 PM
As it's objecting to lower case 'a', try sending an uppercase hex string with only A-F, 0-9
Subject: RE: Error while accessing UUI
Replied by: Vladimir Lozano Martinez on 23-09-2013 06:18:23 PM
Hi Paul
Since this value is stored into a gtd object and thinking that the error comes when the UUI is assingning, I did this:
<form id="start">
<script><![CDATA[function getInfo(){
var vloz_gtd = new com.cisco.objclass.gtd(com.cisco.signal.gtdlist['setup_indication']);
return vloz_gtd.UUS[0].dat.toUpperCase();
}]]></script>
<var name="UUI" expr="getInfo()" />
<block>
<submit next="/CVP/Server" method="post" namelist="UUI audium_vxmlLog" />
</block>
</form>
but the error remains the same.
Now, I noted that when I send UUI seting vloz_gtd.UUS[0].pd to 0 I can not read the UUI in the other endpoint
VXML
<var name="vloz_gtd" expr="new com.cisco.objclass.gtd()" />
<var name="vloz_gtd.message_type" expr="'IAM'" />
<var name="vloz_gtd.UUS[0].pd" expr="0" />
<var name="vloz_gtd.UUS[0].dat" expr="'B B B B B B B B2B3B B B B B B GCB!B B CB7B4B3B!'" />
GW debug
*Sep 19 18:44:31.182: gtd msg = "IAM,
UUS,0,42204220422042204220422042204232423342204220422042204220422047431742214220422043024237423442334221GCI,557bfa02209211e383297cad74cf36d0"
When I set vloz_gtd.UUS[0].pd to 3 I can read whitout any problem in the other end point.
VXML
<var name="vloz_gtd" expr="new com.cisco.objclass.gtd()" />
<var name="vloz_gtd.message_type" expr="'IAM'" />
<var name="vloz_gtd.UUS[0].pd" expr="3" />
<var name="vloz_gtd.UUS[0].dat" expr="'B B B B B B B B2B3B B B B B B GCB!B B CB7B4B3B!'" />
GW debug
*Sep 20 00:13:46.253: gtd msg = "IAM,
UUS,3,422042204220422042204220422042353D4304422143072E75434220422042204220422042204220422042314222"
So, when the Gateway is reading the UUI comes in the same fotmat that setting vloz_gtd.UUS[0].pd to 3.
| *Sep 23 19:06:19.087: //2757/1000E5A3835C/VXML:/vxml_jse_add_gtd_obj_to_list: Sig-event name = setup_indication, gtd-len = 227, gtd-buf = IAM, PRN,isdn*,,QSIG*, USI,rate,c,3,c,1 USI,lay1,alaw TMR,02 CPN,04,,1,5817001 CGN,00,,u,y,1,6043 UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200 CPC,09 FCI,,,,,,,y, GCI,1000e5a323ba11e3835c7cad74cf36d0 I tryed to set UUS[0].pd to 3 when reading, but this fails too (the call drops). Like this:
There is one way to tell the GW to read and send the value as readed? thanks |
Subject: RE: Error while accessing UUI
Replied by: Paul Tindall on 23-09-2013 07:29:44 PM
Vladimir,
I'm not quite 100% sure what your scenario is. Are you communicating UUI between 2 Cisco gateways over ISDN?
The protocol discriminator indicates what type of data is encoded in the hex data. pd = 0 specifies undefined format, pd = 3 specifies IA5 character string. Either should work. When you set UUS[0].dat, what encoding do you see in debug gtd detail? What do you then see at the receiving end in debug? Are you seeing the same content? What do you see in the ISDN Q931 debug?
Subject: RE: Error while accessing UUI
Replied by: Vladimir Lozano Martinez on 24-09-2013 12:26:17 PM
Hi Paul,
I'm not sure what's the other endpoint device, it seems to be an Avaya PBX (I will confirm it). These are the debugs I have collected a few days ago.
*Sep 19 19:02:31.730: //2597/DED6B414832B/VXML:/vxml_jse_add_gtd_obj_to_list:
Sig-event name = setup_indication, gtd-len = 227, gtd-buf =
IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,ded6b414209411e3832b7cad74cf36d0
*Sep 19 19:02:31.730: //2597/DED6B414832B/VXML:/vxml_jse_add_gtd_obj_to_list:
gtd_obj for sig-event [setup_indication] added to session/shadow
var array [0x40459AE8]
*Sep 19 19:02:31.730: //2597/DED6B414832B/VXML:/vxml_create_gtd_sess_vars:
Created object chain for com.cisco.signal.gtdlistGWINB01#
*Sep 19 19:02:31.738: **CVP**DED6B414209411E3832B7CAD74CF36D0**pruebaInbursa**Starting Application...
*Sep 19 19:02:32.386: //2597/DED6B414832B/VXML:/vxml_gtd_get_callback:
Param name , param-id [117]
*Sep 19 19:02:32.386: //2597/DED6B414832B/VXML:/vxml_gtd_parm_get_callback:
Property is an instance number [0]. Param name
*Sep 19 19:02:32.386: //2597/DED6B414832B/VXML:/vxml_get_gtd_parm_field:
Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 19 19:02:32.386: //-1//VXML:/vxml_hexadecimal_to_ascii:
ERROR: Invalid hex char [0x61]
*Sep 19 19:02:32.390: //2597/DED6B414832B/VXML:/vxml_gtd_get_callback:
Param name , param-id [117]
*Sep 19 19:02:32.390: //2597/DED6B414832B/VXML:/vxml_gtd_parm_get_callback:
Property is an instance number [0]. Param name
*Sep 19 19:02:32.390: //2597/DED6B414832B/VXML:/vxml_get_gtd_parm_field:
Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 19 19:02:32.394: //-1//VXML:/vxml_hexadecimal_to_ascii:
ERROR: Invalid hex char [0x61]
*Sep 19 19:02:32.398: //2597/DED6B414832B/VXML:/vxml_gtd_get_callback:
Param name , param-id [117]
*Sep 19 19:02:32.398: //2597/DED6B414832B/VXML:/vxml_gtd_parm_get_callback:
Property is an instance number [0]. Param name
*Sep 19 19:02:32.398: //2597/DED6B414832B/VXML:/vxml_get_gtd_parm_field:
Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 19 19:02:32.398: //-1//VXML:/vxml_hexadecimal_to_ascii:
ERROR: Invalid hex char [0x61]
*Sep 19 19:02:32.402: //2597/DED6B414832B/VXML:/vxml_gtd_get_callback:
Param name , param-id [117]
*Sep 19 19:02:32.402: //2597/DED6B414832B/VXML:/vxml_gtd_parm_get_callback:
Property is an instance number [0]. Param name
*Sep 19 19:02:32.402: //2597/DED6B414832B/VXML:/vxml_get_gtd_parm_field:
Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 19 19:02:32.402: //-1//VXML:/vxml_hexadecimal_to_ascii:
ERROR: Invalid hex char [0x61]
*Sep 19 19:02:32.406: //2597/DED6B414832B/VXML:/vxml_gtd_get_callback:
Param name , param-id [117]
*Sep 19 19:02:32.406: //2597/DED6B414832B/VXML:/vxml_gtd_parm_get_callback:
Property is an instance number [0]. Param name
*Sep 19 19:02:32.406: //2597/DED6B414832B/VXML:/vxml_get_gtd_parm_field: GWINB01#
Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 19 19:02:32.406: //-1//VXML:/vxml_hexadecimal_to_ascii:
ERROR: Invalid hex char [0x61]
When I send information, at the receiving end point the information received is the same as I sent. The problem becomes only when I try to read the received information. It seems that the values is readed correctly from GTD, but then fails when the GW is passing the value to VXML var, as shown in the previous debugs. I'll be collecting the suggested debugs.
Thanks.
Subject: RE: Error while accessing UUI
Replied by: Vladimir Lozano Martinez on 24-09-2013 07:18:43 PM
Hi Paul,
I confirmed and the gateway is connected to an Avaya PBX. These are the results for the debug that you has suggested:
*Sep 24 23:56:27.439: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x3C0B
Sending Complete
Bearer Capability i = 0x9090A3
Standard = CCITT
Transfer Capability = 3.1kHz Audio
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA18381
Preferred, Channel 1
Facility i = 0x9FAA068001008201008B0100A1180202B327020100800F454A4543555449564F2043414C4C43
Progress Ind i = 0x8183 - Origination address is non-ISDN
Calling Party Number i = 0x0080, '6043'
Plan:Unknown, Type:Unknown
Called Party Number i = 0xA1, '5817001'
Plan:ISDN, Type:National
User-User i = 0x04A0A0A0A0A0A0A0B5, '=', 0xC4A1C7, '.uC', 0xA0A0A0A0A0A0A0A0B1A200
Locking Shift to Codeset 4
Codeset 4 IE 0x31 i = 0x80
*Sep 24 23:56:27.439: ISDN Se0/0/0:15: Built a GTD of size 227 octets for ISDN message type 0x5
*Sep 24 23:56:27.439: tsp_ccrawmsg_encap: calling cdapi_find_tsm
*Sep 24 23:56:27.439: cdapi_find_tsm: Found Tunnelled Signaling Msg with GTD: PROT_PTYPE_GTD
*Sep 24 23:56:27.439: cdapi_find_tsm: Found a gtd msg of length 227:
*Sep 24 23:56:27.439: gtd msg = "IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,c29e257024ab11e383897cad74cf36d0"
*Sep 24 23:56:27.443: ccGTDExtractParm: Starting
*Sep 24 23:56:27.443: tunnelledPtype = 2
*Sep 24 23:56:27.443: gtdInstance = 0
*Sep 24 23:56:27.443: gtdBitMap = 0xFFFFFFFF
*Sep 24 23:56:27.443: ccGTDExtractParm: TunnelledContent has GTD message
*Sep 24 23:56:27.443: gtd msg = "IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,c29e257024ab11e383897cad74cf36d0"
*Sep 24 23:56:27.443: ccGTDExtractParm: GTD Parm CPC obtained
*Sep 24 23:56:27.443: ccGTDExtractParm: GTD Parm TMR obtained
*Sep 24 23:56:27.443: ccGTDExtractParm: GTD Parm PRN obtained
*Sep 24 23:56:27.443: ccMapGCItoGUID: GTD Parm GCI present: c29e257024ab11e383897cad74cf36d0
*Sep 24 23:56:27.447: Have gtd msg, length=227:*Sep 24 23:56:27.447: gtd msg = "IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,c29e257024ab11e383897cad74cf36d0"
*Sep 24 23:56:27.451: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xBC0B
Channel ID i = 0xA98381
Exclusive, Channel 1
*Sep 24 23:56:27.451: ISDN Se0/0/0:15 Q931: TX -> CONNECT pd = 8 callref = 0xBC0B
Connected Number i = 0x80, '5817001'
*Sep 24 23:56:27.471: ISDN Se0/0/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x3C0B
*Sep 24 23:56:28.135: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0xBC0B Cause i = 0x8090 - Normal call clearing
*Sep 24 23:56:28.143: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x3C0B
*Sep 24 23:56:28.143: ISDN Se0/0/0:15: Built a GTD of size 27 octets for ISDN message type 0x5A
GWINB01#
*Sep 24 23:56:28.143: tsp_ccrawmsg_encap: calling cdapi_find_tsm
*Sep 24 23:56:28.143: cdapi_find_tsm: Found Tunnelled Signaling Msg with GTD: PROT_PTYPE_GTD
*Sep 24 23:56:28.143: cdapi_find_tsm: Found a gtd msg of length 27:
*Sep 24 23:56:28.143: gtd msg = "RLC,PRN,isdn*,,QSIG*,"
*Sep 24 23:56:28.143: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xBC0B
Subject: RE: Error while accessing UUI
Replied by: Paul Tindall on 25-09-2013 07:04:29 AM
It does look very much like reading UUS from VoiceXML has a problem with lowercase hex. Try the attached custom element just to check that it gives the same behaviour. If so, we could try a workaround by handing-off to TCL to retrieve the GTD.
Subject: RE: Error while accessing UUI
Replied by: Vladimir Lozano Martinez on 25-09-2013 05:09:53 PM
Hi Paul,
The result is the same. Here are som debugs:
<form id="start">
<var name="gtd" expr="com.cisco.signal.gtdlist['setup_indication']" />
<var name="gtdval" expr="gtd.UUS[0].dat" />
<block>
<submit next="/CVP/Server" method="post" namelist="audium_vxmlLog gtdval" />
</block>
...............................................................................................................................................................
*Sep 25 21:42:56.142: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x3D1B
Sending Complete
Bearer Capability i = 0x9090A3
Standard = CCITT
Transfer Capability = 3.1kHz Audio
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s Channel ID i = 0xA18381 Preferred, Channel 1
Facility i = 0x9FAA068001008201008B0100A1180202FDBC020100800F454A4543555449564F2043414C4C43
Progress Ind i = 0x8183 - Origination address is non-ISDN
Calling Party Number i = 0x0080, '6043'
Plan:Unknown, Type:Unknown
Called Party Number i = 0xA1, '5817001'ç
Plan:ISDN, Type:National
User-User i = 0x04A0A0A0A0A0A0A0B5, '=', 0xC4A1C7, '.uC', 0xA0A0A0A0A0A0A0A0B1A200
Locking Shift to Codeset 4
Codeset 4 IE 0x31 i = 0x80
*Sep 25 21:42:56.142: ISDN Se0/0/0:15: Built a GTD of size 227 octets for ISDN message type 0x5
*Sep 25 21:42:56.142: tsp_ccrawmsg_encap: calling cdapi_find_tsm*Sep 25 21:42:56.142: cdapi_find_tsm: Found Tunnelled Signaling Msg with GTD: PROT_PTYPE_GTD
*Sep 25 21:42:56.142: cdapi_find_tsm: Found a gtd msg of length 227:
*Sep 25 21:42:56.142: gtd msg = "IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,45ececff256211e383a67cad74cf36d0"
*Sep 25 21:42:56.146: ccGTDExtractParm: Starting
*Sep 25 21:42:56.146: tunnelledPtype = 2
*Sep 25 21:42:56.146: gtdInstance = 0
*Sep 25 21:42:56.146: gtdBitMap = 0xFFFFFFFF
*Sep 25 21:42:56.146: ccGTDExtractParm: TunnelledContent has GTD message
*Sep 25 21:42:56.146: gtd msg = "IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,45ececff256211e383a67cad74cf36d0"
*Sep 25 21:42:56.146: ccGTDExtractParm: GTD Parm CPC obtained
*Sep 25 21:42:56.146: ccGTDExtractParm: GTD Parm TMR obtained
*Sep 25 21:42:56.146: ccGTDExtractParm: GTD Parm PRN obtained
*Sep 25 21:42:56.146: ccMapGCItoGUID: GTD Parm GCI present: 45ececff256211e383a67cad74cf36d0*Sep 25 21:42:56.146: Have gtd msg, length=227:
*Sep 25 21:42:56.146: gtd msg = "IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,GCI,45ececff256211e383a67cad74cf36d0"
*Sep 25 21:42:56.162: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xBD1B
Channel ID i = 0xA98381 Exclusive, Channel 1
*Sep 25 21:42:56.162: ISDN Se0/0/0:15 Q931: TX -> CONNECT pd = 8 callref = 0xBD1B Connected Number i = 0x80, '5817001'
*Sep 25 21:42:56.166: //2976/45ECECFF83A6/VXML:/vxml_jse_add_gtd_obj_to_list: Sig-event name = setup_indication, gtd-len = 227, gtd-buf = IAM,
PRN,isdn*,,QSIG*,
USI,rate,c,3,c,1
USI,lay1,alaw
TMR,02
CPN,04,,1,5817001
CGN,00,,u,y,1,6043
UUS,3,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
CPC,09
FCI,,,,,,,y,
GCI,45ececff256211e383a67cad74cf36d0
*Sep 25 21:42:56.166: //2976/45ECECFF83A6/VXML:/vxml_jse_add_gtd_obj_to_list:
gtd_obj for sig-event [setup_indication] added to session/shadow var array [0x404546F0]
*Sep 25 21:42:56.166: //2976/45ECECFF83A6/VXML:/vxml_create_gtd_sess_vars:
Created object chain for com.cisco.signal.gtdlist
*Sep 25 21:42:56.186: ISDN Se0/0/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x3D1B
*Sep 25 21:42:56.234: ISDN Se0/0/0:15 Q931: RX <- FACILITY pd = 8 callref = 0x3D1B Facility i = 0x9FAA068001008201008B0100A1180202FDBD02010C30800A0101810080067072756562610000
*Sep 25 21:42:56.234: ISDN Se0/0/0:15: Built a GTD of size 27 octets for ISDN message type 0x62
*Sep 25 21:42:56.234: tsp_ccrawmsg_encap: calling cdapi_find_tsm
*Sep 25 21:42:56.234: cdapi_find_tsm: Found Tunnelled Signaling Msg with GTD: PROT_PTYPE_GTD
*Sep 25 21:42:56.234: cdapi_find_tsm: Found a gtd msg of length 27:
*Sep 25 21:42:56.234: gtd msg = "FAC,PRN,isdn*,,QSIG*,"
*Sep 25 21:42:56.514: //2976/45ECECFF83A6/VXML:/vxml_gtd_get_callback:
Param name , param-id [117]
*Sep 25 21:42:56.514: //2976/45ECECFF83A6/VXML:/vxml_gtd_parm_get_callback:
Property is an instance number [0]. Param name
*Sep 25 21:42:56.514: //2976/45ECECFF83A6/VXML:/vxml_get_gtd_parm_field:
GWINB01#
Reading GTD param success. param , parm-id [117] field , inst [1], value = a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200
*Sep 25 21:42:56.514: //-1//VXML:/vxml_hexadecimal_to_ascii:
ERROR: Invalid hex char [0x61]
*Sep 25 21:42:56.530: //2976/45ECECFF83A6/VXML:/vxml_disconnect_proc: GTD not present in <disconnect>
GWINB01#
*Sep 25 21:43:05.030: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0xBD1B
Cause i = 0x80BF - Service/option not available, unspecified
*Sep 25 21:43:05.050: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x3D1B
*Sep 25 21:43:05.050: ISDN Se0/0/0:15: Built a GTD of size 27 octets for ISDN message type 0x5A
*Sep 25 21:43:05.050: tsp_ccrawmsg_encap: calling cdapi_find_tsm
*Sep 25 21:43:05.050: cdapi_find_tsm: Found Tunnelled Signaling Msg with GTD: PROT_PTYPE_GTD
*Sep 25 21:43:05.050: cdapi_find_tsm: Found a gtd msg of length 27:*Sep 25 21:43:05.050: gtd msg = "RLC,PRN,isdn*,,QSIG*,"
GWINB01#
*Sep 25 21:43:05.054: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xBD1B
GWINB01#
GWINB01#
GWINB01#
*Sep 25 21:46:37.686: ISDN Se0/0/0:15 Q931: RX <- STATUS_ENQ pd = 8 callref = 0x3E42
*Sep 25 21:46:37.686: ISDN Se0/0/0:15 **ERROR**: L3_BadPeerMsg: event 0x75 cr 0xBE42 callid 0x0
*Sep 25 21:46:37.686: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xBE42 Cause i = 0x80D1 - Invalid call reference value
Greetings
Subject: RE: Error while accessing UUI
Replied by: Paul Tindall on 26-09-2013 09:23:29 AM
Vladimir,
I think we should assume you've hit a possible defect here and the workaround I'd suggest to try is handing-off to TCL to retrieve the GTD UUS content. If you need help to do that I can send you something to try but it's unlikely to be today.
One more thing to try -- just as a test, can you get the sending end to simply send a user-user data string that only translates to numeric hex digits? Second thing could be to try only including standard ascii 7 bit characters in the source data so the hex values are less than 0x80.
Paul
Subject: RE: Error while accessing UUI
Replied by: Vladimir Lozano Martinez on 26-09-2013 12:41:55 PM
Hi Paul,
I don't have any experience working with handoff, I'll apreciate any help. Meanwhile I will be reviewing what can I do from the sending side.
Greetings.
Subject: RE: Error while accessing UUI
Replied by: Paul Tindall on 03-10-2013 10:28:04 PM
Vladimir,
Unfortunately the approach of handing-off to TCL doesn't work as the GTD setup object isn't accessible when processing a handoff event. The only alternative I can suggest is to modify the boostrap code and pass UUI up to the CVP application when it's invoked. The downside of that approach is that you'd have to deploy a customised CVPSelfService.tcl application (assuming this is standalone model).
Paul
Subject: RE: Error while accessing UUI
Replied by: Vladimir Lozano Martinez on 07-10-2013 12:45:18 PM
Hi Paul,
Actually this is a Standalone model. I run some additional test regarding to send UUI in binary and Ascii, and the behaivor is the same. The UUI is arriving in the same format:
| PRN,isdn*,,QSIG*, USI,rate,c,3,c,1 USI,lay1,alaw TMR,02 CPN,04,,1,5817001 CGN,00,,u,y,1,6043 UUS,1,a0a0a0a0a0a0a0b53dc4a1c72e7543a0a0a0a0a0a0a0a0b1a200 CPC,09 FCI,,,,,,,y,GCI,45ececff256211e383a67cad74cf36d0" Greetings! |
Subject: RE: Error while accessing UUI
Replied by: Paul Tindall on 07-10-2013 02:04:35 PM
In this example the UUI still has characters greater than 7f hex, for example, the string of a0's at the beginning. As a test, can you send some UUI that maybe just has IA5 content, perhaps, the hex translation of "12345" or similar that would have only 7 bit characters? It may not be the issue but I can see from your original traces that the hex translation failed on the first digit being 'a' (non-IA5) as not a valid hex value. It's the first time I've seen any problems with UUI but I've never sent non-IA5 content.
Labels:
Getting Started
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
Customers Also Viewed These Support Documents