Introduction
The connection issue is a specific Incident report, so we have to focus on connectivity issues, analyzing the entire end-to-end from the reporting User's network to the PBX's one.
Can't connect or register to the server
First Level
Connection issues are often symptoms of network problem, either it's the transport layer (and thus the mobile operator's data configuration) or the application layer (meaning some misconfiguration of the account or some error in the server's network). So we start examining the User's network. First we have to check if the device can connect to the Internet: we open the device's browser and visit a popular web site (your choice, but let's say "google.com"). If the site is not reachable, then you can close the incident as "Not an issue" and tell the user to solve the issue with his(her) provider. If instead the internet connection is available, then check the client connection status.
If the client is connected, then this could be a Temporary Network Problem or a change in the mobile data configurations. To discern the two cases you have to run a search on the User' SIP Sessions. (add procedure and link here)
If the customer's device fails to connect, then we Force Manual Reconnection, so we are sure that the connection action is correctly triggered and thus we can collect answer by the client. In case of failure we can run the procedure once again, then if the failure persist we write the exact error message (if any) about the connection problem. Using this message we Check the Configuration of the Application, looking for misconfigurations which might lead to the incident reported. Example Given: pbx wrong address or port.
In case of Self-Registration (Professional Edition) or Automatic Activation (Enterprise Edition) the customer can't read the application settings and they must be checked in the file "settings.xml" that is sent along with the encrypted logs. Please note that in the mentioned cases the configuration error is unlike to occur.
If the Configuration of the Application is somehow wrong, we can try to fix it and test if the User can connect to the PrivateServer correctly. If the connection works fine, then we close the Incident, else we need to check that the PrivateGSM configurations are correct and that the User's account is actually present on the PrivateServer if it seems to be something wrong, try to fix the configurations and eventually close the incident.
If the configuration looks fine but the Application continue to complain about connecting, we need to escalate.
Second Level
The second level is in charge to fully evaluate the server configuration to understand if the connection problem is somehow related to some issues on the server.
First thing to do is to check the Network, as the connection problem is mostly network driven. If the check goes fine, then we check the server services, paying particular attention to the Asterisk server and to the Database backend, as they are potentially to blame for such behavior.
If the services are fine, we must investigate further what's really happening and so we go down into the client logs. If nothing arise from there, we can just escalate to the third level.