sr-users-es November 2007

sr-users-es@lists.kamailio.org

9 participants
13 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, 7 months

[OpenSER-Users-ES] [OT] Consulta sobre ALG: ¿sólo vale para salientes?

by Iñaki Baz Castillo

Hola, tengo una duda de concepto sobre el ALG para SIP que implementan algunos routers. Ya os comenté que el SpeedTouch no mantiene el puerto abierto y redirigido, y mi duda es si debería o no hacerlo. Es decir, para realizar llamadas y solventar el NAT el router ALG sólo tiene que interceptar el INVITE y cambiar el Contact y SDP. En ese momento se produce una conexión UDP que dura poco y se mantiene el keepalive UDP del router (normalmente 20-30 segundos creo). Pero pare recibir llamadas es necesario que el router, al detectar un REGISTER saliente (con éxito) deje el puerto abierto y redirigido al host local indefinidamente. Pero claro, el router no puede saber cuándo se envía un un-REGISTER ya que desde un mismo dispositivo SIP puede haber varias cuentas registradas. Y dudo muchísimo que el router almacena datos SIP para saber qué cuentas se han registrado. Y por supuesto, el cliente SIP no tiene razón alguna para enviar ningún tipo de keepalive (sólo lo haría si usa STUN). Sólo se me ocurre poner la periodicidad del REGISTER a menos tiempo del keepalive UDP del router (o aumentar éste si se puede), pero me parece una guarrada (sobre todo porque el proxy SIP puede limitar el tiempo mínimo de entre registros) O sea, mi conclusión un poco alarmista es que el ALG de los routers sólo sirve para corregir el NAT en llamadas salientes. ¿Me equivoco en algo? ¿es correcta mi conclusión? Gracias por cualquier explicación. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 10 months

[OpenSER-Users-ES] ¿Permite CPL discriminar según sea INVITE, MESSAGE, etc?

by Iñaki Baz Castillo

Hola, en el RFC 3880 (CPL) no veo forma de discriminar el tipo de mensaje SIP, o sea, que si OpenSer manda ejecutar el CPL de un usuario entonces se ejecuta el CPL sea INVITE o MESSAGE. Una pena, porque estaría bien que una vez dentro del CPL se pudiese, por ejemplo, desviar un MESSAGE a un gateway SIP_SMS sólo si el remitente es del mismo dominio, pero en cambio desviar a un gateway SIP_PSTN sea cual sea el dominio del llamante. Bueno, pues nada... ojalá me equivoque. ¿Es así? Muchas gracias. -- Iñaki Baz Castillo

16 years, 10 months

[OpenSER-Users-ES] Comprobación de diálogo con "OPTIONS - 200 OK"

by Iñaki Baz Castillo

Hola, para controlar el estado de un diálogo se supone se debe usar los Session Timers (RFC 4028) con re-INVITE o UPDATE y tiempos de expiración y tal. Pero en breves me tendré que comunicar con una Nortel SIP_2_PSTN que comprueba el estado de una llamada con OPTIONS. Mi pregunta es si los dispositivos SIP comunes responden con un 200 OK si reciben un OPTIONS in-dialog, ya que no planeo meter un B2BUA entre OpenSer y el NORTEL. Gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 10 months

[OpenSER-Users-ES] [OT] Quitar SIP ALG en router SpeedTouch ST530 v6

by Iñaki Baz Castillo

Hola, me cambio a Orange y me dan un router SpeedTouch ST530 v6 con firmware 5.4.0.13. Hace ALG de SIP, pero **cómo no**, no funciona ni pa'trás, Para empezar al loro con lo que llega en un REGISTER: contact = sip:ibc@85.58.1.105:55638 received = sip:85.58.1.105:55637 ¿¿¿Qué sentido tiene que no sea el mismo puerto??? Obviamente me llamo a mí mismo y no funciona. Un tcpdump en OpenSer muestra que el INVITE llega desde el puerto 57043 y OpenSer lo envía al puerto 57042 22:52:46.387184 IP 85.58.1.105.57043 > 77.77.0.110.5060: SIP, length: 888 22:52:46.389656 IP 77.77.0.110.5060 > 85.58.1.105.57043: SIP, length: 471 22:52:46.448896 IP 85.58.1.105.57043 > 77.77.0.110.5060: SIP, length: 338 22:52:46.463137 IP 85.58.1.105.57043 > 77.77.0.110.5060: SIP, length: 1130 22:52:46.466879 IP 77.77.0.110.5060 > 85.58.1.105.57043: SIP, length: 328 22:52:46.467787 IP 77.77.0.110.5060 > 85.58.1.105.57042: SIP, length: 1062 22:52:46.948355 IP 77.77.0.110.5060 > 85.58.1.105.57042: SIP, length: 1062 22:52:47.948374 IP 77.77.0.110.5060 > 85.58.1.105.57042: SIP, length: 1062 22:52:49.948498 IP 77.77.0.110.5060 > 85.58.1.105.57042: SIP, length: 1062 Es más, un "nmap -sU 85.58.1.105 -p 57042" (y 57043) devuelve que el puerto está cerrado. Vaya **** ******. Ahora simplemente busco como quitar este ALG pero no hay forma. Al parecer en otras versiones del firmware se podía hacer: nat unbind application=SIP port=5060 Pero esa opción no aparece ahora (la de "unbind"). He encontrado otro testimonio que lo corrobora. He rebuscado en todo el menú del telnet y no veo nada. ¿Tiene truco? ¿me tendré que comprar al final un router y dar por hecho que las operadoras de ADSL se van a cargar el SIP? Gracias. -- Iñaki Baz Castillo

16 years, 10 months

[OpenSER-Users-ES] ¿ CPL ?

by Iñaki Baz Castillo

Hola, el sábado noche aún con el resacón del viernes-SIMO le eché un vistazo al RFC de CPL (los ejemplos básicamente XD): http://www.faqs.org/rfcs/rfc3880.html Tengo algunas cuestiones sobre ello: 1) ¿Hay algún cliente SIP que soporte CPL? sería muy chulo que en la configuración de un tfno te diese la opción de subir las preferencias (desvío condicional, etc) al servidor en forma de CPL en vez de sólo comportarse así en el caso de éste teléfono (esta branch). 2) ¿Qué tal sería usar CPL "al margen del usuario"? me refiero a alguna especia de aplicación que meta "a piñón" el XML del CPL para cada usuario e implemente redirecciones, desvíos, bloqueos... Lo pregunto porque tengo entendido que si el CPL XML llega en un REGISTER (como cabe esperar) el módulo CPL de OpenSer lo pasa a binario y lo guarda así en la tabla, lo que luego es más eficiente en su lectura. En cambio si una aplicación externa (web por ejemplo) mete el XML en la tabla no se pasa a binario. Además, no me queda claro cómo interactúa el CPL con el resto del script, ¿qué hay de los flags, los branch_route y todo eso? por ejemplo: Mediante CPL pongo un desvío a otra URI. Cuando se produzca este caso, ¿sale la llamada por el branch_route? ¿o una vez que entra en el CPL queda al margen de script? también he oído sobre problemas para tratar el NAT y así. En fin, ¿alguna aclaración o pista para empezar con esto? Mil gracias. PD: ¿Se usa el CPL en la vida real? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 10 months

[OpenSER-Users-ES] Invento para llamar a PBX tras NAT

by Iñaki Baz Castillo

Hola, anteriormente daba por hecho que si un dominio de OpenSer tiene asignada una centralita externa, para rutar la llamada a ella había que hacer un "seuri(IP_fija_PBX)". Pero claro, esto limita en cuanto a que se hace necesario tener IP fija en la PBX. Ahora he hecho otra cosa aprovechando que me parece lógico esperar que la centralita se registre en OpenSer con usuario "pbx(a)dominio.org". Entonces la cosa es que se registra con "pbx" pero tiene que permitir llamadas a otros usernames. Así que primero hago un "lookup" del RURI y si no es un usuario registrado hago lo siguiente para rutar la llamada a la PBX del dominio: $var(rU_original) = $rU; $rU="pbx"; lookup("location"); $rU=$var(rU_original); route(1); exit; Es decir, averiguo en qué IP está la centralita "pbx(a)dominio.org" (desde qué IP se registró) y mando allí la llamada pero conservando el username original llamado. Bueno, y funciona :) ¿Acierto con este mecanismo? ¿ o es más fiable el rutar a una IP fija sin exigir que la centralita esté registrada? Gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 11 months

[OpenSER-Users-ES] Vulnerabilidad SIP con re-INVITE y digest

by Iñaki Baz Castillo

Hola, Saúl me ha comentado un fallo de seguridad en SIP bastante terrible y lo comento aquí junto con alguna posible solución que se me ha ocurrido: El problema es éste: http://voipsa.org/pipermail/voipsec_voipsa.org/2007-November/002475.html La clave está en que el atacante envía un INVITE a la víctima con un "Contact: num_PSNT@proxy_victima" y luego solicita auth a la víctima cuando ésta le envía un re-INVITE. Entonces finalmente el atacante dispone de un digest válido para hacer la llamada a ese número. Vale, y en dicha lista de correo están bastante alarmados con esto por lo que supongo que en las soluciones que se me han ocurrido falla algo estrepitosamente: 1) Meter un "consume_credentials()" dentro de "loose_route()" para borrar la autenticación justo antes de enviar el paquete al destino. Es decir, entiendo que si un usuario(a)proxy.org es usuario de dicho proxy.org sólo tiene sentido que se autentique en ese proxy (a pesar de los divertidos esquemas del país de la piruleta que se ven en tech-invite.com con autenticaciones secuenciales y demás fricadas que luego sencillamente no existen). 2) Mirar el Contact y denegar el paquete si la URI en dicho Contact está prohibida (se corresponde con el proxy). El módulo "permissiones" permite esto para REGISTER pero no lo encuentro para otros mensajes, ¿no se puede hacer así? sería elegante. En fin, ¿es grave doctor? Saludos. -- Iñaki Baz Castillo

16 years, 11 months

[OpenSER-Users-ES] Problema al probar HelloWorld Servlet con WeSIP

by Alvaro Mari Diego

Hola a todos! Soy nuevo con WeSip, y me ha surgido el primer problema tonto que no sé solucionar :). Tengo wesip corriendo sobre OpenSER 1.2.0, y quiero probar un HelloWorld Servlet que simplemente recibe un MESSAGE request para sip:greetings@amd-openims.test, responde un 200 OK, y a continuación manda un MESSAGE request con un mensaje "Hello, World!". El servlet está metido en un sar en webapps, e instalado con el web app manager de wesip. OpenSER está configurado para reenviar cualquier request de tipo MESSAGE hacia wesip. La conexión por seas parece estar funcionando bien. Sin embargo, cuando pruebo a mandar un MESSAGE desde un cliente alice(a)amd-openims.test, la consola de WeSIP suelta lo siguiente: ******************************************************* SeasMessageEvent [SeasRouter] - New message received, from 138.4.7.163:6060 to 138.4.7.163:5080 over UDP SeasTransactionEvent [SeasRouter] - hash_index = 54974,label=620758046 flags=0 ExpressMessageChannel [ExpressMChannel[0]] - peerAddress = 138.4.7.163/6060 ExpressMessageChannel [ExpressMChannel[0]] - About to process MESSAGE sip:greetings@amd-openims.test SIP/2.0 SipConnector [ExpressMChannel[0]] - createProcessor: Reusing existing processor SipProcessor [ExpressMChannel[0]] - An incoming message is being assigned SipProcessor [SipProcessor[4]] - <<<<<<<<< Request Received <<<<<<<<< MESSAGE sip:greetings@amd-openims.test SIP/2.0 Route: <sip:138.4.7.163:5080;lr=on>,<sip:iscmark@scscf.amd-openims.test:6060;lr=on;s=1;h=0;d=0> Via: SIP/2.0/UDP 138.4.7.163:6060;branch=z9hG4bKeb6d.ff7360e1.0,SIP/2.0/UDP 138.4.7.163:4060;branch=z9hG4bKeb6d.000ef08.0,SIP/2.0/UDP 138.4.7.149:63926;branch=z9hG4bK-d87543-b370c6252d6ad226-1--d87543-;rport=63926 Max-Forwards: 14 To: "Servicio HelloWorld" <sip:greetings@amd-openims.test> From: "alice" <sip:alice@amd-openims.test>;tag=737cbe08 Call-ID: Y2FiYmY0MmM2NjFhYzU5NWUzNTE2MmM5MWY2ZjdhMGI. CSeq: 2 MESSAGE Allow: INVITE,CANCEL,ACK,BYE,INFO,OPTIONS,MESSAGE,SUBSCRIBE,NOTIFY,REFER Content-Type: application/unknown? User-Agent: X-Lite release 1011s stamp 41150 P-Charging-Vector: icid-value="P-CSCFabcd4739818c00000007";icid-generated-at=138.4.7.163;orig-ioi="amd-openims.test" Content-Length: 262 SeasHashTable [SipProcessor[4]] - Inserting hashIdx:54974 label:620758046 into hashTable SipProcessor [SipProcessor[4]] - Transaction [z9hG4bKeb6d.ff7360e1.0] is new Transaction?? --> true EngineSipMapper [SipProcessor[4]] - Request from 138.4.7.163 mapped to: ConvergedEngine[WeSIP_engine].StandardHttpHost[localhost] ConvergedEngineValve [SipProcessor[4]] - Invoking Host:localhost ConvergedHostValve [SipProcessor[4]] - SipSession not found for requestMESSAGE, trying match against Rules ConvergedHostValve [SipProcessor[4]] - No servlet-mapping matched this Request. SipResponse [SipProcessor[4]] - >>>>>>>>> Sending Response >>>>>>>>> SIP/2.0 481 Call Leg/Transaction Does Not Exist Via: SIP/2.0/UDP 138.4.7.163:6060;branch=z9hG4bKeb6d.ff7360e1.0,SIP/2.0/UDP 138.4.7.163:4060;branch=z9hG4bKeb6d.000ef08.0,SIP/2.0/UDP 138.4.7.149:63926;branch=z9hG4bK-d87543-b370c6252d6ad226-1--d87543-;rport=63926 Max-Forwards: 14 To: "Servicio HelloWorld" <sip:greetings@amd-openims.test> From: "alice" <sip:alice@amd-openims.test>;tag=737cbe08 Call-ID: Y2FiYmY0MmM2NjFhYzU5NWUzNTE2MmM5MWY2ZjdhMGI. CSeq: 2 MESSAGE Content-Length: 0 LingerList [SipProcessor[4]] - scheduled transaction z9hG4bKeb6d.ff7360e1.0 for deletion ExpressMessageChannel [SipProcessor[4]] - sending with spiral=false SipConnector [SipProcessor[4]] - recycle: Recycling processor SipProcessor[4] ActionRouter$ActionSender [ActionSender] - Writing 509 bytes into Action Socket SeasHashTable [ExpressMChannel[0]] - Removing hashIdx:54974 label:620758046 from hashTable SeasHashTable [ExpressMChannel[0]] - Transaction with id:z9hG4bKeb6d.ff7360e1.0, hash_idx:54974, label:620758046 removed from the Seas Hash Table ExpressMessageChannel [ExpressMChannel[0]] - Done processing MESSAGE sip:greetings@amd-openims.test SIP/2.0 ****************************************************************** Y en mi cliente recibo el Error 481 Call Leg/Transaction Does Not Exist. No sé si tengo algo mal en mi server.xml o en el propio servlet. Alguien podría echarme un cable? Adjunto un zip con la configuración de openser y wesip (openser.cfg y server.xml) y el servlet HelloWorldServlet. Gracias y un saludo! -- Álvaro Marí

16 years, 11 months

[OpenSER-Users-ES] equipos para cargar nuestra implementación

by Victor Pascual Ávila

Hola, estoy buscando equipos sobre los que poder poner un Asterisk, Openser o aplicaciones propias. He encontrado algunos (AP's, switchs, etc) en los que se puede hacer sobre un openwrt. Me gustaría encontrar CPE's (tipo ata, pap2, teléfono IP, dualphones...) en los que pueda cargar mi propio SIP UA. ¿sobre symbian puedo cargar este tipo de aplicaciones? -pensando en usar nokia nxx- Como algunos sabréis, estamos trabajando en temas de P2PSIP y buscamos equipos sobre los que poder cargar nuestro prototipo. ¿tenéis alguna idea? Muchas gracias y siento si se trata de un off-topic, sobretodo por los que tb forméis parte de la lista de asterisk-es :-) -- Victor Pascual Ávila

16 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es November 2007