MAESTRIA EN INGENIERIA DE...

MAESTRIA EN INGENIERIA DE TELECOMUNICACIONES

Tesis de Maestría

Tema: Tesis de Comunicaciones Multimedia.

Título: Diseño de un sistema de comunicación convergente de Navegador Web a Asterisk para un canal de atención al cliente.

Autor: Ing. Pedro Coronel Delgado

Tutor: Ing. Daniel Cordes / Ing. Roberto Sánchez

Año: 2014

Diseño de un sistema de comunicación convergente de Navegador Web a Asterisk para un canal de atención al cliente. Maestría en Ingeniería de Telecomunicaciones

ii Ing. Pedro Coronel Delgado Mayo 2014

Agradecimientos

Quiero agradecer de forma especial a Daniel Cordes por todo su conocimiento y

aporte brindado para la realización de este proyecto. De igual manera a Roberto

Sánchez por su interés y motivación hacia mi persona.

Agradezco infinitamente a mi esposa Dayana por todo el amor, la paciencia y apoyo

para la culminación de esta etapa, ella ha sido un pilar muy importante para mí.

También agradezco a mis padres, quienes desde pequeño me inculcaron el valor de la

responsabilidad y la constancia para alcanzar mis metas propuestas.


iii Ing. Pedro Coronel Delgado Mayo 2014

Resumen

En este documento se presenta el diseño de un sistema de comunicación

convergente desde un navegador web a una PBX-IP Asterisk para un canal de

atención al cliente. Este diseño se realiza en base a nuevas tecnologías como es el

estándar WebRTC que en integración con tecnologías inalámbricas NFC y servidor de

telefonía IP como Asterisk permiten establecer una comunicación automática y en

tiempo real.

Además del diseño, se realiza parte de la implementación del sistema utilizando

aplicaciones y software de código abierto, que resulta ser una solución práctica y a

bajo costo.

De igual manera el presente trabajo aporta con una base de conocimientos sobre

cómo el estándar WebRTC propone integrarse a los sistemas de comunicación

existentes impulsando a la nueva generación de servicios de comunicaciones IP.

Abstract

This paper presents the design of a converged communication system from a web

browser to an IP-PBX Asterisk for a customer service channel. This design is performed

based on new technologies such as WebRTC standard at integration with IP telephony

server like Asterisk and wireless technologies like NFC allow an automatic and real-

time communication.

Besides the design, a part of the implementation of the system is performed using

applications and software open source code, which turns out to be a practical solution

at low cost.

Similarly, the present study provides a base of knowledge about how the WebRTC

standard proposes integrated into existing communication systems promoting the next-

generation IP communications services


iv Ing. Pedro Coronel Delgado Mayo 2014

Contenido Agradecimientos .......................................................................................................................... ii

Resumen.......................................................................................................................................iii

Abstract .........................................................................................................................................iii

Ilustraciones ................................................................................................................................. ix

Glosario ......................................................................................................................................... xi

I. INTRODUCCIÓN ................................................................................................................. 1

II. FUNDAMENTACION DEL TEMA ..................................................................................... 2

a. Definición de la necesidad ............................................................................................. 3

b. Antecedentes del tema ................................................................................................... 3

c. Estado actual del tema ................................................................................................... 4

d. Planteo del problema ...................................................................................................... 4

III. OBJETIVOS & HIPÓTESIS ........................................................................................... 4

a. Objetivo General .............................................................................................................. 4

b. Objetivos Específicos...................................................................................................... 4

c. Hipótesis ........................................................................................................................... 5

CAPÍTULO 1 ................................................................................................................................ 6

Introducción Teórica de Tecnologías Utilizadas ..................................................................... 6

1.1. Introducción a la Voz sobre IP (VoIP) ...................................................................... 6

1.1.1. Características de VoIP .......................................................................................... 6

1.1.2. Consideraciones de VoIP ....................................................................................... 7

1.1.3. Elementos implicados en VoIP .............................................................................. 7

1.2. Protocolo SIP ............................................................................................................... 9

1.2.1. Conceptos generales .............................................................................................. 9

1.2.2. Concepto de Proxy Server ................................................................................... 10

1.2.3. Concepto de Servidor de Registro ...................................................................... 11

1.2.4. Ejemplo de una comunicación SIP y sus mensajes. ....................................... 12

1.2.5. Descripción de los campos del encabezado del mensaje. ............................. 13


v Ing. Pedro Coronel Delgado Mayo 2014

1.3. Introducción a Web Real-Time Communication ................................................... 15

1.3.1. Introducción a WebRTC ....................................................................................... 15

1.3.2. Elementos de un sistema WebRTC ................................................................... 16

1.3.3. Aplicaciones WebRTC .......................................................................................... 17

1.3.4. Integración de WebRTC con redes de comunicaciones. ................................ 19

1.3.4.1. WebRTC y la red de telefonía pública (PSTN) ......................................... 19

1.3.4.2. WebRTC y redes IMS (IP Multimedia Subsystem) .................................. 20

1.3.5. Consideraciones de implementación WebRTC ................................................ 21

1.3.6. Arquitectura WebRTC ........................................................................................... 22

1.3.7. Protocolos webrtc .................................................................................................. 23

1.3.7.1. Protocolo HTTP ............................................................................................. 23

1.3.7.2. Protocolo Websocket .................................................................................... 24

1.3.7.3. RTP (Real-Time Transport Protocol) y Secure RTP (SRTP) ................. 24

1.3.7.4. SDP (Session Description Protocol) ........................................................... 25

1.3.7.5. TLS (Transport Layer Security) ................................................................... 26

1.3.8. Códecs WebRTC ................................................................................................... 26

1.3.8.1. Códec de Audio Opus ................................................................................... 26

1.3.8.2. Códec de Video VP8 ..................................................................................... 27

1.3.9. Modelo Web y RTC ............................................................................................... 27

1.3.10. WebRTC y SIP ................................................................................................... 29

1.3.10.1. SIP sobre Websocket ................................................................................... 30

1.4. Introducción a Near Field Communication, NFC .................................................. 32

1.4.1. Características Técnicas ...................................................................................... 32

1.4.2. Modos de funcionamiento .................................................................................... 33

1.4.3. Estándares y Protocolos NFC ............................................................................. 34

1.4.4. Arquitectura NFC ................................................................................................... 35

CAPÍTULO 2. ............................................................................................................................. 37

Descripción de Sistemas de la solución ................................................................................ 37

2.1. Central IP-Servidor Asterisk .................................................................................... 37

2.1.1. Introducción a Asterisk ......................................................................................... 37


vi Ing. Pedro Coronel Delgado Mayo 2014

2.1.2. ¿Qué es Asterisk? ................................................................................................. 37

2.1.3. Arquitectura de Asterisk ....................................................................................... 39

2.1.4. Tipos de módulos de Asterisk ............................................................................. 40

2.1.4.1. Drivers de Canales ........................................................................................ 40

2.1.4.2. Aplicaciones de Dialplan .............................................................................. 40

2.1.4.3. Funciones de Dialplan .................................................................................. 40

2.1.4.4. Recursos ......................................................................................................... 41

2.1.4.5. Códec y Formatos ......................................................................................... 41

2.1.4.6. Drivers de Registro detallado de llamadas (CDR) ................................... 41

2.1.4.7. Drivers de registro de eventos de llamada (CEL) .................................... 42

2.1.4.8. Módulo Bridging ............................................................................................. 42

2.1.4.9. Interface de línea de comandos (CLI) ........................................................ 42

2.1.4.10. Asterisk Manager Interface .......................................................................... 42

2.1.4.11. Interface Asterisk Gateway .......................................................................... 43

2.1.5. Archivos de configuración. ................................................................................... 43

2.1.6. Descripción breve del flujo de llamadas. ........................................................... 44

2.1.7. Versiones de Asterisk ........................................................................................... 45

2.2. Introducción a Servidor Web ................................................................................... 46

2.2.1. Servidores web más utilizados ............................................................................ 46

2.2.2. Servidor Web Apache ........................................................................................... 47

2.2.2.1. Arquitectura del servidor Apache ................................................................ 49

2.2.2.2. Archivo de configuración de Apache. ......................................................... 50

2.2.2.3. Virtual Hosts ................................................................................................... 51

2.2.2.4. Versiones de Apache .................................................................................... 51

2.3. Navegador WEB ........................................................................................................ 52

2.3.1. Introducción a Navegador web. .......................................................................... 52

2.3.2. Componentes de un navegador web ................................................................. 53

2.3.3. Navegadores y versiones que soportan el estándar WebRTC ...................... 55

2.3.3.1. Google Chrome.............................................................................................. 55

2.3.3.2. Mozilla Firefox ................................................................................................ 55


vii Ing. Pedro Coronel Delgado Mayo 2014

2.4. Aplicación Softphone ................................................................................................ 56

2.4.1. Introducción a un Softphone ................................................................................ 56

2.5. Esquema de Red Integral de la solución ............................................................... 58

CAPÍTULO 3 .............................................................................................................................. 59

Diseño de la solución. ............................................................................................................... 59

3.1. Evaluación de la página actual de la empresa o institución. .............................. 59

3.3. Lenguaje de programación HTML-HTML5 ............................................................ 62

3.3.1. Mediastream........................................................................................................... 63

3.3.2. RTCpeerConnection. ............................................................................................ 63

3.3.3. RTCDataChannel. ................................................................................................. 64

3.4. Establecimiento y Derivación de la llamada.......................................................... 65

3.4.1. Registro de una extensión ................................................................................... 65

3.4.2. Generación del mensaje INVITE......................................................................... 66

3.4.3. Derivación de la llamada ...................................................................................... 67

3.5. Elementos y APIs para el soporte de WebRTC en Asterisk ............................... 68

3.5.1. JAIN SIP ................................................................................................................. 69

3.5.2. res_http_websocket. ............................................................................................. 69

3.5.3. chan_sip. ................................................................................................................. 69

3.5.4. res_rtp_asterisk. .................................................................................................... 69

3.5.5. res_srtp. .................................................................................................................. 70

3.5.6. chan_pjsip. ............................................................................................................. 70

3.6. Librerías necesarias para compilar Asterisk ......................................................... 70

CAPITULO 4 .............................................................................................................................. 72

Diseño del Sistema NFC. ..................................................................................................... 72

4.1. Descripción de la aplicación softphone y NFC en el smartphone. .................... 72

4.2. Diseño y descripción del Software de funcionamiento ........................................ 74

4.2.1. Formato NDEF ....................................................................................................... 75

4.3. Diseño y descripción del hardware de funcionamiento. .......................................... 77

4.3.1. Características y funcionalidades del lector NFC ACR 122 USB. ...................... 78

CAPITULO 5 .............................................................................................................................. 80


viii Ing. Pedro Coronel Delgado Mayo 2014

Implementación y configuración del sistema de llamada.................................................... 80

5.1. Esquema de Red de la implementación. ............................................................... 80

5.2. Configuración del servidor Asterisk ........................................................................ 81

5.3. Configuración y Registro de una extensión desde el clienteSIPML5................ 84

5.3.1. Descripción del webphone SIPML5................................................................ 84

5.3.2. Configuración del webphone SIPML5. ........................................................... 84

5.4. Configuración de la extensión SIP en el softphone ............................................. 87

5.5. Realización de llamadas de prueba. ...................................................................... 88

5.6. Medición y análisis de la comunicación. ................................................................ 91

5.6.1. Consola Javascript ............................................................................................ 92

5.6.2. chrome://webrtc-internals/ ................................................................................ 93

5.6.3. Consola Asterisk y archivos de registro. ........................................................ 95

5.6.4. Wireshark ............................................................................................................ 98

Conclusiones ............................................................................................................................ 101

Recomendaciones ................................................................................................................... 103

Trabajos citados ...................................................................................................................... 104

Anexo A .................................................................................................................................... 106

Instalación y compilación de Asterisk 12 ......................................................................... 106

Anexo B .................................................................................................................................... 109

Herramientas WebRTC para NAT/Firewall Traversal ................................................... 109


ix Ing. Pedro Coronel Delgado Mayo 2014

Ilustraciones

Ilustración 1. Entorno de voz sobre IP ..................................................................................... 8 Ilustración 2. Comunicación SIP ............................................................................................. 10 Ilustración 3. Comunicación SIP con Proxy .......................................................................... 11 Ilustración 4. Establecimiento de una comunicación SIP ................................................... 12 Ilustración 5. Comunicación SIP con dos proxys. ................................................................ 13 Ilustración 6. Sistema WebRTC .............................................................................................. 17 Ilustración 7. Arquitectura WebRTC. 1 .................................................................................. 22 Ilustración 8. Protocolos webrtc según el nivel de capas. .................................................. 23 Ilustración 9. Modelo web de RTC. ........................................................................................ 28 Ilustración 10. Establecimiento de una comunicación SIP mediante WEB. .................... 30 Ilustración 11. Establecimiento de una comunicación SIP a través de Websocket. ...... 31 Ilustración 12. Comunicación NFC modo pasivo. ................................................................ 33 Ilustración 13. Comunicación NFC modo activo. ................................................................. 34 Ilustración 14. Arquitectura NFC. ............................................................................................ 36 Ilustración 15. Arquitectura Asterisk. ...................................................................................... 39 Ilustración 16. Estadísticas de los servidores web más utilizados. ................................... 47 Ilustración 17. Arquitectura del servidor Apache. ................................................................. 49 Ilustración 18. Servidores web más utilizados. ..................................................................... 53 Ilustración 19. Componentes de un navegador web. .......................................................... 54 Ilustración 20. Esquema de red de la solución. .................................................................... 58 Ilustración 21. Ejemplo de página web canal de atención al cliente. ................................ 60 Ilustración 22. Página web de la institución. ......................................................................... 60 Ilustración 23. Diseño gráfico de la página web “Llamenos”. ............................................. 61 Ilustración 24. Diseño gráfico del canal de atención al cliente. ......................................... 62 Ilustración 25. Diagrama de bloques del registro de una extensión. ................................ 66 Ilustración 26. Diagrama de bloques del mensaje INVITE ................................................. 67 Ilustración 27. Diagrama de bloques de la derivación de la llamada. ............................... 68 Ilustración 28. Aplicación Softphone en Smartphone. ......................................................... 73 Ilustración 29. Conectividad NFC entre Softphone y Navegador Web. ............................ 73 Ilustración 30. Arquitectura Modo peer-to-peer. ................................................................... 74 Ilustración 31. Estructura del Mensaje NDEF. ...................................................................... 75 Ilustración 32. Diagrama de bloques del funcionamiento NFC. ......................................... 76 Ilustración 33. Placa lector/escritor NFC. .............................................................................. 77 Ilustración 34. Lector NFC ACR-122 USB. ........................................................................... 78 Ilustración 35. Diagrama de red de implementación. .......................................................... 81 Ilustración 36. Página inicio webphone. ................................................................................ 85


x Ing. Pedro Coronel Delgado Mayo 2014

Ilustración 37. Webphone Expert Mode................................................................................. 86 Ilustración 38. Configuración de la extensión SIP. .............................................................. 87 Ilustración 39. Configuración de cuenta en softphone Zoiper. ........................................... 88 Ilustración 40. Llamada a una extensión. .............................................................................. 89 Ilustración 41. Permitir acceso a micrófono. ......................................................................... 89 Ilustración 42. Llamada en progreso. ..................................................................................... 90 Ilustración 43. Establecimiento de la sesión de media........................................................ 91 Ilustración 44. Consola javascript. .......................................................................................... 92 Ilustración 45. Estadísticas canal 1 webrtc-internals. .......................................................... 94 Ilustración 46. Estadísticas gráficas de webrtc-internals. ................................................... 95 Ilustración 47. Archivos de registro. ....................................................................................... 96 Ilustración 48. SIP debug en Consola Asterisk. ................................................................... 97 Ilustración 49. RTP debug en consola Asterisk. ................................................................... 98 Ilustración 50. Análisis de TLS en Wireshark. ...................................................................... 99 Ilustración 51. Desencriptación de TLS en Wireshark. ..................................................... 100


xi Ing. Pedro Coronel Delgado Mayo 2014

Glosario

3GPP. 3rd Generation Partnership Project

AGI. Asterisk Gateway Interface.

API. Application Programming Interfaces.

CBR. Constant Bit Rate.

CCID. Community Colleges for International Developmen

CDR. Call Detail Record.

CEL. Channel Event Logging

CLI. Command Line Interface

CSS. Cascading Style Sheets

CSV. Comma-separated values

CTI. Computer Telephony Integration

DTLS. Datagram Transport Layer Security

DTMF. Dual Tone Multi Frequency

HTML. HyperText Markup Language

HTTP. Hypertext Transfer Protocol

ICE. Interactive Connectivity Establishment

IETF. Internet Engineering Task Force

IP. Internet Protocol

LAN. Local Area Network


xii Ing. Pedro Coronel Delgado Mayo 2014

LLCP. Logical Link Control Protocol

LTS. Long Term Support

MIME. Multipurpose Internet Mail Extensions

NAT. Network Address Translation

NCSA. National Center for Supercomputing Applications

NDEF. NFC Data Exchange Format

NFC. Near Field Communication

NNI. Network to Network Interface

OTT. Over the top

PBX. Private Branch Exchange

PLMN. Public Lane Mobile Network

PSTN. Public Switched Telephone Network

RFC. Request for comments

RFID. Radio Frequency IDentification

RTCP. Real Time Control Protocol

RTD. Record Type Definition

RTP. Real-Time Transport Protocol

SIP. Session Initial Protocol

SRTP. Secure Real-time Transport Protocol

SSL. Secure Sockets Layer

STUN. Session Traversal Utilities for NAT


xiii Ing. Pedro Coronel Delgado Mayo 2014

TCP. Transmission Control Protocol

TLS. Transport Layer Security

TURN. Traversal Using Relay NAT

UDP. User Datagram Protocol

URI. Uniform Resource Identifier

URL. Uniform resource locator

URN. Uniform Resource Name

USB. Universal Serial Bus

VBR. Variable bitrate

VoIP. Voz sobre IP

W3C. World Wide Web Consortium

WAN. wide area network

WS. websocket

WSS. Websocket secure


1 Ing. Pedro Coronel Delgado Mayo 2014

I. INTRODUCCIÓN

En la actualidad el rápido avance de las Tecnologías de Información y

Comunicaciones (TICS) y el considerable crecimiento y fuerte implementación de las

redes IP han permitido la convergencia de servicios como la telefonía hacia la red de

datos IP denominado Voz sobre IP (VoIP). Esto se puede lograr gracias a las

diferentes técnicas avanzadas de digitalización de voz, mecanismos de control y

priorización de tráfico, protocolos de trasmisión en tiempo real, así como el estudio de

nuevos estándares de calidad de servicio en redes IP.

Con dicho avance tecnológico también aparecieron las centrales IP (PBX-IP)

basadas en software libre que permiten un completo sistema de comunicaciones

unificadas. Por ejemplo: servicio de buzón de voz, conferencias, fax, video llamadas,

servicio de mail, llamadas en espera, base de datos. Todo este sistema en conjunto

permite a las empresas mejorar en sus procesos, reduciendo tiempos y maximizando

recursos. Por ejemplo en el proceso de atención al cliente, se crea uno o varios

canales de comunicaciones ya sean de voz, mail o chat para atender al cliente de

forma eficaz y rápida.

Además con el desarrollo de nuevas tecnologías aparece un estándar de

comunicaciones en tiempo real que se encuentra en fase de desarrollo. Es el

denominado WebRTC, que se basa en una comunicación de audio y video desde un

navegador web directamente, sin necesidad de instalar algún software o pluggin

adicionales.

El presente trabajo realiza un estudio y diseño de un sistema convergente de

comunicaciones para atención al cliente basado en una central IP de software libre

(Asterisk) hacia un navegador web utilizando además tecnología NFC (Near Field

Communication) para la derivación de la llamada.



El trabajo se distribuye en 5 capítulos, el primer capítulo hace referencia a la

Introducción de VoIP y sus protocolos (SIP,H323 IAX), descripción del estándar

WebRTC y sus respectivos códecs, además de la descripción del protocolo NFC. El

capítulo 2 realiza una descripción de los sistemas a utilizar: Central PBX-IP Asterisk,

Servidor Web, el o los exploradores web que soportan WebRTC, y la respectiva

aplicación de softphone para el Smartphone. El capítulo 3 presenta el diseño y la

configuración del sistema Asterisk y Explorador Web basado en HTML5. El cuarto

capítulo estudia y diseña el sistema NFC que permitirá la derivación de la

comunicación entre Asterisk y el navegador web. El último capítulo presenta la

implementación de parte del proyecto, realizando una comunicación entre el navegador

web y un softphone registrado en un servidor Asterisk.

II. FUNDAMENTACION DEL TEMA

El desarrollo de nuevas tecnologías de telecomunicaciones produce una

convergencia en los sistemas existentes. Cada vez se integran más servicios desde un

sistema ya implementado. Un claro ejemplo de esto es la tecnología de VoIP que en un

principio fue solamente comunicaciones de audio y luego integró el video para las

videoconferencias.

En la actualidad la mayoría de empresas cuentan con un sistema de

comunicaciones unificadas basadas en Asterisk, como por ejemplo: Ciba SRL que

migraron su call center de emergencias en Rosario. Integral Insumos SC Sunchales-

Argentina. Outsourcing 4 IT en Colombia. Boston Medical Group.

Un sistema de comunicaciones unificadas consta de comunicaciones de voz,

videollamadas, Base de datos, servicio de mail, fax. Las empresas buscan integrar su

sistema con las nuevas tecnologías que aparecen para mantenerse actualizados y

ofrecer un mejor servicio a sus clientes.



Un ejemplo de estas nuevas tecnologías es el estándar WebRTC desarrollado por

Google y de código abierto. Este se basa en una comunicación en tiempo real a través

del explorador web sin la necesidad de instalar aplicaciones nativas ni pluggins.

El sistema de central PBX Asterisk está desarrollando nuevas actualizaciones para

soportar el estándar WebRTC y permitir la integración de un sistema de

comunicaciones completo entre teléfonos IP y un explorador web.

a. Definición de la necesidad Las empresas siempre buscan la mejor manera de brindar atención al cliente por

diferentes medios, ya sea telefónico, mail o por chat. Ahora también se están

desarrollando nuevos canales de comunicación y atención al cliente como ‘’click-to-call”

directamente desde la página web.

Lo que se busca es mejorar la atención al cliente sin perder ninguna comunicación

presentando atención personalizada y directa con el cliente. Si el cliente llama

directamente de la página web y el operador no se encuentra en su puesto de trabajo

se deriva la llamada al softphone del celular conectado a la central asterisk. Cuando

regresa a su estación de trabajo, acerca el teléfono a un lector NFC y automáticamente

abre el explorador web y se deriva la llamada para una video comunicación directa.

Es importante mencionar que WebRTC está disponible en la mayoría de dispositivos

móviles que tengan un explorador web, Google Chrome o Mozilla. Es decir que no

necesita ninguna aplicación adicional. Anteriormente se podía realizar esto con Flash

pero Adobe retiro el soporte a dispositivos móviles.

b. Antecedentes del tema En el pasado se realizaban llamadas únicamente de voz, se tenían sistemas

propietarios de arquitectura cerrada, luego se implementaron equipos (gateways) que

permitían interconectar con redes públicas como la PSTN, Se pasó de la telefonía

tradicional a VoIP que de igual forma soportaba videollamadas pero en un entorno

privado empresarial.



La atención del cliente se realizaba únicamente por llamada telefónica al cual

primero la atiende una operadora automática. Se presentaban esperas y

congestionamiento de llamadas.

c. Estado actual del tema WebRTC está en fase de desarrollo y cada institución está desarrollando sus

aplicaciones, software y hardware necesario para contribuir con esta nueva tecnología

de telecomunicaciones. En la actualidad las empresas tienen implementados sus

sistemas de comunicaciones unificadas y desean integrarse con tecnologías abiertas.

Las empresas hoy en día ofrecen atención al cliente por comunicación de voz,

servicio de mail, chat o click-to-call en la página web con aplicaciones de terceros

como Skype para brindar atención personalizada.

d. Planteo del problema ¿Cómo realizar un sistema de comunicación de audio y video convergente de VoIP

a WebRTC?.

III. OBJETIVOS & HIPÓTESIS

a. Objetivo General El objetivo general del trabajo es diseñar un nuevo canal de atención al cliente

integrando tecnologías de VoIP, Servicios Web y NFC.

b. Objetivos Específicos -Relevar información del sistema existente de comunicaciones.

-Describir las actualizaciones del sistema Asterisk existente para soportar WebRTC.

-Diseñar el canal de atención al cliente en la página web existente de la empresa.



-Describir el sistema de derivación de la llamada de Asterisk al explorador web.

-Diseñar el sistema (software y hardware) NFC para permitir la derivación de la

llamada.

-Implementar y configurar una parte del sistema configurando un servidor Asterisk y un

navegador web para realizar una llamada.

-Realizar un análisis del establecimiento y curso de la llamada con un sniffer de red y

VoIP para solucionar posibles problemas.

c. Hipótesis El servicio de atención al cliente de una empresa se mejora con un sistema de

comunicación de audio y video convergente de VoiP (Asterisk) a WebRTC.



CAPÍTULO 1

Introducción Teórica de Tecnologías Utilizadas

En este capítulo se presenta una introducción teórica de las tecnologías de VoIP en

conjunto con el nuevo estándar WebRTC y la tecnología inalámbrica NFC. Incluye sus

características, protocolos y estándares así como su arquitectura.

1.1. Introducción a la Voz sobre IP (VoIP)

La VoIP simplemente es una tecnología que permite trasmitir voz sobre las redes de

datos IP (Internet, LAN, etc.). La telefonía IP permite llamadas telefónicas a través de

la red de datos. Cuando se realiza una llamada de voz, esta se digitaliza, se comprime

y se envía en paquetes de datos. Estos paquetes se envían a través de Internet a la

persona con la que se conversa, los paquetes se ensamblan, se descomprimen y se

convierten en la señal de voz original. El protocolo IP transporta paquetes de datos en

2 formatos básicos, UDP o TCP.

La tecnología de VoIP se encuentra ahora en su estado de madurez, comenzando

por los años 90.

1.1.1. Características de VoIP

Entre sus características principales se tiene:

• Administración de una sola red.



• Se basa en estándares abiertos e internacionales. Interoperabilidad.

Disminución de precios de proveedores.

• Es posible conseguir una misma calidad, de hecho hoy por hoy el 40% de las

llamadas de las grandes operadoras se encaminan por VoIP.

• En redes locales se puede lograr una gran fiabilidad al igual que en Internet

pero hay algunos aspectos que afectan.

• La VoIP tiene la posibilidad de desarrollar nuevos servicios rápidamente. Menor

inversión inicial, costos más bajos para los clientes.

1.1.2. Consideraciones de VoIP

Con VoIP aparecen problemas que no existían o estaban solucionados con la

telefonía tradicional y que afectan a la calidad de servicio (QoS).

• Requerimiento de ancho de banda.

• Funciones de control.

• Latencia o retardo (>150ms impracticable)

• Jitter: Variación de Latencia.

1.1.3. Elementos implicados en VoIP

Teléfonos IP. Físicamente son teléfonos normales con apariencia tradicional.

Incorporan un conector RJ45 para conectar directamente a una red IP.

Adaptadores analógicos IP. Permiten aprovechar los teléfonos analógicos,

transformando su señal analógica en los protocolos de VoIP.

Softphones. Son programas que permiten llamar desde una PC utilizando

tecnología VoIP. Ejemplo: Skype, google talk, xlite, sjphone, etc.



Centrales IP (PBX-IP). Centrales de telefonía que permiten utilizar de forma

combinada la tecnología VoIP (mixtas) o exclusivamente IP (puras).

Protocolo. Es el conjunto de reglas o normas, "lenguaje" que se utilizan para negociar

y establecer las comunicaciones de voz sobre IP. Los más importantes son: SIP, H323,

IAX2, MGCP.

Códec. Es la forma de digitalizar la voz humana para ser enviada por las redes de

datos. Algunos ejemplos: G.711, G.723, G729A, GSM, iLBC. Los códec se utilizan para

transformar la señal de voz analógica en una señal digital.

El protocolo para transportar los paquetes de audio o video es RTP (Real

Time Protocol). (Communicat, 2010)

Ilustración 1. Entorno de voz sobre IP

1



1.2. Protocolo SIP

SIP (Session Initiation Protocol) es un protocolo de control implementado por el

IETF (RFC3261), basado en arquitectura cliente/servidor similar al HTTP, con el que

comparte muchos códigos de estado y sigue una estructura de petición-respuesta. Es

principalmente un protocolo de señalización de capa de aplicación para

iniciación, modificación y terminación de sesiones de comunicación multimedia entre

usuarios.

1.2.1. Conceptos generales

Los principales elementos implicados son:

- User Agent (Usuario)

- Servidor Registrar y SIP Proxy.

Las funciones principales de SIP son:

• La localización del usuario.

• La disponibilidad del usuario: determinación de la voluntad del receptor de la

llamada en participar en las comunicaciones.

• Capacidad del usuario: Determinación del medio y de sus parámetros.

• Gestión de la sesión: transferencia, terminación de sesiones, modificación de

los parámetros de la sesión desde el propio 'User Agent'.

• El protocolo SIP es de forma nativa “peer to peer”: Dos ‘User Agents’ pueden

establecer una sesión entre sí:

Una comunicación SIP utiliza dos canales.

- Señalización (UDP 5060) Establecimiento, negociación, fin)

- Streaming RTP (UDP 10000 20000) y control RTCP



Ilustración 2. Comunicación SIP

El protocolo SIP define principalmente seis tipos de solicitudes:

• INVITE: establece una sesión.

• ACK: confirma una solicitud INVITE.

• BYE: finaliza una sesión.

• CANCEL: cancela el establecimiento de una sesión.

• REGISTER: comunica la localización de usuario (nombre de equipo, IP).

• OPTIONS: comunica la información acerca de las capacidades de envío y

recepción de teléfonos SIP.

Y también presenta seis clases de respuestas:

• 1xx: respuestas informativas, tal como 180, la cual significa teléfono sonando.

• 2xx: respuestas de éxito.

• 3xx: respuestas de redirección.

• 4xx: errores de solicitud.

• 5xx: errores de servidor.

• 6xx: errores globales.

SIP permite llamadas directas entre usuarios o mediante un Proxy server.

1.2.2. Concepto de Proxy Server

El proxy Server es una aplicación intermedia que actúa tanto como servidor y

cliente, generando mensajes SIP a nombre del cliente que generó el mensaje original.



Estos mensajes SIP pueden ser respondidos o encaminados a otros servidores.

Además El proxy server interpreta, re-escribe o traduce los mensajes antes de

encaminarlos.

Existen dos tipos de Proxy Server:

• Inbound Proxy

• Outbound Proxy

Inbound Proxy. El Inbound Proxy permite independizar al usuario del dispositivo que

utiliza y de su localización.

Outbound Proxy. El proxy saliente simplifica administración de los usuarios de un

dominio, aplica políticas, tarifica, etc.

Un mismo servidor puede funcionar como Proxy entrante y saliente de un dominio.

Ilustración 3. Comunicación SIP con Proxy

1

1.2.3. Concepto de Servidor de Registro

El protocolo SIP permite establecer la ubicación física de un usuario determinado.

Esto significa que se puede saber en qué punto de la red está conectado. Para esto se

utiliza el mecanismo de registro.



En el servidor de registro se basa en el siguiente funcionamiento:

Cada usuario tiene una dirección lógica que no depende de la ubicación física del

usuario. Una dirección lógica del protocolo SIP es de la forma usuario@dominio es

decir tiene la misma forma que una dirección de correo electrónico. La dirección física

(denominada "dirección de contacto") es dependiente del lugar en donde el usuario

está conectado (de su dirección IP). Cuando un usuario inicializa su terminal (por

ejemplo conectando su teléfono o abriendo su software de telefonía SIP) el agente de

usuario SIP que reside en dicho terminal envía una petición con el método REGISTER

a un Servidor de Registro, informando a qué dirección física debe asociarse la

dirección lógica del usuario. El servidor de registro realiza entonces dicha asociación.

Esta asociación tiene un período de vigencia y si no es renovada, caduca. La forma en

que dicha asociación es almacenada en la red no es determinada por el protocolo SIP,

pero es vital que los elementos de la red SIP accedan a dicha información.

Ilustración 4. Establecimiento de una comunicación SIP 1

1.2.4. Ejemplo de una comunicación SIP y sus mensajes.

El siguiente esquema representa la comunicación (RFC3261) entre Alice y Bob

interconectados con dos proxys (atlanta.com y biloxi.com). Los mensajes FX

representan los requerimientos y respuestas para establecer la comunicación.

http://es.wikipedia.org/wiki/Protocolo_de_Internet



Cabe destacar que SIP define mecanismos para garantizar la fiabilidad de las

comunicaciones y depende del protocolo SDP (Sesion Description Protocol), que

describe el contenido multimedia de la sesión; por ejemplo, el puerto IP (los clientes

SIP usan el puerto 5060 TCP y UDP para conectar con los servidores SIP) y el códec

que se utilizarán durante la comunicación, etc.

Ilustración 5. Comunicación SIP con dos proxys.1

1.2.5. Descripción de los campos del encabezado del mensaje.

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds 1 Tomado de: http://www.ietf.org/rfc/rfc3261.txt



To: Bob <sip:[email protected]>

From: Alice <sip:[email protected]>;tag=1928301774

Call-ID: [email protected]

CSeq: 314159 INVITE

Contact: <sip:[email protected]>

Max-Forwards: 70

Content-Type: application/sdp

Content-Length: 142

Via: contiene la dirección en la cual el agente espera recibir las respuestas a ese

requerimiento. También contiene un parámetro (branch) que identifica esa transacción.

To: contiene el display name (Bob), y un SIP o SIPS URI (Uniform Resource Identifier)

que indican el destinatario del requerimiento.

From: también contiene un display name (Alice) y un SIP o SIPS URI que indica el

agente originante del requerimiento. Este campo del header, también contiene un

parámetro (tag) que contiene una cadena de caracteres (string) de tipo aleatorio como

identificación.

Call-ID: contiene un identificador global único de esa sesión, generalmente

combinando una string aleatoria y la IP del host.

La combinación de los tag de To, From y Call-ID definen completamente una relación

de a pares entre los agentes y es referida como diálogo.

CSeq: (Command Sequence) contiene un número entero y el nombre de un método. El

número entero se incrementa en 1 con cada nuevo requerimiento dentro de un diálogo.



Contact: contiene una URI SIP o SIPS que representa una ruta directa para contactar

al agente. Mientras el header Via, indica a donde enviar las respuestas, el Contact

específica a donde enviar futuros requerimientos.

Max-Forwards: sirve para limitar el número de saltos (hops) que puede tener un

requerimiento en el camino a su destino. Consiste en un número entero que se

decrementa en 1 en cada salto.

Content-Type: contiene una descripción del tipo de contenido del cuerpo del mensaje.

Content-Length: contiene la cuenta de octetos (bytes) del cuerpo del mensaje. (IETF,

2002)

1.3. Introducción a Web Real-Time Communication

Web Real-Time Communication o WebRTC añade a los navegadores web una

nueva funcionalidad de interactuar directamente entre sí. La capacidad de multimedia

de WebRTC es la nueva característica y en lo que se basa esta técnica.

1.3.1. Introducción a WebRTC

WebRTC o comunicaciones de tiempo real en la web es una tecnología que

permite utilizar HTML5 y API’s (Application Programming Interfaces) de JavaScript para

poder realizar comunicaciones de audio y video. WebRTC permite realizar llamadas de

voz, chat, videoconferencia y uso compartido de archivos P2P directamente desde el

navegador sin la necesidad de instalar ningún complemento “plugg-ins”o programas

adicionales de terceros (flash, ActiveX, Silverlight).

WebRTC sólo es posible por la existencia de HTML5, que es la primera

especificación de HTML que permite el manejo de Websockets.



WebRTC es un proyecto de código abierto patrocinado por Google y actualmente

está en fase de desarrollado y estandarizado por parte del W3C (World Wide Web

Consortion) y el IETF (Internet Engineering Task Force). El W3C está encargado de

estandarizar la tecnología desde la perspectiva de los navegadores y tecnologías Web

(HTML5, CSS, etc.) y de definir APIs estándar para que los desarrolles Web utilicen

WebRTC en sus aplicaciones. Por otro lado, el IEFT se ha centrado en los protocolos y

herramientas que la tecnología utilizará a nivel de transporte, como SRTP,

STUN/ICE/TURN (Anexo B), y códec. (Tejedor, 2012)

Con el desarrollo e incursión de tablets y smartphones en el mercado, WebRTC se

presenta como alternativa para comunicaciones móviles debido a que Adobe retiró el

soporte flash para los dispositivos móviles.

1.3.2. Elementos de un sistema WebRTC

En un sistema WebRTC se incluye servidores web, navegadores web ejecutándose

en diferentes sistemas operativos de varios dispositivos como son: PC, laptos, tablets,

smartphones. Como elementos adicionales se incluye Gateways para la interconexión

con la red de telefonía pública (PSTN) y otros dispositivos de comunicación a través de

internet que utilicen el protocolo SIP, como teléfonos y PBX-IP. WebRTC permite la

comunicación entre todos estos dispositivos. La ilustración 6 muestra un ambiente de

un sistema WebRTC.



Ilustración 6. Sistema WebRTC2

1.3.3. Aplicaciones WebRTC

En la sociedad actual tecnológica hay varios entornos en los que ya se está

aplicando el estándar WebRTC, como son las Telcos, las corporaciones, el entorno de

las redes sociales y fabricantes.

Dentro de las operadoras telefónicas brindan a sus clientes la aplicación de

webphone. En su arquitectura de red se están integrando el estándar con las redes de

nueva generación & IMS. También se le puede utilizar como un nuevo canal de entrada

para atención al cliente como los contact center.

Tanto las corporaciones como instituciones educativas están adoptando WebRTC e

integrando sus redes para facilitar y agilizar las comunicaciones de sus colaboradores.

Un ejemplo de esto es el proyecto PIT-VoIP, elaborado por Red CLARA

(Cooperación Latinoamericana de redes avanzadas) en conjunto con RNP (Red

Nacional de Educación e Investigación del Brasil), cuyo objetivo es integrar las

2 Tomado de: Libro WebRTC: Elements of a WebRTC System



diferentes plataformas de telefonía existentes en las instituciones académicas

latinoamericanas empleando para ello la tecnología de voz sobre IP (VoIP) y protocolos

de comunicación abiertos y escalables. Esto permite contar con un servicio de

comunicación unificado, reducción de costos y mejoras en la calidad de la

comunicación; aportes de los cuales está exenta la red actual por sus limitaciones.

Se utilizan de igual forma en los conferencias web, como Webex y drum que

permiten videoconferencia, uso compartido de archivos, chat, etc.

El software de traducción de voz “Translate your world” ha evolucionado con la

utilización de WebRTC ya que permite generar subtítulos automáticos en varios

idiomas en grandes conferencias, para hablar en Skype entre idiomas y para convertir

seminarios web en una verdadera experiencia mundial a través de WebEx, Adobe

Connect, Blackboard, GoToWebinar o cualquier otro software de conferencias web.

Entre otras aplicaciones, facilita las conferencias internacionales y hace posible que los

estudiantes dialoguen en sus propios idiomas en los cursos de capacitación y

educación empresarial.

En medios sociales como twitter se quiere realizar llamadas entre usuarios

directamente mediante webrtc.

Otra aplicación de WebRTC que se está llevando a cabo es de distribuir los

contenidos multimedia a través del navegador web. El proyecto se llama PeerCDN, de

esta manera se reduce el uso de recursos de las redes CDN ya que se tiene mayor

distribución de usuarios web.

WebRTC está generando mucho interés entre los desarrolladores de aplicaciones

web. Hay un gran impulso en la dirección de imponer al navegador de internet HTML5

como el destino final de las comunicaciones SIP de audio y video.



1.3.4. Integración de WebRTC con redes de comunicaciones.

1.3.4.1. WebRTC y la red de telefonía pública (PSTN)

El estándar WebRTC puede interoperar con la PSTN utilizando gateways que

traducen los datos en solo audio y conecta la llamada telefónica con el explorador web.

Se puede utilizar un tipo de señalización para efectuar la llamada, en este caso SIP.

No se espera que los navegadores tengan asignados números de teléfono o ser

parte de la PSTN. En su lugar, un servicio de Comunicación en Internet podría asignar

un número de teléfono a un usuario, y que el usuario podría utilizar WebRTC para

acceder al servicio.

Para que la convergencia entre el Sistema Telefónico Público disponible hoy y la

telefonía por Internet o Voz sobre IP (VoIP) y que el desarrollo de nuevos servicios

multimedia tengan menos obstáculos, es fundamental que los usuarios puedan realizar

sus llamadas tal como están acostumbrados a hacerlo, marcando números. Para ello

se tiene el sistema ENUM que emplea un conjunto de protocolos para convertir el

sistema de numeración utilizado en la telefonía convencional (E.164) en direcciones de

servicios de internet (URIs), de modo que el sistema de numeración E.164 usado en la

telefonía convencional tenga una función de correspondencia con las direcciones URI

en Internet. ENUM basa su funcionamiento en el sistema de resolución de nombres de

dominio (DNS). Mediante registros NAPTR ("Naming Authority Pointer Resource

Records" tal como lo define el RFC 2915), se define la correspondencia entre el

número telefónico y la URIs correspondiente. (Mariano Javier Martín, 2013)

De igual manera se puede interconectar WebRTC con la PSTN mediante

plataformas de Telefonía IP como es Asterisk que de igual forma tiene sus drivers para

telefonía convencional.



1.3.4.2. WebRTC y redes IMS (IP Multimedia Subsystem)

WebRTC presenta dos modelos de arquitectura de red, el modelo triángulo que es

un sistema independiente que soporta una sesión de comunicaciones. En este modelo

la llamada es operada por un solo proveedor de comunicaciones.

Se tiene otro modelo que es el trapezoide que permite a los sistemas de

comunicaciones interconectarse entre sí utilizando un NNI (Network to Network

Interface) común. En el modelo de interconexión, las llamadas son manejadas por dos

proveedores de comunicaciones.

Las operadoras telefónicas tienen distribuidas redes IMS para dar servicio de

VoLTE y RCS y además telefonía fija, pero a pesar de que VoLTE y RCS (Rich

Communication Service) están basadas en IMS no están interconectadas entre sí.

De igual forma la popularidad masiva de servicios OTT presiona a los proveedores

de IMS a buscar una solución eficaz para integrar servicios. De esta forma WebRTC

puede habilitar la infraestructura para ofrecer servicios directamente desde casi

cualquier dispositivo que tenga un navegador.

Hay un esfuerzo en curso de 3GPP llamado ' WebRTC Acceso a IMS 'con 3GPP TR

23.701 como su principal arquitectura hasta la fecha. El documento TR 23.701 contiene

un estudio sobre las posibles modificaciones de la arquitectura IMS con el fin de

permitir a los clientes basados en WebRTC acceder a IMS. (Pascual, 2014)

Como ventajas de esta integración serán:

• Realizar llamadas hacia y desde la PSTN/PLMN directamente.

• Portabilidad de dirección.

• Elección de suscriptor.

• Transferencia y desvío de sesión.

• Acceso a servicios de confianza.

• Dispositivos de comunicación independientes. (Alcatel-Lucent, 2013)

http://www.3gpp.org/DynaReport/23701.htm



1.3.5. Consideraciones de implementación WebRTC

La implementación de una tecnología conocida en un nuevo entorno trae consigo

una serie de desafíos. Si se desea utilizar el servicio de videoconferencia por WebRTC

se debe analizar todos los dispositivos que interactúan para ofrecer un servicio

eficiente y de alta calidad analizando de igual manera el escenario si es complejo como

el de educación.

Se debe analizar consideraciones como:

-Distintos dispositivos y accesos a la red. Una diversidad de dispositivos que

acceden a la web han incrementado estos últimos tiempos. Como antiguamente había

solo computadores, ahora hay tablets y smartphones que acceden a la web mediante

las redes celulares.

-Tamaño de la pantalla. Las pantallas más pequeñas no pueden mostrar la misma

cantidad de información como los grandes. En vídeoconferencia, por ejemplo, enviar

un vídeo de muy alta calidad a un dispositivo de pequeña pantalla es ineficiente, ya

que los usuarios no pueden notar la diferencia. Un escenario más complicado es la

multiconferencia donde el tamaño de la pantalla limita la cantidad de participantes que

se pueden mostrar al mismo tiempo.

-CPU. La videoconferencia requiere de mucho procesamiento para codificar,

decodificar y distribuir el audio y video en tiempo real. La utilización del CPU depende

de varios factores como los códecs, la calidad de audio y el tamaño del video.

-Ancho de banda y latencia. La variedad de dispositivos va de la mano con la

variedad de diferentes redes de acceso. Por ejemplo, tenemos acceso Ethernet

cableada para los ordenadores y las redes 3G para dispositivos móviles. Estas

diferencias tienen que ser tenido en cuenta si queremos optimizar la comunicación. Por

ejemplo, las conexiones de 3G pueden variar el ancho de banda disponible sin ningún

aviso y darán lugar a una interrupción en la conferencia si el sistema no es capaz de

reaccionar en consecuencia.



-Gateways. La interoperabilidad de una plataforma de comunicación con otra es

siempre un reto. Por ejemplo, la comunicación entre los teléfonos SIP y la PSTN se

logra a través de gateways que traducen señalización y flujos de medios.

1.3.6. Arquitectura WebRTC

La siguiente ilustración describe cómo está conformado un sistema WebRTC.

Dentro de esta arquitectura se presenta un elemento llamado RTCPeerConnection el

cual es el encargado de la estabilidad y eficiencia del flujo de datos de la

comunicación.

Ilustración 7. Arquitectura WebRTC.3 1

3 Tomado de: http://www.webrtc.org/reference/architecture



1.3.7. Protocolos webrtc

Hay un número de protocolos relacionados con WebRTC. Los más importantes se

muestran en la siguiente figura según la capa.

Ilustración 8. Protocolos webrtc según el nivel de capas.4

A continuación se describirán los protocolos más característicos para este

proyecto.

1.3.7.1. Protocolo HTTP

El protocolo de transferencia de hipertexto (HyperText Transfer Protocol, RFC2616)

es un protocolo del nivel de aplicación usado para la transferencia de información entre

sistemas, de forma clara y rápida. Este protocolo ha sido usado por el World-Wide Web

desde 1990.

Este protocolo permite usar una serie de métodos para indicar la finalidad de la

petición. Se basa en otros conceptos y estándares como Uniform Resource Identifier

4 Tomado de: Libro WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web



(URI), Uniform Resource Location (URL) y Uniform Resource Name (URN), para

indicar el recurso al que hace referencia la petición.

Una transacción HTTP está formada por un encabezado seguido, opcionalmente,

por una línea en blanco y algún dato. El encabezado especificará cosas como la acción

requerida del servidor, o el tipo de dato retornado, o el código de estado.

El uso de campos de encabezados enviados en las transacciones HTTP le da gran

flexibilidad al protocolo. Estos campos permiten que se envíe información descriptiva

en la transacción, permitiendo así la autenticación, cifrado e identificación de usuario.

La versión actual de HTTP es la 1.1, un siguiente trabajo de IETF describe una

nueva versión HTTP versión 2.0

1.3.7.2. Protocolo Websocket

El protocolo WebSocket [RFC6455] permite a un navegador abrir conexiones TCP

adicionales a un servidor web. La abertura de conexión está señalizada mediante

HTTP y tiene propiedades de seguridad similares a los de una sesión web HTTP, y se

puede reutilizar la infraestructura HTTP existente. Esto evita que se abran múltiples

sesiones HTTP entre un navegador y un servidor web. Un ejemplo de esto es SIP

websocket que más adelante se especificará su funcionamiento.

1.3.7.3. RTP (Real-Time Transport Protocol) y Secure RTP (SRTP)

El protocolo más importante utilizado por WebRTC es RTP (RFC3550). WebRTC

utiliza sólo el perfil de seguridad de RTP o Secure RTP, SRTP (RFC3711). SRTP es el

protocolo utilizado para transportar audio vídeo de los paquetes de comunicación entre

los clientes WebRTC . Los paquetes de multimedia contienen las muestras de audio

digitalizadas o fotogramas de video digitalizados generados por un micrófono y la



cámara de la aplicación. Mediante mensajes de petición-respuesta se establece una

conexión segura y se transmiten los paquetes de medios.

El protocolo SRTP proporciona información esencial para el transporte de la

información de multimedia, entre los parámetros de información que se transporta se

tiene:

• El códec (codificador/decodificador) utilizado para el muestreo y

comprensión de audio y video.

• La fuente de los medios de comunicación (la fuente de sincronización o

SSRC).

• Una información de “time-stamp” (para una emisión correcta) que es número

de secuencia (para detectar la pérdida de paquetes), y otra información

necesaria para la reproducción.

Si no se trasmiten paquetes de audio y video, no se utiliza SRTP. En cambio, una

llamada a la aplicación RTCDataChannel abrirá un canal de datos entre los

navegadores que permiten intercambiar cualquier tipo de datos.

1.3.7.4. SDP (Session Description Protocol)

SDP (RFC4566). Una sesión de descripción SDP (codificada como un objeto

RTCSessionDescription) se utiliza para describir las características de medios de una

conexión par. Existe una complicada información que se debe intercambiar entre los

dos extremos de la sesión SRTP para que puedan comunicarse. La ejecución del

elemento RTCPeerConnection dará lugar a una sesión SDP, que es un conjunto de

datos que son generados por el navegador y la aplicación web accede usando

JavaScript. Una aplicación que quiere tener un control estricto sobre los medios de

comunicación puede hacer cambios a la SDP antes de compartirlo con otro navegador.

Cuando se realizan cambios en una conexión par, esto se traducirá en cambios en la

sesión que los dos pares intercambiarán. Esto se conoce como un intercambio

petición-respuesta



Tanto SRTP y SDP son protocolos estandarizados por la IETF y ampliamente

utilizadas por los dispositivos y servicios de comunicaciones de Internet, tales como

Voz sobre IP (VoIP) teléfonos, gateways y dispositivos de video conferencia. Como

resultado, la comunicación entre estos dispositivos y un cliente WebRTC es posible.

Sin embargo en la actualidad no todos los dispositivos de VoIP soportan las

características de WebRTC por lo que se deber actualizar sus sistema para poder

realizar una integración, contribuyendo así con el desarrollo de WebRTC.

1.3.7.5. TLS (Transport Layer Security)

El protocolo TLS es definido en RFC5246, posee versiones más antiguas conocidas

como SSL y es una capa de complemento para el protocolo TCP que proporciona

servicios de confidencialidad y autenticación. La confidencialidad se puede aplicar

mediante la encriptación de los paquetes. La autenticación se aplica con el uso de

certificados digitales. La navegación web segura (HTTPS) soporta sólo TLS, WebRTC

puede utilizar TLS para señalización y seguridad de la interfaz de usuario. También

existe una versión de TLS que se ejecuta sobre el protocolo UDP, llamados

datagramas de TLS, (DTLS) y otra versión que se puede utilizar para generar claves

para SRTP conocida como DTLS-SRTP descrita en la RFC 5764.

1.3.8. Códecs WebRTC

1.3.8.1. Códec de Audio Opus

El códec de audio Opus (RFC6176) es el códec de internet de baja latencia para

audio y música. Este incorpora tecnología de Skype (SILK codec) y el códec CELT que

es de código abierto. Opus es flexible soporta bitrates de 6 a 510 Kbps con un

muestreo de señal de 4 a 48 Khz, soporta voz y música mono y stereo con tamaño de



paquetes de 2.5ms a 60ms. Opus también presenta una muy buena calidad frente a

pérdida de paquetes.

1.3.8.2. Códec de Video VP8

El códec de video VP8 (RFC6386) también llamado WebM es un códec creado por

On2 (empresa adquirida por Google y conocida por sus codecs Vp3, Vp4, Vp6, Vp7) su

técnica de comprensión es similar al códec H.264. El códec VP8 ofrece un bitrate

variable VBR y un bitrate constante CBR además presenta una variante de VBR

llamado CQ (Constant Quality) que es un modo de calidad constante. El bitrate de una

trasmisión de video depende del tamaño de pantalla y la capacidad de red.

1.3.9. Modelo Web y RTC

La transmisión de información entre el Navegador Web y el Servidor web se realiza

mediante el protocolo HTTP el cuál funciona sobre el protocolo de transporte TCP o en

otras nuevas implementaciones sobre el protocolo WebSocket. El contenido o la

aplicación son desarrolladas en lenguaje HTML el cual trabaja en conjunto con

lenguaje Javascript y CSS.

En el modelo simple el navegador envía una petición HTTP al servidor web y éste

envía una respuesta conteniendo el documento, imagen o información requerida. En la

forma compleja el servidor envía JavaScript el cual corre e interactúa el navegador a

través de API’s con el usuario seleccionando con clics. Se intercambia información del

servidor web al navegador por una sesión HTTP o un canal Websocket.

El siguiente esquema describe el modelo Web introduciendo la comunicación en

tiempo real, RTC.



Ilustración 9. Modelo web de RTC.5

WebRTC introduce un nuevo aspecto que es la interacción de navegador-a-

navegador también conocida como comunicación peer-to-peer, dónde la función RTC

realiza la comunicación entre un navegador por protocolos estándares on-the-wire. (No

HTTP) a otro navegador o dispositivo VoIP. Mientras el tráfico web utiliza el protocolo

TCP para el transporte de datos. El protocolo on-the-wire para comunicaciones puede

utilizar UDP. También se describe el servidor de señalización que es el encargado de

señalizar la comunicación desde el navegador al otro extremo de la comunicación peer.

Por ejemplo SIP.




1.3.10. WebRTC y SIP

El servidor Web tiene un gateway integrado de señalización SIP que permite

establecer una llamada entre el navegador y el cliente SIP. El flujo de datos entre el

navegador y el SIP User Agent es mediante el protocolo RTP.

El siguiente esquema representa el establecimiento de una sesión SIP entre un

navegador y un SIP User Agent. Como se puede observar son los mismos mensajes

de petición-respuesta SIP.



Ilustración 10. Establecimiento de una comunicación SIP mediante WEB.6

1.3.10.1. SIP sobre Websocket

Un nuevo proyecto de internet define un Websocket para el transporte de SIP (draft-

ietf-sipcoresip-websocket). En este procedimiento el navegador carga un cliente SIP en

Javascript y establece una conexión (REGISTER) con un servidor Proxy SIP el cual

soporta la extensión websocket. Un navegador inicia una sesión WebRTC el cual envía

un INVITE conteniendo la oferta SDP desde el navegador web al servidor proxy.




El navegador de destino o cliente SIP se identificará por la dirección URI (ejemplo.

Sip:[email protected]). El otro navegador recibirá el INVITE y responderá a la sesión

SIP con el mensaje SDP adecuado y la respuesta 200 OK, estableciendo así la sesión

de medios.

Un ejemplo de SIP user agent en Javascript es sipml5 (http://sipml5.org) o jssip

(http://jssip.net) los cuales son de código abierto y disponibles al público, otro ejemplo

de un servidor SIP proxy que soporta la extensión websocket es Asterisk

(http://asterisk.org)

El siguiente esquema representa la señalización SIP en websocket (Johnston, 2013)

Ilustración 11. Establecimiento de una comunicación SIP a través de Websocket.7


http://asterisk.org/



1.4. Introducción a Near Field Communication, NFC

Near Field Communication es una tecnología inalámbrica de corto alcance y

elevada frecuencia que permite la transmisión de información hasta una distancia de

10cm. NFC es una extensión de la norma ISO/IEC 14443 (ECMA, 2013) que utiliza la

RFID (Radio Frequency Identificación), que combinan la interfaz de un mapa a chip y

un lector dentro de un solo periférico.

Fue aprobado como estándar en el 2003 y esta tecnología ya se ha implementado

en llaves para acceso, ticket y pago electrónico.

Se diferencia principalmente de RFID y Bluetooth por su alcance ya que es muy

corto el cual necesita que los dispositivos se acerquen o toquen para establecer

conexión.

El NFC en los dispositivos móviles hace que las tareas diarias se realicen más

fácilmente, NFC está diseñado para una simple y segura interacción entre dispositivos

electrónicos. (Chavarría, 2011)

1.4.1. Características Técnicas

• La frecuencia de operación de NFC es 13.56 Mhz la cual no es una banda

licenciada, es de libre uso.

• Tiene velocidades de trasmisión de 106Kbps, 212Kbps y 424Kbps.

• La comunicación se realiza con la técnica de modulación por desplazamiento

de amplitud y codificación Manchester o Miller codificada.

• Tienes dos modos de funcionamiento Activo y Pasivo



1.4.2. Modos de funcionamiento

Pasivo: Un solo dispositivo se encarga de generar el campo electromagnético y el otro

se beneficia de la modulación de la carga para poder transmitir los datos.

Ilustración 12. Comunicación NFC modo pasivo.8

La figura muestra que el dispositivo que inicia la comunicación es el que genera el

campo magnético a una velocidad de transferencia seleccionada y el otro dispositivo

responde usando datos de carga modulada a la misma velocidad.

Activo: En el modo activo ambos dispositivos generan un campo electromagnético que

utilizan para transmitir sus datos. Ambos dispositivos necesitan energía para funcionar

y seleccionan la misma velocidad de transferencia.

8 Tomado de: http://e-archivo.uc3m.es/bitstream/handle/10016/13724/pfcAidaCampaRuiz.pdf?sequence=1



Ilustración 13. Comunicación NFC modo activo.9

1.4.3. Estándares y Protocolos NFC

NFC es una tecnología de plataforma abierta estandarizada en la ISO/IEC 18092 y

la ECMA-340. Estos estándares especifican los esquemas de modulación, codificación,

velocidades de transferencia y formato de la trama de la interfaz RF de dispositivos

NFC, así como los esquemas de inicialización y condiciones requeridas para el control

de colisión de datos durante la inicialización para ambos modos de comunicación,

activo y pasivo.

También definen el protocolo de transporte, incluyendo los métodos de activación

de protocolo y de intercambio de datos.

El NFC Forum ha desarrollado cuatro tipos diferentes de etiquetas que todo

dispositivo

NFC debe soportar:

9 Tomado de: http://e-archivo.uc3m.es/bitstream/handle/10016/13724/pfcAidaCampaRuiz.pdf?sequence=1



Tipo 1: basado en ISO 14443 A. Proporcionado por Innovision Research &Technology

(TopazTM). Posee una capacidad de hasta 1 Kb y velocidades de transmisión de 106

Kbps. Son etiquetas de bajo coste.

Tipo 2: basado en ISO 14443 A. Proporcionado por NXP Semiconductors (MIFARE

Ultralight). Posee una capacidad de 0,5 Kb y velocidad similares a las tipo 1. También

son de bajo coste.

Tipo 3: basado en FeliCa (que deriva de ISO 18092). Proporcionado por Sony, con

capacidades de hasta 2 Kb y velocidades de 212 Kbps. El coste es mayor aunque útil

para aplicaciones más complejas.

La interface de aire para NFC está estandarizado en: ISO/IEC 18092 / ECMA –

340: Near Field Communication Interface and Protocol-1 (NFCIP-1) ISO/IEC 21481 /

ECMA – 352: Near Field Communication and Protocol-2 (NFCIP-2).

1.4.4. Arquitectura NFC

Se puede observar en la figura que la tecnología NFC puede funcionar en tres

configuraciones distintas y esto hace que sea más adaptable y eficiente que otras

tecnologías.

Los modos de configuraciones son:

El modo lector/escritor lee información de una etiqueta NFC.

Modo Emulación de Tarjeta. En este modo el dispositivo NFC se comporta como una

etiqueta NFC y es leído por otro dispositivo.

El modo Peer to peer. Los dos dispositivos intercambian información de igual a igual.

(Ruiz, 2011)



Ilustración 14. Arquitectura NFC.10

10 Tomado de: http://nfc-forum.org/our-work/specifications-and-application-documents/specifications/



CAPÍTULO 2.

Descripción de Sistemas de la solución

En esta sección se describe cada uno de los sistemas que se emplea en este

proyecto. Se describe su funcionamiento y parámetros de configuración realizables

para integrar las diferentes tecnologías.

2.1. Central IP-Servidor Asterisk

2.1.1. Introducción a Asterisk

Asterisk en un proyecto de software libre desarrollado para la integración de

comunicaciones, Voz, mail, fax, conferencias. En principio fue desarrollado como

plataforma de un sistema PBX pero luego fue evolucionando a más servicios como

Gateway de VoIP, sistemas de call center, conferencias, buzón de voz y otras

comunicaciones en tiempo real.

2.1.2. ¿Qué es Asterisk?

El desarrollo de Asterisk se inició en el año de 1999 por Mark Spencer. En esos

momentos ya había otros proyectos de telefonía basados en código abierto, pero solo

se enfocaban en comunicaciones a nivel de software entre ordenadores. Asterisk se

diferenció de estos proyectos por su interacción con la red de telefonía pública PSTN.



El desarrollador y soporte principal de Asterisk es Digium, desarrollador y fabricante

de hardware de PBX-IP. Es el encargado del apoyo y soporte a distribuidores en el

mercado al igual de la facilidad de la concesión de licencias y servicios a las empresas

fabricantes.

Asterisk es una PBX completa para brindar comunicaciones unificadas a usuarios y

empresas pequeñas y medianas. También implementado por proveedores de servicios

y compañías telefónicas. Asterisk es al mismo tiempo un sistema versátil que puede

interactuar con otras PBX similares en una red IP, ya sean locales o remotas.

Otro aspecto importante a considerar es que Asterisk es un sistema independiente

del hardware a utilizar, es principalmente basado en Linux pero puede correr bajo

cualquier otro sistema operativo. Asterisk puede comportarse como gateway telefónico

(canales POTS, TDM y PRI), Gateway VoIP (canales IP), un sistema IVR, un sistema

de voicemail, además puede ser un sistema de telefonía programable en cualquier

lenguaje. Al contrario, Asterisk no es un sistema de facturación o un sistema CRM, no

es un servidor web o xml, tampoco es un sistema de reconocimiento de voz. Pero se

asocia con servicios como este para brindar una solución completa.



2.1.3. Arquitectura de Asterisk

Ilustración 15. Arquitectura Asterisk.11

La arquitectura de Asterisk está formada por un conjunto de módulos diferentes que

dependen del núcleo del sistema. Esto permite diferentes capacidades del sistema ya

que por ejemplo un módulo podría permitir que el sistema se comunique con líneas

analógicas mientras otro módulo permite hacer un reporte de llamadas.

El núcleo del sistema se basa en cuatro componentes:

• Gestión de Módulos

• Temporizador de Sistema

• Gestión de Canales

• Interfaces de Sistema

En las PBX tradicionales existen estructuras lógicas para diferenciar entre los

teléfonos y otros dispositivos de telefonía como faxes, y por otro lado líneas entrantes

como troncales primarios, líneas RDSI, etc. En Asterisk se cambia este concepto y 11 Tomado de: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Architecture%2C+The+Big+Picture

https://wiki.asterisk.org/wiki/display/AST/Asterisk+Architecture%2C+The+Big+Picture



todo es gestionado de una forma integral, las llamadas entrantes son manejadas de

igual forma que una extensión interna SIP.

2.1.4. Tipos de módulos de Asterisk

2.1.4.1. Drivers de Canales Como se muestra en la parte de arriba de la figura los drivers de canal comunican

a Asterisk con dispositivos externos y traducen protocolos de señalización para permitir

la comunicación con el núcleo del sistema. Son prácticamente unas APIs. Por

ejemplo Dahdi que permite la comunicación entre Asterisk y las interfaces analógicas

de telefonía considerando que hablamos de interfaces que conectan concretamente

con la PSTN.

2.1.4.2. Aplicaciones de Dialplan

Estas aplicaciones permiten la funcionalidad de llamada del sistema. Una aplicación

podría contestar una llamada, transferir una llamada, colgar entre otras.

2.1.4.3. Funciones de Dialplan

Las funciones se utilizan para obtener o establecer determinada información de

cada canal. Son suplementarias a la aplicaciones y permiten una mejora en un aspecto

determinado. Por ejemplo Por ejemplo una función típica es la capaz de recoger el

Identificador de llamada de un canal (CALLERID) para poder manejarlo dentro del plan

de marcación a voluntad.



2.1.4.4. Recursos

La función principal de los recursos es integrar Asterisk con sistemas externos

como: base de datos, servidores web o calendarios. Pueden también utilizar

aplicaciones del sistema de forma estática. Un ejemplo de recurso es música en

espera o la integración con base de datos ODBC.

2.1.4.5. Códec y Formatos

Son los módulos de codificación y decodificación de audio y video digital de

trasmisión (Códec) y almacenamiento (formato)

De alguna forma, son los encargados de convertir vía software, entre un tipo y otro

tipo de formato o códec de forma simultánea al curso de la llamada. Por ejemplo, si

una llamada, viene del canal DAHDI, con el códec G.711 (alaw o ulaw dependiendo del

país) y quiere pasarse a una extensión SIP dentro de nuestro sistema Asterisk, el

traductor correspondiente será el encargado de realizar esta conversión en tiempo

real.

Por otro lado, si lo que estamos tratando son archivos, los encargados de interpretar

el contenido para pasarlo a través del audio del canal correspondiente serían los

traductores de Formatos. En este ámbito los más populares son los estándares, GSM y

WAV en los que están basados la mayor parte de los sonidos por defecto del

sistema Asterisk (los mensajes pregrabados).

2.1.4.6. Drivers de Registro detallado de llamadas (CDR)

Los drivers CDR escriben los registros en un disco duro o base de datos. Los

módulos de CDR se utilizan para almacenar los registros de detalles de llamadas en

una variedad de formatos como por ejemplo (CSV)



2.1.4.7. Drivers de registro de eventos de llamada (CEL)

Los registros de eventos de llamada son similares a los registros detallados de

llamadas, pero registran más detalles acerca de lo que ocurrió dentro

de Asterisk durante una llamada particular.

2.1.4.8. Módulo Bridging

Los controladores de puente, son utilizados por la arquitectura de Asterisk para

proporcionar varios métodos de puenteo de datos de media entre los participantes de

una llamada.

2.1.4.9. Interface de línea de comandos (CLI)

Se considera la consola de administración del sistema. Permite a los

administradores analizar el estado del sistema, recargar o reiniciar el sistema,

actualizar valores en tiempo real, mostrar ayudas de comandos, etc.

2.1.4.10. Asterisk Manager Interface

Este recurso se desarrolló para “computer telephony integration" CTI y permite la

comunicación de computadora a computadora, monitoreo y además permite ejecutar

comandos y controlar.

Como el CLI, cada módulo cargado puede agregar su propio comando AMI

al sistema, sistemas como marcadores predictivos, gestores de llamadas, sistemas de

facturación, etc, se fundamentan en esta interfaz. La forma de interacción está basada

en un flujo de texto simple.



2.1.4.11. Interface Asterisk Gateway

AGI es un ejemplo de una aplicación de interface de programación

para Asterisk porque permite que las aplicaciones de Asterisk sean escritas en casi

todos los lenguajes de programación. Mediante esta aplicación se controla la mayoría

de los aspectos de call-level de Asterisk. permite utilizar links

para aplicaciones externas (databases, servidores LDAP, servicios web, etc.) o

hardware (home automation, etc.). También es muy útil para crear scripts IVR

a medida. (Wikiasterisk, 2012)

2.1.5. Archivos de configuración.

Asterisk está configurado por una serie de archivos texto basados en ASCII, estos

archivos se almacenan por defecto en /etc/asterisk/ y tiene la extensión .conf y pueden

ser editados con cualquier editor de textos.

Asterisk usa muchos archivos de configuración diferentes, pero todos con el mismo

patrón básico. Los archivos de configuración están divididos en secciones. los

encabezados de las secciones son nombres entre corchetes.

Los comentarios comienzan con un punto y coma, y siguen hasta el final de

la oración.

Los bloques de comentarios comienzan con ;-- y terminan con --;

[section-heading]

setting=true ; esto es un comentario;

this is another comment;-- this is a block comment

that runs until here. --;

Entre los archivos de configuración más importantes tenemos:

• Asterisk.conf

• Sip.conf

• Chan_dahdi.conf

• Extensions.conf



Asterisk.conf es el archivo de configuración principal le dice a Asterisk dónde buscar o

crear otros archivos de configuración y estructuras.

Sip.conf es el archivo que permite la configuración para el canal controlador SIP

de Asterisk y contiene la configuración de todos los dispositivos conectados a Asterisk.

Los valores se configuran en la sección [general]

Chan_dahdi.conf es el archivo que almacena la configuración para todas las tarjetas

DAHDI (analógicas y digitales), configura parámetros troncales para conexiones

externas, así como los teléfonos analógicos conectados. Además trabaja en conjunto

con los drivers del kerner Dahi -/etc/dahdi/system.conf en donde se configuran la

mayoría de controladores DAHDI.

Extensions.conf es el archivo que almacena la configuración del dialplan. Es decir, le

dice a Asterisk como administrar las llamadas entrantes y salientes.

2.1.6. Descripción breve del flujo de llamadas.

• Las llamadas entran por los canales (channels) y se procesan inicialmente con

la configuración del archivo “extensions.conf”, que es la especificación del plan

de discado (DialPlan).

• El DialPlan, contiene secciones lógicas denominadas “Contextos”, y cada canal

envía un llamado al DialPlan con un nombre de contexto específico y un

nombre (o número) discado.

• El DialPlan busca la coincidencia (match) del contexto y el nombre discado y

ejecuta la aplicación correspondiente.

• Cada match entre el nombre discado tiene pasos determinados por un número

de orden denominado prioridad que se representa por un número entero que

se incrementa de 1 en 1.



Ejemplo:

[de-troncal-E1]

exten => 14109850123,1,Answer

exten => 14109850123,2,Wait(2)

exten => 14109850123,3,Playback(Bienvenida)

exten => 14109850123,4,Goto(servicio-preatencion,123,1)

[servicio-preatencion]

exten => _12X,1,Playback(no-hay-agente-disponible)

exten => _12X,2,Hangup

2.1.7. Versiones de Asterisk

Release Series

Release Type

Release Date Security Fix Only

EOL

1.2.X 2005-11-21 2007-08-07 2010-11-21

1.4.X LTS 2006-12-23 2011-04-21 2012-04-21

1.6.0.X Standard 2008-10-01 2010-05-01 2010-10-01

1.6.1.X Standard 2009-04-27 2010-05-01 2011-04-27

1.6.2.X Standard 2009-12-18 2011-04-21 2012-04-21

1.8.X LTS 2010-10-21 2014-10-21 2015-10-21

10.X Standard 2011-12-15 2012-12-15 2013-12-15

11.x LTS 2012-10-25 2016-10-25 2017-10-25

12.x Standard 2013-12-20 2014-12-20 2015-12-20

13.x LTS 2014-10

(Tentative)

2018-10

(Tentative)

2019-10

(Tentative)

Tabla 1. Versiones de Asterisk



2.2. Introducción a Servidor Web

Un servidor o servidores son dispositivos de red que brindan un servicio a otros

dispositivos a los cuales se les conoce como clientes. En general quien realiza esta

tarea es un software especializado.

Los servidores web son aquellos que permiten alojar sitios o aplicaciones los cuales

son accedidos por los clientes utilizando un navegador web que se comunica con el

servidor utilizando el protocolo HTTP. Esencialmente un servidor web consta de un

intérprete HTTP el cual se mantiene a la espera de peticiones de clientes y responde

con el contenido solicitado.

Además los servidores pueden disponer de un intérprete de otros lenguajes como

HTML, el cual se basa el estándar WebRTC.

2.2.1. Servidores web más utilizados

El siguiente gráfico muestra cuáles servidores web han sido los más utilizados

durante los años transcurridos. Se ve en el gráfico que el servidor Apache ha sido el

más utilizado ya que es software libre y tuvo éxito por su despliegue en ámbitos

empresariales, tecnológicos y educativos.



Ilustración 16. Estadísticas de los servidores web más utilizados.12

2.2.2. Servidor Web Apache

Apache es el servidor web hecho por excelencia, es un sistema muy robusto y

estable que cada vez millones de servidores reiteran su confianza en este sistema.

Apache es uno de los servidores web más utilizados, posiblemente porque ofrece

instalaciones sencillas para sitios pequeños y si se requiere es posible expandirlo hasta

el nivel de los mejores productos comerciales. Además el servidor HTTP es un sistema

12 Tomado de: Netcraft



de código abierto y está disponible para multiplataforma como: Windows, Mac OS X y

UNIX (GNU, BSD, etc.)

La historia de Apache se remonta a febrero de 1995, donde empieza el proyecto del

grupo Apache, el cual está basado en el servidor Apache httpd de la aplicación original

de NCSA. El desarrollo de esta aplicación original se estancó por algún tiempo tras la

marcha de Rob McCool por lo que varios webmaster siguieron creando sus parches

para sus servidores web hasta que se contactaron vía email para seguir en conjunto el

mantenimiento del servidor web, fue ahí cuando formaron el grupo Apache.

Características principales

• Es un sistema multiplataforma, corre sobre varios sistemas operativos.

• Ofrece una tecnología de código abierto.

• Es un servidor web de diseño modular, puede ser adaptado a diferentes

entornos.

• Trabaja en conjunto con lenguajes de programación como PHP, Perl, Java, JSP

y otros.

• Es extensible en su funcionalidad y calidad de sus servicios.

• Incentiva la realimentación de los usuarios, obteniendo nuevas ideas, informes

de fallos y parches para la solución de los mismos. (Perla Arredondo Morales,

2009)



2.2.2.1. Arquitectura del servidor Apache

Ilustración 17. Arquitectura del servidor Apache.13

Como se ve en la figura 17 la arquitectura de apache consta de módulos:

El módulo base o core tiene la funcionalidad básica de asignar peticiones y gestiona

las conexiones.

Además consta de módulos multi-proceso: mpm_common, perchild, prefork, worker

que aceptan peticiones por los puertos y las redirige a otros.

Otros módulos adicionales importantes son:

mod_access: control de acceso

mod_alias: redirección de URLs

mod_rewrite - reescritura de direcciones (transforma páginas dinámicas como

php en páginas estáticas html)

mod_auth_ldap – Autenticación de usuarios con servidor LDAP

mod_perl - Páginas dinámicas en Perl

mod_php - Páginas dinámicas en PHP

mod_python - Páginas dinámicas en Python 13 Tomado de: http://www.fdi.ucm.es/profesor/jpavon/web/31-ServidoresWeb-Apache.pdf



mod_ruby - Páginas dinámicas en Ruby

mod_ssl - Comunicaciones Seguras vía TLS

mod_security - Filtrado a nivel de aplicación, para seguridad

2.2.2.2. Archivo de configuración de Apache.

El servidor Apache se configura aplicando directivas de texto plano a los archivos

de configuración. Además otros archivos de configuración pueden añadirse usando la

directiva Include y algunos wildcards pueden utilizarse para incluir más archivos de

configuración.

Los archivos de configuración de Apache contienen una directiva por línea. La barra

invertida "\" se utiliza al fin de línea para indicar que la directiva continúa en la siguiente

línea. Las líneas que comienzan con un caracter "#" son considerados comentarios y

son ignorados.

Los archivos de configuración más característicos son:

Apache2.conf; es el fichero de configuración principal del servidor. Por medio de

directivas incluye en este fichero los módulos necesarios y el resto de la configuración

de los restantes ficheros de configuración.

Httpd.conf; este fichero se mantiene por razones de compatibilidad con la primera

versión de Apache. Además se recomienda que la configuración de los módulos de

terceros vayan en este fichero.

/etc/apache2/sites-available; es el directorio donde se tienen los ficheros de

configuración de los diferentes sitios virtuales. El fichero default-000 contiene la

configuración del sitio por defecto.

/etc/apache2/sites-enabled; es un directorio donde existe enlaces simbólicos a los

ficheros de configuración de los sitios virtuales (en el directorio /etc/apache2/sites-

available) que están activos.



Ports.conf; es el fichero de configuración donde se indica el puerto por el que escucha

el servidor y en su caso la dirección IP, inicialmente viene configurado para escuchar

sólo en el 80/tcp.

/etc/apache2/mods-avalaible; directorio que aloja todos los módulos instalados en el

servidor.

/etc/apache2/mods-enabled; directorio que aloja mediante elnaces simbólicos a al

directorio anterior, todos los módulos activos en el servidor.

La configuración del servidor por defecto define un host virtual default cuyo

directorio de trabajo es /var/www, por lo tanto para probar que el servidor está instalado

podemos poner en un navegador http://localhost, con lo que se visualizará la página

web guardada en este directorio. (Intef, 2012)

2.2.2.3. Virtual Hosts

Apache tiene la posibilidad de permitir alojar varios sitios web (múltiples dominios y

direcciones IP) en un solo servidor Apache. A esto se le llama virtual host y cada uno

de estos se configura por separado, con sus logs, sus directivas y restricciones.

(Apache.org, 2010)

2.2.2.4. Versiones de Apache

Apache actualmente tiene 2 versiones la 2.0.xx y la versión 1.3.xx. La versión 1.3.xx

es la versión clásica de Apache que está especialmente optimizada para plataformas

Unix. La versión 2.0.xx introduce cambios en el funcionamiento interno que permite su

utilización en otros sistemas operativos. Es más rápida y más estable en sistemas que

no son tipo Unix, tales como BeOS, OS/2, Windows y Macintosh.



Las versiones disponibles ahora son la versión 1.3.31 que mejora aspectos de

seguridad y permite utilizar protocolos SSL y TLS al igual que la versión 2.0.49 que

además mejora aspectos de vulnerabilidad de accesos remotos. (Mestras, 2012)

2.3. Navegador WEB

2.3.1. Introducción a Navegador web.

Un navegador o explorador web es una aplicación software que permite al usuario o

cliente recuperar y visualizar documentos de hipertexto, comúnmente escritos en

HTML, desde servidores web de todo el mundo a través de Internet.

Esta red de documentos es denominada WorldWide Web (WWW). Cualquier

navegador actual permite mostrar o ejecutar gráficos, secuencias de vídeo, sonido,

animaciones y programas diversos además del texto y los hipervínculos o enlaces.

En la actualidad se utilizan principalmente cinco navegadores: Internet Explorer,

Firefox, Safari, Chrome y Opera. Los ejemplos de este documento se refieren a

navegadores de código abierto, como Firefox, Chrome. Según las estadísticas sobre

navegadores de StatCounter, actualmente el uso conjunto de Firefox, Safari y Chrome

representa el 75% del uso global. Por lo tanto, en estos momentos los navegadores de

código abierto constituyen una parte importante del mercado de los navegadores.



Ilustración 18. Servidores web más utilizados.14

La función principal de un navegador es solicitar al servidor los recursos web que

elija el usuario y mostrarlos en una ventana. El recurso suele ser un documento HTML,

pero también puede ser un archivo PDF, una imagen o un objeto de otro tipo. El

usuario especifica la ubicación del recurso mediante el uso de una URI (identificador

uniforme de recurso).

La forma en la que el navegador interpreta y muestra los archivos HTML se

determina en las especificaciones de CSS y HTML.

2.3.2. Componentes de un navegador web

Interfaz de usuario: Incluye la barra de direcciones, el botón de avance/retroceso, el

menú de marcadores, etc.

14 Tomado de StatCounter



Motor de búsqueda: coordina las acciones entre la interfaz y el motor

de renderización.

Motor de renderización: es responsable de mostrar el contenido solicitado. Por

ejemplo, si el contenido solicitado es HTML, será el responsable de analizar el código

HTML y CSS y de mostrar el contenido analizado en la pantalla.

Red: es responsable de las llamadas de red, como las solicitudes HTTP. Tiene una

interfaz independiente de la plataforma.

Servidor de la interfaz: permite presentar widgets básicos, como ventanas y cuadros

combinados. Muestra una interfaz genérica que no es específica de ninguna

plataforma.

Intérprete de JavaScript: permite analizar y ejecutar el código JavaScript.

Almacenamiento de datos: es una capa de persistencia. El navegador necesita

guardar todo tipo de datos en el disco duro (por ejemplo, las cookies). La nueva

especificación de HTML (HTML5) define el concepto de "base de datos web", que

consiste en una completa base de datos del navegador.

Ilustración 19. Componentes de un navegador web.15

15 Tomado de: http://www.html5rocks.com/es/tutorials/internals/howbrowserswork/#Introduction



Es importante mencionar que Chrome, a diferencia de la mayoría de los

navegadores, implementa varias instancias del motor de renderización, una por cada

pestaña. Cada pestaña representa un proceso independiente. (Garsiel, 2011)

2.3.3. Navegadores y versiones que soportan el estándar WebRTC

Desde la página principal del proyecto de WebRTC los tres navegadores que

soportan WebRTC son: Chrome, Firefox y recientemente el navegador Opera.

2.3.3.1. Google Chrome

Como Google es el promotor de esta tecnología, implementó el

estándar WebRTC desde la versión 23 de Chrome.

Para dispositivos android Chrome implementó la API desde la versión 29. La

versión actual de Chrome y muy estable es la versión 33.

2.3.3.2. Mozilla Firefox

Por otro lado Mozilla Firefox comenzó a realizar pruebas de componentes que

utiliza WebRTC desde la versión 22, en las versiones posteriores implementaron

mayores componentes y resolvieron ciertos bugs para poder ahora soportar video y

tener un sistema estable. La versión actual de Firefox es la 28 con la cual soporta

directamente el estándar WebRTC.

Este proyecto se basa específicamente en el navegador Chrome y se realizará la

implementación y pruebas con este navegador.



2.4. Aplicación Softphone

2.4.1. Introducción a un Softphone

De sus siglas en inglés Soft de software y phone de teléfono, es una aplicación que

simula las funcionalidades de un teléfono convencional a través de un ordenador. Es

utilizado para llamar a otros softphones o teléfonos convencionales usando VoIP. Es

decir un softphone transforma la computadora en un teléfono multimedia con

capacidad de voz, datos e imágenes.

Por lo general un softphone pertenece al entorno de VoIP que se basa en los

estándares SIP o H.323, actualmente hay muchas implementaciones como Skype,

Hongouts o Lync.

Algunos softphones están implementados completamente en software, que se

comunica con las PABX a través de la Red Local (LAN) - TCP/IP para controlar y

marcar a través del teléfono físico. Generalmente se hace a través de un entorno de

centro de llamadas, para comunicarse desde un directorio de clientes o para recibir

llamadas. En estos casos la información del cliente aparece en la pantalla de la

computadora cuando el teléfono suena, dando a los agentes del centro de llamadas

determinada información sobre quién está llamando y cómo recibirlo y dirigirse a esa

persona. (Wikipedia, 2013)

Características de un Sotfphone

• Soportan señalización SIP / H.323

• Proveen interoperabilidad con otros dispositivos y servicios VoIP como IP-PBX

y Gateways.

• Proveen gran calidad de audio y multimedia.

• Tienen múltiple opciones DTMF

• Poseen varios códec de audio G.729 G.723 G.711, GSM

• Fácil integración con teléfonos USB



• Registración automática de usuarios

• Transferencia y reenvío de llamadas.

• Registro de llamadas.

• Ring tones cambiables.

Entre los teléfonos que soportan varias plataformas como Windows y Linux o para

plataformas para móviles como Android son: Xlite de CountherPat

[www.counterpath.com/x-lite], SJphone de SJLabs [www.sjlabs.com/sjp.html], Zoiper

[www.zoiper.com]. Cada uno de ellos tiene una versión gratis con el funcionamiento

gratis y otra versión paga con más funcionalidades como soportar video y otros códecs

de audio licenciados como G.729.

En este proyecto se probaran con softphone Xlite para Windows y Zoiper para la

aplicación de softphone en un dispositivo Android.

Además para la derivación de la llamada con el sistema NFC, la aplicación de

softphone debería trabajar en conjunto con la aplicación NFC o implementar en su

aplicación el subsistema NFC para que derive la llamada al navegador web.



2.5. Esquema de Red Integral de la solución

Ilustración 20. Esquema de red de la solución.

Como se observa en el esquema, se parte de que se tiene implementado una

central Asterisk para la comunicaciones de una empresa, igual que un servidor web el

cual aloja el sitio web de la empresa. Se tiene registrados teléfonos IP o softphone,

puede ser un softphone en un dispositivo móvil. A demás PC con navegador Chrome

para realizar las comunicaciones WebRTC.



CAPÍTULO 3

Diseño de la solución.

En este capítulo se presenta una evaluación de sistemas actual de la institución y el

posterior diseño de la solución propuesta para realizar un canal de comunicación entre

el navegador web y Asterisk.

3.1. Evaluación de la página actual de la empresa o institución.

Muchas empresas tienen una página web para ofrecer servicios e informar a sus

clientes sus actividades y el rol que desempeñan, avisar productos, de igual forma

atender a un cliente, ya sea colocando datos de contacto como números, mail, o chat.

En la actualidad hay canales de atención con click-to-call utilizando skype por ejemplo.

(Ver figura 21)



Ilustración 21. Ejemplo de página web canal de atención al cliente.

En este proyecto se elige la página web de la Facultad de Ingeniería de la

Universidad de Buenos Aires la cual muestra la información de contacto para

comunicarse vía mail o telefonía tradicional.

Ilustración 22. Página web de la institución.



3.2. Diseño gráfico de la página web.

Para este proyecto conceptual se va a tomar la página de la facultad de ingeniería

como base para el diseño del nuevo canal de atención o contacto. Deberá tener un

botón de llamada el cuál abrirá otra página web dónde mostrará botones de llamado y

contactos a quien llamar. Además de un cuadro dónde se visualice la imagen del

video.

Ilustración 23. Diseño gráfico de la página web “Llamenos”.



Ilustración 24. Diseño gráfico del canal de atención al cliente.

Como se observa en la imagen 24, se tiene un cuadro de texto para ingresar el

número de la extensión al cual queremos llamar y los botones de llamar y colgar. Al

lado derecho se abre el video y se habilita si el operador se encuentra en la estación

de trabajo y con el video habilitado.

3.3. Lenguaje de programación HTML-HTML5

HTML (HyperText Markup Language) es un lenguaje utilizado en el desarrollo de

páginas web. Está principalmente formado por un conjunto de etiquetas las cuales

representan la estructura y objetos que conforman la página.

HTML se basa en referencia de objetos externos; es decir si se desea incrustar una

imagen en la página, no se introduce el código relativo a la imagen en el código, sino

que hace una referencia de tipo texto a dicho objeto, mediante su ubicación.

Una de las versiones actuales de HTML es la 5 (HTML5), que aún en la actualidad

se encuentra en desarrollo. HTML5 establece nuevos objetos que le permiten



adaptarse a las nuevas páginas webs, mucho más dinámicas y de mayor

interactuación con el usuario. HTML5 incorpora etiquetas de tipo canvas 2D, 3D, audio

y vídeo, con la incorporación de códecs para mostrar los datos multimedia, de forma

que ofrece mayor capacidad en el manejo y la animación de objetos o imágenes en la

página web.

HTML5 presenta aplicaciones que trabajan en conjunto para permitir la

comunicación en tiempo real. Las tres principales APIs que presenta WebRTC son:

• Mediastream [comando GetUserMedia()]

• RTCpeerConnection

• RTCDataChannel

3.3.1. Mediastream.

Permite sincronizar el flujo de medios de comunicación. Por ejemplo toma las

señales de entrada de la cámara y micrófono y son sincronizadas en pistas de audio y

video para así trasmitirlas por la red.

Cada MediaStream tiene una entrada, que puede ser un MediaStream generada por

navigator.getUserMedia (), y una salida, que podría ser transmitida a un elemento de

vídeo o un RTCPeerConnection.

3.3.2. RTCpeerConnection.

RTCpeerConnection es el componente WebRTC que maneja la comunicación

estable y eficiente del flujo de datos entre pares. Como se observó en la figura () de la

arquitectura de WebRTC los bloques que comprenden los códecs de audio y video, los

protocolos y señalización utilizados son bastante complejos y es debido a esto que se

hace posible la comunicación en tiempo real incluso a través de redes no confiables:

• Oculta pérdida de paquetes.



• Cancelación de eco.

• Ancho de banda adaptable.

• Búfer de jitter dinámico.

• Control automático de ganancia.

• Reducción y supresión de ruido.

• Mejora la imagen.

3.3.3. RTCDataChannel.

De igual forma así como WebRTC soporta audio y video, también permite

comunicación en tiempo real de otros tipos de datos. La API RTCDataChannel permite

el intercambio de datos arbitrarios de par a par con baja latencia y alto rendimiento.

Esta API se utiliza en casos como:

• Juegos en línea

• Conexión remota

• Chat

• Transferencia de archivos

RTCDataChannel tiene varias características para aprovechar al máximo la

comunicación par a par.

• Aprovechamiento de la configuración de sesión RTCpeerConnection

• Múltiples canales simultáneos con prioridad.

• Seguridad integrada (DTLS) y control de congestión.

• Habilidad de utilizarlo con o sin audio y video.

(Dutton, 2012)



3.4. Establecimiento y Derivación de la llamada.

En esta sección se describe el proceso de registro y establecimiento de una sesión SIP

para luego realizar la sesión de media y derivación de la llamada desde la extensión

SIP al navegador Web.

3.4.1. Registro de una extensión

El siguiente diagrama de flujo muestra la registración de una extensión al Servidor

Asterisk, el agente usuario SIP envía una petición de Registro. El primer paso es

generar las cabeceras con las rutas de Register, luego se envía el Register al Servidor

Asterisk. Se pregunta si llegó la confirmación de registro, si es No, se pregunta si está

autorizado. Si es SI, se envía el Registro Autorizado. Esto representa el

establecimiento de llamada SIP tal como muestra la figura (SIP).



Ilustración 25. Diagrama de bloques del registro de una extensión.

3.4.2. Generación del mensaje INVITE

Luego que se está registrado, se procede a establecer una sesión SIP para la

llamada generando un INVITE. El diagrama de bloques muestra la carga del mensaje

SDP, agregando cabeceras y códec y se envía el mensaje INVITE y se espera su

respuesta. Aceptando ésta con el mensaje 200 OK y por la otra parte enviando el ACK.



Ilustración 26. Diagrama de bloques del mensaje INVITE

3.4.3. Derivación de la llamada

El cliente o usuario SIP debe manejar 2 extensiones en el servidor para poder

habilitar la derivación de la llamada. La una extensión es la del softphone SIP y la otra

es la que utiliza el Navegador Web. Como se describe en el diagrama, si el teléfono

está ubicado en la base NFC, se registra la nueva extensión y genera el nuevo invite a

esta, para luego establecer la sesión de media. Es decir actúa como la opción forward

de un teléfono, deriva la llamada de la una extensión a la otra.



Ilustración 27. Diagrama de bloques de la derivación de la llamada.

3.5. Elementos y APIs para el soporte de WebRTC en Asterisk

Para lograr una comunicación en tiempo real tanto el navegador web como Asterisk

necesitan de elementos de configuración y API’s. El navegador Web en este caso

Chrome trabaja con WebRTC y API’s javascript para realizar una comunicación SIP. La

API más conocida y desarrollada es JAIN SIP. En el servidor Asterisk se requieren

archivos y API’s como: res_http_websocket, chan_sip, res_rtp_asterisk, res_srtp.



3.5.1. JAIN SIP

(Java APIs for Integrated Networks) SIP es una potente herramienta que coloca el

estándar SIP dentro del lenguaje Java para el desarrollo de las telecomunicaciones.

Está diseñado para desarrolladores que requieren un acceso al protocolo SIP y

utilizado al lado del cliente, o un proxy register o dentro de un servidor.

3.5.2. res_http_websocket.

Es un módulo que permite a los desarrolladores de JavaScript interactuar y

comunicarse con Asterisk , agrega un websocket para permitir comunicación SIP.

3.5.3. chan_sip.

Como se describió anteriormente es un módulo del driver de canal SIP. Permite

utilizar el protocolo para señalización.

3.5.4. res_rtp_asterisk.

Este módulo se utiliza para la comunicación en tiempo real, soporta el envío y

recepción de media. A este módulo se le agrega el soporte de ICE, STUN Y TURN

para permitir a los clientes tras NAT comunicarse mejor con Asterisk. (Ver Anexo B)



3.5.5. res_srtp.

Este módulo es importante en Asterisk para soportar WebRTC ya que los datos

RTP son encriptados los mensajes son autenticados e integrados para una

comunicación segura.

3.5.6. chan_pjsip.

Este nuevo canal de driver SIP viene incluido con la instalación de Asterisk en la

versión 12, es una API modular y de poco espacio. Desarrollado en C y combina

protocolo de señalización (SIP) con un rico entorno de trabajo multimedia y

funcionalidad NAT transversal.

3.6. Librerías necesarias para compilar Asterisk

Antes de configurar e instalar Asterisk se necesitan librerías que requieren los

módulos de Asterisk vistos anteriormente. Entre ellos: libuuid-

devel, OpenSSL w/DTLS, libsrtp-devel.

libuuid-devel. Esta librería es requerida por el módulo "res_rtp_asterisk" y permite

habilitar el soporte ICE para que los datos de audio atraviesen por NAT.

OpenSSL w/DTLS. Es una librería para aplicación de criptografía utilizada por

protocolos de seguridad de red como: SSL (Secure Socket Layer) y TLS

(Transport Layer Security). TLS realiza una encriptación para la señalización de la

llamada. Es una forma práctica de Es una forma práctica de evitar el conocimiento de



quien llama a personas que no pertenecen al servidor Asterisk. Se recuerda que la

comunicación WebRTC se realiza con encriptación. (openssl, 2012)

libsrtp-devel. Es la librería originalmente escrita por Cisco que permite el soporte del

protocolo SRTP, añade confidencialidad autenticación y protección de mensajes.

(Davenport, 2011)



CAPITULO 4

Diseño del Sistema NFC.

En este capítulo se describirá de forma conceptual el diseño de software, aplicando

un diagrama de flujos, y hardware NFC necesario para lograr la comunicación de los

dispositivos, el smartphone y la PC realizando la descripción de la derivación de la

llamada.

4.1. Descripción de la aplicación softphone y NFC en el smartphone.

La aplicación de softphone debe trabajar en conjunto con la aplicación NFC, o en sí

La aplicación de softphone debe tener un módulo NFC para poder comunicarse con el

lector NFC conectado a una PC. La aplicación Softphone NFC se basa en java y debe

permitir intercambiar datos de la extensión como número, usuario, password, dirección

IP del servidor.

El sistema NFC debe tener el siguiente funcionamiento:

La aplicación de softphone debe tener guardado en sus datos una segunda

extensión o línea con su respectivo, usuario y password. (Ilustración 28) Tendrá

cargado la dirección de la página web de atención al cliente en una URL. Al momento

de acercar el Smartphone a la base del teléfono, se abrirá el navegador web cargando

la página web y registrando la nueva extensión en el servidor Asterisk. Luego la

aplicación de softphone debe tener la opción de transferir la llamada automáticamente,

cuando detecte conectividad NFC, a la nueva extensión. (ilustración 29) Esta nueva

extensión tendrá habilitado el soporte de video y se podrá realizar la videollamada.



Ilustración 28. Aplicación Softphone en Smartphone.

La ilustración 28 presenta una aplicación de softphone, en este caso Zoiper, el cual se

le puede configurar los parámetros necesarios para poder registrarse en el servidor de

Asterisk.

Ilustración 29. Conectividad NFC entre Softphone y Navegador Web.



4.2. Diseño y descripción del Software de funcionamiento

Para el diseño de software del sistema NFC es necesario conocer qué modo y que

tipo de comunicación se necesita para el correcto funcionamiento del mismo. Como se

describió en el apartado 1.4.2 del capítulo 1, el modo a utilizar es el modo activo

porque tanto como el Smartphone y el lector intercambian datos.

El modo de operación que se debe utilizar es peer-to-peer. Este modo sirve para el

intercambio de pequeñas cantidades de datos utilizando el protocolo NFCIP y NDEF

para el intercambio de mensajes. NFC utiliza a nivel de capa de enlace el protocolo de

control de enlace lógico (LLCP), el mismo que es usado para activación, supervisión y

desactivación de la comunicación. En la figura siguiente se muestra la arquitectura del

modo de operación peer-to-peer.

Ilustración 30. Arquitectura Modo peer-to-peer.16

Para entender el intercambio de datos como: número de extensión, usuario,

password, se define el formato de mensajes NDEF.

16 Tomado de: http://67.222.41.204/wp-content/uploads/2013/12/Technical-Architecture.pdf



4.2.1. Formato NDEF

El formato NDEF o NFC Data Exchange Format es un formato común registrado por

el NFC fórum y es usado para el transporte de diferentes tipos de elementos que van

desde cualquier objeto escrito MIME hasta documentos RTD ultra pequeños, tales

como URLs.

NDEF es un formato binario ligero que puede encapsular uno o más payloads de

diferente tipo y tamaño dentro de la estructura de un solo mensaje. El payload está

identificado por un tipo, una longitud y un identificador opcional. Es simplemente un

formato de mensaje, es decir que solo especifica la estructura del formato por lo que no

se debe pensar que declara algún tipo de circuito o algún concepto de conexión o que

pueda especificar el intercambio de información.

NDEF propone una forma de organizar el contenido almacenado en bytes en la

etiqueta o que viaja de un dispositivo a otro. Se caracteriza por poseer una cabecera

de datos, denominada cabecera NDEF a partir de la cual se encuentran los bloques de

información. Cada bloque de información se agrupa en registros que contienen a su

vez los datos agrupados en mensajes NDEF y caracterizados por un tipo MIME

definido.

Ilustración 31. Estructura del Mensaje NDEF.



Como se puede observar en el mensaje NDEF, se debe realizar un ejecutable que

lea y aplique esta estructura de mensaje y permita leer la URL y los datos de la

extensión. De esta manera al leer la dirección URL se abre el navegador Web y

registra la nueva extensión en el servidor Asterisk. En el momento que termina de

transferir los datos necesarios, la aplicación de softphone realiza la derivación o

transferencia de llamada al navegador web.

En el siguiente diagrama de bloques se describe el funcionamiento del sistema. (Main,

2009)

Ilustración 32. Diagrama de bloques del funcionamiento NFC.

Cabe mencionar que en la extensión nueva a registrar debe tener habilitado el

soporte de video para que se pueda realizar la videollamada. De esta forma la

generación del mensaje SDP se agrega el códec de video a utilizar.



4.3. Diseño y descripción del hardware de funcionamiento.

Para el funcionamiento del sistema de derivación automática de llamada se necesita

un lector NFC conectado por USB a la PC o Notebook.

En el mercado existen kits de dasarrollo NFC para múltiples aplicaciones, uno de estos

es el módulo de desarrollo NFC/RFID PNF532. Ver figura 33.

Ilustración 33. Placa lector/escritor NFC.

Se puede optar también por lectores ya desarrollados como es el caso del

fabricante MIFARE, el lector más común utilizado es ACR 122 USB. (ver figura 34).



Ilustración 34. Lector NFC ACR-122 USB.

4.3.1. Características y funcionalidades del lector NFC ACR 122 USB.

El Lector NFC-USB (ref. AHX2) esunlector detarjetas deproximidad compatible

contarjetas de tecnología Mifare, ISO14443 AyB,NFCyFeliCa.

Funciona a 13.56 MHz y cumple con la norma ISO/IEC18092 de Near Field

Communication (NFC). Es compatible con el driver genérico CCID y PC/SC. Por lo que

permite una fácil interoperabilidad con los diferentes dispositivos y aplicaciones.

Características principales:

• Función de lectura y escritura

• Distancia operativa de hasta 5 cm.

• Función inteligente de anticolisión (si se pasan a la vez varias tarjetas)

• Señalizador LED bicolor



• Soporta los 3 modos de NFC: lector, emulación de tarjeta y modo peer-to-peer

• Compatible CCID

• Velocidad de lectura/grabación de hasta 424 kbps

Compatibilidad con:

• Sistemas operativos Windows, Linux y Mac estándar PC/SC CCID

• Interfaz USB y RS232 (serie)

• Tarjetas Mifare®, FeliCa y NFC (ISO / IEC 18092)

Se puede obtener los drivers y especificación técnica del lector en el siguiente link: http://www.nfc-reader.com/pages/contactless-readers/documents/

http://www.nfc-reader.com/pages/contactless-readers/documents/



CAPITULO 5

Implementación y configuración del sistema de llamada.

En esta sección del Proyecto se describe la implementación utilizando el servidor de

PBX Asterisk y el servidor web Apache. Estos servidores se encuentran virtualizados

con la aplicación de Oracle, Virtual Box.

Para simular la página web de atención al cliente, utilizamos el proyecto de código

abierto SIPML5, que principalmente es un teléfono web, con el cual se configura una

extensión SIP para registrarla en un servidor de PBX.

5.1. Esquema de Red de la implementación.

El siguiente esquema muestra la red y las direcciones de los servidores para

realizar la implementación. Se tiene un Router Wifi para permitir la interconexión de

todos los elementos de red.



Ilustración 35. Diagrama de red de implementación.

5.2. Configuración del servidor Asterisk

Antes de analizar y configurar los parámetros de los archivos de configuración se

debe actualizar/instalar Asterisk 12 para el correcto funcionamiento del sistema. La

compilación y las librerías necesarias para la instalación de Asterisk se presentan en el

Anexo A.

Los archivos necesarios a configurar son:

Sip.conf, rtp.conf, http.conf, extensions.conf y se encuentran en el directorio

/etc/asterisk/.

Editamos el archivo sip.conf y cambiamos los siguientes valores: dentro del

contexto[general].

realm=192.168.0.62 ;En este parámetro colocamos el dominio o dirección IP del

servidor.



bindaddr=0.0.0.0:5060 ;Dirección IP para UDP Y TCP

udpbindaddr=0.0.0.0 ;Dirección IP para enlazar el socket UDP

Ahora editamos el archivo rtp.conf . con este archivo habilitamos el parámetro STUN

para comunicaciones a través de NAT, se puede utilizar cualquier servidor STUN.

icesupport=true ; Se habilita el soporte ICE.

stunaddr=stun.l.google.com:19302 ;Habilitamos el servidor STUN si queremos

utilizar el servicio remotamente a través

de la red pública.

Se continúa con la configuración del archivo http.conf.

[general]

enabled=yes

bindaddr=0.0.0.0

bindport=8088 ;Se habilita la comunicación y puerto http.

Luego que configuramos estos parámetros, procedemos a agregar extensiones para

utilizar en el navegador web con SIPML5 y una extensión común SIP.

En el archivo sip.conf, se agrega:

[8000] ; extension SIPML5

secret=8000

context=default

host=dynamic

trustrpid=no

sendrpid=no

type=friend

qualify=no

qualifyfreq=600



videosupport=no

transport=udp,tls,ws,wss

encryption=yes

allow=ulaw

dial=SIP/8000

callerid=Test WebRTC <8000>

callcounter=yes

avpf=yes

icesupport=yes

directmedia=yes

[1001] ;Extensión común SIP

secret=1001

context=default

host=dynamic

type=friend

allow=ulaw

dial=SIP/1001

callerid=Pedro <1001>

directmedia=no

La extensión 8000 está habilitada y configurada para la extensión WebRTC y la

extensión 1001 es de una extensión común SIP.

Para la extensión 8000, como se muestra en negrita, habilitamos el transporte,

websocket y tls, parámetros básicos para la comunicación WebRTC.

Para realizar y permitir el establecimiento de las llamadas se configura el archivo

extensions.conf. Dentro del contexto [default]:

exten => _100X,1,Dial(SIP/${EXTEN})

exten => _100X,n,Hangup()



exten => _800X,1,Dial(SIP/${EXTEN})

exten => _800X,n,Hangup()

5.3. Configuración y Registro de una extensión desde el clienteSIPML5

5.3.1. Descripción del webphone SIPML5.

SIPML5 es el primer cliente SIP basado en HTML5 de código abierto desarrollado

por la empresa Doubango está escrito totalmente en javascript para la integración con

redes sociales, juegos en línea, sitios de comercio electrónico, sin necesidad de

pluggins o extensiones.

El cliente SIPML5 se puede utilizar para conectarse a cualquier red IMS SIP o

desde su navegador web preferido para hacer y recibir llamadas de audio y video.

También es posible realizar llamadas a cualquier red PSTN o SIP-legacy a través de

un Gateway o habilitando los módulos dahdi de Asterisk.

5.3.2. Configuración del webphone SIPML5.

La siguiente imagen muestra la página principal del cliente SIPML5 modificada y los

campos disponibles para configurar. Como se observa la sección para llenar el registro

de la extensión. Usuario, password, Realm.



Ilustración 36. Página inicio webphone.

Antes de registrar la extensión, hacemos clic en Expert mode y configuramos los

siguientes valores:



Ilustración 37. Webphone Expert Mode.

Se deshabilita el video, para pruebas de audio.

Se configura el websocket que habilitamos con la dirección IP y puerto del servidor

Asterisk ws://192.168.0.62:8088/ws

Se deshabilita los parámetros 3GPP, debug messages, cache media stream. Esto

es para que no se llene la memoria con logs. Si se desea analizar problemas de

comunicación o audio es conveniente habilitarlos.

Se continúa grabando la configuración.

En la página principal se configura los valores de la extensión que se configuró en

Asterisk.



Ilustración 38. Configuración de la extensión SIP.

Se procede a registrar la extensión y aparece el mensaje Connected.

5.4. Configuración de la extensión SIP en el softphone

Para las pruebas realizadas utilizamos un Smarphone Android con el softphone

Zoiper. En las siguientes imagen se muestra la configuración de la cuenta.



Ilustración 39. Configuración de cuenta en softphone Zoiper.

Se procede a configurar la cuenta en el softphone. Se ingresa el usuario y password

para la autenticación, además de la dirección IP del servidor PBX-IP. Cuando se

verifique la autenticación aparece el mensaje de registrado y está preparado para

enviar y recibir llamadas.

5.5. Realización de llamadas de prueba.

Luego que se tiene todas las extensiones configuradas se procede a realizar

llamadas de prueba. En el campo “call control” se ingresa el número de la extensión a

llamar.



Ilustración 40. Llamada a una extensión.

Al momento de hacer clic en “call” aparece realizar llamada solo de audio o audio y

video. Y aparece un mensaje para permitir el acceso a la cámara y micrófono

conectado a la PC.

Ilustración 41. Permitir acceso a micrófono.

Se comprueba el funcionamiento y se verifica la comunicación de audio.



Ilustración 42. Llamada en progreso.

Luego del mensaje de “call in progress” aparece el mensaje de “remote ringing” y

suena la extensión llamada. Cuando se establece la sesión de medios y se puede

escuchar el audio aparece el mensaje de “In call”.



Ilustración 43. Establecimiento de la sesión de media.

Como se observa en el gráfico 43, aparece el mensaje “in call“ y además posee

botones de mantener la llamada, transferir y la opción de panel de números para

marcar.

En la siguiente sección de este capítulo se presenta como realizar mediciones y

revisar posibles problemas de registro o audio con la consola de monitoreo de Asterisk

y la utilidad del navegador Chrome “chrome://webrtc-internals/”

5.6. Medición y análisis de la comunicación.

Para la resolución de conflictos y medición de ciertos parámetros de la

comunicación como: Tasa de bits, jitter, retardo, además problemas con el

establecimiento de la comunicación SIP, se utilizan herramientas para dicho análisis

como:



• La consola javascript de herramientas de desarrollo del navegador chrome.

(F12).

• La utilidad de Chrome. chrome://webrtc-internals.

• Archivos log y consola de Asterisk.

• Wireshark.

5.6.1. Consola Javascript

La consola javascript es una herramienta muy útil al momento de establecer la

comunicación SIP, se pueden observar todos los mensajes SIP que intercambian los

elementos de la comunicación. Antes de esto se tiene que habilitar el parámetro

“debug messages” de la configuración del webphone. En el navegador se ejecuta la

consola con la tecla F12.

Se inicia la llamada y se observan los mensajes.

Ilustración 44. Consola javascript.



Como se observa en el gráfico 44, se tiene un mensaje tipo “INVITE” desde la

extensión 8000 hacia la 1001, se observa también en el campo Call-ID que los valores

están encriptados.

5.6.2. chrome://webrtc-internals/

El navegador Chrome tiene una herramienta muy útil para analizar el flujo de datos

de cualquier comunicación WebRTC. Se accede a ésta escribiendo en su panel de

dirección URL: chrome://webrtc-internals/. Con esta utilidad se puede observar los

campos descriptivos de los mensajes SDP, realiza reportes de cada stream, analiza la

tasa de bits, retardos y ancho de banda.

Al momento de establecer la llamada se pueden observar los siguientes valores:



Ilustración 45. Estadísticas canal 1 webrtc-internals.

En el gráfico se pueden observar, los bytes enviados, los paquetes enviados, el

códec de audio utilizado, el nivel de audio de ingreso.

Se puede observar estadísticas gráficas en tiempo real para analizar cualquier

problema que se presente.



Ilustración 46. Estadísticas gráficas de webrtc-internals.

El gráfico 46 muestra las estadísticas de una llamada webrtc. Presenta los niveles

de ingreso de audio, los bits y paquetes enviados y recibidos. Se puede analizar la

calidad de la red con los valores de jitter y latencia (Rtt) recibidos.

Estas dos herramientas se utilizan para analizar una comunicación webrtc y sip,

además se tiene la consola de asterisk y archivos log para analizar su actividad.

5.6.3. Consola Asterisk y archivos de registro.

Se pueden obtener varios registros de la actividad de asterisk, estos archivos son

ideales para la depuración de problemas. Se pueden configurar para el nivel de análisis

que se necesite. Por ejemplo: Notificación, precaución o error. Para el mejor de los

casos y que registre todos los eventos se le configura como full. La ubicación del

archivo es /var/log/asterisk/full. Por defecto viene habilitado 3 niveles y se encuentran

en el archivo “messages”



Ilustración 47. Archivos de registro.

Además de los archivos de registro (logs) se puede analizar la comunicación dentro

de la consola de Asterisk. Se habilita las pruebas sip y rtp.



Ilustración 48. SIP debug en Consola Asterisk.

Como se puede observar en la ilustración 48, es habilitado la opción de sip

mediante el comando “sip set debug on” y a continuación muestra los eventos que se

realizan. De igual forma sucede cuando se establece la comunicación y se envían

paquetes rtp.



Ilustración 49. RTP debug en consola Asterisk.

5.6.4. Wireshark

Es muy importante indicar que opción de menú de VoIP en wireshark no trabaja

para llamadas sobre websockets. Sin embargo se puede seguir el stream del protocolo

TCP y verificar flujo de señalización SIP. También se debe mencionar que no se puede

decodificar el flujo de media rtp, ya que los datos están encriptados.



Ilustración 50. Análisis de TLS en Wireshark.

Se puede analizar los paquetes TLS instalando una llave privada en wireshark. En el

menú de Edit/Preferences/Protocols/SSL/RSA Key List. Esto se puede hacer si se tiene

disponible la llave. (Citrix, 2012)



Ilustración 51. Desencriptación de TLS en Wireshark.



Conclusiones

Desde la aparición de la VoIP y sus mejoras tecnológicas a través del desarrollo de

nuevos protocolos y estándares se ha permitido la integración de varios servicios de

telecomunicaciones. Esta integración o la denominada convergencia hacia redes de

nueva generación NGN permiten facilitar la administración de una sola plataforma de

red IP, haciendo que las comunicaciones sean más ágiles y reduciendo recursos de

red. WebRTC aporta con esta convergencia ya que trabaja en conjunto con redes IMS.

De esta manera se mantiene una integración total entres redes IP, PSTN y redes de

telefonía móvil.

Este trabajo aporta una parte en lo que se puede utilizar Webrtc, mediante la

utilización de los Websockets se pudo realizar la integración del estándar WebRTC con

la telefonía IP VoIP utilizando la plataforma Asterisk que de igual manera se integra

con la red de telefonía pública.

Se debe considerar que Webrtc no solo es un webphone que puede ser utilizado

con la central Asterisk, es todo un sin número de aplicaciones que se están poniendo

en práctica integrando de esta manera muchos más servicios, como mencionamos

anteriormente; plataformas educativas, traductores de voz, distribución de contenidos.

Con este estudio se pudo aportar a las comunicaciones multimedia basadas en

WebRTC debido a que se realizó una implementación práctica resolviendo así algunos

problemas tanto de conectividad como de desarrollo que se presentaron debido a que

es una tecnología que está todavía en desarrollo.

De igual forma se aporta con una base de conocimientos para investigar la forma de

que webRTC puede integrarse con otros sistemas de redes. Llevando así a una nueva

generación del ecosistema de comunicaciones IP.



También se puede unificar otras tecnologías como en este proyecto se agrega

tecnología NFC para aumentar la disponibilidad y tener un sistema automático de

derivación de llamada.

Con el estudio de los sistemas PBX-IP y servicios web, se logró conocer la vialidad

y facilidad de brindar una solución completa a bajo costo con sistemas de código

abierto como Asterisk y Apache.

Al momento de realizar la implementación del sistema de comunicaciones WebRTC

y Asterisk se tuvo problemas de audio. Se establecía la sesión SIP pero no se tenía

audio en ambos lados. Se logró detectar el problema con el análisis de la comunicación

con las herramientas de análisis y medición descritas anteriormente.

Con la propuesta de este proyecto se obtiene un nuevo canal de comunicaciones.

Es un canal abierto y con el cual se mejora la calidad de servicio al cliente, debido a

que se tiene una mayor disponibilidad de servicio, minimizando tiempo y recursos,

mejorando de esta manera la comunicación con el cliente.



Recomendaciones

Se debe tener en cuenta la actualización o instalación del sistema Asterisk ya que

versiones anteriores a la versión 12 presentan ciertos problemas, uno de ellos es el

audio.

También se debe analizar los códecs a utilizar, WebRTC utiliza el códec de audio

Opus y de video VP8 pero la última actualización de Chrome y el estándar WebRTC

permite utilizar G.711 para audio y H.264 para video. Además de definir la utilización

del códec se debe considerar si tiene la versión actual de Asterisk soporte para dicho

códec. Por ejemplo en la versión 11 de Asterisk no soporta el códec de video VP8, éste

se implementó en la versión 12.

No todos los dispositivos SIP actuales como videoteléfonos, soportan el códec VP8

y Opus. Esto es algo muy importante que se debe tomar en cuenta.

Considerar el número de sesiones que se puedan tener y soporte del servidor. En

caso de ser varias comunicaciones simultáneas, principalmente de video, se deberá

implementar un MCU (Unidad de control multipunto).



Trabajos citados

Alcatel-Lucent. (Mayo de 2013). tmcnet.com. Recuperado el Septiembre de 2014, de http://www.tmcnet.com/tmc/whitepapers/documents/whitepapers/2013/8641-alcatel-lucent-webrtc-ims-systems-webrtc-proprietary-islands.pdf

Apache.org. (Abril de 2010). apache.org. Recuperado el Marzo de 2014, de http://httpd.apache.org/docs/2.2/configuring.html

AstRecipes. (Enero de 2014). AstRecipes. Recuperado el Abril de 2014, de http://astrecipes.net/index.php?q=astrecipes/compiling+asterisk+12+on+centos+6.5

Chavarría, D. A. (Julio de 2011). http://eie.ucr.ac.cr/. Recuperado el Abril de 2014, de http://eie.ucr.ac.cr/uploads/file/proybach/pb2011/pb2011_012.pdf

Citrix. (Noviembre de 2012). Citrix.com. Recuperado el Abril de 2014, de http://support.citrix.com/article/ctx116557

Communicat. (2010). Communicat. Recuperado el Marzo de 2014, de http://www.comunicat.com/downloads/marketing_curso_com_intro_voip.pdf

Davenport, M. (Enero de 2011). asterisk.org. Recuperado el Marzo de 2014, de https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Tutorial

Dutton, S. (Julio de 2012). html5rocks.com. Recuperado el Abril de 2014, de http://www.html5rocks.com/en/tutorials/webrtc/basics/

ECMA. (Junio de 2013). ECMA. Recuperado el Marzo de 2014, de http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-352.pdf

Garsiel, T. (Agosto de 2011). html5rocks.com. Recuperado el Marzo de 2014, de http://www.html5rocks.com/es/tutorials/internals/howbrowserswork/#Introduction

IETF. (2002). IETF. Recuperado el Marzo de 2014, de http://www.ietf.org/rfc/rfc3261.txt

Intef. (2012). www.ite.educacion.es. Recuperado el Abril de 2014, de http://www.ite.educacion.es/formacion/materiales/85/cd/linux/pdf/3-Servidor-web-apache.pdf

Irontec. (2012). Paginaspersonales.deusto.es. Recuperado el Marzo de 2014, de http://paginaspersonales.deusto.es/igor.ira/teaching/courses/voip_irontec_november_2009/igor.ira_Introduccion_a_la_VoIP_y_Asterisk.pdf



Johnston, A. B. (2013). WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web. St. Louis,USA: Digital Codex LLC.

Main, J. (Septiembre de 2009). NFC-Forum. Recuperado el Abril de 2014, de http://67.222.41.204/wp-content/uploads/2013/12/Technical-Architecture.pdf

Mariano Javier Martín, F. A. (2013). http://repositorio.redclara.net/. Recuperado el 2014, de http://repositorio.redclara.net/bitstream/10786/772/1/46-Redes%20Acad%C3%A9micas%20de%20VoIP%20Latinoamericanas%20frente%20al%20desaf%C3%ADo%20de%20las%20nuevas%20tecnolog%C3%ADas-26-04-2013.pdf

Mestras, J. P. (Diciembre de 2012). http://www.fdi.ucm.es/. Recuperado el Marzo de 2014, de http://www.fdi.ucm.es/profesor/jpavon/web/31-ServidoresWeb-Apache.pdf

openssl. (2012). openssl.org. Recuperado el Abril de 2014, de https://www.openssl.org/docs/apps/openssl.html

Pascual, V. (30 de Marzo de 2014). webrtcH4cKS. Recuperado el Septiembre de 2014, de http://webrtchacks.com/ims-approach-webrtc/

Perla Arredondo Morales. (Septiembre de 2009). Monografias.com. Recuperado el Marzo de 2014, de http://www.monografias.com/trabajos75/servidores-web/servidores-web2.shtml#ixzz2wHPUTC1k

Ruiz, A. C. (Junio de 2011). http://e-archivo.uc3m.es/. Recuperado el Abril de 2014, de http://e-archivo.uc3m.es/bitstream/handle/10016/13724/pfcAidaCampaRuiz.pdf?sequence=1

Stidolph, R. (Agosto de 2013). Webrtchacks.com. Recuperado el Mayo de 2014, de http://webrtchacks.com/an-intro-to-webrtcs-natfirewall-problem/

Tejedor, R. J. (2012). http://www.ramonmillan.com/. Recuperado el Marzo de 2014, de http://www.ramonmillan.com/tutoriales/webrtc.php#sthash.L5zRa4tN.dpuf

Wikiasterisk. (Junio de 2012). wikiasterisk.com. Recuperado el Marzo de 2014, de http://www.wikiasterisk.com/index.php?title=Arquitectura

Wikipedia. (Octubre de 2013). Wikipedia. Recuperado el Marzo de 2014, de http://es.wikipedia.org/wiki/Softphone



Anexo A

Instalación y compilación de Asterisk 12

Para este proyecto se utiliza la distribución de Linux Centos 6.5 para instalar Asterisk.

-Lo primero que se hace es actualizar el sistema y obtener las librerías necesarias para

la instalación de Asterisk. En la ventana del terminal ejecutamos los siguientes

comandos:

yum update

yum install openssl-devel gcc-c++ make gnutls-devel kernel-

devel libxml2-devel ncurses-

devel subversion doxygen texinfo curl-devel net-snmp-devel neon-

devel

yum install uuid-devel libuuid-devel sqlite-

devel sqlite git speex-devel gsm-devel

-Se compila la API PJSIP, el cual contiene la librería srtp

wget http://srtp.sourceforge.net/srtp-1.4.2.tgz

tar zxvf srtp-1.4.2.tgz

cd srtp

autoconf

./configure

make

make install

cp /usr/local/lib/libsrtp.a /lib

cd ..

-Con la librería compilada se procede a configurar e instalar PJSIP.



git clone https://github.com/asterisk/pjproject pjproject

cd pjproject/

./configure --prefix=/usr --enable-shared --disable-sound --

disable-resample --disable-video --disable-opencore-amr --with-

external-speex --with-external-srtp --with-external-gsm

./configure --prefix=/usr --libdir=/usr/lib64

make dep

make

make install

cd ..

-Para compilar Asterisk se necesita la API y librerías jansson.

wget http://www.digip.org/jansson/releases/jansson-2.5.tar.gz

tar zxvf jansson-2.5.tar.gz

cd jansson-2.5

./configure --prefix=/

make

make install

cd ..

-Se configura e instala Asterisk 12

wget http://downloads.asterisk.org/pub/telephony/asterisk/asteri

sk-12-current.tar.gz

cd asterisk-12.0.0/

./configure

make menuselect

-En el menú de “Channel Drivers” asegurarse que esté habilitado el nuevo canal

“chan_pjsip”



- Se graba y se sale del menú. A continuación se compila y se instala asterisk.

make

make install

make samples

make config

-Se inicia Asterisk y se ingresa a la consola.

service asterisk start

asterisk -vvvvvvr

(AstRecipes, 2014)



Anexo B

Herramientas WebRTC para NAT/Firewall Traversal

Las comunicaciones peer-to-peer son esenciales para muchas aplicaciones WebRTC

para minimizar la latencia y costos de servidores. Se presentan importantes desafíos

para los dispositivos a través de NAT/firewall para realizar una comunicación peer-to-

peer. Sin embargo WebRTC presenta varios mecanismos para resolver esos conflictos.

Los mecanismos que WebRTC necesita para asignar al navegador web deben tener

ciertas características:

- Aprender la topología entre los pares que desean comunicarse.

- Establecer conectividad con la mejor ruta de la topología dada.

- Tener un mecanismo de redundancia si se presenta un error.

El estándar WebRTC requiere utilizar tres estándares IETF NAT traversal para resolver

los problemas.

- Interactive Connectivity Establishment (ICE) – RFC 5245

- Session Traversal Utilities for NAT (STUN) - RFC 5389

- Traversal Using Relay NAT (TURN) - RFC 5766

ICE intenta encontrar el mejor camino para conectar peers. ICE primero intenta

establecer una conexión mediante la dirección de host obtenido del sistema operativo

de un dispositivo y la tarjeta de red; si eso no funciona (para dispositivos detrás de

NAT) ICE obtiene una dirección externa que utiliza un servidor STUN, y si eso falla, el

tráfico se enruta a través de un servidor de retransmisión TURN. Es decir:

Un servidor STUN se utiliza para obtener una dirección de red externa.

Un servidor TURN transmite el tráfico si la conexión directa (peer-to-peer) falla.

(Stidolph, 2013)

MAESTRIA EN INGENIERIA DE...

Documents

Transcript of MAESTRIA EN INGENIERIA DE...