23 Aug
2007
23 Aug
'07
1:46 a.m.
El 21/08/07, Saúl Ibarra <saghul(a)gmail.com> escribió:
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(a)aliax.net>
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.