I have a very odd situation with one of our client's aes. When my application reconnects to the aes it tries to register for all vdns (3 times each for each vdn). Sometimes I am denied registration to these vdns (which in it of itself is odd too because I should be the only routing server for these vdns). My application then restarts. It first sends an open req to which i get a valid invoke id and acs handle, so far so good. Now according to Avaya documentation and tutorials, the next thing I should do is do a "SendAcsGetEventBlock" which should read the acs_open_stream_conf event that should be waiting for me. However it appears that this event never arrives and my application just sits there waiting. If I restart my application again then things go back to normal.

Is there a reason why i would not get this acs_open_stream_conf event? What should I do in this case?

you are raising two issues.
1) VDN re-registration
2) open-stream confirm

2) Enable TSAPI tracing. What do the AES logs say is occurring? Does it show the request and it sending a response? What does a tcp trace show is occurring? what does tcpdump or equivalent show is happening on your server. To me it sounds like there is something amiss at the TCP layer.

1) normally AES will honor a re-register attempt by an application at the same ip as the prior registration. At one point in the distant past there was a product issue with this behavior. I suggest getting on the latest release for the major release the customer is running. If the same IP is not making the request a timeout must occur before a different application can claim the registration (AES doesn't know how many applications may be trying to interface to it). Further enable TSAPI tracing. What do the log files (g3trace and csta-trace) show is occurring when the problem occurs?

Unfortunately we do not have access to the customer's aes or aes logs. I also think that tsapi spy may be disabled so that we can't see what they actually sent us. I am not familiar on how to use tcp trace or dump in conjuction with the aes, could you elaborate on that

if you dont have access to the customer's AES to get at the TSAPI logs then I don't see how you could use a tool like tcpdump on their AES. And actually I was thinking that you should be using those tools on your server... In order to troubleshoot issues, you need to leverage someone with access to the AES. Get the customer to open an Avaya support ticket with Avaya Client Services and have them enable the logs and capture details of the two issues you raise.

TSSPY didnt like to be run on Windows Server edition. I think this was addressed in more recent releases of the SDK, but since the SDK is not free it would cost money to test that possibility associated with getting data on this issue (which version of the SDK are you using).

In the case you do not receive a acs_open_stream_conf within a reasonable time-out (~5-10 seconds), close the stream and reattempt the open.

Thank you very John, you have been extremely helpful

John do you know what the earliest version of the SDK received the fix for the tsapi spy not working on Windows SE?