El Miércoles, 2 de Enero de 2008, Julian J. M. escribió:
Asterisk mantiene en memoria una lista (enlazada) de
los peers
conocidos. Hay un thread que ejecuta la función do_monitor(), y que,
entre otras cosas, comprueba periódicamente si esos peers tienen
mensajes de voz. Si la información cambia de una iteración a otra,
envía un NOTIFY (Event: message-summary) con el dato.
Cada iteración comprueba un peer. No se cuántas iteraciones por
segundo hace ese bucle for, pero si tenemos 10.000 peers en memoria, a
25 peers/sec (por poner un número), da una latencia en la comprobación
de 400 segundos. De cualquier modo, esta comprobación se hace
principalmente buscando modificaciones externas del buzón. Cuando
alguien, usando la aplicación Voicemail, te deja un mensaje de voz, o
borras algún mensaje desde VoicemailMain, se notifica inmediatamente.
Así que, sin poner datos empíricos sobre la mesa, yo apostaría a que
se puede gestionar sin apuros ese volumen de buzones de correo.
Lo malo es que, como decía en otro correo de este hilo, usando RealTime la
lista en memoria de peers está vacía al arrancar Asterisk, y éste sólo va
añadiendo peers a dicha lista cuando recibe un INVITE o REGISTER de alguno de
esos peers y debe hacer una consulta SQL a la tabla del Realtime. En ese
momento añade el peer a la lista interna.
En mi caso, no tengo usuarios registrados en Asterisk, no se registran en él
sino en OpenSer, así que no llega ningún REGISTER y cada peer sólo se añade a
la lista cuando envía un INVITE a Asterisk (para consultar su buzón por
ejemplo).
Es decir, que me tendré que currar algún script con sipsak o similares que
recorra la tabla de usuarios y envíe un OPTIONS o INVITE a Asterisk al
arrancar, para que todos los usuarios se añadan a la lista interna.
Gracias Julián por los datos casi casi empíricos ;)
--
Iñaki Baz Castillo