Hola, trato de habilitar el MWI en Asterisk para usuarios multidominio de OpenSer. He probado prácticamente todo lo que he leído sobre el tema.
Ahora mismo tengo los usuarios SIP de Asterisk en RealTime con ODBC buscando en una vista de la tabla "subscriber".
La conexión BD funciona perfectamente desde Asterisk. Tengo el "rtcachefriends=yes" por lo que si Asterisk recibe un REGISTER, lo comprueba en la tabla y luego lo añade a su lista "interna" (vamos, que aparece en "sip show peers").
Pero claro, la cosa es que Asterisk **no** va a recibir ningún REGISTER, aunque como me estoy volviendo loco de probar cosas se me estaba ocurriendo usar "t_replicate" cuando llega un REGISTER a OpenSer, pero... no es necesario **en absoluto**, ¿verdad?
- Entonces resulta que **nunca** voy a ver los usuarios de OpenSer al hacer un "sip show peers" ya que nunca llegará un REGISTER. He probado un patch que se supone consulta la BD al arrancar Asterisk pero no funciona (lo he probado en la versión trunk modificando alguna cosilla pero nada):
http://www.google.es/search?q=i+cannot+take+any+responsability+if+your+compu...
* Entonces mi primera pregunta es: ¿Necesito que un "sip show peers" muestre los usuarios de la BD de OpenSer para poder recibir el MWI?
Yo creo que sí, pues según entiendo Asterisk sólo envía el NOTIFY de MWI cuando un usuario **registrado** efectúa una llamada, o bien cuando su buzón de voz recibe un mensaje, y Asterisk sabe que un usuario está registrado de acuerdo a su "database" (astdb), y "CLI> database show" no muestra ningún usuario RealTime".
Otro punto es: yo tengo un OpenSer en multidominio y Asterisk este concepto se lo pasa por el ***** ** *** *******. Para Asterisk 200@dominioA es lo mismo que 200@dominioB y seguro tendré problemas con las notificaciones. En ese caso ya me pelearé haciendo alguna ñapa con la URI en OpenSer para "engañar" a Asterisk. Pero de momento necesito saber cómo hacer que se genere el NOTIFY de MWI.
En fin, ¿alguna pista? Lo de currarme un script externo que sea llamado con "externotify" para generar el MWI me parece demasiado artesanal. ¿Hay algún otro método en http://www.voip-info.org/wiki/view/Asterisk+at+large que deba ser empleado para mi propósito?
PD: Estoy probando con Asterisk trunk y Asterisk 1.2.16.
Gracias por cualquier ayuda, estoy dándole vueltas al tema varios días y me va a dar algo.
On Monday 31 December 2007 13:37:34 Iñaki Baz Castillo wrote:
Gracias por cualquier ayuda, estoy dándole vueltas al tema varios días y me va a dar algo.
Vale, tenía un error tonto tonto y es que se me había olvidado crear en la vista de usuarios SIP el campo "mailbox" como concatenación del "username" + @ + "domain".
Ahora es cuando me estoy enfrentando al tema del multidominio vs Asterisk, algo me dice que no lo arreglo este año.
Saludos.
On Monday 31 December 2007 17:02:37 Iñaki Baz Castillo wrote:
On Monday 31 December 2007 13:37:34 Iñaki Baz Castillo wrote:
Gracias por cualquier ayuda, estoy dándole vueltas al tema varios días y me va a dar algo.
Vale, tenía un error tonto tonto y es que se me había olvidado crear en la vista de usuarios SIP el campo "mailbox" como concatenación del "username"
- @ + "domain".
Ahora es cuando me estoy enfrentando al tema del multidominio vs Asterisk, algo me dice que no lo arreglo este año.
Ala, en mi último minuto laboral del 2007 lo he conseguido:
- OpenSer multidominio - Asterisk como servidor de voicemail en BD y RealTime para usuarios SIP. - Voicemail con MWI multidominio.
Para esto último he tenido que pelearme con el módulo UAC para modificar el Fromusername cuando el INVITE llega al Asterisk:
ibc@dominio.com --> ibc_dominio.com@dominio.com
La vista de la tabla de usuarios SIP la he hecho con este detalle:
CREATE VIEW asterisk_sip_users AS SELECT CONCAT(username,'_',domain) as name, CONCAT(username,'_',domain) as username, CONCAT(username,'@',domain) as mailbox, ...
De tal forma que el username que Asterisk ve en la vista es: ibc_dominio.com@dominio.com
Cuando llega una consulta o se deja un mensaje en un buzón de voz en OpenSer cambio el From para que Asterisk lo identifique y genere el NOTIFY tal que así:
NOTIFY sip:ibc_dominio.com@dominio.com SIP/2.0
y cuando ese NOTIFY llega a OpenSer cambio el RURI antes de hacer el "lookup(location)" y lo dejo normal:
ibc@dominio.org
Así se elimina el problema de dos usuarios con mismo username en Asterisk ya que si hago "sip show peers" veré:
ibc_dominio.com ibc_otro_dominio.com
En fin, que menuda alegría, era una lucha sangrienta entre el concepto de multidominio SIP vs Asterisk y esta vez Asterisk ha mordido el polvo XDDDDDDDDD
¡Saludos y feliz año!
Hola Iñaki,
On Monday 31 December 2007 17:02:37 Iñaki Baz Castillo wrote:
On Monday 31 December 2007 13:37:34 Iñaki Baz Castillo wrote:
Gracias por cualquier ayuda, estoy dándole vueltas al tema varios días y me va a dar algo.
Vale, tenía un error tonto tonto y es que se me había olvidado crear en la vista de usuarios SIP el campo "mailbox" como concatenación del "username"
- @ + "domain".
Ahora es cuando me estoy enfrentando al tema del multidominio vs Asterisk, algo me dice que no lo arreglo este año.
Ala, en mi último minuto laboral del 2007 lo he conseguido:
- OpenSer multidominio
- Asterisk como servidor de voicemail en BD y RealTime para usuarios
SIP.
- Voicemail con MWI multidominio.
Enhorabuena!!... y... ¿que te has dejado para el 2008? :)
Feliz año a todos.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Martes, 1 de Enero de 2008, Jesus Rodriguez escribió:
Ala, en mi último minuto laboral del 2007 lo he conseguido:
- OpenSer multidominio
- Asterisk como servidor de voicemail en BD y RealTime para usuarios
SIP.
- Voicemail con MWI multidominio.
Enhorabuena!!... y... ¿que te has dejado para el 2008? :)
Pues iba a responder con un listado de cosas, pero me sale:
513 Message Too Large
XD
Feliz a año.
El Lunes, 31 de Diciembre de 2007, Iñaki Baz Castillo escribió:
Ala, en mi último minuto laboral del 2007 lo he conseguido:
- OpenSer multidominio
- Asterisk como servidor de voicemail en BD y RealTime para usuarios SIP.
- Voicemail con MWI multidominio.
Para esto último he tenido que pelearme con el módulo UAC para modificar el Fromusername cuando el INVITE llega al Asterisk:
ibc@dominio.com --> ibc_dominio.com@dominio.com
La vista de la tabla de usuarios SIP la he hecho con este detalle:
CREATE VIEW asterisk_sip_users AS SELECT CONCAT(username,'_',domain) as name, CONCAT(username,'_',domain) as username, CONCAT(username,'@',domain) as mailbox, ...
De tal forma que el username que Asterisk ve en la vista es: ibc_dominio.com@dominio.com
Cuando llega una consulta o se deja un mensaje en un buzón de voz en OpenSer cambio el From para que Asterisk lo identifique y genere el NOTIFY tal que así:
NOTIFY sip:ibc_dominio.com@dominio.com SIP/2.0
y cuando ese NOTIFY llega a OpenSer cambio el RURI antes de hacer el "lookup(location)" y lo dejo normal:
ibc@dominio.org
Así se elimina el problema de dos usuarios con mismo username en Asterisk ya que si hago "sip show peers" veré:
ibc_dominio.com ibc_otro_dominio.com
Bueno, hay una pequeña pega derivada del sistema Realtime de Asterisk:
Resulta que Asterisk sólo envía el NOTIFY MWI si el usuario está registrado **según su lista interna**, o sea, si sale listado al hacer "sip show peers".
Si un usuario llama a Asterisk encontes Asterisk hace la consulta SQL a la tabla (vista) de usuarios RealTime y en ese momento dicha entrada se añade a la lista interna de usuarios (a partir de ese momento ya podría recibir MWI).
Tengo puesto las opciones "rtcachefriends=yes" y "ignoreregexpire=yes", con lo que el problema desaparece para un determinado usuario en cuanto éste llama a Asterisk para lo que sea. Es decir, sólo es necesario que **cada** usuario llame al menos una vez al Asterisk para recibir MWI.
El problema ocurre si se reinicia Asterisk (se vacía la lista interna de usuarios).
Traté de probar un parche que se supone carga todos los usuarios del Realtime en el aranque pero no lo logré. Tal vez me haga algún script que lance un INVITE o un OPTIONS a Asterisk por cada usuario de OpenSer (con su From correspondiente).
Lo malo es: si efectivamente logro que "sip show peers" muestre TODOS los usuarios, esa información está cacheada en Asterisk, en memoria. Si son mucho usuarios... ¿no podría ser un problema?
Saludos.
[snip]
Lo malo es: si efectivamente logro que "sip show peers" muestre TODOS los usuarios, esa información está cacheada en Asterisk, en memoria. Si son mucho usuarios... ¿no podría ser un problema?
Sospecho que podría haber algún problema, aunque es solo un suposición, pero igual no aguanta 10000 usuarios, así que yo me plantearía la posibilidad de poner varios asterisk para ello... IMHO :)
Saludos.
-- Iñaki Baz Castillo
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
El Miércoles, 2 de Enero de 2008, Saúl Ibarra escribió:
[snip]
Lo malo es: si efectivamente logro que "sip show peers" muestre TODOS los usuarios, esa información está cacheada en Asterisk, en memoria. Si son mucho usuarios... ¿no podría ser un problema?
Sospecho que podría haber algún problema, aunque es solo un suposición, pero igual no aguanta 10000 usuarios, así que yo me plantearía la posibilidad de poner varios asterisk para ello... IMHO
Bueno, realmente el Asterisk no va a recibir ningún REGISTER ni nada, tan sólo recibirá INVITE's a las extensiones de buzón de voz. Pero claro, si mantiene en memoria todos las entradas de la tabla de subscribers de OpenSer... hummmm....
Bueno, sobre la marcha XD
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.
Julián J. Menéndez
On Jan 2, 2008 6:22 PM, Saúl Ibarra saghul@gmail.com wrote:
[snip]
Lo malo es: si efectivamente logro que "sip show peers" muestre TODOS los usuarios, esa información está cacheada en Asterisk, en memoria. Si son mucho usuarios... ¿no podría ser un problema?
Sospecho que podría haber algún problema, aunque es solo un suposición, pero igual no aguanta 10000 usuarios, así que yo me plantearía la posibilidad de poner varios asterisk para ello... IMHO :)
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 ;)
On Jan 2, 2008 10:20 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
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.
Hombre, en mi opinión veo más fiable modificar el código para que consulte la tabla de la BD y genere del tirón todos los peers en la lista interna que guarda en memoria. De hecho, comentabas que había un parche pero que no funcionaba... Sería cuestión de echarle un ojo.
Lo que no sabría es como gestionar los cambios que se produzcan en la base de datos, ya que asterisk cachearía la información hasta el siguiente reload... Aunque bueno, aquí un cron que cada hora recargue la tabla no sería tan traumático ;)
Julián J. Menéndez
PD: Y perdón a todos por el offtopic ;) A ver si este 2008 me meto con Openser de una vez.
El Miércoles, 2 de Enero de 2008, Julian J. M. escribió:
On Jan 2, 2008 10:20 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
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.
Hombre, en mi opinión veo más fiable modificar el código para que consulte la tabla de la BD y genere del tirón todos los peers en la lista interna que guarda en memoria. De hecho, comentabas que había un parche pero que no funcionaba... Sería cuestión de echarle un ojo.
Cierto, lo haré.
Lo que no sabría es como gestionar los cambios que se produzcan en la base de datos, ya que asterisk cachearía la información hasta el siguiente reload... Aunque bueno, aquí un cron que cada hora recargue la tabla no sería tan traumático ;)
No no, en realidad no hay nada que hacer, la tabla de usuarios RealTime que ve Asterisk es una vista que no cambia nunca, es **completamente** estática y de hecho ni siquiera ataca a la tabla "location" donde OpenSer guarda los registros de los usuarios, sino que ataca a la tabla "subscriber" donde simplemente figuran los usuarios existentes.
En realidad es un engaño en toda regla a Asterisk, porque le dices que TODOS los usuarios están registrados en la IP de OpenSer, de tal forma que Asterisk no tiene ni idea de dónde están realmente registrados los usuarios y envía los mensajes a OpenSer. De hecho pego la creación de la vistadonde se ve claro lo que digo (fíjate en los campos "ipaddr" o "defaultip"):
CREATE VIEW asterisk_sip_users AS SELECT CONCAT(username,'_',domain) as name, CONCAT(username,'_',domain) as username, 'friend' as type, NULL as secret, domain as host, CONCAT(rpid, ' ','<',username,'>') as callerid, 'from_openser' as context, CONCAT(username,'@',domain) as mailbox, 'yes' as nat, 'no' as qualify, username as fromuser, NULL as authuser, domain as fromdomain, NULL as insecure, 'no' as canreinvite, NULL as disallow, NULL as allow, NULL as restrictcid, '__IP_OPENSER__' as defaultip, '__IP_OPENSER__' as ipaddr, '5060' as port, NULL as regseconds FROM subscriber;
Nota: en Voip-Info e incluso en los apuntes del Von de Roma del año pasado figuraba "domain as defaultip" y "domain as ipaddr". Eso es un error ya que si se trata de un registro SRV Asterisk morirá al localizarlo (esos campos indican la IP donde un usuario está registrado, no su dominio).
PD: Y perdón a todos por el offtopic ;) A ver si este 2008 me meto con Openser de una vez.
A ver si es verdad, que no participa mucha gente últimamente y aquí hay mucho que compartir ;)
Saludos.
On Jan 2, 2008 11:29 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
Lo que no sabría es como gestionar los cambios que se produzcan en la base de datos, ya que asterisk cachearía la información hasta el siguiente reload... Aunque bueno, aquí un cron que cada hora recargue la tabla no sería tan traumático ;)
No no, en realidad no hay nada que hacer, la tabla de usuarios RealTime que ve Asterisk es una vista que no cambia nunca, es **completamente** estática y de hecho ni siquiera ataca a la tabla "location" donde OpenSer guarda los registros de los usuarios, sino que ataca a la tabla "subscriber" donde simplemente figuran los usuarios existentes.
Pero al añadir un nuevo usuario a la tabla de openser, querrás también que asterisk tenga constancia de ello: por un lado creando el buzón, y por otro forzando a asterisk a que cargue el peer desde la vista asterisk_sip_users.
Julián J. Menéndez
El Jueves, 3 de Enero de 2008, Julian J. M. escribió:
On Jan 2, 2008 11:29 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
Lo que no sabría es como gestionar los cambios que se produzcan en la base de datos, ya que asterisk cachearía la información hasta el siguiente reload... Aunque bueno, aquí un cron que cada hora recargue la tabla no sería tan traumático ;)
No no, en realidad no hay nada que hacer, la tabla de usuarios RealTime que ve Asterisk es una vista que no cambia nunca, es **completamente** estática y de hecho ni siquiera ataca a la tabla "location" donde OpenSer guarda los registros de los usuarios, sino que ataca a la tabla "subscriber" donde simplemente figuran los usuarios existentes.
Pero al añadir un nuevo usuario a la tabla de openser, querrás también que asterisk tenga constancia de ello: por un lado creando el buzón, y por otro forzando a asterisk a que cargue el peer desde la vista asterisk_sip_users.
Ops, cierto, es verdad. Supongo que aquí es donde entra en juego el script con sipsak que envíe un INVITE o OPTIONS a Asterisk al crear el usuario vía web por ejemplo, y que ese INVITE vaya con el From del nuevo usuario para que Asterisk consulte la BD y lo incluya en la lista.
El Jueves, 3 de Enero de 2008, Iñaki Baz Castillo escribió:
Pero al añadir un nuevo usuario a la tabla de openser, querrás también que asterisk tenga constancia de ello: por un lado creando el buzón
Ah por cierto, el buzón se crea automáticamente en BD mediante un trigger al crear un usuario en OpenSer.
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez -
Julian J. M. -
Saúl Ibarra