6 Sep
2007
6 Sep
'07
7:08 p.m.
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?
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
6 Sep
6 Sep
7:22 p.m.
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(a)in.ilimit.es
7:44 p.m.
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(a)in.ilimit.es> escribió:
El Thursday 06 September 2007 18:08:37 Saúl Ibarra
escribió:
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
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(a)in.ilimit.es
_______________________________________________
Users-es mailing list
Users-es(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users-es
9:20 p.m.
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
10:18 p.m.
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(a)aliax.net> escribió:
El Jueves, 6 de Septiembre de 2007, Saúl Ibarra
escribió:
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users-es
6317
days inactive
6317
days old
sr-users-es@lists.kamailio.org
4 comments
3 participants
participants (3)
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Saúl Ibarra