Skip to end of metadata
Go to start of metadata

Introduction

If the User can't receive calls but can call the others, then you have a very specific Incident to deal with. This kind of Incident is very often a configuration mismatch from client to server about, for example, the PrivateGSM is configured as a Professional version, instead it is an Enterprise. Other bogus configuration has to be checked as well. As the PrivateGSM can place the outgoing calls, it's unlike that the cause of the Incident is a network issue. However we better verify any possibility before jumping to the conclusions.

 

User can't receive calls

First Level

In order to test investigate this kind of issues, the user has to call the customer service with a device different from that on PrivateGSM is installed.

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 make a test call if the test call goes wrong then we will move to the User can't call for Enterprise or Professional edition

If the call goes fine, let's try to call the user to determine if he (she) is actually experiencing problems to receive calls. 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 focus on the other party configuration, in most cases the caller's device is registered on another server then we can close the incident as "Not an issue", if the server is the same for both of devices, we need to escalate to the second level.

Second Level

Since at this point it's very possible we are experiencing a configuration problem on the server side, you have to check the User's account activities on the server in order to discover some conflict, such as a  virtual number duplication, if it does then resolve the conflict and close the incident. If it doesn't, then we need to perform 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.

  • No labels