Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to VozDigital DevFest 31/10/14
Similar to VozDigital DevFest 31/10/14 (20)
Recently uploaded
Recently uploaded (6)
VozDigital DevFest 31/10/14
- 1. VozDigital bridging calls between WebRTC and SIP Javier Fernández Seco
- 2. ● VozDigital ● What is WebRTC? ● Jingle signaling ● Tangle!!!!! ● VoIP in tuenti ● SIP signaling ● Signaling gateway ● High availability
- 3. An inbound & outbound VoIP service …using the customer’s GSM number! …with no additional data charges! …integrated with existing Tuenti chat infrastructure
- 4. Why not using a SIP SoftPhone?
- 5. Let’s recap what we already have...
- 6. WebRTC for App2App calls
- 7. Multiple resources Will he be available??
- 12. Let’s dig into W3C’s WebRTC “The mission of the Web Real-Time Communications Working Group, part of the Ubiquitous Web Applications Activity, is to define client-side APIs to enable Real-Time Communications in Web browsers. These APIs should enable building applications that can be run inside a browser, requiring no extra downloads or plugins, that allow communication between parties using audio, video and supplementary real-time communication, without having to use intervening servers (unless needed for firewall traversal, or for providing intermediary services)”
- 13. What is WebRTC
- 14. Transports for signaling o TCP o UDP o SCTP
- 15. Transports for streaming o SDES o DTLS-SRTP
- 16. SDP v=0 o=jinglephone 372345681 372345681 IN IP4 192.168.1.2 s=Jingle Softphone c=IN IP4 192.168.1.2 t=0 0 m=audio 1940 RTP/AVP 0 99 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:99 ILBC/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=rtcp:1942 a=ptime:20 m=video 1944 RTP/AVP 96 34 a=rtpmap:96 H264/90000 a=rtpmap:34 H263/90000 a=rtcp:1946
- 17. ● local ● STUN - reflexive ● TURN - relay ICE
- 21. Microsoft’s response to WebRTC ORTC (Object Real-Time Communications) “Our mission: To enable rich, high quality, RTC applications to be developed in mobile endpoints and servers via native toolkits, simple Javascript APIs and HTML5. It is also a mandate that Object RTC be compatible with WebRTC.”
- 22. Y dónde se posiciona Apple?
- 25. Signaling over XMPP ● Jingle protocol <jingle xmlns='urn:xmpp:jingle:1' action='session-initiate' initiator='romeo@montague.lit/orchard' sid='a73sjjvkla37jfea'> <content creator='initiator' name='voice'> <description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'> <payload-type id='96' name='speex' clockrate='16000'/> <payload-type id='97' name='speex' clockrate='8000'/> <payload-type id='18' name='G729'/> <payload-type id='0' name='PCMU' /> <payload-type id='103' name='L16' clockrate='16000' channels='2'/> <payload-type id='98' name='x-ISAC' clockrate='8000'/> </description> </content> </jingle>
- 26. SDP over XMPP in tuenti ● Tangle protocol <tangle xmlns='urn:tuenti:tangle:1' action='session-initiate' initiator='javierf@tuenti.com' sid='a73sjjvkla37jfea'> <sdp><![CDATA[SDP]]></sdp> </tangle>
- 27. VoIP message sequence chart
- 30. SIP 2.0 - RFC 3261 ● Controls multimedia comms over IP. ● Can rely on SDP ● Use of different transports for signaling ● Signaling may be encrypted with TLS ● Use of different transports for streaming
- 31. SIP scenario
- 32. We need a SIP stack!
- 33. NkSIP Carlos Gonzalez Florido carlosj.gf@gmail.com https://github.com/kalta/nksip @carlosjgf
- 34. SIP Servlets API SIP Protocol support with a full stack
- 36. Let’s see how everything fits together
- 37. VoIP message sequence chart
- 38. SIP message sequence chart
- 39. Merging the message sequence charts
- 41. Voice Gateway ● Handles signaling between protocols ● Is a Servlet ● Uses a SipServlets framework ● Uses Squirrel State Machine ● Uses Guice Servlet Injection FW
- 43. HTTP servlets V.S. SIP servlets ● return HTML pages ● client-server ● does not originate requests ● request/response ● a request is handled by one servlet ● connect SIP clients ● peer to peer ● creates requests ● request/multiple responses ● a request can be handled by multiple
- 44. Converged Applications HTTP Client HTTP Servlet SIP agent SIP Servlet SIP agent HTTP servlet SIP servlet
- 45. Voice Gateway Overview Messenger App xmpp http SIP Chat Server Http Server SIP Servlets Application SIP provider
- 46. Servlet architecture Call Bridge Spec SIP Servlets (Mobicents) Tangle Spec Call Bridge Impl Tangle Servlet Spec SIP Servlet Spec (Oracle) Voice Call Bridge Servlet
- 47. Development approach ● SIP gateway scenarios/use cases ● MSC charts ● Integration Tests ● Development
- 48. Outbound Call State Machine
- 49. But, what about the media?
- 50. Media connection
- 51. High availability SIP HTTP Tangl e
- 53. Tools
- 58. End Questions?
- 59. Thank you!
Editor's Notes
- Hola, me llamo Javier Fernández y actualmente estoy trabajando en tuenti en el desarrollo del servicio de VozDigital
- VozDigital Qué se persigue con voz digital Cómo debemos hacerlo realidad Qué es WebRTC Sus transportes de señalización: TCP/UDP/SCTP Sus transportes de streaming: DTLS-SRTP/SDES Session description protocol - SDP Interactive connectivity establishment - ICE Jingle protocol Tangle!!!! VoIP en tuenti También vamos a ver fugazmente qué es SIP Para luego hablar del pegamento que une todo esto: nuestro Voice signaling gateway y la infraestructura que hemos montado para dar un servicio con alta disponibilidad...
- Hace unos 6 meses empezamos a desarrollar un nuevo producto para Tuenti Movil. Este producto consiste en dar la posibilidad de realidad llamadas telefónicas a través de la aplicación de tuenti. Esta charla tratará de porqué hemos optado por esta solución, los retos a los que nos hemos enfrentado, la infraestructura que hemos montado, los problemas que nos hemos ido encontrando a lo largo del camino y las cosas que hemos aprendido. Tuenti quiere dar un valor añadido a sus clientes. Como parte su propuesta, quiere crear un producto que le diferencie de la competencia mucho más allá de tener unos precios atractivos. Por esa razón, nos embarcamos en la aventura de dar a nuestros clientes un servicio (como ahora lo llaman) ‘over-the-top’ que complemente nuestros servicios como operador movil, permitiendo servicios adicionales como la posibilidad de realizar llamadas a través de nuestra aplicación, aportando una experiencia de usuario única y rompiendo con todos los cánones establecidos sobre los operadores móviles.
- Para conseguir estos objetivos, lo más directo que se nos vino a la cabeza es usar un SoftPhone. Esta solución suele hacerse de la siguiente manera: 1.- Se compra una de las múltiples marcar de softphones que existen en el mercado 2.- Se modifica para que se conecte únicamente a una URL de un dominio SIP 3.- Se integran las funcionalidades para crédito y pago, por ejemplo, cuánto crédito te queda, añadir más crédito usando PayPal, … 4.- Se acondiciona un SIP gateway usando Asterisk o FreeSWITCH 5.- Se añade algún software de cobro a la mezcla y… 6.- Se saca al mercado! ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This normally goes like: Buy any of the existing re-brandable SIP SoftPhones.. Modify it a bit so it registers with your hardcoded SIP domain URL. Integrate your credit & payment facilities (ie. how much credit do I still have, add more credit using paypal, etc.) Setup an asterisk or freeswitch server as gateway.. Add some billing software to the mix.. Go live and offer a really crappy service!
- Bueno, pero antes de seguir adelante, vamos a ver qué es lo que tenemos ahora en nuestro producto...
- Ya estamos usando desde hace un tiempo WebRTC en nuestra aplicación como base de nuestra comunicación por voz app2app...así que el seguir usando WebRTC para las comunicaciones con terminacion GSM parecía una opción bastante viable y obvia… Y además, como motor de medios, WebRTC nos permitía beneficiarnos de su disponibilidad multiplataforma... Nuestra solución de VoIP está montada encima de nuestra infraestructura de chat, basada en XMPP, por lo que también poseíamos los medios necesarios para la señalización… Ya teníamos clientes VoIP para las plataformas más usadas por nuestros clientes: Android, iOS y web. Y además son capaces de interoperar entre las distintas plataformas ya que por debajo todas ellas usan la misma tecnología: WebRTC, ya que no sólo provee clientes para los navegadores web, sino que también provee librerías nativas de cliente usadas en iOS y Android. El proyecto parece que evoluciona rápido y que mucho esfuerzo hay puesto en que se adopte como standard, además proporciona, por ejemplo, codecs tan chulos como Opus, que tiene un comportamiento muy bueno en condiciones de red poco amigables. Si comparamos esto con desarrollar una aplicación completa in-house, podemos darnos cuenta de la cantidad de esfuerzo que te puedes ahorrar usando WebRTC. ------------------------------------------------------------------------------------------------------------------------------------ We already had been using WebRTC in our app as the basis of our App2App voice feature.. so above it all, using WebRTC for bridging calls seemed like a pretty obvious choice. As a media engine, WebRTC allowed us to benefit from multi-platform availability.. So what we have done is building a VoIP solution powered by this WebRTC technology, on top of our existing messaging infrastructure. We have built VoIP clients for the current top client platforms: Web, Android and iOS. They are able to interoperate with each other using the same technology under the hood as WebRTC is not only providing client stack for browsers but also native client libraries on which we are relying. The project is evolving fast, it’s becoming more and more stable and it supports the best possible quality using cool codecs like Opus. Besides, there is a growing community working and building things on top of the platform. If we compare that with dealing with a full in-house effort, it would be really difficult to maintain. With WebRTC we can focus on product high-level tasks and still benefit from WebRTC advances.
- También tenemos la capacidad de tener múltiples recursos activos, por lo que lo único que necesitas es un terminal donde iniciar una nueva sesión. --------------------------------------------------------------------------- We can handle multiple resources for a user.
- Un problema muy común es que la fiabilidad para iniciar una comunicación real-time basándose en notificaciones push, las cuales dependen de terceros y de su capacidad para entregarlas en un tiempo prudencial, por lo que en tuenti, para garantizar una máxima disponibilidad, se ha diseñado un sistema para mantener el socket de la conexión XMPP activo a base de unos ping que mantienen activo el canal aún sin tráfico, dejando así las notificaciones push como ultimísima posibilidad... ------------------------------------------------------------------------------------------------------------------------------------------------------------------- In order to have the maximum connectivity chances, we do not rely on push notifications to awake the app (unless strictly necessary): hybrid model.
- Y por supuesto, la capacidad como operador de telefonía de poder ofrecer a nuestros clientes tráfico de datos entre sus terminales y nuestros servidores de modo gratuito…incluyendo las llamadas de voz sobre IP. -------------------------------------------------------------------------------------------------------------------- With ZeroLimites, there’s no data charge for the use of the app, including VoIP calls.
- Sí, podríamos haber elegido esta ruta también, pero al final, este tipo de soluciones suelen proporcionar una muy mala experiencia de usuario, y además se hubiera hecho muy difícil integrarlo con las funcionalidades ya existentes… Pero...añadiendo algunas piezas más al puzzle, podíamos dar una experiencia de usuario mucha más rica al cliente… Así que decidimos ponernos a buscar esas piezas que nos faltaban… ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- We could have gone this route too, but in the end, this solutions tend to have a bad user experience and are harder to integrate with existing features.. But...adding some more pieces to the puzzle we can give a much richer experience to the user!!!
- Llegados a este punto, me gustaría explicar un poco más en profundidad qué es exactamente WebRTC y qué nos proporciona y qué no.
- WebRTC es un estándar aún en evolución definido por el Web Real-Time Communications Working Group Este grupo clama que su misión es definir las API de cliente para habilitar las comunicaciones en tiempo real en navegadores web. Estas APIs deben habilitar el desarrollo de aplicaciones que puedan ser ejecutadas en navegadores, sin la necesidad de descargas extra ni plugins, y que permitan la comunicación entre partes usando audio, video y comunicaciones en tiempo real suplementarias ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- WebRTC is an upcoming standard Web Real-Time Communications Working Group Charter The mission of the Web Real-Time Communications Working Group, part of the Ubiquitous Web Applications Activity, is to define client-side APIs to enable Real-Time Communications in Web browsers. These APIs should enable building applications that can be run inside a browser, requiring no extra downloads or plugins, that allow communication between parties using audio, video and supplementary real-time communication, without having to use intervening servers (unless needed for firewall traversal, or for providing intermediary services
- En el proyecto WebRTC se tiene un API disponible con las capacidades multimedia que se puedan necesitar. También se definen protocolos de comunicación y se nos proporcionan una serie de codecs, tanto para audio como para video, por lo que se evitan todos los problemas de licencias que puede acarrear usar un codec que la requiera. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- In the WebRTC project you have an API available with the media capabilities you might need, communication protocols are defined and you avoid codec licensing problems.
- Se definen los siguientes transportes para la señalización Qué protocolo de señalización se debe usar para el inicio y control de la sesion multimedia no se especifica en el standard, por lo que se puede usar la que más oportuna se considere. -------------------------------------------------------------------------------------------------------------------------------------------------- Transmission control protocol - TCP User datagram protocol - UDP Stream Control Transmission Protocol - SCTP Signaling is not specified in the standard.
- También se definen los protocolos para el streaming del contenido multimedia: SDES Source Description RTCP (Real-Time Control Protocol) Packet Datagram Transport Layer Security (DTLS) combined with Secure Real-Time Transport Protocol (SRTP)
- Otra pieza clave es el SDP o Session Description Protocol Son los metadatos del medio que se va a transmitir. Describen desde la resolución de video, los formatos y codecs usados hasta la encriptación de la transmisión ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Session Description Protocol (SDP) is a standard for describing the multimedia content of the connection such as resolution, formats, codecs, encryption, etc so that both peers can understand each other once the data is transferring. This is not the media itself but more the metadata.
- Para salvar problemas de conectividad por el uso de NAT se ha definido ICE. ICE es un framework que te permite la conexión entre dos partes. Hay múltiples razones por las que una conexión directa entre dos partes pueda no establecerse: Puede que no se tenga una dirección IP pública. Puede que necesite pasar firewalls que no permitan abrir conexiones. ICE proporciona los medios para conocer la IP pública (o también llamada reflexiva) además de los medios para que la parte abra una conexión a un servidor que actúa como relay de la comunicación. imple Traversal of UDP through NAT (STUN) Traversal Using Relay NAT (TURN) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Interactive Connectivity Establishment (ICE) is a framework to allow your web browser to connect with peers. There are many reasons why a straight up connection from Peer A to Peer B simply won’t work. It needs to bypass firewalls that would prevent opening connections, give you a unique address if like most situations your device doesn’t have a public IP address, and relay data through a server if your router doesn’t allow you to directly connect with peers. Simple Traversal of UDP through NAT (STUN) Traversal Using Relay NAT (TURN)
- Aquí vemos un ejemplo de un escenario donde la conectividad entre ambas partes sería imposible sin el uso de ICE y un servidor TURN Como comenté anteriormente, nuestra señalización se intercambia a través de nuestro canal XMPP existente, donde hemos preparado servidores STUN. No obstante los servidores TURN los tenemos montados fuera de la infraestuctura de chat… ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Signalling is exchanged through our already existing XMPP channel and we set up STUN servers in those same chat servers. Our TURN servers are external to the chat infrastructure though.
- Y para terminar con ICE, se definen las fases del protocolo… Primeramente se recopilan todos los candidatos, usando las tecnicas de STUN y TURN, Para seguidamente enviarselos a la otra parte, Que hace una serie de chequeos de conectividad y selecciona los candidatos mejores Y se envía esa decisión a la otra parte. Lo único que queda sería iniciar la comunicación de medios entre ambos candidatos!!
- Aquí podemos ver la tabla de compatibilidad de los distintos navegadores que hay en el mercado, Se puede apreciar que en general se está apostando por WebRTC, exceptuando dos casos: IE y Safari (Apple) Hace poco ha salido al mercado Firefox Hello (con la versión 34 del navegador) que proporciona comunicación real-time con WebRTC para Mozilla. Bueno, y qué es lo que pasa con estos navegadores?
- Bueno, pues Microsoft nos ha sorprendido hace poco con ORTC, que deberá ser compatible con WebRTC Por lo que traerá el mundo WebRTC a IE, También hay que decir que Google está también involucrado en este proyecto, aunque parezca contradictorio, probablemente cuidando de sus intereses
- Safari de momento no se ha posicionado, por lo que de momento no tiene WebRTC, probablemente está esperando a que se solucione esta batalla que está en ciernes... Quizás el futuro sea unificación de ambas iniciativas ¿Creándo WebRTC 2.0? Ya veremos...
- Bueno, después de este repaso a qué es WebRTC, voy a empezar a hablar de cómo está implementado en tuenti las llamadas VoIP app2app
- Como antes comenté WebRTC no especifica cómo señalizar la sesión, sin embargo tenemos un canal XMPP, que es el que va a ser usado para la señalización necesaria para el inicio y control de la comunicación de medios. Esta comunicación de medios será directa entre ambas partes o podrá ser a través de un servidor TURN.
- Existe un protocolo ideado para la señalización sobre XMPP, y se llama Jingle. Jingle añade los mecanismos para el control de sesiones multimedia peer-to-peer como VoIP o videoconferencia. Fue diseñado por Google y XMPP Standards Foundation Google Talk, por ejemplo, usa la librería libjingle que implementa dicho protocolo y que es de uso público bajo licencia BSD Bueno, pues en tuenti nos encontramos con que Jingle era muy bonito, muy legible por humanos, pero no había una librería para parsear ese XML en iOS, así que nos encontramos en la duda de si implementarla o… --------------------------------------------------------------------------------------------------------------------------------------------------------- Jingle adds peer-to-peer (P2P) session control (signaling) for multimedia interactions such as in Voice over IP(VoIP) or videoconferencing communications. It was designed by Google and the XMPP Standards Foundation. The libjingle library, used by Google Talk to implement Jingle, has been released to the public under a BSD license
- Bueno, también podríamos crear nuestro propio standard… Para que necesitamos que ese SDP sea también parseado junto con el resto del mensaje y transmitido así hasta el otro extremo, para luego ser reconstruido como un texto recreando el original? No vimos un porqué y decidimos crear nuestro propio protocolo: tangle Mucho más fácil de implementar en todas las plataformas que jingle para iOS.
- Aquí tenemos un ejemplo de un típico gráfico de secuencia de los mensajes intercambiados en una llamada de voz sobre ip con WebRTC.
- Como antes he comentado, la aplicación de tuenti permite múltiples sesiones en multiples dispositivos, por lo que ese mismo diagrama, aplicado a dos dispositivos quedaría de este modo. Y bueno, para terminar el repaso de cómo funciona la solución VoIP usada en tuenti, comentar que últimamente nos hemos dedicado a hacer muchas mejoras en la experiencia VoIP, entre las cuales se encuentra la de establecimiento temprano del canal de audio, ya que una de las principales quejas que se pueden tener del protocolo usado por WebRTC es que todo este proceso hasta la conexión del canal de medios lleva bastante tiempo, y desde que se descuelga la llamada, hasta que se empieza a escuchar el audio pueden pasar varios segundos. Este establecimiento temprano del audio mejora hasta casi cero el tiempo de conexión del audio...aunque el diagrama de comunicación quedaría muchísimo más complejo que el de la diapositiva.
- Y bueno, hasta ahora no hemos hablado otra de las principales piezas del puzzle que debemos completar, y esa pieza es SIP
- SIP es efectivamente eso un protocolo que inicia una sesión sobre internet Es un protocolo de señalización sobre IP, usado comúnmente para telecomunicaciones, pudiendo usarse para comunicaciones desde una llamada telefónica hasta una compleja conferencia multimedia colaborativa SIP puede funcionar junto con otros protocolos de capa de aplicación para la identificación y transporte de los medios como pueden ser: SDP para la negociación de los medios Para la transmisión de los mensajes se pueden usar los transportes TCP, UDP o SCTP o incluso WebSockets... Para la transmisión segura de mensajes de señalización se puede usar TLS Para la transmisión de los streams de medios normalmente se emplea RTP o SRTP, aunque también se puede usar SDES o DTLS Hombre, viendo todo esto, parece que es bastante parecido a lo que WebRTC nos ofrece... ------------------------------------------------------------------------------------------------------------------------------------------------------------- So what is SIP? SIP stands for Session Initiation Protocol, and that’s exactly what it is. It’s a type of protocol that initiates a session over the Internet. Known as (Request for Comments) RFC 3261 The Session Initiation Protocol (SIP) is a signaling communications protocol, widely used to initiate a session as simple as a two-way telephone call or as complex as a collaborative multi-media conference session over Internet Protocol (IP) networks. SIP works in conjunction with several other application layer protocols that identify and carry the session media. Media identification and negotiation is achieved with theSession Description Protocol (SDP). For the transmission of media streams (voice, video) SIP typically employs the Real-time Transport Protocol (RTP) or Secure Real-time Transport Protocol (SRTP). For secure transmissions of SIP messages, the protocol may be encrypted with Transport Layer Security (TLS).
- Y aquí podemos ver un escenario típico de SIP donde vemos que existen proxies con y sin estado y toda una serie de pasos en la señalización para el establecimiento de la llamada… SIP es un protocolo muy complejo, con transacciones, dialogos, sesiones, timers y retransmisiones...y está fuera de todo duda implementar más de 20 RFCs...
- Está claro que necesitamos un stack SIP que nos facilite la vida con este protocolo, abstrayéndonos de toda esa selva de diálogos y retransmisiones, y que podamos centrarnos en el desarrollo de la aplicación! Por las fechas que valoramos las distintas opciones que había nos llamaron la atención dos:
- Nuestro primer candidato fue NkSIP, un servidor de aplicaciones SIP, open source creado y desarrollado por Carlos González escrito completamente en erlang. Proporciona el control necesario sobre SIP para dicha abstracción del protocolo y es muy robusto y escalable...podía ser un gran candidato. Pero por el tiempo en que estábamos considerando las opciones, las aplicaciones SIP que se podían desarrollar tenían que estar escritas en erlang, por lo que no nos pareció apropiado acoplarlo de ese modo a la infraestructura de chat que ya poseíamos Hace poco asistí como oyente a una conferencia en Voip2Day dada por Carlos, donde anunciaba que la evolución de NkSIP tendría la capacidad de servir aplicaciones distribuidas, comunicándolas por sockets, dando así la capacidad de desarrollarlas en cualquier tipo de lenguaje.
- API de Oracle que define: Protocol transactions Dialog management Route procession Leaves applications to provide high-level functions
- Y bueno, implementando esa api, tenemos Mobicents, parte de TeleStax, que han desarrollado una solución certificada open source. Ésta es la solución que adoptamos para tener un stack SIP completo. Más adelante hablaré un poco más en profundidad de esto...
- Bueno, hasta ahora tenemos por un lado el mundo de la aplicación, su comunicación VoIP usando WebRTC y señalización usando Tangle, y por el otro SIP, con toda su complejidad… Vamos a ver como encajan entre ellas...
- Este es un típico diagrama de secuencia de mensajes para el inicio de una conexión VoIP de WebRTC...
- Y este es un típico diagrama de secuencia de mensajes para el inicio de una conexión SIP… Y nuestro objetivo es...
- Combinar ambas señalizaciones para que ambos mundos puedan relacionarse entre sí. Así nace el concepto de signaling gateway, que será una nueva pieza en nuestro puzzle que encajará por un lado el mundo Tangle y por el otro lado el mundo SIP...
- Ahora voy a hablar un poco más en profundidad de esta nueva pieza que completa el puzzle de la señalización...
- Como visión general, Su objetivo es manejar la señalización entre ambos protocolos. Al estar basado en SipServlets → es un servlet. Como hemos podido ver en los diagramas de secuencia, parece que existen estados, y transiciones de unos a otros dependiendo de un input, y para manejar esto, hemos usado la libreria de maquina de estados de squirrel. Para la inyección de dependencias usamos el framework de inyección de dependencias para servlets de Google : Guice Servlet FW
- Mobicents nos ofrece una amplia gama de productos, de los cuales hacemos uso de dos: SipServlets y jDiameter Mobicents SIP Servlets is the first open source certified implementation of the SIP Servlet v1.1 (JSR 289 Spec) on top of Tomcat and jBoss containers. Como hemos comentado, usamos SipServlets para nuestro GW de señalización, los cuales se montan sobre el stack JAIN-SIP y sobre los contenedores JBoss y Tomcat. En nuestro caso, estamos usando un servidor JBoss como contenedor. Diameter es un protocolo usado para la facturación, contabilizando el crédito que se va gastando con cada llamada, y jDiameter es la implementación de Mobicents en Java del servidor que registra todo este consumo a través de dicho protocolo.
- HTTP servlets typically return HTML pages to clients, while SIP servlets typically connect SIP-enabled clients. SIP servlets can be seen as a link between two SIP devices. SIP is a peer-to-peer protocol and SIP servlets can originate SIP requests, while HTTP is a client-server protocol and HTTP servlets cannot originate requests. SIP servlets can generate multiple responses for one request. There are often several SIP servlets that handle the same SIP request, while a HTTP request is handled by an unique HTTPservlet.
- Dentro de SIP servlets, se define el concepto de aplicación convergente. Cuando decimos que aplicación SIP es una aplicación convergente, quiere decir que una sesión de dicha aplicación puede contener una o más sesiones SIP y puede también contener sesiones HTTP. Hay muchos casos de uso dónde es útil el poder unir ambos mundos, como puede ser una aplicación web click-to-call, poder acceder a las presencias de los distintos clientes o incluso poder acceder a la configuración de la cuenta...
- Y también puede servir para comunicar con nuestro protocolo Tangle. Bueno, y exactamente, cómo se comunican ambos mundos? Tangle y SIP? Como he comentado, los mensajes de señalización viajan por nuestra infraestructura de chat, dicha infraestructura, cuando se encuentra con un mensaje tangle, lo empaqueta en una petición http la cual se envía a la aplicación SIP que está ejecutándose en un JBoss. Dicha aplicación convergente SIP recibe la petición HTTP a la que asocia una sesión HTTP y se asocia a una sesión de aplicación. Todas las subsiguientes peticiones que sean referentes a la misma llamada deberán llevar la misma sesión HTTP que se devuelve junto con la respuesta a la primera petición HTTP. Por ejemplo, para una llamada iniciada en la aplicación se generará un mensaje session-initiate que viajará por XMPP hasta el servidor de chat, el cual lo retransmitirá empaquetado en una petición HTTP hasta nuestro GW, el cual creará una nueva sesión de aplicación y una nueva sesión y petición SIP que se enviará al proveedor SIP de turno... De ese modo podremos relacionar por un lado la pata Tangle y por el otro lado la pata SIP dentro de una única sesión de aplicación.
- Por otro lado, y teniendo en cuenta que las posibilidades del stack SIP pueden cambiar en un futuro, como parece que puede pasar con NkSIP y sus aplicaciones distribuidas, decidimos hacer una arquitectura donde pudiéramos separar claramente nuestra lógica de negocio de los detalles. Así nacieron todos los módulos de especificaciones, donde definimos claramente a través de interfaces nuestro protocolo Tangle, y su extensión para ser usados en servlets, así como la interfaz de nuestro CallBridge, donde estará nuestra lógica de negocio. jBoss 7.2: The whole solution will run over a jBoss 7.2 server. Oracle SIP Servlet Spec: It is the specification for the framework. Mobicents SIP Servlets 3.0: This dependency is the implementation made by Mobicents of Oracle’s SIP Servlet Spec. Tangle Spec: Defines the specification of the Tangle protocol. Tangle Servlet Spec: Defines the extensions needed by Tangle spec to be used in a servlet. Call Bridge Spec: Represents the specification for the Bridging BL. Call Bridge Impl: This module has all the business logic for bridging calls Voice Call Bridge Servlet: Will serve as the entry point for the SIP and HTTP requests, handling the Session Verification and delegating the actions to the Call Bridge.
- Desde el principio hemos tenido muy claro qué es lo que queríamos que hiciera nuestro gateway, teníamos unos casos de uso o escenarios muy especificados… tan especificados que teníamos hasta mensajes de secuencia que los representaban… Por lo que, una vez definidos los interfaces de nuestro protocolo Tangle y de nuestro CallBridge, lo único que debíamos hacer es escribir los tests de integración que representaran todos esos casos de uso que teníamos, que no eran pocos… Y bueno...con una serie de tests escritos, lo único que nos quedaba, era el desarrollo de la aplicación para que todos esos tests pasaran de rojo a verde… No os suena este tipo de desarrollo? Puedo decir que con este desarrollo hemos conseguido un software muy robusto, ya que, aunque había casos que no se habían contemplado desde un principio, los que sí que se habían contemplado funcionaron perfectamente desde el principio.
- Como hemos visto por los diagramas de secuencia de mensajes, parecía bastante evidente que ibamos a necesitar una maquina de estados que representara el estado de la llamada. Para ello hemos usado squirrel y hemos definido los estados que han sido necesarios …….. Así como las transiciones entre los distintos estados, dependiendo del input recibido, ya sea desde la pata tangle, como de la pata sip, como de timeouts internos: ……..
- Hasta ahora hemos asumido que el canal de medios se establece mágicamente una vez que la señalización especifica cuales son los candidatos, pero nada más lejos de la realidad… Existe mucha complejidad en esto, y aunque no quiero meterme de lleno en este tema, sí que quiero comentar algunas nociones básicas de cómo lo hemos montado en tuenti...
- Como hemos visto, a través del protocolo ICE se seleccionan los mejores candidatos, y , una vez seleccionados, se abre una conexión SRTP/SDES a través de un TURN server o directamente con un FreeSwitch que actúa como Session Border Controller y Transcoder, el cual nos conecta con nuestro proveedor SIP a través de una conexión RTP. También tengo que mencionar que, para una buena experiencia de usuario, hemos tenido que pelear, y seguimos haciéndolo con los codecs, ya que una buena elección de éstos hace que la experiencia mejore enormemente. Esa es una de las principales razones por las que se ha decidido poner un SBC al final de nuestra infraestructura, ya que, por ejemplo, dependiendo del proveedor SIP, y del fabricante que gaste, van a poder ofrecernos más o menos codecs, en este caso estamos usando uno muy común en telefonía : G711 Otro problema que nos hemos encontrado es que, dependiendo de la plataforma, funciona mejor un códec u otro. Así, para iOS estamos usando iSAC, ya que el dispositivo posee un circuito para su codificacion/decodificación por hardware, y funciona genial, y para android todo lo contrario, aparte, Opus funciona bastante bien en estos dispositivos y en condiciones de red poco amigables.
- Para terminar me gustaría daros una pincelada de la infraestructura que tenemos montada para dar alta disponibilidad al servicio de VozDigital
- Y así quedaría la foto completa de todos los elementos involucrados en la conexión de una llamada de VozDigital
- No puedo terminar esta charla sin mencionar esas herramientas que han conseguido que nuestra vida sea un poquito más fácil...
- En la fase de desarrollo del servicio hemos usado SNGrep, Visor de flujos SIP, UDP no TCP, ongoing...
- Ya en producción no se puede andar a bajo nivel trasteando con las máquinas, por lo que necesitabamos un software que pudiera darnos todos los detalles de cualquier llamada que se cursara usando nuestro servicio...
- Para el cálculo de estadísticas de llamadas, típicas en una telco, usamos CDR-stats
- Por último, mencionar que todo este servicio está monitorizado con graphite, dándonos de un vistazo, el estado de salud del mismo...