OVHcloud Web Hosting Status
Current status
Legend
- Operational
- Degraded performance
- Partial Outage
- Major Outage
- Under maintenance
FS#10287 — call queue
Incident
Report for Web Cloud
Resolved
Changes previously made on the call queue machine to adjust the 5 seconds of white noise have effectively degraded the quality of calls transferred or put on hold.
We have reproduced the error and we're working to fix the situation ASAP.
Update(s):
Date: 2014-03-21 13:36:29 UTC
Following feedback given on the ML and also to support, the problem has been resolved.
Date: 2014-03-17 05:49:40 UTC
All machines have been updated.
We are waiting for your reactions to check service improvements .
Date: 2014-03-17 05:48:22 UTC
Remaining one machine to update.
Date: 2014-03-16 21:09:35 UTC
We are starting to disable the codec G729 on the servers of the cluster.
Date: 2014-03-13 20:00:07 UTC
Thereafter different tests done on the new architecture and claims of some people who have done tests, we have noticed that disabling the codec G729 improves the quality of communications and problems while resuming the call.
Having no quick solution for the initial architecture, we have decided to disable this codec temporarily. We will apply this modification on Sunday night at 22h.
Meanwhile, we advise you to mainly check that no member of your queue calls is in G729 only (which is generally not advisable).
We will be waiting your feedback on Monday morning on the ML in order to notice the efficiency of this modification.
We aim to allow you have a better quality communications.
Then, we'll look for further details to identify the origin of the issue.
Date: 2014-03-11 20:09:04 UTC
We have tested the setting allowing to by-pass the call forwarding to the members.
We are quickly setting it on the queue calls.
Date: 2014-03-11 20:07:53 UTC
Some queues are still having blank communications issue, oftenly the MGCP members, thereafter an on-hold.
On the new infrastructure of queue calls that we have deployed,
we were able to isolate the issue which is due to the codec G729.
We have disabled the management of this codec on the new servers. We would like to know why the
issue occurs in order to suggest this codec sustainably on the queue calls.
If the issue reoccurs, you could test the new infrastructure by forwarding it to us via the voip mailing list.
Meanwhile, we are working to manage the call sending on the queue calls service, for now, managed in (easy|mini)Pabx.
Date: 2014-02-25 17:26:35 UTC
Only 2 machines are still to be updated.
Date: 2014-02-25 12:32:07 UTC
The machine has been returned to the cluster.
We are monitoring the activity as planned.
Date: 2014-02-25 11:45:03 UTC
This morning, we tested various configurations on the development environment with yesterday's patch (classic call test, on hold, SIP and MGCP transfers etc).
No anomalies were found.
We have removed a machine from the cluster in order to update it
Once done, we will redeploy it and monitor the activity for 2 to 3 hrs to confirm that there are no side effects on a larger scale.
The next stage will be to update the other machines of the cluster.
Date: 2014-02-24 23:28:41 UTC
Thereafter the reproduction of the bug on a testing environment, we have succeeded to isolate the issue and develop a patch fixing it.
We have planned a phase of deepened tests on the environment in order to validate the corrective tomorrow morning.
Thereafter this, we will set it into production one by one the servers of the cluster progressively.
Date: 2014-02-21 21:28:37 UTC
We have done many tests in order to fix the issue, but any found solution impacts other options.
We are still looking for a reliable solution.
We have reproduced the error and we're working to fix the situation ASAP.
Update(s):
Date: 2014-03-21 13:36:29 UTC
Following feedback given on the ML and also to support, the problem has been resolved.
Date: 2014-03-17 05:49:40 UTC
All machines have been updated.
We are waiting for your reactions to check service improvements .
Date: 2014-03-17 05:48:22 UTC
Remaining one machine to update.
Date: 2014-03-16 21:09:35 UTC
We are starting to disable the codec G729 on the servers of the cluster.
Date: 2014-03-13 20:00:07 UTC
Thereafter different tests done on the new architecture and claims of some people who have done tests, we have noticed that disabling the codec G729 improves the quality of communications and problems while resuming the call.
Having no quick solution for the initial architecture, we have decided to disable this codec temporarily. We will apply this modification on Sunday night at 22h.
Meanwhile, we advise you to mainly check that no member of your queue calls is in G729 only (which is generally not advisable).
We will be waiting your feedback on Monday morning on the ML in order to notice the efficiency of this modification.
We aim to allow you have a better quality communications.
Then, we'll look for further details to identify the origin of the issue.
Date: 2014-03-11 20:09:04 UTC
We have tested the setting allowing to by-pass the call forwarding to the members.
We are quickly setting it on the queue calls.
Date: 2014-03-11 20:07:53 UTC
Some queues are still having blank communications issue, oftenly the MGCP members, thereafter an on-hold.
On the new infrastructure of queue calls that we have deployed,
we were able to isolate the issue which is due to the codec G729.
We have disabled the management of this codec on the new servers. We would like to know why the
issue occurs in order to suggest this codec sustainably on the queue calls.
If the issue reoccurs, you could test the new infrastructure by forwarding it to us via the voip mailing list.
Meanwhile, we are working to manage the call sending on the queue calls service, for now, managed in (easy|mini)Pabx.
Date: 2014-02-25 17:26:35 UTC
Only 2 machines are still to be updated.
Date: 2014-02-25 12:32:07 UTC
The machine has been returned to the cluster.
We are monitoring the activity as planned.
Date: 2014-02-25 11:45:03 UTC
This morning, we tested various configurations on the development environment with yesterday's patch (classic call test, on hold, SIP and MGCP transfers etc).
No anomalies were found.
We have removed a machine from the cluster in order to update it
Once done, we will redeploy it and monitor the activity for 2 to 3 hrs to confirm that there are no side effects on a larger scale.
The next stage will be to update the other machines of the cluster.
Date: 2014-02-24 23:28:41 UTC
Thereafter the reproduction of the bug on a testing environment, we have succeeded to isolate the issue and develop a patch fixing it.
We have planned a phase of deepened tests on the environment in order to validate the corrective tomorrow morning.
Thereafter this, we will set it into production one by one the servers of the cluster progressively.
Date: 2014-02-21 21:28:37 UTC
We have done many tests in order to fix the issue, but any found solution impacts other options.
We are still looking for a reliable solution.