travaux.telandgo.com

L'incident peut être lié à celui d'orange remonté par un colistié : j'ai une source via mon correspondant collectivités qui me dit : "Vos services sont perturbés ou interrompus suite à un incident sur le réseau Orange. Nous prévoyons un rétablissement complet au plus tard le 13/06/2014 à 11:00. Nous vous prions de nous excuser pour la gêne occasionnée." a priori cela semble toucher l'accès internet, mais je ne sais pas ou cela peut être, est ce les orages ?.?.?

Le problème est revenu : mercredi, 11 juin 2014, 09:26 Une de nos passerelles de conversion entre le réseau IP et le réseau Telecom a un rencontré une surcharge. Nous investiguons. mercredi, 11 juin 2014, 09:35 Nous redémarrons la carte completement. La relance des applications n'a pas suffit a fixer le problème. mercredi, 11 juin 2014, 09:56 La carte est a nouveau stabilisé. mercredi, 11 juin 2014, 10:13 La carte de conversion a un soucis. Nous la remplacons des que possible. mercredi, 11 juin 2014, 10:39 La tâche travaux actuelle est due à un soucis avec une carte de sortie. L'effet de bord constaté est que la carte de conversions est saturée. Elle n'arrive pas à utiliser ses ressources de conversion, de ce fait, certains appels extérieurs au réseau téléphonique OVH n'aboutissent pas. À la suite du problème d'hier, une nouvelle carte a été redémarrée ce matin. Nous travaillons activement à la résolution de ce problème. Nous attendions jusqu'à aujourd'hui le retour de SFR pour la mise en place de la nouvelle interco (la mise en place a commencé en janvier). Suite au problème actuel, l'incident est passé en priorité chez eux, le but est de délester les cartes de sortie. Nous devrions avoir des nouvelles d'eux entre la fin de matinée et le début d'après midi.

mercredi, 11 juin 2014, 11:26 La carte est en cours d'acheminement. Dès réception elle sera mise en place dans les plus bref délais.

mercredi, 11 juin 2014, 12:19 Pour une raison inconnue, nos passerelles de conversion entre les réseaux ip et telecom ne parviennent pas à acheminer toutes les demandes d'appels. Actuellement, la nouvelle interco est en train d'être montée, elle devrait être finalisée avant 14h00. mercredi, 11 juin 2014, 12:27 Les tests de circuits sont terminées. Nous avons ouvert le traffic vers la nouvelle interco. Nous surveillons l'évolution de la situation.

mail du fournisseur : Bonjour, Nous avons eu un soucis ce matin sur l’acheminement des appels. Pour une raison encore inconnue pour le moment, nos cartes n'ont pas réussi à acheminer autant d'appels qu'à l'habitude. Nous cherchons a comprendre ce qu'il s'est passé avec notre constructeur. En parallèle, nous avions déjà commandé une nouvelle interconnexion pour acheminer les appels sortants depuis plusieurs mois. Cette interconnexion était prévue sur une nouvelle infrastructure dédiée aux appels sortants. Il s'agit d'une autre technologie d'un autre constructeur. Le principe est vraiment différent sur l'utilisation des codecs de voix. Le fonctionnement est plus souple à l'utilisation et dynamique. La livraison de l'interconnexion était prévue dans les jours à venir. Nous avons réussi à pousser afin d’accélérer la mise en production. Chose faite depuis midi. Aussi, nous augmentons le nombre de cartes de conversions pour diminuer les ressources utilisées afin d'identifier le soucis que nous avons rencontré. Mais aussi séparer le matériel dédié aux appels entrants des appels sortants. Nous sommes particulièrement désolés de la gêne occasionnée. Nous monopolisons toutes les ressources possibles afin de résoudre ce problème le plus rapidement possible. Amicalement, Simon

mercredi, 11 juin 2014, 14:06 Les indicateurs posés par nous et par notre fournisseur sur la nouvelle interco ne montrent pas de défaut sur les nouveaux liens. Nous continuons notre surveillance sur le bon acheminement des appels. mercredi, 11 juin 2014, 14:31 Nous avons reçu les nouvelles cartes. La carte qui posait le plus de problèmes ce matin vient encore de poser problème. Nous la remplaçons.

mercredi, 11 juin 2014, 16:12 Le remplacement de la carte n'a pas corrigé le problème. Nous recherchons activement avec le constructeur la source du problème : une surconsommation des ressources qui ne corresponde pas aux nombres d'appels simultanés en cours. En parallèle nous préparons de 2 nouvelles cartes pour baisser le niveau d'utilisation cette carte. Ces cartes sont déjà dans le datacenter en cours de raccordement. L'installation se fera durant la soirée. mercredi, 11 juin 2014, 21:47 nous démarrons les opérations de migration Commentaire de OVH - mercredi, 11 juin 2014, 21:54 les fibres sont tirés dans le datacentres. les nouvelles cartes sont allumés. nous démarrons la configuration et le déplacement des liens. Commentaire de OVH - mercredi, 11 juin 2014, 22:49 Les cartes sont initialisés et configurés. Elles sont prêtes à recevoir les E1. mercredi, 11 juin 2014, 23:51 le processus de migration est très long. il faut refaire l'acheminement complet de l'E1 et vérifier circuit apres circuit. nous sommes à 20% de la migration. jeudi, 12 juin 2014, 00:46 les circuits sur les appels entrants sont équilibrés sur toutes les cartes. nous avancons sur les circuits d'appels sortants. jeudi, 12 juin 2014, 01:24 la moitié des circuits sortants a été déplacé. nous terminons la deuxieme moitié. jeudi, 12 juin 2014, 02:10 la migration de tous les circuits est terminée les ressources de chaque carte sera utilisé uniformément.

jeudi, 12 juin 2014, 10:56 Une des nouvelles cartes installées cette nuit montrent des instabilités. Avec Cirpack nous sommes en train de bloquer la carte et préparer son remplacement au plus vite, délai estimé de 3h max. jeudi, 12 juin 2014, 11:31 La carte en cause a été bloqué, mais les autres cartes saturent comme hier. Des ressources sont utilisées alors qu'elles ne correspondent à aucun appel en cours. Plusieurs pistes sont en cours d'étude par la cellule Cirpack/OVH. Les actions actuellement en cours : - cartes en cours de transit pour remplacer celle qui reboot aléatoirement - basculement des infrastructures sur les équipements redondants prévu vers midi dans le creux d'appel : le but est d'exclure un défaut possible sur ces équipements principaux - analyse du traffic IP jeudi, 12 juin 2014, 11:41 Nous vérifions aussi la totalité des branchements de l'infrastructure Voip dans le datacentre. jeudi, 12 juin 2014, 12:05 Nous allons commencer la bascule sur l'équipement de secours. La manipulation devrait prendre 3 minutes. Commentaire de OVH - jeudi, 12 juin 2014, 12:10 Avant d'effectuer le basculement, par précaution, nous avons rebooter l'équipement de secours. Une fois que ce sera fait, nous allons vérifier son bon comportement et enfin lancer la bascule. jeudi, 12 juin 2014, 12:18 Tous les circuits remontent, les premiers sont revenus en moins de 2 minutes. jeudi, 12 juin 2014, 12:56 Une carte a crashé et ne remonte pas. Les 2 nouvelles cartes commandées ce matin vont arriver d'ici quelques minutes. Nous passerons donc de 2 cartes (hier matin) à 8 pour gérer les appels entrants et sortants de notre réseaux téléphoniques.

jeudi, 12 juin 2014, 13:54 Nous démarrons le remplacement de la carte. jeudi, 12 juin 2014, 14:05 La nouvelle carte est installé. Nous la remettons en service.

jeudi, 12 juin 2014, 14:36 La situation semble se stabiliser. Les logs et les tickets d'appels sont correct et ne remontent pas les soucis de ce matin et d'hier. Les cartes communiquent correctement avec le controleur. Nous poursuivons nos observations sur l'infrastructure.

jeudi, 12 juin 2014, 15:09 on doit recevoir un chassis class 4 dans quelques heures. on le connecte puis soit cette nuit soit ce wk on bascule les interco de sortie dessus.

jeudi, 12 juin 2014, 15:31 Nous avons de nouveaux des congestions sur les cartes d’interconnexions. Nous allons mettre en place un autre class4 cette nuit et séparer les interconnections entrantes et sortantes.

jeudi, 12 juin 2014, 17:19 on avait un patch appliqué sur 5c depuis 6 mois. on vient de le retirer du 4. c'est enfin stable. on n'annule pas la mise en place de 4b. on termine avant lundi tout le boulot programmé sur 2 mois. a partir de lundi tout doit etre stable jusqu'a la fin de nos jours.

jeudi, 12 juin 2014, 18:42 Nous avons retiré le dernier patch des infrastructures class 5 qui avait été testé depuis plusieurs mois sur c5c et mise en place ce week-end sur c5a et c5b. Celui-ci résoud des problèmes de boucle d'appels mais il semble qu'il ne libère pas bien les ressources et provoque des surcharges. Depuis le retrait vers 16h30 nous n'avons pas détecté de congestion et donc de pertes d'appels. Il faut valider cette hypothèse dans la journée de demain. En parallèle nous mettons ce soir en place une nouvelle infrastructure class 4 pour les interconnections, dans le but de réduire la charge et diviser l'impact d'un problème éventuel. Tout les détails de l’intervention seront suivi dans une nouvelle tâche.

jeudi, 12 juin 2014, 21:06 Le matériel est arrivé. Nous démarrons l'installation. jeudi, 12 juin 2014, 23:35 Le chassis a été monté et le ping est effectif entre c4a et c4b. Le technicien Cirpack monte le controleur. S'en suivera une installation des applications et faisceaux sur la nouvelle machine. De notre côté, nous avons préparé la configuration du c4b pour router les appels vers l'interco ainsi que la configuration de chargement des DSP. vendredi, 13 juin 2014, 02:37 L'installation des nouvelles cartes n'est pas terminée. Elle prend beaucoup plus de temps que prévu. Nous attendons encore la fin de la configuration de la part de notre constructeur. vendredi, 13 juin 2014, 02:56 Le problème sur le chassis a été réglé. Nous commençons le déploiement de notre configuration. vendredi, 13 juin 2014, 03:44 Les interconnections sont up. Nous finalisons la configuration du class 4. vendredi, 13 juin 2014, 03:55 L'interco est monté sur la nouvelle infra c4b. Nous effectuons actuellement les tests du c5c vers l'extérieur en passant par c4b. vendredi, 13 juin 2014, 04:23 Les premiers tests ont été concluant. Nous avons mis en place le système de fallback entre les deux c4. Un appel qui ne pourra pas aboutir sur un c4 passera automatiquement sur l'autre. Nous propageons actuellement la configuration sur tous les c5. vendredi, 13 juin 2014, 05:06 La config a été propagé sur tous les c5 avec succès. Nous avons aussi adapté la conf des machines des autres services afin qu'elles utilisent la nouvelle infra. L'équipe de jour va prendre le relai d'ici peu.

vendredi, 13 juin 2014, 09:55 Nous avons détecté un problème de routage d'appels vers certains numéros spéciaux qui cherchent à s'écouler par la route C4B. Nous avons identifié l'origine du problème et la corrigeons. Tous les autres appels s'écoulent normalement, les indicateurs sont dans le vert.

vendredi, 13 juin 2014, 10:38 Une des cartes du C4A a redémarré, nous avons essuyé des coupures d'appels et des problèmes d'appels entrants, la situation s'est, pour l'instant, stabilisée. Pour ce qui est du trafic sortant, notre fournisseur d'interconnexion branchée sur le C4B nous rejette certains appels, nous investiguons.

vendredi, 13 juin 2014, 10:38 Une des cartes du C4A a redémarré, nous avons essuyé des coupures d'appels et des problèmes d'appels entrants, la situation s'est, pour l'instant, stabilisée. Pour ce qui est du trafic sortant, notre fournisseur d'interconnexion branchée sur le C4B nous rejette certains appels, nous investiguons.

vendredi, 13 juin 2014, 12:55 Le problème sur les numéros surtaxés est fixé sur tous les c5.

vendredi, 13 juin 2014, 15:08 Cirpack le fabricant du matériel livre dans moins d'une heure une version d'un programme à mettre en place sur les cartes PTG afin d'avoir un système de statistiques et remontées plus efficace.

samedi, 14 juin 2014, 12:25 Le nouveau binaire est en place sur les PTG. Celui-ci permet d'avoir un système de statistiques et de remontées plus efficace. samedi, 14 juin 2014, 17:44 Voici la liste des points sur lesquels nous avançons : 1) On finit les migrations de 150 lignes restants MGCP de c4a vers c5a. les telephones ne veulent pas prendre la nouvelle conf (firewall ?) et donc on va bouger l'ip directement En même temps on fait la migration de 1007 sur le c5a. Tous les abonnés c'est à dire les 130K/140K lignes SIP/MGCP seront à 100% sur les 3 infra c5a/c5b/c5c 2) Nous avons un nouveau equipement qui fait le class 4 c'est à dire l'interco avec France Telecom SFR, Completel, DTAG, BT, Belgacom et Telefonica. Il s'agit de TelcoBridges. Il y a 2 mois nous avons passé la commande pour 4 chassis (au lieu de Cirpack) et nous les avons reçu il y a 1 mois. Depuis, nous faisons les tests, ça se passe bien. On a trouvé un bug cette semaine et on a reçu le patch cette nuit. Ceci dit on ne peut pas l'utiliser pour France Telecom, pas encore, il faut qu'on le certifie avec FT et les autres opérateurs historiques en Europe. Ca va prendre qq mois. Mais on peut l'utiliser pour toutes les communications sortantes et les numeros speciaux. Donc, nous avons mis en place 4 nouveaux chassis TB4A, TB4B, TB4C et TB4D. TB4D c'est notre spare. 3) TB4B est en production avec une interco SFR, dans 1H on va reconfigurer toutes les voix sortantes via cet equipement et on va vous demander de bien valider s'il n'y ait plus de problemes sur les ringback. 4) sur TB4C on va bouger une interco qui est actuellement connecté sur le C4B. C4B ne sera plus utilisé. 5) Sur TB4A on va migrer une interco SFR et ça va prendre 3 à 4 jours, car il faut migrer circuit par circuit. C'est pas grave, le TB4B et TB4C peuvent prendre tous les appels sortants sans probleme. 6) Nous aurons donc les appels entrants sur le C4A et les appels sortants sur TB4A/TB4B/TB4C Nous n'aurons donc plus de crashs pour les appels sortants puisque tout va partir par les TB4 7) Nous pouvons encore avoir les crashs sur C4A liés au client qui fait les choses catholiques. Et pourque ca n'arrive pas dés Lundi voici la liste des actions: A) On a installé l'anti-ddos qui nous protege contre les attaques DDoS et nettoie tout ce qui n'est pas catholique. B) On a la liste des 30 numeros qui reviennent à chaque de 7 crashs que nous avons eu. Nous allons contacter les 6 clients et on va leur bloquer les input. Ils pourront toujours sortir la voix mais pas se faire appeler. C) On va travailler avec ces clients à partir de la semaine prochaine et uniquement la nuit pour voir s'ils peuvent nous generer les appels et faire crasher l'infra input. D) On active les dump IP sur les IP qui utilisent ces 30 numeros. E) On va upgrade C4A vers la nouvelle version du soft qui permet d'avoir les logs de crashs de PTG. On va le faire cette nuit. Ceci nous permettra d'avoir les infos en cas de crash F) si on n'arrive pas reproduire le bug et tout est stable durant 10J, nous allons bouger une interco sur C4B et durant une matinée dans 2 semaines, nous allons l'utiliser pour sortir le max de voix. Le but sera de faire crasher l'infra C4B et avoir les logs qui permettront de fixer le bug. 8) On prepare les dedomagements pour ces derniers 18 mois qui vont venir sur la facture de mois de Juin. 9) nous allons construire avec Cirpack une infra de test et de qualification de patchs qu'ils nous proposent on veut pouvoir tester 5K appels simu de maniere suivate: SIP-C5X-C4X=e1=TBX-SIP Avec une telle infra de test on pense pouvoir maintenir l'infra en production tout en continuant de fixer les petits bugs par ici et par là. Puis de mettre en place une infra de qualification/stress test de vos infra: - vous configurez un nouveau asterisk - vous voulez faire un stresse test/qualifier votre infra, clic et ca balance les appels in/out - ca va vous permettre de voir si votre asterisk tient la route et nous voir s'il dialogue correctement avec nous samedi, 14 juin 2014, 17:45 > E) On va upgrade C4A vers la nouvelle version du soft > qui permet d'avoir les logs de crashs de PTG. On > va le faire cette nuit. Ceci nous permettra d'avoir > les infos en cas de crash on prevoit la mise à jour vers 21H00. ca va prendre entre 7 à 12 minutes, le temps de rebooter tous les equipements de l'infra C4A samedi, 14 juin 2014, 17:46 > D) On active les dump IP sur les IP qui utilisent > ces 30 numeros. done samedi, 14 juin 2014, 18:13 E) On va upgrade C4A vers la nouvelle version du soft qui permet d'avoir les logs de crashs de PTG. On va le faire cette nuit. Ceci nous permettra d'avoir les infos en cas de crash http://travaux.ovh.net/?do=details&id=10970 preparation pour 21H00 samedi, 14 juin 2014, 23:39 4) sur TB4C on va bouger une interco qui est actuellement connecté sur le C4B. C4B ne sera plus utilisé. done samedi, 14 juin 2014, 23:39 B) On a la liste des 30 numeros qui reviennent à chaque de 7 crashs que nous avons eu. Nous allons contacter les 6 clients et on va leur bloquer les input. Ils pourront toujours sortir la voix mais pas se faire appeler. done samedi, 14 juin 2014, 23:39 E) On va upgrade C4A vers la nouvelle version du soft qui permet d'avoir les logs de crashs de PTG. On va le faire cette nuit. Ceci nous permettra d'avoir les infos en cas de crash done nous avons presque fini la mise a jour des l'infra C4A avec les chassis et toutes les cartes de voix en france et en europe. C4A gere les appels entrants et les numeros courts. est ce que vous pouvez verifier dans differents cas de figure que vous pouvez appeler vos numeros de telephones chez ovh ? merci d'avance. c'est tres importants. samedi, 14 juin 2014, 23:41 3) TB4B est en production avec une interco SFR, dans 1H on va reconfigurer toutes les voix sortantes via cet equipement et on va vous demander de bien valider s'il n'y ait plus de problemes sur les ringback. done tout l'output passe par TB4B. si vous avez 2 minutes pour tester un appel \340 partir de votre telephone vers un n\260 exterieur et confirmer que tout se passe bien dans tous les cas de figure, \347a nous aiderait. merci d'avance

samedi, 14 juin 2014, 12:25 Le nouveau binaire est en place sur les PTG. Celui-ci permet d'avoir un système de statistiques et de remontées plus efficace. samedi, 14 juin 2014, 17:44 Voici la liste des points sur lesquels nous avançons : 1) On finit les migrations de 150 lignes restants MGCP de c4a vers c5a. les telephones ne veulent pas prendre la nouvelle conf (firewall ?) et donc on va bouger l'ip directement En même temps on fait la migration de 1007 sur le c5a. Tous les abonnés c'est à dire les 130K/140K lignes SIP/MGCP seront à 100% sur les 3 infra c5a/c5b/c5c 2) Nous avons un nouveau equipement qui fait le class 4 c'est à dire l'interco avec France Telecom SFR, Completel, DTAG, BT, Belgacom et Telefonica. Il s'agit de TelcoBridges. Il y a 2 mois nous avons passé la commande pour 4 chassis (au lieu de Cirpack) et nous les avons reçu il y a 1 mois. Depuis, nous faisons les tests, ça se passe bien. On a trouvé un bug cette semaine et on a reçu le patch cette nuit. Ceci dit on ne peut pas l'utiliser pour France Telecom, pas encore, il faut qu'on le certifie avec FT et les autres opérateurs historiques en Europe. Ca va prendre qq mois. Mais on peut l'utiliser pour toutes les communications sortantes et les numeros speciaux. Donc, nous avons mis en place 4 nouveaux chassis TB4A, TB4B, TB4C et TB4D. TB4D c'est notre spare. 3) TB4B est en production avec une interco SFR, dans 1H on va reconfigurer toutes les voix sortantes via cet equipement et on va vous demander de bien valider s'il n'y ait plus de problemes sur les ringback. 4) sur TB4C on va bouger une interco qui est actuellement connecté sur le C4B. C4B ne sera plus utilisé. 5) Sur TB4A on va migrer une interco SFR et ça va prendre 3 à 4 jours, car il faut migrer circuit par circuit. C'est pas grave, le TB4B et TB4C peuvent prendre tous les appels sortants sans probleme. 6) Nous aurons donc les appels entrants sur le C4A et les appels sortants sur TB4A/TB4B/TB4C Nous n'aurons donc plus de crashs pour les appels sortants puisque tout va partir par les TB4 7) Nous pouvons encore avoir les crashs sur C4A liés au client qui fait les choses catholiques. Et pourque ca n'arrive pas dés Lundi voici la liste des actions: A) On a installé l'anti-ddos qui nous protege contre les attaques DDoS et nettoie tout ce qui n'est pas catholique. B) On a la liste des 30 numeros qui reviennent à chaque de 7 crashs que nous avons eu. Nous allons contacter les 6 clients et on va leur bloquer les input. Ils pourront toujours sortir la voix mais pas se faire appeler. C) On va travailler avec ces clients à partir de la semaine prochaine et uniquement la nuit pour voir s'ils peuvent nous generer les appels et faire crasher l'infra input. D) On active les dump IP sur les IP qui utilisent ces 30 numeros. E) On va upgrade C4A vers la nouvelle version du soft qui permet d'avoir les logs de crashs de PTG. On va le faire cette nuit. Ceci nous permettra d'avoir les infos en cas de crash F) si on n'arrive pas reproduire le bug et tout est stable durant 10J, nous allons bouger une interco sur C4B et durant une matinée dans 2 semaines, nous allons l'utiliser pour sortir le max de voix. Le but sera de faire crasher l'infra C4B et avoir les logs qui permettront de fixer le bug. 8) On prepare les dedomagements pour ces derniers 18 mois qui vont venir sur la facture de mois de Juin. 9) nous allons construire avec Cirpack une infra de test et de qualification de patchs qu'ils nous proposent on veut pouvoir tester 5K appels simu de maniere suivate: SIP-C5X-C4X=e1=TBX-SIP Avec une telle infra de test on pense pouvoir maintenir l'infra en production tout en continuant de fixer les petits bugs par ici et par là. Puis de mettre en place une infra de qualification/stress test de vos infra: - vous configurez un nouveau asterisk - vous voulez faire un stresse test/qualifier votre infra, clic et ca balance les appels in/out - ca va vous permettre de voir si votre asterisk tient la route et nous voir s'il dialogue correctement avec nous samedi, 14 juin 2014, 17:45 > E) On va upgrade C4A vers la nouvelle version du soft > qui permet d'avoir les logs de crashs de PTG. On > va le faire cette nuit. Ceci nous permettra d'avoir > les infos en cas de crash on prevoit la mise à jour vers 21H00. ca va prendre entre 7 à 12 minutes, le temps de rebooter tous les equipements de l'infra C4A samedi, 14 juin 2014, 17:46 > D) On active les dump IP sur les IP qui utilisent > ces 30 numeros. done samedi, 14 juin 2014, 18:13 E) On va upgrade C4A vers la nouvelle version du soft qui permet d'avoir les logs de crashs de PTG. On va le faire cette nuit. Ceci nous permettra d'avoir les infos en cas de crash http://travaux.ovh.net/?do=details&id=10970 preparation pour 21H00 samedi, 14 juin 2014, 23:39 4) sur TB4C on va bouger une interco qui est actuellement connecté sur le C4B. C4B ne sera plus utilisé. done samedi, 14 juin 2014, 23:39 B) On a la liste des 30 numeros qui reviennent à chaque de 7 crashs que nous avons eu. Nous allons contacter les 6 clients et on va leur bloquer les input. Ils pourront toujours sortir la voix mais pas se faire appeler. done samedi, 14 juin 2014, 23:39 E) On va upgrade C4A vers la nouvelle version du soft qui permet d'avoir les logs de crashs de PTG. On va le faire cette nuit. Ceci nous permettra d'avoir les infos en cas de crash done nous avons presque fini la mise a jour des l'infra C4A avec les chassis et toutes les cartes de voix en france et en europe. C4A gere les appels entrants et les numeros courts. est ce que vous pouvez verifier dans differents cas de figure que vous pouvez appeler vos numeros de telephones chez ovh ? merci d'avance. c'est tres importants. samedi, 14 juin 2014, 23:41 3) TB4B est en production avec une interco SFR, dans 1H on va reconfigurer toutes les voix sortantes via cet equipement et on va vous demander de bien valider s'il n'y ait plus de problemes sur les ringback. done tout l'output passe par TB4B. si vous avez 2 minutes pour tester un appel \340 partir de votre telephone vers un n\260 exterieur et confirmer que tout se passe bien dans tous les cas de figure, \347a nous aiderait. merci d'avance

dimanche, 15 juin 2014, 16:59 Les problèmes de coupure d'appel après une mise en attente sont corrigés pour tous les C5. dimanche, 15 juin 2014, 19:32 Les transferts d'appels sortants sont fixés. Il n'y a plus de problèmes connus en cours. dimanche, 15 juin 2014, 19:37 tous les travaux prevus sont terminés et on attend le 1er pic de Lundi 10H-11H pour valider le bon fonctionnement de l'infra class 4.

lundi, 16 juin 2014, 10:16 Nous avons eu un problème de son haché dû à la latence entre RBX et P19. Nous l'avons fixé. Il reste le problème de "manque de ringtone avec les codecs G729 lors de transfert d'appel sans confirmation" lundi, 16 juin 2014, 10:34 coupure 15 sec, erreur humaine sur une manipulation d'ACL. lundi, 16 juin 2014, 10:49 10h45 Il nous reste 2 problèmes à fixer: - quand on fait un appel sortant et on fait en suite un transfert sur un autre poste, il n'y a pas de ringback (pas de sonnerie d'attente) et on a parfois la communication blanche - quand on fait un appel sortant , parfois on n'a pas de ringback Nous avons réactivé les dumps de tout trafic VoIP et on peut désormais chercher l'origine du problème. lundi, 16 juin 2014, 14:02 à 13h08 nous avons eu un crash d'une PTG sur le C4A (les appels entrants), différent: crash franc du bladectrl au lieu d'un freeze. lundi, 16 juin 2014, 15:51 Nous avons eu plusieurs crashs consécutifs sur le C4A, seuls les appels entrants sont impactés. Les appels sortants fonctionnent sans soucis. Le constructeur dispose de traces complètes sur ces crashs, grâce aux patchs et au câble série mis en place ce week-end. lundi, 16 juin 2014, 18:46 On commence d'avoir les bonnes pistes. Le problème arrive pour certaines redirection de FAX qui essaient de renégocier le T38 de manière très violente. les cartes PTG se prennent un flood de renego et crashent. On vient de désactiver le forcing T38 en output. lundi, 16 juin 2014, 18:54 18H50: on l'a déactivé sur TB4A/B/C donc les FAX en transfert inconditionnel d'un n° OVH vers un n° externe ne fonctionnent plus en attendant qu'on trouve une solution au niveau du cirpack. lundi, 16 juin 2014, 20:39 Résultat de Lundi: Bonjour, Nous avons beaucoup travaillé ce week-end pour éviter les pannes de l'infra pour Lundi. Ce n'est pas un franc succès même s'il y a un mieux. Nous avons 2 bugs sur les appels sortants en transfert sur lesquels on bosse. Le nouveau équipement qu'on a mis ce wk, envoi la capabilité UPDATE alors qu'il ne le gère pas bien. On regarde comment le désactiver. Soit il existe une commande (qu'on n'a pas vu) soit il faudra patcher et rebooter. w8. C'est une boite Canadienne donc ça bosse en ce moment .. Aussi, nous avons eu le bug qui fait planter les cartes PTG, on a eu 6 ou 7 crashs dans l'après midi. Ca a été un peu mieux que la semaine passée car ça n'a impacté que l'input, mais quand même, on a eu ces foutus crashs. Ouais :( Avec les logs et les dumps on a trouvé d'où ça peut venir et on a tout désactivé pour que ça n'arrive plus, vers 18H50, en attendant que Cirpack reproduise le bug et patch leur système. Le problème vient de transfert inconditionnel d'un n° ovh vers un n° extérieur qui fait passer les FAX. La renego T38 est très violente en DTMF entre les infra output et input ce qui provoque un flood interne de packet UDP (100 pps durant 2 à 3 secondes) et ça fait mourir la PTG. Ca fait pas mal de temps qu'on propose ce service et on n'explique pas pourquoi c'est seulement qu'à partir de mercredi qu'il a posé le problème au point de faire tout crasher. Juste hallucinant. On n'a pas tenu la parole qui disait que tout va marcher à partir de Lundi. C'est vrai et je ne peux pas le nier. On sait tous ce que ça veut dire et il n'y a aucune discussion là dessus. Aucune. Même si on a mis le boost ce wk sur la reconfiguration de l'infra et le basculement de pleins d'équipements on regarde les résultats et on avait des impacts aujourd'hui. Moins que la semaine passée mais on en a eu et donc on n'a pas tenu la parole. Echec. Mat. Perdu. Désolé pour les pannes. On a fait le max. Cette nuit et demain, on continue de se battre avec ce foutu bug qui plante la PTG et les 2 bugs sur l'output/transfert. Et on va le fixer de chez fixer. Il n'y a pas d'autres choix d'options et on va mettre toute l'énergie possible pour retrouver la stabilité. On attend le feedback de Cirpack et TelcoBridge pour ces bugs et on espère avoir les réponses qui donnent la banane et pas de nouveaux problèmes. Aussi on prépare une commande chez TelcoBribge pour remplacer le Cirpack sur le Class 4 si on voit qu'il n'y a pas d'espoir de fixer ce bug. Le délai de livraison et de mise en place n'est pas formidable mais ça reste une option qu'on va pas attendre longtemps à jouer. Merci de votre confiance, au moins de ce qu'il en reste. Amicalement Octave

18/06/2014 10h20 une carte PTG a planté et a coupé les appels qu'elle gérait à ce moment là. Ce crash correspond au problème recherché, c'est le seul de la matinée. Cirpack a des logs supplémentaires suite à l'installation des patchs hier, et on leur fourni les traces. Ils n'ont pas encore réussi à reproduire le crash, mais ils ont plusieurs pistes.

Commentaire de OVH - Le problème de redirection d'appel a été identifié et corrigé. Nous avons réussi a reproduire ce problème que vers le réseau Bouygues Telecom. Nous n'avons pas constaté ce problème de renvois d'appel vers les autres opérateurs mobile français. L'origine du problème est un message supplémentaire dans le message de l'appel sur le réseau télécom, nous avons retiré ce message ce qui corrigé le problème.

mercredi, 18 juin 2014, 18:18 Le blocage d'un paquet INVITE trop volumineux par notre VAC (firewall) est corrigé. Il n'est plus nécessaire de réduire la liste des codecs.

mercredi, 18 juin 2014, 20:12 Cirpack a trouvé le "dead packet" qui plante une PTG. Nous avons refait les tests en interne et nous avons réussi à faire planter la PTG de notre lab. Cette nuit nous allons appliquer un patch qui va donner encore + de logs lors du plantage. La maintenance sera effectué à 5h30. jeudi, 19 juin 2014, 05:29 Nous débutons l'intervention : une première PTG va être patchée puis rebootée. Ensuite, nous procéderons de même sur toutes les autres en même temps. L'intervention est estimée à 30 minutes. Une coupure des appels entrants, sortants pour les 08 et portabilité est à prévoir lors des redémarrages. Commentaire de OVH - jeudi, 19 juin 2014, 05:55 Nous procédons au reboot des PTGs restantes. jeudi, 19 juin 2014, 06:06 Les patchs ont été appliqués avec succès. La configuration actuelle est telle que si une PTG venait a redémarrer, celle-ci reprendrait l'ancienne version par sécurité. jeudi, 19 juin 2014, 07:43 Bonjour, Hier, Cirpack a pu créer un packet UDP qui fait planter très très rapidement une carte PTG. Nous avons testé ce packet sur la PTG dans notre lab et ça génère bien le plantage avec exactement le même log d'erreur qu'on a pendant les plantage. Un patch a été fait pour protéger le CPU de la PTG quand un packet comme ça se présente et les détails sur ip/dst afin de le retrouver dans les dumps. Le patch a été mis en place ce matin vers 5h30-5h50 Donc l ne reste plus qu'à attendre pour voir c'est fixé ou il reste encore d'autres packets bizarres à retrouver. Amicalement Octave

Notice: Trying to access array offset on value of type bool in /var/www/clients/client1/web21/web/includes/class.user.php on line 229 Notice: Trying to access array offset on value of type bool in /var/www/clients/client1/web21/web/includes/class.user.php on line 236 Notice: Trying to access array offset on value of type bool in /var/www/clients/client1/web21/web/includes/class.user.php on line 237 Notice: Trying to access array offset on value of type bool in /var/www/clients/client1/web21/web/includes/class.user.php on line 243 Notice: Trying to access array offset on value of type bool in /var/www/clients/client1/web21/web/includes/class.user.php on line 243 Notice: Trying to access array offset on value of type bool in /var/www/clients/client1/web21/web/includes/class.tpl.php on line 185 Notice: Trying to access array offset on value of type bool in /var/www/clients/client1/web21/web/includes/class.tpl.php on line 199 jeudi, 19 juin 2014, 21:39 Bonjour, Le "dead packet" est bien identifié et filtré sur les équipements. Il n'y a plus d'impact de ce packet sur la production depuis ce matin 6h00. Le problème de comm blanche entrant: on a activé le dump pour debugger quelques clients qui l'ont. On regarde pourquoi ca arrive. Il faut ouvrir les tickets standard et on regarde les détails avec chacun d'entre vous. On pense qu'il n'y a pas de rapport mais on est à fond dessus. Les quelques problèmes de fax c'est reglé. On est + flexible sur la nego. Les quelques problèmes de renego de codecs sont en cours de traitement. On force la renego en ce moment et on change la conf pour accepter le 1er codec propos\351 et ne plus le changer ou en proposer un autre. On est actuellement dessus. On attend de la part de TelcoBridge le patch pour gérer les transfert a aveugle qui vont fixer aussi le bug de ringback. La release patchée n'a pas passé tous les tests. Ils sont en train de recoder le patch et repasser dans la quality qualif pour les tests de régressions. On s'approche de la fin ! Amicalement Octave vendredi, 20 juin 2014, 15:54 Bonjour, voici l'état des lieux : on attend un retour cette après-midi de Telcobridges pour la livraison du patch. Ce doit patch doit corriger les problèmes suivants restant sur appels sortants : - pas de ringback tone dans certains cas suivant l'ordre des codecs - transfert d'appel qui coupe l'appel en cours - mise en attente qui coupe l'appel en cours On regarde aussi tout les tickets remontées sur des communications blanches en entrant et en sortant, de suite ou après quelques minutes. Pour ces cas il faut surtout ouvrir des tickets incidents qu'on puisse recouper le maximum d'informations et faire les captures. Merci d'avance pour vos remontées. Coté carte Cirpack le patch fait le boulot et il n'y a plus du tout de crash depuis hier matin 6h00, c'est stable. vendredi, 20 juin 2014, 18:26 Le patch Telcobridges est prêt. Il passe en ce moment les batteries de test de validation de charge et de non-régression. Nous prévoyons l'installation du patch dès réception cette nuit ou dans la nuit de samedi à dimanche. vendredi, 20 juin 2014, 20:11 Nous allons analyser le trafic SIG pour recouper les configurations de codecs avec la configuration personnalisée de chaque ligne. Dans le cas de différence de configuration nous allons adapter cette configuration afin de la rendre compatible avec la configuration du client. Dans le cas d'une incohérence (2 téléphones sur un SIP avec 2 conf différentes) nous allons informer le client de cette situation. Ce problème peut provoquer les comm blanches. samedi, 21 juin 2014, 09:52 Nous avons reçu la nouvelle version du soft pour le TelgoBridge. On va commencer les tests puis on va le mettre en production dans la nuit. samedi, 21 juin 2014, 16:20 Nous avons bloqué le trafic sur une de nos gateway telco pour la mettre à jour. La mise à jour s'est correctement déroulé. Les premiers tests sont ok. La gateway a été remise en service pour bloquer la seconde gateway afin de la mettre à jour également. samedi, 21 juin 2014, 18:07 Les passerelles sont à jours. lundi, 23 juin 2014, 18:54 Bonjour, Avec 1 semaine de retard sur la date promise pour la fin de problèmes sur la VoIP, on va clore le task travaux lié au "dead packet". C'est clairement un cas exceptionnel proche d'un bug 0-day. Probabilité d'avoir ce genre de problème: 1 fois dans une vie. Nous allons donner un peu plus d'information sur le type de packet qui casse les PTG mais dans 1 ou 2 mois, quand les clients de Cirpack auront mis à jour le software. Cette semaine, on va valider les indemnités liées à tous les travaux et pannes qu'on a eu depuis ces derniers 18 mois. Ca ne va pas régénérer de la confiance mais j'aimerais qu'on arrive à dire: il y avait avant et après le juin 2014. La confiance reviendra du temps. Beaucoup de temps. Nous, en tout cas on est là (on l'a prouvé lors de gestion de ce problème) et on sera là demain avec la VoIP et on a une liste de nouveaux services qu'on va déployer dans qq semaines, comme ça. Oui une liste comme ça longe. On va vous fournir une roadmap sur 18 mois avec les services qu'on veut vous proposer. Et on veut y intégrer les services à valeur ajoutée que nos partenaires font avec notre VoIP, directement dans notre commande. On ne voit pas d'autres travaux en vue et on ne voit pas du tout les zones à risques où notre infrastructure nous empêcherait à vous délivrer le service. Cet incident nous a obligé d'avancer tous les travaux qu'on avait programmé pour fin aout. Bon, voilà, là c'est fait, dans la douleur mais c'est fait. Désolé une fois encore pour ce problème et les autres que nous avons eu. Cordialement Octave

Pas de remontée pour le moment, l'incident est pour le moment clos.