El Martes, 11 de Septiembre de 2007, Saúl Ibarra escribió:
No va exactamente así, porque si conectas un OpenSER
con un proveedor,
entonces el OpenSER tiene el rol de UAC, por lo que tiene que
autenticarse EL en el proveedor, cosa que va bastante mal en
OpenSER...
Yo no lo veo así. Precisamente un proxy SIP hace de router SIP (recordemos
esos hilos sobre la nomenclatura y tal).
Supongamos:
A ------> P1 -----------> P2
A = Tfno SIP
P1 = Su proxy
P2 = Proxy proveedor VoIP
A envía un INVITE, P1 le pide auth y tras ello A se autentica en el siguiente
INVITE a P1.
Entonces P1 ruta el mensaje a P2 quien a su vez le pide auth... a ¡¡A!! (y no
a P1). Recordemos que quien envía el mensaje es A (con su from, su
posibilidad de auth...).
Entonces A se autentica en P2 (pasando por supuesto por P1 en el cuál ya no
tiene que autenticarse al ser in-dialog).
Recalco que en este escenario P1 NO está haciendo de UAC.
A modo de analogía, digamos que en nivel 3 de TCP/IP, la IP origen que le
llega a un firewall no es la del último router, si no la del dispositivo de
capa 3 que generó ese paquete, y sobre esa IP es sobre la que se establece
una política de seguridad a nivel de firewall.
Para ver algo más documentado mirar este ilustrativo ejemplo:
http://tech-invite.com/Ti-sip-CF3665.html#ref33
* Para Hugo:
¿Eres consciente de que si el escenario que persigues es este entonces A se
debe autenticar en dos proxies y que eso podría implicar tener que usar el
mismo usuario/passwd en ambos?
Aunque bueno, es posible que algunos clientes (como por ejemplo Twinkle) te
pregunten interactivamente usuario/realm/passwd cuando toque autenticase en
P2 si la autenticación que tienen configurada para P1 no es válida en P2.
Saludos.
--
Iñaki Baz Castillo