Introduction
This is one of the most claimed incidents to occur. This Incident troubleshooting must be confronted only if the incident definition and description hasn't pointed out any operational requirements violation. "User can't call" cause is equally divided into client/server misconfigurations and connection issues.
| Warning | ||
|---|---|---|
| ||
Please keep in mind that a call can fail due a reason that doesn't depends on the client Please note that this troubleshooting workflow only applies if no specific error messages are written by the PrivateGSM (e.g. License problems, user offline o or doesn't exist, etc...). In these cases an error message should appear on the client screen, so check any message before to proceed to troubleshoot an incident of this kind. See TODO: insert section |
First Level
...
. |
User can't call
First Level
We check the connection on the PrivateGSM side is fine: check the connection status declared by the application. After we record the connection status, we perform a App - Force Manual Reconnection to make sure that the connection action is correctly triggered and thus we can collect answer by the client. If the connection has some problem, then we move to the Connection Issues troubleshooting. If the connection proceeds fine or was declared all right then is possible that the User experienced a Temporary Network Problem which could be over.
To test the actual Incident status first of all we ask the User to perform to make a call to a surely reachable accounttest call.
If the call fails, first check that the PrivateGSM configurations are correct and if not, fix them and close the Incident. If they are fine, let's escalate to the second level
If PrivateGSM reconnects to perform the test call to Echo service, then most probably we had a Temporary Network Problem issue. Let's check if now the User can call other PrivateGSMs.
If the call to the Echo service fails then we have to investigate further on the server configuration and services, thus escalate.
If the call goes fine, but still the user can't place calls to other PrivateGSM, then we can drop any connection and license causes, or most of their cases. So we can now focus on misconfigurations either on PrivateGSM and PrivateServer: let's start with the trunks.
Check if the PrivateServer is configured with one or more Outgoing trunks. If no trunk is configured, then the issue can be on the PrivateServer: check if the User has an account and if such account is registered. If it's not either accounted or registered, then this is not an issue: you must create the new user before he/she can call.
If almost one trunk is present, we'd better check if the User is using such trunk to route the call and so check trunk(s) status and configuration. If the trunk(s) are fine, but still the User can't call, then you need to escalate.
...
party now, if he (she) can then close the incident. If the User still can't call then check that the other device is connected and registered and if it doesn't, close the incident as "Not an issue".
If the other party is connected and registered then escalate to the second level.
Second Level
We can receive an escalation request either for a User's remote party configuration check or for a PrivateServer status check.
In the former case we need we have to understand if check the User's account has been created remote party activities on the related server. If it's, then we assure it's registered as well and (most important) we must check if his/hers virtual number has a similar entry assigned to another user: is the user duplicated? If all this checks pass fine, then we can only escalateserver in order to discover some conflict, such as a virtual number duplication and eventually try to solve the conflicts.
In the latter case we we need to first perform a Server services' check. If the Services pass the tests, than we can focus on the Check Network Status, to understand if some communication issue are causing the Incident. If nothing arise, then we go for a deeper look using the client logs and, at last, we escalateperform some tests on the PrivateServer status: Network and PSAM 3.3 Check Server Services.
If all of the above are fine, the final possibility of a bug in the client become feasible, thus we check the client logs and then we escalate to the third level.