Buen día Lista, esta pregunta es mas que todo referida al protocolo SIP, actualmente estoy probando una maqueta de alta disponibilidad con dos Kamailio en una disposicion activo-pasivo ya está configurada la parte de la IP Virtual (con la que se registran los teléfonos) usando Heartbeat y funciona adecuadamente, ahora bien, el problema radica en que cuando el servidor que está en estado activo sufre una falla, el sip-proxy que asume la IP Virtual no sabe donde están los teléfonos hasta que ellos envían su registro de nuevo al momento de vencerse el temporizador (por default 3600 seg) . Dado que en una implementación grande no seria práctico bajar este tiempo en todos los teléfonos, investigue sobre esta utilidad llamada "sipsak" con la que se pueden construir mensajes SIP, ahora bien ¿ Es posible construir un mensaje SIP que indique a todos los teléfonos que deben enviar una petición de registro en un momento determinado?, algo asi como mandar un mensaje a la dirección de broadcast. ¿ Que otras opciones les parece que existen ?. Gracias de antemano.
El 4 de agosto de 2009 18:55, Robert Contrerastalfli64@gmail.com escribió:
Buen día Lista, esta pregunta es mas que todo referida al protocolo SIP, actualmente estoy probando una maqueta de alta disponibilidad con dos Kamailio en una disposicion activo-pasivo ya está configurada la parte de la IP Virtual (con la que se registran los teléfonos) usando Heartbeat y funciona adecuadamente, ahora bien, el problema radica en que cuando el servidor que está en estado activo sufre una falla, el sip-proxy que asume la IP Virtual no sabe donde están los teléfonos hasta que ellos envían su registro de nuevo al momento de vencerse el temporizador (por default 3600 seg).
Eso es que ambos servidores no están usando la misma BD (o una base de datos replicada) para guardar la información de los registros. Por supuesto, si quieres redundancia los registros se *deben* guardar en BD y no sólo en memoria (mira el parámetro db_mode del módulo usrloc o registrar).
Opciones: 1) Manejar una BD en un servidor externo. 2) Tener una BD en cada server Kamailio con replicación master-master (upsss).
Dado que en una implementación grande no seria práctico bajar este tiempo en todos los teléfonos, investigue sobre esta utilidad llamada "sipsak" con la que se pueden construir mensajes SIP, ahora bien ¿ Es posible construir un mensaje SIP que indique a todos los teléfonos que deben enviar una petición de registro en un momento determinado?, algo asi como mandar un mensaje a la dirección de broadcast.
No, eso no se puede hacer.
¿ Que otras opciones les parece que existen ?. Gracias de antemano.
El problema lo tienes en el diseño del servidor (la parte de la BD).
On Tuesday 04 August 2009 18:05:29 Iñaki Baz Castillo wrote:
Eso es que ambos servidores no están usando la misma BD (o una base de datos replicada) para guardar la información de los registros. Por supuesto, si quieres redundancia los registros se *deben* guardar en BD y no sólo en memoria (mira el parámetro db_mode del módulo usrloc o registrar).
Opciones:
- Manejar una BD en un servidor externo.
- Tener una BD en cada server Kamailio con replicación master-master
(upsss).
No es necesario el master-master, se puede tener una BD en cada servidor y usar t_replicate, aunque la opción de master-master es la mejor.
¿ Que otras opciones les parece que existen ?. Gracias de antemano.
Prefiero una configuración de activo-activo, registros SRV, migración de IP's reales y replicación master-master de un cluster externo de BD. Jejeje .. es que así es como lo tenemos nosotros.
Muchisimas Gracias por su pronta respuesta al aclararme el problema de diseño, indudablemente una configuración activo-activo es lo mas eficiente, y respecto al servidor externo de registros el problema es que se convierte en el punto de falla , sin embargo como dice Raul, con el cluster de BD (mas recursos) se resuelven ambos problemas.
2009/8/4 Raúl Alexis Betancor Santana rabs@dimension-virtual.com
On Tuesday 04 August 2009 18:05:29 Iñaki Baz Castillo wrote:
Eso es que ambos servidores no están usando la misma BD (o una base de datos replicada) para guardar la información de los registros. Por supuesto, si quieres redundancia los registros se *deben* guardar en BD y no sólo en memoria (mira el parámetro db_mode del módulo usrloc o registrar).
Opciones:
- Manejar una BD en un servidor externo.
- Tener una BD en cada server Kamailio con replicación master-master
(upsss).
No es necesario el master-master, se puede tener una BD en cada servidor y usar t_replicate, aunque la opción de master-master es la mejor.
¿ Que otras opciones les parece que existen ?. Gracias de antemano.
Prefiero una configuración de activo-activo, registros SRV, migración de IP's reales y replicación master-master de un cluster externo de BD. Jejeje .. es que así es como lo tenemos nosotros.
-- Raúl Alexis Betancor Santana Dimensión Virtual
SR-Users-ES mailing list SR-Users-ES@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-es
¿ Es posible construir un mensaje SIP que indique a todos los teléfonos que deben enviar una petición de registro en un momento determinado?, algo asi como mandar un mensaje a la dirección de broadcast. ¿ Que otras opciones les parece que existen ?.
Tienes que seguir las recomendaciones de Iñaki pero, para tu información, existe la RFC 3680 (scenario 3.1) que define un mecanismo similar a el que estas pidiendo para informar a los UAC de volver a registrarse. Pero me temo que no tiene implementación en kamailio. just for your information.
-pascal
Gracias de antemano. _______________________________________________ SR-Users-ES mailing list SR-Users-ES@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-es
On Tuesday 04 August 2009 20:52:35 Pascal Maugeri wrote:
¿ Es posible construir un mensaje SIP que indique a todos los teléfonos que deben enviar una petición de registro en un momento determinado?, algo asi como mandar un mensaje a la dirección de broadcast. ¿ Que otras opciones les parece que existen ?.
Tienes que seguir las recomendaciones de Iñaki pero, para tu información, existe la RFC 3680 (scenario 3.1) que define un mecanismo similar a el que estas pidiendo para informar a los UAC de volver a registrarse. Pero me temo que no tiene implementación en kamailio. just for your information.
Le he echado una leída rápida a ese RFC ... y le veo principalmente 2 pegas:
1) Que los UAC SIP han de subscribirse al sistema de "eventos de registro" (menuda paja mental del IETF), umm .. no se yo cuantos dispositivos SIP hay por ahí afuera que soportasen esto.
2) Que vas a tener un problemón muy gordo con los UAC que están detrás de NAT como no guardes en algún sitio información sobre los puertos/ip/socket por el que se registró originalmente. Los eventos generados desde el servidor no llegarían.
Y para rematar la faena .. tenemos el problema de rendimiento, ¿te imaginas un proxy con ... digamos ... 1.000.000 de usuarios registrados, enviando 1.000.000 de NOTIFY's forzando re-subscripción, que generarán a su vez 1.000.000 de REGISTERS ... uff ..., como no lo puedas lanzar por tandas, vas a fundir al proxy, a los UAC's y tu ancho de banda.
Totalmente de acuerdo contigo Raul :-))) Tranquilo que solo era "FYI". Como te lo he escrito, hay que empezar con las recomendaciones previas de unificar la BB.DD. -pascal
2009/8/4 Raúl Alexis Betancor Santana rabs@dimension-virtual.com
On Tuesday 04 August 2009 20:52:35 Pascal Maugeri wrote:
¿ Es posible construir un mensaje SIP que indique a todos los teléfonos que deben enviar una petición de registro en un momento determinado?, algo asi como mandar un mensaje a la dirección de broadcast. ¿ Que
otras
opciones les parece que existen ?.
Tienes que seguir las recomendaciones de Iñaki pero, para tu información, existe la RFC 3680 (scenario 3.1) que define un mecanismo similar a el
que
estas pidiendo para informar a los UAC de volver a registrarse. Pero me temo que no tiene implementación en kamailio. just for your information.
Le he echado una leída rápida a ese RFC ... y le veo principalmente 2 pegas:
- Que los UAC SIP han de subscribirse al sistema de "eventos de registro"
(menuda paja mental del IETF), umm .. no se yo cuantos dispositivos SIP hay por ahí afuera que soportasen esto.
- Que vas a tener un problemón muy gordo con los UAC que están detrás de
NAT como no guardes en algún sitio información sobre los puertos/ip/socket por el que se registró originalmente. Los eventos generados desde el servidor no llegarían.
Y para rematar la faena .. tenemos el problema de rendimiento, ¿te imaginas un proxy con ... digamos ... 1.000.000 de usuarios registrados, enviando 1.000.000 de NOTIFY's forzando re-subscripción, que generarán a su vez 1.000.000 de REGISTERS ... uff ..., como no lo puedas lanzar por tandas, vas a fundir al proxy, a los UAC's y tu ancho de banda.
-- Raúl Alexis Betancor Santana Dimensión Virtual
SR-Users-ES mailing list SR-Users-ES@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-es
El Martes, 4 de Agosto de 2009, Raúl Alexis Betancor Santana escribió:
On Tuesday 04 August 2009 20:52:35 Pascal Maugeri wrote:
¿ Es posible construir un mensaje SIP que indique a todos los teléfonos que deben enviar una petición de registro en un momento determinado?, algo asi como mandar un mensaje a la dirección de broadcast. ¿ Que otras opciones les parece que existen ?.
Tienes que seguir las recomendaciones de Iñaki pero, para tu información, existe la RFC 3680 (scenario 3.1) que define un mecanismo similar a el que estas pidiendo para informar a los UAC de volver a registrarse. Pero me temo que no tiene implementación en kamailio. just for your information.
Le he echado una leída rápida a ese RFC ... y le veo principalmente 2 pegas:
- Que los UAC SIP han de subscribirse al sistema de "eventos de registro"
(menuda paja mental del IETF), umm .. no se yo cuantos dispositivos SIP hay por ahí afuera que soportasen esto.
Jaja, yo conocía la existencia de ese RFC pero pensé que era mejor ni mencionarlo pues, como dices, ni cristo lo implementa. Pero curiosamente, Asterisk, cuando se comporta como cliente de registro, envía la cabecera "Event: register" de dicho RFC... y me apuesto lo que sea a que la añade "porque sí". XD
Tiene sus usos. La arquitectura IMS utiliza el "registration event" con profusión para notificar el estado de registro de los clientes a los servidores de aplicación y a diversos proxies. Pero, evidentemente, es otro escenario. JM
-----Mensaje original----- De: sr-users-es-bounces@lists.sip-router.org [mailto:sr-users-es-bounces@lists.sip-router.org] En nombre de Iñaki Baz Castillo Enviado el: miércoles, 05 de agosto de 2009 21:50 Para: users-es@lists.kamailio.org Asunto: Re: [SR-Users-ES] SIPSAK, Alta disponibilidad
El Martes, 4 de Agosto de 2009, Raúl Alexis Betancor Santana escribió:
On Tuesday 04 August 2009 20:52:35 Pascal Maugeri wrote:
¿ Es posible construir un mensaje SIP que indique a todos los teléfonos que deben enviar una petición de registro en un momento determinado?, algo asi como mandar un mensaje a la dirección de broadcast. ¿ Que otras opciones les parece que existen ?.
Tienes que seguir las recomendaciones de Iñaki pero, para tu información, existe la RFC 3680 (scenario 3.1) que define un mecanismo similar a el que estas pidiendo para informar a los UAC de volver a registrarse. Pero me temo que no tiene implementación en kamailio. just for your information.
Le he echado una leída rápida a ese RFC ... y le veo principalmente 2 pegas:
- Que los UAC SIP han de subscribirse al sistema de "eventos de registro"
(menuda paja mental del IETF), umm .. no se yo cuantos dispositivos SIP hay por ahí afuera que soportasen esto.
Jaja, yo conocía la existencia de ese RFC pero pensé que era mejor ni mencionarlo pues, como dices, ni cristo lo implementa. Pero curiosamente, Asterisk, cuando se comporta como cliente de registro, envía la cabecera "Event: register" de dicho RFC... y me apuesto lo que sea a que la añade "porque sí". XD
-- Iñaki Baz Castillo ibc@aliax.net
_______________________________________________ SR-Users-ES mailing list SR-Users-ES@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-es
2009/8/5 Iñaki Baz Castillo ibc@aliax.net:
El Martes, 4 de Agosto de 2009, Raúl Alexis Betancor Santana escribió:
On Tuesday 04 August 2009 20:52:35 Pascal Maugeri wrote:
¿ Es posible construir un mensaje SIP que indique a todos los teléfonos que deben enviar una petición de registro en un momento determinado?, algo asi como mandar un mensaje a la dirección de broadcast. ¿ Que otras opciones les parece que existen ?.
Tienes que seguir las recomendaciones de Iñaki pero, para tu información, existe la RFC 3680 (scenario 3.1) que define un mecanismo similar a el que estas pidiendo para informar a los UAC de volver a registrarse. Pero me temo que no tiene implementación en kamailio. just for your information.
Le he echado una leída rápida a ese RFC ... y le veo principalmente 2 pegas:
- Que los UAC SIP han de subscribirse al sistema de "eventos de registro"
(menuda paja mental del IETF), umm .. no se yo cuantos dispositivos SIP hay por ahí afuera que soportasen esto.
Jaja, yo conocía la existencia de ese RFC pero pensé que era mejor ni mencionarlo pues, como dices, ni cristo lo implementa.
Eso es totalmente falso, el reg Event State se implementa entornos IMS. Yo no lo calificaría de "paja mental" ni diría que no se implementa tan a la ligera: el 3GPP tenia que solventar un problema en entornos IMS, fue al IETF y pidió una solución para ese problema.
Que algunas especificaciones no se usen en los entornos en los que uno trabaja no significa que no se usen. Los operadores (hablo de grandes players como AT&T, ChinaMobile, etc) hacen uso de varias especificaciones que en esta (y otras listas) se han calificado de inútiles.
Un saludo,
El 6 de agosto de 2009 13:25, Victor Pascual Avilavictor.pascual.avila@gmail.com escribió:
- Que los UAC SIP han de subscribirse al sistema de "eventos de registro"
(menuda paja mental del IETF), umm .. no se yo cuantos dispositivos SIP hay por ahí afuera que soportasen esto.
Jaja, yo conocía la existencia de ese RFC pero pensé que era mejor ni mencionarlo pues, como dices, ni cristo lo implementa.
Eso es totalmente falso, el reg Event State se implementa entornos IMS. Yo no lo calificaría de "paja mental" ni diría que no se implementa tan a la ligera: el 3GPP tenia que solventar un problema en entornos IMS, fue al IETF y pidió una solución para ese problema.
Que algunas especificaciones no se usen en los entornos en los que uno trabaja no significa que no se usen. Los operadores (hablo de grandes players como AT&T, ChinaMobile, etc) hacen uso de varias especificaciones que en esta (y otras listas) se han calificado de inútiles.
"SIP for vendors and telcos"
Para los mismos telcos que cobran 25 céntimos por conceptos abstractos como "establecimiento de llamada" y envío de 100 carácteres en texto plano (SMS).
Correcto, un mercado de 2000 millardos de dólares al año, que seguramente irá a la baja, por razones que muchos anticipamos y compartimos, pero del que a todos nos encanta tener un trocito :-)
-----Mensaje original----- De: sr-users-es-bounces@lists.sip-router.org [mailto:sr-users-es-bounces@lists.sip-router.org] En nombre de Iñaki Baz Castillo Enviado el: jueves, 06 de agosto de 2009 13:34 Para: Lista de usuarios de SIP Router Asunto: Re: [SR-Users-ES] SIPSAK, Alta disponibilidad
"SIP for vendors and telcos"
Para los mismos telcos que cobran 25 céntimos por conceptos abstractos como "establecimiento de llamada" y envío de 100 carácteres en texto plano (SMS).
-- Iñaki Baz Castillo ibc@aliax.net
_______________________________________________ SR-Users-ES mailing list SR-Users-ES@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-es
On Jueves, 6 de Agosto de 2009 12:25:47 Victor Pascual Avila escribió:
2009/8/5 Iñaki Baz Castillo ibc@aliax.net:
El Martes, 4 de Agosto de 2009, Raúl Alexis Betancor Santana escribió:
On Tuesday 04 August 2009 20:52:35 Pascal Maugeri wrote:
¿ Es posible construir un mensaje SIP que indique a todos los teléfonos que deben enviar una petición de registro en un momento determinado?, algo asi como mandar un mensaje a la dirección de broadcast. ¿ Que otras opciones les parece que existen ?.
Tienes que seguir las recomendaciones de Iñaki pero, para tu información, existe la RFC 3680 (scenario 3.1) que define un mecanismo similar a el que estas pidiendo para informar a los UAC de volver a registrarse. Pero me temo que no tiene implementación en kamailio. just for your information.
Le he echado una leída rápida a ese RFC ... y le veo principalmente 2 pegas:
- Que los UAC SIP han de subscribirse al sistema de "eventos de
registro" (menuda paja mental del IETF), umm .. no se yo cuantos dispositivos SIP hay por ahí afuera que soportasen esto.
Jaja, yo conocía la existencia de ese RFC pero pensé que era mejor ni mencionarlo pues, como dices, ni cristo lo implementa.
Eso es totalmente falso, el reg Event State se implementa entornos IMS. Yo no lo calificaría de "paja mental" ni diría que no se implementa tan a la ligera: el 3GPP tenia que solventar un problema en entornos IMS, fue al IETF y pidió una solución para ese problema.
Lo de "paja mental", que lo dije yo, no Iñaki, viene de que no me parece lógico EN ABSOLUTO, que un UAC se tenga que registrar para recibir eventos de re-registro, es que me parece lo más absurdo del mundo. Es dejar a decisión del UAC si quiere o no recibir esos eventos, una locura (cuando hablamos de eventos de registro)
Puede que en entornos IMS tenga sentido, no lo sé, no lo he investigado. Pero de una lectura rápida del RFC saqué esa conclusión, que me parecía y parece ... una paja mental.
Que algunas especificaciones no se usen en los entornos en los que uno trabaja no significa que no se usen. Los operadores (hablo de grandes players como AT&T, ChinaMobile, etc) hacen uso de varias especificaciones que en esta (y otras listas) se han calificado de inútiles.
Tienes que admitir que son formas complicadas de resolver problemas simples .... ;-), vamos el típico "Matar moscas a cañonazos".
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Jose M Recio -
Pascal Maugeri -
Raúl Alexis Betancor Santana -
Robert Contreras -
Victor Pascual Avila