Re: [OpenSER-Users-ES] Re: [Users-es] Mensajes que requieren autenticación

Iñaki Baz Castillo ibc at aliax.net
Thu Aug 23 00:46:22 CEST 2007


El 21/08/07, Saúl Ibarra <saghul at gmail.com> escribió:
> Me respondo a mi mismo, con algunas conclusiones... espero me
> corrijáis si me equivoco :P

Te comento mis opiniones.


> > Según he leido por aqui (creo que lo comentó Iñaki), los mensajes que
> > tienen que autenticarse con el proxy_authorize y tal son:
> >
> > -INVITE
> > -REGISTER
> > -MESSAGE
> > -SUBSCRIBE
> > -PUBLISH
> > -OPTIONS

Ahí te faltaría autenticar los REFER, aunque matizo abajo si dentro o
fuera de diálogo.


> > Entonces me quedan MESSAGE y OPTIONS. Actualmente he estado probando
> > los mensajes sin autenticación y por supuesto iban OK.

Excepto si pruebas con clientes como Minisip o Linphone que "pasan" de
autenticarse para enviar MESSAGE.




> > La pregunta es: podría utilizar este mismo bloque para los OPTIONS?

Sí, lo que pasa es que te quedará bastante código repetido. Yo lo que
hago es dividir en bastantes "routes" y, por ejemplo, el MESSAGE me
queda así:

else if(method=="MESSAGE") {
                route(10);  # Aliases.

                if (!route(4)) {  # Trusted.
                        if (is_from_local()) {
                                route(6);  # Auth.
                        }
                        route(7);  # Grupos.
                        route(5);  # ACL.
                }

                route(11);  # Location.
}


Y el OPTIONS me queda muy parecido, pero añado la condición de no
permitirlo si el dominio destino $rd es diferente del origen $fd (por
nada en concreto).



> No se como generar un OPTIONS

Con el Twinkle en el menú "Call" - "Terminal capabilities".  ;)



> pero por lo que he leido ese bloque
> deberia servirme para los MESSAGE, OPTIONS y REFER, ya que pide el
> auth y tal.

> Los INFO también los manejamos con loose_route.

Sí, los INFO son (no sé si también para otras cosas) para enviar DTMF
(aunque haya otros métodos). Tienen sentido sólo en medio de una
llamada.


> > Ya solo nos quedan REFER, UPDATE y ese PRACK que no se yo... :P
> >
> > Segun leo en el RFC3515, "REFER request MAY be placed outside the
> > scope of a dialog" entonces, deberia tratarlo fuera del loose_route?
> > Iria autenticado?
> >
>
> Si, deberia.



El tema de permitir o no REFER fuera de diálogo te comento que yo al
menos nunca lo he visto, salvo en un caso para implementar Click2Dial:
  http://tech-invite.com/Ti-sip-service-19.html

Pero de todas formas eso ya lo consulté en esta lista y Jesús me
respondió que no lo había visto usar nunca así, y por supuesto está la
gran duda de cómo demonios va a responder un teléfono a un REFER sin
estar en una llamada. Es decir, ¿se va a poner a sonar para que tú lo
cojas y entonces hace el INVITE? apuesto lo que sea a que la gran
mayoría de teléfonos SIP pasarían olímpicamente de esos mensajes.

Así que yo, de momento y por simplificar, sencillamente deniego REFER
fuera de diálogo y a correr. XD


Pero, el REFER dentro de diálogo **sí** debe exigir autenticación o
sería realmente un riego.


Saludos.




-- 
Iñaki Baz Castillo
<ibc at aliax.net>


More information about the Users-es mailing list