diseño e implementación de un sistema de comunicación voip...

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Ericson J. Estupiñan P.

Diseño e implementación de un sistema de comunicación VoIP usando la EDU-CIAA.

Autor


Director del trabajo

Esp. Alejandro Celery

Jurado propuesto para el trabajo

- Esp. Ing. Sergio Renato de Jesús Meleán - Esp. Ing. Guillermo Evangelista - Esp. Ing. Marcelo E. Romeo

Página 1 de 30




Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de

Proyectos entre mayo y junio de 2018.

Tabla de contenido

Registros de cambios 3

Acta de Constitución del Proyecto 4

Descripción técnica-conceptual del Proyecto a realizar 5

Identificación y análisis de los interesados 8

1. Propósito del proyecto 9

2. Alcance del proyecto 9

3. Supuestos del proyecto 9

4. Requerimientos 10

5. Entregables principales del proyecto 11

6. Desglose del trabajo en tarea 12

7. Diagrama de Activity On Node 14

8. Diagrama de Gantt 15

9. Matriz de uso de recursos de materiales 17

10. Presupuesto detallado del proyecto 18

11. Matriz de asignación de responsabilidades 19

12. Gestión de riesgos 20

13. Gestión de la calidad 22

14. Comunicación del proyecto 26

15. Gestión de Compras 27

16. Seguimiento y control 27

17. Procesos de cierre 30

Página 2 de 30




Registros de cambios

Revisión Detalle de los cambios realizados Fecha

1.0 Creación del documento 07/05/2018

1.1 Correcciones de redacción y diagramas 23/05/2018

Página 3 de 30




Acta de Constitución del Proyecto

Buenos Aires, 4 de mayo de 2018

Por medio de la presente se acuerda con el Ing. Ericson Joseph Estupiñan Pineda que su Trabajo

Final de la Carrera de Especialización en Sistemas Embebidos se titulará “Diseño e implementación de un

sistema de comunicación VoIP usando la EDU-CIAA”, consistirá esencialmente el prototipo preliminar de

un sistema de comunicación de voz y tendrá un presupuesto estimado de 600 hs de trabajo y $234 USD,

con fecha de inicio lunes 01 de mayo de 2018 y fecha de presentación pública lunes 3 de diciembre de

2018.

Se adjunta a esta acta la planificación inicial.

Ariel Lutenberg

Director de la CESE-FIUBA

Alejandro Celery

Director del Trabajo Final

Esp. Ing. Sergio Renato de Jesús Meleán Esp. Ing. Guillermo Evangelista

Jurado del Trabajo Final Jurado del Trabajo Final

Esp. Ing. Marcelo E. Romeo

Jurado del Trabajo Final

Página 4 de 30




Descripción técnica-conceptual del Proyecto a realizar

Los sistemas de comunicaciones y la Internet han abierto el paso a nuevas tecnologías y paradigmas como lo es el Internet de las Cosas o IoT (Internet of Things). De la mano con los sistemas embebidos se desarrollan nuevas aplicaciones en diferentes áreas industriales y de consumo doméstico. En el área de las comunicaciones, las aplicaciones de voz sobre ip (VoIP) cada día toman más importancia en el día a día de las personas, por esta razón el desarrollo de procesamiento de voz y transporte en sistemas embebidos es fundamental. El presente proyecto plantea el diseño e implementación de un sistema de comunicación VoiP haciendo uso de la plataforma EDU-CIAA. El sistema permitirá la comunicación de voz entre los interlocutores en modo half-duplex o full-duplex dependiendo del modo de operación. Al usar protocolos de comunicación estándar como RTP(Real-time Transport Protocol) y G711 (estándar de la ITU-T para la codificación de audio) se busca que cualquier dispositivo pueda fácilmente ser integrado al sistema, como teléfonos inteligentes, computadoras u otros sistemas embebidos.

Se ha elegido la plataforma de desarrollo EDU-CIAA por ser un elemento de aprendizaje a lo largo de la Especialización de Sistemas Embebidos y además para apoyar sus implementaciones y crecimiento en diferentes aplicaciones de la industria. La EDU-CIAA es una plataforma que usa un procesador de arquitectura ARM contando con muchos beneficios para el desarrollo de sistemas embebidos de bajas, medianas y altas prestaciones. El proyecto busca ser una base conceptual y funcional para nuevos proyectos por lo que también se piensa en la escalabilidad en diferentes familias de los procesadores ARM.

En una descripción más detallada y técnica, los actores del sistema de comunicación son los terminales y el servidor de enrutamiento. Los dispositivos finales son todos aquellos que permitan la reproducción y/o captura de audio, implementando el protocolo de comunicación RTP sobre UDP y la codificación de audio G711. La EDU-CIAA con el debido desarrollo funcionará como una terminal. El servidor de enrutamiento será el encargado de recibir y transmitir los paquetes de voz utilizando el protocolo RTP; bajo reglas de enrutamiento se permite que varios interlocutores tengan diferentes canales de comunicación. El servidor de enrutamiento decide qué dispositivos pueden tener un canal de comunicación y en qué momento destruirlo. Para pruebas del sistema se integrará una aplicación móvil Android que implemente los protocolos propuestos para permitir una comunicación entre la plataforma EDU-CIAA y un teléfono inteligente Android. Ver Figura 1.

Página 5 de 30




Figura 1. Diagrama conceptual del proyecto.

La Figura 2 se ilustra un diagrama de capas de firmware que correrá en los terminales. En caso de streaming de voz la terminal usa un codec de audio que tomará paquetes de 20ms de audio en formato PCM 16bits 8Khz, se codifican en formato G711, se empaquetan en protocolo RTP y se transmiten al servidor. En caso de la recepción de streaming voz, se captura los datos del protocolo RTP, se decodifican y se reproducen en formato PCM 16bit 8Khz.

Página 6 de 30




Figura 2. Diagrama de capas del firmware de la terminales.

El proyecto se destaca especialmente por ser una base conceptual y funcional que permitirá el desarrollo de nuevos proyectos e ideas en el área de las comunicaciones VoIP integrando diferentes dispositivos finales. De esta forma el presente proyecto facilita una base para proyectos tales como:

● Incorporación de protocolo SIP para integración con sistemas PBX Asterisk. ● Citófono IP. ● Radios VoIP multiplataforma. ● Sistemas de altavoz en zonas industriales. ● Etc.

También se busca contribuir a la competitividad de productos nacionales en la industria con un sistema base que facilite el desarrollo de soluciones electrónicas a la medida de las necesidades del cliente.

Página 7 de 30




Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante

Cliente Ariel Lutenberg

Impulsor

Responsable Ericson Estupinan Ingeniero de

desarrollo

Colaboradores

Orientadores Alejandro Celery

Equipo

Opositores

Usuario Final Desarrolladores y/o

futuros estudiantes del

posgrado de Sistemas

Embebidos.

Página 8 de 30




1. Propósito del proyecto

El propósito de este proyecto es diseñar e implementar un sistema de comunicación VoIP que facilite el

desarrollo de nuevos proyectos en el área de las comunicaciones. Además de apoyar con nuevas

implementaciones de la plataforma EDU-CIAA dejando un precedente para futuros proyectos en esta

área.

2. Alcance del proyecto

El proyecto que se presenta en este documento pretende ser una base conceptual y práctica para futuros

proyectos. Por esta razón el alcance se limita a la siguiente lista:

● Captur de voz con la plataforma EDU-CIAA-NXP.

● Reproducción de voz con la plataforma EDU-CIAA-NXP.

● Codificación y decodificación de voz.

● Envío y recepción de paquetes RTP sobre protocolo TCP/IP.

● Implementación de un servidor de comunicación de voz utilizando el protocolo RTP.

● Creación de canales de comunicación desde el servidor.

● Desarrollo de una aplicación para teléfono inteligente Android que se integre al sistema.

A continuación se listan características que no se encuentran en el alcance del proyecto y pueden servir a

futuros proyectos.

● Establecimiento del canal de comunicación desde una terminal.

● Algoritmos de cancelación de eco.

● Algoritmos de detección de voz.

● Establecimiento de sesiones con SIP para llamadas VoIP.

● Algoritmos de compresión de voz.

● Captura y envió de vídeo (Streaming de video.)

Página 9 de 30




3. Supuestos del proyecto

Para el desarrollo del presente proyecto se supone contar con los siguientes elementos y herramientas:

1. Plataforma de desarrollo EDU-CIAA y su IDE (Eclipse) de programación.

2. Soporte de protocolo de transporte UDP en plataforma EDU-CIAA.

3. Velocidad de procesamiento suficiente para recepción y transmisión de audio half-duplex o

full-duplex.

4. Circuitos electrónicos y conectores para salida y entrada de audio para la EDU-CIAA. En caso de

ser necesario, circuitos integrados de codificación de audio.

5. Capacidad económica para la compra de elementos electrónicos (resistencias , condensadores,

conectores, etc) , analizador lógico y elementos que se requieran a lo largo del proyecto.

6. Teléfono inteligente con sistema operativo Android.

7. Headset (auriculares) o micrófonos con conexión estándar (audio jack 3.5mm) .

4. Requerimientos

Los requerimientos del presente documento surgen de la necesidad de cumplir con la principal

funcionalidad de un sistema de comunicación VoIP, la cual es el establecimiento de un canal de voz entre

dos interlocutores.

Requerimientos asociados al sistema (RQ1XX)

● RQ101. El sistema debe establecer un canal de comunicación de voz entre dos dispositivos finales

o terminales, una plataforma EDU-CIAA-NXP y un celular inteligente Android.

Requerimientos asociados a la terminal EDU-CIAA (RQ2XX)

● RQ201. La terminal debe ser compatible con la plataforma EDU-CIAA-NXP usando los puertos

digitales, analogicos, SPI y I2C que sean necesarios.

● RQ202. La terminal debe permitir la captura y reproducción de audio digital PCM 16 bits a

8000Hz.

● RQ203. La terminal debe permitir la codificación y decodificación de audio en el estándar G711.

● RQ204. La terminal debe enviar y recibir datagramas RTP sobre el protocolo de transporte UDP

haciendo uso de algún módulo electrónico que le permita tener conexión ETHERNET.

● RQ205. La terminal desarrollada con la EDU-CIAA debe permitir la conexión de salidas y/o

entradas de audio estándar (Jack 3.5mm). (Ej: auriculares)

● RQ206. Las terminales deben contar con un ID único y reportarse periódicamente al servidor de

enrutamiento, que permita su identificación en la red del sistema.

● RQ207. Los terminales o dispositivos finales deben poder silenciar el micrófono.

Página 10 de 30




Requerimientos asociados a la terminal Android (RQ3XX)

● RQ301. Se debe desarrollar una aplicación para teléfonos inteligentes Android programada en

lenguaje JAVA y hacer uso del framework JNI para implementación de funciones en C de ser

necesario.

● RQ301. La aplicación android debe implementar el protocolo RTP.

● RQ302. La aplicación android debe enviar y recibir datagramas RTP sobre el protocolo de

transporte UDP.

● RQ303. La aplicación android debe permitir la codificación y decodificación de audio en el

estándar G711.

● RQ304. La aplicación Android debe permitir la reproducción y captura de audio.

● RQ305. Las aplicación Android deben contar con un ID único y reportarse periódicamente al

servidor de enrutamiento y permitir su identificación en la red del sistema.

Requerimientos asociados a la Servidor (RQ4XX)

● RQ401. Se debe desarrollar un servidor de enrutamiento UDP que permita la conmutación de

paquetes de voz entre dos terminales o dispositivos finales.

● RQ402. El servidor de enrutamiento debe identificar las terminales o dispositivos finales

conectados al sistema.

● RQ403. El sistema debe permitir la creación y destrucción de canales de comunicación entre dos

terminales desde el servidor de enrutamiento.

● RQ404. El servidor debe enrutar los paquetes de voz y permitir la comunicación de dos terminales

o dispositivos finales.

● RQ405. El servidor de enrutamiento debe poder listar las terminales en el instante.

5. Entregables principales del proyecto

Las entregas principales del proyecto se listan a continuación:

● Memorias del proyecto

● Manual de usuario.

● Diagramas de conexiones eléctricas e instalación a la EDU-CIAA.

● Repositorio GIT de código fuente.

Página 11 de 30




6. Desglose del trabajo en tarea

El proyecto se divide acorde al desarrollo de los subsistemas. Cada grupo de tareas representa el

desarrollo de un subsistema además de gestión del proyecto, recopilación de material bibliográfico y

validación y verificación.

Índice de tarea Tarea Tiempo (horas)

1 Gestión de proyecto 48

1.1 Definición de proyecto, alcances, requerimientos, WBS y plan de trabajo.

28

1.2 Presentación y exposición del proyecto. 20

2 Marco teórico 32

2.1 Búsqueda de bibliografía técnica 12

2.2 Organización y clasificación de información 8

2.3 Escritura de referencias técnicas del proyecto. 12

3 Hardware 56

3.1 Subsistema de micrófono

3.1.1 Definición de sensor de audio o interfaz de micrófono.

12

3.2 Subsistema de audio

3.2.1 Definición de interfaz para reproducción de audio.

12

3.3 Diseño de controles para la comunicación de voz.

12

3.4 Montaje de prototipo. 20

4 Firmware 221

4.1 Definición de interfaces y protocolos (Ethernet, I2C, SPI, ADC, DAC).

16

4.2 Programación de funciones de periféricos. 30

Página 12 de 30




4.3.1 Programación de protocolo G711 codificador y decodificador

35

4.3.2 Programación de protocolo RTP 35

4.4 Programación de funciones TCP/IP UDP. 35

4.5 Programación de API. 30

4.6 Pruebas de funcionamiento. 40

5 Aplicación Android 64

5.1 Programación de captura y reproducción de audio en teléfonos inteligentes Android.

16

5.2 Programación de red para recepción y transmisión de datagramas RTP.

12

5.3 Programación de protocolo RTP 12

5.4 Programación de codificador y decodificador G711.

12

5.5 Programación interfaz de usuario sencilla e intuitiva.

12

6 Servidor 105

6.1 Diseño de servidor de enrutamiento RTP. 25

6.2 Programación de servidor de enrutamiento. 40

6.3 Pruebas de funcionalidad del servidor 40

7 Validación y verificación 44

7.1 Planificación de pruebas de funcionamiento 14

7.2 Pruebas de campo

10

7.3 Validación e informe 10

7.4 Verificación e informe 10

Página 13 de 30




7. Diagrama de Activity On Node En el la Figura 3. se ilustra el diagrama Activity On Node, la ruta crítica es resaltada en líneas rojas y

cuadros rojos. Aunque solo se cuenta con un recurso humano a lo largo del proyecto, se ejecutan tareas

relacionadas en paralelo.

Figura 3. Diagrama AON

Página 14 de 30




8. Diagrama de Gantt

Página 15 de 30




Página 16 de 30




9. Matriz de uso de recursos de materiales

Para el debido desarrollo del proyecto y su correspondiente ejecución, se identifican los siguientes recursos:

1. Computadora. 2. Plataforma de desarrollo EDU-CIAA. 3. Teléfono inteligente Android 4. Servidor de aplicaciones. 5. Diadema o audifonos. 6. Cable de red RJ-45.

La siguiente Tabla ilustra la matriz de uso de recursos.

Código

WBS

Nombre de la tarea

Recursos requeridos (horas) Total

Horas

PC EDU-CIAA Telefono Android

Servidor Diadema

Cable Ethernet

1 Gestión de

proyecto

48 - - - - - 48

2 Marco

Teórico

32 - - - - - 32

3 Hardware 19 19 - - 18 - 56

4 Firmware 55 56 - - 55 55 221

5 App Android 21 - 22 - 21 - 64

6 Servidor 16 16 16 21 16 16 101

7 Validación

y

verificación

29 3 3 3 3 3 44

Total 566

Página 17 de 30




10. Presupuesto detallado del proyecto A continuación se presentan los costos del proyecto, directos e indirectos y su correspondiente tabla detalle:

● Costos directos:

○ Mano de obra

○ EDU-CIAA

○ Módulo de audio.

○ Módulo Ethernet para EDU-CIAA.

○ Elementos electrónicos.

● Costos indirectos

○ Servicios energía, conexión internet.

Detalle Cantidad Costo unidad Costo Total (USD)

Mano de obra 566 horas $19 USD $10754 USD

EDU-CIAA 1 unidad $71 USD $71 USD

Módulo Audio 1 unidad $40 USD $40 USD

Módulo Ethernet 1 unidad $40 USD $40 USD

Elementos electrónicos. N/A $15 USD $15 USD

Servicios energía, conexión eléctrica

566 horas $ 0.12 USD $68 USD

Total sin mano de obra $234 USD

Total $10988 USD

Total $219760 ARG

Total $30’766.400 COL

El costo del proyecto es estimado en dólares americanos.

Página 18 de 30




11. Matriz de asignación de responsabilidades

En este apartado se presenta en la siguiente tabla la asignación de responsabilidades.

Código WBS Título de la tarea

Listar todos los nombres y apellidos y el rol definidos en el proyecto

Ericson J Estupiñan Project Manager

Ericson J Estupiñan Lider de

desarrollo

Alejandro Celery

Director

Usuario

1 Gestión de

proyecto

P R IA

2 Marco Teórico P R A

3 Hardware P A

4 Firmware P A

5 App Android P A

6 Servidor R P A

7 Validación y

verificación

R R IA P

Referencias: P = Responsabilidad Primaria S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado

Página 19 de 30




12. Gestión de riesgos A lo largo del desarrollo del proyecto se hacen visibles los siguientes riesgos de los cuales se presenta una

gestión de los mismos.

Identificación de riesgos.

● Riegos 1: No disponer por algún motivo de la plataforma de desarrollo EDU-CIAA-NXP.

○ Severidad (S): En caso de no contar con la plataforma de desarrollo EDU-CIAA-NXP por

motivos de fallas y/o pérdida. (8)

○ Ocurrencia (O): La probabilidad de este riesgo es mínima pero no nula. (2)

● Riegos 2: No contar con el hardware necesario para captura y/o reproducción de audio.

○ Severidad (S): la reproducción y captura de audio es un punto crucial para el desarrollo

del proyecto. (10)

○ Ocurrencia (O): Por el funcionamiento que se requiere es posible no contar con el

hardware necesario en el mercado. (3)

● Riegos 3: No cumplir con la totalidad de los requerimientos en la fecha de entrega.

○ Severidad (S): el cumplimiento de cada uno de los requerimientos del proyecto es

importante para los objetivos del mismo. (10)

○ Ocurrencia (O): por la candida de requerimientos del proyecto y su alcance por una mala

planeación se puede incumplir el 20% de los requerimientos. (3)

● Riego 4: Cambios en costos de electronica en importación o nacional.

○ Severidad (S): Cambio en costos de elementos electrónicos importados o nacionales. (4)

○ Ocurrencia (O): se considera cierta probabilidad en la que se eleve el costo de elementos

electrónicos. (3)

● Riego 5: No contar con servidor de aplicaciones en la nube.

○ Severidad (S): El servidor de aplicaciones es un elemento importante para el

funcionamiento del proyecto aunque puede ser reemplazado por un computador local.(3)

○ Ocurrencia (O): se considera cierta probabilidad en la que se eleve el costo de elementos

electrónicos. (3)

Tabla de gestión de riesgos.

Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*

1 8 2 16 - - -

2 10 3 30 5 5 25

3 10 3 30 3 10 30

4 3 3 9 - - -

5 3 3 9 - - -

Página 20 de 30




Criterio adoptado: - Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 30. Nota: - Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación. Plan de mitigación de los riesgos.

● Riego 2: Como plan de mitigación se plantea la búsqueda del hardware necesario en el mercado internacional para ser importados.

○ Severidad (S): Se cuenta con elementos estándar en el mercado. (5) ○ Ocurrencia (O): Es muy probable encontrar estos elementos en el mercado. (5)

● Riego 3: Como plan de mitigación se plantea priorizar las funcionalidades y aumentar horas de trabajo de ser necesario.

○ Severidad (S): Se considera cierta severidad que mejora el seguimiento del proyecto. (3) ○ Ocurrencia (O): Se considera una probabilidad del 100%. (10)

Página 21 de 30




13. Gestión de la calidad En este apartado se presenta por cada requerimiento su respectiva gestión de calidad. RQ101. El sistema debe establecer un canal de comunicación de voz entre dos terminales, una

plataforma EDU-CIAA-NXP y un celular inteligente Android.

● Verificación:

○ Verificar hoja de datos de módulos de audio para captura y/o reproducción de audio que

cumpla con formato de audio PCM 16bit 8KHz.

○ Verificar documentación de captura y reproducción de audio en teléfonos inteligentes

Android que cumpla con formato de audio PCM 16bit 8KHz.

○ Verificar documentación para enrutamiento de paquetes de audio entre dispositivos que

cumpla con el protocolo RTP.

● Validación:

○ Establecimiento de un canal de voz y en las terminales se captura , reproduce y transmite

el audio.

RQ102. El sistema debe permitir la creación y destrucción de canales de comunicación entre dos

terminales desde el servidor de enrutamiento.

● Verificación: ○ Verificar mediante consulta de expertos sobre creación de canales de comunicación

desde el servidor de enrutamiento desde una conexión TCP.

● Validación:

○ Mediante evidencias gráficas (imágenes, videos) y funcionales validar la creación de un

canal de comunicación.

RQ103. El servidor debe enrutar los paquetes de voz permitiendo la comunicación de dos terminales o

dispositivos finales.

● Verificación:

○ Verificar mediante consulta de expertos sobre enrutamiento de paquetes de voz para

comunicación entre terminales usando protocolo UDP.

● Validación:

○ Usar sniffer (analizador de protocolos) para asegurar el correcto enrutamiento de

paquetes de voz.

RQ104. El servidor de enrutamiento debe poder listar las terminales en el instante.

● Verificación: ○ Verificar mediante consulta de expertos sobre lista de terminales conectados en el

instante mediante una interfaz TCP. ● Validación:

○ Mediante evidencia gráfica validar lista de terminales.

Página 22 de 30




RQ201. La terminal debe ser compatible con la plataforma EDU-CIAA-NXP usando los puertos digitales, o

análogos, SPI y I2C que sean necesarios.

● Verificación:

○ Verificar hoja de datos de la plataforma EDU-CIAA-NXP que disponga de los puertos

requeridos.

● Validación:

○ Por medio de evidencias textual y funcional validar compatibilidad con plataforma

EDU-CIAA-NXP.

RQ202. La terminal debe permitir la captura y reproducción de audio digital PCM 16 bits a 8000Hz.

● Verificación:

○ Verificar hoja de datos de módulos en el mercado que permita captura y reproducción de

audio en PCM 16 bits 8000Hz.

● Validación:

○ Prueba y evidencia de funcionamiento de captura y reproducción de audio.

RQ203. La terminal debe permitir la codificación y decodificación de audio en el estándar G711.

● Verificación:

○ Verificar mediante consulta a expertos la codificación y decodificación de audio en el

estándar G711.

● Validación:

○ Usar sniffer para evidencias que validen la codificación de audio.

RQ204. La terminal debe enviar y recibir datagramas RTP sobre el protocolo de transporte UDP haciendo

uso de algún módulo electrónico que le permita tener conexión ETHERNET.

● Verificación:

○ Verificar mediante consulta a expertos la posibilidad del uso de un módulo electrónico

ETHERNET para enviar y recibir datagramas RTP.

● Validación:

○ Evidencias gráficas y/o funcionales que validen la transmisión y recepción de datagramas

RTP.

RQ205. La terminal desarrollada con la EDU-CIAA-NXP debe permitir la conexión de salidas y/o entradas

de audio estándar. (Ej: auriculares).

● Verificación:

○ Verificar hoja de datos de módulos en el mercado que permita conexión estándar de

audio. (AUDIO JACk 3.5mm)

● Validación:

○ Evidencia gráfica y/o funcional de conexiones de audio estándar.

Página 23 de 30




RQ206. Las terminales deben contar con un ID y reportarse periódicamente al servidor de enrutamiento,

permitiendo su identificación en la red del sistema.

● Verificación:

○ Verificar mediante consulta de expertos el proceso de identificación única por ID de las

terminales.

● Validación:

○ Evidencia gráfica que valide la identificación de las terminales.

RQ207. Los terminales o dispositivos finales deben poder silenciar el micrófono.

● Verificación:

○ Verificar hoja de datos de módulos o consultar a expertos la funcionalidad de silenciar

micrófono.

● Validación:

○ Evidencia funcional que valida la funcionalidad de silenciar micrófono.

RQ301. Se debe desarrollar una aplicación para teléfonos inteligentes Android programada en lenguaje

JAVA y hacer uso del framework JNI para implementación de funciones en C de ser necesario.

● Verificación:

○ Verificar documentación para creación de aplicaciones Android.

● Validación:

○ Evidencia gráfica y funcional de la aplicación.

RQ301. La aplicación android debe implementar el protocolo RTP.

● Verificación:

○ Verificar documentación de protocolo y consulta a expertos para implementar protocolo

RTP.

● Validación:

○ Evidencia con sniffer (analizador de protocolo) que valide la implementación de RTP.

RQ302. La aplicación android debe enviar y recibir datagramas RTP sobre el protocolo de transporte UDP.

● Verificación:

○ Verificar documentación para implementación de socket UDP en aplicación Android.

● Validación:

○ Evidencias gráficas, funcionales y mensajes de aplicación que validen la transmisión y

recepción de datagramas UDP.

Página 24 de 30




RQ303. La aplicación android debe permitir la codificación y decodificación de audio en el estándar G711.

● Verificación:

○ Verificar documentación de protocolo y consulta a expertos para implementar protocolo

G711.

● Validación:

○ Evidencia con sniffer (analizador de protocolo) que valide la implementación de G711.

RQ304. La aplicación Android debe permitir la reproducción y captura de audio.

● Verificación:

○ Verificar documentación para reproducción y captura de audio en aplicaciones Android.

● Validación:

○ Evidencia gráfica y funcional de la aplicación.

RQ305. Las aplicación Android deben contar con un ID y reportarse periódicamente al servidor de

enrutamiento, permitiendo su identificación en la red del sistema.

● Verificación:

○ Verificar mediante consulta de expertos el proceso de identificación única por ID de las

terminales.

● Validación:

○ Evidencia gráfica que valide la identificación de las terminales.

RQ401. Se debe desarrollar un servidor de enrutamiento UDP que permita la conmutación de paquetes

de voz entre dos terminales o dispositivos finales.

● Verificación:

○ Verificar mediante consulta de expertos sobre enrutamiento de datagramas UDP para

comunicación entre terminales.

● Validación:

○ Usar sniffer (analizador de protocolos) para evidenciar el enrutamiento de datagramas

UDP.

RQ402. El servidor de enrutamiento debe identificar las terminales conectados al sistema.

● Verificación:

○ Verificar mediante consulta de expertos sobre identificación de terminales conectadas al

servidor.

● Validación:

○ Evidencia gráfica y/o funcional que valide la identificación de cada terminal.

Página 25 de 30




14. Comunicación del proyecto El plan de comunicación del proyecto es el siguiente:

PLAN DE COMUNICACIÓN DEL PROYECTO

Desarrollo de etapas

Audiencia Propósito Frecuencia Método de comunicac.

Responsable

Avances de Plan de trabajo

Clase Gestión de Proyectos

Evitar retrasos y errores

3 Semanal Correo, documento compartido

Ericson J Estupiñan

Avances Marco teórico

Director de Proyecto


2 Semanal Correo Ericson J Estupiñan

Avances de hardware



2 Semanal Correo y/o reunión personal


Avances de Firmware





Avances de Aplicación

Android





Avances de Servidor





Avances de Validación y Verificación





Presentación final de

proyecto

Jurados y personas

relacionadas el departamento

de Sistemas Embebidos

Tener claridad en la

comunicación

Unica vez Presentación y documento

memorias.


Página 26 de 30




15. Gestión de Compras Para el desarrollo del proyecto es necesario comprar el servicio de un VPS donde se aloja el servidor de

enrutamiento. Los siguientes son los criterios que el proveedor debe cumplir:

● Sistema Operativo CentOS GNU/Linux.

● Capacidad mínima en disco duro: 10GB.

● Capacidad mínima de RAM: 512MB.

● Capacidad de procesamiento mínimo: 1 CPU.

● Servidor en el continente de América.

Proveedores candidatos:

● VULTR: https://www.vultr.com

● DIGITAL OCEAN: https://www.digitalocean.com/

16. Seguimiento y control

SEGUIMIENTO DE AVANCE

Tarea del

WBS

Indicador de avance

[%]

Frecuencia de reporte

Responsable de

seguimiento

Persona a ser

informada

Método de comunicac.

1 Gestión de proyecto

8,48%

3 semanas Project Manager

Director de proyecto

Correo electrónico, documento compartido

1.1 Definición de proyecto, alcances,

requerimientos, WBS y plan de trabajo. 4,95%

1.2 Presentación y exposición del

proyecto. 3,53%

2 Marco teórico

5,65%



Correo electrónico, documento compartido

2.1 Búsqueda de bibliografía técnica 2,12%

Página 27 de 30

https://www.vultr.com/

https://www.digitalocean.com/




2.2 Organización y clasificación de

información 1,41%

2.3 Escritura de referencias técnicas

del proyecto. 2,12%

3 Hardware

9,89%



Correo electrónico,fotografía, hojas de

datos

3.1 Subsistema de micrófono 0

3.1.1 Definición de sensor de audio o interfaz

de micrófono. 2,12%

3.2 Subsistema de audio 0

3.2.1 Definición de interfaz para reproducción de

audio. 2,12%

3.3 Diseño de controles para la comunicación

de voz. 2,12%

3.4 Montaje de prototipo. 3,53%

4 Firmware

39,05%



Correo electrónico, repositorio

GIT

4.1 Definición de interfaces y

protocolo (Ethernet, I2C, SPI, ADC, DAC). 2,83%

4.2 Programación de funciones de periféricos. 5,3%

Página 28 de 30




4.3.1 Programación de protocolo G711 codificador y decodificador 6,18%

4.3.2 Programación de protocolo RTP 6,18%

4.4 Programación de funciones TCP/IP UDP. 6,18%

4.5 Programación de API. 5,3%

4.6 Pruebas de funcionamiento. 7,07%

5 Aplicación Android

11,31%




GIT

5.1 Programación de captura y reproducción de audio en teléfonos inteligentes Android. 2,83%

5.2 Programación de red para recepción y transmisión de datagramas RTP. 2,12%

5.3 Programación de protocolo RTP 2,12%

5.4 Programación de codificador y decodificador G711. 2,12%

5.5 Programación interfaz de usuario sencilla e intuitiva. 2,12%

6 Servidor

17,84%




GIT

Página 29 de 30




6.1 Diseño de servidor de enrutamiento RTP. 4,42%

6.2 Programación de servidor de enrutamiento. 7,07%

6.3 Pruebas de funcionalidad del sistema en conjunto. 7,07%

7 Validación y verificación

7,77%



Correo electrónico, documento compartido, fotografías,

videos

7.1 Planificación de pruebas de funcionamiento 2,12%

7.2 Puesta en escena del proyecto 1,41%

7.3 Validación e informe 1,77%

7.4 Verificación e informe 1,77%

17. Procesos de cierre Como último apartado se describen las pautas que darán cierre al presente proyecto:

● Reunión presencial o videoconferencia con director de proyecto consignando en un acta el resultado de la reunión.

○ Revisión de cumpliminto de plan de trabajo. ○ Análisis de conclusiones del proyecto. ○ Revisión de técnicas de diseño aplicadas en el proyecto, cuales tuvieron éxito y cuáles no. ○ Revisión de problemas a lo largo del proyecto y su respectiva solución.

● Presentación de proyecto ante jurados. ○ Exposición presencial del trabajo final ante jurados mediante diapositivas y/o vídeos. ○ Demostración del prototipo del proyecto. ○ Palabras de agradecimiento a las personas que directa o indirectamente ayudaron a ser

posible el proyecto.

Página 30 de 30

diseño e implementación de un sistema de comunicación voip...

Documents