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.
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 we ask the User to perform a call to the Echo service.
If PrivateGSM reconnects to perform the 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 the case presented into the Introduction. First check that the PrivateGSM configurations are correct and if not, fix them and close the Incident. If they are fine, then test one call to the User and try to catch the exact error on the client as it happens on your side. Check if this can lead to identify a cause.
If you are still clueless you better escalate
Second Level
Since at this point it's very possible we are experiencing a configuration problem on the server side, you have to check deeply the User's account configuration: is the User accounted on the PBX? Is his/hers account registered? Is there any virtual number duplication? Is the Account configuration compatible with the client one (check the obfuscation for example).
If all this checks go fine, 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 feasable, thus we check the client logs and then we escalate.