Good morning community, I need your support.

I can not detect the user data field in the XML event envelope of the event I receive from my AES version 6.2, using the XML services that it exposes.

Is it a version issue or a configuration issue? As I write, I'm thinking if it may be a Private Data Version problem that my application negotiates at the time of the session with the AES: I'm using PDV 6.

This is an example of an event I receive, where I do not see the USER DATA node, I would imagine to find within the PRIVATE DATA node, being sure that the sender has correctly inserted and sent some data into the UUI of the ISDN signaling:


<EstablishedEvent
xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<monitorCrossRefID>73</monitorCrossRefID>
<establishedConnection>
<callID>12146</callID>
<deviceID typeOfNumber="other" mediaClass="notKnown" bitRate="constant">4002:CMCT::0</deviceID>
</establishedConnection>
<answeringDevice>
<deviceIdentifier typeOfNumber="other" mediaClass="notKnown" bitRate="constant">4002:CMCT:172.31.200.143:0</deviceIdentifier>
</answeringDevice>
<callingDevice>
<deviceIdentifier typeOfNumber="explicitPublic:national" mediaClass="notKnown" bitRate="constant">957129001:CMCT::0</deviceIdentifier>
</callingDevice>
<calledDevice>
<deviceIdentifier typeOfNumber="explicitPublic:national" mediaClass="notKnown" bitRate="constant">95724331:CMCT::0</deviceIdentifier>
</calledDevice>
<lastRedirectionDevice>
<notKnown/>
</lastRedirectionDevice>
<localConnectionInfo>connected</localConnectionInfo>
<cause>newCall</cause>
<networkCallingDevice>
<notKnown/>
</networkCallingDevice>
<networkCalledDevice>
<notKnown/>
</networkCalledDevice>
<callLinkageData>
<globalCallData>
<globalCallLinkageID>
<globallyUniqueCallLinkageID>00001121461497274430</globallyUniqueCallLinkageID>
</globalCallLinkageID>
</globalCallData>
</callLinkageData>
<extensions>
<privateData>
<private>
<ns1:EstablishedEventPrivateData
xmlns:ns1="http://www.avaya.com/csta"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns1:EstablishedEventPrivateData">
<ns1:trunkGroup>1</ns1:trunkGroup>
<ns1:trunkMember>3</ns1:trunkMember>
<ns1:reason>none</ns1:reason>
<ns1:distributingDevice>
<notKnown/>
</ns1:distributingDevice>
<ns1:distributingVDN>
<notKnown/>
</ns1:distributingVDN>
<ns1:originalCallInfo>
<ns1:reason>0</ns1:reason>
<ns1:callLinkageData>
<globalCallData>
<globalCallLinkageID>
<globallyUniqueCallLinkageID>00000000000000000000</globallyUniqueCallLinkageID>
</globalCallLinkageID>
</globalCallData>
</ns1:callLinkageData>
</ns1:originalCallInfo>
</ns1:EstablishedEventPrivateData>
</private>
</privateData>
</extensions>
</EstablishedEvent>


Thanks for your attention.

Matteo.

UserData is available using PDV 6 so that should not be the cause of your problem. The fact that there is no userData field in the XML would seem to imply that Communication Manager has not send any to AE Services.

The first thing you should do is to check that UUI is actually included in the call. I think the easiest way to do that is to to add a uui-info button to the receiving station's configuration. During the call, press this button and the UUI will be shown on the phone's display.

Martin

Hi Martin,
I want to add that my colleague has already debugged on CM, highlighting in yellow in the following log that CM correctly receives UUI from ISDN signalling.

Waiting that I can configure the uui-info button on the station, there is some setting or other check that I could do on the CM and/or AES?

11 16:52:50.047 60 4001180f ==> SETUP crv 0_0019
D-channel port number: 4001180f
Protocol Discriminator: 08 call control
Call Reference Value: 02 00 19 Origination 0019
Q.931 Message Type: 05 Setup
=> SENDING COMPLETE (a1)
=> BEARER CAPABILITY 90 90 a3 3.1 kHz audio, 64 kbps, A-law
| coding standard: CCITT
| transfer mode: circuit-mode
| layer 1 indent: layer 1
=> CHANNEL IDENT a1 83 9d B-ch num 29, pref
=> PROGRESS IND 80 83 user, ORIGination is non-ISDN
=> CALLING PARTY NUMBER .................................. 957129001
| type of number: national
| numbering plan: ISDN/telphny plan E.164/3 |cv ISDN/telphny pln
| presentation ind: presentation allowed
| screening: network provided
=> CALLED PARTY NUMBER .................................... 95724331
| type of number: national
| numbering plan: ISDN/telphny plan E.164/3 |cv ISDN/telphny pln
=> USER-USER user-specific protocol, 13 bytes
| 00 fe 5f 09 22 42 34 39 53 67 88 75 f6

12 16:52:50.048 62 4001180f <-- CALL_PROC crv 1_0019
D-channel port number: 4001180f
Protocol Discriminator: 08 call control
Call Reference Value: 02 80 19 Destination 0019
Q.931 Message Type: 02 Call Proceeding
<- CHANNEL IDENT a9 83 9d B-ch num 29, excl

As you are able to collect MST, I suggest that you enable ASAI tracing when configuring "change mst", it is on page 1.

ASAI is the protocol that Communication Manager uses to send events to AE Services. Make sure that Communication Manager is sending the UUI to AE Services. It should be in an Alerting event.

Alternatively, you should be able to see the events in the TSAPI traces on AE Services. There are instructions in the Devconnect Product FAQ "What is the procedure for enabling and accessing the AE Services logs for TSAPI (trace, tracing, g3trace, csta_trace)?". It is in the "FAQ: AE Services TSAPI -> General" section. Check there is an Alerting event in the g3 file and that it includes userData.

Martin

Please also let us know that the 'ASAI Link Version' is set to in AE Services web OA&M -> AE Services -> TSAPI Links

Hi John,
I have verified that AES is using ASAI Link Version 5.

That is what is working in my lab. Verifying that UserData (UUI) is arriving at AES from CM by one of the methodologies that Martin outlined is the next step.

Good morning,
I enabled the TSAPI tracing on the AES server and extracted the following ASAI message from the g3trace log, where UUI information appears to be missing, although received from the CM in ISDN reporting.

If my log reading is correct, what can I further investigate?


06/13/2017 16:26:01.135:TSAPI:LinkThread01: Received ASAI Message ConnectList
06/13/2017 16:26:01.135:TSAPI:LinkThread01: cap,prim,sao_id C_EN_REP,C_REQUEST,422
06/13/2017 16:26:01.135:TSAPI:LinkThread01: event_name C_CONNECTED
06/13/2017 16:26:01.135:TSAPI:LinkThread01: callID 1293
06/13/2017 16:26:01.135:TSAPI:LinkThread01: callingDev,Party 957129001,1
06/13/2017 16:26:01.135:TSAPI:LinkThread01: callingFlags 0x50000
06/13/2017 16:26:01.135:TSAPI:LinkThread01: callingState 0x10
06/13/2017 16:26:01.135:TSAPI:LinkThread01: affectdDev,Party 4002,3
06/13/2017 16:26:01.135:TSAPI:LinkThread01: affectedFlags 0x60000
06/13/2017 16:26:01.135:TSAPI:LinkThread01: affectedState 0x10
06/13/2017 16:26:01.135:TSAPI:LinkThread01: party_id 3
06/13/2017 16:26:01.135:TSAPI:LinkThread01: cause_value CS0/16
06/13/2017 16:26:01.135:TSAPI:LinkThread01: called_num 95724331
06/13/2017 16:26:01.135:TSAPI:LinkThread01: calling_num 957129001
06/13/2017 16:26:01.135:TSAPI:LinkThread01: connect_num 4002
06/13/2017 16:26:01.135:TSAPI:LinkThread01: called_type[addr_type,numb_plan] 2,1
06/13/2017 16:26:01.135:TSAPI:LinkThread01: calling_type[addr_type,numb_plan] 2,1
06/13/2017 16:26:01.135:TSAPI:LinkThread01: con_type[addr_type,numb_plan] 7,15
06/13/2017 16:26:01.135:TSAPI:LinkThread01: trk[id,gid,direct] 10,1,0x0
06/13/2017 16:26:01.135:TSAPI:LinkThread01: oli: hasInfo?(F)value(0)
06/13/2017 16:26:01.135:TSAPI:LinkThread01: ucid: 8 byte dump of 8 bytes of data:
06/13/2017 16:26:01.135:TSAPI:LinkThread01: ucid: hex '0001050d 593ff5f0'
06/13/2017 16:26:01.135:TSAPI:LinkThread01: ucid: std format: '00001012931497363952'
06/13/2017 16:26:01.135:TSAPI:LinkThread01: redir_num (null)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: Sent CSTA Msg (CSTAUNSOLICITED)(4) (CSTA_ESTABLISHED)(59)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: msgoff(24)msglen(368)privoff(392)privlen(253)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: invokeID(2989)monXref(75)sessionID(2)clsOfServ(0)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: establishedConnection.callID(1293) .devID(4002) .devIDType(STATIC)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: answeringDevice.device(4002) (EXPLICIT_PRIVATE_LOCAL_NUMBER)(55) (ID_PROVIDED)(0)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: localConnectionInfo(CS_CONNECT)(3)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: cause(EC_NEW_CALL)(22)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: callingDevice.device(957129001) (EXPLICIT_PUBLIC_NATIONAL)(32) (ID_PROVIDED)(0)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: calledDevice.device(95724331) (EXPLICIT_PUBLIC_NATIONAL)(32) (ID_PROVIDED)(0)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: lastRedirectionDevice.device() (EXPLICIT_PUBLIC_UNKNOWN)(30) (ID_NOT_REQUIRED)(2)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: eventType(ATT_ESTABLISHED)(129)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: trunkGroup(1)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: trunkMember(10)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: split()
06/13/2017 16:26:01.137:TSAPI:LinkThread01: userInfotype(UUI_NONE)(-1)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: .length(0)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: lookaheadInfohours(0) minutes(0) seconds(0)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: sourceVDN()
06/13/2017 16:26:01.137:TSAPI:LinkThread01: type(LAI_NO_INTERFLOW)(-1)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: priority(LAI_NOT_IN_QUEUE)(0)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: 0 wchar_t(s) [unsigned short(s)] in hex:
06/13/2017 16:26:01.137:TSAPI:LinkThread01: userEnteredCodedata()
06/13/2017 16:26:01.137:TSAPI:LinkThread01: collectVDN()
06/13/2017 16:26:01.137:TSAPI:LinkThread01: type(UE_NONE)(-1)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: indicator(UE_COLLECT)(0)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: reason(AR_NONE)(0)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: distributingDevice.device() (EXPLICIT_PUBLIC_UNKNOWN)(30) (ID_NOT_KNOWN)(1)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: distributingVDN.device() (EXPLICIT_PUBLIC_UNKNOWN)(30) (ID_NOT_KNOWN)(1)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: UCID(00001012931497363952)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: hasInfo(F)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: callOriginatorType(0)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: flexBilling(F)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: DeviceHistory: count(0)
06/13/2017 16:26:01.137:TSAPI:LinkThread01: ** originalCallInfo (OCI) Begins **
06/13/2017 16:26:01.137:TSAPI:LinkThread01: trunkGroup()
06/13/2017 16:26:01.137:TSAPI:LinkThread01: trunkMember()
06/13/2017 16:26:01.137:TSAPI:LinkThread01: callingDevice.device() (EXPLICIT_PUBLIC_UNKNOWN)(30) (ID_NOT_REQUIRED)(2)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: calledDevice.device() (EXPLICIT_PUBLIC_UNKNOWN)(30) (ID_NOT_REQUIRED)(2)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: userInfotype(UUI_NONE)(-1)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: .length(0)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: reason(OR_NONE)(0)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: lookaheadInfohours(0) minutes(0) seconds(0)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: sourceVDN()
06/13/2017 16:26:01.138:TSAPI:LinkThread01: type(LAI_NO_INTERFLOW)(-1)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: priority(LAI_NOT_IN_QUEUE)(0)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: 0 wchar_t(s) [unsigned short(s)] in hex:
06/13/2017 16:26:01.138:TSAPI:LinkThread01: userEnteredCodedata()
06/13/2017 16:26:01.138:TSAPI:LinkThread01: collectVDN()
06/13/2017 16:26:01.138:TSAPI:LinkThread01: type(UE_NONE)(-1)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: indicator(UE_COLLECT)(0)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: UCID(00000000000000000000)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: hasInfo(F)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: callOriginatorType(0)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: flexBilling(F)
06/13/2017 16:26:01.138:TSAPI:LinkThread01: OCI DeviceHistory: count(0)
06/13/2017 16:26:01.139:TSAPI:LinkThread01: Sent CSTA Msg (CSTAUNSOLICITED)(4) (CSTA_ESTABLISHED)(59)
06/13/2017 16:26:01.139:TSAPI:LinkThread01: msgoff(24)msglen(368)privoff(392)privlen(253)
06/13/2017 16:26:01.139:TSAPI:LinkThread01: invokeID(2989)monXref(84)sessionID(2)clsOfServ(0)
06/13/2017 16:26:01.139:TSAPI:LinkThread01: establishedConnection.callID(1293) .devID(4002) .devIDType(STATIC)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: answeringDevice.device(4002) (EXPLICIT_PRIVATE_LOCAL_NUMBER)(55) (ID_PROVIDED)(0)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: localConnectionInfo(CS_CONNECT)(3)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: cause(EC_NEW_CALL)(22)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: callingDevice.device(957129001) (EXPLICIT_PUBLIC_NATIONAL)(32) (ID_PROVIDED)(0)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: calledDevice.device(95724331) (EXPLICIT_PUBLIC_NATIONAL)(32) (ID_PROVIDED)(0)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: lastRedirectionDevice.device() (EXPLICIT_PUBLIC_UNKNOWN)(30) (ID_NOT_REQUIRED)(2)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: eventType(ATT_ESTABLISHED)(129)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: trunkGroup(1)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: trunkMember(10)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: split()
06/13/2017 16:26:01.141:TSAPI:LinkThread01: userInfotype(UUI_NONE)(-1)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: .length(0)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: lookaheadInfohours(0) minutes(0) seconds(0)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: sourceVDN()
06/13/2017 16:26:01.141:TSAPI:LinkThread01: type(LAI_NO_INTERFLOW)(-1)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: priority(LAI_NOT_IN_QUEUE)(0)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: 0 wchar_t(s) [unsigned short(s)] in hex:
06/13/2017 16:26:01.141:TSAPI:LinkThread01: userEnteredCodedata()
06/13/2017 16:26:01.141:TSAPI:LinkThread01: collectVDN()
06/13/2017 16:26:01.141:TSAPI:LinkThread01: type(UE_NONE)(-1)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: indicator(UE_COLLECT)(0)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: reason(AR_NONE)(0)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: distributingDevice.device() (EXPLICIT_PUBLIC_UNKNOWN)(30) (ID_NOT_KNOWN)(1)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: distributingVDN.device() (EXPLICIT_PUBLIC_UNKNOWN)(30) (ID_NOT_KNOWN)(1)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: UCID(00001012931497363952)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: hasInfo(F)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: callOriginatorType(0)
06/13/2017 16:26:01.141:TSAPI:LinkThread01: flexBilling(F)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: DeviceHistory: count(0)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: ** originalCallInfo (OCI) Begins **
06/13/2017 16:26:01.142:TSAPI:LinkThread01: trunkGroup()
06/13/2017 16:26:01.142:TSAPI:LinkThread01: trunkMember()
06/13/2017 16:26:01.142:TSAPI:LinkThread01: callingDevice.device() (EXPLICIT_PUBLIC_UNKNOWN)(30) (ID_NOT_REQUIRED)(2)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: calledDevice.device() (EXPLICIT_PUBLIC_UNKNOWN)(30) (ID_NOT_REQUIRED)(2)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: userInfotype(UUI_NONE)(-1)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: .length(0)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: reason(OR_NONE)(0)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: lookaheadInfohours(0) minutes(0) seconds(0)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: sourceVDN()
06/13/2017 16:26:01.142:TSAPI:LinkThread01: type(LAI_NO_INTERFLOW)(-1)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: priority(LAI_NOT_IN_QUEUE)(0)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: 0 wchar_t(s) [unsigned short(s)] in hex:
06/13/2017 16:26:01.142:TSAPI:LinkThread01: userEnteredCodedata()
06/13/2017 16:26:01.142:TSAPI:LinkThread01: collectVDN()
06/13/2017 16:26:01.142:TSAPI:LinkThread01: type(UE_NONE)(-1)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: indicator(UE_COLLECT)(0)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: UCID(00000000000000000000)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: hasInfo(F)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: callOriginatorType(0)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: flexBilling(F)
06/13/2017 16:26:01.142:TSAPI:LinkThread01: OCI DeviceHistory: count(0)

I also attach the new MST+ASAI tracing:


55 16:25:52.210 60 4001180f ==> SETUP crv 0_00ac
D-channel port number: 4001180f
Protocol Discriminator: 08 call control
Call Reference Value: 02 00 ac Origination 00ac
Q.931 Message Type: 05 Setup
=> SENDING COMPLETE (a1)
=> BEARER CAPABILITY 90 90 a3 3.1 kHz audio, 64 kbps, A-law
| coding standard: CCITT
| transfer mode: circuit-mode
| layer 1 indent: layer 1
=> CHANNEL IDENT a1 83 8a B-ch num 10, pref
=> PROGRESS IND 80 83 user, ORIGination is non-ISDN
=> CALLING PARTY NUMBER .................................. 957129001
| type of number: national
| numbering plan: ISDN/telphny plan E.164/3 |cv ISDN/telphny pln
| presentation ind: presentation allowed
| screening: network provided
=> CALLED PARTY NUMBER .................................... 95724331
| type of number: national
| numbering plan: ISDN/telphny plan E.164/3 |cv ISDN/telphny pln
=> USER-USER user-specific protocol, 13 bytes
| 00 fe 5f 09 38 42 34 39 43 96 82 28 f8

56 16:25:52.211 62 4001180f <-- CALL_PROC crv 1_00ac
D-channel port number: 4001180f
Protocol Discriminator: 08 call control
Call Reference Value: 02 80 ac Destination 00ac
Q.931 Message Type: 02 Call Proceeding
<- CHANNEL IDENT a9 83 8a B-ch num 10, excl
57 16:25:52.212 62 4001180f <-- ALERT crv 1_00ac
D-channel port number: 4001180f
Protocol Discriminator: 08 call control
Call Reference Value: 02 80 ac Destination 00ac
Q.931 Message Type: 01 Alerting
58 16:25:53.217 62 4001180f <-- CONN crv 1_00ac
D-channel port number: 4001180f
Protocol Discriminator: 08 call control
Call Reference Value: 02 80 ac Destination 00ac
Q.931 Message Type: 07 Connect
<- PROGRESS IND local pvt netwk |cv pub netwrk serv local usr, DESTination is non-ISDN
59 16:25:53.260 60 4001180f ==> CONN_ACK crv 0_00ac
D-channel port number: 4001180f
Protocol Discriminator: 08 call control
Call Reference Value: 02 00 ac Origination 00ac
Q.931 Message Type: 0f Connect Acknowledge
60 16:26:01.123 57 00000000 <-- DOMAIN crv 1_0091 <<!
ASAI association type: domain control
CTI Link number: 00000001
Protocol Discriminator: 08 call control
Call Reference Value: 02 80 91 Destination 0091
Q.931 Message Type: 62 Facility
><- LOCKING SHIFT TO CODESET 6
<- FACILITY invoke: event report
<- | CAUSE local pvt netwk |cv pvt netwk serv local usr:127. Intrwrkg unspecfd |cv Normal unspecfd
<- | CALL IDENTITY 05 0e x050e
<- | LOCKING SHIFT TO CODESET 6
<- | PARTY ID 81 1
<- | SPECIFIC EVENT 97 call forwrdng |cv call initiatd evnt
<- | UNIVERSAL CALL ID 00 01 05 0e 59 3f f5 f9 8 bytes
61 16:26:01.123 57 00000000 <-- DOMAIN crv 1_0091 <<!
ASAI association type: domain control
CTI Link number: 00000001
Protocol Discriminator: 08 call control
Call Reference Value: 02 80 91 Destination 0091
Q.931 Message Type: 62 Facility
><- LOCKING SHIFT TO CODESET 6
<- FACILITY invoke: event report
<- | CAUSE local pvt netwk |cv pvt netwk serv local usr:127. Intrwrkg unspecfd |cv Normal unspecfd
<- | CONNECTED NUMBER ........................................... 4002
| | type of number: reserved for exten
| | numbering plan: CM internal numbering plan
<- | CALL IDENTITY 05 0e x050e
<- | LOCKING SHIFT TO CODESET 6
<- | PARTY ID 81 1
<- | SPECIFIC EVENT 84 disconnected/dropped
62 16:26:01.123 57 00000000 <-- DOMAIN crv 1_0091
ASAI association type: domain control
CTI Link number: 00000001
Protocol Discriminator: 08 call control
Call Reference Value: 02 80 91 Destination 0091
Q.931 Message Type: 62 Facility
<- LOCKING SHIFT TO CODESET 6
<- FACILITY invoke: event report
<- | CAUSE local pvt netwk |cv pvt netwk serv local usr:16. Normal clearing
<- | CONNECTED NUMBER ........................................... 4002
| | type of number: reserved for exten
| | numbering plan: CM internal numbering plan
<- | CALL IDENTITY 05 0d x050d
<- | CALLING PARTY NUMBER .................................. 957129001
| | type of number: national
| | numbering plan: ISDN/telphny plan E.164/3 |cv ISDN/telphny pln
<- | CALLED PARTY NUMBER .................................... 95724331
| | type of number: national
| | numbering plan: ISDN/telphny plan E.164/3 |cv ISDN/telphny pln
<- | LOCKING SHIFT TO CODESET 6
<- | TRUNK IDENTIF 80 81 8a auditing SNC grp 1 trk 10
<- | PARTY ID 83 3
<- | SPECIFIC EVENT 8b connected (local answer detection)
<- | UNIVERSAL CALL ID 00 01 05 0d 59 3f f5 f0 8 bytes


=============================================================================
| count | IE0_... Codeset 0 Info Elem | 1st,last msgno | 1st,last times |
=============================================================================
2 BearCap Bearer Capability 23, 55 15:37:15-16:25:52
40 Cause Cause 1, 72 15:36:34-16:26:32
34 ConnNum Connected Number 1, 71 15:36:34-16:26:32
49 CallIdy Call Identity 1, 73 15:36:34-16:26:52
4 ChanId Channel Identification 23, 56 15:37:15-16:25:52
6 ProgInd Progress Indicator 23, 58 15:37:15-16:25:53
11 CngPNum Calling Party Number 8, 64 15:36:44-16:26:15
16 CedPNum Called Party Number 7, 73 15:36:44-16:26:52
1 UsrUsr User-to-User Information 55, 55 16:25:52-16:25:52

While TSAPI Established events are triggered from ASAI Connected events, the Connected event never contains UserData. AE Services fills in an Established event with the Userdate that it previously received in an ASAI Alerting event.

In your case, AE Services does not seem to have been sent an Alerting event for this call and therefore the Established event does not contain UserData.

There are a couple of other things that are different from your MTA to any I have checked:

1. Yours includes Progress Indications that say ORIGination is non-ISDN and DESTination is non-ISDN. If theer are non-ISDN type trunks (ie not ISDN, H.323 or SIP) then this would very much limit the information available to TSAPI.

2. In the MTAs that I have checked, the USER-USER sections are much bigger than yours and are included in all the ISDN trace. USER-USER includes more than just UUI so I am surprised that yours is so small.

So I think your problem is maybe due to your setup or configuration.

John may know more about this but I do not think I can help your any further.

Martin

Can you explain your call flow as represented by these messages in excruciating detail please. How is the call originated, on what type of device, what is the intervening networking trunk types if any, what type of device is 95724331 and 4002?

Where is the TSAPI monitor (4002)??

It looks like A 957129001 calls B 95724331 and something redirects it to 4002 where it is auto answered. There are very few ASAI events for the call. You may need a TSAPI monitor on the device represented by 95724331 so that AES gets the user info.

Also what release of CM are you using? I recall a prior problem where in a use case where alerting is not sent to AES, UUI information was not available with the call. You may try disabling auto answer on 4002 (assuming that is the case here).

Also please open a support ticket through the devconnect portal, that way you can send full traces of the call and not what appear to be partial traces.

Good morning Martin, Good morning John, sorry if I answer you late, but we are preparing the go-live of a new emergency system and I have to leave the problem.

I have not directly configured our system (which in this case is the called system AVAYA AURA 6.2), but I know you and I describe the flow that follows an incoming call.

The number 957129001 is the PSTN number (GNR of ISDN PRA) of the calling system AVAYA AURA 7.x

The number 95724331 is the PSTN number (GNR of ISDN PRA) of the called system AVAYA AURA 6.2, forwarded to an IVR and, after the welcome message, to an internal ring-all queue with extension 4018.

The number 4002 is one of the extensions that is part of that queue.

The CM version I have detected from its web interface is R016x.02.0.823.0

Thank you always for your attention.

What do you mean by "ring-all queue"? How is this configured?

Martin

I too would like to know what a ring-all-queue means to you. I have some ideas but I want you to describe it in terms of how it is configured in communication manager.

As a suggestion have the inbound call to 957129001 come into Communication Manager, and terminate on a VDN, have that VDN send it on to the IVR. Put a monitor calls via device on the VDN (using the DMCC Dashboard or TSAPI exerciser, whichever you are familiar with). Verify the UUI information is present as the call reaches this inbound VDN. Have the call from the IVR to extension 4018 go to a VDN as well (you will probably have to make some routing change as the call comes back to Communication Manager using the "change inc-call-handling trunk [trunk group #] have that call then route-to extension 4018 and do its thing to reach x4002. Put a monitor calls via device on this second VDN. Verify UUI information is present (my guess is that it isn't). Troubleshoot the trunking to the IVR, and the behavior of the IVR if my guesses are correct.

Hi John,
I found the project deliverables that describes the flow of the incoming call on our AVAYA AURA 6.2 system , which I tried to explain in my own words before.

The 118 is the public emergency health number in Italy , which in Catania (Sicily) is mapped over PSTN ISDN number 95724331.


The our Avaya system is configured with the following "Queue Service 118":

118 --> VDN 4038 (VECTOR 118) --> QUEUE 118 (HG 118 – 4048) --> 4028 (extension queue TEAM)

The above extension queue TEAM, if I understood the project documentation, is defined as follows:
INTERNAL 4001 + TEAM 4028
INTERNAL 4002 + TEAM 4028
INTERNAL 4003 + TEAM 4028
INTERNAL 4004 + TEAM 4028
INTERNAL 4005 + TEAM 4028
INTERNAL 4006 + TEAM 4028
INTERNAL 4007 + TEAM 4028
INTERNAL 4008 + TEAM 4028
INTERNAL 4009 + TEAM 4028


Now, if I try to monitor the VDN 4038 through the dashboard (using the specific call control monitor tab "Established" + "Deliver" + ...), I get the error <invalidDeviceID>: what could be your problem?


-----------------------
Incoming XML 2
<?xml version="1.0" encoding="UTF-8"?>
<GetDeviceIdResponse xmlns="http://www.avaya.com/csta">
<device typeOfNumber="other" mediaClass="voice" bitRate="constant">4038:CMCT:172.31.200.143:0</device>
</GetDeviceIdResponse>

-----------------------
Incoming XML 3
<?xml version="1.0" encoding="UTF-8"?>
<GetPhysicalDeviceNameResponse xmlns="http://www.avaya.com/csta">
<deviceType>vdn</deviceType>
<device>4038</device>
<name>118_IN</name>
</GetPhysicalDeviceNameResponse>

-----------------------
Incoming XML 4 4038:CMCT:172.31.200.143:0
<?xml version="1.0" encoding="UTF-8"?>
<CSTAErrorCode xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<operation>invalidDeviceID</operation>
</CSTAErrorCode>