Hoola!
Aquí volvemos a la carga. Estoy mirando el tema de la presencia, y me encuentro con un par de cosas. Por un lado veo el módulo presence, que en el wiki viene para montar un SIMPLE, y por otro lado veo los módulos como pua y demás.
Según entiendo, a mi me interesa más la primera opción, es decir, manejar los PUBLISH y SUBSCRIBE y mandar NOTIFY.
NO debería actuar como UA, mandando yo PUBLISH y demaś, como por ejemplo con pua y pua_usrloc.
Estoy en lo cierto?
El Thursday 06 September 2007 18:08:37 Saúl Ibarra escribió:
Hoola!
Aquí volvemos a la carga. Estoy mirando el tema de la presencia, y me encuentro con un par de cosas. Por un lado veo el módulo presence,
Añado que también hay otro módulo "pa" de presencia que está abandonado (creo) y desde luego no hace falta pues es más completo el de "presence".
que en el wiki viene para montar un SIMPLE, y por otro lado veo los módulos como pua y demás.
Según entiendo, a mi me interesa más la primera opción, es decir, manejar los PUBLISH y SUBSCRIBE y mandar NOTIFY.
NO debería actuar como UA, mandando yo PUBLISH y demaś, como por ejemplo con pua y pua_usrloc.
Estoy en lo cierto?
Efectivamente. El PUA es en realidad una dependencia del pua_usrloc y pua_mi (y en la 1.3 del pua_bla).
Sirve para que OpenSer genere él mismo (como UAC) PUBLISH cuando (por ejemplo con pua_usrloc) alguien se registra (alguien que no genere publish de presencia, como casi todos los teléfonos hard).
Entonces podría interesarme para los teléfonos que no soportan PUBLISH no? Creo que tu anduviste en el tema pero no era posuible saber cuales soportaban y cuales no, no? Como solucionaste el tema?
Thnx!
El 6/09/07, Iñaki Baz Castillo ibc@in.ilimit.es escribió:
El Thursday 06 September 2007 18:08:37 Saúl Ibarra escribió:
Hoola!
Aquí volvemos a la carga. Estoy mirando el tema de la presencia, y me encuentro con un par de cosas. Por un lado veo el módulo presence,
Añado que también hay otro módulo "pa" de presencia que está abandonado (creo) y desde luego no hace falta pues es más completo el de "presence".
que en el wiki viene para montar un SIMPLE, y por otro lado veo los módulos como pua y demás.
Según entiendo, a mi me interesa más la primera opción, es decir, manejar los PUBLISH y SUBSCRIBE y mandar NOTIFY.
NO debería actuar como UA, mandando yo PUBLISH y demaś, como por ejemplo con pua y pua_usrloc.
Estoy en lo cierto?
Efectivamente. El PUA es en realidad una dependencia del pua_usrloc y pua_mi (y en la 1.3 del pua_bla).
Sirve para que OpenSer genere él mismo (como UAC) PUBLISH cuando (por ejemplo con pua_usrloc) alguien se registra (alguien que no genere publish de presencia, como casi todos los teléfonos hard).
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Jueves, 6 de Septiembre de 2007, Saúl Ibarra escribió:
Entonces podría interesarme para los teléfonos que no soportan PUBLISH no?
Sí, pero como no hay una forma estándar de comunicar eso en los mensajes SIP (por ejemplo en el REGISTER)...
Creo que tu anduviste en el tema pero no era posuible saber cuales soportaban y cuales no, no?
No, no hay.
Probé unos cuántos inventos, como por ejemplo examinar la tabla location con "is_registered()" para aplicar sólo el pua_usrloc si el usuario no estaba registrado, y más chapucillas así. Pero no son válidas porque es una carrera de timers entre el tiempo de registro y el tiempo de caducidad del PUBLISH, y paso de obligar a un intervalo de registro fijo sólo por la tontería del pua_usrloc.
Es decir, me encontré con un montón de problemas.
Como solucionaste el tema?
Primeramente decir que realmente "no" debería ser un problema tan grande que un cliente SIP envíe un PUBLISH cuando se inicia y que, como también envía un REGISTER, resulte que OpenSer genera otro PUBLISH para él. Piensa que cuenta el último que se genere (que es el que genera un nuevo NOTIFY acorde con su contenido).
Un ejemplo de problema: Imagina que arrancas un softphone que envía un REGISTER cada 1000 segundos y un PUBLISH cada 1500 (además de en el arranque, claro).
- En el arranque se envían ambos mensajes y bueno, no pasa nada. - Pero ahora el usuario se pone a mano en modo "offline". - Entonces genera un PUBLISH que en OpenSer genera a su vez varios NOTIFY con "offline" para todos los subscriptores de la presencia de nuestro usuario. - Es decir, ahora el resto le ven "offline". - Pero entonces pasan 1000 segundos y mi cliente SIP envía un REGISTER con lo que se genera un PUBLISH "online" y los consiguientes NOTIFY y nos ven como "online". - Esto se "arregla" a los 500 seg con mi próximo PUBLISH que indicará "offline" (si es que el usuario no lo cambia manualmente antes).
Es decir, una carrera de "timers".
Lo suyo sería tener un listado de clientes que soporten PUBLISH o de los que no, y comprobar el User-Agent antes de hacer el pua_usrloc, pero claro... coñazo.
En fin, que yo digamos que dejé el tema un poco en el olvido.
Saludos.
Ya veo... mayormente casi como lo recordaba... Entonces lo que haré será implementar la presencia con el módulo publish, para el tema de los softphones (Twinkle powa!), mensajería y tal...
El 6/09/07, Iñaki Baz Castillo ibc@aliax.net escribió:
El Jueves, 6 de Septiembre de 2007, Saúl Ibarra escribió:
Entonces podría interesarme para los teléfonos que no soportan PUBLISH no?
Sí, pero como no hay una forma estándar de comunicar eso en los mensajes SIP (por ejemplo en el REGISTER)...
Creo que tu anduviste en el tema pero no era posuible saber cuales soportaban y cuales no, no?
No, no hay.
Probé unos cuántos inventos, como por ejemplo examinar la tabla location con "is_registered()" para aplicar sólo el pua_usrloc si el usuario no estaba registrado, y más chapucillas así. Pero no son válidas porque es una carrera de timers entre el tiempo de registro y el tiempo de caducidad del PUBLISH, y paso de obligar a un intervalo de registro fijo sólo por la tontería del pua_usrloc.
Es decir, me encontré con un montón de problemas.
Como solucionaste el tema?
Primeramente decir que realmente "no" debería ser un problema tan grande que un cliente SIP envíe un PUBLISH cuando se inicia y que, como también envía un REGISTER, resulte que OpenSer genera otro PUBLISH para él. Piensa que cuenta el último que se genere (que es el que genera un nuevo NOTIFY acorde con su contenido).
Un ejemplo de problema: Imagina que arrancas un softphone que envía un REGISTER cada 1000 segundos y un PUBLISH cada 1500 (además de en el arranque, claro).
- En el arranque se envían ambos mensajes y bueno, no pasa nada.
- Pero ahora el usuario se pone a mano en modo "offline".
- Entonces genera un PUBLISH que en OpenSer genera a su vez varios NOTIFY
con "offline" para todos los subscriptores de la presencia de nuestro usuario.
- Es decir, ahora el resto le ven "offline".
- Pero entonces pasan 1000 segundos y mi cliente SIP envía un REGISTER con lo
que se genera un PUBLISH "online" y los consiguientes NOTIFY y nos ven como "online".
- Esto se "arregla" a los 500 seg con mi próximo PUBLISH que
indicará "offline" (si es que el usuario no lo cambia manualmente antes).
Es decir, una carrera de "timers".
Lo suyo sería tener un listado de clientes que soporten PUBLISH o de los que no, y comprobar el User-Agent antes de hacer el pua_usrloc, pero claro... coñazo.
En fin, que yo digamos que dejé el tema un poco en el olvido.
Saludos.
-- Iñaki Baz Castillo
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
sr-users-es@lists.kamailio.org