sr-users-es

sr-users-es@lists.kamailio.org

487 discussions

[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

17 years, 1 month

[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

17 years, 1 month

[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

17 years, 1 month

[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

17 years, 1 month

[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

17 years, 1 month

[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

17 years, 1 month

[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

17 years, 1 month

[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í

17 years, 1 month

[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

17 years, 1 month

[OpenSER-Users-ES] aplicar o no RtpProxy si llamante y llamado tras misma IP pública

by Iñaki Baz Castillo

Hola, estaba yo super contento con mi decisión de no aplicar RtpProxy si el llamante y llamado están tras la misma IP pública. Realmente es más eficiente que si ambos usasen STUN ya que STUN obligaria a que el RTP pasase por el router innecesariamente. Este tema lo he hablado en algún hilo de la lista de OpenSer versión inglesa y a todo el mundo le había parecido residual la posibilidad de encontrar casos en los que llamante y llamado apareciesen tras mismo NAT pero no tuviesen comunicación directa. Estaba yo feliz hasta que Raúl Alexis me ha lanzado este bombazo de correo que casi me deprime. Me gustaría escuchar más opiniones al respecto. Por otra parte, una solución a los problemas que me plantea Raúl Alexis sería que los clientes, en esas circunstancias tan malvadas, usasen STUN. Ya, ¿y si tienen NAT simétrico? bufff, bueno, pues es como si tienen ALG's malvados, nada pueden hacer. ¿Qué opináis? ---------- Mensaje reenviado ---------- Asunto: [Asterisk-ES] Re: Recomedación proveedores VoIP IAX2 Fecha: Martes, 30 de Octubre de 2007 De: Raúl Alexis Betancor Santana <rabs(a)dimension-virtual.com> Para: asterisk-es(a)googlegroups.com El Tuesday 30 October 2007 13:58:14 Iñaki Baz Castillo escribió: > Creo que las ventajas de asumir que están tras el mismo NAT (permitir > tráfico directo en la LAN) supera, con creces, los casos aislados y > particulares en los que dos usuarios en los que se detecta NAT salen con > misma IP pública y resulta que no son accesibles directamente entre ellos. IMHO cometes un error tamaño catedral asumiendo eso. Además no son "casos aislados y particulares", es el caso típico de un complejo de apartamentos con distintas zonas de cobertura WiFi o peor aún, es EL CASO en la 3G en España. > Si una empresa X se monta un pollo de red local con una IP pública y hace > separaciones en la LAN con VLAN's, distintos rangos de red bloqueados por > firewall o no rutables entre sí, etc... es su problema. No confundas cosas, yo no he hablado de como tenga la empresa configurado su routing interno. Te voy a poner un ejemplo (valdría cualquier otro) sobre como tu suposición del NAT tras la misma IP falla estrepitosamente si lo intentas resolver de la forma que tu planteas: Usuario A en habitación x del hotel J, IP asignada por el hotel: 172.26.1.A Usuario B en habitación y del hotel J, IP asignada por el hotel: 172.26.1.B Central SIP oficina: IP pública (o mapeada, que pal caso es lo mismo), AAA.BBB.CCC.DDD Red LAN oficina: 172.26.0.0/23 Ahora el escenario ... Usuario A llega a su habitación, enciende el portatil, se engancha a la red VPN de la oficina para trabajar en la intranet (IP asignada intranet: 172.26.2.A) y va a su bola currando Usuario B llega a su habitación, enciente el portatil, se pone a navegar por internet y se le ocurre llamar a A, porque lo ve por el precense del sotfphone ¿Resultado con tu planteamiento de "ignorar el NAT existente"? que A recibe la señalización pero jamás recibirá el RTP y te dejo como ejercicio averiguar porqué. Y te adelanto que este escenario es más que normal, a la par de muchos otros donde no puedes ignorar el tema del NAT a la lijera. > > La única solución que SIEMPRE funciona cuando hay un NAT de por medio en > > SIP es hacer de proxy del RTP, no hay más tutia. > > Vale, imagina una centralita en internet con un proxy RTP y una > oficina/delegación muy remota con usuarios SIP. ¿Obligarías a que una > llamada entre ellos origine tráfico hasta el proxy RTP de ida y vuelta? > Recuerda que STUN no funciona tras NAT simétrico (por desgracia abundante > hoy en día) y que aún funcionando, dos usuarios tras el mismo NAT > configurados con STUN se enviarían el tráfico de audio a través de su > router (y no directamente). A ver, a ver .. no confundas ... si es una oficina remota, la solución MAS simple es que el router de salida de esa oficina soporte VPN, enchangas un tunel a la central y metes la señalización por el tunel, de esa forma la red es "plana" y no te preocupas del NAT. En caso de no soportar VPN tienes 2 opciones: A) la que tu propones, que ya te digo tiene muchas lagunas y IMHO genera más dolores de cabeza de los que resuelve. B) abrir puertos en el router y fijar en los dispositivos SIP los puertos para que no sean dinámicos. -- Saludos. Raúl Alexis Betancor Santana Dimensión Virtual S.L. -------------------------------------------------------------------------------------------------------------- -- Iñaki Baz Castillo ibc(a)in.ilimit.es

17 years, 1 month

← Newer
1
...
37
38
39
40
41
42
43
...
49
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es