Sinologic

Etiqueta: SIP

  • Publicado el RFC para la transición de IPv6

    Acaba de ser publicado el RFC (6157) para la transición del protocolo SIP a IPv6, un paso más para solucionar el tremendo inconveniente que supone el nuevo sistema de direcciones IP para un protocolo tan importante como es SIP.

    Del IPv6 ya hemos hablado e incluso hemos explicado cómo configurar IPv6 en nuestro sistema y cómo configurar Asterisk para cuando tengamos una dirección IP de este tipo, el siguiente paso es esperar a que los operadores empiecen a dar direcciones IP estáticas para los usuarios, pero visto lo visto vamos a tener una temporada mala en cuanto a direcciones IP se refiere hasta que se estabilice el asunto.

    Una vez llegado el día que dispongamos de nuestra dirección IPv6, la transición será dura ya que la mayoría de las aplicaciones que utilizamos a diario no están suficientemente preparadas para este tipo de direcciones y habrá que actualizar muchas de ellas.

    El RFC-6157 puedes verlo aquí: http://www.rfc-editor.org/rfc/rfc6157.txt

    ¿Y tú? ¿has probado ya IPv6? ¿o estás esperando a que llegue «el lobo«?

     

  • SIPit 28 se celebrará en Huntsville del 11 al 15 de Abril

    Kevin P. Flemming acaba de anunciar que la próxima celebración del conocido evento para desarrolladores SIP se celebrará en las instalaciones de Digium (Jackson Conference Center) en Huntsville -Alabama- los próximos días 11 al 15 de Abril.

    SIPit (Session Initiation Protocol Interoperatibility Test) es un evento generalmente celebrado en Estocolmo (Suecia) donde fabricantes y desarrolladores tendrán la oportunidad de llevar sus implementaciones para hacerle pruebas de forma que se certifique la compatibilidad con la especificación IETF SIP en un marco profesional y puramente técnico.

    Si algo es importante en un dispositivo o un software que trabaje con SIP es su perfecta compatibilidad con otras aplicaciones (ya sean software o hardware) ya que esa es una de las principales ventajas de utilizar un protolo estándar.

    «We’re excited to be able to bring this global event that is of such tremendous value to Huntsville for the first time, and we’re hoping the attendees will enjoy their time here enough to want us to host SIPit again in the future!»

    Más información: https://www.sipit.net/

  • Curso de desarrollo de Kamailio en Barcelona (10-11 de Feb.)

    Daniel Constantine Mierla, principal desarrollador de Kamailio (antiguo OpenSER) ha anunciado que los próximos días 10 y 11 de Febrero organizará un curso de dos días en Barcelona donde aquellos asistentes que quieran apuntarse aprenderán a crear módulos para Kamailio y donde se explicará en profundidad el funcionamiento de:

    • internal architecture
    • SIP parser
    • memory manager
    • locking manager
    • database API
    • config file language interpreter
    • RPC interface
    • pseudo-variables and transformations framework
    • module interface – write your own extensions in C as modules
    • documentation docbook format

    El precio para asistir a este curso es de 160€ y el número de plazas está bastante limitado.
    Para inscribirse, hay que enviar un email a la dirección: registration [arroba] kamailio.org

    Además de este curso y aprovechando que en él se darán cita bastantes fans de Kamailio se organizará un «Social Networking Event« la tarde/noche del día 10 donde se reunirán aquellos que quieran pasar un buen rato hablando y debatiendo sobre Kamailio y VoIP en general con algo de comida, bebida y de postre, SIP, VoIP y más Kamailio. 😛

    Este evento está abierto a cualquiera que quiera participar completamente gratis, eso sí, el consumo va por cuenta de cada uno

  • BLF distribuido entre varios Asterisk

    Olle Johansson acaba de publicar los detalles de su trabajo en la rama de desarrollo «Pinana» que permitirá transmitir la información BLF en una arquitectura distribuida, es decir, poder ver el estado de usuarios conectados en otros sistemas y poder configurar el BLF en nuestros terminales para saber cuando hablan, cuando están registrados,…

    Esta característica es muy interesante, ya que muchas infraestructuras están formadas por varios Asterisk y esto nos permitirá conocer cuando habla otro usuario de otro dominio.

    Hi!

    Brad Watkins (Marquis42) and I have been working on project pinana for a while. A lot of time was spent on architecture, something we locked down at Astricon and went from architecture work to coding. We now have the follwowing state:

    – Asterisk can subscribe to remote device states by adding hints
    – Asterisk can PUBLISH device state updates to a presence server

    (más…)

  • Asterisk 1.8 será más estricto con el protocolo SIP

    Acaba de salir a la luz una nueva beta de Asterisk 1.8 (beta 5) que incluye algunas mejoras y correcciones sobre la beta 4.

    Una de las que más me ha llamado la atención (para bien) ha sido el cambio del valor por defecto del parámetro ‘pedantic‘ del archivo sip.conf lo que hará que muchos dispositivos que no cumplan con el estándar definido en el RFC3261, dejen de funcionar correctamente.

    De siempre, este parámetro ha sido recomendable activarlo ya que obliga a que «la práctica» se comporte según «la teoría», pero el hecho de que este parámetro viniese desactivado por defecto siempre ha sido motivo de polémica al dar la impresión, por parte del equipo de desarrolladores, de estar más interesados en la compatibilidad con dispositivos que implementan sus propias modificaciones del protocolo SIP que en cumplir con los estándares, como debe hacer cualquier software de calidad.

    (más…)

  • Probando y explicando CEL en Asterisk 1.8

    Una de las grandes novedades que traía Asterisk 1.6.2 y que forman parte del gran número de novedades de Asterisk 1.8 es el soporte de un nuevo sistema de logueo de eventos llamado CEL (Channel Event Logging) que, supuestamente viene a solucionar los grandes problemas que tiene el CDR de Asterisk, como cuando se utilizan transferencias SIP en lugar de las transferencias nativas de Asterisk.

    Esta característica es seguramente, una de las mejores razones por las que actualizar nuestro Asterisk de 1.4 o Asterisk 1.6.0 a la nueva versión de Asterisk 1.8. ya que son muchas las empresas que utilizan a diario el listado de llamadas realizadas junto con toda la información que suele incluir el CDR y necesitan aún más información o por lo menos, que esta se muestre adecuadamente.

    Para que el no lo sepa, el CDR (Call Detail Record) es un registro «log» que gestiona y almacena todo el detalle de llamadas que se realizan a través de Asterisk por lo que, tanto para las empresas que necesitan llevar un control riguroso de llamadas, como para los proveedores que utilizan el CDR de Asterisk para poder facturar a sus clientes, este registro es de vital importancia.

    La mayoría de las centralitas traen integrado un sistema que permite extraer el listado de llamadas, así como el resto de sus datos: fecha y hora de inicio de la llamada, duración, origen, destino, si la llamada se ha podido realizar correctamente o si ha ocurrido algún error, etc. Aunque la principal diferencia es que para acceder al CDR, o bien hay que pagar un ‘extra’, necesitar de otro sistema independiente que se conecta a la PBX mediante un puerto serie, y además no es todo lo fiable que debería ser.

    El CDR que incluye Asterisk tampoco es una maravilla (aunque en comparación con el resto de sistemas PBX comerciales, es la mayor joya jamás inventada), y es que cuando se realizan llamadas que queremos monitorizar, existen algunas ciscustancias en las que el CDR no sabe interpretar correctamente: Por ejemplo, una transferencia realizada mediante la función SIP REFER (Transferencias SIP) que trae el propio terminal SIP, es algo que el CDR no implementa bien y en estos casos (y más aún si necesitamos facturar dicha llamada) se puede complicar bastante y para estos casos y muchos otros aparece CEL del que vamos a explicaros qué es y cómo funciona…

    (más…)

  • Comparativa de teléfonos IP en VoIP-News

    La gente de VoIP-News acaba de publicar una comparativa de los terminales IP de distintas marcas a nivel mundial de las siguientes marcas: Nortel Networks, ShoreTel, Avaya, Siemens, Cisco Systems, Polycom y AltiGen.

    El inconveniente de dicha comparativa es que son marcas muy profesionales pero poco realistas para una PYME (las grandes interesadas en este tipo de comparativas) ya que el coste mínimo del teléfono más barato (el Polycom IP 650 ronda los $300), es prácticamente igual al terminal más caro de otras marcas más interesantes económicamente hablando y con una gran experiencia en grandes despliegues, mientras que el teléfono más caro (el 4690 de Avaya) ronda los $1.300.

    La comparativa la podeis descargar de aquí:

    http://www.voip-news.com/comparison-guides/ip-phones-comparison-guide/

  • Cómo hacer videoconferencia Web con Asterisk

    Uno de los mayores atractivos de Asterisk es que deja la puerta abierta a desarrollos realmente innovadores y atractivos que llaman la atención de usuarios y empresas, uno de estos desarrollos lo acabamos de conocer de la mano de la conocida empresa española i6Net.

    i6Net acaba de desarrollar un canal especial de Asterisk para poder realizar conferencias de audio y vídeo vía web a través de Flash añadiendo soporte Flash/RTMP a Asterisk de forma que cualquier persona que disponga de un navegador web con soporte Flash pueda realizar videoconferencias de una forma fácil y rápida sin necesidad de configurar softphones ni forzar a Asterisk a realizar llamadas telefónicas vía PSTN.

    We are please to announce a new important feature for voice & video services over VXI* 5.1 next release. Flash/RTMP for Asterisk / VXI* is an add-on channel driver for Asterisk-based PBX systems. Adding Flash/RTMP for Asterisk to any Asterisk server enables complete access to manage bi-directional video calls from a Web browser with a Flash player.

    Flash/RTMP for Asterisk / VXI* is an add-on channel driver for Asterisk-based PBX systems. Adding Flash/RTMP  for Asterisk to any Asterisk server enables complete access to manage bi-directional video calls from a Web browser with a Flash player.

    Real Time Messaging Protocol (RTMP) is a proprietary protocol developed by Adobe Systems for streaming audio, video and data over the Internet, between a Flash player and a server. Adobe Flash, is the industry-leading web application environment, present in web browsers on 99% of the world’s computers. Flash can access the webcam and microphone on a PC and works through any firewall.

    Features:

      • RTMP Video IN/OUT
      • RTMP Audio IN/OUT
      • DTMF

    Flash/RTMP can send or receive video calls from/to:

      • Video 3G-324m
      • Video SIP
      • Video h323
      • Video Flash/RTMP

    Sin duda, esto es lo que muchos conocidos estaban esperando que alguien desarrollase tarde o temprano, así que por fin lo tenemos aquí.

  • Abriendo puertas con Asterisk

    Nuestro colega Jorge Montero acaba de publicar en la lista de Asterisk-ES cómo, a través de Asterisk, un par de tarjetas y un pequeño transformador podemos crearnos un sistema que pueda abrir puertas mediante el protocolo SIP.

    Asterisk y la domótica son grandes amigos desde hace tiempo, pero como siempre faltan ver proyectos donde puedan ser utilizados y donde el coste final no haga que el proyecto finalice antes de tiempo.

    Aquí os dejo el vídeo:

  • El iPhone 4 tendrá videollamadas mediante VoIP y SIP

    Una de las novedades más esperadas del nuevo iPhone 4 era la incorporación de una segunda cámara delantera con la que poder hacer videoconferencia, pero la sorpresa llegó en forma de presentación cuando aparecieron las palabras mágicas de la VoIP:

    Fotografía de engadget.com

    Ayer Olle Johansson y Saúl Ibarra ya lo comentaron: Estos términos dejan claro que la VoIP es el método ideal para el futuro de las comunicaciones y de hecho se muestran bastante orgullosos de mostrarlo así: SIP, STUN, ICE, TURN, RTP, SRTP y códecs AAC y H.264.

    Que el iPhone4 incorpore de serie un cliente SIP (de hecho la novedosa aplicación FaceTime no es más que un video-softphone SIP con vídeo). No obstante las ilusiones se caen cuando leemos que esta aplicación no tendrá apenas configuración, por lo que toda videollamada seguramente se haga mediante los propios servidores de Apple como un servicio propio. ¿Estamos ante lo que podría llamarse la «Introducción de la VoIP de Apple«? Recordamos que hace unos meses ya vimos que Apple tenía la intención de comprar una empresa dedicada a la VoIP.

    La videoconferencia del iPhone4 de momento únicamente podrá realizarse mediante Wifi pero hay intenciones de que pueda llegar a utilizar 3G o HDSPA para realizar estas videoconferencias en un futuro próximo.

    A continuación podéis ver un ejemplo de la videoconferencia del iPhone4:

    (más…)