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 ;)