Normalement ça doit fonctionner, est ce que vous avez des valeurs qui sont ajoutés dans sipregs ? Il est possible que structure de table est ancienne, et que dans 1.8 ça à changé.
Normalement ça doit fonctionner, est ce que vous avez des valeurs qui sont ajoutés dans sipregs ? Il est possible que structure de table est ancienne, et que dans 1.8 ça à changé.
Comment ça "qui sont ajoutés dans sipregs" ? Ne suis-je pas supposé les insérer moi-même ? Ce que je ne comprends pas c'est comment Asterisk peut-il ajouter le peer "immédiatement" s'il ne surveille pas la base SQL ? Il aurait fallu pour cela mettre des TRIGGER dans MySQL.
Concernant la structure, je n'ai aucune erreur, et j'ai utilisé le paramètre "requirements=createclose" dan sip.conf pour créer/modifier les champs manquants.
Le wiki dit que:
https://wiki.asterisk.org/wiki/displ...+Configuration
Je suppose il sauvegarde aussi l’état d'enregistrement, par exemple "Trying"If you specify a separate family called "sipregs" SIP registration data will be stored in that table and not in the "sippeers" table.
Dans ce cas si j'ai bien saisi vous pouvez tout stocker dans sippeers, et sipregs est en option, la structure que vous avez utilisé est suivante ?
https://wiki.asterisk.org/wiki/displ...able+structure
sippeers fonctionne très bien, mais il est utilisé uniquement lorsqu'un appel entrant arrive, c'est à dire que Asterisk accède et lit la base SQL pour voir son contenu qu'à ce moment là. Lorsque l'on fait un "register => user:pass@foobar.Com" (fichier plat), l'enregistrement du peer se fait immédiatement (en plus d'être enregistré dans la table visible par "sip show registry".
Je n'ai pas du tout ce comportement avec l'utilisation d'un base SQL+ Realtime:
- À aucun moment, je n'ai quoi que ce soit dans le sip show registry, et je peux affirmer qu'il n'y a rien parce que l'Asterisk distant ne reçoit pas de connexion.
- Aucun évènement n'arrive dans l'Asterisk (même avec un "core set verbose 9999") quand j'insère une nouvelle ligne dans la base SQL dans la table sipregs, ce qui, pour moi, est normal vu qu'Asterisk ne surveille pas les changements dans la base, mais qui est anormal vu le comportement supposé équivalent avec "register => ..."
Ça fait un moment que j'ai touché au realtime.
Regarde si sipregs fonctionne encore sur le bugtracker de digium, ils ont une tendance de la casser temp en temps.
Bonjour,
Avez vous trouvé une solution a cette question? J'ai exactement le même problème sous asterisk 1.8
Bonjour,
avez vous résolu le probléme? Ou trouve ton les tables spécifique pour la version 1.8?