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.