Good to hear you are back to making progress on your application.

I have sent some questions uplink to see what I can find out for you regarding the how to of your question.

Have you looked at the JTAPI sample application available on the devconnect web portal ... login and change your uri to:
https://devconnect.avaya.com/public/dyn/d_dyn.jsp?fn=125

The "Conference Transfer" sample application is a JTAPI application designed to demonstrate the use of several third party call control capabilities. Using this application users can control their phone set from their PC. Calls can be placed, answered, put on hold, and retrieved from hold. The application can also conference additional parties onto an existing call and transfer a call.

This will demonstrate the proper methodology for securing deviceIDs.  While the application is meant to monitor stations, you can peal the initialization sequencing from it to properly initialize to monitor a VDN.

Your best bet then is to get the end customer to escallate through Avaya support. It should work.   I don''t have access to the knowledgebase of known issues. This scenario is simple enough that that group would be aware of an issue and what it''s resolution is.

How did you verify the ANI was received at CM 1.3 system? what command let you see it? Note that seeing it on the wire is not proof that CM bothered to receive it.  You could try some simpler call scenarios between the two systems to verify the CM 1.3 system is receiving ANI and delivering it (say) to a display station.

Have you tinkered with the vector handling to prove the vector got the ANI informatin and it was not deleted during inbound trunk processing?

What releases are you running on the CT servers? I presume the most current (1.3). If not you should lay your hands on it and get it installed

If you have Avaya maintenance on these systems, I think the shortest path to getting this resolved is to open an escallation. They will get the CT server upgraded, and then ask you to re-run the scenario. if it fails, they will capture a trace of the ASAI message from CM to the CT server and verify the information is not being delivered (you can do this if you know how to generate a g3trace using tracemask file). I''m betting the information is not being delivered by CM based on what you are observing.  Once they verify it is not being delivered by CM CT tier 2/3 support will pull in CM support to figure out why the ANI information is diaappearing.  Since my expertise is in the APIs themselves, based on what I preceive is wrong here, I can not really be of much more use to you.

are you saying you see the ANI in the tracing on site 2?  If so it is coming across the trunk, then right?   I am not sure it matters in this case, but do you have a wait step at the begining of the vector to make sure the information is fully collected before the vector starts acting on the information it received?

Have you read through the ANI & BSR information in "Avaya Call Center Release 3.1 Call Vectoring and Expert Agent  Selection (EAS) Guide  (document # 07-300477)"

See also section''Displaying ANI Calling Party Information'' in Administrator Guide for
Avaya Communication Manager (document # 03-300509 Issue 2)

Have you determined if the ANI is being signaled between the two switches? i.e. is site 1 sending it?

Are the two trunk groups provisioned the same (in regard to calling number handling)? See pages 2 and 3 (particluarly the Outgoing ANI flag/send calling number on page 3) of the trunk group form. Is site 1 properly provisioned for sending ANI over the trunk?

Any time... we are here to help.

If you call Site 2 vdn X directly from your mobile (or other device), do you see CTI events from the CT Server connected to Site 2?

The TSAPI SDK is a for fee product. This is because the SDK includes an ASN1 compiler and other tools from a third party company for which Avaya must transfer licensing costs.

As a registered developer, you can purchase the SDK from a business partner. You can find business partners by going to the www.avaya.com web page and clicking the ''Find a BusinessPartner'' link from the Connect with Avaya column (third from left). Higher level devConnect members can use the procurement page in the webPortal to purchase the TSAPI SDK.

The JTAPI SDK is available for free download off this page
https://devconnect.avaya.com/public/dyn/d_dyn.jsp?fn=131
(login to the portal first and then change your URI to the above text).

And when you call vector X and it does a bsr query to site 1, you see a different set of  events? I.e. I infer from your first post that you see the call arrive at vecor X and then see it at vector A? Do I have that right?

What devices are you monitoring at the two sites? the vectors? the splits? both?

In the two scenarios, I presume you have an exerciser connected to site 1 and a separate exerciser connected to site 2, each through its own CT server (true?), can you be more specific about which exerciser sees which events?

I''m still trying to get clear on what you see and where you see it from.

Good point. I stand corrected.
In that scenario or others where a DMCC ''party'' is in a connection with some other party or parties, and the DMCC party is in a talking state, and is in the server media mode, the DMCC API can be used to collect DTMF events. If the DMCC ''party'' is in client media, then the application can collect digits on its own. If the DMCC ''party'' is in shared control, DTMF events can not be collected.

Sorry for the delayed response, the engineer responding to it went out on vacation. 

Once a call enters the ''talk'' state there are no DTMF detectors attached to it. In order for CM to ''hear'' the DTMF events, it needs a DTMF detector attached.  This is because in most configurations, the button push is signaled to the far end by the telephone as an in-band tone, and no event is passed into the switch. For a few station types the switch receives an event related to the (DTMF) button push, but not all station types.   A DTMF detector is a shared (precious) resource and leaving them attached to calls in the talk state is expensive.

So, sorry, but no, there is not a mechanism (in JTAPI or any of the other call control APIs) to collect DTMF events from a call after it enters a stable talking state (or even after it has been routed to a destination and it is ringing there).

When you did a Get DeviceID, you provided either a specific IP address or symbolic gatekeeper name. Given what I see in this response message, I suspect you provided an IP address for CM in the CM IP Addr/Name field of ''10.196.xx.xx''  You need to provide a fully qualified IP address for a CM C-LAN or procr interface in that field. You can see what data items the dashboard uses in each request by positioning the cursor over thebutton and the tool will backlight the data items with a bluish hue. Since the dashboard allows either IP addresses or H.323 Gatekeeper names in this field I suspect the problem lies in that portion of your attempt to use the dashboard.

The alternative problem is that you are using a H.323 Gatekeeper symbolic name. H.323 GK names are a bit of an advanced topic, but through the AES OA&M web pages you can access the ''switch connection'' provisioning. Within a switch connection (something you create the name of), you can create a H.323 Gatekeeper List. A DMCC getDeviceID request can utilize the switch connection name in its request in lieu of a specific IP address for CM. This allows the AES to distribute traffic across a set of C-LANS.

The dashboard is a great learning tool. Keep at it and you will see how useful it is.