Hoola!
En algún hilo se ha comentado el tema de qué mensajes deberían ir
autenticados o no, pero como no era el tema central, he decidido abrir
este otro hilo para comentar mi pregunta/cosa:
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
Vale, si esta es la lista, entonces yo ahora mismo tengo un
problemilla de seguridad, así que quería verificar una cosa:
Los INVITE se suelen tratar en u route aparte, así como los REGISTER.
Aunque todavía no me he metido mucho con ello, PUBLISH y SUBSCRIBE
también irían aparte, porque están relacionados con la presencia.
Entonces me quedan MESSAGE y OPTIONS. Actualmente he estado probando
los mensajes sin autenticación y por supuesto iban OK. Ahora he
añadido este bloque para manejarlos:
# -----------------------------------------------------------------
# MESSAGE handler
# -----------------------------------------------------------------
route[8]
{
xlog("L_INFO","$Cbx-- Mandando un MESSAGE --$Cxx\n");
## Es necesario autenticarse
if (!proxy_authorize("","subscriber")) {
xlog("L_INFO","$CbxSe necesita autenticacion para el MESSAGE$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*** MESSAGE correcto ***$Cxx\n");
consume_credentials();
# Puede que venga a nosotros pero tengamos definido un alias a fuera.
lookup("aliases") nos da la nueva URI que puede sea !=myself.
lookup("aliases");
if (!is_uri_host_local()) {
xlog("L_INFO","$CrxNot my URI after the alias lookup$Cxx\n");
## A las salientes
route(4);
exit;
};
## Miramos si existe el destino en nuestra tabla "location".
if (!lookup("location")) {
xlog("L_INFO","$Crx404 User Not Found$Cxx\n");
sl_send_reply("404", "Not Found");
exit;
};
## Si hemos llegado hasta aquí enrutamos el mensaje al destino por la
ruta por defecto.
route(1);
exit;
}
La pregunta es: podría utilizar este mismo bloque para los OPTIONS?
Entonces, llegados a este punto (sorry por la chapa) nos quedan por
tratar CANCEL, BYE, INFO, REFER, UPDATE, y PRACK?
Bien, entonces, asumiendo que tenemos esto en nuestro route principal:
if (!is_uri_host_local()) {
if (is_from_local()) {
route(4);
}
else {
sl_send_reply("403", "Forbidden");
};
exit;
}
Si un cuanlquiera nos manda algo pasaremos de ello. Entonces, para los
CANCEL y los BYE podemos hacer t_relay tranquilamente.
Los INFO solo ocurririan en loose_route no?Al igual que los UPDATE?
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?
PD: Sorry por la "pesadilla mail", si aun os quedan fuerzas tras haber
llegado hasta aqui: que hacemos con el PRACK? (aunque no lo he visto
nunca...)
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
Buenas, discutiendo con un carrier sobre porqué no se presentan los callerid
de las llamadas, me dice que es que tenemos que activar el "Nature of.
Address indicator" a "International number", por lo que he estado buscando,
ese parámetro de "Nature of. Address indicator" está relacionado con los
códigos ISUP, pero no encuentro una contrapartida de definición en una
cabecera SIP.
¿Alguien sabe de alguna otra cabecera que no sea el From, Network-Asserted-ID,
Remote-Asserted-ID ó P-Asserted-ID para expecificar el CallerID del llamante?
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Hola a todos!
Actualmente me encuentro configurando mi Openser y quiero direccionar las
llamadas de acuerdo a mi número de origen (al campo From), estuve leyendo
por ahí y vi que se podía hacer con el módulo AVPOPS, pero al configurarle
los parámetros, me arroja un error.
"ERROR: add_avp_galias_str <$fu> set module parameter"
"Can`t set module parameter"
Lo que hice fue lo siguiente:
...
loadmodule "avpops.so"
...
modparam("avpops", "avp_url", "mysql://openser:openserrw@161.xxx.xxx.xxx
/openser")
modparam("avpops", "avp_table", "usr_preferences")
modparam("avpops","avp_aliases","email=s:email_addr;fwd=i:753;$Tf=s:time;$from=$fu")
modparam("avpops","uuid_column","uuid")
modparam("avpops","username_column","username")
modparam("avpops","domain_column","domain")
modparam("avpops","attribute_column","attribute")
modparam("avpops","value_column","value")
modparam("avpops","type_column","type
...
if (method == "INVITE"){
route(3);
exit;
};
...
route[3]{
if (avp_check("s:0001sip:0001@.*"eq/$from/I)) {
exit;
};
Me falta algo? o estoy colocando mal alguna línea?
Muchas Gracias por la ayuda que puedan brindar
Hola Buenas Tardes a Todos
Actualemente me encuentro desarrollando un proyecto que permita aplicar QoS
sobre Openser.
Por una parte mi Openser.cfg toma decisiones de enrutar por la ruta más
económica de acuerdo al número marcado.
También permite enrutar por un canal dedicado si el número que llama es un
usuario VIP.
Ahora bien, me gustaría que mi Openser pueda testear la congestión de
determinado canal y en base a ello tomar la decisión de enviarlo a otra ruta
menos congestionada. He leído que existen programas para chequear la
congestión de la red, pero eso lo hace el usuario. vi que con ethereal se
puede hacer.Sin embargo esto lo que me permite es crear un plan preventivo
pero estático.
En mi red tengo 50 usuarios. Conocen uds alguna herramienta o módulo en
Openser para lograr medir la congestión de una ruta y en base a ella tomar
una decisión.
¿Se les ocurre alguna otra forma de implementar QoS sobre Openser?
Sinceramente Gracias
Oscar
Saludos, amigos del Voip.
Soy un usuario novato de lo que la telefonía ip se refiere, leyendo y
leyendo encontré lo que es OpenSer pero no sé si cumplirá mis
necesidades, explico un poco lo que necesito, como dije anteriormente
soy bastante novato por lo que mi consulta inicial también lo es :-)
Que es lo que necesito "Optimamente" para poder empezar a trabajar con
telefonía ip? me explico, quiero saber que tengo que instalar /Nombre
de Software/ para crear un Servidor que soporte la creación de lineas
no reales, que las maneje, que ellas puedan salir por un proveedor
determinado y realizar llamadas entre si y que las llamadas se cobren
a un cierto costo X dado. ¿Qué es lo que necesito para poder realizar
esto?
No sé si OpenSer+Asterisk me da la posibilidad de ello o que más necesito.
Muchas gracias de antemano por las respuesta.
Atentamente.
Kapeta.
tengo mi servidor OpenSER con una IP publica, para poder hacer llamadas independiente donde me encuentre en la red, mi configuracion es la sencilla, soporta presencia simple, ahora lei que para soportar NAT debo instalar el RPTPRoxy en la misma PC o en otra, para que maneje el trafico multimedia. si alguien tuviera el archivo de configuracion de como hacer todo ello, he intentado con los que hay en la red y no lo consigo. espero contar con vosotros
lo que necesito es openser-presencia+nat.
saludos cordiales
Arturo
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…
Hola a todos, me acabo de inscribir a este grupo y comenzando a jugar
con openser, tengo una consulta que a lo mejor la hayan echo pero no
he encontrado informacion de lo que busco. Lo que quiero es poder
mostrar en la pagina web que usuario esta disponible (o el estado que
tenga en ese momento) y si es posible inyectarle un mensaje desde un
formulario a este usuario y que pueda responder, es decir si el
mensaje de respuesta se guarde una DB y asi que el usuario que esta en
web recuprar asi como un sistema de chat en linea...
Bueno muchos saludos :)
Hola, ¿cuál es el peligro real que trata de impedir el
fichero "register.deny"?
Es decir, sé que lo que hace es impedir registros cuyo "Contact" indique una
IP o nombre DNS contenido en este fichero de texto "register.deny".
Pero no sé cuál es el problema real.
Según el propio fichero:
# Suppose that we have a PSTN gateway with IP address 1.2.3.4
# We should prevent REGISTER messages that contain that IP
# address in Contact header field because that can cause serious
# security hole (a malicious user might be able to register such
# a contact and bypass security checks performed by the SIP proxy).
#
# The following line prevents registering Contacts with IP 1.2.3.4
# (Don't forget to list also all hostnames that can be used to
# reach the PSTN gateway)
Veamos, el único problema de seguridad que yo veo es que un usuario
malintencionado pudiese acceder a la pasarela PSTN 1.2.3.4 y que se
registrase desde ella, pero nada más, ¿no?
O sea, aunque yo hackee mi softphone o use SIPp o lo que sea y envíe un
REGISTER con "Contact=sip:1.2.3.4" no pasa absolutamente nada, ¿no?
Bueno, tal vez si fuese un registrar abierto y cada cuál se podría registrar
con un usuario que el decidiese sin necesidad de autenticarse, entonces el
usuario malintencionado enviaría un REGISTER:
To: 937123123(a)dominio.org
Contact: sip:1.2.3.4
Y entonces si luego el mismo llama desde otra cuenta SIP a
sip:937123123@dominio.org entonces OpenSer enviaría esa llamada a la PSTN
precisamente al número 937123123.
Pero no sé, me parece un cúmulo de cosas mal hechas. yo me refiero a un
sistema en el que se exige autenticación para REGISTER y en el que existen
unos usuarios en la tabla "subscriber" o en el Radius o como sea.
Entonces no habría problema, ¿no?
Saludos.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Umm, estoy intentando probar un escenario donde los usuarios se pueden
registrar en distintos OpenSer, el backend de DB es postgres y todo va ok,
hasta que un usuario del servidor A quiere llamar a uno que se registro en el
servidor B, como ambos servidores manejan la misma base de datos, setean el
campo socket de la tabla location con la IP:puerto del OpenSer donde se
registraron, pero si una llamada entra por el openser A y llama a un usuario
que está registrado por el B, se le responde Not Found, cuando lo que yo
quiero es llame al usuario del servidor B.
Ambos servidores manejan el mismo dominio.
¿Alguna pista/documentación?, he estado buscando por google información sobre
si es posible que ambos servidores compartan esa tabla de la base de datos o
si hay algún método alternativo para solventar la papeleta y no he encontrado
nada, probablemente me estoy saltando algo obvio.
¿Pistas, URL, documentación ó .cfg's de ejemplo serán bienvenidos?.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Hola, estoy empezando con el módulo siptrace, en principio parece que funciona
pero me entra una terrible duda:
Resulta que si doy valor a:
modparam("siptrace", "traced_user_avp", "$avp(s:siptrace)")
y luego lo uso:
$avp(s:siptrace_uri) = "loquesea";
sip_trace();
entonces resulta que me guarda todo el tráfico de cada llamada, incluidas las
respuestas:
traced_user method status direction
----------------------------------------------------------------------------
loquesea INVITE in
loquesea INVITE 100 out
loquesea INVITE out
loquesea INVITE 100 in
loquesea INVITE 180 in
loquesea INVITE 180 out
loquesea INVITE 200 in
loquesea INVITE 200 out
y por supuesto las IP origen y destino son las correctas y tal.
En cambio si no le doy valor o no utilizo "traced_user_avp" entonces sólo
aparece la primera entrada de las anteriores.
¿Por qué razón?
Por otra parte, si uso sip_trace() obtengo entradas distintas en la tabla que
si uso setflag(22); # Flag de siptrace.
Concretamente aparecen duplicadas cada respuesta (100, 180, 200) pero el campo
de "traced_user" sólo tiene valor en la segunda.
En fin, qué cosas.
Ya puestos aprovecho para
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es