El Friday 15 February 2008 08:36:59 Iñaki Baz Castillo escribió:
Lo que tienes que hacer es tratar todos esos temas
dentro de
un "branch_route[ ]". Es decir, tras hacer el lookup("location") no
hagas "nada" más dentro de ese "route",
Algo así:
route {
[...]
t_on_branch("ON_BRANCH_TO_USER");
if (! lookup("location")
sl_send_error(;
exit;
}
t_relay()
}
branch_route[ON_BRANCH_TO_USER] {
Tratar aquí cada nuevo branch por separado. Por ejemplo:
ifbflagset(BFLAG_NATTED_USER)
use_media_proxy();
}
Buff, me va tocar rehacer todo el script, hasta ahora yo tenía chorrocientos
route[n], para que cada uno hicera una cosa muy concreta (comprobar y setear
un CLI de un cliente, activar accounting, etc.)
Si modifico solo el route que trata el invite, derivando los branches a un
branch_route, ¿puedo desde ahi seguir llamando a mis route anteriores que
ejecutaban mis "funciones"?, supongo que sí .. pero ahora el tema del
branching me descoloca un poco .. toca repasar docu.
Eso es porque llamas a "use_media_proxy()"
desde el route. Por ejemplo,
supongamos que un AoR está registrado desde NAT y desde una IP pública.
Correcto, es lo que hacía. Ya veo que no lo entendí correctamente, de hecho me
mosqueaba muy mucho, que todos los INVITE's "forkeados" que salian hacia los
distintos UA's tubiesen exactamente el mísmo identificador de branch, cuando
se supone que cada uno debería de tener uno distinto.
Si tras el "lookup(location)" haces en el
mismo route un:
ifbflagset(BFLAG_NATTED_USER)
entonces es una lotería:
- Si el primer contanto que aparece en location está tras NAT entonces se
esa función "ifbflagset" devuelve TRUE.
- Si el primer contanto que aparece en location está tras IP pública
entonces se esa función "ifbflagset" devuelve FALSE.
Es decir, no hay forma de hacer distinción.
En cambio si haces esa comprobación dentro de un branch_route sí que se
actuará por separado, pues dentro de un branch_route se actua sobre cada
branch por separado, y cada branch tiene su RURI, sus flags...
Ajá, gracias por la aclaración.
pero cuando
los
branches que no contestaron reciben su 487, cortan, pero es que el
OpenSer tambien me llama a end_media_session, jodiendome el invento,
porque el usuario se queda con una llamada con el canal de señalización
abierto, pero sin RTP.
No te debería pasar eso si haces lo que te comento, garantizado.
Ok, entonces modificaré el script para trabajar de la siguiente manera ...
route[0]
{
....
if(is_method("INVITE"))
{
route(13); #
}
...
}
...
route[13]
{
sl_send_reply("100", "Trying");
...
t_on_branch(2);
if(!lookup("location"))
{
xlog("L_INFO", "Local user offline - M=$rm RURI=$ru F=$fu T=$tu
IP=$si
ID=$ci\n");
...
}
t_relay()
...
}
...
branch_route[2]
{
route(12)
}
#######################
La duda la tengo, en si puedo llamar a route(12) desde el branch_route y que
sigua el flujo que ya tenía antes definido en el script.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.