...
If PrivateGSM reconnects to perform the test call, then most probably we had a Temporary Network Problem issue. LetIf 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.
Anchor escalate escalate
Second Level
| escalate | |
| escalate |
We can receive an escalation request either for three reasons: a User's remote party configuration needs to be checked, we have to check or for a PrivateServer wether one or more trunk are configured, a general network status check.
In the former first case we have to check the User's remote party activities on the server in order to discover some conflict, such as a virtual number duplication and eventually try to solve the conflicts.
In the latter case we need to perform some tests on the PrivateServer status: Network and second case we need to check if the User is using such trunk to route the call and so check trunk(s) status and configuration, by performing the checks described in PSAM 3.3 Check Server Services section.
In the latter case, no issues have been found in User client configuration, so we need to perform some tests on the Network status to understand if some communication issue are causing the Incident.
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.