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.
...
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)
any case we force a 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. If the connection proceeds fineIn case of failure we can run the procedure once again, then the User experienced a Temporary Network Problem which is now over and then the Incident is closed, otherwise 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.
| Note |
|---|
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 on the server side. Plus in these 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.
...