Meetme - conférence longue durée

Bonjour à tous,

Je suis actuellement en train de réaliser des essais de conférence et mes essais ne sont pas concluants. (j'utilise asterisk v1.6.0.15, avec dahdi 2.2 sur un serveur équipé d'une carte DIGIUM)

En effet, je réalise une conférence entre plusieurs abonnés SIP. Cette conférence doit fonctionner 24h/24h. Je viens de m'apercevoir que le son dérive dans le temps (environ 2ms toute les 5minutes). Du coup, au bout de quelques heures, la conférence devient inexploitable.
Après quelques heures, lorsqu'un abonné parle dans la conférence, les autres abonnés de cette conférence reçoivent le son après quelques centaines de millisecondes voir quelques secondes (en fct du temps)

Sur mon serveur, j'ai une carte DIGIUM.

Je pensais au départ que cela venait de l'horloge utilisée par dahdi (je n'ai pas réussi à supprimer le problème en modifiant l'horloge système dans lilo.conf => utilisation de hpet par exemple)

de plus, ce phénomène semble aléatoire, de temps en temps (rarement), il n'y a pas de dérive de la conférence ?

La conférence est crée à partir d'invitation de type originate (conférence dynamique gérée par un soft externe). J'ai du coup un doute sur le type de "channel" à utiliser lors d'une mise en conférence des abonnés.

Merci d'avance pour vos commentaires et idées.

Salut,

Déjà je te conseille de mettre à jour dahdi et Asterisk car y a eu pas mal de modification sur tout ça puis de refaire un test.

Merci pour le conseil, mais en faite j'ai déjà réalisé les mises à jour pour essayer (dernière version d'asterisk 1.6.2.x + dahdi 2.4), mais toujours le même phénomène....

hum intéressant, c'est quoi la carte Digium que tu as mis ? J'ai déjà remarqué ce phénomène mais sur des meetme qui tourne dans un KVM par exemple.
Sinon as tu essayé avec ConfBridge dans Asterisk 1.8. Ce module n'utilise plus dahdi pour la synchro. Faudrait creuser un peu.

en passant fait un dahdi_test pour voir ce que cela donne et montre aussi un cat /proc/dahdi/*

Bonjour,
j'ai également testé le confbridge de la version 1.6.2.x et à mon grand étonnement, j'avais exactement le même phénomène... Pour gagner du temps j'ai réalisé une petite manipulation avec un oscillo et un géné bf pour pouvoir mesurer ce délai. Je pensais également qu'en utilisant confbridge je contournerai le problème....
Pour le cat /proc/dahdi/*, je vois que j'utilise une horloge haute précision.
La carte digium utilisée est une TDM400p ou TE122 ( même problème....)

avez vous déjà utilisé meetme sur une longue période ? Et si oui, combien de temps ?
Merci

Pour le dahdi test, je tourne avec des valeurs inférieures à 99,99x
j'ai essayé de changer d'horloge système mais sans réel changement....

As-tu lu cette page?
https://wiki.asterisk.org/wiki/displ...ing+Interfaces
Même remarque, les mises à jour sont utiles, mais apparemment c'est fait.
Si 1.6.2, essaye de désactiver le module timerfd pour forcer l'utilisation du timing fourni par dahdi, on ne sait jamais.

Merci pour les conseils.
Je vais essayer de forcer à travers le menuselect, l'utilisation d'un timer. Jusqu'à présent, je modifiais uniquement le timer au niveau de l'OS mais pas au niveau de la compilation d'asterisk.
De plus après avoir lu : https://wiki.asterisk.org/wiki/displ...ing+Interfaces, je me rends compte qu'une mise à jour de l'OS peut également avoir un impact sur les timers.
Merci pour ces nouvelles pistes, je vous tiens au courant dès que j'aurai réaliser les différents essais.

Bonjour,

Il ne doit pas y avoir de décalage temporel dans une conférence Asterisk si l'horloge est bien dérivée d'une carte Digium (sauf B410P et TC400B).

Si une dérive subsiste, c'est bien l'horloge système (OS) qui est utilisée, ou alors la carte Digium est HS (à priori pas le cas présent, puisque deux cartes différentes donneraient le même résultat) ou son driver non chargé (à vérifier).

Certains utilisateurs d'Asterisk utilisent les B400P/B410P pour cette raison - sans module ligne -, uniquement pour la synchro des conférences et trunks IAX.

Cordialement,
Francois

Citation:

---

Envoyé par F6HQZ

...
si l'horloge est bien dérivée d'une carte Digium (sauf B410P et TC400B).

---

Une b410p gérée par Dahdi (pas misdn) n'est pas capable de fournir un timer ? J'aurai cru le contraire, j'ai pas mal d'installations basées là-dessus, mais en même temps toujours du matériel et un kernel gérant HPET, et en général des conférences peu chargées et utilisées ponctuellement, donc pas de problème :)

Citation:

---

Envoyé par F6HQZ

Certains utilisateurs d'Asterisk utilisent les B400P/B410P pour cette raison - sans module ligne -, uniquement pour la synchro des conférences et trunks IAX.
Cordialement,
Francois

---

Je suppose que tu parle des tdm400p et tdm410p, par curiosité j'avais la question (sur l'ancien forum) du timer si aucun module placé sur la carte, pas eu de réponse à l'époque et pas de carte non-utilisée pour tester, merci pour la réponse :jap:

Savez-vous comment vérifier qu'asterisk utilise bien l'horloge de la carte digium ? Existe-t-il une commande sous asterisk pour vérifier l'horloge utilisée ?

J'ai l'impression que de temps en temps, asterisk utilise la bonne horloge ( pas de dérive de la conférence dans le temps !) ? C'est étrange, cela vient peut-être d'un chargement/déchargement aléatoire du module dahdi?

J'ai constaté également sur la carte digium d'un problème d'écho. Peut-être que le problème est lié, l'annulateur d'écho se base peut-être sur la même horloge ?

Je ne pense pas que l'echo provienne de là, l'anti-echo ne nécessite pas cette horloge dont nous parlons.

Pour l'horloge, si le module dahdi se déchargeait/rechargeait de temps en temps (aucune raison), il y'aurait une trace dans les logs et/ou dans la cli d'Asterisk.

Si vous êtes en 1.6.2, forcez le non-chargement des deux autres modules de timing (pthread et fdtimer) avec des noload => le-module.so dans /etc/asterisk/modules.conf, il ne restera que le module de timing par dahdi.

Ok, je vais également tester cette méthode et vous tiens au courant.
Merci