Meetme - conférence longue durée

[seb29]

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.

[quintana]

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.

[seb29]

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....

[quintana]

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.

[quintana]

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

[seb29]

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

[seb29]

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....

[ffossard]

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.

[seb29]

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.

[F6HQZ]

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