23 Aug
2007
23 Aug
'07
1:38 p.m.
OK, entendido, pero lo del hastotag en realidad lo tengo asi:
if (loose_route()) {
xlog("L_INFO","*** Estamos en loose_route() ***\n");
## Con el has_totag sabemos si son "in-dialog"
if ((method=="INVITE" || method=="REFER") && !has_totag())
{
sl_send_reply("403", "Forbidden");
xlog("L_INFO","$Crx ** INVITE o REFER sin TO tag ** $Cxx\n");
exit;
}
if (method=="INVITE") {
## Es un re-INVITE
route(7);
}
route(1);
exit;
}
Ahora voy a añadir la comprobación para el auth del REFER...
Thnx Iñaki!!
El 23/08/07, Iñaki Baz Castillo <ibc(a)aliax.net> escribió:
El 23/08/07, Saúl Ibarra <saghul(a)gmail.com>
escribió:
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
He estado "limpiando" un poco el
código, metiendo el auth, el alias y
el location en distintos routes, y ahora me queda más "legible" xD
Lo que no me ha quedado muy claro es la utenticación del REFER. Yo
actualmente hago esto:
## Con el has_totag sabemos si son "in-dialog"
Humm, creo que no exactamente. Para saber si es en dialog es la función:
if (loose_route())
http://4z.com/people/emin-gabrielyan/public/070412-SIP-record-route/
El tema del "has_totag" se debe a que, una vez dentro de un diálogo
establecido, los mensajes in-dialog deben necesariamente tener un
parámetro "tag" dentro del campo "To". Es una medida de seguridad
aunque reconozco que tengo pendiente comprobar cómo de seguro es esto,
es decir, si yo genero a propósito un mensaje nuevo con un "tag" en el
"To" y le añado la cabecera "Route" para que pase por
"loose_route"
(in-dialog) ¿significa eso que OpenSer me permite el paso de es
mensaje "trampa" que en realidad no pertenece a ningún diálogo
establecido? Aquí hay que recordar que OpenSer no recuerda el estado
de diálogos, sólo de transacciones.
if ((method=="INVITE"
|| method=="REFER") && !has_totag()) {
sl_send_reply("403", "Forbidden");
xlog("L_INFO","$Crx ** INVITE o REFER sin TO tag
** $Cxx\n");
exit;
}
Así vale? O debería añadir a continuación algo como:
if (method=="REFER") {
route(22);
route(1);
}
Donde route 22 es:
# -----------------------------------------------------------------
# Auth check
# -----------------------------------------------------------------
route[22]
{
## Es necesario autenticarse
if (!proxy_authorize("","subscriber")) {
xlog("L_INFO","$CbxSe necesita autenticacion para $rm
$Cxx\n");
proxy_challenge("","0");
exit;
}
## Tienen que coincidir el nombre de usuario con el de la cabecera FROM
else if (!check_from()) {
xlog("L_INFO","$Crx*** check_from() = NO!!
***$Cxx\n");
sl_send_reply("403", "Use From=ID");
exit;
}
xlog("L_INFO","$Cbx*** Autenticacion Correcta para $rm
***$Cxx\n");
consume_credentials();
}
??
Sí, en efecto, es necesario ese Auth para REFER. Piensa en el caso de
que llames desde un PAP2 (por ejemplo) a un número SIP
"ajeno"/exterior. Una vez en el diálogo, si no pides auth para el
REFER la otra parte podría enviarte un REFER para que tu teléfono haga
una llamada al número que sea, lo que podría ocasionar llamada vía
PSTN con el coste económino asociado (y es una llamada que ha hecho tu
PAP2).
Pongo el ejemplo del PAP2 porque, que o sepa, ningún deskphone pide
confirmación al usuario cuando recibe un REFER. En cambio, con Twinkle
al recibir un REFER te saca un pop-up preguntando al usuario si desea
aceptar el REFER a la URI que sea. Ah, y todo esto yo he leído en
algún RFC que es lo correcto por obvia seguridad, en cambio parece
como si la mayoría de dispositivos SIP delegasen en su proxy SIP la
seguridad del REFER.
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
Users-es mailing list
Users-es(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users-es