...
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 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
|
User can't call
First Level
...
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, then most probably we had a Temporary Network Problem issue. If the test call goes fine, check if the PrivateServer is configured with one or more Outgoing trunks. If almost one trunk is present, then you need to escalate.
On the other hand, if no trunks are configured, let's check if the User can call other 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 for three reasons: a User's remote party configuration needs to be checked, we have to check wether one or more trunk are configured, a general network status check.
...