Nous utilisons depuis des années des scripts VXML sur les SVI VXML d'ovh.
Depuis une semaine, 20% des transferts effectués par nos script échouent avec une erreur network_busy.
Le problème est totalement intermittent et ne semble pas lié au numéro lançant le script VXML, ni à la ligne destinataire du transfert.
Une hypothèse pourrait être que dans les différents IPBX d’OVH hébergeant l’exécution des scripts VXML, un ou plusieurs IPBX présentent un problème réseau et ne sont plus capable de transférer l’appel à une ligne OVH.
Est-ce que vous rencontrez le même problème ? Avez-vous trouvé une solution ?
Bonjour,
Je rencontre également les mêmes problèmes.
Certains transferts passent, d'autres ne sont pas effectués. Pour un même script et un même scénario.
Pour l'instant je suis en quête de solutions également.
Le support OVH a enfin accepté de regardé le problème, mais pour l'instant ils indiquent que je suis le seul client à rencontrer le problème.
Merci par avance si vous pouvez aussi de votre côté ouvrir un ticket et leur indiquer que c'est le problème que le ticket n°1247181. Cela nous donnera plus de chance que cela avance.
Ok, je fais ça de suite.
Edit : c'est fait.
Bonjour,
Je rencontre également le même problème. J'ai pris des appels simultanés supplémentaires et j'ai l'impression que ça réduit la fréquence des network_busy, sans totalement régler le problème.
J'ai aussi remarqué que quand un appel était transféré sur une ligne et que la communication était finie, cette ligne restée en état network_busy pendant quelques minutes après avoir raccroché.
Bonjour à tous,
Nous avons le même soucis de notre coté depuis jeudi approximativement. C'est un soucis que nous avons déjà eu il y a un an environ. (TEL-5842)
La soucis avec OVH et le VXML c'est que le support est très limité et non priotaire, il faut déjà passer la barrière du "pas de support VXML" car le code est de notre responsabilité.
Le taux d'échecs est assez variable, parfois 3 appels sur 4, parfois 1/2… De noté coté nous somme retournée en configuration OVH en perdant nos outils (gestion des files custom, alerting…) Je scrute matin et soir le ticket voip sur travaux mais pas d'évolutions pour le moment…
Bon courage à vous en espérent que ce soit réglé rapidement…
Merci pour votre retour.
Pour aider OVH à constater le problème, nous leur avons mis en place un prototype simple
Sur le numéro 01.84.25.22.42, un script qui tranfert l'appel au 01.88.32.37.75 puis énonce le code de retour du transfert "Je suis le script 1. Le code de retour du transfert est xxxxxxx", script visible au lien : https://gestion4.neovote.com/file/uuf_3323efc53c6c5fa7e240a74a0e8ba329faae0267de148487fa092133b17c3c58.txt https://gestion4.neovote.com/file/uuf_3323efc53c6c5fa7e240a74a0e8ba329faae0267de148487fa092133b17c3c58.txt
Sur le numéro 01.88.32.37.75, un script qui énonce simplement "Je suis le script 2. Le transfert a bien fonctionné, au revoir", script visible au lien :
https://gestion4.neovote.com/file/uuf_c262f45c4852ff4e1fc11f80b587c54aacfbdc930891942b4257a70388bbfce0.txt https://gestion4.neovote.com/file/uuf_c262f45c4852ff4e1fc11f80b587c54aacfbdc930891942b4257a70388bbfce0.txt
En appelant le 01.84.25.22.42 (vous pouvez faire le test), on devrait entendre "Je suis le script 2. Le transfert a bien fonctionné, au revoir. Je suis le script 1. Le code de retour du transfert est near_end_disconnect"
Cependant aléatoirement, le resultat est "Je suis le script 1. Le code de retour du transfert est network_busy".
Les numéros n'étant pas assujetti aux appels simultanés, le test a priori exclu cette cause possible.
En espérant que le cas test que nous leur avons transmis va intriguer le support d'OVH.
J'ai fait un peu dans le même principe pour simplifier les tests et "isoler" un peu le soucis :
https://pastebin.com/RY9YxuaJ
(j'ai fait en sorte de copier un script depuis internet pour limiter les cas et que ce soit le plus "standard" possible)
Bonjour,
Je vous confirme qu'il ne s'agit pas d'un cas isolé.
Nous rencontrons le même problème depuis le 04/12/2020 (journaux à l'appui).
Nous redirigeons nos appels vers notre serveur Asterisk, celui ci ne voit aucun appel.
La consultation des logs vxml ne donne pas grand chose, ils sont actualisés tardivement, et se limitent à 10 lignes.
Rappel ils sont consultables sur l'api OVH :
/telephony/".$billingAccount."/vxml/".$serviceName."/settings/logs
Il s'agit bien d'un problème avec la balise transfert, un appel direct sur le numéro de destination ne pose pas de problème.
Je n'ai pas non plus identifié de causes possibles, cela reste aléatoire, certains appels passent, d'autres non.
Merci pour vos retours. Pour essayer de faire accélérer la résolution de l'incident, nous avons fait escaladé la gestion du ticket par notre interlocuteur commercial grand compte. Espérons que porte ses fruits.
Nous avons réussi à avoir un premier retour d'un admin OVH. Le bug est référence sous la tâche : TELSD-1277 dans le suivi http://travaux.ovh.net/?do=details&id=31870 http://travaux.ovh.net/?do=details&id=31870
Juste pour centraliser l'info :
Comment by OVH - Monday, 21 December 2020, 09:01AM
Tickets résolus:
TELSD-1257 18/12/2020 [Carrier-SIP] Sortants vers BE KO
TELSD-1279 17/12/2020 Commande alias géo impossible sur la commune Oloron-Sainte-Marie
TELSD-1277 16/12/2020 [SVI Vxml] - erreur network_busy
TELSD-1275 14/12/2020 Conf. gratuites - Room à 0
Bonjour,
Je rencontre exactement le même soucis ("network_busy" lors des transfers via vxml).
Avez-vous pu trouver résoudre ce soucis ?