15 Feb
2008
15 Feb
'08
3:03 a.m.
Buenas a todos, os planteo una duda ...
Ante un INVITE que llega a un OpenSer, para un usuario que tiene n contacs (se
ha registrado desde varios sitios), el comportamiento de TM y REGISTRANT es
hacer branching y paralel forking, hasta ahi todo ok.
Ahora resulta que uno o varios de los n contacs tiene Path y esto
hace "saltar" las branches a otro proxy.
Todos los contact reciben su INVITE, al que contestan con sus respectivos 100
Trying, 180 Ringing, etc ...
Si un contact contesta (genera un 200 Ok), el OpenSer "autogenera" (desde el
proxy que ha recibido el 200 OK) un 487 para el resto de los branches,
incluidos los que van con PATH, hasta aqui todo ok
Problema: algunos de los contacs estaban detrás de NAT, lo que hico que el
INVITE generase peticiones de sesion a un MediaProxy, 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.
Pregunta: ¿Como se puede hacer que el end_media_session se ejecute SOLO ante
el final reply del branch que contestó y no ante los 487 que van para los
branches que no contestaron?, está claro que será con setbflag, pero la duda
es como puedo saber, ante una llamada a lookup que este INVITE va a generar
branching.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
15 Feb
15 Feb
9:36 a.m.
El Friday 15 February 2008 03:03:08 Raúl Alexis Betancor Santana escribió:
Buenas a todos, os planteo una duda ...
Ante un INVITE que llega a un OpenSer, para un usuario que tiene n contacs
(se ha registrado desde varios sitios), el comportamiento de TM y
REGISTRANT es hacer branching y paralel forking, hasta ahi todo ok.
Ahora resulta que uno o varios de los n contacs tiene Path y esto
hace "saltar" las branches a otro proxy.
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();
}
Todos los contact reciben su INVITE, al que contestan
con sus respectivos
100 Trying, 180 Ringing, etc ...
Si un contact contesta (genera un 200 Ok), el OpenSer "autogenera" (desde
el proxy que ha recibido el 200 OK) un 487 para el resto de los branches,
incluidos los que van con PATH, hasta aqui todo ok
Problema: algunos de los contacs estaban detrás de NAT, lo que hico que el
INVITE generase peticiones de sesion a un MediaProxy,
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.
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...
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.
Saludos.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
10:56 a.m.
El Friday 15 February 2008 08:36:59 Iñaki Baz Castillo escribió:
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.
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.
11:12 a.m.
El Friday 15 February 2008 10:56:30 Raúl Alexis Betancor Santana escribió:
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.
¡¡ Sí !! esa es la buena noticia ;)
Desde un branch_route puedes llamar a un route y en ese caso sólo se actuará
sobre cada branch. Comprobadísimo :)
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]
{
Yo aquí añadiría:
xlog("branch_route[2]: RURI = $ru \n");
(así verás cada branch y su localización, para debugueo y tal).
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.
Sí :)
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
11:37 a.m.
La duda más estúpida del mundo ...
t_on_branch(n) "salta" automáticamente después del lookup() o la secuencia es
t_on_branch(n) ... lookup() ... t_relay() ¿?
Porque siendo el segundo caso ¿que pasa si solo hay un AoR y no varios? ..
¿salta igualmente al branch_route[n]?
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
11:44 a.m.
El Friday 15 February 2008 11:37:20 Raúl Alexis Betancor Santana escribió:
La duda más estúpida del mundo ...
t_on_branch(n) "salta" automáticamente después del lookup() o la secuencia
es t_on_branch(n) ... lookup() ... t_relay() ¿?
on_branch[ ] se ejecuta tras crear la transacción, o sea, justo al hacer
t_relay().
Porque siendo el segundo caso ¿que pasa si solo hay un
AoR y no varios? ..
¿salta igualmente al branch_route[n]?
Sí, salta aunque sólo haya uno, es lo mismo.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
11:58 a.m.
El Friday 15 February 2008 10:44:09 Iñaki Baz Castillo escribió:
El Friday 15 February 2008 11:37:20 Raúl Alexis
Betancor Santana escribió:
Bien, el cambio ha sido menos dramático de lo que me pensaba .. menos mal, ya
tenía sudores frios si tenía que volver a plantear todo el script .. XDD
Un tema sobre las pseudovariables ... $ou siempre contiene la RURI original
¿verdad?, es que tengo un caso rana que tenía resuelto haciendo $ru=$ou y no
quería que ahora eso se fuera al garete con el branch
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
La duda más estúpida del mundo ...
t_on_branch(n) "salta" automáticamente después del lookup() o la
secuencia es t_on_branch(n) ... lookup() ... t_relay() ¿?
on_branch[ ] se ejecuta tras crear la transacción, o sea, justo al hacer
t_relay().
Porque siendo el segundo caso ¿que pasa si solo
hay un AoR y no varios?
.. ¿salta igualmente al branch_route[n]?
Sí, salta aunque sólo haya uno, es lo mismo.
12:03 p.m.
El Friday 15 February 2008 11:58:33 Raúl Alexis Betancor Santana escribió:
Un tema sobre las pseudovariables ... $ou siempre
contiene la RURI original
¿verdad?, es que tengo un caso rana que tenía resuelto haciendo $ru=$ou y
no quería que ahora eso se fuera al garete con el branch
Sí, $ou tiene el RURI original que llegó a OpenSer. Incluso aunque hagas
cambios sucesivos del $ru, $ou sigue conteniendo el original.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
5914
days inactive
5914
days old
sr-users-es@lists.kamailio.org
7 comments
2 participants
participants (2)
-
Iñaki Baz Castillo -
Raúl Alexis Betancor Santana