tag:blogger.com,1999:blog-13041325482599062812012-02-16T08:47:58.441+01:00A veces te apetece recopilar ideas, compartirlas... entonces abres un blog.<BR> De momento hablando sobre temas relacionados con SIP y VoIP en general. Mañana ya veremos.Iñaki Baz Castillonoreply@blogger.comBlogger6125tag:blogger.com,1999:blog-1304132548259906281.post-39376061616223358422007-12-14T18:40:00.000+01:002007-12-14T21:26:33.029+01:00

He descubierto recientemente el peligro de un REGISTER con una cabecera "Contact" maliciosa y la vulnerabilidad que puede suponer en entornos con gateways. Pregunté sobre ello en la lista de users-es@mail.openser.org donde obtuve muy buenas y didácticas respuestas de miembros muy experimentados con estos asuntos. Escenario Supongamos una infraestructura con los siguientes personajes: Un

Iñaki Baz Castillonoreply@blogger.com1tag:blogger.com,1999:blog-1304132548259906281.post-11938440585052292902007-10-10T11:28:00.000+02:002007-10-10T12:35:10.719+02:00

Gracias al servicio Gtalk2Voip es posible hablar y chatear entre cuentas SIP genéricas, Gtalk, MSN y Yahoo. Explico a continuación algún ejemplo y posteriormente una pequeña configuración para OpenSer que ofrece algo de transparencia. Llamada de SIP a Gtalk Primeramente es necesario que el receptor (en este caso una cuenta de Gtalk user@gmail.com) autorice a un nuevo contacto (la pasarela) en

Iñaki Baz Castillonoreply@blogger.com0tag:blogger.com,1999:blog-1304132548259906281.post-68328023893693569292007-09-13T23:47:00.000+02:002007-09-14T10:52:48.137+02:00

Tras un larguísimo pero muy didáctico hilo de discusión en la lista de correo de Twinkle he aprendido algo interesante sobre las distintas formas de rechazar un INVITE y las consecuencias que ello tiene en entornos donde se produce un "pararell fork". Parallel fork Este término viene a designar un comportamiento del proxy SIP por el cuál una llamada se ramifica en varias "branches" (ramas),

Iñaki Baz Castillonoreply@blogger.com4tag:blogger.com,1999:blog-1304132548259906281.post-19476233314475098642007-08-30T22:53:00.000+02:002007-09-24T02:16:38.979+02:00

El "chan_sip" versión 1 presente en Asterisk adolece de la posibilidad de recibir de vuelta un INVITE con el URI modificado. Este hecho se hace palpable cuando usamos un proxy SIP en conjunción con Asterisk. El problema Supongamos que tenemos nuestros usuarios SIP en OpenSer y que tenemos un Asterisk para ofrecer servicios de media así como pasarela a la PSTN. Imaginemos el siguiente caso (

Iñaki Baz Castillonoreply@blogger.com0tag:blogger.com,1999:blog-1304132548259906281.post-19374997116339977612007-08-29T11:47:00.000+02:002007-08-30T21:21:48.433+02:00

En vista de la ensalada de soluciones existentes para abordar el tema de SIP y NAT me propongo tratar de explicar algunas de ellas. Igualmente trataré de desmentir algunas hipótesis que se escuchan de vez en cuando. Problema del NAT en SIP y RTP No voy a excederme relatando los problemas que ocasiona el NAT para las comunicaciones SIP. Supongamos un cliente SIP detrás de NAT que trata de

Iñaki Baz Castillonoreply@blogger.com2tag:blogger.com,1999:blog-1304132548259906281.post-76752494218941002252007-08-16T13:53:00.001+02:002007-08-29T13:47:36.917+02:00

Changelog 28-08-07 Añadido soporte para expresiones regulares SQL en los campos "from_username" y "to_username". 16-08-07 Primera versión. Escenario OpenSer albergando varios dominios independientes, es decir, autónomos y administrados por responsables diferentes. Siendo in_A.com y in_B.com dominios locales de OpenSer y ext_C.com un dominio externo no debería haber diferencia de privilegios

Iñaki Baz Castillonoreply@blogger.com2