OVH Community, votre nouvel espace communautaire.

perte de registration sip périodiques


atmora
30/12/2013, 17h15
Citation Envoyé par tigrou2409
T as encore des wrong password?
Oui, toujours !

tigrou2409
17/12/2013, 18h34
T as encore des wrong password?

atmora
17/12/2013, 14h25
Vous avez encore des tickets ouverts qui étaient rattaché à l'incident #4820 ?

Car il ont fermé l'incident #4820 sans que je sache ce qu'ils ont fait, mais visiblement ils n'ont pas solutionné le problème, et ils répondent maintenant que l'infra OVH fonctionne très bien, et que sont nos Asterisk qui sont mal paramétrés

Pour info, notre n° de ticket: 1518928

laurentm
11/12/2013, 23h12
Ce qui est étonnant, c'est qu'il n'y a aucun de ces problèmes chez les concurrents d'OVH.

Bien sûr on rencontre d'autres problèmes, comme la perte de qualité avec plus de 15 appels simultanés sur le proxy irlandais d'un opérateur de SIP prépayé asiatique, ou tout simplement des tarifs bien trop gourmands chez d'autres opérateurs français qui veulent rémunérer les revendeurs intermédiaires (à mon sens, ce modèle commercial est totalement dépassé, mieux vaut vendre cher une belle installation une fois pour toute à un client qui va ensuite réaliser de grosses économies et la jouer 'gagnant-gagnant" que de vouloir gratter comme un rat sur les communications qu'il émet).

tigrou2409
11/12/2013, 09h14
Bien sur les dérives des asterisk qui marchent depuis plusieurs années ça vient forcement de la configuration de l'asterisk du client c'est tellement facile de ne pas s'embêter à chercher.

Comme si on laissait 120sec de période d'enregistrement ils nous prennent vraiment pour des truffes.

Genre les asterisk vous nous faites chier on va encore plus vous bloquer avec le firewall, ça c'est constructif comme réponse...

atmora
11/12/2013, 08h54
Citation Envoyé par laurentm
Je soupçonne un chef de projet psycho-rigide qui a pondu ce nouveau et merveilleux firewall-proxy sip et qui ne veut pas admettre que son usine à gaz est une bouse !
Ca semble se confirmer, on vient finalement de me répondre (après 3 mois, sic !) par ce post de la ML:

-----Message d'origine-----
De : simon
Envoyé : mardi 15 octobre 2013 10:19
Objet : [partenaires] Asterisk et bon comportement

Bonjour à tous,


Nous constatons de plus en plus de dérive des asterisk suite à des mauvaises configuration.


Le register d'une ligne permet de notifier au serveur sa présence pour une durée de X secondes. Par défaut, asterisk s'enregistre pour une durée de 120 secondes.
C'est beaucoup trop. La norme préconise un enregistrement toutes les 30 minutes.
soit 1800 secondes. Dans le cas d'un serveur, on peux monter à 1 heure sans problème.


L'option qualify=yes d'un asterisk envoie un paquet OPTIONS toutes les
2
secondes pour vérifier si la machine distante est toujours vivante. 2 secondes, c'est vraiment tres court, mais bon, acceptons.


Par contre, lorsque cette option est configuré sur N comptes, la machine va envoyer N fois toutes les 2 secondes un paquet si la machine est vivante.
De plus, les N requêtes seront identiques, et elles ne monitorent pas les comptes mais le serveur distant.
Dans le cas d'un serveur avec 20 lignes SIP, ca fait 10 paquet/sec pour juste savoir si la machine répond.
Il n'y a pas d'interet de monitorer plus de 1 compte SIP vers le même host.


De notre coté, nous allons durcir les règles de nos firewalls en limitant le nombre de paquet autorisé par seconde. Si la machine distante abuse, elle se fera bannir automatiquement pour une durée limité. L'impact sera limité.


Enfin, une petite information si vous gérez les configurations de vos téléphones ou de vos pabx qui sont derriere un NAT.
Sachez que nous gérons aussi les keepalive. C'est à dire que nous envoyons un paquet toutes les 60 secondes à vos téléphone pour garder les routes NAT des modem/routeurs ouvertes.
Par défaut, un routeur garde ses routes ouvertes durant 180 à 300 secondes.
Donc, pas de soucis, ils peuvent être désactivés au niveau des téléphones.


Amicalement,
Simon
OVH

tigrou2409
24/11/2013, 19h51
+1 pour laurent aussi, ce firewall-proxy sip est une bouse et ça marchait bien mieux avant et un filtrage par IP est déjà une solution suffisante pour les gros consommateurs.
Je bosse avec d'autre fournisseurs j'ai des sessions sip avec eux et on fait ça avec l'ouverture d'ip dans le firewall.

spyman28
23/11/2013, 23h31
slt
je dirais +1 pour laurent et aussi match null
que ca marche comme sur des roulettes ca je suis pour mais que ovh securise sont infra ca je comprends aussi cela dit il n y a pas photo ca traine que ce soit chez ovh ou sont fournisseur d infra(cirteck si je me gourre pas ) (il doivent pas en vendre des 1000 et des 100 des srv de tel comme ca)donc je pence que entre les dev interne et externe et les dev de cirteck il puissent pas trouver un moyen de stabiliser la platforme ( c est pas des mec qui s improvise dev du jour au lendemain (enfin j espere))

laurentm
23/11/2013, 20h36
C'est "comment perdre des clients fidèles" que nous joue OVH depuis le passage à sip.ovh.fr !

Je soupçonne un chef de projet psycho-rigide qui a pondu ce nouveau et merveilleux firewall-proxy sip et qui ne veut pas admettre que son usine à gaz est une bouse !
Comme par exemple pour le grand projet mirobolant de gestion des paies au Ministère de la Défense, qui n'a jamais fonctionné.

Le pire est que ça fonctionnait à la perfection avant... Bien sûr il y avait des risques de piratage, mais il aurait été bien plus astucieux de proposer des connexions VPN IPSEC aux clients qui avaient de grosses cautions, pour sécuriser totalement leurs connexions.

atmora
23/11/2013, 14h17
C'est dingue tout de même qu'OVH ne se bouge pas plus pour résoudre cet énorme bug.
Je suis en support VIP, et c'est "no comment", aucune réponse sur mon ticket depuis des jours.

tigrou2409
22/11/2013, 08h31
ET ben finalement il y a un code erreur coté ovh pour les appels d'1sec.
Et la communication a été coupée au bout de 23min avec le support youpi.....

tigrou2409
21/11/2013, 18h20
Personne n'a eu des appels d'une seconde aujourd'hui?
De vrais appels mais qui on sonné qu'une fois puis raccroché et ensuite la personne a rappelé et ça fonctionne?

atmora
21/11/2013, 13h42
Citation Envoyé par laurentm
C'est quand même fou que cela puisse durer depuis des mois sans résolution du problème !!!
+1000 !

tigrou2409
21/11/2013, 12h41
Ouep j suis d'accord, encore 2 coupures détectées par mes scripts ce matin.

laurentm
20/11/2013, 13h13
C'est quand même fou que cela puisse durer depuis des mois sans résolution du problème !!!

On ne sait pas tout, par exemple, depuis quand ont-ils décidé de se pencher vraiment sur la question, et surtout quel est le niveau de compétence
des gens en charge de solutionner ce problème ?

Je verrais bien les spécialistes de la voip patauger dans ce problème typiquement de firewall. Si chacun reste dans un domaine de compétence hyper-pointu, les problèmes surviennent exactement à la frontière entre le réseau ip et la téléphonie SIP ! Déja vu la même chose dans le monde du broadcast (Jeux Olympiques ou Coupe du Monde) entre les spécialistes vidéo et ceux des Télécoms, c'est toujours la faute de l'autre...

tigrou2409
20/11/2013, 08h46
Espérons que ça finisse par aboutir à quelque chose.

docteurmicro
19/11/2013, 18h38
Oui c'est certain. Malheureusement l'intervention de cette nuit a foiré... ils ont été obligé de faire un retour arrière...

tigrou2409
19/11/2013, 18h28
Au moins ils essayent de s'en occuper je suis déjà bien content, c'était pas gagné à une époque.

docteurmicro
18/11/2013, 16h55
Non justement pas enfin, il est juste précisé : "Nous cherchons à trouver l'origine du problème des 403 wrong login/password qui apparaissent par intermittence"

donc pour l'instant c'est de la recherche... mais c'est déjà ça :-)

tigrou2409
18/11/2013, 16h53
enfinnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

docteurmicro
18/11/2013, 16h33
Pour info, intervention ce soir :

http://travaux.ovh.net/?do=details&id=9714

tigrou2409
18/11/2013, 15h23
nouvelle infra et :
[2013-11-18 15:02:09] WARNING[2457] chan_sip.c: Forbidden
- wrong password on authentication for REGISTER for
'0033972XXXXXX' to 'sip.ovh.fr'

Bien la solution de la nouvelle infra parfaite où les problème n'est plus là...

tigrou2409
18/11/2013, 10h01
C'est aussi le sentiment que j'ai même si sur mon ticket je n'ai pas plus d'infos.
C'était pour gagner du temps car ils m'avaient certifié que c'était un problème résolu sur la nouvelle infra et une solution testée avec d'autres clients pour ce problème.

docteurmicro
18/11/2013, 09h59
Le support m'a annoncé ce matin qu'ils ont le même souci de wrong password sur la nouvelle infra, mais que pour l'instant ils n'ont pas de solution de la part de leur fournisseur...

Je sens que la migration d'infra n'a servi à rien... toujours les mêmes soucis...

tigrou2409
18/11/2013, 09h51
C'est clair, là avec d'autres fournisseurs en sortie pour les fax sip et les appels vers les mobiles et l’international j'ai réussi à calmer un peu le jeu mais ça a été chaud.
Ce n'est pas OVH qui a résolu le problème et encore une fois comme depuis quelques temps maintenant il a fallu se débrouiller seul.

Je continue de surveiller mes remontés de script sur le wrong password...

docteurmicro
15/11/2013, 19h11
Dans tout les cas, ça me rassure vraiment pas vis à vis de mes clients qui sont déjà assez agacés...

tigrou2409
15/11/2013, 18h34
Moi aussi :

[2013-11-15 11:32:53] WARNING[23924] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '0033482XXXXXX' to 'sip.ovh.fr'

Et comme ça impacte sip.ovh.fr et siptrunk.ovh.net je dirai que c'est un problème de firewall chez ovh et pas d'infra ancienne ou nouvelle.

docteurmicro
15/11/2013, 11h34
A nouveau une déconnexion des trunks ce matin malgré le passage sur la nouvelle infra....

[Nov 15 11:02:23] WARNING[29712] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '00339723456XX' to 'sip.ovh.fr'
[Nov 15 11:02:23] WARNING[29712] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '00339724436XX' to 'siptrunk.ovh.net'

tigrou2409
14/11/2013, 07h43
J'ai laissé faire aussi et les DDI sont ok ce matin.

En revanche je ne sais pas si d'autres ont se problème, depuis le plantage d'avant hier soir 18h40 plus moyen de passer un fax en sip via ovh, j'ai du passer par un autre prestataire directement raccordé à FT pour les faire passer de nouveau.

docteurmicro
13/11/2013, 20h49
J'ai laissé faire. Les appels sortants étaient toujours fonctionnels mais j'ai vu qu'il y avait un souci sur les DDI configurés dans le manager quand mes clients ont commencé à se plaindre de ne plus avoir un seul appel entrant...

tigrou2409
13/11/2013, 20h26
t as fait des sip reload sur tous les ipbx un par un pour reconnecter les sip à la nouvelle infra ou t'as laissé faire?

docteurmicro
13/11/2013, 19h02
Par contre la bascule a flingué toutes les redirections DDI de mes clients, et j'ai été obligé de tout reconfigurer dans le manager. D'après le support ils ont trouvé la source du pb et ça n'arrivera plus pour les prochains clients à migrer sur la nouvelle infra...

tigrou2409
13/11/2013, 19h00
ok, je bascule dessus en ce moment.

docteurmicro
13/11/2013, 18h49
Qualité des appels okay (j'utilise g729 exclusivement) et les communications blanches je n'en avais pas avant sur l'ancienne infra et je n'en ai toujours pas maintenant.

tigrou2409
13/11/2013, 18h47
quid de la qualité des appels et des communications blanches?

docteurmicro
13/11/2013, 16h07
Pour ma part plus de pb de "Wrong password" depuis que je suis migré sur la nouvelle infrastructure.

1fopresta.com
13/11/2013, 11h29
Bonjour,
depuis 7J pb de déconnexion du trunk sip au moins 1 fois toute les matinées sur un cisco uc320w.
Il faut rebooter pour corriger le pb.
??

tigrou2409
13/11/2013, 08h14
Pour le coup le problème d'hier soir 18h40 environ était une erreur humaine au moins on sait de quoi ça venait.
C'est l'histoire des wrong password qui est chiante.

Je surveille si j'en ai encore j'ai également un ticket rattaché au bug tracker d'ouvert.

hb22
13/11/2013, 04h00
je constate toujours des erreurs d'authentification
Moi aussi et beaucoup.

De plus hier sur nos 30 Asterisk :
2013-11-12 18:37:52] NOTICE[1426] chan_sip.c: Peer 'O-ovh' is now UNREACHABLE! Last qualify: 5
2013-11-12 18:39:48] NOTICE[1426] chan_sip.c: Peer 'O-ovh' is now Reachable. (6ms / 300ms)
2013-11-12 18:41:49] NOTICE[1426] chan_sip.c: Peer 'O-ovh' is now UNREACHABLE! Last qualify: 9
2013-11-12 18:42:52] NOTICE[1426] chan_sip.c: Peer 'O-ovh' is now Reachable. (5ms / 300ms)
2013-11-12 18:47:52] NOTICE[1426] chan_sip.c: Peer 'O-ovh' is now UNREACHABLE! Last qualify: 7
2013-11-12 18:48:55] NOTICE[1426] chan_sip.c: Peer 'O-ovh' is now Reachable. (14ms / 300ms)
j'en ai marre. C'est décidé, je quitte OVH pour tout. Dédiés et téléphonie.
Il n'y a plus moyen de faire du travail sérieux avec OVH.
L'étude est en cours...

tigrou2409
12/11/2013, 19h20
http://travaux.ovh.com/?do=details&id=9684 je pense aussi pour tes problèmes d'authentification de ce soir.

tigrou2409
12/11/2013, 18h51
c'était quoi encore cette coupure là :
Registration for '0033482xxxxxx@sip.ovh.fr' timed out

sur tous les comptes sip.
ça va fonctionner une jour?

atmora
12/11/2013, 18h43
Fausse alerte, je constate toujours des erreurs d'authentification

tigrou2409
12/11/2013, 18h25
Le bug est corrigé?

atmora
12/11/2013, 17h53
J'ai eu un retour d'OVH sur mon ticket comme quoi le problème serait réglé.
Je surveille ça...

hb22
12/11/2013, 11h12
2013-11-12 10:55:52] WARNING[1670] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '003397232XXXX' to 'sip.ovh.fr'

Un de plus...

C'est toujours quand il y a des pics de trafic chez OVH.
Jamais avant 8h00 du matin.
Jamais le soir après 18h.
J'ai pourtant du trafic sur certains Asterisk la nuit et le weekend mais jamais de problème dans ces périodes.

Je vais essayer de les faire se bouger...

tigrou2409
06/11/2013, 16h38
C'est plus court que le mien lol....

atmora
06/11/2013, 16h36
Citation Envoyé par docteurmicro
Tu lances quoi exactement comme commande dans ta tache cron?
Perso j'utilise ça en cron toutes les 2mn :
Code:
#
# Verification de l'enregistrement des comptes SIP OVH
# et alerte email en cas de coupure
#
/usr/sbin/asterisk -rx 'sip show registry'>/tmp/sip.txt
cat /tmp/sip.txt | grep 'No Authentication'>/tmp/sip_noauth.txt
if [ -s /tmp/sip_noauth.txt ]
then
echo Certains Trunks ne sont pas enregistres
echo Envoi d un email d alerte et lancement d un reload
mailsend -smtp smtp.xxxxxxxxxxx -t xxxx@xxxxxxxx -f ipbx@local -sub "IPBX: trunks SIP en erreur"
Mais ce serait vraiment bien qu'OVH prenne conscience du problème et le règle....

tigrou2409
06/11/2013, 16h34
j'ai un script php qui va chercher sip show registry, qui l'explose pour trouver l'état du trunk et ensuite j'ai une action en fonction de chaque résultat.
tout ça dans une tâche cron qui s’exécute chaque minute sur chaque ipbx.

docteurmicro
06/11/2013, 16h14
Je vérifierai la prochaine fois...

Merci pour tes conseils.

tigrou2409
06/11/2013, 16h12
et avec un sip show registry?

docteurmicro
06/11/2013, 16h09
ok, moi le souci c'est que quand le souci appariait, le trunk est encore vu connecté lorsque je fais un "sip show peers"...

tigrou2409
06/11/2013, 16h08
- test etat du trunk sip
- si trunk deconnecte :
-> Mail d'alerte explicite pour identifier l'ipbx concerné.
-> Et là je vais rajouter /etc/init.d/asterisk reload car j'ai remarqué que dans ce cas ça reconnecte le trunk.

docteurmicro
06/11/2013, 14h46
Tu lances quoi exactement comme commande dans ta tache cron?

Merci.

tigrou2409
06/11/2013, 10h36
Encore 2 fois à 10h30 ce matin.
Ticket incident complété mais ça commence à être fatiguant de devoir aller plus vite que le client pour qu'il ne s'en aperçoive pas.

tigrou2409
06/11/2013, 09h45
La seule façon de faire c'est une tâche cron avec une périodicité courte pour te prévenir quand ça arrive et sur quel ipbx ça arrive.

Mais moi ça commence aussi à m'embêter vraiment cette histoire et je n'arrive pas à avoir plus d'informations sur une éventuelle résolution.
ça marchait bien avant qu'est ce qui a changé?

docteurmicro
06/11/2013, 09h08
Idem sur mon infrastructure de téléphonie.... et mes clients commencent à avoir de moins en moins de patience...

tigrou2409
06/11/2013, 08h43
Moi j'ai ça après le wrong password :
[2013-11-04 14:42:27] WARNING[23924] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '0033482xxxxxx' to 'sip.ovh.fr'
[2013-11-04 14:43:02] WARNING[23924] chan_sip.c: Received response: "Forbidden" from '"04280xxxxxx" ;tag=as4b8382a9'

laurentm
05/11/2013, 14h42
RAS LE BOL DES PANNES OVH SUR ASTERISK !!!

RIEN N'AVANCE DEPUIS DES MOIS !!!


[Nov 5 11:05:14] VERBOSE[17665] netsock.c: == Using SIP RTP CoS mark 5
[Nov 5 11:05:14] VERBOSE[17665] app_dial.c: -- Called fixes-ovh/0688****44
[Nov 5 11:05:14] WARNING[1911] chan_sip.c: Received response: "Forbidden" from '"0184******" ;tag=as68aa58fa'

tomtomgo
04/11/2013, 20h22
Même tarif pour moi coupure a 11:39:21 par wrong password.
J'ai ouvert un ticket jeudi dernier mais il n'a pas encore été traité

tigrou2409
04/11/2013, 12h16
2 coupures de trunk sip ce matin avec l'erreur wrong password....
Bizarrement en heure ouvré avec de la charge.

Ouep c'est moyen tout ça et pourtant ça marchait bien il n'y a pas si longtemps.

laurentm
04/11/2013, 11h57
En SDSL OVH est au top. En hébergement et Housing ça roule.

En téléphonie c'est le fiasco technologique.

Je ne parle pas des serveurs mails Exchange toujours en carafe avec un filer
car la technologie Microsoft est moisie et on ne peut pas en vouloir à OVH,
puisque les clients réclament du Exchange au lieu de préférer du Postfix + imap cent mille fois plus fiable et plus léger ...

laurentm
04/11/2013, 11h55
Les équipements ne semblent plus à la hauteur. A OVH de s'énerver vis à vis des fournisseurs et, peut-être, de changer de matériel.

tigrou2409
04/11/2013, 08h00
J'avais dit dès le départ que wrong password sur un enregistrement avec un password correct avait surement pour origine une surcharge à certains moments.

Surtout que comme tu le soulignes, les périodes moins chargées, ça ne se produit pas ou peu....

Idem pas de réponse depuis le rattachement au bug tracker...

hb22
04/11/2013, 03h20
Le problème est survenu moins souvent depuis ces 15 derniers jours.
Les vacances ?
Donc moins de trafic.

Je trouve quand même le problème sur certains Asterisk.

2013-10-29 17:32:05] WARNING[1745] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '003397242XXXX' to 'sip.ovh.fr'
2013-10-29 17:32:05] WARNING[1745] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '003397242XXXX' to 'sip.ovh.fr'

Mon ticket a aussi été rattaché à l'incident générique SIP #4820 le 25/10 et depuis plus de nouvelles.

"nous avons identifié un souci de micro-congestion au
niveau de l'un de nos équipements. Nous avons ouvert un
incident auprès de notre fournisseur d'infrastructure
Thomson. J'ai attaché votre ticket à cette tâche. Nous
vous préviendrons de manière automatique lorsqu'un
correctif sera en place."

L'équipement OVH est un Cirpack. Mais je crois que cette société n'est pas au mieux de sa forme...
http://www.bfmtv.com/economie/teleph...in-502436.html

tigrou2409
30/10/2013, 16h11
Idem :

Votre ticket a ete attache a l'incident numero #4820.
pb aleatoire de connexion via un client Sip Asterisk
Nous vous informerons prochainement sur la resolution de
l'incident.

3 coupures aujourd'hui, merci cron pour les détecter rapidement mais ça ne peut pas durer.

atmora
30/10/2013, 15h45
De mon coté, mon ticket a été rattaché à "l'incident numéro #4820 pb aléatoire de connexion via un client Sip Asterisk"...

tigrou2409
30/10/2013, 15h28
j'en suis à 3 rien qu'aujourdhui

tigrou2409
30/10/2013, 08h17
Pour que ça aide il faut l'envoyer sur un ticket incident rattaché au bug tracker interne avec le numéro de la ligne en totalité.

tomtomgo
29/10/2013, 21h18
Salut,
aujourdhui j'ai eu la mienne toujours dans l'apres midi.
[Oct 29 16:52:27] WARNING[926] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '0033482xxxxxx' to 'sip.ovh.fr'

Toujours le même problème !

Si ca peut aider !

tigrou2409
29/10/2013, 10h33
Alors voilà des nouvelles, le ticket que j'ai ouvert avec Louis à ce sujet et maintenant rattaché à un OVH Bug Tracker.
Donc c'est un bug suivi en internet qui sera apparemment corrigé.

Je n'ai pas d'infos sur le pourquoi du comment du bug.

tigrou2409
25/10/2013, 09h17
Apparemment aucun rapport entre les nouveaux réglages appliqués aujourd'hui et ce problème.

tigrou2409
25/10/2013, 08h45
Exact, je fais comme toi, j'ai 2 autres fournisseurs pour les appels sortants et je ne peux pas faire de porta avec eux.
La sécurisation avec les autres fournisseurs se fait par IP sans authentification et firewall.
Donc quand le trunk sip ovh coupe ça coupe les appels entrants et c'est pénible car en plus le message pour l'appelant est que le numéro n'est pas attribué.
Je vais mettre les renvois sur portables en cas de défaillance du trunk sip également.
Je viens de voir que ovh a mis à jour sa tâche travaux http://travaux.ovh.com/?do=details&id=9542 aujourd'hui avec une mise à jour de configuration...
J'ai demandé à Louis si ça avait un lien avec nos problèmes mais je n'ai pas encore de réponse.

laurentm
25/10/2013, 08h39
Oui, il me semble évident que les ennuis ont commencé avec la migration de sip.ovh.net vers sip.ovh.fr . Si la sécurisation est aussi tordue que les différentes versions du Manager OVH, cela expliquerait bien des choses.
J'ai un autre opérateur (étranger et en pré-payé) qui m'offre le choix entre login + password ou tout simplement mon adresse ip pour m'authentifier. Cela me va très bien.

Le problème, pour moi, vient des appels entrants. Au bout de trois ans, j'ai eu confiance en OVH et ai supprimé tous les abonnements numéris de mes clients et porté leurs numéros chez OVH (ce que je ne peux pas faire chez un fournisseur étranger) et, à chaque plantage de l'enregistrement SIP, les appels entrants n'aboutissent plus (dans mon cas je les dévie vers un GSM).
C'est tolérable une fois ou deux par an, mais trois par mois (et parfois trois fois par jour ou par semaine) ce ne l'est pas du tout !
Il faut donc plus de sérieux et réactivité de la part d'OVH si ils veulent conserver des pros dans leurs clients.

tomtomgo
24/10/2013, 20h44
Pas de problème pour moi depuis non plus.
Mais je suis d'accord sur le fait que sur les montées de charge OVH lache les asterisk.
Pour moi OVH veut sursecurisé ses serveurs.

tigrou2409
24/10/2013, 14h22
Je continue de compléter mon ticket quand je constate des logs remontés par les tâches cron sur mes serveurs.
Je n'ai pas plus d'infos si ce n'est que Louis me dit qu'il a identifié le problème, j'attends plus d'infos.

Cette aprem je gère une autre problématique, la mise en place de regex fail2ban pour asterisk en cas de défaillance de firewall sur les ipbx...

laurentm
24/10/2013, 13h53
tiens nous au courant de la solution...

C'est exact que le problème SIP OVH semble toucher seulement Asterisk,
mais le fait que l'on n'ait pas ces ennuis avec les autres opérateurs prouve
qu'OVH a bricolé à sa sauce le protocole SIP, ce qui n'est pas génial techniquement.

tigrou2409
24/10/2013, 09h06
Apparemment, via un ticket que j'ai ouvert aussi, Louis se rapproche de la solution et aurait détecté l'origine du problème....

hb22
24/10/2013, 04h19
Bonjour,

Sur les 30 Asterisk que nous gérons, les derniers problèmes remontent au 18/10.

2013-10-17 15:22:07] WARNING[1359] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '00339724XXXX' to 'sip.ovh.fr'
2013-10-17 15:22:07] WARNING[1359] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '00339724XXXX' to 'sip.ovh.fr'
2013-10-18 12:14:36] WARNING[1359] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '00339724XXXX' to 'sip.ovh.fr'
2013-10-18 12:14:36] WARNING[1359] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '00339724XXXX' to 'sip.ovh.fr'
2013-10-18 16:57:15] VERBOSE[3741] chan_sip.c: -- Got SIP response 480 "Temporarily Not Available" back from 91.121.129.20:5060

OVH ne maitrise pas bien sont infrastructure VOIP.
Dès que la charge est importante tout le monde se retrouve avec des problèmes. Les problèmes sont toujours concentrés dans les périodes de fortes affluences téléphoniques. Je n'ai jamais eu ces messages la nuit ou le weekend. J'ai ouvert plusieurs ticket et OVH a toujours accusé les Asterisk. Pourtant sur ces Asterisk, j'ai des trunk vers d'autres opérateurs ou je n'ai jamais ce type de problème. L'avantage d'OVH est le prix.
Pas chère mais pas stable.

tigrou2409
23/10/2013, 08h07
Citation Envoyé par laurentm
Ca continue aujourd'hui...
T'as un log sur un de tes asterisk dans l'apres midi?

laurentm
22/10/2013, 18h09
Ca continue aujourd'hui...

tigrou2409
22/10/2013, 08h06
Si tu m'envois en message prive ton message d erreur avec la ligne je l'ajoute à mon ticket incident actuellement ouvert avec Louis d'OVH sur le sujet.

On chercher depuis plusieurs jours et il a une plateforme d'essai et apparemment il aurait reproduit le problème une fois dessus.

Mais plus il y a de messages dans le ticket et plus on aura des chances qu'ils cherchent plus.

tomtomgo
21/10/2013, 21h54
Bonjour,

je prends le fil en route mais en cherchant des réponses a mon problème je tombe sur ce post.

J'ai exactement le même problème que vous a savoir :

[Oct 21 10:32:16] WARNING[942] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '003348xxxxxx' to 'sip.ovh.fr'

C'est tout a fait periodique mais la période est difficile a determinée

Cela fait un moment que je tourne avec defaultexpiry = 3600 mais j'ai toujours ces mêmes pertes d'authentifications.

Je suis donc très intéressé aussi par une solution ( autre que crontab )

Merci

laurentm
18/10/2013, 10h41
qu'en est il du outbound proxy avec Asterisk ? est ce qu'il solutionne les problèmes ? ou bien a des inconvénients parfois cités, comme un retard pour envoyer la numérotation ?

tigrou2409
16/10/2013, 08h57
J'ai un ticket ouvert à ce sujet et ovh m'a contacté hier par tel, ils supervisent mes lignes 24h et on fait le point ce soir.

laurentm
12/10/2013, 13h06
pour FreePbx, j'ai un peu l'impression que le problème survient sur certaines versions plus que sur d'autres, mais en même temps, il est possible que tous les clients OVH ne soient pas sur les mêmes versions d'équipements Cirpack...

Comme une grande majorité des clients OVH utilisent des téléphones ip (et pas d'ipbx) et ne rencontrent pas ces ennuis, on a peu de chance qu'OVH se penche sérieusement sur la question.

hb22
12/10/2013, 04h29
j'ai compté, j'ai 28 IPBX avec trunk OVH et aucun problème ce jour.
Comme j'ai installé un crontab avec un "sip reload" automatique, notre supervision Zabbix ne nous renvoie plus le problème. J'ai été au hasard sur certains IPBX et j'ai trouvé cela :
Thu Oct 10 15:35:01 CEST 2013
Host dnsmgr Username Refresh State Reg.Time
sip.ovh.fr:5060 N 00339724XXXX 1785 No Authentication Thu, 10 Oct 2013 15:02:13
sip.ovh.fr:5060 N 00339724XXXX 1785 No Authentication Thu, 10 Oct 2013 15:02:13
Donc, le problème est toujours présent.

laurentm
11/10/2013, 17h51
Ca recommence depuis quelques jours les pertes d'enregistrement SIP, et après redémarrage d'Asterisk (FreePbx) tout refonctionne... j'ai un pbx par jour qui perd l'enregistrement SIP, mais pas les autres. Je sens qu'il y a eu des modifs chez OVH dont on n'a pas été informé, sinon comment expliquer que cela fonctionne pendant 1 an et que, du jour au lendemain, il y ait des plantages sans aucune modification de l'installation client ???

hb22
10/10/2013, 18h35
j'ai compté, j'ai 28 IPBX avec trunk OVH et aucun problème ce jour.

atmora
10/10/2013, 17h38
Citation Envoyé par atmora
Désolé pour ceux chez qui ça ne fonctionne pas, mais pour nous ça a l'air bon.
Bon, je retire ce que j'ai dit, on en a encore eu des
Forbidden - wrong password on authentication for REGISTER for 'xxxx' to 'sip.ovh.fr'

On est donc bien dans le même bateau...

hb22
08/10/2013, 17h39
Pile au même moment !!!
[Oct 8 10:22:21] WARNING[1621] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '003328552xxxx' to 'sip.ovh.fr'
Bizarre,bizarre...
Non, il y a une heure de différence.
A moins que ton Asterisk ne soit pas à l'heure.

hb22
08/10/2013, 17h16
Deux autres problèmes sur deux Asterisk différents :

2013-10-08 14:51:45] WARNING[1319] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '003397240XXXX' to 'sip.ovh.fr'


2013-10-08 15:22:09] WARNING[1384] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '003397243XXXX' to 'sip.ovh.fr'

oxiwan
08/10/2013, 15h58
Pile au même moment !!!

[Oct 8 10:22:21] WARNING[1621] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '003328552xxxx' to 'sip.ovh.fr'
Bizarre,bizarre...

hb22
08/10/2013, 14h02
Eh bien mois aussi :

Code:
2013-10-08 11:22:07] WARNING[1359] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '003397242XXXX' to 'sip.ovh.fr'
2013-10-08 11:22:07] WARNING[1359] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '003397242XXXX' to 'sip.ovh.fr'
Deux trunk sur le même Asterisk et problème sur les deux en même temps !!!

oxiwan
08/10/2013, 12h20
En théorie peut être, mais en pratique je viens juste d'en faire un a nouveau sur un site bloqué.

hb22
08/10/2013, 04h50
Réponse d'OVH lundi 07/10 à 15h :
"Nous avons mis à jour notre serveur pour les configurations sous Asterisk. Vous ne devriez plus avoir à faire de Sip Reload en théorie."

atmora
04/10/2013, 13h44
Bon, ça fait 48h que l'on a fait les réglages suivants:
defaultexpiry=1800
maxexpiry=3600
minexpiry=1800

Et plus de désenregistrement depuis

Désolé pour ceux chez qui ça ne fonctionne pas, mais pour nous ça a l'air bon.

Gaston_Phone
03/10/2013, 13h40
Citation Envoyé par atmora
Sur ce sujet, OVH ne semble tout de même pas au mieux du respect des standards et bonnes pratiques, malgré l'argument bateau "ça marche avec un SoftPhone".
Hum! Hum! Quand il y a un problème dans une chaine on isole les différents éléments de la chaine pour trouver le maillon défaillant.

Donc le test avec un softphone permet, à priori, de qualifier les tronçons :
  • Modem,
  • OVH.


Maintenant tu dis que tes "trunks SIP fonctionnent avec les autres opérateurs" donc ton "Asterisk" a l'air correct.

Donc le problème se situe dans les protocoles échangés entre ton Trunk et OVH ainsi que dans les réglages de configuration de l'un et de l'autre.

Il te reste à faire une recherche pour voir si d'autres utilisateurs avec le même contexte ont des problèmes.

sim@ovh.net
03/10/2013, 11h32
Citation Envoyé par Gaston_Phone
Pour les deux cas, le mets le réglage "Réenregistrer toutes les 60 secondes".
Je regarde à ce problème.

Plus la valeur d'enregistrement est grande, moins il y a de chance de rencontrer de type de soucis.

Par contre, 60 secondes de réenregistrement est un mauvais paramétrage.
La valeur recommandé est 1800 s. Le mieux est 3600 secondes.

La valeur par défaut sur asterisk est 120 secondes :/ Je ne pense pas qu'un serveur change d'ip toutes les 120 secondes.
Le mieux pour ce type de pabx est de mettre aussi 3600 secondes.

dans le fichier sip.conf :
defaultexpiry=3600

atmora
03/10/2013, 11h03
Citation Envoyé par Gaston_Phone
Donc c'est un problème sur ton installation. Bon courage.
Heu... on dirait un peu une réponse du support

D'ailleurs le support IPBX me répond: mes trunks SIP fonctionnent avec les autres opérateurs, pas avec OVH, donc c'est un problème OVH.

La question n'est pas de dire "c'est à cause de ton install" ou "c'est à cause d'OVH" mais qu'est-ce qui fait que ce n'est pas interopérable.
Sur ce sujet, OVH ne semble tout de même pas au mieux du respect des standards et bonnes pratiques, malgré l'argument bateau "ça marche avec un SoftPhone".

Gaston_Phone
01/10/2013, 11h58
Citation Envoyé par atmora
Cela fonctionne certainement avec un SipPhone.
Donc c'est un problème sur ton installation. Bon courage.

atmora
01/10/2013, 10h01
Citation Envoyé par Gaston_Phone
Je me demande si tu ne pourrais pas faire l'essai avec une ligne SIP directement connectée à OVH (pas de passage par pabx ni de trunck).
Ligne à configurer sur un softphone.
Ex. SIP, Zoiper PORTABLE et OVH.
Cela fonctionne certainement avec un SipPhone.

Nous avons pu avancer sur le diagnostic du problème:
La valeur du paramètre Asterisk defaultexpiry est par défaut à 120 secondes, alors que le support OVH préconise 1800 ou 3600 secondes.
Cela génère de nombreuses requêtes "Register" auprès du serveur OVH. Au bout d'un certain nombre, il fini par donner un retour "401 unauthoriszed" puis "403 forbidden", en raison des protections anti-flood.

On va essayer de monter le defaultexpity à 1800.
Ce serait bien tout de même de l'indiquer dans les guides OVH !

Gaston_Phone
22/07/2013, 09h12
Je me demande si tu ne pourrais pas faire l'essai avec une ligne SIP directement connectée à OVH (pas de passage par pabx ni de trunck).
Ligne à configurer sur un softphone.
Ex. SIP, Zoiper PORTABLE et OVH.

atmora
22/07/2013, 09h04
Bonjour,

Je suis confronté exactement au même problème (depuis +/- 2 mois):
IPBX Elastix, perte régulière des enregistrements SIP (no authentification), avec dans les logs "Forbidden - wrong password on authentication for REGISTER for 'xxxxxxxxxxxxxx' to 'sip.ovh.fr'"
Je pensais à des problèmes réseau, mais même après avoir dédié une SDSL OVH à l'IPBX et monitoré que le lien était ok, le phénomène reste inchangé.

J'ai également contourné le problème par un reload périodique, mais je vais ouvrir un ticket !

tanguyd
11/06/2013, 10h12
J'ai le même problème, je me retrouve de temps en temps avec un "wrong password" sur un trunk puis il ne cherche plus à s’authentifier a nouveau.

Pour moi la dernière fois c'est le 18 mars 2013, j'ai constaté le pb fin 2011. Voici ma méthode sale pour contourner

J'ai ce script toute les 10 minutes en contab, il fait un sip reload si un trunk est non authentifié, ça ne coupe pas les communications en cours, ça fait juste un peu de logs.

Attention cependant, si tu a réellement un mot de passe KO, le reload complet est fait toute les 10 minutes.

Code:
#!/bin/sh
# verifie si un trunk est bloqué

LOG=/var/log/sip_reload.txt
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

asterisk -rx "sip show registry" | grep "No Authentication"  > /dev/null

if [ $? = 0 ] ; then
	date >> $LOG
	asterisk -rx "sip show registry" >> $LOG	
	asterisk -rx "sip reload"
	asterisk -rx "sip show registry" >> $LOG
	
	echo "######" >> $LOG
fi

Si quelqu'un a une méthode propre, je suis preneur :-)

Gaston_Phone
10/06/2013, 23h15
Bonjour Laurent.

Je n'ai pas de pabx ni de trunck. Je n'utilise que :
  • Chez moi : des Softphones (Bria, Zoiper, CSIP Simple)
  • Chez mes clients : Des C470IP de OVH


Pour les deux cas, le mets le réglage "Réenregistrer toutes les 60 secondes".

Si cela peut aider!

Je me demande si tu ne pourrais pas faire l'essai avec une ligne SIP directement connectée à OVH (pas de passage par pabx ni de trunck).
Ligne à configurer sur un softphone.
Ex. SIP, Zoiper PORTABLE et OVH.

laurentm
10/06/2013, 22h32
De temps à autre, je suis obligé de désactiver puis réactiver un trunk sur mes FreePbx pour retrouver la registration de mes comptes sip.

Qu'on ne me dise pas que cela vient de mes connexions internet, ce soir cela concerne mon pabx qui tourne sur une machine virtuelle XenServer en housing dans le datacenter OVH de Paris XIX° et qui dispose donc d'une vraie connexion gigabit vers l'internet.

C'est ennuyeux et curieux, et cela fait quelques mois que ce problème est apparu. Je finis par préférer les vraies grosses pannes franches plus simples à diagnostiquer.