[OpenSER-Users-ES] Problemas con el Paralel Forking

Raúl Alexis Betancor Santana rabs at dimension-virtual.com
Fri Feb 15 10:56:30 CET 2008


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.




More information about the Users-es mailing list