Freeze the first failed boundary
Record server identity, running branch and maintenance release, manager listener and transport, client source, manager username, connection time, exact request headers with secrets redacted, unique ActionID, raw response and the first disconnect observation. Classify whether connection, framing, challenge, login, post-login action, event delivery or later session lifetime failed.
Do not rotate credentials, widen the ACL and change the listener simultaneously. Those changes erase the evidence needed to distinguish reachability, authentication and authorization.
Prove the expected listener and protected path
Confirm the client reached the intended Asterisk instance and manager service rather than another host, port or HTTP surface. Compare listener policy and the client source with the deployment's network controls and manager ACL. A successful TCP connection is not a successful AMI login.
Do not expose the manager interface publicly as a reachability test. Keep the official safe-environment, SSH-or-VPN and permit/deny guidance as the network boundary.
Validate message framing and Login fields
Verify Header: value lines, the blank-line terminator, exact Action: Login, Username, AuthType and the matching Secret or Key field. Preserve whether the client relied on the documented plain default or requested MD5. Compare the username with the effective manager.conf owner without disclosing the stored secret.
Keep parser failure, unknown account, incorrect credential material and an authorization failure after login as different diagnoses.
Reconstruct the MD5 challenge transaction
If the client uses MD5, retain a bounded record that Challenge was requested with AuthType: MD5, a challenge response was received and the final key was formatted as 32 lowercase hexadecimal characters. Do not publish the challenge, key or secret.
Do not treat the MD5 exchange as TLS, server authentication or a replacement for network isolation. If the client reused stale transaction state across a reconnect, start a fresh session rather than mixing exchanges.
Separate authentication from events and actions
After login, use the user-scoped command inventory to test action visibility. Compare the login-time Events selection with account read classes, later Events actions, filters and client parsing before labeling missing events as a dropped session. A working Ping/Pong or one received event proves only its own boundary.
Do not grant all read or write classes to make a test pass. Identify the specific permission and negative case the integration requires.
Classify termination and retest one clean session
Distinguish explicit Logoff, client close, remote close, network reset, server restart and client timeout using evidence from both endpoints where available. Start a new session identity after reconnect, use new ActionID values and do not attach late data from the old connection to the new one.
Retest the protected path, login, user-visible inventory and one authorized operation in order, then record the actual repair and rollback owner. No PBX, manager configuration, credential, ACL, socket, session, request, response, event, channel, packet, media stream or live call was inspected or tested for this diagnostic.
Start core-data diagnosis with the current manager session
The core-query diagnostic rejects cached target identity and responses that cross reconnect boundaries.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.