sr-users-es

sr-users-es@lists.kamailio.org

487 discussions

[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, 8 months

[OpenSER-Users-ES] Test Sipp: ¿Seguridad en "loose_route()" con " !has_totag()"?

by Iñaki Baz Castillo

Hola, se supone no hay que pedir Auth en un re-INVITE y que es suficiente con comprobar "!has_totag()" dentro de ""loose_route()". Se me ha ocurrido probar el Sipp, crear un XML tratando de colarme al añadir un "Route" (para que pase por "loose_route()") y poniendo un tag aleatorio en el "To". Entonces sólo con conocer la IP y puerto público donde escucha un cliente podemos llegar hasta él sin más que poner en el XML: INVITE sip:ibc@86.35.221.20:22723 SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] Route: <sip:88.95.0.210;lr=on;ftag=[call_number]> From: sipp <sip:sipp@mydomain.org:[local_port]>;tag=[call_number] To: ibc <sip:[service]@[remote_ip]:[remote_port]>;tag=aaaaa ... Y lanzando "sipp": sipp -sf mi-invite-trampa.xml ip_server -s ibc -r 100 -m 1 Bueno, pues obviamente ese paquete es rechazado por MI cliente Twinkle (que es muy listo) y devuelve: 481 Call Leg/Transaction Does Not Exist Pero el caso es que llega. Es decir, existe una forma muy sencilla (la que he descrito) de echar algo de peste sobre una red interna por muy protegida que esté vía firewall (incluso aunque sólo permita paquetes SIP desde el proxy) y tan sólo conocer: - Su proxy SIP. - Un nombre de usuario. - Su IP pública o bien la del NAT. - Suponer que se mapea en el NAT el puerto también al 5060. En fin, que lo que toca es entonces fiarse de los clientes SIP que sabrán rechazar estos mensajes por no pertenecer a ninguna transacción (al contener un "tag" en el "To" del que no se sabía nada). Pero me vienen entonces a la cabeza todos esos ataques SIP que tumban algunos softphones como el X-Lite, OpenWengo y un montón más con sólo enviar algún parámetro con valor "malintencionado" (length = valor negativo y cosas así). En fin, ¿qué opináis? ¿hay que dejar esto así sin más? PD: Obviamente, aún en el caso de solicitar auth para el re-INVITE también podría repetir lo anterior enviando cualquier otro mensaje. Saludos. -- Iñaki Baz Castillo

16 years, 8 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, 8 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, 8 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, 8 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, 8 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, 8 months

[Users-es] Mandar llamadas de Asterisk a OpenSER

by Saúl Ibarra

Hoola! Hasta ahora, mando llamadas de OpenSER a Asterisk sin problemas. Pero hoy se me ha ocurrido hacerlo al revés, imaginando que las llamadas de entran por IAX o por una ZAP... Como ya tengo creado el friend OpenSER, he probado a mandarle la llamada en plan: exten => noseke,n,Dail(SIP/openser/200) por ejemplo Pero claro, OpenSER protesta diciendo que necesita autenticación y no hay INVITE que valga xD He pensado en utilizar el parámetro "fromuser" en el Asterisk, que me permite poner otra cosa en el from, pero hacer esa comprobación en OpenSER no se yo si es demasiado seguro... Como podría hacer esto de una manera "decente"? Thnx!! -- Saúl -- "Some people say why, other just say, why not." ---------------------------------------------------------------- http://www.saghul.net/

16 years, 8 months

[OpenSER-Users-ES] [Users-es] Curso de OpenSER en el VON

by Saúl Ibarra

Hoola! Se que este tema se comentó en la otra lista, pero necesito reflotarlo un poco xD Me estoy planteando *my seriamente* acercarme al VON, para ir al curso de OpenSER. Cunando digo "muy seriamente" me refiero a que tengo la tarjeta de crédito en la mano... Creo que por aquí alguien iba a ir (Iñaki?) y tal... Si podéis comentar algo de hoteles cerca y tal... os lo agradecería mucho. Salu2!! -- Saúl -- "Some people say why, other just say, why not." ---------------------------------------------------------------- http://www.saghul.net/

16 years, 8 months

[OpenSER-Users-ES] RTProxy o MediaProxy

by Raúl Alexis Betancor Santana

¿Alguien tiene alguna comparativa entre ambos?, la intención es usar para solventar los problemas de NAT con OpenSer 1.2.2, por lo que las sugerencias son bienvenidas. -- Saludos. Raúl Alexis Betancor Santana Dimensión Virtual S.L.

16 years, 8 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es