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?
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.
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?
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ó:
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:
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.
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&gro...
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.
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ó:
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:
No, tiene mucho sentido poder decidir a que onreply_route va cada branch
Sí sí, claro que tiene sentido. Me refería a que yo pensaba que no se podía hacer a nivel de 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
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.
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.
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ó:
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.
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).
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.
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.
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.
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Raúl Alexis Betancor Santana