[OpenSER-Users-ES] Gestionando "correctamente" el loose route

[Iñaki Baz Castillo]

El Monday 26 May 2008 16:01:23 Saúl Ibarra escribió:

> > ----------------
> > # ¿in-dialog?
> > if (loose_route()) $var(loose_route) = 1; else $var(loose_route) = 0;

Cierto es que estaba mal puesto el comentario de:
# ¿in-dialog?

Pero bueno, aquí hemos guardado en una variable si existía o no una 
cabecera "Route" además de que al ejecutar "loose_route()" OpenSer ya ha 
quitado la primera "Route" si apuntaba a sí mismo y esas cosas.


> > ### In-dialog procesing:
> >
> > if (has_totag() && $var(loose_route)) {
> >        if (message == "INVITE")
> >                route(x);
> >        if (message == "REFER")
> >               route(y);
> >        ...
> > }

Aquí hemos procesado el caso de que fuese in-dialog (hast_totag()) y además 
tuviese el correspondiente "Route" (si no sería un in-dialog incorrecto).



> > ### Initial request processing:
> >
> > if (!has_totag() && $var(loose_route)) {
> >        # Initial request -> preloaded ROUTE set?
> >         if ($var(loose_route)) {

Efectivamente esta línea sobra, fallo mío al copiar (tenía dos versiones y las 
junté mal). Sobra este último "if".

> >                xlog("L_ERROR", "ERROR: Attempt to route with preloaded
> > Route\n"); sl_send_reply("403","Preload Route denied"); }
> >        }
> > }
> > ---------------------

Aquí hemos comprobado que era un "initial-request" y que entonces no tenía 
un "Route" (si lo tiene sería peligroso pues podría constituir un intento de 
relay).



> hasta aquí OK, pero esta segunda parte me pierde un poco: ni NO tiene
> totag, el if haría if (1 && $var(loose_route)) entonces, la única
> menra de entrar en ese if no sería que loose_route valiera 1? No
> podríoa ser algo así?:

Sí, fallo tonto mío al pegar.



> >> Y ya que estoy, otra preguntilla :) Qué mensajes in-dialog han de ir
> >> autenticados? (INVITE y REFER fijo, pero los demás?).
> >
> > Esta pregunta la hice yo en su día en esta misma lista, recuerdo que
> > había buenas conclusiones.
> > Por cierto, el re-INVITE **NO** se debe autenticar necesariamente (de
> > hecho no hay razón alguna para hacerlo), y el REFER puede hacerse o no.
> > Más seguro es que sí, pero ojo si el llamado es un alias y luego exiges
> > "check_from()" en la autenticación a un REFER desde dicho alias.
>
> Umm, entonces puede que si pido autenticación para los re-INVITE y
> REFER algún UA me de por el culo?!

Sólo si tienes alias. Ejemplo:

- "A" llama a "AliasB"

- "AliasB" resulta ser un alias de B por lo que OpenSer ruta la llamada a la 
localización de B, pero en el From y To pone:

  From: A
  To: AliasB

- B responde y tal.

- Al de un rato B envía un REFER. Depende del UAC es posible que mantenga el 
From y To (pero invertidos), o sea:

  REFER A
  From: AliasB
  To: A 

- OpenSer pide autenticación a B quien genera un nuevo REFER:

  REFER A
  From: AliasB
  To: A 
  Proxy-Authenticacion: Digest username="B"  <--- OJO !!

- Si OpenSer ejecuta "check_from()" le dará FALSE puesto que el username del 
From ("AliasB") es distinto que el username de autenticación ("B").


Lo que no tengo claro es si en el REFER B tendría que poner como "From" 
el "To" que recibió en el INVITE ("AliasB") o poner "B". Twinkle toma la 
primera opción por lo que fallaría el REFER. Otros tfnos no lo sé.


Saludos.


-- 
Iñaki Baz Castillo
ibc at in.ilimit.es