16 Feb
2008
16 Feb
'08
2:19 p.m.
Siguiendo con la pelea de los branches .. a ver si los termino de dominar ..
esto es lo que tengo puesto ...
route[n]
{
..
t_on_branch(2);
if(!lookup("location"))
{
..
}
...
}
branch_route[2]
{
if(isbflagset(6))
{
xlog("L_INFO", "Fix 2 BI:$T_branch_idx flags=$bF\n");
use_media_proxy();
t_on_reply(2);
}
else
{
xlog("L_INFO", "Fix 2 non needed BI:$T_branch_idx flags=$bF\n");
t_on_reply(1);
}
}
Bien .. pues devolviendo lookup 2 contacs, uno en IP pública y el otro tras
NAT, saltan ambos a branch_route[2] como era de esperar.
Al contact tras NAT, se le aplica correctamente el use_media_proxy y al otro
nada, limpito .. pues resulta que todos los REPLY's me entran por
onreply_route[1] ... y no entiendo porqué, cuando se supone que los reply's
del usuario NAT de deberían llegar a onreply_route[2]
¿Algo no he captado de como funcionan los branch_route? ¿no deberían de
quedar "marcados" estos branches en openser para que sus replies vayan a
donde deben?
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
16 Feb
16 Feb
2:53 p.m.
Me contesto yo mismo ..., parece haber un bug desde el año 2006 y no se puede
usar t_on_reply "per branch", pues bendita putada ... menos mal que los flags
si se respetan.
Si alguien tiene otra explicación (la docu del bug en sourceforge no está
actualizada desde 2006) que lo comente plz.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
5:58 p.m.
El Sábado, 16 de Febrero de 2008, Raúl Alexis Betancor Santana escribió:
Me contesto yo mismo ..., parece haber un bug desde el
año 2006 y no se
puede usar t_on_reply "per branch", pues bendita putada ... menos mal que
los flags si se respetan.
Yo no sabía que eso era un bug, siempre he pensado que es lo lógico. Me
explico:
Usar t_on_reply, t_on_branch o t_on_failure implica que una vez creada la
transacción (t_relay) cada branch pasará por onbranch_route, las respuestas
pasarán, individualmente claro, por onreply_route, y si el resultado final
(la mejor de las respuestas) es un error ([3456]XX), entonces se puede
haceralgo al respecto en onfailure_route (como por ejemplo crear un nuevo
branch con "append_branch" y poner la URI al voicemail...).
Es decir, sólo tiene sentido poner t_on_reply antes de un t_relay, pero da
igual que se ponga antes o después de generar los branches. Ejemplo:
Esto:
t_on_reply("2");
lookup("locaiont");
t_relay;
es lo mismo que est:
lookup("locaiont");
t_on_reply("2");
t_relay;
Lo que tú pretendes es que, además, cada branch tenga un onreply_route
distinto, cosa que yo nunca había pensado que se podía hacer, ¿puedes
indicarme el bug que has visto al respecto?
--
Iñaki Baz Castillo
8:44 p.m.
El Saturday 16 February 2008 22:58:33 Iñaki Baz Castillo escribió:
El Sábado, 16 de Febrero de 2008, Raúl Alexis Betancor
Santana escribió:
No, tiene mucho sentido poder decidir a que onreply_route va cada branch ... y
que se pudiese fijar los branchflags de un branch concreto sin tener que
especificarlo en setbflag, me explico con un ejemplo:
branch_route[2]
{
if(isbflagset(NAT)) # Ver nota2
{
t_on_reply(2); # Ver nota1
}
else
{
t_on_reply(1);
}
}
Nota1: quiero poder tratar los replies de NAT de forma diferente, con el
código actual no se puede y has de volver a hacer los nat_uac_test en un
ÚNICO onreply_route
Nota2: esto peta que da gusto, porque solo comprueba si para TODOS los
branches esta seteado el flag, si quieres hacer una comprobación individual
por branch, simplemente no puedes, porque nisiquiera soporta la sintaxis
isbflagset($T_branch_idx,NAT), que para mí entender debería de ser el
comportamiento implícito de isbflagset dentro de un branch_route, porque si
estás tratando cada branch por separado, ¿que demonios me importa el flag
global de todos los branches?, me importa el del branch que estoy tratando.
Me contesto yo mismo ..., parece haber un bug
desde el año 2006 y no se
puede usar t_on_reply "per branch", pues bendita putada ... menos mal que
los flags si se respetan.
Yo no sabía que eso era un bug, siempre he pensado que es lo lógico. Me
explico:
Usar t_on_reply, t_on_branch o t_on_failure implica que una vez creada la
transacción (t_relay) cada branch pasará por onbranch_route, las respuestas
pasarán, individualmente claro, por onreply_route, y si el resultado final
(la mejor de las respuestas) es un error ([3456]XX), entonces se puede
haceralgo al respecto en onfailure_route (como por ejemplo crear un nuevo
branch con "append_branch" y poner la URI al voicemail...).
Es decir, sólo tiene sentido poner t_on_reply antes de un t_relay, pero da
igual que se ponga antes o después de generar los branches. Ejemplo: Esto:
t_on_reply("2");
lookup("locaiont");
t_relay;
es lo mismo que est:
lookup("locaiont");
t_on_reply("2");
t_relay;
Esto sí, pero desde que pones un t_on_brach antes del lookup .. se jodió el
invento, no funciona el t_on_reply y has de usar el onreply_route[1] PARA
TODO lo que se genere desde un branch.
Lo que tú pretendes es que, además, cada branch tenga
un onreply_route
distinto, cosa que yo nunca había pensado que se podía hacer, ¿puedes
indicarme el bug que has visto al respecto?
Si y no lo veo tan raro, no hablo de onreply_route dinámicos por branch ni
cosas de esas ... simplemente poder decirle en función del estado de
determinados flags, que las respuestas de ese branch las trata una ruta
concreta, si se puede hacer cuando no se usa branching, ¿por qué se pierde
esa funcionalidad cuando se usa branching?, no le veo una explicación lógica,
aunque puede que la tenga.
El bug es este:
http://sourceforge.net/tracker/index.php?func=detail&aid=1530057&gr…
No es exactamente este, pero a partir de él encontré una discursión en una
lista de Ser/OpenSer sobre que no se podía hacer t_on_reply en branch_route
ni en ningún request_route que se llame desde el branch_route
correspondiente.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
17 Feb
17 Feb
10:20 a.m.
El Domingo, 17 de Febrero de 2008, Raúl Alexis Betancor Santana escribió:
El Saturday 16 February 2008 22:58:33 Iñaki Baz
Castillo escribió:
Sí sí, claro que tiene sentido. Me refería a que yo pensaba que no se podía
hacer a nivel de branch.
El Sábado, 16 de Febrero de 2008, Raúl Alexis
Betancor Santana escribió:
No, tiene mucho sentido poder decidir a que onreply_route va cada branch Me contesto yo mismo ..., parece haber un bug
desde el año 2006 y no se
puede usar t_on_reply "per branch", pues bendita putada ... menos mal
que los flags si se respetan.
Yo no sabía que eso era un bug, siempre he pensado que es lo lógico. Me
explico:
Usar t_on_reply, t_on_branch o t_on_failure implica que una vez creada la
transacción (t_relay) cada branch pasará por onbranch_route, las
respuestas pasarán, individualmente claro, por onreply_route, y si el
resultado final (la mejor de las respuestas) es un error ([3456]XX),
entonces se puede haceralgo al respecto en onfailure_route (como por
ejemplo crear un nuevo branch con "append_branch" y poner la URI al
voicemail...).
Es decir, sólo tiene sentido poner t_on_reply antes de un t_relay, pero
da igual que se ponga antes o después de generar los branches. Ejemplo: ... y que se pudiese fijar los branchflags de un
branch concreto sin tener
que especificarlo en setbflag, me explico con un ejemplo:
branch_route[2]
{
if(isbflagset(NAT)) # Ver nota2
{
t_on_reply(2); # Ver nota1
}
else
{
t_on_reply(1);
}
}
Nota1: quiero poder tratar los replies de NAT de forma diferente, con el
código actual no se puede y has de volver a hacer los nat_uac_test en un
ÚNICO onreply_route
No, podrías usar un único t_on_reply en el cual miras haces:
on_replyroute(1) {
ifbflagset(NAT) {
use_media_proxy();
...
}
}
Recuerda que un bflag persiste durante toda la transacción de su branch, lo
cual incluye las respuestas. O sea, si envías un INVITE en cuyo branch tenía
activado el bflag(NAT) verás ese bflag activo en el on_replyroute
correspondiente.
Nota2: esto peta que da gusto, porque solo comprueba si para TODOS los
branches esta seteado el flag, si quieres hacer una comprobación individual
por branch, simplemente no puedes, porque nisiquiera soporta la sintaxis
isbflagset($T_branch_idx,NAT), que para mí entender debería de ser el
comportamiento implícito de isbflagset dentro de un branch_route, porque si
estás tratando cada branch por separado, ¿que demonios me importa el flag
global de todos los branches?, me importa el del branch que estoy tratando.
No te entiendo. Si haces:
branch_route[2]
{
if(isbflagset(NAT))
Sencillamente comprobarás para cada branch si está activo ese bflag, no sé a
qué te refieres con "solo comprueba si para TODOS los branches esta seteado
el flag". Por ejemplo:
branch_route[2]
{
if(isbflagset(NAT)) {
xlog("bflag(NAT) activado para este branch con RURI $ru \n");
}
}
Ese xlog sólo lo verás para los branches pertenecientes a localizaciones del
usuario tras NAT.
--
Iñaki Baz Castillo
10:44 a.m.
El Sunday 17 February 2008 15:20:45 Iñaki Baz Castillo escribió:
No, podrías usar un único t_on_reply en el cual miras
haces:
on_replyroute(1) {
ifbflagset(NAT) {
use_media_proxy();
...
}
}
No funciona, lo he comprobado, puesto que si solo UNO de los branches tiene el
bflag(NAT) activado .. ese if será TRUE para todos los branches.
De hecho he tenido que cambiar ese códigos por
onreply_route[1]
{
if(isbflagset(NAT) || nat_uac_test("19"))
{
use_media_proxy();
}
}
Recuerda que un bflag persiste durante toda la
transacción de su branch, lo
cual incluye las respuestas. O sea, si envías un INVITE en cuyo branch
tenía activado el bflag(NAT) verás ese bflag activo en el on_replyroute
correspondiente.
Eso es la teoría, la práctica dice que las llamadas a setbflag,resetbflag y
isbflagset actuan sobre el branch 0 (todos los branches) a no ser que le
especifiques el branch_idx sobre el que comprobar, lo cual no seria ningún
problema sino fuera proque ninguna de las tres funciones admite ni una
variable, ni una pseudovariable ni un AVP como parámetro branch_idx, lo cual
imposibilita DIRECTAMENTE utilizar dicha funcionalidad.
Además no lo digo yo .. es un bug reportado.
http://66.102.9.104/search?q=cache:7_2_51k69wcJ:openser.org/pipermail/users…
No te entiendo. Si haces:
branch_route[2]
{
if(isbflagset(NAT))
Sencillamente comprobarás para cada branch si está activo ese bflag, no sé
a qué te refieres con "solo comprueba si para TODOS los branches esta
seteado el flag". Por ejemplo:
Que no, que no funciona así .. eso es lo que uno esperaría .. pero no funciona
de esa manera, mira la discursión del link que pongo más arriba.
branch_route[2]
{
if(isbflagset(NAT)) {
xlog("bflag(NAT) activado para este branch con RURI $ru \n");
}
}
Ese xlog sólo lo verás para los branches pertenecientes a localizaciones
del usuario tras NAT.
Ese log lo veré para todos los branches, con que solo uno sea NAT. Juraito
Iñaki .. que lo he tenido que arreglar a base de meter cabeceras extras en
las transacciones que llevan NAT.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
12:28 p.m.
El Domingo, 17 de Febrero de 2008, Raúl Alexis Betancor Santana escribió:
El Sunday 17 February 2008 15:20:45 Iñaki Baz Castillo
escribió:
Bien, vale más una captura que mil palabras XDDD
He registrado un usuario tras NAT y sin NAT. He puesto más o menos este código:
route {
t_on_branch("ON_BRANCH_DEFAULT");
t_on_reply("ON_REPLY_DEFAULT");
...
lookup("location");
t_relay();
}
branch_route[ON_BRANCH_DEFAULT] {
xlog("*********************** branch_route[ON_BRANCH_DEFAULT] \n");
xlog("----------------------- branch con RURI = $ru \n");
xlog("----------------------- $rr \n");
if (isbflagset(BFLAG_NAT_CALLED))
xlog("----------------------- bflag(BFLAG_NAT_CALLED) activo \n");
}
onreply_route[ON_REPLY_DEFAULT] {
xlog("*********************** onreply_route[ON_REPLY_DEFAULT] \n");
xlog("----------------------- branch con RURI = $ru \n");
xlog("----------------------- $rr \n");
if (isbflagset(BFLAG_NAT_CALLED))
xlog("----------------------- bflag(BFLAG_NAT_CALLED) activo \n");
}
Como ves es exactamente de lo que estamos hablando.
Ahora llamo a ese usuario y estos son los xlogs que veo:
*********************** onreply_route[1] desde CONTACTO_CON_NAT
----------------------- branch con RURI = <null>
-----------------------Trying
----------------------- bflag(6) activo
*********************** onreply_route[1] desde CONTACTO_SIN_NAT
----------------------- branch con RURI = <null>
----------------------- Trying
*********************** onreply_route[1] desde CONTACTO_SIN_NAT
----------------------- branch con RURI = <null>
----------------------- Ringing
*********************** onreply_route[1] desde CONTACTO_CON_NAT
----------------------- branch con RURI = <null>
----------------------- Ringing
----------------------- bflag(6) activo
Como ves la función "isbflagset(XX)" sólo me devuelve true en onreply_route y en
branch_route para los branches con
dicho bflag activado trasel lookup(location).
No, podrías usar un único t_on_reply en el cual
miras haces:
on_replyroute(1) {
ifbflagset(NAT) {
use_media_proxy();
...
}
}
No funciona, lo he comprobado, puesto que si solo UNO de los branches tiene
el bflag(NAT) activado .. ese if será TRUE para todos los branches.
http://66.102.9.104/search?q=cache:7_2_51k69wcJ:openser.org/pipermail/users
/2006-July/005982.html+t_on_reply+inside+branch_route&hl=es&ct=clnk&cd=1&cli
ent=iceweasel-a
No, lo que ese hilo dice es que si durante el route inicial haces "setbflag(X)"
entonces ese bflag se activará
para todos los branches que se creen, pero recuerda que TODAVIA no existen esos branches
(existirán
después de hacer t_relay).
Ese comportamiento lo he visto usarse para el NAT de la siguiente forma:
- Un usuario "pepe"está registrado tras NAT y sin NAT.
- "carlos" le llama.
- Como "carlos" está tras NAT (lo cual se detecta en el route inicial) se activa
el bflag(NAT). Este bflag
se activará por tanto en todos los branches que se creen.
- A su vez ese bflag se activaría tras el lookup para el contacto "pepe" sin
NAT, pero
como carlos está tras NAT el escenario es que hay que hacer el tratamiento de NAT aunque
"pepe"
esté con IP pública.
En caso de que "carlos" estuviese con IP pública, el bflag(NAT) sólo se
activaría para el contacto nateado.
A mí de todas formas no me gusta ese planteamiento y lo hago diferente, pero lo he visto
en mucho ejemplos.
Saludos.
--
Iñaki Baz Castillo
3:35 p.m.
El Sunday 17 February 2008 17:28:32 Iñaki Baz Castillo escribió:
route {
t_on_branch("ON_BRANCH_DEFAULT");
t_on_reply("ON_REPLY_DEFAULT");
...
lookup("location");
t_relay();
}
branch_route[ON_BRANCH_DEFAULT] {
xlog("*********************** branch_route[ON_BRANCH_DEFAULT] \n");
xlog("----------------------- branch con RURI = $ru \n");
xlog("----------------------- $rr \n");
if (isbflagset(BFLAG_NAT_CALLED))
xlog("----------------------- bflag(BFLAG_NAT_CALLED) activo \n");
}
onreply_route[ON_REPLY_DEFAULT] {
xlog("*********************** onreply_route[ON_REPLY_DEFAULT] \n");
xlog("----------------------- branch con RURI = $ru \n");
xlog("----------------------- $rr \n");
if (isbflagset(BFLAG_NAT_CALLED))
xlog("----------------------- bflag(BFLAG_NAT_CALLED) activo \n");
}
Como ves es exactamente de lo que estamos hablando.
Ahora llamo a ese usuario y estos son los xlogs que veo:
Ok, punto y set ... pero no partido ... ;-)
Sigue pendiente la parte de q ue no se pueden setear branch flags desde un
branch, porque setea el flag para todos los branches.
Me explico:
route[0]
{
t_on_branch(2);
t_on_reply(1);
lookup(location);
t_relay();
}
onbrach_route[2]
{
if($dd = IP1)
{
setbflag(PARA_IP1); # Esto no funciona
}
}
... y que no funcione el setbflag ahi es un crimen gordo, si en vez de llamar
a setbflag ahí, haces un route(n) y desde route(n) haces el setbflag tampoco
funciona, porque cambia el flag para todos los branches y no puedes
especificar el branch_idx de forma dinámica.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
5:47 p.m.
El Domingo, 17 de Febrero de 2008, Raúl Alexis Betancor Santana escribió:
... y que no funcione el setbflag ahi es un crimen
gordo, si en vez de
llamar a setbflag ahí, haces un route(n) y desde route(n) haces el setbflag
tampoco funciona, porque cambia el flag para todos los branches y no puedes
especificar el branch_idx de forma dinámica.
Ok, leyendo el hilo completo del bug que indicabas efectivamente queda ese
punto en el aire. Hay incluso alguno que dice que sí le funciona, pero a
saber...
Por supuesto que es un bug y gordo si resulta que haces setbflag en un
branch_route y te setea el bflag para todos. No obstante yo no he necesitado
usarlo para nada y por eso nunca me ha fastidiado.
--
Iñaki Baz Castillo
6156
days inactive
6157
days old
sr-users-es@lists.kamailio.org
8 comments
2 participants
participants (2)
-
Iñaki Baz Castillo -
Raúl Alexis Betancor Santana