1 –Run BUSYOUT and RELEASE for all extensions with TCP socket NO to establish the socket again, monitor to see if denial event persists after that.
2 –In case the denial event persists:
Network-region was programmed with the parameter Near End Establishes TCP Signaling Socket? Y . With that, PBX was responsible to establish the TCP signaling to AES. I recommended to change it to NO and then, the FAR-END (AES) would establish it. This parameter is called TTL.
With this, a problem with TCP socket is recognized by AES and ACR will receive the information.
To identify the cause of TCP socket NO we will need to change it back and collect a sniffer trace between AES and PBX, so I think we could consider the high traffic over PROCR and the statements below when the TTL is enabled:
1. In heavy occupancy situations, the establishment of the TCP signaling connection between endpoint and CM will be delayed.
2. The direction of the connection is reversed; CM will connect out to the IP endpoint.
3. Resiliency to TCP connection failure. If a connection fails, the system will not rush to reestablish the connection but connection can be triggered by endpoints (ARQ message.)
4. Registration persistence. The registration will persist for TTL duration regardless of TCP connection failure, network outages, or even restarts of the endpoint ( not power outage.)