it would be helpful to see your outbound requests as well.

My guess is you used a MonitorDevice request. VDNs require the use of MonitorCallsViaDevice.

I realized something wrong but do not know how to monitor the VDN with the dashboard.

take a look at the attachment

Thank you John for the precious information.

From the following log, I seem to understand that the user data is lost in the established event of the station. What could be wrong configured in the CM or AES?

Start Monitor Response (Third Party Call Control):12 Device ID:4038:CMCT:172.31.200.143:0 Monitor ID:176
Delivered Event: 176
Connection Id:
Device Id: 4038:CMCT::0
Call Id:4010
Alerting Device Id: 4038:CMCT:172.31.200.143:0
Calling Device Id: 957129001:CMCT::0
Called Device Id: 95724331:CMCT::0
Last Redirection Device Id: 95724331:CMCT::0
Local Connection Info:null
Event Cause: newCall
User Data as String: EFBFBD5F097100303902EFBFBD4428EFBFBD
User Data as Text: �_ q
-------- Device History Start
-------- Device History End
-------- Original Call Information Start
Reason:0
Trunk Group:
Trunk Member:
User Data:
Network Called Device:
Network Calling Device:
Device Id:0
Globally Unique Call Linkage Id: 00000000000000000000

-------- Look Ahead Information Start
InterFlow Priority: Undefined
Interflow Type: Undefined
Source Vdn:
Hours:
Minutes:
Seconds:
-------- Look Ahead Information End
-------- Device History Start
-------- Device History End
-------- User Entered Code Start
Collect VDN:
Data:
User Entered Code Type: Undefined
User Entered Code Indicator: Undefined
-------- User Entered Code End
-------- Original Call Information End
Delivered Event: 176
Connection Id:
Device Id: 4028:CMCT::0
Call Id:4010
Alerting Device Id: 4028:CMCT::0
Calling Device Id: 957129001:CMCT::0
Called Device Id: 95724331:CMCT::0
Last Redirection Device Id: 95724331:CMCT::0
Local Connection Info:null
Event Cause: redirected
User Data as String: EFBFBD5F097100303902EFBFBD4428EFBFBD
User Data as Text: �_ q
-------- Device History Start
-------- Device History End
-------- Original Call Information Start
Reason:0
Trunk Group:
Trunk Member:
User Data:
Network Called Device:
Network Calling Device:
Device Id:0
Globally Unique Call Linkage Id: 00000000000000000000

-------- Look Ahead Information Start
InterFlow Priority: Undefined
Interflow Type: Undefined
Source Vdn:
Hours:
Minutes:
Seconds:
-------- Look Ahead Information End
-------- Device History Start
-------- Device History End
-------- User Entered Code Start
Collect VDN:
Data:
User Entered Code Type: Undefined
User Entered Code Indicator: Undefined
-------- User Entered Code End
-------- Original Call Information End
Established Event: 176
Connection Id: Device Id: 4003:CMCT::0 Call Id:4010
Alerting Device Id: 4003:CMCT::0
Calling Device Id: 957129001:CMCT::0
Called Device Id: 95724331:CMCT::0
Last Redirection Device Id:
Local Connection Info: null
Globally Unique Call Linkage ID: 00001040101498066488
Event Cause: newCall
ACD Group: 4048:CMCT::0
-------- Original Call Information Start
Reason:0
Trunk Group:
Trunk Member:
User Data:
Network Called Device:
Network Calling Device:
Device Id:0
Globally Unique Call Linkage Id: 00000000000000000000

-------- Look Ahead Information Start
InterFlow Priority: Undefined
Interflow Type: Undefined
Source Vdn:
Hours:
Minutes:
Seconds:
-------- Look Ahead Information End
-------- Device History Start
-------- Device History End
-------- User Entered Code Start
Collect VDN:
Data:
User Entered Code Type: Undefined
User Entered Code Indicator: Undefined
-------- User Entered Code End
-------- Original Call Information End

The format of the information you provided is not familiar. Can you elablrate on how you collected it please.

Can you provide
1) screen shots of the vdn SAT form
2) screen shots of the related vector SAT form
3) somewhere in that vector there is probably a route to step with an extension.
4) I need the SAT forms that represents the type of device and full configuration for that extension.

I fear you are using the TEAM feature for your service. TEAM is not supported by Avaya CTI, and while I don't understand why that would impact UUI, I fear it is.

I suggest modifying the route-to step to direct the call to a specific station 4003, and observe the CTI eventing and see if that change impacts the receipt of UserData at the station.

Communication Manager and AE Services are setup to exchange UUI (UserData) as evidenced by its presence in the event from the VDN.

With the monitor on the VDN active, check if you are now getting UUI on the station monitor. Also, check if the Call ID of the events for the VDN is the same as the Call ID for the call to the monitored station.

Hi everyone, I have not yet made the screenshots that John asked, but I ran the two types of monitors suggested by Martin: (VDN + STATION) and (ONLY STATION)

In the first case I get the (USER DATA) but in the second case no. Is this a configuration problem or is it normal behavior?

CASE 1: VDN+ STATION
-----------------------
Incoming XML 9999
<?xml version="1.0" encoding="UTF-8"?>
<EstablishedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<monitorCrossRefID>193</monitorCrossRefID> (MY COMMENT: VDN)
<establishedConnection>
<callID>8179</callID>
<deviceID typeOfNumber="other" mediaClass="notKnown" bitRate="constant">4001:CMCT::0</deviceID>
</establishedConnection>
<answeringDevice>
<deviceIdentifier typeOfNumber="explicitPrivate:localNumber" mediaClass="notKnown" bitRate="constant">4001:CMCT::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>
<numberDialed typeOfNumber="explicitPrivate:localNumber" mediaClass="notKnown" bitRate="constant">4028:CMCT::0</numberDialed>
</lastRedirectionDevice>
<localConnectionInfo>null</localConnectionInfo>
<userData>
<string>EFBFBD5F095200303933491069EFBFBD</string>
</userData>
<cause>newCall</cause>
<networkCallingDevice>
<notKnown />
</networkCallingDevice>
<networkCalledDevice>
<notKnown />
</networkCalledDevice>
<callLinkageData>
<globalCallData>
<globalCallLinkageID>
<globallyUniqueCallLinkageID>00001081791498150707</globallyUniqueCallLinkageID>
</globalCallLinkageID>
</globalCallData>
</callLinkageData>
<extensions>
<privateData>
<private>
<EstablishedEventPrivateData xmlns:ns1="http://www.avaya.com/csta" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="EstablishedEventPrivateData">
<trunkGroup>1</trunkGroup>
<trunkMember>25</trunkMember>
<acdGroup typeOfNumber="other" mediaClass="notKnown" bitRate="constant">4048:CMCT::0</acdGroup>
<reason>none</reason>
<distributingDevice>
<deviceIdentifier typeOfNumber="explicitPublic:national" mediaClass="notKnown" bitRate="constant">95724331:CMCT::0</deviceIdentifier>
</distributingDevice>
<distributingVDN>
<deviceIdentifier typeOfNumber="other" mediaClass="notKnown" bitRate="constant">4038:CMCT:172.31.200.143:0</deviceIdentifier>
</distributingVDN>
<originalCallInfo>
<reason>0</reason>
<callLinkageData>
<globalCallData>
<globalCallLinkageID>
<globallyUniqueCallLinkageID>00000000000000000000</globallyUniqueCallLinkageID>
</globalCallLinkageID>
</globalCallData>
</callLinkageData>
</originalCallInfo>
</EstablishedEventPrivateData>
</private>
</privateData>
</extensions>
</EstablishedEvent>
-----------------------
Incoming XML 9999
<?xml version="1.0" encoding="UTF-8"?>
<EstablishedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<monitorCrossRefID>194</monitorCrossRefID> (MY COMMENT: STATION 4001)
<establishedConnection>
<callID>8179</callID>
<deviceID typeOfNumber="other" mediaClass="notKnown" bitRate="constant">4001:CMCT::0</deviceID>
</establishedConnection>
<answeringDevice>
<deviceIdentifier typeOfNumber="other" mediaClass="notKnown" bitRate="constant">4001: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>
<numberDialed typeOfNumber="explicitPrivate:localNumber" mediaClass="notKnown" bitRate="constant">4028:CMCT::0</numberDialed>
</lastRedirectionDevice>
<localConnectionInfo>connected</localConnectionInfo>
<userData>
<string>EFBFBD5F095200303933491069EFBFBD</string>
</userData>
<cause>newCall</cause>
<networkCallingDevice>
<notKnown />
</networkCallingDevice>
<networkCalledDevice>
<notKnown />
</networkCalledDevice>
<callLinkageData>
<globalCallData>
<globalCallLinkageID>
<globallyUniqueCallLinkageID>00001081791498150707</globallyUniqueCallLinkageID>
</globalCallLinkageID>
</globalCallData>
</callLinkageData>
<extensions>
<privateData>
<private>
<EstablishedEventPrivateData xmlns:ns1="http://www.avaya.com/csta" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="EstablishedEventPrivateData">
<trunkGroup>1</trunkGroup>
<trunkMember>25</trunkMember>
<acdGroup typeOfNumber="other" mediaClass="notKnown" bitRate="constant">4048:CMCT::0</acdGroup>
<reason>none</reason>
<distributingDevice>
<deviceIdentifier typeOfNumber="explicitPublic:national" mediaClass="notKnown" bitRate="constant">95724331:CMCT::0</deviceIdentifier>
</distributingDevice>
<distributingVDN>
<deviceIdentifier typeOfNumber="explicitPrivate:localNumber" mediaClass="notKnown" bitRate="constant">4038:CMCT::0</deviceIdentifier>
</distributingVDN>
<originalCallInfo>
<reason>0</reason>
<callLinkageData>
<globalCallData>
<globalCallLinkageID>
<globallyUniqueCallLinkageID>00000000000000000000</globallyUniqueCallLinkageID>
</globalCallLinkageID>
</globalCallData>
</callLinkageData>
</originalCallInfo>
</EstablishedEventPrivateData>
</private>
</privateData>
</extensions>
</EstablishedEvent>



CASE 2: ONLY STATION
-----------------------
Incoming XML 9999
<?xml version="1.0" encoding="UTF-8"?>
<EstablishedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<monitorCrossRefID>195</monitorCrossRefID> (MY COMMENT: STATION 4001)
<establishedConnection>
<callID>8303</callID>
<deviceID typeOfNumber="other" mediaClass="notKnown" bitRate="constant">4001:CMCT::0</deviceID>
</establishedConnection>
<answeringDevice>
<deviceIdentifier typeOfNumber="other" mediaClass="notKnown" bitRate="constant">4001: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>00001083031498152967</globallyUniqueCallLinkageID>
</globalCallLinkageID>
</globalCallData>
</callLinkageData>
<extensions>
<privateData>
<private>
<EstablishedEventPrivateData xmlns:ns1="http://www.avaya.com/csta" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="EstablishedEventPrivateData">
<trunkGroup>1</trunkGroup>
<trunkMember>8</trunkMember>
<reason>none</reason>
<distributingDevice>
<notKnown />
</distributingDevice>
<distributingVDN>
<notKnown />
</distributingVDN>
<originalCallInfo>
<reason>0</reason>
<callLinkageData>
<globalCallData>
<globalCallLinkageID>
<globallyUniqueCallLinkageID>00000000000000000000</globallyUniqueCallLinkageID>
</globalCallLinkageID>
</globalCallData>
</callLinkageData>
</originalCallInfo>
</EstablishedEventPrivateData>
</private>
</privateData>
</extensions>
</EstablishedEvent>

As Martin pointed out earlier in this thread, UserData is typically sent from CM in a Delivered event to the station. Your trace isn't showing Delivered events. Just Established. That says to us something interesting is going on from a feature perspective (e.g. bridging , Team Button, etc) that does not send the Delivered event.

For whatever reason the monitor on the VDN is providing UserData in the Established event, and that makes UserData available to AE Services, which can then provide it with the Station Monitor (it knows the same call ID is in use for both) in that Established event.

So I believe your problem is traceable to the missing Delivered event, which as I said is probably due to the choice of features used in this call flow. Which is why I was driving at understanding the vector and how the call is delivered to the stations.

Sorry John, but talking to you I'm trying to understand the meaning of many terms I do not know very well.

I was concentrating on the "established event" because I would like to monitor "the user who receives a call and raised the handset", so I imagined that the most appropriate event was the "established event" (I do not know the difference with the "delivered event").

Also, I did not understand if it may be useful for your troubleshooting to repeat the monitoring (VDN + STATION) with the Dashboard, also selecting the "delivered event".

I also add that USER DATA seems truncated to what I expect.

Sorry, I am assuming you are familiar with CSTA terminology

Delivered equates to a call offered to a destination device (think alerting).
Established equates to a destination device answered (or was joined into) a call.

Unless you go out of your way to reduce the number of events that are provided by a monitor, you would get all of the aforementioned events (and then some), so our base assumption (particularly when using the DMCC Dashboard) is you are getting all events that AES would normally send.

If you are filtering off events (deselecting them when creating a monitor), yes I would suggest enabling the delivery of the DELIVERED event (actually all events so you begin learning about them) and repeating the test on just the STATION case. I believe we have established that the VDN+STATION case is 'well behaved.'

We understand that UserData is not appearing in the monitor for the station in the established event when only the station is monitored.

Hi John,
i attach a monitor log with all enabled events and SAT screenshots.

From what I see on the dashboard, it seems that the Delivered Event, though enabled in the monitor, is not generated or it does not reach the AES server.

I also want to add that our AVAYA AURA 6.2 platform is completely fault tolerant (N.2 MEDIAGW + N.2 CM + N.2 SM + N.2 AES), I do not know whether in balanced mode (if it exists) or in active-passive mode.

I do not know if this information may be pertinent to the case.

So to summarize,

o UUI is sent from Communication Manager to AE Services ONLY in an ASAI Alerting event (equivalent to DMCC Delivered event).

o Once AE Services has received UUI for a call, it will include it in a subsequent Established event when it receives an ASAI Connected event.

o You have a call flow which does not produce an Alerting event when the call reaches the agent's phone.

o In order to have UUI included in the Established event, AE Services must first receive an Alerting event from Communication Manager. As you have a VDN in the call path, an easy way to achieve this is to place a monitor on the VDN. You have seen this working.

o I agree that the UUI you received is corrupt. This is due to how the DMCC module in AE Serivices handles negative numbers (where a byte is > 0x7F). I reported this recently to the product house in MR AES-16385. So, until this problem is fixed, you must ensure that all bytes in the UUI are < 0x80.

If you need further support on this, I suggest you open a technical support ticket. Please note, for non-paid members, there may be a fee for this service.

Martin

Thank you Martin and Thank John for the great help in identifying the problem.

I forwarded the result of your help to my company to allow me to open a technical support ticket and pay for it.