sr-users-es August 2007

sr-users-es@lists.kamailio.org

19 participants
30 discussions

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

by Saúl Ibarra

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/

16 years, 1 month

[OpenSER-Users-ES] Enrutamiento por el campo From

by Oscar Castillo

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

16 years, 6 months

[OpenSER-Users-ES] Spam en VoIP

by Javier Allende Astigarraga

Tras leer un documento de los q me recomendasteis quiero hacer unas pruebillas pero me encuentro con un par de dudas. Quiero enviar un mensaje estilo "compra XXXX",pero como puedo enviar ese mensaje?? http://www.projectspider.org/ siguiendo un pdf dice que usando el SIPp,y creando un xml del siguiente estilo <scenario name="UAC with media"> <send retrans="5"> <![CDATA[ INVITE MESSAGE TEXT ]]> </send> <recv response="100" optional="true"> </recv> <recv response="180" optional="true"> </recv> <recv response="200" rtd="true" crlf="true"> </recv> <send> <![CDATA[ ACK MESSAGE TEXT ]]> </send>  <nop> <action> <exec play_pcap_audio="pcap/SOME_PRERECORDED_MESSAGE.pcap"/> </action> </nop> <pause milliseconds="8000"/> <send retrans="500"> <![CDATA[ BYE MESSAGE TEXT ]]> </send> <recv response="200" crlf="true"> </recv> </scenario> puedo pasarle un fichero pcap,pero mi duda es como creo ese fichero pcap,con el mensaje que os he comentado. luego tendría que mirar como evitar que pase esto,pero bueno lo primero es realizar el ataque :P -- ===================================================== Legolas_Bilbao[ID2006][GKR] Dios creo un equipo Perfecto a los demas los lleno de extranjeros http://www.forosindicedonkey.com http://usuarios.lycos.es/ligaforo/ =====================================================

16 years, 7 months

[OpenSER-Users-ES] Configuracion de sip proxy

by Hugo Franco

Hola, actualmente tengo instalado un servidor openser, con el cual puedo hacer llamadas entre los usuarios que pertenecen a la base de datos. Ahora deseo que este sea tambien el proxy de mi red sip, en mi topologia tengo varios asterisk pbx que administrar y un proveedor sip en el que tengo un acuenta con su login y password. 1._Deseo comunicar sin problema las extensiones de los diferentes asterisk, para esto cree una cuenta para cada uno y hago que se registren contra el openser y me lo hace sin problemas. Con respecto a esto mi pregunta es: para que me autentique que usuarios puden llamar y a que extensiones que modulos, parametros y demas configuraciones necesito? me he encontrado por alli con estas lineas pero no me queda claro contra que tabla autentica de colocarlas if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); return; }; 2._Por otra parte debo enrutar llamadas de las asterisk pbx a el proveedor sip, como este me dio una cuenta de ususario supongo que tengo que hacer de uac, por lo que estuve leyendo sobre este modulo pero, no me queda claro cuales lineas agregaria para poder registrarme con el openser contra el proveedor de servicio. Encontre pro ejemplo modparam("uac","credential","login:dominio:password") pero no especifica como hacer que se registre y ademas tambien encontre varios parametros de avpops configurados por lo que no se si necesito de ese modulo para esto. Tambien encontre codigo para redireccionar el trafico que esta dirigido hacia otros equipos, entonces no se si en vez loguearme con el openser, solo redirecciono y que el asterisk se encargue de loguearse. Si es asi como dirijo el trafico hacia el openser? solo configurando en los clientes a openser como proxy? De antemano muchas gracias por su ayuda

16 years, 7 months

[OpenSER-Users-ES] Poner una cabecera y quitarla a la vez

by Iñaki Baz Castillo

Hola, ya sé que de esto se habló pero no me cuadra lo que me ocurre. Por simplificar: append_hf("Forwarding: Yes\r\n"); remove_hf("Forwarding"); Después de eso el mensaje llega al destino con la cabecera bien visible. Ya sé que las operaciones sobre cabeceras OpenSer las hace en el momento de abandonar el servidor, pero si le digo que ponga algo y que luego lo quite entiendo que al final debería desaparecer, lo haga como lo haga, ¿no es así? Gracias. -- Iñaki Baz Castillo

16 years, 7 months

[OpenSER-Users-ES] [OT] Mira que el Ekiga es marranote...

by Iñaki Baz Castillo

Nada, que estaba probando el Ekiga a ver si había mejorado algo y veo que sigue tan horrendo, poco usable, lento y pesado como siempre. Para mi sorpresa mando un mensaje con letras en negrita desde Ekiga a Twinkle (Twinkle visualiza correctamente el HTML) y veo para mi desesperación que Ekiga envía esto (recortado): ----------------------------------------------------------------------------------- MESSAGE sip:ibc@192.168.1.33:5080 SIP/2.0 ... Content-Type: text/plain;charset=UTF-8 Content-Length: 28 Max-Forwards: 69 P-hint: usrloc applied que pasa <b>hola</b> que tal ----------------------------------------------------------------------------------- ¿Pero qué es eso de "text/plain"? ay ay ay... qué decepción. Así que en Twinkle recibo literalmente: que pasa <b>hola</b> que tal En fin, que sigo pensando que lo peor que le puede pasar a SIP de cara a homogeneizarlo como tecnología VoIP interoperable y tal es la ensalada de malos clientes que tiene (algunos injustamente aclamados como es el caso del Ekiga). Sin más, sólo por comentar. Saludos. -- Iñaki Baz Castillo

16 years, 7 months

[OpenSER-Users-ES] Openser para voip+presence+IM

by Alejandro Cabrera Obed

Buen dia, soy nuevo en la lista y llegue aqui porque actualmente tengo un server Debian Etch + Asterisk 1.2.13 como servidor de voip, pero ahora necesito ademas agregar presencia+mensajeria instantanea. Me dijeron algunas personas que Asterisk no soporta presencia+IM, y me dijeron que esto debia hacerlo con OpenSER. Mi pregunta es la siguiente: si yo tengo varios clientes que usan softphones del tipo X-Lite y Twinkle que se deben conectar entre ellos para establecer llamadas de voip+presencia+mensajeria instantanea, sin necesidad de conectarse a la red publica de telefonia (PSTN), es suficiente con usar solamente OpenSER ???? O debo integrar tambien a Asterisk tambien ??? Muchas gracias por adelantado, saludos. Alejandro

16 years, 7 months

[OpenSER-Users-ES] Asterisk y LoopBack en SIP (dolor de cabeza)

by Iñaki Baz Castillo

Hola, estoy probando este escenario: Asterisk genera una llamada SIP a alguna extensión de OpenSer. Todo correcto aún en el caso de que se cree un LoopBack en Asterisk: - Asterisk llama a sip:500@openser.dominio.org - OpenSer recibe la llamada y la vuelve a encaminar a Asterisk con rewriteuri. - Asterisk la recibe, avisa de "482: Loop Detected" pero la recibe y se establece la comunicación. - Por supuesto, puesto que Asterisk tiene un SIP cutre, el siguiente BYE no respeta el "Record-Route" y no pasa por OpenSer, en fin... Este es el log de Asterisk: ----------------------------------------------------------------------------------------- -- Executing [KK_500@default:1] Dial("OSS/dsp", "SIP/openser/500") in new stack -- Called openser/500 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding OSS/dsp to 'Local/500@entrantes-openser' (thanks to SIP/openser-08351810) -- Executing [500@entrantes-openser:1] Playback("Local/500@entrantes-openser-e11e,2", "demo-congrats") in new stack -- Local/500@entrantes-openser-e11e,1 answered OSS/dsp ----------------------------------------------------------------------------------------- Pero ahora me da por poner un simple alias: 888 -> 500. - En Asterisk hago una llamada a 888(a)openser.dominio.org. - OpenSer encuentra un alias de 888 a 500 y reescribe el URI. - Entonces de nuevo OpenSer reescribe el URI y encamina al Asterisk. - Pero ahora Asterisk se vuelve loco del todo, avisando decenas de veces de "LoopBack". Ahora en Asterisk leo: ----------------------------------------------------------------------------------------- -- Executing [888@entrantes-openser:1] Dial("Local/888@entrantes-openser-870f,2", "SIP/openser/888||") in new stack -- Called openser/888 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding Local/888@entrantes-openser-870f,2 to 'Local/888@entrantes-openser' (thanks to SIP/openser-081fdf50) -- Executing [888@entrantes-openser:1] Dial("Local/888@entrantes-openser-8f00,2", "SIP/openser/888||") in new stack -- Called openser/888 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding Local/888@entrantes-openser-8f00,2 to 'Local/888@entrantes-openser' (thanks to SIP/openser-0823aed8) -- Executing [888@entrantes-openser:1] Dial("Local/888@entrantes-openser-71d9,2", "SIP/openser/888||") in new stack -- Called openser/888 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding Local/888@entrantes-openser-71d9,2 to 'Local/888@entrantes-openser' (thanks to SIP/openser-081fdf50) ----------------------------------------------------------------------------------------- En fin, me gustaría preguntaros por vuestras experiencias exprimiendo el stack SIP de Asterisk. ¿Por qué demonios me permite loopback directo pero no lo permite si es un alias? ¿acaso se fija en el "To:" por alguna razón? Saludos y gracias por cualquier aclaración. -- Iñaki Baz Castillo

16 years, 7 months

[OpenSER-Users-ES] ¿Posibilidad de monitorizar estado de diálogos mediante re-INVITE's?

by Iñaki Baz Castillo

Hola, casualmente he encontrado este texto en la web en construcción de B2BUA de Sippy Software: http://www.b2bua.org/wiki/B2BUADocumentation -------------------------------------------------------------------------------------------------- Can the Sippy B2BUA determine if one of the peer in a session gone without a BYE message (eg. disconnected the network interface) and then send a BYE message to the other peer? Yes, it's possible. There are two methods for determining that the one of the parties is gone: the first is by sending periodical re-INVITE to both parties (so-called SIP keep-alives), and another one is by monitoring state of the RTP session in the proxy. The first one is already supported by the B2BUA. -------------------------------------------------------------------------------------------------- ¿Y no es posible esto con OpenSer? sería una funcionalidad muy interesante para el módulo "dialog", y tal vez para otros posibles módulos que en un futuro podrían depender de "dialog". ¿O es una idea feliz fruto de haber dormido poco? -- Iñaki Baz Castillo

16 years, 7 months

[OpenSER-Users-ES] ¿Forwarding correcto?

by Iñaki Baz Castillo

Hola, después de pelearme unos cuantos días creo que ya tengo suficientemente bien implementado el tema del forwarding, es decir, que al llamar a un usuario se consulte si tiene otra URI asociada y se le llame a ambas en paralelo hasta que coja de una de ellas. Lo primero me gustaría comentar que lo que en muchos sitios se explica como "forwarding" al mero hecho de poner un "append_branch()" me parece bastante incierto, hay que tener mucho cuidado ya que el nuevo branch no debe pasar de nuevo por un auth (o fallará en el lado cliente). Es decir, si alguien llama al "pepe" y se crea un nuevo branch a "juan", el nuevo branch que va a "pepe" consiste en un nuevo INVITE originado por OpenSer que pasaría de nuevo por el authenticate y demás (salvo que se añadan cabeceras para evitarlo o se testee la IP de origen y tal). Si no se tiene cuidado se volverá a pedir autenticación sobre ese INVITE para el cuál ya se había autenticado el usuario que llama y cuyo cliente fallará si recibe otro "authenticate" (lo he comprobado). Bueno, y para complicarlo un poco más yo lo tengo puesto en modo multidominio, con restricciones de llamadas entre dominios (cada dominio decide quién puede llamar a qué miembros del dominio) y además permito forwarding a dominios distintos del local (estos dominios podrían ser a la vez locales o externos, pero debe implicar el mismo comportamiento pues pretendo independencia total de dominios). Después de probar unas cuantas cosas he optado por hacer un "outbound" tal cuál al INVITE cuya URI se ha modificado con la del forwarding, sea el nuevo dominio el mismo u otro diferente (local o externo), por eso creo que un "outbound" es lo más sencillo: si el dominio es local ya volverá el paquete XD Después de la chapa comento mi trocito de INVITE y el forwarding: # ----------------------------------------------------------------- # INVITE # ----------------------------------------------------------------- route[3] { # Comprobamos los aliases. Recordar que los alias son sólo del mismo dominio. route(10); # Aliases. # Permisos. if (!route(4)) { # Trusted. # Sólo pedimos autenticación si es el llamante es local. if (is_from_local()) { route(6); # Auth. } route(7); # Grupos. # Comprobamos los permisos ACL entre-dominios. route(5); # ACL. } # Comprobamos los forwardings. Pueden apuntar a otros dominios. route(11); # Forwarding. # Ahora buscamos el usuario llamado. route(12); # Location. } Y el forwarding: # ----------------------------------------------------------------- # Forwarding # ----------------------------------------------------------------- route[11] { if ($hdr(Forwarding)) { xlog("L_INFO", "Encontrada cabecera 'Forwarding' -> No miramos tabla 'forwarding' para $ru\n"); return(-1); } avp_db_query("SELECT uri FROM forwarding WHERE username='$rU'", "$avp(s:forwarding_uri)"); if ($rc == 1) { # Cabecera para que el nuevo branch y el actual (via outbound) # no pasen por "trusted": append_hf("No-Trusted: Forwarding\r\n"); # Cabecera para que el nuevo branch no vuelva a pasar por "forwarding": append_hf("Forwarding: Yes\r\n"); # Cabecera para que el nuevo branch y el actual (via outbound) # no se tengan que volver a autenticar en "auth". append_hf("Authenticated: Yes\r\n"); append_branch(); $ru = $avp(s:forwarding_uri); remove_hf("Forwarding"); # En el INVITE original modificado a la URI del forwarding quitamos esta cabecera pues la URI del forwarding podría contener a su vez otro forwarding. # Enviamos el INVITE modificado con la URI del forwarding a outbound. # Si tiene que volver ya volverá. route(9); # Outbound. exit; } } En fin, ¿es correcto? Me funciona bien y por ejemplo tiene en cuenta el siguiente caso un poco "tramposo": - Imaginemos dos dominios locales "a.com" y "b.com". - b.com tiene puestos unos ACLs que impiden llamadas entrantes desde a.com. - Un espavilado de a.com define un forwarding: pepe(a)a.com -> juan(a)b.com - Ahora imaginemos que luis(a)a.com llama a pepe(a)a.com por lo que también llamaría (o intentaría llamar) a juan(a)b.com. - Si yo no hiciese el outbound final en el forwarding, o bien añado mucha lógica redundante sobre permisos, o mi OpenSer cometería el error de permitir la llamada a juan(a)b.com ya que el llamante se había autenticado **pero para llamar a alguien de su dominio, a pepe(a)a.com**. - Por eso yo he optado por hacer un outbound, así la llamada vuelve a entrar, con la cabecera añadida y comprobando que viene de la IP de OpenSer evito que vuelva a tener que autenticarse, pero el INVITE pasa por el ACL's donde se le deniega la llamada al dominio b.com. Pues eso, ¿qué os parece así? ¿estoy olvidando algo? Gracias por cualquier opinión y sugerencia. Saludos. -- Iñaki Baz Castillo

16 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es August 2007