OVH Community, votre nouvel espace communautaire.

TUTORIEL FREEPBX: détecter perte d'enregistrement SIP et relancer automatiquement


rudddy
13/04/2016, 20h24
Citation Envoyé par laurentm
Quel est le modèle du routeur ? certains sont voip friendly et d'autres pas du tout...

Cela dépend aussi du type de NAT (full cone ou pas), mais ce n'est pas marqué en général sur les docs...
FORTIGATE tout le reste fonctionne nickel que ce soit en sip ou en mgcp

c'est juste cette erreur aléatoire sur les transferts qui pose pb

merci

laurentm
13/04/2016, 19h39
Quel est le modèle du routeur ? certains sont voip friendly et d'autres pas du tout...

Cela dépend aussi du type de NAT (full cone ou pas), mais ce n'est pas marqué en général sur les docs...

rudddy
13/04/2016, 13h52
Citation Envoyé par Uncle Buzz
Il faudrait un autre script mais indépendant de freepbx, car on peut être rejeté si le routeur qui NAT la connexion vers ovh change de port UDP au cours de la session (la durée de vie des sessions udp dépend du routeur, chez moi c'est 30 secondes)
Dsl de déterrer le sujet mais sait-on quelle est la bonne durée ?
Car j'ai 300s et OVH m'indique (je suis pas certain que le tech est compétent) 180s mais j'ai toujours des erreurs

Code:
 2016-03-10 15:10:00 signal_DifferentRegisterInvitePort The invite request does not use the same port as the register. 403 expected - Register port is : '9159' but invite port is '13066'
DIFFERENTREGISTERINVITEPORT:Utilisation de deux ports depuis un même compte Les requêtes envoyées depuis votre télephone arrive depuis deux connexions différentes. Ce type d'anomalie empeche d'emettre ou de recevoir des appels correctement. En effet, OVH autorise l'émission d'appels depuis la même connection enregistrée.
Le délai d'expiration des sessions NAT configuré dans votre routeur doit être trop court pour les connections UDP.
En effet, le port source qui a servi à l'enregistrement du poste (REGISTER) n'est pas le même que celui utilisé pour emettre l'appel (INVITE).
Il est possible que certains appels ne peuvent aboutir correctement du fait de cette configuration.
et également des "IncompleteLegOnInvite" et "ClienterrorOnInvite"

Merci

laurentm
20/02/2014, 21h00
J'ai parfois 24h de tranquillité et d'autres fois je reçois une dizaine de mail envoyé par le script dans l'après-midi !

Pour moi cela semble bien fonctionner avec les appels entrants, puisque je n'utilise plus du tout OVH en sortie.

Uncle Buzz
20/02/2014, 10h26
Au passage, chez moi le script AGI n'est exécuté que lors d'un appel rejeté sur le trunk, si le trunk se désenregistre ou devient "unreachable" sans qu'aucun appel ne soit lancé, alors le script n'est pas exécuté.

Ça permet de rattraper le coup après un échec, mais pas de prévenir les échecs, et pour les appels entrants, comme on est coupé du trunk, on ne voit pas non plus les échecs.

C'est mieux que rien, mais pas suffisant pour surveiller un trunk et éviter les ratés...

laurentm
18/02/2014, 10h58
Le double WAN est un vrai problème... chez mon client qui fait 6000 appels par jour, j'ai réglé définitivement le problème de façon assez radicale :

le routeur 1 est serveur DHCP, il gère le trafic général (tout sauf voip) avec une SDSL 4 paires OVH 13 Mb/s
(c'est un peu loin du DSLAM donc pas les 20 Mb/s potentiels)

le routeur 2 (sur le même LAN) ne sert qu'à FreePbx et est connecté à une SDSL perso OVH à 25 euros ht/mois (sans GTR)
(ce qui est amusant c'est que là j'ai 5 Mb/s car cette paire de cuivre est meilleure que toutes les autres, bien que la distance soit la même du DSLAM)

En plus, je n'ai pas du tout à me préoccuper de QOS, tous mes switches sont en Gigabit ethernet, et j'utilise des fibres optique pour tout ce qui dépasse une trentaine de mètres dans le LAN (les faux-plafonds sont pleins de tubes fluos et de câbles électriques triphasés générateurs de perturbations sinon).

Ailleurs, je n'ai pas trop d'ennuis avec le double wan quand ce n'est pas OVH... j'ai pourtant essayé de forcer les routes sortantes, mais rien n'y fait, il y a toujours certains paquets qui passent par l'autre ip...
L'idéal est d'avoir une fibre Orange (surtout pas Numéricable), on évite la deuxième connexion et on a tellement de débit upload que plus besoin non plus de QOS.

Uncle Buzz
18/02/2014, 10h36
Il faudrait un autre script mais indépendant de freepbx, car on peut être rejeté si le routeur qui NAT la connexion vers ovh change de port UDP au cours de la session (la durée de vie des sessions udp dépend du routeur, chez moi c'est 30 secondes) et cela ne se voit pas via asterisk ou freepbx car c'est seulement lors d'une communication sortante qui se fait rejeté par OVH qu'on s'en aperçoit.

Sinon, en ip dynamique ou sur une connexion multiwan, je ne sais pas si au changmeent d'IP freepbx se désenregistre ou pas, si ce n'est pas le cas, il faut un script pour scanner l'adresse ip publique et lancer un sip reload au changement d'ip (personnellement j'ai un double WAN, et l'un d'eux est en ip dynamique, j'utilise la configuration ip statique que je mets à jour via un script)

laurentm
17/02/2014, 23h52
Le script m'a permis de voir trois coupures chez le même client ce Lundi à 11h56, 13h09, 14h24 !!! Ils sont sur l'infrastructure B d'OVH avec sip.ovh.fr

Par contre, deux autres clients sur l'infrastructure A n'ont pas eu de panne aujourd'hui... Mais un client sur l'infrastructure A a eu une perte d'enregistrement sip.

laurentm
17/02/2014, 23h38
Testé sur FreePbx version 2.9.0.12

1°) Dans l'onglet TRUNK cocher la case "monitor trunk failures" compléter le champ avec le nom du script AGI : alerte.agi (choisi par moi-même)

2°) Créer (avec le gestionnaire de fichiers de Webmin, c'est bien plus facile) le fichier alerte.agi dans /var/lib/asterisk/agi-bin
Le propriétaire de ce fichier est asterisk et le groupe asterisk

edit : ne pas oublier de rendre le fichier exécutable !

3°) Contenu de ce script agi (j'ai commenté le champ IAX car je n'utilise pas d'IAX) :




#!/bin/bash
EMAIL=votremail@votredomaine
DATE=`date`
HOST=`votrenomdhote
/usr/sbin/asterisk -rx "sip reload"
SIPTRUNKS=`/usr/sbin/asterisk -rx "sip show registry"
###IAXTRUNKS=`/usr/sbin/asterisk -rx "iax2 show registry"
MESSAGE="A trunk failure forced a reload on $HOST"
MESSAGE="$MESSAGE\nDate: $DATE"
MESSAGE="$MESSAGE\nCurrent Trunk Status:"
MESSAGE="$MESSAGE\n\nSIP Trunks:\n$SIPTRUNKS"
MESSAGE="$MESSAGE\n\nIAX2 Trunks:\n$IAXTRUNKS"
echo -e "$MESSAGE" | mail -s "Trunk Failure" "$EMAIL"





4°) Ma configuration de trunk

username=003397xxxxxxx
type=peer
secret=xxxxxxx
restrictcid=no
qualify=yes
insecure=port,invite
host=sip.ovh.fr
dtmfmode=inband
disallow=all
context=custom-get-did-ovh
canreinvite=no
allow=alaw&ulaw


Mon champ registration string : 003397xxxxxxx:xxxxxxx@sip.ovh.fr

Rien dans le champ "incoming settings"


5°) Par contre, dans /etc/asterisk/ j'ai un fichier extensions_custom.conf
afin de pouvoir recevoir les appels entrants (car OVH ne semble pas suivre les standards habituels de la voip) qui contient :

[custom-get-did-ovh]
exten => s,1,Goto(from-trunk,${CUT(CUT(SIP_HEADER(To),@,1),:,2)},1)

6°) Dans l'onglet asterisk sip settings de FreePbx j'ai les réglages suivants :

NAT = yes

IP configuration = static IP

External IP = mon adresse ip publique (WAN)

Local Networks = tous mes LAN (y compris ceux des sites distants reliés par VPN IPSEC)

Registrations 20 (timeout) 0 (register attempts)

Registrations times 1800 / 3600 / 1800

Bind address : l'adresse ip interne (LAN) de mon FreePbx

Bind port : 5060

Allow sip guests = yes






Résultat des courses, depuis la mise en place du script AGI (on remarque un souci d'accents pour février
et le contenu du champ status du trunk reste vide (il doit manquer quelque chose dans ma configuration).
Voici le mail que je reçois à chaque fois




A trunk failure forced a reload on
Date: ven. févr. 14 10:46:30 CET 2014
Current Trunk Status:

SIP Trunks:

IAX2 Trunks:




Le trunk se relance bien automatiquement. A priori (mais je n'ai pas vérifié), ça ne coupe donc pas les communications
en cours établies en sortant sur un autre trunk (ce qui est préférable pour ne pas être mal vu par les utilisateurs).
J'ai appelé les numéros entrants sans problème pour vérifier, et je ne tombe pas sur le renvoi vers un portable de secours.