PDF

UNIVERSIDAD SIMN BOLVAR
Decanato de Estudios Profesionales

Coordinacin de Electrnica
DESARROLLO DE UN SISTEMA VOIP Y DISEO DE

PROTOTIPO DE EQUIPO TERMINAL HW/SW
Por:
Nery Sorangel Silva Perdomo
Luixany Dynora Velasquez Veita
Sartenejas, Febrero de 2006.


Por:
Realizado con la Asesora de:
Tutor Acadmico: Ing. Fidel Gil
Tutor Industrial: Ing. Rmulo Rojas
PROYECTO DE GRADO
Presentado ante la Ilustre Universidad Simn Bolvar
como requisito parcial para optar al ttulo de Ingeniero Electrnico


PROYECTO DE GRADO presentado por
REALIZADO CON LA ASESORA DE: Tutor Acadmico: Ing. Fidel Gil
Tutor Industrial: Ing. Rmulo Rojas
RESUMEN
Debido a las ventajas incalculables de la tecnologa IP, las empresas se han volcado a
la investigacin y desarrollo de proyectos en esta rea. Particularmente este proyecto parte de
la iniciativa de Avlis Consultores S.A. de disear un sistema VoIP que permita la realizacin
de llamadas telefnicas utilizando esta tecnologa.
El diseo cuenta con dos componentes fundamentales, una aplicacin base Asterisk, el
cual har las funciones de central IP, con una tarjeta interfaz para lneas analgicas de la red
PSTN y un Terminal telefnico con elementos de hardware para el procesamiento de la voz e
interfaz con el usuario (para no sobrecargar el sistema Operativo de la computadora) as como
elementos de software que manejen las funciones de red y los protocolos telefnicos y de
Internet necesarios para el establecimiento de la comunicacin VoIP competitiva.
Este proyecto es slo un abreboca de las innumerables aplicaciones que se pueden
realizar con esta tecnologa, y pone de manifiesto la libertad que ofrece dicha tecnologa para
el desarrollo de proyectos por parte de cualquiera que tenga la iniciativa, debido a la
interoperabilidad que la caracteriza.
PALABRAS CLAVES
VoIP, Telefona, TCP/IP, SIP, Asterisk, Softphone.
Aprobado con mencin:_______
Postulado para el premio:_______
DEDICATORIA
Un da escuch que el regalo ms grande que a sus hijos da el seor, es su madre y el

milagro de su amor. Dedico este trabajo a mi madre que es lo ms grande y hermoso que la
vida me ha regalado. Nos graduamos mi negrita!!!!!!!!!!!!!!
Luixany
Velasquez.
Dedico este trabajo a Jesucristo, por darle sentido a mi vida y por haber ganado este
logro para m. A Isolina, mi madre, por ser el pilar que sostiene mis luchas cotidianas con sus
detalles de amor. A Luis, mi padre, por impulsarme a creer que soar vale la pena. A
Abrahan, mi novio, por recordarme siempre que existe el cielo. Los amo
Nery
Silva.
AGRADECIMIENTOS
A Dios por su presencia constante y por demostrarme una vez ms que su amor y su
poder estn por encima de mis tribulaciones, sostenindome en los momentos ms difciles.
A mis familiares: padres, abuelos, hermanos, tos, padrinos, primos y sobrinos, por la
confianza que han depositado en mi, lo cual fue el motor que impulsaba da a da este logro.
A mis hermanos de MARANATHA, en especial a Luis, a todos agradezco por haber
sido instrumento del amor de Dios en mi vida, sin su compaa y consuelo esto no hubiese
sido posible.
A mis profesores y compaeros de la universidad, porque su presencia y apoyo a lo
largo de todo este camino, definitivamente fue determinante para alcanzar esta hermosa meta.
En especial al profesor Fidel Gil por su ayuda incondicional y a mi compaera de pasanta
Nery, quien lleg a mi vida para ser reflejo de la misericordia de Dios.
A mis amigos incondicionales Lismar, Lisseth y Elias por haberme brindado su
amistad sincera y haberse convertido en uno de mis mayores soportes.
A Avlis Consultores por darme la oportunidad de desarrollar este trabajo, y hacer de mi
primer contacto con el mundo laboral una de las mejores experiencias. En especial a Jorge y
al Sr. Javier por su gran apoyo y confianza.
A todos mis amigos y vecinos, porque en cada ayuda que me brindaban me ofrecan lo
mejor de ellos, aportando as su grano de arena en este logro.
Disfrutemos todos de ste, nuestro triunfo!!!!!!!!!!!!!!!!!!!!
Luixany Velasquez.
Agradezco a Dios por haberme sostenido en esta etapa de mi vida y por suscitarme
una ayuda adecuada en cada momento de dificultad.
Agradezco a mis padres por dar su vida por m y por verme alcanzar mis logros. A mis
hermanos y familiares por animarme siempre a continuar.
Agradezco a mi comunidad por consolarme y rezar por m. Al Padre Willy y a Toi
por sus palabras de aliento en momentos cruciales de mi vida.
Agradezco a Avlis Consultores por darme la oportunidad de realizar mis pasantas all
y por prestarnos toda la ayuda que estuvo a su alcance, especialmente al Sr. Javier por velar
por nuestro bienestar y a Jorge por ser nuestro principal apoyo.
Agradezco a Fidel por ser nuestro tutor y porque nos ha enseado que un profesional
siempre est dispuesto a ser til a los dems. Agradezco al profesor Luis Da Costa por
asistirnos siempre que le hemos solicitado ayuda.
Agradezco a mis amigos Ulloa, Jos Luis y Yuber por estar siempre dispuestos a
ayudarnos. A mis panas de Asobec por ser la mejor compaa en la universidad. Agradezco a
Yury por ser una amiga incondicional y oportuna.
Agradezco a Luixany por ser no slo mi compaera de pasanta, sino por ser tambin
mi amiga y ayuda en los momentos ms difciles durante mis ltimos aos en la universidad.
Y a t Abrahan, por ser como eres conmigo.
A todosmil gracias. Este logro es nuestro!
Nery Silva.
NDICE GENERAL
NDICE GENERAL .....................................................................................................................i
NDICE DE TABLAS Y FIGURAS..........................................................................................iv
LISTA DE SMBOLOS Y ABREVIATURAS .........................................................................vi
CAPTULO I. INTRODUCCIN...............................................................................................1
1.1 Informacin General de la Empresa. .................................................................................2
1.2 Antecedentes y Justificacin. ............................................................................................3
1.3 Visin General del Proyecto..............................................................................................4
1.4 Objetivos............................................................................................................................6
1.4.1 Objetivo General. .......................................................................................................6
1.4.2 Objetivos Especficos. ................................................................................................7
1.5 Alcance y Limitaciones. ....................................................................................................8
1.6 Estructura del informe. ......................................................................................................9
CAPTULO II. FUNDAMENTOS TERICOS. ......................................................................11
2.1 Protocolos de Internet......................................................................................................11
2.1.1 TCP / IP. ...................................................................................................................13
2.1.2 UDP / IP. ..................................................................................................................16
2.1.3 RTP...........................................................................................................................17
2.1.4 RTCP. .......................................................................................................................19
2.2 Protocolos de Telefona tradicional.................................................................................21
2.2.1 Analgica..................................................................................................................21
2.2.1.1 DTMF. ...............................................................................................................22
2.2.1.2 MFC-R2.............................................................................................................22
2.2.1.3 Sealizacin #5..................................................................................................25
2.2.2 Digital. ......................................................................................................................25
2.2.2.1 CCITT Recomendacin Q.931. .........................................................................26
2.2.2.2 Sealizacin #7..................................................................................................29
2.3 Telefona IP. ....................................................................................................................30
2.3.1 VoIP..........................................................................................................................32
2.3.1.1 Funciones de un Sistema VoIP..........................................................................32
2.3.1.1.1 Digitalizacin de la voz. .............................................................................33
2.3.1.1.2 Paquetizacin y Enrutamiento de los paquetes de voz. ..............................39
2.3.1.1.3 Otras funciones. ..........................................................................................40
2.3.2 Caractersticas...........................................................................................................40
2.3.3 Ventajas sobre la telefona tradicional......................................................................41
2.3.4 Retos de la telefona IP: Calidad de Servicio (QoS). ...............................................43
2.3.5 Topologa de una red VoIP.......................................................................................46
2.3.5.1 PSTN. ................................................................................................................47
2.3.5.2 Pasarelas PSTN/IP (Gateway). ..........................................................................48
2.3.5.3 Porteros (Gatekeepers). .....................................................................................48
2.3.5.4 Concentradores Telefnicos (HUBs).................................................................49
2.3.5.5 Telfonos IP.......................................................................................................49
2.3.6 Protocolos utilizados en telefona IP. .......................................................................51
2.3.6.1 H.323. ................................................................................................................51
2.3.6.2 MEGACO..........................................................................................................54
ii
2.3.6.3 SIP. ....................................................................................................................55
2.3.6.4 Soporte para Sealizacin #7. ...........................................................................58
2.3.6.5 RSVP. ................................................................................................................61
2.3.6.6 MPLS.................................................................................................................62
2.3.6.7 Nuevas VPNs. ..................................................................................................66
2.3.7 Centrales IP. .............................................................................................................68
2.3.7.1 Ejemplos de Centrales IP...................................................................................70
2.3.7.2 Asterisk..............................................................................................................72
2.3.7.1.1 Funcionalidad y alcance. ............................................................................73
2.3.7.1.2 Hardware. ...................................................................................................74
2.3.8 Softphones. ...............................................................................................................74
2.3.8.1 X-lite..................................................................................................................75
2.3.8.2 SipXphone. ........................................................................................................75
2.3.8.3 Solucin SipXezphone (Libre). .........................................................................76
2.3.8.3.1 SipXTapi.....................................................................................................77
2.3.8.3.2 SipXCallLib (Call Processing Library). .....................................................78
2.3.8.3.3 SipXezPhone. .............................................................................................78
2.3.8.3.4 SipXmediaLib (Media Processing Library). ..............................................79
2.3.8.3.5 SipXmediaAdapterLib................................................................................80
2.3.8.3.6 SipXportLib................................................................................................80
2.3.8.3.7 SipXtackLib................................................................................................81
CAPTULO III. TELEFONA IP EN VENEZUELA Y EL MUNDO.....................................82
CAPTULO IV. MARCO METODOLGICO ........................................................................90
4.1 Investigacin previa al diseo. ........................................................................................90
4.2 Construccin de una matriz de parmetros y requisitos. .................................................92
4.2.1 Software....................................................................................................................92
4.2.2 Hardware. .................................................................................................................93
4.3 Establecimiento de criterios de diseo. ...........................................................................93
4.3.1 Software....................................................................................................................93
4.3.2 Hardware. .................................................................................................................94
4.4 Equipos utilizados. ..........................................................................................................95
4.5 Softwares utilizados.........................................................................................................95
4.6 Hardware utilizado. .........................................................................................................96
CAPTULO V. DESARROLLO DEL DISEO.......................................................................97
5.1 Instalacin de la central IP...............................................................................................97
5.2 Instalacin de softphones de prueba................................................................................98
5.3 Hardware. ......................................................................................................................101
5.3.1 Generador de Tonos. ..............................................................................................101
5.3.2 Mdulo de Procesamiento de Voz..........................................................................102
5.3.2.1 Circuitos de Reloj y Sincronizacin de seales...............................................103
5.3.2.2 CODEC Ley A CCITT. ...................................................................................104
5.3.3 Microcontrolador. ...................................................................................................104
5.3.3.1 Manejo de Pantalla LCD. ................................................................................105
5.3.3.2 Manejo de Teclado Alfanumrico. ..................................................................106
5.3.3.3 Seales de Control. ..........................................................................................107
5.3.3.3.1 Mdulo de Procesamiento de Voz............................................................107
5.3.3.3.2 Generador de Tonos. ................................................................................108
iii
5.3.3.4 Manejo de Interrupciones externas..................................................................109
5.3.3.5 Manejo de la Comunicacin Serial..................................................................110
5.3.4 Interfaz Serial USB..............................................................................................111
5.4 Software.........................................................................................................................112
5.4.1 Compilacin de la solucin sipXezphone para Windows. .....................................112
5.4.2 Simplificacin de funciones de la solucin sipXezphone. .....................................117
5.4.3 Creacin Clase Puerto Serial. .................................................................................119
5.4.3.1 Instanciacin de la clase. .................................................................................120
5.4.3.2 Rutina de recepcin y revisin de caracteres recibidos...................................121
5.4.3.2.1 Sealizacin..............................................................................................121
5.4.3.2.2 Datos de voz. ............................................................................................122
5.4.3.3 Redireccionamiento de la adquisicin de datos de sealizacin desde el puerto
serial al proyecto principal. .........................................................................................122
5.4.4 Redireccionamiento de la sealizacin proveniente de Asterisk al hardphone a
travs del puerto serial.....................................................................................................122
5.4.5 Redireccionamiento de las invocaciones de los hilos de micrfono y audfono a las
funciones de recepcin y envo de los datos de voz por el puerto serial.........................123
CAPTULO VI. RESULTADOS Y DISCUSIONES. ............................................................125
6.1 Resultados Parciales en Hardware.................................................................................125
6.2 Resultados Parciales en Software. .................................................................................133
6.3 Integracin y pruebas. ...................................................................................................138
CAPTULO VII. CONCLUSIONES Y RECOMENDACIONES..........................................144
REFERENCIAS BIBLIOGRAFICAS ....................................................................................146
APENDICES ...........................................................................................................................150
APNDICE A: ESQUEMATICOS DEL CIRCUITO GENERAL Y CIRCUITO DE PRUEBA
DEL CODEC...........................................................................................................................151
APNDICE B: CARACTERSTICAS PRINCIPALES DEL MICROCONTROLADOR
MC68HC908GP32 Y DEL CODEC TLV320AC37CN. .......................................................153
iv
NDICE DE TABLAS Y FIGURAS

Figura 1.1 Esquema General del Proyecto. .................................................................................5
Figura 2.1 Modelo OSI..............................................................................................................11
Figura 2.2 Comunicacin virtual entre las capas anlogas de dos computadoras.....................12
Figura 2.3 Esquema de empaquetamiento para los paquetes RTP. ..........................................18
Figura 2.4 Estructura General del paquete RTP a nivel de la capa de red. ...............................19
Figura 2.5 Tonos DTMF............................................................................................................22
Figura 2.6 Tonos para eventos telefnicos segn la Norma Europea del CCITT. ...................23
Figura 2.7 Frecuencias utilizadas en el protocolo MFC-R2......................................................24
Figura 2.8 Sealizaciones que se usan en el enrutamiento de una llamada...............................25
Figura 2.9 Modelo general de comunicacin entre centrales y usuarios ISDN. .......................27
Figura 2.10 Formato general de los mensajes correspondientes al protocolo Q.931. ...............28
Figura 2.11 Red ISDN con terminales analgicos y digitales...................................................28
Figura 2.12 Analoga entre las partes del SS7 y las capas del modelo OSI. .............................29
Figura 2.13 Ejemplo de muestreo de una seal de audio. .........................................................33
Figura 2.14 Comparacin entre muestreo a 8 bits y 16 bits. .....................................................34
Figura 2.15 Ejemplo de cuantizacin de una seal de audio.....................................................35
Tabla 2.1 Cdigo binario de los nmeros del 0 al 7. ................................................................35
Figura 2.16 Ejemplo de codificacin de una seal de audio. ....................................................36
Figura 2.17 Curvas de Compresin: Ley y Ley A. ................................................................38
Tabla 2.2 Parmetros tpicos de los SLAs..............................................................................46
Figura 2.18 Elementos de una red VoIP....................................................................................47
Figura 2.19 Diagrama en Bloques General de un Telfono IP..................................................50
Figura 2.20 Estructura General de las capas usando VoIP sobre H.323. .................................54
Figura 2.21 Arquitectura General de una aplicacin SIP. .........................................................58
Figura 2.22 Topologa General de una Red de Sealizacin SS7. ............................................58
Figura 2.23 Topologa General de una Red de Sealizacin SS7 para VoIP............................61
Figura 2.24 Topologa fsica y lgica del sistema enrutador-conmutador. ...............................63
Figura 2.25 Sistemas de envo y control en las redes ATM. .....................................................63
Figura 2.26 Algoritmo de funcionamiento de un LSR. .............................................................64
Figura 2.27 Ejemplo de dominio MPLS entre 2 enrutadores. ...................................................65
Figura 2.28 Red privada virtual, VPN.......................................................................................67
Figura 2.29 Red privada virtual, VPN.......................................................................................68
Figura 2.30 Conexiones Lgicas del MpCallFlowGraph..........................................................79
Figura 5.1. Interfaz grfica y men de configuracin X-Lite....................................................98
Figura 5.2. Interfaz Web de configuracin del SipXphone.....................................................100
Figura 5.3. Interfaz grfica del SipXphone. ............................................................................100
Figura 5.4. Interfaz grfica y men de configuracin del SipXezphone.................................101
Figura 5.5 Diagrama en Bloques del mdulo generador de tonos. .........................................102
Figura 5.6 Diagrama en Bloques del Mdulo de Procesamiento de Voz................................103
Figura 5.7 Diagrama en Bloques del Mdulo de manejo de la LCD. .....................................105
Figura 5.8 Diagrama en Bloques del Mdulo de manejo del Teclado. ...................................106
Figura 5.9 Diagrama en Bloques del Mdulo deMmanejo de Interrupciones Externas..........109
Figura 5.10 Estructura Funcional de la Interfaz USB. ............................................................112
Figura 5.11 Diagrama en Bloques General de sipXmediaLib modificado..............................118
v
Figura 5.12 Modificaciones en la Interfaz Grfica del sipXezphone. ....................................119
Figura 6.1 FSR vs Din, 20s/div. ............................................................................................127
Figura 6.2 FSR vs DCLKR, 20 s/div. ...................................................................................128
Figura 6.3 Din vs DCLKR, 5s/div. .......................................................................................128
Figura 6.4 FSR 0,2 ms/div. FSR 0, 5ms/div............................................................................129
Figura 6.5 Din 0,2 ms/div. Din 0, 5ms/div..............................................................................129
Figura 6.6 Din vs DCLKR negado, 50s/div. .........................................................................130
Figura 6.7 Intercambio de paquetes entre un softphone y la central IP...................................135
Figura 6.8 Mensajes de Llamada saliente (dialing) en softphone. ..........................................139
Figura 6.9 Mensajes de Llamada saliente en hardphone. ........................................................140
Figura 6.10 Mensaje de Conexin de Llamada en softphone..................................................140
Figura 6.11 Mensaje de Conexin de Llamada en hardphone. ...............................................141
Figura 6.12 Mensajes de Falla de Red.....................................................................................141
Figura 6.13 Mensajes de Configuracin del Hardphone. ........................................................142
vi
LISTA DE SMBOLOS Y ABREVIATURAS
ATM Asynchronous Transfer Mode (Modo de Transferencia Asncrona): Estndar ITU, antes
CCITT, para tecnologa donde la informacin de mltiples tipos de servicios (voz, video,
datos) se convierte en celdas pequeas de longitud fija.
AT&T: American Telephone and Telegraph.
Best-Effort: Mejor esfuerzo.
Backbone: parte de la red utilizada como el camino primario para transportar trfico entre
segmentos de red.
CCITT Consultative Committee for International Telegraph and Telephone: Comit
Consultivo Internacional de Telefona y Telegrafa.
CODEC: Codificador/Decodificador.
Datagramas: Paquetes que se enlutan de forma independiente y sin necesidad de establecer
circuitos, es decir, un datagrama es de tipo sin conexin.
DiffServ Differentiated Services Internet QoS model: Modelo de Calidad de Servicio en
Internet basado en Servicios Diferenciados, donde a cada tipo de servicio es asignada una
prioridad dentro del control de flujo en la red.
DNS Domain Name System (Sistema de Nombres de Dominio): Se utiliza principalmente para
relacionar direcciones simblicas con direcciones IP.
DSP: Procesador Digital de Seal, en ingls, Digital Signal Processing.
DTMF: Protocolo Multi-Frecuencial, en ingls, Dual Tone Multi-Frequency.
vii
EEPROM Electrically Erasable Programmable Read Only Memory: Memoria de slo
lectura programable elctricamente.
Enrutador: Dispositivo de la capa 3 del modelo OSI el cual puede decidir por cual de los
varios caminos el trfico de red puede dirigirse basado en alguna mtrica de optimizacin.
FXO: Terminal de Central para lnea analgica, en ingls, Foreing Exchange Office.
FXS: Terminal de Central para suscriptor analgico, en ingls, Foreing Exchange Station.
Hardphone: Trmino empleado para referirse al componente de hardware o fsico del equipo
terminal telefnico.
H.323: Estndar de la ITU-T para voz y videoconferencia interactiva en tiempo real en redes
de rea local LAN, e Internet.
HW/SW: Elemento Hardware/Software.
Intranet: Red propia de uan organizacin, diseada y desarrollada siguiendo los protocolos
propios deinternet, en particular el protocolo TCP/IP. Puede tratarse de una red aislada, es
decir, no conectada a Internet.
IP Internet Protocol (Protocolo Internet): Protocolo utilizado en la capa de red del modelo
OSI con el objetivo de establecer envo y recepcin de paquetes, es un protocolo orientado a
datagrama.
IPSec IP Security (Protocolo de Seguridad IP): Protocolo de Seguridad que funciona sobre IP,
encriptando la informacin de los paquetes a ser transportados a travs de la red.
IPv4: Protocolo Internet versin 4.
viii
ISDN Integrated Services Data Network (Red Digital de Servicios Integrados, RDSI): Es un
modelo de referencia adoptado por el CCITT pensado para proporcionar un servicio ubicuo,
extremo a extremo, interactivo para datos, audio y video.
ISP Internet Service Provider (Proveedor de Servicios Internet): Empresa dedicada a conectar
a Internet la lnea telefnica de los usuarios, redes distintas e independientes, ambas. En
general es una empresa que ofrece a los usuarios un servicio a travs del cual estos pueden
acceder a Internet.
ISUP: Parte de Usuario ISDN, en ingls, ISDN User Part.
ITU-T International Telecommunications Union-Telecommunications (Unin Internacional de
Telecomunicaciones): Organizacin perteneciente al Sistema de las Naciones Unidas donde
los gobernantes y el sector privado coordinan los principios para el funcionamiento de las
redes de telecomunicaciones y los servicios.
IVR Interactive Voice Response: Tecnologa en el rea de telefona por medio de la cual un
usuario, a travs de los tonos generados en la lnea telefnica, interacta con una base de
datos, bien sea para extraer o para ingresar informacin a la misma.
Jitter: Variacin del retraso.
LAN Local rea Network (Red de rea Local): Red que interconecta PC, estaciones de
trabajo, servidores, impresoras, y otros perifricos de elevada velocidad a lo largo de
distancias cortas (habitualmente en la misma planta o edificio).
MCU: Unidad de Conferencia Mltiple, en ingles, Multiple Conference Unit.
MFC-R2: Protocolo de sealizacin multifrecuencial de secuencia forzada, en ingls, MultiFrecuency Code - Regional 2.
ix
MEGACO Media Gateway Control (Control de Pasarela de Medios): Es un protocolo que
define los mecanismos de sealizacin necesaria para permitir al los MGC controlar las
funciones de las pasarelas (gateways) para soportar la transmisin de datos y de voz entre
redes de distinta naturaleza. Este protocolo se presenta como una evolucin del protocolo
MGCP.
MG Media Gateway: Pasarela fsica que conecta de forma bidireccional redes analgicas y las
digitales, realizando la conversin del flujo de una tecnologa a otra.
MGC Media Gateway Control: Entidad lgica que tiene a su cargo el control y manejo de los
MG. Se responsabiliza por toda la operacin de la red, incluyendo la iniciacin de las
llamadas.
MGCP Media Gateway Control Protocol (Protocolo de Control de Pasarela de Medios): Este
protocolo es el antecesor del protocolo MEGACO, y de manera similar es un protocolo de
comunicacin entre los MGC para el control del flujo de paquetes entre redes analgicas y
digitales.
MPLS Multiprotocol Label Switching (Conmutacin de Etiquetas Multiprotocolo): Protocolo
de Internet basado en el cambio de etiquetas entre los conmutadores de una trayectoria. Se
emplea en aplicaciones en tiempo real donde se desee ofrecer calidad de servicio QoS.
MTP: Parte de Transferencia de Mensajes, en ingls, Message Transfer Part.
OSI: Interconexin de sistemas abiertos, en ingls, Open Systems Interconnection.
PBX Private Branch Exchange (Centralita Telefnica Privada): Nodo compuesto por lneas
telefnicas analgicas y tecnologa de conmutacin tradicional entre dichas lneas.
POTS Plain Old Telephone Service (Servicio Telefnico Tradicional): Servicios telefnicos
disponibles para lneas analgicas.
x
PSTN Public Switched Telephone Network (Red de Telefona Conmutada Pblica).
QoS Quality of Service (Calidad de Servicio): Calidad de servicio es un trmino que se refiere
al conjunto de parmetros que caracterizan el trfico de una red.
RAS: Registro, Admisin y Estado, en ingls, Registration, Admission and Status.
RFC Request for Coment (Solicitud de comentario): Borradores que contienen estndares y
especificaciones propuestas. Despus, las RFC se pueden aprobar o simplemente archivar
como recomendaciones histricas.
RSVP Reservation Protocol (Protocolo de Reserva): Protocolo utilizado para ofrecer garanta
de calidad de servicio QoS, a travs de la reservacin de ancho de banda para la transmisin
de paquetes.
RTCP Real Time Control Protocol (Protocolo de Control de Tiempo Real): Protocolo basado
en la transmisin peridica de paquetes de control implementado para realizar funciones de
supervisin de flujo entre terminales de una red digital.
RTP Real Time Protocol (Protocolo de Tiempo Real): Protocolo implementado para
aplicaciones en tiempo real. Es usado con UDP sobre IP para identificacin de carga til,
numeracin secuencial, monitoreo, etc.
SCCP: Parte de Control de Conexin de la Sealizacin, en ingls, Signalling Connection
Control Part.
SIP Session Initiation Protocol (Protocolo de Inicio de Sesin): Protocolo implementado en
telefona digital para el establecimiento de sesiones. SIP es un protocolo ms simple que
H.323 y est basado en texto.
xi
SG Signaling Gateway: Es la interfaz que hace posible la comunicacin entre la red de
sealizacin N 7 y sus elementos de control.
SOFTPHONE: Aplicacin de software que ejecuta las funciones de un telfono.
SS7 Signalling System Number 7 (Sistemas de Seales nmero 7): Conjunto de protocolos
implementados en la sealizacin en redes telefnicas digitales.
TAPIS Telephony Application Programming Interface: Conjunto de funciones programables
implementadas en el desarrollo de aplicaciones interfaz de telefona.
TCAP: Parte de Aplicacin de Capacidades de Transacciones, en ingls, Transaction
Capabilities Application Part.
TCP Transmission Control Protocol (Protocolo de Control de Transmisin): Protocolo de
transporte orientado a conexin encargado de controlar el orden y la prdida de paquetes en la
transmisin bidireccional. Tambin es tarea de este protocolo dividir la data en paquetes de
tamao fijo, adecuados a los requerimientos de la red.
ToS: Tipo de Servicio, en ingls, Type of Service.
UDP User Datagram Protocol (Protocolo de Datagramas de Usuario): Es un protocolo del
nivel de transporte basado en el intercambio de datagramas. Permite el envo de datagramas a
travs de la red sin que se haya establecido previamente una conexin. No tiene control de
flujo, por lo que los paquetes pueden perderse o llegar en desorden
VPN Virtual Private Network (Red Privada Virtual): Es una red privada que se extiende,
mediante un proceso de encapsulacin mediante el encriptamiento de los paquetes de datos
transmitidos a distintos puntos remotos mediante el uso de unas infraestructuras pblicas de
transporte, de modo que se establezca un tnel virtual entre estos puntos.
xii
WFQ: Sistema de Colas Equitativo Ponderado, en ingls, Weighted Fair Queuing.
X.25: Uno de los primeros protocolos de red pblica de conmutacin de paquetes (de datos)
estandarizados por el CCITT. Diseado originalmente para funcionar sobre enlaces de
comunicaciones no fiables, admite servicios tanto de circuitos virtuales como datagrama.
CAPTULO I
CAPTULO I. INTRODUCCIN.
La provisin de los servicios de voz mediante tecnologas de conmutacin de paquetes,
y en particular de protocolo Internet IP, como forma alternativa a la tradicional, est haciendo
cada vez ms inminente la convergencia tecnolgica de la que tanto se ha hecho mencin en el
pasado.
Muchos de los servicios compatibles con la tecnologa de voz sobre IP incluyen
elementos innovadores capaces de ofrecer mucho ms que la telefona clsica: control de
presencia, movilidad, trabajo en grupo (voz + video), etc. As mismo, representan una
importante contribucin a la mejora de la productividad de las empresas, gobiernos,
particulares y al bienestar general.
Aunque las tecnologas de conmutacin de paquetes se han venido empleando desde
hace varios aos para el servicio de datos, su uso para la provisin de voz
ha estado
condicionado por una calidad inferior en las comunicaciones frente a la conmutacin de

circuitos. Aunado a esto, est la menor capacidad de escalabilidad.
En los ltimos aos, sin embargo, las tecnologas IP han acelerado su desarrollo
tecnolgico, mejorando la calidad de los servicios de voz con mejores circuitos de
procesamiento de voz y con protocolos de gestin de paquetes, haciendo confiables las
implementaciones a mayor escala y la posibilidad de emulacin de los servicios ofrecidos por
la conmutacin de paquetes.
Es por esto, que muchas empresas en Venezuela y el mundo, incursionan en la
investigacin de estas tecnologas y en el mercado de servicios de valor agregado
desarrollados sobre las redes IP. En particular, AVLIS Consultores S.A. (ACSA), es una de
ellas.
2
CAPTULO I
1.1 Informacin General de la Empresa.
AVLIS Consultores S.A. (ACSA) es una empresa venezolana, con ms de 8 aos de

operacin continua en el pas, que presta sus servicios en el rea de Tecnologa de la
Informacin (TI), a nivel nacional e internacional.
ACSA cuenta con consultores, funcionales y tcnicos, especializados en la
implantacin de Soluciones Integradas (ERP), integracin de soluciones y, especialmente, en
la implantacin, mantenimiento y soporte de proyectos informticos.
El inicio de ACSA se remonta al ao 1996, cuando la creciente demanda de inversin
en tecnologas, era cada vez ms importante en la mayora de las organizaciones. Desde
entonces, ACSA ha protagonizado una evolucin constante para adaptarse a los cambios del
mercado informtico y para dar respuesta a las necesidades de los clientes, evolucin que se ha
materializado en sectores de Petrleo y Gas, Petroqumica, Manufactura, Servicios, Finanzas,
Banca, Seguros, entre otros.
La misin de ACSA es ofrecer productos y servicios de alta calidad con tecnologa de
vanguardia, brindando a sus clientes flexibilidad, una gran capacidad de integracin en los
equipos de profesionales de los clientes y la colaboracin con terceros a travs de alianzas
tcticas y estratgicas.
La filosofa de la empresa se resume en cuatro puntos fundamentales:
9 Innovacin.
9 Responsabilidad.
9 Integridad.
9 Oportunidad y Rapidez.
3
CAPTULO I
Entre los productos desarrollados destacan:

TELVOICE: Automatizacin de Procesos de Negocios. Solucin para la generacin y
deteccin de llamadas, en el cual: Voz, Datos, Telefona y Procesos de Negocio convergen
para maximizar el uso de su plataforma tecnolgica.
SENTEL: Sistema de Encuesta Telefnica. Producto orientado a Estudios de Mercadeo,
Sondeos de Opinin, Anlisis de Satisfaccin e Impulso de Ventas, a travs de servicios
telefnicos convencionales.
SINECT: Gestin para Negocios de Cines y Teatros. Sistema para dar soporte a los procesos
de ventas en salas de cines y teatros.
SAFT: Administracin y Facturacin Telefnica. Aplicacin para gestionar y controlar la
facturacin telefnica de su organizacin.
Entre los principales clientes de ACSA se encuentran Alcalda Girardot (Maracay),
ONIDEX (Gran Caracas), Alcalda Mayor (Gran Caracas), Alcalda Santiago Mario
(Turmero), Alcalda del Municipio del Hatillo (Gran Caracas), Alcalda San Francisco (Zulia),
entre otros.
1.2 Antecedentes y Justificacin.
Debido al panorama de grandes beneficios que proveen las soluciones basadas en la

tecnologa IP para el manejo de las comunicaciones y servicios de valor agregado, ya muchas
empresas del mundo, y en particular de Venezuela, han desarrollado e implementado dichas
soluciones.
Estas soluciones para las comunicaciones de voz, incluyen el empleo de terminales de
software y hardware, y el uso de centrales telefnicas digitales que ofrecen las ms variadas y
4
CAPTULO I
complejas aplicaciones superando las ofrecidas por las centrales convencionales, con una
calidad de servicio competitiva y una relacin espacio fsico-efectividad favorable, dado los
bajos requerimientos de hardware exigidos por stas.
Todos estos antecedentes, aunados a la imperante necesidad de llevar a cabo
investigaciones y diseos de origen nacional, que adems fueran competitivos con los
existentes en el mercado, han sido el impulso para el desarrollo de este trabajo.
1.3 Visin General del Proyecto.
En los pasados 100 aos, la comunicacin de voz se le haba confiado exclusivamente

a la PSTN (Red Telefnica Conmutada Pblica o "Public Switched Telephone Network"). De
manera que, durante una llamada entre dos lugares, siempre la lnea haba sido dedicada a las
dos partes y ninguna otra informacin poda viajar sobre ella, aunque el ancho de banda
disponible fuera suficiente.
Con el auge de las comunicaciones de datos, las empresas pagaron por lneas de datos
separadas de forma que se pudiera compartir informacin entre las computadoras, mientras
que las comunicaciones de voz y fax eran todava manejadas por la PSTN.
Actualmente, las empresas con redes de datos IP estn usando la tecnologa VOIP (voz
sobre IP) para comunicaciones de voz y envo de faxes sobre sus lneas de datos.
Por el costo de un enlace VOIP en cada oficina, las empresas pueden prescindir de la
PSTN y evitar los cargos de las llamadas de voz o fax de larga distancia sobre las redes de
datos IP existentes.
Conforme a este panorama, la necesidad de las empresas de maximizar el uso de sus
recursos informticos y minimizar los gastos asociados en telefona convencional, se convierte
en una razn de rigor para el diseo e implementacin de soluciones que integren esta
tecnologa VOIP.
5
CAPTULO I
El proyecto que se presenta, propone el desarrollo e implementacin de servicios y

componentes de telefona que permitan la comunicacin de voz entre nodos de una red a
travs del protocolo de comunicaciones TCP/IP, y que permitan tambin el acceso a la red
pblica nacional e internacional mediante el uso de dispositivos teleinformticos, partiendo de
la implementacin de un servidor de Telefona IP, aplicacin base del proyecto.
El proyecto incluye actividades de investigacin, diseo, desarrollo, prueba de los
equipos que deben sustituir los componentes de telefona, software de control e interfaz de
dichos equipos con sistemas informticos, software necesario para adaptar la capa 7 de
aplicacin, as como tambin de instalacin y configuracin del sistema operativo del servidor
y su aplicacin base.
Ms especficamente, se propone el desarrollo de un prototipo de telfono IP de fcil
configuracin que permita la emisin y recepcin de llamadas tanto internas como externas
va USB o SERIAL, y otro componente diseado como servicio o aplicacin que haga uso de
dispositivos convencionales de una computadora. En la figura 1.1 se muestra el esquema
general del proyecto.
Figura 1.1 Esquema General del Proyecto.

El proyecto est conformado, principalmente, por un servidor de telefona IP y estaciones terminales con
componentes de hardware y software.
6
CAPTULO I
Ntese que se observan dos componentes fundamentales:

1.- Servidor de telefona. Este servidor incluye:
Un cpu que contiene la aplicacin base Asterisk, el cual har las funciones de central
IP.
Una tarjeta Interfaz con la PSTN, que permitir la entrada y salida de voz desde y
hacia las lneas de voz analgicas. Por ejemplo, Intel Dialogic D 41JCT-LS.
2.- Estacin Terminal HW/SW. Comprende:

Un prototipo de telfono IP que se encargar de las funciones de captura,
procesamiento de la voz y envo de datos de voz y sealizacin a la computadora de
forma USB o SERIAL.
Una computadora que contiene un programa cliente que llevar a cabo las funciones
de recepcin de datos de voz y sealizacin, empaquetamiento de los datos de voz y de
interfaz con la Internet.
1.4 Objetivos.
1.4.1 Objetivo General.
Diseo de prototipo de equipo Terminal Hardware/Software que permita la emisin y
recepcin de llamadas va USB o SERIAL, y una aplicacin cliente que sea capaz de
interactuar con un servidor de telefona.
7
CAPTULO I
1.4.2 Objetivos Especficos.

a.- Investigar acerca de las plataformas para el servidor de telefona IP existentes en el
mercado.
b.- Seleccionar, configurar y evaluar la aplicacin base que har las funciones de
servidor de telefona IP.
c.- Evaluar dispositivos de telefona convencional y de tecnologa IP.
d.- Desarrollar una aplicacin cliente que interacte con el servidor de telefona y con
el prototipo de telfono IP.
e.- Implementar la circuitera requerida para el manejo de la pantalla de cristal lquido,
que permita la visualizacin de dgitos y sealizacin.
f.- Implementar la circuitera necesaria para el manejo del teclado telefnico de 12
teclas, que permita introducir los dgitos a discar y los datos alfanumricos requeridos para el
proceso de configuracin del telfono prototipo.
g.- Implementar la circuitera necesaria para la generacin de los tonos asociados a
telefona.
h.- Implementar la circuitera que se requiere para el procesamiento de la voz.
i.- Implementar la relojera
necesaria
para la sincronizacin del CODEC de
voz con la unidad de control.

j.- Disear e implementar una unidad de control que procese y coordine las funciones
de pantalla, teclado, procesamiento de la voz y sincronizacin con el CODEC de voz.
8
CAPTULO I
k.- Disear e implementar un protocolo para la comunicacin y sealizacin entre la

unidad de control y el programa cliente.
1.5 Alcance y Limitaciones.
El alcance de este trabajo es el diseo de un sistema VoIP y de un prototipo de equipo

Terminal HW/SW.
El sistema VoIP contempla la investigacin sobre las plataformas para el servidor de
telefona IP (aplicacin base), su seleccin, instalacin y configuracin, y la evaluacin de
dispositivos de telefona convencional y de tecnologa IP.
El prototipo de equipo Terminal HW/SW contempla el diseo de un telfono con
pantalla de cristal lquido para la visualizacin de dgitos y datos de configuracin entrantes,
teclado telefnico de 12 teclas, auricular y micrfono integrado, que se comunique con la
computadora va USB o SERIAL y que sea capaz de interactuar con el programa cliente que
reside en la computadora, el cual se har cargo de todas las funciones de red requeridas para
su comunicacin con el servidor de telefona.
No se contemplan aspectos adicionales tales como:
La implementacin de algunos de los servicios ofrecidos por la aplicacin base seleccionada
(Asterisk): correo de voz con directorio (voicemail), conferencia, IVR, llamada en espera,
soporte para desvo de llamadas, servicios de identificador de llamada (caller ID),
administrador de recursos (ADSI), entre otros.
La implementacin del acceso a la red PSTN a travs de la tarjeta interfaz (gateway) y la
aplicacin base seleccionada (Asterisk).
9
CAPTULO I
Debido a que las labores desempeadas por la empresa tienen un carcter de

consultora predominante, particularmente en el rea de Tecnologa de la Informacin, se
tuvieron las siguientes limitaciones:
Ms fortaleza tcnica en el rea de informtica que en el rea de electrnica.
El personal destinado a prestar asesora a este proyecto requera realizar sus deberes
laborales fuera de las instalaciones de la empresa, lo cual, disminua su disponibilidad de
tiempo.
Falta de dotacin de equipos de laboratorio: instrumentos de medicin, fuentes de
alimentacin, generador de seales, entre otros.
El tiempo de respuesta de los proveedores tambin limit el proyecto, debido a las
ocupaciones inherentes de los mismos, y el tiempo de solicitud y entrega de pedidos de
materiales slo disponibles en el extranjero.
1.6 Estructura del informe.
En el primer captulo se presenta informacin general de la empresa donde se

desarroll el proyecto y una visin general del proyecto. Se hace tambin una introduccin al
problema, planteando los antecedentes que dieron origen al mismo y justificando la
realizacin del proyecto, junto con sus objetivos, alcance y limitaciones.
El segundo captulo contiene el marco terico, donde se introducen y profundizan las
bases tericas que fueron necesarias para el desarrollo del proyecto, como por ejemplo los
protocolos de Internet, de telefona tradicional y de tecnologa IP.
Despus de explorar la motivacin de este proyecto y establecer la teora del mismo, en
el tercer captulo se presenta un breve resumen de las ofertas de telefona IP que proveen las
10
CAPTULO I
principales empresas de telefona de Venezuela, y las ofertas libres propuestas en el mercado

de Internet, con la finalidad de plantear parmetros de diseo que ofrezcan compatibilidad con
lo existente en el mercado y posibilidad de competencia con otros productos de ndole similar.
En el cuarto captulo se describe la metodologa usada para el logro de los objetivos
planteados, y en el quinto captulo se desglosa el desarrollo del diseo propuesto.
Para concluir, en los captulos finales sexto y sptimo, se presentan las conclusiones y
recomendaciones pertinentes basndose en el anlisis de los resultados obtenidos.
CAPTULO II
CAPTULO II. FUNDAMENTOS TERICOS.
2.1 Protocolos de Internet.
Una red es una configuracin de computadoras que intercambian informacin. stas

pueden proceder de una variedad de fabricantes, y es probable, que tengan diferencias tanto en
hardware como en software. Para posibilitar la comunicacin entre ellas,
es necesario
establecer un conjunto de reglas formales para su interaccin.

En 1984, la Organizacin Internacional de Estandarizacin, ISO (International
Standards Organization), desarroll un modelo llamado OSI (Open Systems Interconection),
Interconexin de sistemas abiertos, el cual es usado para describir el uso de datos entre la
conexin fsica de la red y la aplicacin del usuario final. Este modelo es el mejor conocido y
el ms usado para describir los entornos de red. La figura 2.1 ilustra la forma en que estn
organizadas las capas del modelo OSI.
Figura 2.1 Modelo OSI.

El modelo OSI describe formalmente el uso de datos entre la conexin fsica de la red y la aplicacin del
usuario final.
Las capas OSI estn numeradas de abajo hacia arriba. Las funciones ms bsicas, como
el colocar los bits de datos en el cable de red, estn en la parte ms baja, mientras las
funciones que atienden los detalles de las aplicaciones del usuario estn arriba.
12
CAPTULO II
Cada capa en el modelo OSI tiene el propsito de proveer los servicios para la
siguiente capa superior, resguardando los detalles de cmo los servicios son implementados
realmente. stas son abstradas de tal manera, que cada capa cree que se est comunicando con
la capa asociada en la otra computadora, cuando realmente cada una de ellas se comunica slo
con las capas adyacentes de la misma computadora. La figura 2.2 muestra la comunicacin
virtual entre las capas de dos computadoras.
Figura 2.2 Comunicacin virtual entre las capas anlogas de dos computadoras.
La comunicacin real ocurre entre las capas superiores e inferiores de una misma computadora. Sin embargo,
cada capa cree que se comunica con su anloga en el otro equipo.
En la figura 2.2 se puede apreciar que, a excepcin de la capa ms baja del modelo
OSI, ninguna capa puede pasar informacin directamente a su contraparte en la otra
computadora. La informacin que enva una computadora debe de pasar por todas las capas
inferiores. La informacin se mueve entonces a travs del cable de red hacia la computadora
que recibe, y hacia arriba a travs de sus capas, hasta que llega al mismo nivel de la capa que
envi la informacin.
Por ejemplo, si la capa de red enva informacin desde la computadora A, esta
informacin se mueve hacia abajo a travs de las capas de enlace y fsica del lado que enva,
13
CAPTULO II
pasa por el cable de red, y sube por las capas fsica y de enlace del lado del receptor hasta
llegar a la capa de red de la computadora B.
La interaccin entre las diferentes capas adyacentes se llama interfaz. La interfaz
define qu servicios ofrece la capa inferior a su capa superior y de qu forma se tiene acceso a
esos servicios. Las capas se comunican a travs de una serie de reglas denominada protocolo.
2.1.1 TCP / IP.

Se han desarrollado diferentes familias de protocolos para la comunicacin por red de
datos. El ms ampliamente utilizado es el Internet Protocol Suite, comnmente conocido como
TCP / IP (Transmission Control Protocol over Internet Protocol), Protocolo de Control de
Transmisin sobre Protocolo Internet.
La primera meta de diseo de TCP/IP fue construir una interconexin de redes que
proporcionase servicios de comunicacin universales: una red, o Internet. Cada red fsica tiene
su propia interfaz de comunicaciones dependiendo de la tecnologa que la implementa, en la
forma de una interfaz de programacin que proporciona funciones bsicas de comunicacin
(primitivas).
Las comunicaciones entre servicios las proporciona el software que se ejecuta entre la
red fsica y la aplicacin de usuario, y da a estas aplicaciones una interfaz comn,
independiente de la estructura de la red fsica subyacente. La arquitectura de las redes fsicas
es transparente al usuario.
El segundo objetivo de TCP/IP es interconectar distintas redes fsicas para formar lo
que al usuario le parece una nica y gran red. Tal conjunto de redes interconectadas se
denomina "internetwork" o Internet.
14
CAPTULO II
TCP/IP no es un nico protocolo, sino que es un conjunto de protocolos que trata de

reemplazar la funcionalidad de los distintos niveles del modelo OSI. Los dos protocolos ms
importantes son el TCP y el IP, que son los que dan nombre al conjunto.
La arquitectura del TCP/IP consta de cuatro niveles o capas en las que se agrupan los
protocolos, y que se relacionan con los niveles OSI de la forma que se expone a continuacin.
Aplicacin.
Es el nivel ms alto. Los usuarios llaman a una aplicacin que acceda servicios
disponibles a travs de la red de redes TCP/IP. Una aplicacin interacta con uno de los
protocolos de nivel de transporte para enviar o recibir datos.
Cada programa de aplicacin selecciona el tipo de transporte necesario, el cual puede
ser una secuencia de mensajes individuales o un flujo continuo de octetos. El programa de
aplicacin pasa los datos en la forma requerida hacia el nivel de transporte para su entrega.
Transporte.
Coincide con el nivel de transporte del modelo OSI. La capa de transporte regula el
flujo de informacin. En el caso de TCP puede tambin proporcionar un transporte confiable,
asegurando que los datos lleguen sin errores y en secuencia, esto debido, a que se habla de un
protocolo orientado a conexin.
Para lograr mayor confiabilidad, el software del protocolo de transporte se asegura de
que el lado receptor enve acuses de recibo de retorno, y que el lado transmisor retransmita los
paquetes perdidos. Adicionalmente, divide el flujo de datos que se est enviando en pequeos
fragmentos, conocidos como paquetes, y los pasa con una direccin de destino, hacia la
siguiente capa de transmisin. [1]
15
CAPTULO II
Por ejemplo, una entidad de transporte TCP, acepta mensajes de longitud

arbitrariamente grande procedentes de los procesos de usuario, los separa en pedazos que no
excedan de 65.536 octetos y, transmite cada pedazo como si fuera un datagrama separado.
Por su parte, la capa de red, no garantiza que los datagramas se entreguen
apropiadamente, por lo que TCP deber utilizar temporizadores y retransmitir los datagramas
si es necesario. Los datagramas que consiguen llegar, pueden hacerlo en desorden, y
depender de TCP el hecho de reensamblarlos en mensajes, con la secuencia correcta.
Internet.
Es el nivel de red del modelo OSI y se encarga de enviar los paquetes de informacin a
sus destinos correspondientes. Los protocolos del nivel de transporte lo usan con este fin.
Entre stos, el protocolo IP que no es orientado a conexin, sino que se basa en la idea de los
datagramas internos de la red que son transportados transparentemente, pero no siempre con
seguridad, desde la computadora fuente hasta la computadora destino, quizs recorriendo
varias redes mientras viaja.
Este protocolo trabaja de la siguiente manera: la capa de transporte toma los mensajes
y los divide en datagramas. Luego, cada datagrama se transmite a travs de la red interna,
posiblemente fragmentndose en unidades ms pequeas, durante su recorrido normal. Al
final, cuando todas las piezas llegan a la mquina destinataria, la capa de transporte las
reensambla para as reconstruir el mensaje original.
Un datagrama IP consta de una parte de cabecera y una parte de texto. La cabecera
tiene una parte fija de 20 octetos y una parte opcional de longitud variable.
Acceso a Red: "Host to Network".
Este nivel reemplaza la capa fsica y de enlace del modelo OSI. Contiene funciones
que completan la interaccin entre el anfitrin y la red, define la unidad bsica de transferencia
16
CAPTULO II
a travs de la sta e incluye el concepto de direccionamiento de destino y enrutamiento. As, la

red permite que paquetes definidos por los protocolos del nivel 3 sean mayores que el tamao
de la trama que puede ser transferida en el nivel 2.
El software del nivel 3 ensambla un paquete en la forma esperada por la red y utiliza el
nivel 2 para transferirlo (quizs en fragmentos) hacia el conmutador de paquetes. El nivel 3
tambin debe responder a los problemas de congestionamiento en la red. TCP/IP no especifica
ningn protocolo concreto, as es que corre por las interfaces conocidas, como por ejemplo,
X.25.
2.1.2 UDP / IP.

El Protocolo de Datagrama de Usuario, UDP (User Datagram Protocol), no est
orientado a conexin, por lo tanto, cada datagrama UDP existe independientemente del resto
de datagramas UDP, es decir, no hay un nmero de secuencia que los relacione entre s. Por
esta razn, UDP no proporciona ningn tipo de control de errores ni de flujo, aunque s utiliza
mecanismos de deteccin de errores. Cuando se detecta un error en un datagrama, en lugar de
entregarlo a la aplicacin, se descarta.
Por lo antes expuesto, este protocolo no garantiza la fiabilidad. No podemos asegurar
que cada datagrama UDP transmitido llegue a su destino. Es un protocolo del tipo best-effort
(mejor esfuerzo), porque hace lo que puede para transmitir los datagramas hacia la aplicacin
pero no puede garantizar que la aplicacin los reciban. Del mismo modo, no preserva la
secuencia de la informacin que proporciona la aplicacin. La informacin se puede recibir
desordenada (como ocurra en IP) y la aplicacin debe estar preparada por si se pierden
datagramas, llegan con retardo o llegan desordenados.
Este protocolo se ha definido teniendo en cuenta que el protocolo del nivel inferior (el
protocolo IP), tampoco es orientado a conexin y puede ser interesante tener un protocolo de
transporte que explote estas caractersticas.
17
CAPTULO II
El protocolo UDP es muy sencillo y tiene utilidad para las aplicaciones que requieren
pocos retardos o para ser utilizado en sistemas simples que no pueden implementar el
protocolo TCP.
2.1.3 RTP.
El protocolo RTP (Real-Time Transport Protocol), Protocolo de Tiempo Real, es
utilizado para el transporte de la seal vocal. ste tiene como objetivo, asegurar una calidad de
servicio QoS (Quality of Service) para servicios de tipo tiempo real. RTP incluye: la
identificacin de la carga til (payload), la numeracin secuencial, la medicin de tiempo y el
reporte de la calidad, y sus funciones son: la memorizacin de datos, la simulacin de
distribucin interactiva, el control y mediciones de aplicaciones. [2]
Como se mencion anteriormente, el datagrama de UDP no tiene el control sobre el
orden en el cual los paquetes son recibidos o de cunto tiempo toma para llegar ah. Estos dos
puntos son fundamentales para poder hablar de la calidad del audio (qu tan clara se escucha
la voz de la otra persona) y la calidad de la conversacin (qu tan fcil es llevar una
conversacin). RTP resuelve estos problemas permitiendo que el receptor ordene los paquetes
correctamente y que no se retrase por los paquetes que hayan perdido el camino o se tarden
mucho en ser recibidos.
RTP trabaja en la capa de transporte y sobre UDP, de forma que posee un chequeo
redundante para deteccin de error (checksum) y la posibilidad de multiplexacin de puertos
(puerto UDP). Sobre RTP se disponen de protocolos de aplicacin del tipo H.320/323 o SIP
para vdeo y voz.
Para poder realizar las funciones antes mencionadas, se utiliza un tipo de
empaquetamiento para los paquetes RTP con la informacin necesaria para la reconstruccin
del mensaje.
18
CAPTULO II
La figura 2.3 muestra un esquema que ilustra dicho empaquetamiento, que incluye
varios campos:
V: Versin del RTP que se usa.
P: Bit de paridad.
X: Indica la presencia de la extensin del encabezado.
CC: Campo que contiene el nmero de identificadores CSRC que siguen al encabezado. El
campo CSRC se usa por ejemplo cuando hay conferencia.
M: Bit para marcar.
Figura 2.3 Esquema de empaquetamiento para los paquetes RTP.

Este tipo de empaquetamiento para los paquetes RTP, contiene la informacin necesaria para la
reconstruccin del mensaje.
El protocolo RTP puede trabajar en conjunto con el Protocolo de Reserva de Recursos

RSVP (Resource reSerVation Protocol) para la reservacin de ancho de banda, y asegurar de
esta forma la QoS del tipo Garantizada.
La QoS del tipo Diferenciada, se logra mediante la priorizacin de trfico que puede
adoptar dos alternativas. En IP se pueden asignar diversas alternativas de prioridad para
19
CAPTULO II
formar una cola de espera en los enrutadores (routers). Un algoritmo particular de gestin de
prioridad de trfico es el Sistema de Colas Equitativo Ponderado o WFQ (Weighted Fair
Queuing), que emplea un modelo de multiplexacin TDM para distribuir el ancho de banda
entre clientes. Todos los clientes que tienen la misma prioridad, en cuanto a calidad de
servicio, ocupan un intervalo de tiempo en un algoritmo en el que todos tienen igualdad de
condiciones: Round-Robin.
Por otro lado, la funcionalidad del Tipo de Servicio ToS (Type of Service) en IP, puede
determinar un ancho de banda especfico para el cliente. Un servicio sensible al retardo
requiere un ancho de banda superior. En IP, adems del ToS, se puede utilizar la direccin de
origen y destino IP, tipo de protocolo y nmero de socket para asignar una ponderacin.
En la figura 2.4 se ilustra la estructura general del paquete RTP a nivel de la capa de
red, considerando los encabezados IP y UDP correspondientes a dicha capa.
Figura 2.4 Estructura General del paquete RTP a nivel de la capa de red.
Este esquema considera tambin, los encabezados IP y UDP que aade la capa de red al paquete RTP.
2.1.4 RTCP.
El Protocolo de Control de Tiempo Real RTCP (Real-Time Control Protocol), permite
completar a RTP facilitando la comunicacin entre extremos para intercambiar datos,
monitorear la calidad de servicio y obtener informacin acerca de los participantes en la
sesin.
20
CAPTULO II
RTCP se fundamenta en la transmisin peridica de paquetes de control a todos los

participantes en la sesin, usando el mismo mecanismo de RTP de distribucin de paquetes de
datos. El protocolo UDP dispone de distintas puertos como mecanismo de identificacin de
protocolos.
Dado que la funcin primordial de RTCP es la de proveer una realimentacin de la
calidad de servicio, l involucra varios tipos de mensajes para el control de congestin y flujo
de datos, entre ellos:
Receiver Report: para recepcin estadstica desde emisores no activos.
Source Description: para un identificador de nivel de transporte denominado CNAME
(Canonical Name).
Bye: para indicar el final de la participacin en la conexin.
Application: para aplicaciones especficas.
Send report: para emisin y recepcin de estadsticas (en tiempo aleatorio) desde emisores
activos.
Este es uno de los mensajes ms interesantes. Dispone de 3 secciones bien
diferenciadas: los primeros 8 Bytes se refieren a un encabezado comn, la segunda parte de 20
Bytes permite la evaluacin de diferentes parmetros (retardo, variacin del retraso o jitter,
eficiencia de datos, etc).
La tercera parte, de 24 Bytes, lleva reportes que han sido obtenidos desde el ltimo
reporte informado. Incluye los siguientes reportes: cantidad total de paquetes RTP perdidos y a
la proporcin de los mismos, la cantidad de paquetes recibidos y el jitter entre paquetes, el
horario del ltimo paquete recibido y el retardo de transmisin del mismo.
21
CAPTULO II
2.2 Protocolos de Telefona tradicional.

Los protocolos de telefona tienen como funcin principal, brindar la informacin
necesaria sobre las etapas de una llamada, las cuales se pueden clasificar en establecimiento,
mantenimiento y desconexin de la misma.
Esta informacin de inters se denomina
sealizacin.
En la telefona analgica la sealizacin se divide en tres tipos:
Supervisoria. Referida a la asignacin y liberacin de recursos (colgado y descolgado).
De Registro. Contiene informacin de origen y destino (nmeros de telfonos).
Informacin de llamada. Contiene la informacin sobre el estado de la llamada y se divide a
su vez en: Alerta (alerta de repique) y Progreso (tonos de ocupado, cogestin, tono de repique,
etc.).
La sealizacin tambin puede ser forzada, en el caso que se reciban acuses de recibo
de la informacin, y no forzada en caso contrario.
2.2.1 Analgica.
Una de las principales caractersticas de la telefona analgica es que tanto la
sealizacin como la voz viajan por el mismo canal o par telefnico. De aqu que, cuando se
habla de sealizacin en la telefona analgica, se hace referencia a una sealizacin por canal
asociado.
Existen muchos protocolos de sealizacin para telefona analgica. Son objeto de
estudio, en particular, los que han sido utilizados en Venezuela.
22
CAPTULO II
2.2.1.1 DTMF.
El protocolo DTMF (Dual Tone Multi-Frequency), es un protocolo multifrecuencial

utilizado bsicamente para la sealizacin de registro, el cual a travs de la propagacin de
seales de frecuencia especficas entre un suscriptor y su central local, transmite la
informacin sobre el nmero telefnico de destino.
El DTMF es un protocolo de sealizacin de tipo no forzada y las frecuencias
correspondientes a cada dgito telefnico son fijas, y estn determinadas por la suma de dos
valores de frecuencia.
La figura 2.5 representa una matriz que asocia valores de frecuencia determinados a
cada una de sus filas y columnas, recomendados por la UIT - T. A partir de sta, puede
ilustrarse el hecho de que cada tono es la suma de dos valores de frecuencia. Por ejemplo, el
tono para el dgito 1 es la suma de 697 Hz + 1209 Hz, de forma que la frecuencia de este tono
es de 1906 Hz.
Figura 2.5 Tonos DTMF.

Los tonos asociados a cada dgito, se obtienen de la suma de los valores de frecuencia segn su posicin
dentro de una matriz (fila y columna). Por ejemplo, para el 1, el tono es 697 Hz + 1209 Hz = 1906 Hz.
2.2.1.2 MFC-R2.
El protocolo de sealizacin multifrecuencial de secuencia forzada MFC-R2 (MultiFrecuency Code - Regional 2), estandarizado en 1962 por la CCITT, es todava utilizado en
algunas zonas de Amrica Latina, Europa, Australia y Asia, para la comunicacin entre
centrales nacionales.
23
CAPTULO II
Est constituido por un conjunto de seales analgicas a determinadas frecuencias a las

cuales se les ha atribuido previamente un significado especfico para cada caso, es decir, es un
protocolo multifrecuencial donde cada frecuencia tiene un mensaje de sealizacin asociado,
sealizacin que es de tipo forzada.
Cabe destacar que la sealizacin que se transmite a travs de este protocolo, puede ser
de dos tipos: supervisoria o de lnea en cuyo caso se transmite un tono de invitacin a marcar
(TIM), o de progreso en el que se transmitir la seal de congestin, ocupado, o tono de
repique segn sea el caso.
En la figura 2.6 se pueden observar las caractersticas de los tonos antes mencionados,
de acuerdo a la Norma Europea del CCITT. Ntese que es necesario generar un solo tono de
425 Hz y luego, la alternancia del tono con espacios de silencio (denominados cadencia), es lo
que dar origen a todos los tonos de sealizacin de progreso.
Figura 2.6 Tonos para eventos telefnicos segn la Norma Europea del CCITT.
Es necesaria la generacin de un nico tono de 425 Hz. La cadencia es lo que distingue a los tonos de
discado, repique, ocupado y congestin.
Por lo antes expuesto, tanto los equipos terminales como las centrales estn diseados
para la interpretacin de dichas seales, las cuales se transmiten de central a central a travs de
las troncales telefnicas, haciendo el recorrido desde el suscriptor de origen hasta el suscriptor
de destino.
24
CAPTULO II
El protocolo MFC-R2 tiene frecuencias asociadas a todos los mensajes de sealizacin

en cualquiera de sus clasificaciones. Bsicamente los mensajes o seales se dividen en dos
grandes grupos:
Grupo A. Tambin denominadas seales hacia delante o forward, cuya funcin es informar
de algn requerimiento a solicitar a la central siguiente en la trayectoria de enrutamiento de la
llamada.
Grupo B. Tambin denominadas seales hacia atrs o backward, las cuales son utilizadas
slo por la central de destino, para responder a las solicitudes o para dar acuses de recibo de
las seales recibidas a la central previa en la ruta.
De forma anloga al protocolo DTMF, cada seal del MFC-R2 consiste en una
combinacin de 2 frecuencias. Se tienen dos conjuntos de frecuencias, uno para cada sentido
de transmisin (hacia delante o hacia atrs), cada uno formado por 6 diferentes frecuencias.
La figura 2.7 muestra los dos conjuntos de frecuencia utilizados en MFC-R2.
Figura 2.7 Frecuencias utilizadas en el protocolo MFC-R2.

Hay un conjunto de frecuencia para cada sentido de transmisin: hacia delante y hacia atrs. Las seales del
MFC-R2 consisten en una combinacin de 2 frecuencias. Los recuadros negros indican cul par de seales se
suman para obtener la seal de inters.
25
CAPTULO II
2.2.1.3 Sealizacin #5.
Es tambin un protocolo de sealizacin multifrecuencial, constituido por seales hacia

adelante y hacia atrs, pero especficamente utilizado para el intercambio de informacin entre
centrales internacionales. Por tal motivo, a diferencia del MFC-R2 posee seales para indicar
cdigos numricos de los distintos pases, cdigos de rea, as como sealizacin para indicar
si la central que enva la informacin es una central de trnsito o es la propia central de origen,
el idioma que se utiliza en la localidad de donde se recibe el mensaje, o si se recibe de una
operadora internacional entre otras cosas.
El protocolo de sealizacin # 5 es, al igual que en el caso de MFC-R2, una
sealizacin de tipo forzada.
En la figura 2.8 se muestra, de forma general, las distintas sealizaciones que se
utilizan en el enrutamiento de una llamada a travs de centrales analgicas nacionales e
internacionales.
Figura 2.8 Sealizaciones que se usan en el enrutamiento de una llamada.

Ntese que entre suscriptor y central se usa el protocolo DTMF, entre centrales locales se usa MFC-R2 y
entre centrales internacionales se usa el protocolo de sealizacin #5.
2.2.2 Digital.
Todos los protocolos de telefona digital parten del mismo principio: enviar la
informacin necesaria a travs de la transmisin de paquetes con una codificacin binaria
previamente establecida.
26
CAPTULO II
Adicionalmente, en la telefona digital se introduce un nuevo concepto, el de

sealizacin por canal comn, de tal forma que ahora la voz viaja por un canal o par
telefnico, mientras que la sealizacin de todos los canales de un mismo troncal viaja por un
canal independiente de los canales de voz. A partir de esto, es posible supervisar el estado de
la red y adems transmitir informacin sobre el mismo. Esta nueva informacin es un tipo de
sealizacin denominada control de red.
As como en el caso analgico, existen muchos protocolos para telefona digital y en
este trabajo se estudiarn los utilizados en Venezuela.
2.2.2.1 CCITT Recomendacin Q.931.
Una Red Digital de Servicios Integrados, ISDN (Integrate Services Digital Network),
no es ms que un conjunto de nodos que estn interconectados a travs de enlaces de datos.
En general la red est compuesta por equipos terminales ET (TE, Terminal
equipments), que se conectan a un terminal de red TR (NT, network termination) y stos a su
vez, se comunican con un terminal de central TC (ET, exchange termination) a travs de una
lnea de suscriptor digital LSD (DSL, Digital Subscriber Line), para finalmente, mediante
estos terminales llegar a la central local ISDN [3], tal como se muestra en la figura 2.9. De tal
modo, la recomendacin Q931 se utiliza como protocolo digital de comunicacin entre los
subscriptores y su central local, pasando por las etapas antes expuestas.
27
CAPTULO II
Figura 2.9 Modelo general de comunicacin entre centrales y usuarios ISDN.

Los ETs son los equipos terminales. stos se conectan a un terminal de red TR, los cuales se comunican con
un Terminal de Central a travs de una lnea de suscriptor digital LSD para as comunicarse con la Central Local
ISDN.
Los paquetes de la norma Q931 estn compuestos de octetos de bits. Cada octeto tiene
un significado particular, los primeros 3 contienen informacin de cabecera y los restantes
contienen el mensaje que se desea transmitir. Este mensaje puede ser de 11 tipos diferentes,
para el establecimiento, mantenimiento y desconexin de una llamada (SETUP, PROG,
ALERT, CONN, DISC, RLSE, INFO, etc.).
A su vez cada tipo de mensaje permite enviar una gama de informacin tan completa
como se requiera, ya que para ello existen 14 elementos u octetos que permitirn brindar
informacin adicional como: nmero de origen y destino, estado de la llamada, capacidad para
transmitir la informacin, caracterstica del terminal y troncal de origen (modo circuito
analgico modo paquete digital), identificacin y compatibilidad del canal, entre muchos
otros mensajes. La estructura general de estos paquetes se ilustra en la figura 2.10.
28
CAPTULO II
Figura 2.10 Formato general de los mensajes correspondientes al protocolo Q.931.

Todos los mensajes comienzan con una cabecera estndar que comprende los octetos: Tipo de Protocolo,
Referencia de llamada y Tipo de Mensaje.
En la figura 2.11 se muestra un esquema general de una red ISDN, con suscriptores
analgicos y digitales.
Figura 2.11 Red ISDN con terminales analgicos y digitales.

Desde el punto de vista del usuario, ISDN es una red de servicios integrados. Sus lneas de suscriptor digital
pueden ser usadas para la comunicacin en modo circuito o modo paquete.
29
CAPTULO II
2.2.2.2 Sealizacin #7.
El sistema de sealizacin por canal comn N 7 tiene una estructura modular igual
que el sistema OSI, pero en 4 niveles en lugar de 7. Los tres niveles ms bajos, forman la
Parte de Transferencia de Mensajes, MTP (Message Transfer Part), la cual provee esquemas
de deteccin y correccin de errores, y tambin, funciones de enrutamiento, discriminacin y
distribucin dentro de un nodo.
El cuarto nivel lo conforman las Partes de Usuario, UPs (User Parts), que representa
los niveles 4, 5, 6 y 7 en el sistema OSI. En la figura 2.12 se muestra el diagrama del
protocolo de sealizacin N 7 y su analoga con las capas del sistema OSI.
Figura 2.12 Analoga entre las partes del SS7 y las capas del modelo OSI.
Ntese que el nivel 3 de MTP del sistema de sealizacin # 7 + el SCCP = Nivel 3 del sistema OSI.
El sistema de sealizacin por canal comn N 7 no es totalmente compatible con el

sistema OSI. Una gran diferencia es el proceso de comunicacin de la red. El modelo OSI
describe un intercambio de data orientado a conexin,
mientras que SS7 provee slo
transporte sin conexin para la transferencia de datos, ya que sta es la va ms rpida para el
transporte de los mismos.
Para poder ofrecer los dos servicios, orientado a conexin y sin conexin, se origin la
Parte de Control de Conexin de la Sealizacin SCCP (Signalling Connection Control Part),
la cual provee una interfaz entre los niveles de transporte (MTP) y los otros niveles de la red
que en general conforman el modelo OSI.
30
CAPTULO II
SCCP provee el direccionamiento completo para enrutar un mensaje a la base de datos

correcta. El SCCP permite enrutar mensajes de forma transparente a travs de la red, usando
nodos intermedios como enrutadores, sin necesidad de conocer las direcciones individuales de
cada uno de los nodos intermedios.
SCCP hace posible usar el sistema de sealizacin por canal comn N 7, basado sobre
MTP, como un portador entre las aplicaciones que usa el sistema OSI en los niveles
superiores.
Por otro lado, la Parte de Aplicacin de Capacidades de Transacciones, TCAP
(Transaction Capabilities Application Part), es utilizada por las bases de datos para las
transacciones. Se requiere de la SCCP para enrutar mensajes a su propia base de datos.
La Parte de Usuario ISDN, ISUP (ISDN User Part), es un protocolo utilizado para la
conexin telefnica entre centrales.
Este protocolo ofrece adems funciones de redes
inteligentes y servicios de ISDN.
2.3 Telefona IP.

Las redes desarrolladas a lo largo de los aos para la transmisin de conversaciones
vocales, se basan en el concepto de conmutacin de circuitos, es decir, en el establecimiento
de un circuito fsico durante el tiempo de llamada, lo que significa que los recursos que
intervienen en la realizacin de sta, no pueden ser utilizados en otra llamada hasta que la
primera no finalice, incluso durante los silencios que se suceden dentro de una conversacin
tpica.
Lo que se tiene hasta hoy es una red de acceso, que incluye el cableado desde el hogar
del abonado hasta las centrales locales y el equipamiento necesario, y una red de transporte,
que incluye las centrales de rango superior y los enlaces de comunicaciones que las unen.
31
CAPTULO II
Por otro lado, se tienen las redes de datos, basadas en el concepto de conmutacin de
paquetes, es decir, una misma comunicacin sigue diferentes caminos entre origen y destino
mientras dura, lo que significa que los recursos que intervienen en una conexin pueden ser
utilizados por otras conexiones que se efecten al mismo tiempo.
La telefona IP conjuga dos mundos histricamente separados: la transmisin de voz y
de datos. Se trata de transportar la voz, previamente convertida a datos, entre dos puntos
distantes.
En la telefona IP el cambio fundamental se produce en la red de transporte: ahora esta
tarea es llevada a cabo por una red basada en el protocolo IP, de conmutacin de paquetes, por
ejemplo Internet. En cuanto a la red de acceso, puede ser la misma que en el caso de la
telefona convencional, fsicamente hablando (bucle de abonado).
La telefona IP hace uso de tecnologa que digitaliza la voz y la comprime en paquetes
de datos que se reconvierten de nuevo en voz en el punto de destino. Algunas formas de
acceder a este servicio son:
Comunicacin entre usuarios de computadoras conectados a Internet. Mediante el uso de los
componentes multimedia de una computadora y un programa adecuado, se puede entablar una
conversacin en tiempo real con otra computadora similar ubicada en cualquier parte del
planeta.
Comunicacin entre dos usuarios, aunque uno de ellos no est conectado a Internet. Esto es,
una persona conectada a Internet a travs de su computadora puede llamar a un telfono fijo.
Comunicacin entre dos telfonos fijos. Dos telfonos fijos pueden comunicarse entre s por
medio del protocolo IP; uno de ellos llama a una central conectada a Internet y sta lo
comunica con el otro telfono fijo.
32
CAPTULO II
Estas modalidades posibilitan el uso de las redes de datos para efectuar llamadas
telefnicas, y dan paso al desarrollo de una nica red que se encargue de efectuar todo tipo de
comunicacin, ya sea vocal o de datos.
2.3.1 VoIP.
Voz sobre IP, VoIP (Voice over IP), es un trmino usado para hacer referencia a la
tecnologa que hace posible aprovechar la infraestructura de transmisin de datos existente,
para el envo de voz utilizando el protocolo IP, involucrando adems conceptos de telefona,
de redes y de ingeniera de trfico. Esto es, en general, enviar voz en forma digital por medio
de paquetes a travs de la red, en lugar de enviarla en forma analgica a travs de circuitos
conmutados como lo hace una compaa de telefona convencional o PSTN.
La voz sobre redes IP (VoIP), inicialmente se implement para reducir el ancho de
banda mediante compresin vocal, aprovechando los procesos de compresin diseados para
sistemas celulares en la dcada de los aos 80. En consecuencia, se logr reducir los costos en
el transporte internacional. Luego tuvo aplicaciones en la red de servicios integrados sobre la
LAN e Internet. Posteriormente, se migr de la LAN (aplicaciones privadas) a la WAN
(aplicaciones pblicas) con la denominacin Telefona IP (IP-Telephony).
An cuando existen caractersticas que hacen de la Telefona IP un problema de
complejidad elevado respecto de la VoIP, dado que se ocupa de aspectos adicionales como: la
interoperatividad con las redes telefnicas actuales, calidad de servicio garantizada y servicios
de valor agregado, en adelante se har uso del trmino VoIP para hacer referencia a telefona
IP en general.
2.3.1.1 Funciones de un Sistema VoIP.
Un sistema VoIP debe realizar tres funciones bsicas: digitalizacin de la voz,

paquetizacin de la voz y enrutamiento de los paquetes.
33
CAPTULO II
2.3.1.1.1 Digitalizacin de la voz.
Comprende las funciones de conversin analgica-digital de la voz y de compresin de

la seal digital obtenida.
La conversin analgica-digital consta de varios procesos:
Muestreo. Es el proceso a travs del cual se convierte una seal de tiempo continuo
en una seal de tiempo discreto. Su principio se basa en la obtencin de muestras de la seal
de tiempo continuo en instantes de tiempo discreto. La figura 2.13 ilustra el proceso de
muestreo.
Figura 2.13 Ejemplo de muestreo de una seal de audio.

Los puntos sobre lnea de la grfica de la derecha, representan los valores de la seal analgica original que
fueron capturados en instantes de tiempo discretos, durante el proceso de muestreo.
La razn de muestreo o frecuencia de muestreo de una seal en un segundo, determina

el rango de frecuencias o ancho de banda de un sistema. A mayores razones de muestreo,
habr ms calidad o precisin y mayor ser el ancho de banda. La figura 2.14 ilustra la
relacin entre la calidad de la seal muestreada con respecto a la original, y el nmero de bits a
los cuales se muestre sta ltima.
34
CAPTULO II
Figura 2.14 Comparacin entre muestreo a 8 bits y 16 bits.

La figura evidencia el hecho de que si se realiza el muestreo a ms bits, la seal es ms cercana a la original.
La razn de muestreo debe ser al menos el doble de la frecuencia de la seal a

muestrear, de modo que al realizar el proceso contrario, conversin digital-analgica, la seal
sea muy parecida a la original. Esto es lo que propone el Teorema de Nyquist.
Cuantizacin. Es el proceso que convierte una seal de tiempo discreto con valores
continuos en una seal de tiempo discreto con valores discretos: seal digital. El valor de cada
muestra de la seal se presenta mediante un valor seleccionado de un conjunto finito de
valores posibles.
Mientras que el muestreo representa el tiempo de captura de una seal, la
cuantizacin es el componente amplitud del muestreo.
Para hacer esto, la amplitud de la seal de audio es representada en una serie de
pasos discretos. Cada paso est dado por un nmero en cdigo binario que digitalmente
codifica el nivel de la seal. La longitud de la palabra determina la calidad de la
representacin. Una vez ms, una palabra ms larga indica mejor calidad de un sistema de
audio. La figura 2.15 ilustra el proceso de cuantizacin.
35
CAPTULO II
Figura 2.15 Ejemplo de cuantizacin de una seal de audio.

Los rectngulos sobre la grfica, representan los valores discretos de la seal analgica original, es decir, las
amplitudes discretas de la seal muestreada.
Codificacin. Es la representacin numrica de la cuantizacin utilizando cdigos ya

establecidos y estndares.
En la tabla 2.1 se representan los nmeros del 0 al 7 con su respectivo cdigo binario.
Tabla 2.1 Cdigo binario de los nmeros del 0 al 7.

El cdigo ms utilizado para la representacin numrica de la cuantizacin es el cdigo binario, no obstante,
no es el nico.
Se observa en la tabla, con 3 bits, que se pueden representar ocho estados o niveles de
cuantizacin, N = 8.
36
CAPTULO II
La ecuacin 1, muestra la forma general de obtener el nmero de niveles de

cuantizacin, para un nmero de bits n:
N = 2n
Ecuacin 1. Nmero de Niveles de Cuantizacin.
n es el nmero de bits de las muestras.
En la figura 2.16 se muestra una seal de audio codificada, usando cdigo binario con
8 niveles de cuantizacin.
Figura 2.16 Ejemplo de codificacin de una seal de audio.

Los nmeros en los rectngulos son los valores discretos que se obtuvieron del proceso de cuantizacin.
Debajo de la grfica estn estos valores representados en cdigo binario.
Aunque se ha modelado la conversin anloga a digital en varias etapas, en la prctica

la conversin se hace en un nico paso, tpicamente a travs de una tarjeta con un conversor
integrado.
La compresin de la seal, por su parte, es una tcnica comn que se emplea para
reducir la tasa de datos de seales de audio, haciendo que los niveles de cuantizacin sean
desiguales. Esta reduccin de la tasa de datos se traduce en un decremento proporcional del
costo de la transmisin de la seal.
37
CAPTULO II
El sonido ms alto que puede ser tolerado por el odo humano (120 dB SPL, Sound
Power Level) es aproximadamente un milln de veces la amplitud del sonido ms bajo que
puede ser detectado (0 dB SPL). Sin embargo, el odo no es capaz de distinguir entre sonidos
que estn cercanos a 1dB (que representa el 12% en amplitud) en los sonidos ms bajos. En
otras palabras, existen solamente alrededor de 120 diferentes niveles de sonidos altos que
pueden ser detectados, espaciados logartmicamente sobre un rango de amplitud de un milln.
Este hecho es relevante para la digitalizacin de seales de audio. Si los niveles de
cuantizacin estn igualmente espaciados, deben usarse 12 bits para obtener una calidad de
voz telefnica. Sin embargo, slo 8 bits son requeridos si los niveles de cuantizacin son
desiguales, haciendo juego con las caractersticas de odo humano. Esto es bien intuitivo: si la
seal es pequea, los niveles necesitan estar muy cercanos entre ellos; si la seal es grande,
deben estar ms espaciadas entre s.
Los formatos estndares de compresin, son conocidos como algoritmos de
compresin. Entre los algoritmos de compresin ms conocidos se encuentran:
PCM (Pulse Code Modulation) Standard ITU-T G.711. La Modulacin por Pulsos
Codificados, es un mtodo para la modulacin en la que las seales son muestreadas y
convertidas en palabras digitales que son transmitidas en serie. La mayora de los sistemas
PCM utilizan cdigos binarios de 7 u 8 bits, requiriendo de 64 kbps.
Para la compresin de curvas son usados tpicamente, dos estndares muy parecidos
para la codificacin PCM: Ley 255, tambin llamada Ley , usada en Norte Amrica; y Ley
A usada en Europa. Ambos, usan el esquema no-lineal logartmico puesto que ste convierte
los espacios detectables por el odo humano en espacios lineales. Las ecuaciones 2 y 3
muestran las expresiones de las curvas usadas en la Ley y Ley A.
38
CAPTULO II
Ecuacin 2. Compresin con Ley .

La constante tiene un valor de 255, definido por AT&T. x es le seal de entrada.
Ecuacin 3. Compresin con Ley A.

La constante A tiene un valor de 87,6, definido por la CCITT. x es le seal de entrada.
En la figura 2.17, han sido graficadas las ecuaciones 2 y 3 para la variable de entrada x,
con valores entre -1 y +1, y la salida entre este mismo rango de valores. Las ecuaciones 2 y 3
slo aceptan valores de entrada positivos. La porcin negativa de la curva se encontr por
simetra.
Figura 2.17 Curvas de Compresin: Ley y Ley A.

Las curvas de compresin correspondientes a las Leyes y A, son casi idnticas. Ellas slo difieren cerca del
origen. La compresin incrementa la amplitud de la seal cuando sta es pequea, y la reduce cuando es grande.
ADPCM (Adaptive differential PCM) Standard ITU-T G.726. La Modulacin por

Pulsos Codificados Diferencial Adaptativa es una tcnica de compresin, que slo convierte la
39
CAPTULO II
diferencia entre el paquete de voz actual y el previo, requiriendo de 32 kbps, reduciendo as el

ancho de banda necesitado para transportarlo a travs de enlaces de baja velocidad.
Delta. Se trata de una forma especial de codificacin DPCM. No tiene aplicaciones
extendidas. La velocidad de muestreo es 64 kb/s y la codificacin es 1 bit por muestra.
CODEC de Prediccin Lineal, LPC (Linear Predictive CODEC). Se basa en una
estimacin lineal de la fuente. Se codifican un grupo de muestras; por ejemplo 160 muestras
en 20 mseg. Se aplican en sistemas celulares para alta compresin de la informacin vocal
(menos de 10 kb/s).
2.3.1.1.2 Paquetizacin y Enrutamiento de los paquetes de voz.
Una vez digitalizada la seal de audio analgica, se procede a efectuar las funciones
de paquetizacin de la seal digital obtenida y enrutamiento de dichos paquetes, esto es,
insertar los paquetes de voz en los paquetes de datos siguiendo los formatos o protocolos
existentes. En esta tarea se usa, tpicamente, el protocolo RTP sobre UDP sobre IP.
Se requiere tambin de un protocolo de sealizacin para la comunicacin con los
usuarios. Los protocolos de sealizacin ms comunes son: ITU-T H.323 y el RFC 3261 SIP,
los cuales sern detallados en la seccin 2.3.6.
En el otro extremo de la comunicacin, despus de la recepcin de los paquetes de
voz, stos deben ser desensamblados y extraer los datos que luego sern sometidos al proceso
de conversin digital-analgica y enviar la seal de audio analgica obtenida a la tarjeta de
audio o telfono.
Todos estos procesos mencionados anteriormente, deben llevarse a cabo en tiempo
real, debido a que no puede esperarse tanto tiempo para recibir una respuesta vocal al otro lado
del telfono.
40
CAPTULO II
2.3.1.1.3 Otras funciones.
Un sistema VoIP ejecuta otras funciones adicionales, entre las que se pueden
mencionar:
Conversin de nmeros telefnicos a direcciones IP y viceversa.
Generacin de la sealizacin requerida por la red telefnica.
Control de admisin, tarificacin y facturacin.
Manejo de Fax.
2.3.2 Caractersticas.
Tolerante a Errores y prdida de paquetes.
Como se mencion anteriormente, VoIP se refiere al transporte de trfico de voz
utilizando el protocolo IP.
El protocolo IP no provee garantas por s mismo, al contrario, presenta problemas
como: paquetes viajando por diferentes rutas, atraso, prdida, entrega fuera de secuencia, etc.
Otros protocolos lo complementan: TCP, por ejemplo, suministra entrega confiable, en
secuencia, etc.
Sin embargo, TCP es un protocolo diseado para transporte de datos, no para
transporte de voz. Los datos no son tolerantes a errores. La voz, por su parte, es ms tolerante
a errores o prdida de paquetes, ya que cada paquete maneja, solamente, entre 10 y 40
milisegundos de conversacin.
Al contrario de TCP, UDP no contiene informacin para hacer retransmisin de
paquetes perdidos, ni prcticamente ninguna otra cosa. Sin embargo, permite la entrega de
paquetes fuera de secuencia, y si se pierden paquetes no hay forma de saberlo. Es por esta
41
CAPTULO II
razn que se usa RTP sobre UDP, ya que RTP incluye campos como el nmero de secuencia,
para que la aplicacin pueda detectar prdida de paquetes o su llegada fuera de orden.
Requerimientos de orden y tiempo.
A diferencia de los datos, la voz no es tolerante a retrasos, debido a que causa
frustracin a los usuarios. Los retardos de cientos de milisegundos, comunes en redes de datos,
son inaceptables en una conversacin telefnica.
Por su parte, el orden en la recepcin de los paquetes adquiere tambin una gran
relevancia. Las redes IP estn diseadas para descartar paquetes en caso de congestin y
retransmitirlos en caso de error. Esto no es adecuado para la voz.
Requerimiento de algoritmos de compresin.
La tasa de datos es un factor de gran importancia en el rea de las telecomunicaciones.
Esto se debe a que ella es directamente proporcional al costo de la transmisin de la seal. La
disminucin del nmero de bits se traduce entonces en la disminucin del presupuesto a
invertir. La compresin es una tcnica comn que se emplea para reducir la tasa de datos de
seales de audio.
2.3.3 Ventajas sobre la telefona tradicional.

Convergencia de las comunicaciones de datos y voz en una plataforma nica.
Desde hace tiempo, los responsables de comunicaciones de las empresas tienen en
mente la posibilidad de utilizar su infraestructura de datos, para el transporte del trfico de voz
interno de la empresa. No obstante, es la aparicin de nuevos estndares, as como la mejora y
abaratamiento de las tecnologas de compresin de voz, lo que est provocando finalmente su
implantacin.
42
CAPTULO II
Esta convergencia facilita la gestin y el mantenimiento de la plataforma nica, as

como tambin, el entrenamiento del personal que se ocupar de ella.
Reduccin de los costos de operacin.
Despus de haber constatado que, desde una computadora con elementos multimedia
es posible realizar llamadas telefnicas a travs de Internet, se puede pensar en una posible
reduccin de gastos, debido al empleo de los recursos ya existentes para la introduccin de
esta tecnologa.
Por su parte, las soluciones VOIP propuestas en el mercado, proporcionan el potencial
para ahorrar 50-80% en costos de larga distancia en aplicaciones punto a punto. Los negocios
con oficinas remotas alrededor del mundo o solo a un cdigo de rea diferente a cientos de
kilmetros de distancia, pueden beneficiarse de una solucin de VOIP. Por ejemplo, un
negocio con una oficina central en determinada ciudad, y algunas oficinas remotas en otra
ciudad e incluso otro pas, puede rpidamente obtener sustanciales ahorros en cargos de larga
distancia.
El abaratamiento de los DSPs, los cuales son claves en la compresin y
descompresin de la voz, es otro elemento que contribuye a la disminucin de costos de
implementacin de los sistemas VoIP. Estos DSPs son claves tambin para el ahorro de
ancho de banda y aprovechamiento de los intervalos entre rfagas de datos haciendo un uso
ms efectivo de los canales de comunicacin.
Integracin de Voz y Datos da paso a nuevos servicios.
El hecho de que en los sistemas VoIP los recursos no estn dedicados al origen y
destino de la comunicacin, como sucede en la telefona tradicional, el costo de las llamadas
depende ms del mercado que del tiempo de conexin. De esta forma, donde antes se
estableca una sola conversacin, ahora puede entablarse ms de una. Este hecho incrementa
43
CAPTULO II
el inters por la implementacin de nuevos servicios que exploten esta tecnologa: transmisin
de fax, voz, vdeo, correo electrnico por telfono, mensajera y comercio electrnico.
2.3.4 Retos de la telefona IP: Calidad de Servicio (QoS).

Las redes IP fueron diseadas para el transporte ptimo del trfico de datos, por lo que
la Calidad de Servicio (QoS) requerida en las mismas se bas nicamente en la integridad de
los datos, esto es, no prdida de contenido ni de la secuencialidad de los mismos.
En este sentido, IP fue concebido para mover por la red, de forma ptima y segura,
trfico sin requerimientos de tiempo real. Para esto el servicio que brinda IPv4 es del tipo
Best-Effort.
Por otra parte, el trfico de audio y vdeo no solo requiere ser transferido por las redes
IP de forma ntegra, sino que adems requiere ser transferido en el tiempo adecuado, en
correspondencia con la cadencia que es generado. En consecuencia, la calidad de servicio en
relacin con el trfico que tiene requerimientos de tiempo real necesita considerar otros
parmetros de calidad, tales como la latencia (retardo y variacin de retardo) y el ancho de
banda.
Dados estos requerimientos de calidad de servicio impuestos por el trfico con
caractersticas de tiempo real, como es audio y el vdeo, se necesitan mecanismos de
sealizacin que propicien tener bajo control dichos parmetros de calidad, y dar garanta de
calidad de servicio.
Los parmetros ms influyentes en el comportamiento de una transmisin de voz, que
deben considerarse, se describen a continuacin.
44
CAPTULO II
Latencia (Delay).
Se define as a los vacos o silencios en la conversacin debido a los retardos
acumulados. El primer retardo es el producido por el proceso de almacenamiento y reenvo de
los paquetes de voz y el de procesamiento de los mismos (cambio de encabezado de paquetes,
por ejemplo). A esto se suman los retardos propios del proceso de compresin vocal
(insignificante en codificacin G.711 y ms elevado en aplicaciones con G.729).
El retraso es un aspecto crucial en las conversaciones pues causa frustracin en los
usuarios. Actualmente, slo a travs del control y gestin global extremo a extremo, y la
disponibilidad de suficiente ancho de banda, as como la tecnologa de conmutacin y
enrutamiento necesaria, es posible asegurar unos niveles de retardo mximos.
Variacin del retraso (Jitter).
Es el efecto por el cual el retardo entre paquetes no es constante. Se trata de una
latencia variable producida por la congestin de trfico. Este parmetro tiene los mismos
problemas y dificultades que el retardo, por lo que las soluciones van en la misma lnea. Si
cabe, en este caso son ms importantes las tecnologas de enrutamiento de los paquetes IP.
Prdida de paquetes (Packet Loss).
Es la tasa de prdida de paquetes. Representa el porcentaje de paquetes transmitidos
que se descartan en la red. Estos descartes pueden ser producto de una alta tasa de error en
alguno de los medios de enlace o, por sobrepasarse la capacidad de memoria de algn arreglo
de datos de una interfaz en momento de congestin. Los paquetes perdidos son retransmitidos
en aplicaciones que no son de tiempo real; en cambio para telefona, no pueden ser
recuperados y se produce una distorsin vocal.
Sera muy fcil dar Calidad de Servicio si las redes nunca se congestionaran. Para ello,
habra que sobredimensionar todos los enlaces, cosa no siempre posible o deseable. Si se desea
45
CAPTULO II
ofrecer calidad de servicio con congestin, es preciso tener mecanismos y polticas que
permitan dar un trato distinto al trfico preferente, entre los que se mencionan:
1.- Campo TOS (Type of Service), Tipo de Servicio, en el protocolo IP, para describir el tipo
del servicio: los valores altos indican urgencia baja, mientras que los valores ms bajos nos
traen cada vez ms urgencia de tiempo real.
2.- Mtodos para encolar paquetes:
a.- FIFO (First In First Out): permite el paso de los paquetes por orden de llegada, el
primero que entra es el primero que sale.
b.- WFQ: permite el paso justo de paquetes, dependiendo de la clase de datos que
fluye, tpicamente un paquete para UDP y para uno para TCP.
c.- CQ (Custom Queuing): permite que los usuarios puedan decidir la prioridad.
d.- PQ (Priority Queuing): hay un nmero de lneas (tpicamente 4), con un nivel de
prioridad cada uno: primero, se envan los paquetes de la primera lnea, luego cuando la
primera lnea est vaca, se envan los de la segunda y as sucesivamente.
Se dice que una red o un proveedor ofrece calidad de servicio, cuando se garantiza el
valor de uno o varios de los parmetros que definen la calidad de servicio que ofrece la red. Si
el proveedor no se compromete en ningn parmetro, entonces lo que se ofrece es un servicio
Best-Effort.
El contrato que especifica los parmetros de calidad de servicio acordados entre el
proveedor y el usuario (cliente) se denomina SLA (Service Level Agreement). En la tabla 2.2
se ilustran ejemplos de los parmetros tpicos acordados en los SLAs.
46
CAPTULO II
Tabla 2.2 Parmetros tpicos de los SLAs.

La calidad de servicio debe garantizar el valor de los parmetros acordados en el SLA. Se presentan valores
de ejemplo tpico.
2.3.5 Topologa de una red VoIP.

Los elementos necesarios para que se puedan realizar llamadas vocales a travs de una
red IP dependen, en gran medida, de qu terminales se utilizan en ambos extremos de la
conversacin. Estos pueden ser terminales IP (telfono IP, ordenador multimedia, fax IP, etc.)
o no IP (telfonos o faxes convencionales).
Los primeros son capaces de entregar a su salida la conversacin telefnica en formato
de paquetes IP, adems de ser parte de la propia red IP, mientras que los segundos no, por lo
que necesitan de un dispositivo intermedio que haga este trabajo antes de conectarlos a la red
IP de transporte.
Actualmente se cuenta con una serie de elementos disponibles en el mercado, que de
acuerdo a los recursos disponibles y necesidades requeridas, permiten construir aplicaciones
VoIP a la medida. La figura 2.18 es un esquema general que ofrece una idea de todas las
conjugaciones posibles de dichos elementos en el diseo de un sistema VoIP.
47
CAPTULO II
Figura 2.18 Elementos de una red VoIP.

Este esquema muestra un sistema VoIP que comprende equipos terminales IP y no IP, interfaces con la red
de telefona convencional, enrutadores, entre otros elementos.
A partir de la figura 2.18 pueden deducirse, de forma intuitiva, las funciones de los
distintos elementos mostrados. A continuacin se detallarn brevemente.
2.3.5.1 PSTN.
PSTN es el acrnimo de Public Switched Telephone Network o Red Pblica de
Telefona Conmutada, que hace mencin a la red telefnica tradicional, la cual emplea la
tecnologa de conmutacin de circuitos para transmitir las llamadas.
En esta red estn conectados todos los telfonos analgicos. sta tiene a su cargo las
funciones de sealizacin de lnea, de registro y de informacin de llamada inherentes a la
telefona convencional, que permiten el establecimiento de comunicaciones de voz en las
reas locales.
48
CAPTULO II
2.3.5.2 Pasarelas PSTN/IP (Gateway).
Las pasarelas PSTN/IP o gateways, son los encargados de conectar dos redes dismiles
y de realizar la traduccin de la sealizacin, de las codificaciones de audio y vdeo y de los
protocolos de transmisin entre las diferentes redes.
Realizan la emulacin de interfaz FXO/FXS, lo que permite adaptar una central
analgica PABX a la VoIP. Se conecta a la PABX convencional por un lado y a la red de
transporte IP por el otro, lo que permite conectar un usuario convencional a la red de
Telefona-IP pblica. Permite la traslacin de direcciones desde IP a la ITU E.164 (Plan de
numeracin internacional de telecomunicaciones) de la red telefnica convencional. Es decir,
acta de interfaz desde la red IP (direccin de 4 bytes) hacia la PSTN (direccin de 16 dgitos
decimales).
Los gateways de VoIP proveen un acceso ininterrumpido a la red IP. Las llamadas de
voz se digitalizan, codifican, comprimen y paquetizan en un gateway de origen y luego, se
descomprimen, decodifican y rearman en el gateway de destino. Los gateways se
interconectan con la PSTN segn corresponda, a fin de asegurar que la solucin sea ubicua.
El procesamiento que realiza el gateway de la cadena de audio que atraviesa una red IP
es transparente para los usuarios. Desde el punto de vista de la persona que llama, la
experiencia es muy parecida a utilizar una tarjeta de llamada telefnica. La persona que realiza
la llamada ingresa a un gateway por medio de un telfono convencional discando un nmero
de acceso. Una vez que fue autenticada, la persona disca el nmero deseado y oye los tonos de
llamada habituales hasta que alguien responde del otro lado. Tanto quien llama como quien
responde se sienten como en una llamada telefnica "tpica".
2.3.5.3 Porteros (Gatekeepers).

Los porteros o Gatekeepers (GK), son las entidades que proveen los servicios de
directorio, autorizacin e identificacin de terminales y gateways, control de admisin para
49
CAPTULO II
autorizar el acceso a la red mediante mensajes, manejo de ancho de banda, conversin de

direcciones, control de llamadas, tarificacin, etc. Aunque los GK son opcionales, resultan ser
esenciales para los sistemas de gran escala.
Los GK utilizan la interfaz estndar de la industria ODBC-32 (Open Data Base
Connectivity Conectividad abierta de bases de datos) para acceder a los servidores de
backend (servidores de trabajo medular internos) en el centro de cmputos del carrier
(proveedor de servicios) y as autenticar a las personas que llaman como abonados vlidos al
servicio, optimizar la seleccin del gateway de destino y sus alternativas, hacer un
seguimiento y una actualizacin de los registros de llamadas y la informacin de facturacin, y
guardar detalles del plan de facturacin de la persona que efecta la llamada.
Pueden existir varios GK por razones de redundancia y compartir la carga en la red. El
principal parmetro del GK es la cantidad de llamadas cursadas en las horas pico. Dicho
parmetros se conoce como BHCA (Busy Hour Call Attempts).
2.3.5.4 Concentradores Telefnicos (HUBs).
La arquitectura de red hub est preparada para los crecimientos inesperados y los
cambios producidos en la red, de una forma ms sencilla que las redes punto a punto.
Los hubs telefnicos concentran el trfico en un punto central y distribuye las seales a
varios circuitos.
2.3.5.5 Telfonos IP.
Un telfono IP, es un telfono que permite realizar llamadas telefnicas utilizando
Internet o cualquier red IP.
50
CAPTULO II
Los telfonos IP usan los servicios proporcionados por su Proveedor de Servicios de

Internet, ISP (Internet Service Provider), sin necesidad de ordenador, sin cambiar de nmero
de telfono y con capacidad de comunicacin simultnea de voz y datos.
Un telfono IP consta, bsicamente, de cuatro bloques principales: CODEC, Circuito
Interfaz para Voz, Unidad de Control e Interfaz de Red. La figura 2.19 muestra un diagrama
en bloques general de un telfono IP.
Figura 2.19 Diagrama en Bloques General de un Telfono IP.

Este esquema muestra las principales etapas para el diseo de un Telfono IP estndar o sencillo: CODEC,
Circuito Interfaz para Voz, Unidad de Control e Interfaz de Red.
El audio que es capturado por el micrfono pasa al CODEC, el cual lleva a cabo el
procesamiento de la voz (digitalizacin y compresin de la voz). Comnmente, se emplean
CODECs del tipo PCM Ley A o Ley .
El circuito interfaz para voz lleva a cabo funciones de cancelacin de eco, deteccin
de DTMF, deteccin de mltiples tonos, amplificacin de entrada y salida de voz y generacin
de tonos, entre otras.
La unidad de control, por su parte, es la encargada de coordinar las funciones de
recepcin y transmisin de los datos digitales de voz provenientes, tanto de la red o de la
interfaz USB, como de la etapa de procesamiento de la voz. Tambin recibe y procesa los
51
CAPTULO II
datos provenientes del teclado, as como tambin genera la sealizacin y visualizacin

necesaria para el usuario a travs, por ejemplo, de una pantalla de cristal lquido.
La interfaz USB permite la interaccin de la unidad de control con la computadora, en
el caso en que las funciones de red (empaquetamiento y enrutamiento de paquetes) vayan a ser
manejadas por sta. En caso contrario, es la interfaz de red la que har este trabajo.
2.3.6 Protocolos utilizados en telefona IP.

Al igual que en la telefona tradicional, en el mundo de la telefona IP existen
protocolos que tienen la funcin de proveer informacin relacionada con las etapas de una
llamada. Adicionalmente, se utilizan otros protocolos para el control del flujo de los paquetes
de voz, con el fin de asegurar calidad de servicio.
2.3.6.1 H.323.
El H.323 es la primera especificacin completa bajo la cual, los productos

desarrollados se pueden usar con el protocolo de transmisin ms ampliamente difundido (IP).
Se conforma de una familia de estndares definidos por el ITU para las comunicaciones
multimedia sobre redes LAN. Est definido especficamente para tecnologas LAN que no
garantizan una calidad de servicio (QoS).
El H.323 fue el primer estndar en definir los siguientes componentes:
Terminales: equipo final que transmite o recibe el flujo de datos.
Gateway: equipo que permite la interconexin de redes de distinta naturaleza.
GateKeeper (GK): equipo de control que vela por el funcionamiento de la red.
Unidad de Control Multipunto MCU (MultiPoint Control Unit): equipo central empleado
para el establecimiento de multiconferencias.
52
CAPTULO II
El H.323 soporta vdeo en tiempo real, audio y datos sobre redes de rea local,
metropolitana, regional o de rea extensa. Soporta as mismo Internet e intranets y
adicionalmente, soporta videoconferencia sobre conexiones punto a punto, telefnicas y
ISDN, para lo cual se debe disponer de un protocolo de transporte de paquetes.
Debido a que el estndar H.323 del ITU-T, cubra la mayor parte de las necesidades
para la integracin de la voz, se decidi que ste fuera la base del VoIP. VoIP tiene como
principal objetivo asegurar la interoperabilidad entre equipos de diferentes fabricantes, fijando
aspectos tales como la supresin de silencios, codificacin de la voz y direccionamiento, y
estableciendo nuevos elementos para permitir la conectividad con la infraestructura telefnica
tradicional.
VoIP sobre H.323 comprende, a su vez una serie de estndares y se apoya en una serie
de protocolos que cubren los distintos aspectos de la comunicacin:
Direccionamiento.
RAS (Registration, Admission and Status). Registro, Admisin y Estado. Protocolo de
comunicaciones que permite a una estacin H.323 localizar otra estacin H.323 a travs del
Gatekeeper.
DNS (Domain Name Service). Nombre de Servidor de Dominio. Servicio de
resolucin de nombres en direcciones IP con el mismo fin que el protocolo RAS pero a travs
de un servidor DNS.
Sealizacin.
Q.931: Sealizacin inicial de llamada.
H.225: Control de llamada: sealizacin, registro y admisin, paquetizacin y
sincronizacin del flujo (stream) de voz.
53
CAPTULO II
H.245: Protocolo de control para especificar mensajes de apertura y cierre de canales

para flujos de voz.
Compresin de voz.
Requeridos: G.711 y G.723.
Opcionales: G.728, G.729 y G.722.
Transmisin de voz.
UDP. La transmisin se realiza sobre paquetes UDP, pues aunque UDP no ofrece
integridad en los datos, el aprovechamiento del ancho de banda es mayor que con TCP.
RTP (Real Time Protocol). Maneja los aspectos relativos a la temporizacin, marcando
los paquetes UDP con la informacin necesaria para la correcta entrega de los mismos en
recepcin.
Control de la transmisin.
RTCP. Se utiliza principalmente para detectar situaciones de congestin de la red y
tomar, en su caso, acciones correctoras.
La figura 2.20 muestra, en general, como se modifican las capas superiores del modelo
OSI con el uso de VoIP sobre H.323.
54
CAPTULO II
Figura 2.20 Estructura General de las capas usando VoIP sobre H.323.
2.3.6.2 MEGACO.
Debido a que es necesario asegurar el acceso de todos los usuarios a los servicios de
telefona, las redes de nueva generacin deben coexistir con la red telefnica tradicional. Por
esta razn, se requiere de equipos con funciones de pasarela que se encarguen de la traduccin
entre los formatos de los datos usados en los dos tipos de redes, de forma que sea garantizada
tambin la interoperabilidad entre los mecanismos de sealizacin de ambas.
Para este nuevo modelo de red, las pasarelas se dividen en tres entidades lgicas
independientes:
Pasarela fsica (MG, Media Gateway): proporciona una interfaz bidireccional entre redes de
distinta naturaleza.
Controlador de pasarela (MGC, Media Gateway Controller): se encarga de realizar el control
de la pasarela fsica. Maneja la sealizacin para canalizar la provisin de servicios y realiza
funciones de procesamiento y control de llamadas.
Pasarela de sealizacin (SG, Signalling Gateway): proporciona una interfaz bidireccional
para la sealizacin entre las redes SS7 y los elementos de control de las redes de paquetes.
Con este nuevo esquema, se logra separar la inteligencia y funciones de control de las
funciones de transporte dentro de la red. Adicionalmente, es necesario el establecimiento de
55
CAPTULO II
protocolos estandarizados que hagan posible la comunicacin entre estas tres entidades
lgicas. El protocolo de control de pasarela fsica MEGACO/H.248 (Media GAteway Control
protocol) es uno de ellos.
MEGACO especifica los procedimientos que se deben seguir para llevar a cabo la
comunicacin entre la pasarela fsica y su controlador. Se basa en una arquitectura de control
de llamadas en la que la inteligencia se separa de la pasarela fsica MG, y es manejada por un
elemento de control externo, el controlador de pasarela MGC que se responsabiliza por toda
la operacin de la red, incluyendo la iniciacin de llamadas.
MEGACO/H.248 es un protocolo de arquitectura maestro/esclavo que maneja
comandos basados en texto para establecer y controlar los dispositivos que intercambian los
flujos de informacin. Es compatible con H.323 y SIP y presenta funcionalidades
complementarias, de forma que, se puede realizar el control de la red y la provisin de algunos
servicios bsicos.
2.3.6.3 SIP.
El Protocolo de Inicio de Sesin SIP (Session Initiation Protocol) es un protocolo

basado en texto, diseado para la iniciacin, mantenimiento y desconexin de sesiones de
comunicacin interactivas entre usuarios. Tales sesiones pueden incluir voz, video, chat,
juegos interactivos y realidad virtual.
SIP es similar al Protocolo de Transferencia de Hipertexto HTTP (Hypertext Transfer
Protocol) de quien toma parte de la sintaxis y semntica, mecanismos de autenticacin, etc.
Tambin es similar al Protocolo Simple de Transferencia de Correo SMTP (Simple Mail
Transfer Protocol) del cual toma mecanismos de enrutamiento y modo de direccionamiento.
56
CAPTULO II
SIP define y usa los siguientes componentes [4]:

Agente Usuario Cliente, UAC (User Agent Client). Cliente en el terminal que inicia la
sealizacin SIP.
Agente Usuario Servidor, UAS (User Agent Server). Servidor en el terminal que responde a
la sealizacin SIP del UAC.
Agente Usuario, UA (User Agent). Terminal de red SIP (telfonos SIP, gateways de otras
redes, Softphones, Gateway PSTN, servidor de conferencias, servidor de correo de voz,
Respuesta Vocal Interactiva (IVR, Interactive Voice Response), discador, etc.) que contiene al
UAC y al UAS.
Servidor Proxy (Servidor delegado). Recibe las solicitudes de conexin desde el UA y las
transfiere a otro servidor Proxy si una determinada estacin no est bajo su administracin.
Servidor de Redireccin (Redirect Server). Recibe solicitudes de conexin y las enva de
vuelta al solicitante incluyendo datos de destino en lugar de enviarlas a la persona a quien se
llama. Al contrario de un servidor proxy, el servidor redirect no inicia sus propios mensajes
de SIP, slo responde. Al contrario de un UA, no acepta o termina llamadas.
Servidor de Localizacin (Location Server). Recibe solicitudes de registro del UA y
actualiza la base de datos del terminal con ste. Este servidor es utilizado por un servidor
redirect o servidor Proxy para obtener informacin acerca de las posibles locaciones de un
usuario llamado.
El servidor de localizacin obtiene informacin del servidor de registro (Registrar
Server) o por interfaces de aprovisionamiento de usuarios, es una base de datos y no usa SIP
para comunicarse con los otros servidores.
57
CAPTULO II
Servidor de Registro (Registrar Server). Un servidor que acepta mensajes del tipo
REGISTER. Permite popular al servidor de localizacin de manera dinmica.
Un usuario puede estar registrado con mltiples dispositivos. Un dispositivo puede
tener registrado mltiples usuarios. Cada usuario es responsable de registrar y mantener el
registro en sus diferentes dispositivos.
La divisin entre servidor Proxy, servidor de registro, servidor Redirect y servidor de
localizacin no es fsica, sino conceptual, con lo cual dichas funciones pueden residir en un
nico servidor o estar separadas por motivos de escalabilidad, redundancia o rendimiento.
Los mensajes bsicos enviados en un entorno SIP son: INVITE, ACK, OPTIONS,
BYE, CANCEL y REGISTER. Las respuestas a los mensajes SIP estn en formato digital
similar al protocolo http.
La sencillez de SIP es altamente valorada por desarrolladores de aplicaciones y
dispositivos. sta es una de las razones por las que SIP se perfila como el protocolo ideal para
el desarrollo de nuevos modelos y herramientas de comunicacin, adems de la telefona y
videoconferencia IP.
La figura 2.21 muestra la arquitectura general de una aplicacin SIP.
58
CAPTULO II
Figura 2.21 Arquitectura General de una aplicacin SIP.

Ntese que los agentes usuarios pueden ser telfonos SIP, gateways de otras redes y cualquier otro
dispositivo que soporte SIP.
2.3.6.4 Soporte para Sealizacin #7.
Para visualizar mejor las modificaciones introducidas en la red de sealizacin SS7

para aplicaciones de voz sobre IP, es necesario estudiar la topologa de una red de
sealizacin SS7 convencional, la cual se ilustra en la figura 2.22.
Figura 2.22 Topologa General de una Red de Sealizacin SS7.

Los SSPs distinguen los datos de sealizacin y voz, y los conmuta hacia los enlaces SS7 y troncales,
respectivamente. Los STPs son centrales de trnsito. En los SCPs se controlan los servicios de usuario.
59
CAPTULO II
Lo primero que se observa en la figura 2.22 es la separacin entre los canales de

sealizacin y los canales por donde viaja la voz, es decir, la evidencia de que la sealizacin
SS7 es de tipo canal comn.
Adicionalmente, se observan 3 componentes principales:
Punto de Servicio de Conmutacin, SSP (Service Switching Point): Es el punto donde
confluyen la red de voz y la red de datos. Realiza las funciones de conmutacin de servicios
entre estas dos redes.
Punto de Transferencia de Servicio de Sealizacin, STP (Signal Transfer Point): Es una
central de trnsito. Realiza las funciones de un enrutador en la red SS7. Los STPs conmutan
mensajes provenientes de diferentes SSPs a travs de la red hacia su destino.
Punto de Control de Servicios, SCP (Service Control Point): Es una base de datos remota
dentro de la red SS7. Realiza la traslacin y enrutamiento de los datos necesarios para
entregar servicios avanzados de red inteligente. El SCP se utiliza para almacenar informacin
acerca de los servicios de los suscriptores, enrutamiento de nmeros especiales, validacin de
tarjetas telefnicas y proteccin antifraude.
Sobre estos tres elementos, se encuentra el Sistema de Servicio de Monitoreo SMS
(Service Manager System), el cual lleva a cabo las funciones de control de todos los puntos de
sealizacin de la red SS7.
Por otra parte, debido a que la red VoIP requiere interactuar con la PSTN, est claro
que la red VoIP necesita hablar SS7. Esto es, VoIP no slo debe soportar los mensajes de
sealizacin SS7, sino que adems debe cumplir con los requerimientos de ejecucin
especificados por SS7.
El punto es, que una red de VoIP que usa SS7, debe conocer estrictamente los
requerimientos que estn ya garantizados por la red de conmutacin tradicional. El problema
60
CAPTULO II
radica en cmo asegurar que la red VoIP pueda emular el rendimiento de la red SS7.
Afortunadamente, varios grupos han estado trabajando en este particular.
Las redes VoIP transportan SS7 sobre IP usando protocolos definidos por Sigtran
(Signaling Transport), grupo de trabajo de la Internet Engineering Task Force (IETF),
organizacin internacional responsable de recomendar los estndares de Internet. Estos
protocolos incluyen tres componentes: transporte IP estndar, transporte de sealizacin
comn y un mdulo de adaptacin [5].
El componente de transporte de sealizacin comn, asegura que los mensajes sean
entregados libres de error y en secuencia, independientemente del comportamiento de la red
IP. El mdulo de adaptacin hace posible que sealizacin de tipo no-SS7 sea transportada
sobre el Protocolo de Control de Transmisin de Flujo, SCTP (Stream Control Transmisin
Protocol). SCTP es un protocolo de transporte de sealizacin genrico que permite la
transmisin confiable de otros tipos de trficos de sealizacin.
SCTP opera sobre varios mdulos de adaptacin. Entre estos mdulos se encuentran:
la adaptacin del MTP2 para aplicaciones de usuario (M2UA), la adaptacin del MTP2 para
aplicaciones peer to peer (horizontal entre pares) (M2PA), la adaptacin del MTP3 para
aplicaciones de usuario (M3UA), la adaptacin del SCCP para aplicaciones de usuario (SUA),
la adaptacin del ISDN para aplicaciones de usuario (IUA) y el V5UA como extensin del
IUA.
En la figura 2.23 se ilustra la topologa general de la SS7 para aplicaciones VoIP.
61
CAPTULO II
Figura 2.23 Topologa General de una Red de Sealizacin SS7 para VoIP.
Se introducen elementos que permiten la interaccin entre la red SS7 y la red IP: signaling gateway (pasarela
de sealizacin) y media gateway controller (controlador de pasarela).
2.3.6.5 RSVP.
El Protocolo de Reserva de Recursos RSVP (Resource Reservation Protocol), es un

protocolo sealizacin de QoS, que posibilita:
Dar a las aplicaciones un modo uniforme para solicitar determinado nivel de QoS.
Encontrar una forma de garantizar cierto nivel de QoS.
Proveer autentificacin.
RSVP es un protocolo que se desarrolla entre los usuarios y la red, y entre los
diferentes nodos (routers) de la red que soportan este protocolo. Consiste en hacer reservas
de recursos en dichos nodos para cada flujo de informacin de usuario, con la consecuente
ocupacin de los mismos. Esto requiere, lgicamente, intercambio de mensajes RSVP entre
dichos entes funcionales, as como mantener estados de reserva en cada nodo RSVP. Si no se
pueden asegurar las condiciones pedidas se rechaza la llamada (control de admisin).
De forma que, tanto la solicitud de las reservas como el mantenimiento de stas
durante la comunicacin, y la posterior cancelacin, implica el intercambio de mensajes de
62
CAPTULO II
sealizacin, lo cual representa un trfico considerable cuando de entornos como Internet se

trata.
RSVP ofrece dos tipos de servicios: de carga controlada y garantizado. El servicio de
carga controlada, aunque no est muy bien definido, debe ofrecer una prdida de paquetes
muy baja o nula. El servicio garantizado, se basa en solicitar determinado ancho de banda y
cierta demora de trnsito mxima.
De los dos tipos de servicios que RSVP soporta, el ms adecuado para aplicaciones con
requerimientos de tiempo real es el servicio garantizado, aunque es ms complejo de
implementar.
2.3.6.6 MPLS.
El protocolo de Conmutacin de Etiquetas MPLS (Multiprotocol Label Switching), es

un estndar que surgi para consensuar diferentes soluciones de conmutacin multinivel,
propuestas por distintos fabricantes a mitad de los aos 90. Como concepto, MPLS es a veces
un tanto difcil de explicar. Como protocolo es bastante sencillo, pero las implicaciones que
supone su implementacin real son enormemente complejas.
MPLS se puede presentar como un sustituto de la conocida arquitectura IP sobre ATM
(Asynchronous Transfer Mode, Modo de Transferencia Asncrona).
Las redes ATM sobre IP, estn basadas en la utilizacin de conmutadores inteligentes
que implementan funciones de control para enrutar los paquetes por trayectorias ms directas
entre un enrutador y el siguiente (lneas PVC). Para ello, estas funciones de control consultan
con las funciones de envo, las cuales proporcionan las tablas de enrutamiento necesarias para
la conmutacin correspondiente en cada caso.
En la figura 2.24 se muestra la interfaz
constituida por una serie de conmutadores entre un enrutador y el siguiente.
63
CAPTULO II
Figura 2.24 Topologa fsica y lgica del sistema enrutador-conmutador.

Esta topologa optimiza la trayectoria en el envo de paquetes en la red, a travs de la conmutacin en los
diferentes enlaces entre enrutadores (routers), para formar lneas de comunicacin llamadas PVC.
La deficiencia de este protocolo es que las funciones de envo y las de control son
manejadas por dos sistemas diferentes e independientes, de forma que se generan problemas
de interoperabilidad en los grandes circuitos de red. El protocolo MPLS viene a solucionar
este problema, dado que integra las dos funciones, es decir, los niveles 2 y 3 del modelo OSI.
Estos dos sistemas se ilustran el la figura 2.25.
Figura 2.25 Sistemas de envo y control en las redes ATM.

Los componentes de envo y control, se encuentran en niveles distintos y trabajan de forma independiente.
Sin embargo, el componente de control requiere consultar al componente de envo, las tablas de enrutamiento.
64
CAPTULO II
El protocolo MPLS est basado en la implementacin de etiquetas que definen un tipo

de flujo particular para cada grupo de paquetes. A travs de ellas, se puede establecer una ruta
especfica desde cada conmutador al siguiente. Los conmutadores inteligentes en este caso, se
denominan LSR, que es un enrutador que funciona a base de intercambiar etiquetas segn una
tabla de envo. El algoritmo de funcionamiento de un LSR se ilustra en la figura 2.26.
Figura 2.26 Algoritmo de funcionamiento de un LSR.

El paquete marcado con una etiqueta especfica, que entra por una determinada lnea, es re-etiquetado y
redireccionado de acuerdo a la tabla de etiquetas.
Esta tabla se construye a partir de la informacin de encaminamiento que proporciona

la componente de control, y es correspondiente a cada tipo de flujo. Al llegar el paquete
marcado con determinada etiqueta, el conmutador realiza el cambio de etiqueta
correspondiente y lo direcciona al siguiente conmutador de trayectoria ms ptima. Esta
trayectoria se denomina camino LSP, que no es ms que un circuito virtual que siguen por la
red todos los paquetes asignados a la misma FEC (clase equivalente de envo) [6].
Un ejemplo de lo antes expuesto sera el mostrado en la figura 2.27, donde el LSR de
entrada recibe un paquete normal (sin etiquetar) cuya direccin de destino es 212.95.193.1. El
LSR consulta la tabla de encaminamiento y asigna el paquete a la clase FEC definida por el
grupo 212.95/16, adems de asignarle una etiqueta (con valor 5 en el ejemplo) y enviar el
paquete al siguiente LSR del LSP.
65
CAPTULO II
Figura 2.27 Ejemplo de dominio MPLS entre 2 enrutadores.

El LSR de entrada recibe un paquete sin etiquetar, consulta la tabla de encaminamiento y le asigna una clase
FEC definida a travs de una etiqueta. Luego, enva el paquete al siguiente LSR del LSP.
Dentro del dominio MPLS los LSR ignoran la cabecera IP; slo analizan la etiqueta de
entrada, consultan la tabla correspondiente (tabla de conmutacin de etiquetas) y la
reemplazan por otra nueva, de acuerdo con el algoritmo de intercambio de etiquetas. Al llegar
el paquete al LSR de cola (salida), ve que el siguiente salto lo saca de la red MPLS; al
consultar ahora la tabla de conmutacin de etiquetas quita sta y enva el paquete por un
enrutador convencional.
MPLS tambin se puede presentar como un protocolo para hacer tneles, o bien, como
una tcnica para acelerar el encaminamiento de paquetes. En realidad, MPLS lleva a cabo un
poco de cada una de esas funciones, debido a que integra la capa de enlace y la capa de red,
combinando eficazmente las funciones de control del enrutamiento (routing) con la
simplicidad y rapidez de la conmutacin de la capa de enlace.
Al combinar en uno solo lo mejor de cada nivel (la inteligencia del routing con la
rapidez del switching), MPLS ofrece nuevas posibilidades en la gestin de backbones
(caminos primarios para el transporte de trfico), as como en la provisin de nuevos servicios
de valor aadido.
66
CAPTULO II
2.3.6.7 Nuevas VPNs.
Una Red privada virtual VPN (Virtual Private Network), es una tecnologa de red que
permite una extensin de la red local sobre una red pblica o no controlada (como por ejemplo
Internet).
Existen dos motivaciones para la implantacin de las VPN: financiera y de seguridad.
Financiera dado que los enlaces dedicados son demasiado costosos, principalmente cuando las
distancias son largas. Por otro lado existe Internet, que por ser una red de alcance mundial,
tiene puntos de presencia diseminados por el mundo. Las conexiones con Internet tienen un
coste ms bajo.
La motivacin de seguridad obedece a que, debido a que Internet es una red pblica
donde los datos en transito pueden ser ledos por cualquier equipo, se hace necesaria una
forma de cambiar los datos codificados, de forma que si fuesen capturados durante la
transmisin, no puedan ser descifrados.
Los datos transitan codificados por Internet en "tneles virtuales" creados por
dispositivos VPNs que utilizan criptografa. Estos dispositivos que son capaces de descifrar
los datos codificados forman, una red virtual sobre la red pblica. Es esa red virtual la que es
conocida como VPN.
Los dispositivos responsables para la formacin y administracin de la red virtual, para
propiciar una comunicacin con seguridad, deben ser capaces de garantizar:
La seguridad de los datos: en el caso que fuesen interceptados durante la transmisin, no
puedan ser decodificados.
Integridad de los datos: adems de no ser decodificados (seguridad), los datos no puedan ser
modificados durante la transmisin.
67
CAPTULO II
La autenticacin: garanta de que los datos estn siendo trasmitidos o recibidos del
dispositivo remoto autorizado y no de un equipo cualquiera, es decir, que el dispositivo remoto
con el cual fue establecido el tnel, es el autorizado y no otro equipo hacindose pasar por l.
La figura 2.28 ilustra la filosofa de las VPNs.
Figura 2.28 Red privada virtual, VPN.

Las redes privadas virtuales crean un tnel o conducto de un sitio a otro para transferir datos. Los paquetes
van encriptados de forma que los datos son ilegibles para los extraos.
Realmente, el problema que plantean estas VPNs es que estn basadas en un modelo
topolgico superpuesto sobre la topologa fsica existente, a base de tneles extremo a extremo
(o circuitos virtuales) entre cada par de enrutadores de cliente en cada VPN. De all las
desventajas en cuanto a la poca flexibilidad en la provisin y gestin del servicio, as como en
el crecimiento cuando se quieren aadir nuevos emplazamientos.
Con una arquitectura MPLS se obvian estos inconvenientes, ya que el modelo
topolgico no se superpone sino que se acopla a la red del proveedor. En el modelo acoplado
MPLS, en lugar de conexiones extremo a extremo entre los distintos emplazamientos de una
VPN, lo que hay son conexiones IP a una "nube comn" en las que slo pueden entrar los
miembros de la misma VPN. Las "nubes" que representan las distintas VPNs, se implementan
mediante los caminos LSPs creados por el mecanismo de intercambio de etiquetas MPLS.
Los LSPs son similares a los tneles en cuanto a que la red transporta los paquetes del
usuario (incluyendo las cabeceras) sin examinar el contenido, a base de encapsularlos sobre
otro protocolo. Aqu est la diferencia: en los tneles se utiliza el encaminamiento
convencional IP para transportar la informacin del usuario, mientras que en MPLS, esta
informacin se transporta sobre el mecanismo de intercambio de etiquetas, que no ve para
68
CAPTULO II
nada el proceso de enrutamiento IP. Sin embargo, s se mantiene en todo momento la

visibilidad IP hacia el usuario, que no sabe nada de rutas MPLS sino que ve una red privada
(intranet) entre los miembros de su VPN.
De este modo, se pueden aplicar tcnicas QoS basadas en el examen de la cabecera IP,
que la red MPLS podr propagar hasta el destino, pudiendo as reservar ancho de banda,
priorizar aplicaciones, establecer Clases de Servicio (CoS) y optimizar los recursos de la red
con tcnicas de ingeniera de trfico.
En la figura 2.29 se representa una comparacin entre ambos modelos.
Figura 2.29 Red privada virtual, VPN.

La diferencia entre los tneles IP convencionales (o los circuitos virtuales) y los "tneles MPLS" (LSPs) est
en que stos se crean dentro de la red, a base de LSPs, y no de extremo a extremo a travs de la red.
2.3.7 Centrales IP.

Las centrales IP basadas en software, al ser comparadas con las centrales tradicionales,
resultan ser mucho ms convenientes, por muchas razones, pero particularmente se podra
mencionar la flexibilidad y extensibilidad que estas ofrecen. Las centrales tradicionales hacen
su trabajo muy bien, sin embargo, es todo lo que pueden hacer.
69
CAPTULO II
En cambio, una central IP es totalmente personalizable, permitiendo cubrir todas las

necesidades de comunicacin de las empresas actuales.
La funcionalidad de una Central IP
puede llegar a ser muy amplia, a continuacin se hace mencin a las funciones bsicas o
estndar de una central IP y ms adelante a otras funciones ms complejas como avance de las
anteriores.
La capacidad mnima de una central IP debe estar compuesta por todos los elementos
necesarios para realizar las funciones de una central PBX analgica, es decir, enrutamiento de
llamadas, manejo se sealizacin, adems de manejo de las diferentes funciones y protocolos
de Internet, as como contar con el
hardware y software interfaz con las redes de telefona
analgica.
Todo lo anterior es debido a que el equipo que hace las veces de central IP debe
proveer todo el control y la lgica de servicio de las llamadas.
El control de las llamadas y la lgica de las llamadas se refieren colectivamente a las
funciones necesitadas para procesar una llamada telefnica. Algunos ejemplos de control de
las llamadas son:
9 Determinar si la parte a la que se llama est disponible, ocupada, tiene una
transferencia de llamada, y entonces se aplica la manipulacin apropiada (por ejemplo,
provocar un ring en el telfono, aplicar una seal de ocupado, enviar la llamada a un correo de
voz, etc).
9 Reconocer que una de las partes que llama levant el telfono y que el tono de marcar debe
ser provisto.
9 Interpretar los cdigos marcar y determinar si la llamada debe ser terminada.
9 Manejar los paquetes de voz, de la manera ms eficiente posible, a fin de obtener buena
calidad de servicio.
70
CAPTULO II
9 Manejar diferentes extensiones.

9 Tener la capacidad de enrutar tanto la sealizacin como los paquetes de voz a las lneas
telefnicas tradicionales.
9 Desarrollo de otro tipo de aplicaciones de valor agregado.
Con este concepto la empresa se libera de la inversin y el costo de operar una central
telefnica empresarial (PBX).
2.3.7.1 Ejemplos de Centrales IP.
Existen variedad de ofertas en lo que a centrales IP se refiere, especficamente existen

varias opciones de centrales IP por software, entre ellas se pueden mencionar las siguientes:
Pingtel.
Es una central IP de software cerrado llamada tambin SipX, manejada por una
organizacin sin fines de lucro llamada Sip Foundry. Esta diseada bajo el protocolo SIP lo
cual permite alto grado de compatibilidad tanto de software como de hardware.
La facilidad de uso y la administracin son los criterios claves del diseo para el sipX.
SipX permite su administracin a travs de una interfaz web, es una solucin modular sobre
en LINUX y no requiere ningun hardware adicional.
Algunas caractersticas de este software son:
9 Seleccin de ruta automtica.
9 Servicio de autorizacin de llamadas.
9 Sealizacin de progreso de llamada.
71
CAPTULO II
9 Interfaz con la red PSTN.

9 Asignacin de cdigos sencillos a conexiones con nmeros telefnicos ms complejos.
9 Servicio de bloqueo de llamadas a determinados nmeros telefnicos.
9 Comunicacin segura, encriptamiento de los paquetes.
9 Transferencia de llamadas.
9 Servicio de cambio de estado por parte del cliente, a no disponible u ocupado para
determinada lista de nmeros telefnicos.
9 Permite movilidad al cliente, es decir, este puede abrir sesiones en ubicaciones geogrficas
diferentes.
Yate (Yet Another Telephony Engine).
Yate en una aplicacin para telefnica de ultima generacin, la cual esta
principalmente enfocada en los servicios de Vos sobre IP y en los servicios telefnicos sobre
la red PSTN. La fortaleza de esta aplicacin es su capacidad para ser expandida fcilmente.
Voz, video, data y mensajes instantneos pueden ser unificados sobre esta aplicacin de
enrutamiento flexible, maximizando de esta forma la eficiencia en las telecomunicaciones y la
minimizacin en los costos de infraestructura.
Las funciones que puede implementar este software son:
9 Servidor de voz sobre IP.
9 Interfaz cliente para voz sobre IP.
9 Interfaz entre telefona digital de voz sobre IP y la red PSTN.
9 Pasarela de PC al telfono y de telfono a PC.
9 Porteros H.323.
9 Mltiples terminales de central H.323.
9 Controlador de sesiones SIP.
9 Enrutador SIP.
9 Servidor para Registro SIP.
9 Protocolo IAX (Inter-Asterisk eXchange protocol) para sevidor y cliente.
72
CAPTULO II
9 Aplicaciones de IVR. (Interactive voice resurce)

9 Servidor de centro de llamadas
9 Sistema de manejo de tarjetas pre-pago y post-pago.
Este software esta realizado en lenguaje C y soporta algoritmos de encriptamiento en
diferentes lenguajes de programacin.
Bayonne.
GNU Bayonne es un proyecto basado en la plataforma GNU, que no es ms que un
sistema operativo de software abierto, que realiza las funciones de un servidor o central
telefnica. Es gratuito, medianamente independiente del ambiente de software y ofrece
soluciones para telefona IP sobre redes de ltima generacin, tales como:
9 Servidor de voz sobre IP.
9 Interfaz cliente para voz sobre IP.
9 Interfaz entre telefona digital de voz sobre IP y la red PSTN.
9 Porteros H323.
9 Controlador de sesiones SIP.
9 Protocolo IAX (Inter-Asterisk eXchange protocol) para sevidor y cliente.
9 Puede soportar distintos tipos de hardware para aplicaciones de IVR.
9 Puede soportar aplicaciones Java.
2.3.7.2 Asterisk.
Asterisk es una PBX completa en software. Opera sobre Linux, BSD (sistema
operativo derivado del sistema Unix), Windows y OS X y ofrece todas las caractersticas que
se podran esperar de una PBX y ms. Asterisk hace voz sobre IP en cuatro protocolos, ADSI
(administrador de recursos), SIP, H.323 (en ambos: cliente y gateway), MGCP (solo call
73
CAPTULO II
manager) y SCCP/Skinny (limitado) y puede inter-operar con casi todos los equipos de
telefona estndares usando un hardware relativamente ms barato.
2.3.7.1.1 Funcionalidad y alcance.
Asterisk permite:
9 Conectar empleados desde la casa a la PBX de la oficina sobre conexiones de banda ancha.
9 Conectar oficinas en varios estados a travs de VoIP, Internet o una red IP privada.
9 Ofrecer servicios de mensajera de voz (voicemail), integrado con la web y correo.
9 Construir aplicaciones interactivas de voz, que se conecten a un sistema de control u otras
aplicaciones domticas.
9 Dar acceso a la PBX de la compaa a empleados que se encuentren en constantes viajes
de negocios, conectndolos a travs de una VPN desde el aeropuerto, hotel, o cualquier otro
lugar.
Asterisk tambin incluye muchas caractersticas encontradas nicamente en sistemas
de comunicacin modernos basados en la unificacin de mensajes, tales como:
9 Llamada en espera y colas de llamadas.
9 Msica para llamada en espera (ej. Formato MP3).
9 Cola de llamadas que puede ser manejadas y monitoreadas conjuntamente por el agente
llamado.
9 Sistema de integracin de texto a voz (text-to-speech).
9 Generacin de registro de llamadas (Call data record, CDR) para integracin de sistemas
de tarificacin.
9 Sistema de reconocimiento de voz.
9 Habilidad de ser interfaz con lneas telefnicas.
9 Permite recibir alarmas en el telfono.
9 Aade mensajes al correo electrnico.
9 Servicio de Investigacin de llamadas maliciosas.
74
CAPTULO II
9 Transferencia de llamadas.
9 Registro conversaciones.
9 Agenda.
9 Acceso a funciones de una central PBX.
9 Identificador de llamadas.
9 Servicio de mensajera de texto.
2.3.7.1.2 Hardware.
Para la interconexin con equipos telefnicos digitales y analgicos, Asterisk soporta

varios dispositivos de hardware, especialmente los manufacturados por su patrocinante
Digium.
Digium adems de tener interfaces para dispositivos digitales, cuenta tambin con
tarjetas para la conexin de equipos o lneas analgicas (FXO y FXS) las cuales estn
disponibles y son de fcil instalacin.
Asterisk tambin es compatible con otras tarjetas de diversos fabricantes, entre los que
podemos mencionar: Aculab, Eicon, Intel, Openvox, Sangoma, Voicetronix y Xorcom.
2.3.8 Softphones.
En el entorno laboral actual est creciendo cada vez ms la necesidad de contar con
sistemas de comunicaciones flexibles. Los usuarios remotos o mviles necesitan con
frecuencia acceder a todo tipo de herramientas de comunicaciones mientras estn fuera de la
oficina.
Los softphones (telfonos de software) son aplicaciones de software ejecutables a
travs del PC. Resultan ser una solucin ideal para los usuarios remotos o mviles, pero
75
CAPTULO II
tambin para los usuarios que pasan mucho tipo frente al PC, como pueden ser los agentes de
centros de llamadas o los empleados de servicios de atencin al cliente.
Al ofrecer adems todas las prestaciones tradicionales de telefona, cubren por
completo las necesidades del entorno de la telefona a travs del PC.
2.3.8.1 X-lite.
El vendedor de software de telfonos VoIP, Xten Networks, ha puesto a disposicin un

softphone SIP: el X-Lite, el cual est disponible con un kit de desarrollo de software (SDK),
dispositivos embebidos y aplicaciones de mensajera instantnea.
X-Lite permite a los usuarios realizar llamadas IP a IP y llamadas IP a PSTN/Celular.
Soporta una variedad de proveedores de servicios de VoIP y tambin, puede usarse con una
central IP local (IP-PBX). Ofrece lnea en espera, tres lneas, el discado rpido, transferencia
de llamadas, lista de los nmeros ms recientes, identificador de llamadas, supresin de audio
(mute), cronmetro de la llamada, y ms.
El X-Lite es el modelo ms bsico de Xten, dado que esta compaa tambin ofrece
softphones de primera clase que soportan video y otros funciones ms avanzadas, y est
disponible para Macs, PCs y para la plataforma de PocketPC.
2.3.8.2 SipXphone.
SipXphone es un softphone SIP disponible para las plataformas Windows y Linux. Es

parte de la familia de proyectos sipX de SIPfoundry con licencia de cdigo abierto bajo LGPL.
76
CAPTULO II
SipXphone es un softphone SIP de fuente abierta para equipos personales y

computadoras porttiles. Este softphone VoIP ofrece una funcionalidad excepcional, una
interfaz de usuario intuitiva y una calidad de audio de ambientes Microsoft Windows y Linux.
SipXphone es usado tpicamente por aquellos que quieren o necesitan acceder a un
telfono de oficina cuando viajan. Les proporciona a sus usuarios la habilidad de llevar su
telfono de oficina y todos sus rasgos, aplicaciones, y directorios en su computadora porttil,
estableciendo conexin con el servidor SIP de la Empresa. Tambin es apropiado para
empleados de la empresa que prefieren un telfono integrado en la computadora, dado que no
requiere ningn espacio del escritorio.
Usando el sipXphone, los usuarios pueden acceder el marcado rpido, los directorios
corporativos, manejo de llamadas, registro de llamadas, discado desde Microsoft Outlooko, as
como otras aplicaciones que refuerzan la productividad. Incluye adems una mquina virtual
Java que permite agregar aplicaciones personalizadas muy fcilmente.
2.3.8.3 Solucin SipXezphone (Libre).

SIPfoundry ha puesto a disposicin un conjunto completo de funciones SIP, libreras y
herramientas para construir soluciones clientes SIP. Los ejemplos incluyen el Agente Usuario
(UA) sipXtapi, que contiene los libreras de sipX: sipXcallib, sipXtacklib, sipXmedialib y
sipXportlib; y la solucin sipXezphone que incluye al proyecto sipXtapi (con sus libreras) y
al proyecto sipXmediaAdapterLib.
El softphone sipXezPhone se construye encima de la interfaz (API) sipXtapi que
simplifica la compleja tarea de usar bibliotecas subyacentes con el fin de crear caractersticas
de un softphone, u otras aplicaciones SIP.
La interfaz de usuario (UI) para el sipXezPhone se hace usando wxWidgets, una
librera UI. La aplicacin del sipXezPhone se maneja por estados y eventos. Los eventos de la
77
CAPTULO II
capa de sipXtapi y del caso de la interfaz de usuario provocan transiciones de estado en la

mquina de estados.
2.3.8.3.1 SipXTapi.
SipXtapi es una Interfaz de Programacin de Aplicaciones (API) hecha en lenguaje C

para comunicaciones de voz sobre IP. Especficamente, sipXtapi proporciona una interfaz de
telefona generalizada sobre el Protocolo de la Iniciacin de la Sesin (SIP) y el Protocolo del
Transporte de Tiempo Real (RTP). Mientras los protocolos SIP y RTP proporcionan
sealizacin e infraestructura de transporte de datos de voz, sipXtapi incluye tambin muchos
otros protocolos e implementaciones estndares necesitadas para comunicaciones de voz.
SipXtapi est desarrollada bajo open source (cdigo fuente abierto) y presentado como
parte de la lnea de proyectos sipX disponibles de SIPfoundry. Se licencia bajo LGPL, que
permite el uso comercial de la biblioteca sin la "infeccin vrica" asociada con GPL. La
tecnologa utilizada debajo de sipXtapi fue donada por la Corporacin Pingtel
(www.pingtel.com) en marzo de 2004. Esta tecnologa se considera bien probada y muy
interoperable con otros dispositivos SIP.
El objetivo primario para sipXtapi es proveer una simple interfaz de programacin para
desarrolladores de aplicaciones, en particular, de aplicaciones de telefona. SipXtapi est
diseado para permitir esta clase de desarrollos proporcionando una solucin sencilla que
abstrae muchos de los complejos detalles de SIP. Los desarrolladores que usan sipXtapi no
requieren tener un dominio exacto de la sintaxis y semntica de los protocolos fundamentales,
de modo que pueden enfocarse en un modelo de llamada ms familiar.
SipXtapi compila y se ejecuta bajo Windows y Linux. Su uso ms obvio, es como base
para el desarrollo de telfonos de software (softphones), incluyendo caractersticas como:
Interfaz de Programacin de Aplicaciones de Telefona (TAPI), mltiples llamadas
simultneas, mltiples identidades SIP, autentificacin de lnea, puertos configurables,
codificacin y decodificacin de la voz, entre otras.
78
CAPTULO II
2.3.8.3.2 SipXCallLib (Call Processing Library).
El proyecto de sipXcallLib proporciona una capa abstracta de procesamiento de

llamadas, sobre las libreras sipXmediaLib y sipXtackLib. Esta capa provee un modelo de
llamada sobre los constructores SIP bsicos y maneja los recursos y ciclos de vida de la
misma. Adicionalmente, sipXcallLib impone un modelo de hebra seguro.
La biblioteca de procesamiento de llamada SipXcallLib, est escrito en C++ y su
corazn incluye las clases: CallManager (manager de llamadas), Call Classes (clases de
llamada), Connection Classes (clases de conexin); y la interfaz de media.
2.3.8.3.3 SipXezPhone.
Bajo el proyecto de sipXcallLib, se encuentra el ejemplo sipXezPhone, el cual

demuestra por primera vez, la capacidad del Agente Usuaro (UA) sipXtapi de implementar un
softphone sencillo. SipXezPhone est pensado como una implementacin de ejemplo para que
los desarrolladores aprendan cmo cmo usar sipXtapi.
SipXezPhone est escrito utilizando C++, wxWidgets
y sipXtapi. SipXtapi y
sipXezPhone se construyen para ser multiplataforma.

SipXezPhone es un softphone SIP de fcil uso, con una interfaz grfica sencilla. Es un
buen punto de partida para experimentar con la tecnologa SIP o para construir un softphone o
cliente SIP propio. Adems, tiene soporte para las siguientes caractersticas:
sipXezPhone sostiene actualmente la lista siguiente de caractersticas: transferencia de
llamadas, cancelacin automtica de eco, identificador de llamada, lista de nmeros
recientemente usados, ajuste de volumen, entre otras.
79
CAPTULO II
2.3.8.3.4 SipXmediaLib (Media Processing Library).
El proyecto sipXmediaLib incluye todas las funciones de procesamiento de audio

usadas en los proyectos sipXphone y sipXvxml de Sipfoundry. Su biblioteca contiene, por
ejemplo, puentes de audio (bridges), clasificadores de audio (splitters), supresin de eco,
generacin de tonos (DTMF), soporte de flujo (streaming), RTCP, CODECs PCM, etc.
El objeto de ms alto nivel en el proyecto sipXMediaLib es el Grfico de Flujo de
Llamada, MpCallFlowGraph. Este grfico de flujo rene varios recursos de media en un orden
definido de flujo, donde cada recurso tiene cero o ms entradas y cero o ms salidas. Los
recursos son procesados en el orden implicado por la topologa de conexin.
Los recursos pueden ser agregados dinmicamente al grfico de flujo y nuevos tipos de
recursos pueden ser derivados. Una conexin es una construccin lgica que contiene los
recursos relacionados a una sola fuente remota de media. Pueden existir cero o ms
conexiones en un MpCallFlowGraph.
La figura 2.30 ilustra las conexiones lgicas del MpCallFlowGraph.
Figura 2.30 Conexiones Lgicas del MpCallFlowGraph.

MpCallFlowGraph es el objeto de ms alto nivel en el proyecto sipXMediaLib, el cual rene varios recursos
de media.
80
CAPTULO II
Dentro del MpCallFlowGraph se crean los recursos incluidos en la clase Media Task
(Puente, Desde Micrfono, etc.), se agregan stos al grfico de flujo y se crean los enlaces
entre ellos.
Media Task espera recibir
una notificacin en cada intervalo de tiempo,
indicando el momento en que tiene que procesar un recurso de media, segn el orden en el
cual fueron enlazados (linked). Media Task procesa cada recurso de acuerdo a un mtodo
llamado doprocessframe que es diferente para cada recurso.
La clase Connection se crea en el momento en que se requiere una conexin para el
establecimiento de una comunicacin. Dentro de sta se crean los recursos de Connection
(Desde la red, decodificador, codificador, etc.). Una vez que han sido creados estos recursos,
Media Task los incluye en su lista de procesamiento.
2.3.8.3.5 SipXmediaAdapterLib.
El
directorio
sipXmediaAdapterLib
contiene
nicamente
el
proyecto
sipXmediaMediaProcessing. ste fue creado en esta forma de modo que diferentes libreras,
las cuales implican distintos mtodos o algoritmos de procesamiento de media, pudiesen
existir todas en el directorio sipXmediaAdapterLib.
2.3.8.3.6 SipXportLib.
La librera de portabilidad y capa de abstraccin de sistema operativo, sipXportLib,

provee un conjunto de clases que proporcionan una abstraccin de una mayora de funciones
sistema operativo. Todos los proyectos sipX usan esta librera para asegurar fcil traslado a
cualquier sistema operativo. La biblioteca contiene actualmente, las clases que encapsulan las
funciones y las operaciones para:
9 Hebras.
9 Locks (cerraduras) y Mutexes.
9 Semforos.
81
CAPTULO II
9 Mensajes y Colas.
9 Temporizadores.
9 Tiempo y Fecha.
9 Sockets.
9 Archivo y Directorio.
9 Procesos de sistema operativo.
9 Carga dinmica de libreras bibliotecas y smbolos compartidos.
Esta librera est trasladada a las siguientes plataformas de sistema operativo:
Windows/win32, Windows CE, Linux y Solaris.
2.3.8.3.7 SipXtackLib.
Este proyecto proporciona una pila SIP. Esta pila se construye sobre una base modesta
de la pila de HTTP. Ambas pilas, estn pensadas para ser utilizadas
en los sistemas
embebidos. Sin embargo, ellas son totalmente funcionales.

La interfaz principal de la pila SIP se encuentra en la clase SipUserAgent. Este
proyecto depende del proyecto sipXportLib.
Tambin estn incluidas en este proyecto, algunas herramientas para el envo,
recepcin y visualizacin de mensajes y transacciones SIP.
CAPTULO III
CAPTULO III. TELEFONA IP EN VENEZUELA Y EL MUNDO.

Las compaas de telecomunicaciones estn mirando con mayor inters la posibilidad
de ofrecer servicios integrados bajo plataformas de Internet o protocolos IP, los cuales, les
permitirn ofrecer ms valor agregado a sus clientes y un sin fin de servicios adicionales a
travs de la red.
Algunas empresas filiales locales estn, desde hace aproximadamente cuatro aos,
brindando a sus clientes corporativos soluciones de voz sobre IP, basadas en la tecnologa de
Internet, marcando as el inicio de una nueva etapa en la era tecnolgica
Por otro lado, existen empresas que pretenden hacer ofertas de telefona IP no slo para
las compaas, sino tambin para los clientes residenciales, y es que el mercado venezolano, es
uno de los principales consumidores de tecnologa en Amrica Latina. En otras palabras,
Venezuela es uno de los pases ms receptivos en cuanto a la adopcin de servicios y
productos tecnolgicos se refiere.
A continuacin se exponen los planteamientos generales de algunas de las empresas
que han sido responsables de la oferta de telefona IP en Venezuela. [7]
CISCO.
Esta compaa es lder mundial en soluciones de voz sobre IP, con un 31,8% de
participacin en los ingresos totales alcanzados por la industria en el segundo trimestre de
2004, superando a la industria francesa Alcatel. A nivel mundial, Cisco aparece, como el
cuarto proveedor de voz a nivel empresarial ms grande del mundo, medido por ingresos
totales en ventas de voz IP y voz tradicional.
Durante el ltimo trimestre del ao 2004, Cisco vendi el 41,6% de todos los telfonos
IP del mundo (alrededor de 437 mil telfonos), ms que cualquier otro fabricante y ms que
cualquier otro trimestre desde que la compaa entr en el mercado de voz. Cisco es lder en
83
CAPTULO III
soluciones PBX IP-puro con el 62 % del mercado y en telfonos IP con el 54 %
de
participacin, en Amrica Latina.

En Venezuela Cisco atac el mercado corporativo en el pas y ahora est enfocado en
ofrecer sus servicios de comunicaciones IP a las pequeas y medianas empresas, as como al
sector de los proveedores de servicios, la industria, banca, etc.
Hoy en da, CISCO cuenta con ms del 60% de participacin en telefona IP, con ms
de cuatro mil telfonos colocados en los ltimos 4 aos, convirtindose Cigarrera Bigott, en un
gran cliente al adquirir ms de 700 telfonos, negocio alcanzado por Cisco de la mano de
Equant, empresa que ejecut la negociacin desde su sede de Latinoamrica ubicada en
Argentina. Este negocio gener, en conjunto, cerca de los 25 millones de dlares.
En el mundo, la telefona IP est creciendo a un ritmo de ms de 45% cada ao, segn
resea la empresa de investigacin Infonetis, y por su parte Venezuela y Amrica Latina
tambin siguen un patrn de crecimiento similar, donde Cisco mantiene un 60% de
participacin de mercado. Los ltimos resultados de Cisco a escala mundial para el ao 2004,
reflejaron un incremento en las ventas anuales de 16,8% y, especficamente en Venezuela, las
ventas de tecnologas avanzadas con nfasis en telefona IP y seguridad, representaron el 15%
del total de las ventas locales.
AVAYA.
Pese a que, prcticamente, Cisco es lder en todo lo que tiene que ver con IP, existen
otros proveedores de servicios e infraestructura que da tras da, han ido acumulando un
nmero importante de clientes y, de esta forma, posicionando sus productos en el mercado
local.
Uno de estos proveedores es AVAYA. Esta compaa, que ser proveedor oficial de
tecnologa para el mundial Alemania 2006, tiene un total de 130 clientes en Venezuela,
donde tambin est instalada una de sus bases, que adems es una de las ms grandes de la
84
CAPTULO III
regin. Tienen 250 equipos instalados, ms de 30 mil puertos en funcionamiento en un

estimado de 130 empresas, entre las cuales se pueden mencionar: Exxon Mobil, Enelbar y
Citibank.
Anteriormente ellos colocaban sus productos principalmente en las grandes empresas,
pero hoy da la estrategia ha cambiado. Avaya cuenta con productos para la pequea y
mediana industria, en donde las empresas, dependiendo de sus capacidades, podrn adquirir
una solucin, ya que stas van desde los 600 dlares para una empresa de caractersticas
menores y entre ocho mil y 12 mil dlares para una compaa grande.
INTERCABLE.
Generalmente cuando se habla de telefona IP, slo se hace referencia a la oferta
corporativa existente a travs de compaas de redes y servicios con protocolos de Internet.
Sin embargo, en Venezuela mucho se ha planteado en cuanto a telefona IP residencial o
telefona digital, que slo puede ser prestada por empresas con habilitaciones administrativas,
an cuando hasta hace poco las iniciativas se haban quedado en espera.
Intercable es una de las empresas dispuesta a brindar este servicio. Su idea es ofrecer el
servicio de telefona digital a travs de la red de fibra ptica tanto a empresas como a clientes
de de televisin por suscripcin en algunas zonas del pas, para primer trimestre de 2005.
La red de Intercable atravesaba para el 2004, 1,4 millones de hogares, de los cuales
unos 500 mil estn adecuados para poseer servicios de Internet de banda ancha, siendo sta la
nica va para que tambin le sea posible a la compaa ofrecer telefona digital.
Intercable pretende enfocarse en dar valores agregados y una plataforma de servicios
ms desarrollada.
Las empresas de televisin por suscripcin tienen una importante ventaja competitiva
en este tipo de servicios en comparacin con el resto de las compaas, debido a
la
85
CAPTULO III
infraestructura instalada que poseen y las posibilidades reales que tienen de ofrecer telefona
digital a travs de la red de fibra a los clientes del servicio de televisin por cable, que en el
caso de Intercable, est en el orden de los 350 mil hogares.
Desde que la compaa inici operaciones en Caracas, hace aproximadamente dos
aos, se
haban realizado algunos intentos de desarrollar la infraestructura para ofrecer
telefona a travs de su basta red de fibra, pero no haba sido posible. Sin embargo, an se
mantiene como la primera empresa con claras intenciones de masificar el uso de la telefona
digital y ofrecerla a escala residencial, a travs de redes IP basadas en fibra ptica.
LUCENT.
La consigna actual de Lucent Technologies est focalizada en la migracin hacia
plataformas unificadas, en donde puedan converger un sinfn de servicios y valores agregados.
Esta compaa hoy en da, presta sus servicios a las dos empresas ms importantes de
telecomunicaciones en Venezuela, como son Telcel y Cantv con Movilnet.
Su estrategia est basada en estndares IP, es una de las pocas empresas que tienen la
visin de que todas las plataformas y servicios actuales deben converger sobre una plataforma
nica, tal que el usuario final pueda tener la posibilidad de acceder a servicios diferentes sin
tener que moverse de una plataforma a otra no tener que adquirir mltiples equipos terminales
para este fin.
A modo general, la idea principal, es tener una red IP a la que se puedan conectar las
diferentes plataformas actuales que conocemos, tanto la inalmbrica como las almbricas, y
desde all, permitir al operador ser un multiservicio. En Lucent tienen la visin que si no se
convierte en multiservicio se quedar con uno slo y ese ser su diferenciador en los precios y
las ganancias por los valores agregados.
86
CAPTULO III
EQUANT.
Equant posee ms de 152 mil usuarios conectados a su red en todo el mundo, con
presencia en unos 220 pases, a travs de sus ms de tres mil 700 clientes. Esta empresa ha
enfocado su estrategia en la captacin de clientes transnacionales, as como tambin se he
centrado en la oferta de servicios de transporte para los proveedores de servicios de Internet
(ISP) en el pas para el desarrollo de negocios a travs de los protocolos de Internet IP.
Para febrero del 2002, Equant haba sido la primera empresa en manejar soluciones de
Telefona IP de escritorio a escritorio con calidad de portadora, a travs de la tecnologa
MPLS (Multi Protocol Label Switching). De este modo, la compaa ofreca telefona en la
red de rea local (WAN) e integraba una PBX sobre IP basada en la red con funciones
avanzadas de voz sobre VPN y capacidades extensas fuera de la red de rea local.
Recientemente cerraron un contrato por 25 millones de dlares con Cigarrera Bigott
conjuntamente con Cisco, para la implementacin de una solucin de telefona IP.
En
Venezuela, la fortaleza de la compaa se encuentra en el transporte de datos y redes IP, donde

cuentan con una suma considerable de clientes, alrededor de los 280 y entre los cuales
destacan empresas privadas y redes del estado.
Ellos sealan que 75% del trfico de Internet de Venezuela sale a travs de Equant, de
esta manera Equan se convierte en uno de los principales proveedores de servicios de Internet
(carriers) de Venezuela.
En cuanto a tecnologa IP se refiere, stos ofrecen a su cartera de clientes un conjunto
de soluciones integrales e insisten en ir ms all de los enrutadores y el transporte a travs de
redes privadas virtuales, VPN.
Equant es un aliado de empresas como Cisco, con las cuales, de forma conjunta, ofrece
servicios de telefona IP, siendo su principal valor la implementacin de la infraestructura,
aunque a veces venden los equipos y no el transporte, o viceversa.
87
CAPTULO III
Entre sus clientes mundiales, se encuentran Samsung, Cigarrera Bigot, Mastercard, LG

Electronics, Renault y Pirelli, aseguradora Zurich, y la cadena de hoteles L Meridiem.
Adicionalmente, los puntos de acceso de Conatel operan bajo la red de Equant. La empresa
tambin provee la red de tecnologa IP de datos en acuerdo con la operadora Netuno,
encargada del transporte de los datos.
Esta empresa est certificada con Cisco y Nortel Networks para ofrecer telefona IP.
Tienen, por su parte, la capacidad de ofrecer a sus clientes Call Manager y equipamiento en
general, adems del transporte. Son una empresa con capital de France Telecom, con ms de
mil 100 clientes en el servicio de IP-VPN y ms de 35 mil puertos instalados a escala mundial.
En Amrica Latina, Equant estim un crecimiento para el 2005, entre 8% y 10%,
similar a la registrada en mercados tan importantes como Argentina, Brasil y Venezuela.
BANTEL.
En telecomunicaciones, Bantel se enorgullece de ser la nica empresa completamente
venezolana con una red satelital en Amrica Latina, desde el Ro Grande hasta la Patagonia
con lo ms avanzado en IP satelital.
Inicialmente con el proceso de apertura en el pas y la llegada de nuevos operadores de
servicios, Bantel se vio amenazada y atraves ciertas dificultades operativas. Sin embargo, se
han mantenido en el mercado y para el ao 2004 contaban con un total de 102 clientes que
utilizan sus servicios.
Sus directivos sostienen que la empresa es una joya en redes privadas IP, ATM y
Frame Relay, y que la oferta satelital IP que en principio no tena mayor auge, hoy en da tiene
mucha importancia porque tiene la capacidad de llegar donde las dominante no pueden, lo cual
les brinda una ventaja competitiva con el resto.
88
CAPTULO III
Fueron los primeros en tener en el pas una red privada satelital, diseada a la medida
de las necesidades de las compaas que las usan (VSAT Very Small Aperture Terminals)
con tecnologa IP, as como tambin fueron los primeros en ofrecer el servicio corporativo de
videoconferencia.
En general, los servicios satelitales estaban basados en video broadcast, que
empaquetan una cpsula de video y la hacen ineficiente, porque el proceso es ms lento y es
ms costoso en el ancho de banda. En contraste, el sistema BANTEL maneja la red satelital
que est hecha nica y exclusivamente para el manejo IP desde la gestin hasta el final, por tal
motivo ellos ofrecen garanta de servicios y calidad.
El ao pasado, la compaa lanz un nuevo servicio denominado Bantel Bass, con el
cual pretendieron ofrecer a los clientes la posibilidad de abarcar todo el continente mediante
un nico proveedor. Con Bantel Bass los clientes podrn soportar una gran variedad de
servicios y aplicaciones de IP de voz, datos y video, permitindoles clasificar y priorizar el
trfico de los datos en la red en tiempo real.
De este modo, BANTEL es otra empresa venezolana orientada a brindar cada da
mejores y ms interesantes ofertas en cuanto a los servicios sobre las redes IP.
IMPSAT.
Esta compaa que ha sido siempre proveedora de servicios integrados de
telecomunicaciones en datos, Data Center, Telefona e Internet Banda Ancha, etc. Hoy en da
se ha planteado ofrecer otros servicios de valor agregados, aprovechando los avances en lo
que a redes IP se refiere. En este sentido este ao ha presentado al mercado venezolano IP
Anywhere, una nueva oferta de servicios de tipo IP, con el objetivo de potenciar la evolucin y
expansin de los negocios empresariales.
Esta nueva propuesta contiene desde los servicios bsicos de conexin hasta los de
mximo valor agregado como consultora y outsourcing, en una nica plataforma de red de
89
CAPTULO III
banda ancha, permitiendo la conexin entre sitios dispersos, en forma sencilla y transparente,
donde confluyan todo tipo de aplicaciones y trficos, incrementando, de esta forma, la
productividad e inclusive los ingresos del cliente.
Con esta nueva oferta, Impsat permitir al cliente enfocarse completamente en el
desarrollo, planificacin y crecimiento de su negocio delegando a Impsat la operacin de los
sistemas de misin crtica, que requieren seguridad y disponibilidad. IP Anywhere es un
concepto muy arraigado a la imagen de Impsat como empresa consultora y aliado tecnolgico
de sus clientes.
CAPTULO IV
CAPTULO IV. MARCO METODOLGICO

4.1 Investigacin previa al diseo.
Para realizar un planteamiento concreto de todos los elementos del proyecto a

desarrollar, fue necesario desplegar una investigacin bastante amplia respecto a varios
aspectos inherentes a este proyecto.
En primer lugar, se procedi a investigar sobre los protocolos de telefona tanto
analgica como digital, con el objetivo de conocer el funcionamiento de las centrales y los
terminales telefnicos, en el establecimiento y desconexin de una llamada.
En segundo lugar, se investig sobre los principales protocolos de Internet y se
profundiz especialmente en aquellos relacionados con aplicaciones en tiempo real.
En tercer lugar, se realiz la investigacin correspondiente a las centrales utilizadas
para telefona IP, para ello se tomaron en cuenta aspectos como:
9 Capacidad de la central en cuanto a los servicios que ofrece (correo de voz, conferencia,
videoconferencia, llamada en espera, servicios de IVR, fax, etc) para futuras aplicaciones.
9 Manejo de extensiones.
9 Protocolos de telefona y de Internet que soporta.
9 Compatibilidad con telfonos de software que permita la realizacin de pruebas y estudio
del funcionamiento de los elementos de comunicacin en conjunto.
9 Compatibilidad con el hardware existente que permita la interaccin de la telefona IP con
la red telefnica tradicional PSTN.
9 Requerimientos de hardware para la instalacin de dicha central.
9 Disponibilidad del software sin restricciones de licencia y con cdigo fuente abierto.
9 Interfaz Web para la configuracin de la misma, entre otros aspectos.
91
CAPTULO IV
Posteriormente, se procedi a la investigacin sobre algunos telfonos de software

(softphones) y se procedi a su instalacin para realizar las pruebas correspondientes a la
interaccin de stos con la central. Para esto, fue de gran ayuda la utilizacin de un analizador
de protocolo que permiti observar la entrada y salida de todos los tipos de paquetes (RTP,
SIP, RTCP, TCP, etc) desde los telfonos de software hasta la central y viceversa.
Despus de haber adquirido un conocimiento ms integral sobre el funcionamiento de
la telefona por Internet, se procedi a investigar sobre las posibles plataformas de software a
utilizar para el desarrollo del programa cliente, que tendr la misin de manejar las sesiones de
Internet para sealizacin y datos de voz y cuyo lenguaje debe permitirle comunicarse con la
central.
Despus de haber avanzado considerablemente en la investigacin respecto al
componente de software del proyecto, se continu con la investigacin del componente del
hardware.
Tomando en consideracin todas las funciones que deba realizar el hardware, como
manejo de pantalla, teclado, CODEC y dems funciones de control, se tuvo la necesidad de
utilizar un microcontrolador que adems tuviese los componentes necesarios para el desarrollo
de todas sus funciones, en especial un mdulo para la comunicacin serial o USB.
El siguiente paso en la investigacin respecto al hardware fue relacionado con el
CODEC. Para esto se busco informacin sobre los posibles formatos de codificacin y
decodificacin de la voz y se realizaron comparaciones entre ellos, con el objeto de identificar
cual formato sera el mas conveniente y tambin cuales eran soportados por la central.
Posteriormente, se realiz la respectiva investigacin para el logro de la generacin de
los tonos debidos a los eventos en una llamada telefnica segn la norma europea. En forma
general se investig sobre, circuitos generadores de tonos, circuitos amplificadores, acople de
impedancias, etc.
92
CAPTULO IV
Por ltimo, se realizaron investigaciones continuas, a lo largo de todo el desarrollo del

proyecto, con el fin de solventar las nuevas dificultades que se iban generando as como cubrir
los requerimientos nacientes. Para esto se fueron realizando las modificaciones respectivas
tanto en software como en el hardware.
4.2 Construccin de una matriz de parmetros y requisitos.

4.2.1 Software.
9 Debe soportar el manejo multihebra, que permita el procesamiento concurrente de las
distintas funciones a implementar.
9 El software debe estar en la capacidad de establecer una sesin TCP para la sealizacin.
9 El software debe ser capaz de establecer una sesin UDP para los paquetes de voz.
9 Debe servir de puente entre las sesiones de Internet y el hardware.
9 Debe tener compatibilidad
con la central IP, es decir, manejar los protocolos de
comunicacin que le permitan el intercambio de informacin de inters con sta.

9 Debe poseer un mdulo que permita la comunicacin por puerto serial o USB, para su
interaccin con el hardware.
9 Debe estar en la capacidad de diferenciar entre los bytes provenientes del puerto de
comunicacin serial o USB, es decir, contener un protocolo sencillo de comunicacin entre
aplicacin cliente y el hardware, que distinga entre bytes de datos y bytes de sealizacin.
9 Debe poseer un mdulo que permita el redireccionamiento de los bytes obtenidos a travs
del puerto de comunicacin serial o USB hacia las sesiones TCP o UDP, dependiendo de si
dichos paquetes corresponden a sealizacin o datos.
93
CAPTULO IV
9 Debe soportar el manejo de TAPIS.
4.2.2 Hardware.
9 Necesidad de crear un prototipo de telfono que se conecte a la computadora por puerto
USB o SERIAL.
9 Capacidad de realizar llamadas a telfonos con tecnologa VoIP, tanto de hardware como
de software.
9 Posibilidad a futuro de realizar llamadas por Internet a telfonos fijos tradicionales,
utilizando una tarjeta interfaz en la central.
9 Este prototipo debe dar respuesta a la mayor parte de los requerimientos del proyecto, con
el objetivo de sobrecargar lo menos posible el sistema operativo de la mquina.
4.3 Establecimiento de criterios de diseo.

4.3.1 Software.
9 La necesidad de que el software a desarrollar pudiera soportar el manejo de mltiples
hebras, motiv al estudio de los ambientes de programacin que ofrecieran esta caracterstica.
Entre stos se consideraron: Borland C, Borland C++, Borland C++ Builder, C# y Microsoft
Visual Studio .Net 2003.
9 A partir del estudio que se realiz respecto a las caractersticas que debe tener la central IP
se decidi trabajar con la central digital Asterisk para el manejo de la aplicacin. Por tal
motivo el software cliente debe estar en la capacidad de realizar funciones de registro con
dicha central y establecer acuerdos de comunicacin, para el intercambio de sealizacin y
datos de voz.
94
CAPTULO IV
9 Luego de adquirir un conocimiento ms robusto sobre los posibles protocolos de telefona,

se realizaron las evaluaciones correspondientes a la eleccin del protocolo ms adecuado, y se
decidi utilizar el protocolo SIP por las ventajas que ste ofrece y por la sencillez de su
implementacin.
9 Una vez elegido el protocolo a utilizar y verificar su compatibilidad con la central
Asterisk, se decidi basar este desarrollo a partir de un telfono de software denominado
SipXezPhone que implementa especficamente un conjunto de TAPIS que utilizan el
protocolo SIP y que adems son compatibles con Asterisk, denominadas SIPTAPIS.
4.3.2 Hardware.
Se desea que el hardware contenga:
9 Un modulo para la visualizacin.
9 Un mdulo para el manejo del teclado alfanumrico.
9 Un mdulo para el procesamiento de la voz.
9 Un mdulo para la generacin de los tonos segn la norma europea.
9 Un mdulo para manejar interrupciones externas.
Por todas estas razones, las cuales generan los requerimientos del microcontrolador
expuestos en la seccin de la investigacin documental, se determino utilizar el
microcontrolador Motorola MC68HC908GP32.
Cabe destacar que otra motivacin importante para esta eleccin fue el hecho de
disponer dentro del pas y a menor costo la tarjeta para la programacin de este
microcontrolador.
Para el procesamiento de la voz el formato de mayor eficiencia, en cuanto a la
velocidad o menor consumo de ancho de banda, era en primer lugar el formato GSM, luego el
ADPCM, seguido del PCM comprimido y por ltimo el PCM lineal. Todos soportados por la
95
CAPTULO IV
central. Pese a estas condiciones, se tuvo que implementar un CODEC de formato PCM
comprimido, debido a la disponibilidad de ste en el pas, y a las dificultades para adquirir los
otros integrados fuera del pas, dadas las limitaciones en cuanto al consumo slo al mayor.
Es importante mencionar que, dado que la utilizacin de comunicacin serial est en
desuso, se plante la necesidad de que la comunicacin se realizara a travs del puerto USB,
pese a que el microcontrolador escogido se comunica de forma serial. Para responder a este
requerimiento se realiz una investigacin a partir de la cual se utiliz una interfaz Serial USB que permitiese la comunicacin serial por parte del microcontrolador pero la recepcin
por parte de la computadora a travs de un cable con conexin USB en ambos extremos.
4.4 Equipos utilizados.
Una computadora de medianas exigencias de hardware: Pentium III de 500 MHz, con
128 M de memoria RAM. Este equipo realizar las funciones de la central IP.
4.5 Softwares utilizados.
Para grabar el programa de control del hardware en la memoria flash del

microcontrolador se utiliz la herramienta Flash Programmer y para la generacin de dicho
programa de control (en Assembler traducido a lenguaje C) se implement el software
CodeWarrior.
Ambos software estaban disponibles para el desarrollo de la aplicacin,
especficamente para el modelo de microcontrolador escogido.

Respecto al software para el desarrollo del programa cliente se decidi implementar
VisualStudio.net y se trabaj un tiempo en el proceso de compilacin del sipXezphone y de
sus SIPTAPIS.
96
CAPTULO IV
4.6 Hardware utilizado.
9 Pantalla LCD de 16 x 2 GDM1602K.

9 Teclado Matricial de 4 x 3.
9 Interfaz Serial USB.
9 El microcontrolador Motorola MC68HC908GP32.
9 Generador de tonos ICL8038.
9 CODEC PCM ley a TCM320AC37.
9 Circuito Oscilador de 16.384 MHz.
9 Registro binarios -flip flop tipo D- SN54LS377.
9 Flip flop tipo J K SN54109.
9 Compuertas NAND.
9 Compuertas NOT.
9 Contadores binarios de 8 bits.
9 Inversores de Polaridad.
9 Switches Analgicos.
9 Reguladores de Voltajes de 3V.
9 Pulsadores.
9 Dispositivos varios.
CAPTULO V
CAPTULO V. DESARROLLO DEL DISEO

5.1 Instalacin de la central IP.
Para lograr una instalacin exitosa de la central IP, as como para realizar la
configuracin de sta, se llevaron a cabo los siguientes pasos:
Se realiz la descarga de este software desde el sitio http://asteriskathome.sourceforge.net en
una unidad de almacenamiento, especficamente a un disco compacto CD.
Se realiz la corrida de este CD y se ejecut la accin correspondiente a la instalacin del
programa, considerando que el contenido del disco duro del equipo sera desechado.
Al aparecer la ventana solicitando un usuario user y una contrasea password se
colocaron las palabras root y password respectivamente.
Para la configuracin de la central se procedi a entrar en la interfaz web, a travs de la
direccin IP fija del equipo donde se realiz la instalacin del software.
Una vez dentro de esta interfaz, entramos en el link Asterisk Management Portal (AMP),
donde aparecer una ventana de solicitud de un usuario user y una contrasea password,
en donde se colocarn las palabras maint y password respectivamente.
Posteriormente se hace clik en Extensions y luego en Add Extensions.
Rellenar los datos solicitados para la creacin de la extensin, utilizar nmeros de extensin
a partir del nmero 200, inclusive este que es el nmero por defecto. [8]
Este software se actualiz en dos oportunidades durante el desarrollo de este proyecto,
es decir, en principio se instal la versin 1.3, despus la versin 2.0 y finalmente la versin
98
CAPTULO V
2.1. Estos cambios de versin se justifican en la adicin de nuevas funcionalidades as como

en la correccin de errores.
5.2 Instalacin de softphones de prueba.
Para la instalacin todos los softphones de prueba, se realiz un procedimiento similar.

Softphone X-Lite: En primer lugar se ingres en la pgina http://www.xten.com para
descargar este softward. Seguidamente, se procedi a la configuracin del mismo mediante el
men de configuracin. Se completaron los requerimientos de este men, sobre la extensin,
tal como se configur en la central, y los datos de la propia central, como direccin IP, etc. En
la figura 5.1 se ilustra la interfaz del softphone X-Lite as como, el men de configuracin con
sus respectivos datos.
Figura 5.1. Interfaz grfica y men de configuracin X-Lite.

A travs del men de configuracin que provee la interfaz de este softphone, se pueden establecer los
parmetros de comunicacin con la central digital para realizar y recibir llamadas, y utilizar otros servicios de
valor agregado.
99
CAPTULO V
SipXphone: De igual modo se procedi a descargar este software del sitio

http://www.sipfoundry.org/pub/sipXphone/win32/. La configuracin de ste se debe realizar a
travs de una interfaz web, para ello se procede de la siguiente manera:
9 Abrir la aplicacin SipXphone.
9 Seguir la siguiente ruta: More > Apps > Pref > Mysip softphone web. En la ventana que
aparece solicitando password admin dejarlo en blanco y hacer clic sobre OK. Luego
aparece otra ventana solicitando el puerto establecido para la transmisin de la voz, colocar
5060.
9 Abrir un explorador de Internet y colocar como direccin la direccin IP del equipo
seguido de dos puntos (:) y el puerto 5060.
9 Posteriormente aparece una nueva ventana donde se deber colocar como user la palabra
admin y ningn password, y as se ha ingresado al sitio Web de configuracin para el
SipXphone.
Una vez en el sitio web de configuracin, se procede a completar los requerimientos
que se muestran en dicho sitio, de forma al caso del softphone anterior. La imagen del sitio
web para la configuracin se muestra en la figura 5.2 y, adicionalmente la interfaz grfica de
este softphone se ilustra en la figura 5.3.
100
CAPTULO V
Figura 5.2. Interfaz Web de configuracin del SipXphone.

A travs de la direccin Ip del equipo donde se instal el software seguido del puerto para la voz, se accede
a una interfaz web donde se completan los requerimientos para establecer la comunicacin del SipXphone.
Figura 5.3. Interfaz grfica del SipXphone.

SipXPhone es un producto de sipfoundry, que permite la conexin de un cliente con una central digital, para
realizar y recibir llamadas, as como implementar otras funciones de valor agregado.
101
CAPTULO V
SipXezphone:
Para
descargar
esta
aplicacin,
se
ingres
en
la
pgina
http://www.sipfoundry.org/sipXezPhone/. Una vez instalado, se procedi a configurarlo a

travs de su men de configuracin, de forma similar que en caso del X-Lite. En la figura 5.4,
se ilustra la interfaz grfica de este softphone as como el men de configuracin del mismo.
Figura 5.4. Interfaz grfica y men de configuracin del SipXezphone.

A travs del men de configuracin que provee la interfaz del sipXezphone, se pueden establecer los
parmetros de comunicacin con la central digital para realizar y recibir llamadas, y utilizar otros servicios de
valor agregado.
5.3 Hardware.
Un diagrama ms detallado de todos los mdulos que se presentan a continuacin,

puede consultarse en el apndice A.
5.3.1 Generador de Tonos.
El equipo Terminal o telfono debe tener la capacidad de generar los tonos debidos a
los diferentes eventos que se pueden presentar en medio de una llamada, y adems resultara
prctico que dichos tonos estn en concordancia con la norma establecida por la CCITT,
particularmente con la norma europea que es la utilizada en Venezuela. La descripcin del
mdulo generador de tonos en diagrama de bloques, se observa en la figura 5.5.
102
CAPTULO V
Figura 5.5 Diagrama en Bloques del mdulo generador de tonos.

El circuito generador de tonos produce un tono continuo de 400 Hz a partir del cual se obtienen los tonos de
sealizacin (segn la Norma Europea), mediante el uso de un switche analgico y seales de control del
microcontrolador, los cuales definen la cadencia de los mismos.
El circuito generador de tono, est conformado por un VCO (ICL8038) que,

conjuntamente con otros dispositivos, generan la onda senoidal de 425 Hz, un amplificador
para controlar la ganancia de la seal y para acople de impedancias, un inversor de polaridad
(AMD660) para la alimentacin dual de los integrados antes mencionados, y por ltimo un
Switche analgico (74HC4066).
El funcionamiento de este mdulo a partir de las seales de control del
microcontrolador, se expondrn mas adelante.
5.3.2 Mdulo de Procesamiento de Voz.

Este mdulo tiene como objetivo, tomar y recibir las seales analgicas de al voz,
codificarlas y comprimirlas para ser enviada al microcontrolador y posteriormente a al red, a
travs del programa cliente. El diagrama en bloques de este mdulo se muestra en la figura
5.6.
103
CAPTULO V
Figura 5.6 Diagrama en Bloques del Mdulo de Procesamiento de Voz.

El CODEC modula la voz en formato PCM A utilizando seales de reloj (oscilador externo) y otras seales
de control del microcontrolador. Para la captura y reproduccin de la voz, se usa un circuito interfaz.
5.3.2.1 Circuitos de Reloj y Sincronizacin de seales.
Para el funcionamiento del CODEC se hace indispensable un sistema de relojera

bastante preciso y adems sincronizado, para lograr este objetivo se utiliz un circuito
oscilador de 16,384 MHz y un registro binario de 8 bits (SN74LS162) para la divisin de la
seal hasta obtener un reloj de 2,048 MHZ que es exactamente la seal de reloj requerida por
el CODEC.
Respecto a la sincronizacin de las seales, es necesario que estas seales de control
generadas por el microcontrolador estn sincronizadas con el reloj del CODEC, para ello las
salidas del microcontrolador antes de entrar en el CODEC pasan por algunas compuertas
lgicas. Especficamente, las seales que son ms rpidas pasan primero por un flip-flop tipo
J-K con el objetivo de prevenir que se genere un cambio de estado en la seal y no pueda ser
detectado por el CODEC antes que se genere el siguiente. Posteriormente dichas seales
pasan por otro flip-flop tipo D para que el cambio de estado quede memorizado hasta el
prximo flanco de bajada del reloj, en cuyo caso la transicin quedar sincronizada con el
reloj en cuestin. Respecto a las seales ms lentas, slo pasan por el flip-flop tipo D con el
mismo objetivo.
104
CAPTULO V
5.3.2.2 CODEC Ley A CCITT.
El CODEC utilizado tiene la capacidad de codificar y decodificar datos en formato

PCM lineal, y PCM en modo comprimido segn la Ley A de la CCITT. En este caso se ha
utilizado el CODEC en modo comprimido, para obtener mayor rendimiento en la transmisin
de los paquetes de voz. Las especificaciones tcnicas de este CODEC pueden consultarse
detalladamente en el apndice B.
Por otro lado el CODEC puede ser utilizado en modo fijo o en modo variable. El modo
fijo permite codificar y decodificar hasta 31 canales de voz, designando una ventana de tiempo
a los datos de cada canal y multiplexando dicha data. En contraste, el modo variable permite
trabajar en la codificacin y decodificacin de un solo canal.
En este caso se utiliz el modo variable, principalmente porque los requerimientos de
velocidad en todas las seales de control eran muy elevados en comparacin con la capacidad
del microcontrolador utilizado y porque adems este proyecto se ha enfocado en procesar la
voz de slo un terminal telefnico, sin considerar las opciones de conferencia.
De esta forma el CODEC se trabaj en modo variable o asncrono, generando las
seales especficas para la transmisin y recepcin serial de los bits, con la nica condicin
que el tiempo de transmisin de cada bit no sea mayor a 125s, que es correspondiente al
inverso de 8 KHz, es decir, la frecuencia de muestreo de la voz.
5.3.3 Microcontrolador.
Se
ha
utilizado
el
microcontrolador
Motorola
MC68HC908GP32,
cuyas
especificaciones tcnicas se pueden consultar en el apndice B. La razn de esta eleccin es,

en principio, que el mismo tiene funcionalidad elevada, ya que posee distintos mdulos para
diversas aplicaciones que permiten manejar eficazmente todos los elementos del hardware.
Este integrado posee tres contadores para generar interrupciones peridicas, conversor
105
CAPTULO V
analgico digital, puerto para interrupciones externas, modulo de comunicacin serial, y

tambin otros puertos para variedad de funciones.
Por otro lado este microcontrolador tiene la capacidad de trabajar con distintos valores
de frecuencia de bus, para este proyecto se ha configurado para trabajar con 7,3728 MHz,
debido a que esta frecuencia permite obtener mayor velocidad en el procesamiento de los
bytes de voz de forma serial (transmisin y recepcin de bits del microcontrolador al CODEC
y viceversa) y adems brinda la posibilidad de comunicarse con la computadora a una
velocidad adecuada para la transmisin de la voz en general , considerando que es una
aplicacin en tiempo real.
En secciones posteriores se describir en detalle el manejo de los mdulos antes
mencionados por parte del microcontrolador.
5.3.3.1 Manejo de Pantalla LCD.
El mdulo de visualizacin de datos, se compone como se ilustra en la figura 5.7.
Figura 5.7 Diagrama en Bloques del Mdulo de manejo de la LCD.

El microcontrolador dispone de lneas de datos para el envo de los caracteres que sern impresos en la
pantalla, y de lneas de control para el manejo de las funciones de escritura, lectura de datos, borrado, etc.
El microcontrolador genera seales de control para poder comunicarse con la pantalla

LCD y en consecuencia poder habilitarla, borrarla y enviar los datos para que sean dibujados
en la misma. Como se observa en la figura 5.7, las lneas de control y las de datos son
106
CAPTULO V
independientes. Los datos se pueden enviar por byte con lo cual se necesitara 8 pines, o bien
se pueden enviar por mitades para ahorrar 4 pines, ste ltimo es el modo se ha utilizado en
este proyecto.
5.3.3.2 Manejo de Teclado Alfanumrico.
El mdulo de teclado alfanumrico es manejado a travs del Conversor Analgico

Digital del microcontrolador, en combinacin con divisores de voltaje que permitirn
identificar la tecla oprimida en cada caso. El diagrama en bloques de este mdulo se muestra
en la figura 5.8.
Figura 5.8 Diagrama en Bloques del Mdulo de manejo del Teclado.

Los divisores de voltaje proveen de 4 voltajes fijos que permiten identificar la fila del teclado donde se ubica
la tecla presionada. La medicin de cualquiera de estos voltajes por parte del ADC, permite identificar la
columna de la tecla presionada.
Tal como se muestra en la figura 5.8, los voltajes V1, V2, V3 y V4, son los generados
por los divisores de voltaje y estn conectados a las filas del teclado matricial. Por otro lado
C1, C2 y C3 son las columnas del teclado y estn conectadas a las entradas ADC del
microcontrolador.
107
CAPTULO V
El funcionamiento es el siguiente; dado que se est manejando el teclado por los pines
del ADC del microcontrolador y no por los pines de interrupciones externas, el principio de
recepcin de las seales del teclado no puede ser asncrono. Por esta razn se tuvo que
generar una interrupcin interna sncrona lo suficientemente rpida para no dejar pasar el
pulsado de una tecla, y a partir de sta se evalan los tres canales del ADC (C1, C2, C3), y la
intercepcin entre el nmero de columna y el voltaje especfico (V1, V2, V3, V4) se logra
identificar cual tecla se ha oprimido.
Adicionalmente, para poder trabajar el teclado alfanumrico, se agregan posteriores
evaluaciones de los pines del ADC con sus respectivos retrasos, de modo que, por cada
segundo aproximadamente que el usuario mantenga presionada la tecla la las opciones entre
nmeros y letras irn cambiando progresiva y recurrentemente hasta que deje de presionarla,
cuando ste est conforme con la opcin alfanumrica, que el mdulo de visualizacin le
permitir observar, dejar de presionar, se detendr el ciclo, se guardar el dato en memoria y
se continuar todo de la misma manera para las teclas subsiguientes.
5.3.3.3 Seales de Control.

5.3.3.3.1 Mdulo de Procesamiento de Voz.
Las seales que el micro debe generar para manejar este mdulo son justamente las
seales que el CODEC necesita para recibir y enviar los datos de forma serial.
Adicionalmente, el micro debe generar dichas seales acorde se vayan procesando los datos.
Se tiene por una parte, que los datos que se reciben por el puerto serial son
direccionados por byte, por lo que se deben implementar algunas funciones lgicas que
permitan extraer o direccionar por bit esta data, para as enviarlos de forma serial a travs de
un pin del micro hasta el pin serial del CODEC.
Por otro lado, con los bits que llegan de forma serial del CODEC al microcontrolador,
se deben realizar funciones opuestas para ensamblar estos bits en bytes.
108
CAPTULO V
Las seales de control del microcontrolador son las siguientes:

FSR: Es la seal que debe estar en alto mientras que el CODEC est recibiendo del
micro los bits de un byte, y debe cambiar a bajo voltaje cuando ya se haya transmitido un byte.
DCLKR: Es la seal que debe estar el alto mientras que el CODEC est recibiendo
del micro un bit, y debe cambiar a bajo voltaje cuando ya se haya transmitido dicho bit.
FSX: Es la seal que debe estar en alto mientras que el CODEC est transmitiendo al
micro los bits de un byte, y debe cambiar a bajo voltaje cuando ya se haya transmitido un byte.
DCLKR: Es la seal que debe estar el alto mientras
que el CODEC est
transmitiendo al micro un bit, y debe cambiar a bajo voltaje cuando ya se haya transmitido
dicho bit.
Como se mencion anteriormente, estas seales deben estar sincronizadas con el reloj
del CODEC, para lo cual se aplic el mtodo antes expuesto.
5.3.3.3.2 Generador de Tonos.
El objetivo de estas seales es poder controlar la cadencia, y as generar los tonos

correspondientes a congestin, ocupado, tono de invitacin a marcar (TIM) y tono de repique.
El funcionamiento es el siguiente, la salida del circuito generador de tono es la entrada
del switche analgico, quien es activado por una seal de control del microcontrolador para
que permita o no el paso de la seal hacia la bocina. La seal de control del microcontrolador
es generada segn un contador quien dependiendo del tono habilita y deshabilita el switche en
determinados intervalos de tiempo.
109
CAPTULO V
Estos intervalos de tiempo son controlados a travs de uno de los temporizadores del
microcontrolador.
5.3.3.4 Manejo de Interrupciones externas.
En general este mdulo se pudo haber manejado directamente como un conjunto de

interrupciones externas, pero razones de licencia del software utilizado en la programacin del
microcontrolador, se tuvo que implementar un hardware adicional para manejar a travs de un
nico evento de interrupcin el pulsador ENTER y el pulsador CONFIGURACION.
Adicionalmente la interrupcin de colgado/descolgado por tener la mxima prioridad
respecto a todos los dems eventos de llamada se utiliz la interrupcin del IRQ. El diagrama
en bloques de este mdulo se presenta en la figura 5.9.
Figura 5.9 Diagrama en Bloques del Mdulo deMmanejo de Interrupciones Externas.

Las funciones de discado, configuracin y entrada de datos (enter), son manejadas por el microcontrolador
como interrupciones externas, a travs de su mdulo KBI. Por su parte, la interrupcin de colgado/descolgado (de
mxima prioridad) es manejada por la entrada IRQ del microcontrolador.
110
CAPTULO V
5.3.3.5 Manejo de la Comunicacin Serial.
Los bytes de sealizacin que llegan a la computadora a travs de una sesin TCP, y
los bytes de voz en formato PCM ley A que llegan a la computadora a travs de una sesin
UDP, al ser transmitidos al microcontrolador por el puerto serial, son indistinguibles para ste,
es decir, no existe una forma de identificar inequvocamente por parte del microcontrolador un
byte de data de uno de sealizacin. Por tal motivo, se ha acordado enviar una cadena de 15
bytes idnticos antes de enviar cada byte de sealizacin.
El byte que forma dicha cadena se ha escogido de tal forma que tenga mnimas
probabilidades de aparecer como byte de data. En otras palabras, los bytes de voz en formato
PCM ley a tienen pocas probabilidades de estar cercanos al valor 0xFF.
Partiendo de este principio se ha decidido implementar como byte de sealizacin el byte
0xFE. Adicionalmente, se disminuye an ms esta probabilidad, si enviamos 15 bytes 0xFE
seguidos, siendo menos posible obtener una data de voz que contenga una cadena completa de
15 bytes de valor 0xFE.
En todo caso, no se ha dejado de considerar en este trabajo la probabilidad mnima de
que este evento ocurra. Por ello, se ha implementado una especie de filtro tanto en el programa
cliente como en la programacin del microcontrolador, de tal forma que si en la data de voz se
presenta un caso como ste, se desechen estos datos y se contine con la data siguiente,
considerando que 15 bytes en data de voz no tienen mayor efecto en el odo humano, lo cual
finalmente, no afectara el mensaje.
Por lo antes expuesto, es necesario y ms eficiente programar la recepcin serial por
parte del microcontrolador, para que genere una interrupcin cada 16 bytes. Luego, se evalan
los primeros 15 para identificar si es data o la cadena de sealizacin y dependiendo de este
resultado, se procesa el byte 16 como sealizacin generando las acciones respectivas o se
copian los 16 bytes en el buffer de donde se tomarn los datos para enviarlos al CODEC.
111
CAPTULO V
Anlogamente, cuando se van recibiendo los datos del CODEC, se espera tener 16
bytes, se evalan los primeros 15 para ver si coinciden con la cadena de sealizacin, y
dependiendo del resultado de este anlisis, se desecha esta data o se enva el paquete de 16
bytes a la computadora por el puerto serial.
Es importante destacar que para garantizar que la aplicacin sea en tiempo real, debe
haber una velocidad de transmisin mnima. La velocidad de transmisin en el formato PCM
ley A es 64kbps, es decir que mnimo se debera transmitir de forma serial a esta velocidad.
Pero considerando el tiempo de procesamiento de los bits por parte del microcontrolador, las
interrupciones internas del mismo, la generacin de las seales de control para el CODEC,
entre otros factores, se obtiene una latencia adicional, por lo cual se ha decidido trabajar la
velocidad de transmisin serial a 115.200 baudios que, en este caso, coincide con 115.200
bkps.
5.3.4 Interfaz Serial USB.

La interfaz Serial USB CP2102 no es ms que un circuito integrado compuesto por
pocos elementos, que sirven como puente entre el bus de data serial asncrona (Asynchronous
Serial Data BUS UART) y el modo de comunicacin serial USB.
El CP2102 contiene: controlador de funciones de USB 2.0 de alta velocidad, transmisor
receptor USB, oscilador, EEPROM, y un bus de data serial asncrona. El diagrama en bloques
de esta interfaz se muestra en la figura 5.10.
112
CAPTULO V
Figura 5.10 Estructura Funcional de la Interfaz USB.
La tarjeta interfaz tiene dos posibles conexiones para la alimentacin, una de 3,3
voltios regulados, con capacidad de corriente de 100mA y una posible conexin de 5 voltios
no regulados con capacidad de corriente de 500mA. Para esta aplicacin se ha decidido utilizar
la conexin de 5 voltios no regulados para la alimentacin de todo el hardware, principalmente
porque la mayora de los dispositivos utilizados necesitan esta alimentacin y por otro lado,
porque nos ofrece un limite de consumo de corriente mayor.
Para la utilizacin de esta interfaz se procedi a la instalacin de un driver, que permite
ver la conexin USB como un puerto virtual, de esta forma se ha trabajado la comunicacin
con la computadora como una comunicacin serial sin ninguna variante.
5.4 Software.
5.4.1 Compilacin de la solucin sipXezphone para Windows.

Para la compilacin de la solucin sipXezphone se llevaron a cabo los pasos que se
describen a continuacin.
113
CAPTULO V
a) Obtencin del TortoiseSVN.

TortoiseSVN es un cliente gratuito de cdigo abierto para el sistema de control de
versiones Subversion. Maneja ficheros y directorios a lo largo del tiempo. Los ficheros se
almacenan en un repositorio central. El repositorio es prcticamente lo mismo que un servidor
de ficheros ordinario, salvo que recuerda todos los cambios que se hayan hecho a sus ficheros
y directorios. Esto permite que pueda recuperar versiones antiguas de sus ficheros y examinar
la historia de cundo y cmo cambiaron sus datos. [9]
Subversin es un sistema general que puede ser utilizado para manejar cualquier
coleccin de ficheros, incluyendo cdigo fuente.
Se obtuvo TortoiseSVN para realizar seguidamente a travs de l, la descarga del
cdigo fuente de la solucin sipXezphone.
b) Obtencin de cdigo fuente.
Se cre un directorio nuevo c:\sipfoundry en el que residiran todos los proyectos
requeridos.
Luego usando subversin, desde la consola del sistema (command prompt), se
obtuvieron las fuentes de todos los proyectos de Sipfoundry necesarios para la compilacin de
la solucin sipXezphone, a travs de la ejecucin de las siguientes lneas de comando:
cd \sipfoundry
svn checkout http://scm.sipfoundry.org/rep/sipX/main/sipXportLib sipXportLib
svn checkout http://scm.sipfoundry.org/rep/sipX/main/sipXtackLib sipXtackLib
svn checkout http://scm.sipfoundry.org/rep/sipX/main/sipXmediaLib sipXmediaLib
114
CAPTULO V
svn checkout http://scm.sipfoundry.org/rep/sipX/main/sipXmediaAdapterLib

sipXmediaAdapterLib
svn checkout http://scm.sipfoundry.org/rep/sipX/main/sipXcallLib sipXcallLib
El cdigo del
sipXezPhone
y los archivos de proyecto de Visual Studio estn
localizados en el directorio sipXcallLib\examples\sipXezPhone. Las fuentes empleadas datan

de los primeros das del mes de Septiembre de 2005.
c) Instalacin de otros softwares requeridos.
MSVC Microsoft Visual Studio.NET 2003 (o mayor).
Librera GLib2 (Low-level core library). ltima versin probada 2.4.7.
Se necesitan los siguientes paquetes de glib: glib-2.4.7.zip (glib runtime environment),
glib-dev-2.4.7.zip (glib developer package), libiconv-1.9.1.bin.woe32.zip (GNU libiconv) y
gettext-runtime-0.13.1.zip (GNU gettext runtime for Win32), los cuales se pueden obtener de
http://www.gimp.org/~tml/gimp/win32/downloads.html,
bien,
de
http://www.sipfoundry.org/pub/sipXphone/depends/win32/.
Usando una aplicacin de descompresin de archivos, se extrajeron los contenidos de
todos estos paquetes en un nuevo directorio, C:\glib.
A continuacin, se agregaron las rutas de glib al ambiente de MSVC, seleccionando
Opciones del men Herramientas, carpeta de Proyectos, Directorios de VC++, y luego
"Incluir archivos" o "Archivos de Librera" de la lista.
En "Incluir archivos", se aadi:
9 C:\glib\include\glib-2.0
115
CAPTULO V
9 C:\glib\lib\glib-2.0\include
En "Archivos de Librera", aadi:
9 C:\glib\lib
Librera PCRE (Perl Compatible Regular Expression Library). ltima versin
probada 4.4.
Se requieren los siguientes paquetes de PCRE: pcre-4.4-bin.exe (PCRE runtime
environment) y pcre-4.4-lib.exe (PCRE development package), los cuales se pueden obtener
de
http://gnuwin32.sourceforge.net/packages/pcre.htm,
bien,
de
http://www.sipfoundry.org/pub/sipXphone/depends/win32/.
Se instalaron ambos paquetes en C:\Program Files\GnuWin32. Primero el pcre-4.4-bin
y despus el otro, y se agregaron las rutas de PCRE al ambiente MSVC:
En "Incluir archivos", se aadi:
9 C:\Program Files\GnuWin32\include
En "Archivos de Librera", aadi:
9 C:\Program Files\GnuWin32\lib
Librera wxWidgets (open-source, platform independent GUI library). ltima
versin probada 2.4.2.
La librera wxWidgets se descarg de http://www.wxwidgets.org/. El setup.exe de
wxWidgets instala la librera en la carpeta \wxWindows-2.4.2.
116
CAPTULO V
Para la librera wxWidgets, hay un paso adicional despus de su instalacin: copiar el

archivo setup.h ubicado en \wxWindows-2.4.2\include\wx\msw, hacia \wxWindows2.4.2\include\wx.
Por ltimo, usando Microsoft Visual Studio.NET 2003 se abri
la solucin
C:\wxWindows-2.4.2\src\wxWindows.dsw y se compil.
d) Compilacin del cdigo C++.
Se abri la solucin sipXezPhone.sln en MSVC, se verific que sipXezPhone fuese el
proyecto principal y que las dependencias entre las libreras estuviesen ajustadas:
9 Dependencias de SipXtapi: sipXcallLib, sipXtackLib, sipXmediaLib, sipXportLib
y sipXmediaMediaProcessing.
9 Dependencias de sipXezphone: sipXtapi.
Se compil el proyecto.
e) Ajuste de Variables de Ambiente.
En la corrida, el softphone debe ser capaz de encontrar a la librera dinmica libglib2.0-o.dll y sus dependencias relacionadas. Para ello, desde la consola del sistema, se aadi:
PATH=%PATH%;c:\glib\bin.
f) Ajuste de eventos de post-generacin.
Debido a que cuando el proyecto sipXtapi se genera,
actualiza
en
C:\sipfoundry\sipXcallLib\sipXtapi\Debug
la librera sipXtapi.dll se
y
no
en
C:\sipfoundry\sipXcallLib\examples\sipXezPhone\Debug para que est disponible para el
117
CAPTULO V
sipXezPhone, se agreg una directiva en las propiedades del proyecto sipXtapi Eventos de
generacin Evento posterior de generacin Lnea de comandos:
COPY $(OutDir)\sipxtapid.* $(SolutionDir)\$(ConfigurationName)
De esta forma, cada vez que se compila y genera de nuevo el proyecto sipXtapi, se
actualiza la sipXtapi.dll en la carpeta Debug del sipXezPhone.
5.4.2 Simplificacin de funciones de la solucin sipXezphone.

Una vez compilada la solucin sipXezphone, se procedi al estudio detallado de su
estructura: clases principales, funciones de sealizacin, funciones de manejo de datos de voz,
funciones de registro con el servidor SIP, etc., con el fin de definir cules cambios eran
necesarios, qu clases agregar, cules clases no eran de inters, dnde deban ser
interceptados los datos de sealizacin, etc.
Para ello, se llev a cabo una simplificacin del cdigo, descartando progresivamente:
Funciones de video, verificando que las funciones de sealizacin y audio permanecieran
intactas.
Funciones de conferencia, dejando intactas las funciones de audio y sealizacin.
Funciones de micrfono, verificando que las funciones de sealizacin no resultaran
alteradas.
Funciones de audfono (speaker), manteniendo sin cambios las funciones de sealizacin.
Funciones de codificacin y decodificacin de audio diferentes a PCM Ley A. Dado que se
pretenda implementar, a travs del hardware del prototipo de telfono IP, la codificacin y
decodificacin de la voz por PCM Ley A, se forz en el cdigo que slo se empleara este
algoritmo (el cual, ms tarde, sera tambin dedicado slo al etiquetamiento de los paquetes).
118
CAPTULO V
Por otra parte, motivado a que el inters principal era conservar las funciones de
sealizacin SIP de la solucin sipXezphone, se realizaron modificaciones importantes en el
proyecto sipXmediaLib, el encargado del procesamiento de la voz. La figura 5.11 muestra un
diagrama en bloques general del proyecto sipXmediaLib modificado.
Figura 5.11 Diagrama en Bloques General de sipXmediaLib modificado.

Dado que el procesamiento de la voz se realizara por hardware, sipXmediaLib fue modificado
significativamente.
En primer lugar, se deshabilit la creacin de todos los recursos de la clase Media Task
(from mic, mux, etc.). En la clase Connection, por otro lado, se aadieron los recursos Desde
micrfono (from mic) y Hacia Audfono (to speaker), los cuales pertenecan a Media Task.
Esto ltimo con el fin de aprovechar el manejo de las colas de mensajes que se llevan a cabo
en estos recursos.
En segundo lugar, fue aadida la clase Puerto Serial para el manejo del puerto de
comunicacin serial de la computadora. Esto se detallar en la seccin 5.3.3.
En tercer lugar, se modificaron las hebras de micrfono y audfono. Esto se describir
en la seccin 5.3.5.
119
CAPTULO V
Adicionalmente, se hicieron simplificaciones a nivel de la interfaz grfica. Dado que se

pretenda hacer del softphone un servicio y adems las funciones de discado, colgar/descolgar
y configuracin seran implementadas en hardware, no se requera dicha interfaz grfica. Sin
embargo, se conserv una muy sencilla para la realizacin de pruebas.
La figura 5.12, a la derecha, muestra la interfaz grfica simplificada; a la izquierda la
interfaz original.
Figura 5.12 Modificaciones en la Interfaz Grfica del sipXezphone.

Se conservaron solamente los botones de discado, colgado/descolgado y men de configuracin (settings)
para la realizacin de pruebas.
5.4.3 Creacin Clase Puerto Serial.

Debido a que exista el requisito imperativo de que el hardware del prototipo de
telfono IP se comunicara con la aplicacin cliente (softphone), se tuvo la necesidad de
implementar una clase serial para el manejo del puerto serial de comunicacin de la
computadora.
Esta clase serial est encargada de las funciones de apertura y cierre del puerto serial,
de la configuracin de los parmetros de comunicacin del puerto (velocidad, nmero de bits,
paridad, bit de parada, etc.) y del manejo de la recepcin y transmisin de bytes.
120
CAPTULO V
Para llevar a cabo estas tareas, la clase de puerto serial contiene una serie de funciones
y, en particular, una hebra que tiene a su cargo, el manejo de tres eventos principales: Lectura,
Escritura y Cierre de puerto.
Las funciones ms importantes, implementadas dentro de esta clase, son:
RecibirCar(CSerialPort* port, LPCOMSTAT comstat) para la recepcin de bytes y,
EnviarBloqueCar(CSerialPort *port) para el envo de un bloque de bytes.
5.4.3.1 Instanciacin de la clase.
La solucin sipXezphone, como se mencion previamente, tiene una dependencia: el

proyecto sipXtapi, el cual a su vez tiene dependencias, que son los dems proyectos incluidos
en la solucin sipXezphone.
La diferencia entres estas dependencias, es que los proyectos que son dependencias de
sipXtapi (sipXcallib, sipXtacklib, sipXmedialib, sipXportlib y sipXmediaAdapterLib), se
enlazan estticamente con dicha librera. En cambio, sipXtapi es una librera dinmica usada
por sipXezphone. Esto hecho limita la capacidad de realizar invocaciones directas, de acceso a
variables y de traspaso de parmetros desde cualquiera de las libreras que contiene sipXtapi
hacia el proyecto principal sipXezphone.
Por otra parte, dado que el manejo de los arreglos de datos de voz (buffers de audio) se
ejecuta en el proyecto sipXmedialib, exista una probabilidad muy alta de que se necesitara
acceder desde sipXmedialib a las funciones relacionadas con el manejo del puerto de
comunicacin serial, a travs del cual se transmitiran y recibiran los datos de voz.
Tomando en cuenta estas consideraciones, se decidi que lo ms apropiado era realizar
la instanciacin de la clase de puerto serial CSerialPort, dentro del proyecto sipXmediaLib, de
forma tal que, no existieran problemas de traspaso de informacin entre stos. As, en el
archivo dmaTaskWnt.cpp del proyecto sipXmediaLib, se configuran los parmetros de
comunicacin del puerto y se hace la apertura del mismo.
121
CAPTULO V
5.4.3.2 Rutina de recepcin y revisin de caracteres recibidos.
Este es el corazn de la clase puerto serial CSerialPort. Ejecuta en primer lugar, la

funcin de recepcin de caracteres RecibirCar(CSerialPort* port, LPCOMSTAT comstat) y
luego, lleva a cabo la distincin entre datos de sealizacin y de voz.
5.4.3.2.1 Sealizacin.
Debido a que la transmisin de datos por parte del microcontrolador es de byte en byte,
se ha establecido un protocolo de comunicacin entre ste y la computadora, con el fin de
discernir cules datos corresponden a sealizacin y cules a datos. De acuerdo a dicho
protocolo, antes de enviar un byte de sealizacin a la computadora, deber enviarse una
cadena de 16 bytes de valor 0xFE.
La funcin de recepcin entonces, recibe byte por byte, y si uno de los bytes es igual a
0xFE, se incrementa un contador cuyo valor se revisar al entrar la vez siguiente a la rutina. Si
el valor del contador llega a ser igual a 16, se tomar el byte siguiente (el byte 17) como byte
de sealizacin y dependiendo su valor se ejecutar una accin especfica.
Dado que algunas acciones a tomar en caso de sealizacin requieren el acceso e
invocacin de ciertas funciones del proyecto principal, a las que no se tiene acceso desde el
proyecto sipXmediaLib (donde est la clase de puerto serial), lo que se hace es enviar
mensajes a una hebra ubicada en el proyecto principal sipXezphone, la cual ha sido creada con
la finalidad de establecer un enlace desde sipXtapi y cualquiera de los proyectos contenidos en
ella, hacia el proyecto principal. Esta hebra se llama FromCom.
Los datos de sealizacin incluyen: colgado y descolgado, discar, inicio de envo de
nmero a discar, nmero telefnico a discar, inicio y fin de parmetros de configuracin,
parmetros de configuracin del telfono, solicitud de registro.
122
CAPTULO V
5.4.3.2.2 Datos de voz.
Una vez distinguido un dato de voz, es almacenado en los arreglos de datos de voz
(buffers de audio), y cuando stos estn completamente llenos, se enva un mensaje al hilo del
micrfono con el apuntador al buffer que est listo para ser procesado.
5.4.3.3 Redireccionamiento de la adquisicin de datos de sealizacin desde el puerto serial al

proyecto principal.
Para redireccionar los datos de sealizacin correspondientes al nmero a discar y a los

datos de configuracin, se emplea el mecanismo de mensajes a la hebra FromCom ubicada en
el proyecto principal, por las razones expuestas en las secciones anteriores a sta.
Estos mensajes contienen, en uno de sus parmetros, el apuntador al arreglo en el cual
fueron recopilados los datos de sealizacin en la recepcin de puerto serial. Se extraen los
datos usando el apuntador, y se les da el formato que requieren para poder ser pasados como
parmetros a las funciones de discado y de configuracin.
Por ejemplo, una vez obtenido en la recepcin de puerto serial el nmero a discar, a
ste debe hacrsele una conversin de tipo (casting), agregrsele el prefijo sip: y
concatenarle al final el @grupo de trabajo y seguidamente invocar la funcin que provoca la
transicin en la mquina de estados del telfono (softphone).
5.4.4 Redireccionamiento de la sealizacin proveniente de Asterisk al hardphone a travs del

puerto serial.
El proyecto sipXtapi usa los eventos para comunicar las transiciones de estado del
telfono a la capa de la aplicacin. Dado que muchas de las llamadas de sipXtapi son
asncronas, las notificaciones de eventos deben estar siendo revisadas siempre para ambas
123
CAPTULO V
operaciones, tanto para el establecimiento de una llamada como para la desconexin de un

softphone remoto.
La sealizacin que proviene de la central IP Asterisk, es desviada al proyecto
principal, a travs del mismo mecanismo de envo de mensajes a la hebra FromCom.
Posteriormente, esta sealizacin es enviada a una hebra denominada ToCom_Write
que est ubicada en el proyecto sipXmediaLib, la cual fue creada con la finalidad realizar las
funciones de carga del arreglo o buffer de transmisin de puerto serial con los datos a ser
transmitidos, y de disparar el evento de escritura de puerto serial. A esta hebra van todos los
mensajes que quieran enviar datos va serial al hardphone.
5.4.5 Redireccionamiento de las invocaciones de los hilos de micrfono y audfono a las

funciones de recepcin y envo de los datos de voz por el puerto serial.
Debido a que las funciones de procesamiento de la voz se pretendan hacer por

hardware, era necesario introducir modificaciones en el manejo de los arreglos de datos de voz
y en el flujo de los mismos.
Los hilos de micrfono y audfono, MicThread y SpkrThread respectivamente, fueron
modificados de manera tal que no entregaran los arreglos de voz manipulados por ellos, a
ningn dispositivo de audio (micrfono o cornetas) sino a la clase de puerto serial, para as
poder desviarlos hacia el hardphone. Para esto se deshabilitaron funciones de apertura y cierre
de dispositivos de audio (micrfono y cornetas).
El hilo de micrfono MicThread, al recibir el mensaje desde puerto serial con la
informacin del apuntador del buffer listo a ser procesado, toma este apuntador y lo coloca en
la cola de micrfono pMicQ que alimenta al recurso Desde micrfono (From Mic) que est
dentro de la clase Connection, ver figura 2.41.
124
CAPTULO V
Una vez encolados, el bloque Desde micrfono (From Mic) los va sacando de la cola
y los va transfiriendo al bloque siguiente, el de codificacin, en el cual se hace un traspaso de
los datos sin modificacin al bloque Hacia la Red (To Net), debido a que la rutina de
codificacin slo coloca los encabezados que marcan al paquete de datos de voz como un
paquete PCM A, de modo que puedan ser reconocidos por la central IP Asterisk como
paquetes de voz.
Por su parte, el hilo de audfono SpkrThread se alimenta de la cola pSpkQ que ha sido
llenada por el bloque Hacia audfono (To spkr). Previamente, el bloque decodificador les ha
eliminado el encabezado. El hilo de audfono SpkrThread toma los datos de la pSpkQ y los
enva a puerto serial para que sean decodificados por hardware y reproducidos.
CAPTULO VI
CAPTULO VI. RESULTADOS Y DISCUSIONES.

6.1 Resultados Parciales en Hardware.
El principal reto por parte del hardware era alcanzar un procesamiento concurrente de
todas las funciones que llevaba a cabo el microcontrolador, para el manejo y supervisin de
todos sus mdulos.
Se tuvo especial cuidado en el manejo de interrupciones para el logro de la
concurrencia entre los procesos y los niveles de prioridad de las mismas.
6.1.1 Resultados del mdulo de Generador de Tonos.
Con el diseo inicial del circuito generador de tonos, se obtuvo una onda sinusoidal de
unos 410 Hz aproximadamente. Dado que se deseaba cumplir con la Norma Europea (ver
figura 2.6), se realizaron ajustes en los valores de resistencia, obteniendo los 425 Hz
especificados por dicha norma. Este ajuste permiti percibir de forma audible una similitud
con el tono de invitacin a marcar de los telfonos convencionales.
Por otro lado, se realizaron ajustes de amplitud de la onda sinusoidal, para as evitar el
ruido en los lapsos de cadencia (tiempos de silencio) de los tonos de sealizacin.
6.1.2 Resultados del mdulo de Procesamiento de Voz.
Para la puesta en marcha del CODEC, se requeran diversas seales de control y
sincronizacin.
En primer lugar, se obtuvo la seal de reloj maestro a travs del oscilador, y las seales
de tiempo y sincronizacin restantes a travs del microcontrolador, de acuerdo a los
requerimientos establecidos en las especificaciones del CODEC.
126
CAPTULO VI
Las seales de control generadas por el microcontrolador, en principio, no cumplan

con los requerimientos de tiempo del CODEC, especficamente, el tiempo de transmisin por
bit era de 18s lo que daba un tiempo de transmisin por byte, mayor a 125s que es el
mximo especificado. Para solucionar este problema, se realizaron cambios en las funciones
de transmisin y recepcin de datos por parte del microcontrolador.
Anteriormente, se reciba una interrupcin de un temporizador a partir de la cual se
realizaba el procedimiento para direccionar un bit de datos y enviarlo por un pin del
microcontrolador. Luego, en el programa principal, una vez fuera de la interrupcin, se
realizaba un procedimiento anlogo para recibir y direccionar en memoria un bit de datos.
Posteriormente, se program el microcontrolador de forma tal que en la misma
interrupcin del temporizador, se hiciera el procedimiento para recibir y enviar 16 bytes de
datos, optimizando as, los procesamientos para direccionar por bits y el envo de paquetes de
datos ms grandes por cada interrupcin. De esta manera, se reduce tambin el tiempo de
transmisin por bit y, en consecuencia, el tiempo de transmisin por byte cumpliendo as con
las especificaciones del CODEC.
Al tener la certeza de que todas las seales de control podan ser originadas y
sincronizadas con el reloj maestro, se procedi a realizar una prueba, en la cual desde la
computadora, se enviaba al microcontrolador de forma controlada un flujo de datos conocidos
y desde ste, se generaban las seales de control y se enviaban los datos al CODEC conforme
a ellas.
En la figura 6.1 se muestra la seal FSR como un pulso que tiene la misma duracin en
tiempo que los ocho bits de datos. Se introdujeron bytes de valor 0xAA en la entrada digital
del CODEC, Din, de modo que la seal de datos fuera un tren de pulsos simtrico.
127
CAPTULO VI
Figura 6.1 FSR vs Din, 20s/div.

Arriba se muestra la seal FSR. Abajo la seal de entrada del CODEC, Din. Ntese que los ocho bits
suceden dentro de la ventana de tiempo proporcionada por FSR.
A partir de esta figura se puede verificar que se cumple la especificacin del CODEC,
en cuanto a enviar los bits correspondientes a un byte dentro de una ventana FSR. Tambin se
puede apreciar que los bits de datos que se enviaron desde la computadora no fueron alterados,
ya que se logra distinguir la secuencia de pulsos en la seal correspondiente a la data.
Ntese que, adicionalmente, la ventana de tiempo FSR es de aproximadamente 80s
cuando debe ser como mximo de 125s, segn las especificaciones del CODEC.
En la figura 6.2 se muestran ocho pulsos de la seal DCLKR dentro de un pulso FSR,
lo cual certifica que dentro de este ltimo existen ocho seales de reloj que permitirn enviar
los ocho bits de datos. Adicionalmente, en la figura 6.3 se muestra cmo se generan los ocho
pulsos de la seal DCLKR posteriores a la estabilizacin del valor del bit de dato en el pin de
salida.
128
CAPTULO VI
Figura 6.2 FSR vs DCLKR, 20 s/div.

Arriba se muestra la seal FSR. Abajo la seal para la transmisin de cada DCLKR. Se puede verificar que
existen ocho seales de transmisin de bit dentro de un pulso de FSR.
Figura 6.3 Din vs DCLKR, 5s/div.

En la parte superior, se muestra el tren de pulsos correspondiente a los datos, y la parte inferior los pulsos
correspondientes a la transmisin de cada bit de data. Ntese que el pulso se genera posterior a la estabilizacin
del valor de la data.
Al tener estos resultados, se procedi a realizar las pruebas con el circuito de interfaz
de audfono, enviando no una data conocida como en el caso anterior, sino los bytes
correspondientes a un archivo de audio en formato PCM Ley A (obtenido del grabador de
sonidos de windows). Se pudo apreciar que el tiempo en que el sonido era
percibido,
corresponda al tiempo de duracin del archivo de audio, sin embargo, el sonido era inteligible
un 30% aproximadamente.
129
CAPTULO VI
Como consecuencia de este resultado, se estudi ms a fondo las seales de control y

de datos, lo cual permiti percibir que a corto plazo s se cumplan con los requerimientos,
pero a largo plazo surgan espacios de tiempo sin flujo de datos. Estos huecos o espacios de
tiempo vacos superaban el tiempo correspondiente a cinco veces la ventana de transmisin
por byte, FSR, ocasionando que el dispositivo entrara en modo standby, es decir, que los pines
de entrada y salida de datos (digital) estn activos pero no son cargados los datos en estos.
En la figura 6.4, a la izquierda, se observan (al inicio) pulsos de FSR en los que se
envan los bytes de datos y luego la ausencia de dichos pulsos por un tiempo de
aproximadamente 3,5 ms, tal y como se muestra a la derecha de esta misma figura.
Figura 6.4 FSR 0,2 ms/div. FSR 0, 5ms/div.

Ntese la ausencia de los pulsos FSR por un tiempo mayor a cinco veces el tiempo de duracin de la ventana
de transmisin de un byte, por lo cual, el CODEC entra en modo standby.
Anlogamente, en la figura 6.5 se muestra el flujo de datos, tambin con ausencia de

datos en un intervalo de tiempo igual que el de la figura anterior.
Figura 6.5 Din 0,2 ms/div. Din 0, 5ms/div.
130
CAPTULO VI
Motivado a estos resultados, se procedi al diseo de otro circuito que proporcionara

un flujo de datos continuo a la entrada del CODEC, haciendo que la entrada digital del
CODEC fuera alimentada por la salida digital del mismo. Se implement tambin una serie de
compuertas, relojes y registros para la generacin de las seales de control en congruencia con
el flujo de datos. Este circuito est detallado en el apndice A.
En la figura 6.6 se muestran las seales Din (en la parte superior) y DCLKR negado
(en la parte inferior). Ntese que puede observarse un flujo continuo de bytes, espaciados entre
s por un tiempo menor de 125s.
Figura 6.6 Din vs DCLKR negado, 50s/div.

En la parte superior, se muestra el flujo de datos continuo, y la parte inferior los pulsos del DCLKR negado.
Dadas estas condiciones, se procedi a realizar las pruebas generando datos digitales
de entrada por el uso del micrfono, esperando escuchar en el audfono el eco de esta seal de
audio. Se poda apreciar que se reciban datos en la entrada digital del CODEC al mismo
tiempo que se originaba audio por el micrfono. Sin embargo, en la salida de audio no se
obtuvieron mejores resultados que los obtenidos en la prueba anterior.
Dado que se ha cumplido con los requerimientos expuestos en las especificaciones del
CODEC, y no obstante, no se obtuvieron los resultados deseados, se tuvo la necesidad de
hacer pruebas ms concretas para verificar el estado del dispositivo en uso.
131
CAPTULO VI
Entre stas:
Colocar el dispositivo en modo silencio (mute), para lo cual las especificaciones sealan que
la salida digital de audio debera ser cero y no lo era, sino que era un tren de pulsos.
Se llev el pin de entrada de datos digitales a cero y la salida tampoco se iba a cero.
Se realizaron las mismas pruebas con otro CODEC y la salida se iba a alta impedancia, lo
cual arroja discrepancias entre los resultados de las mismas pruebas con dispositivos distintos.
6.1.3 Resultados del mdulo de Manejo de Pantalla LCD.
Los resultados del manejo de pantalla fueron casi inmediatos. Debido a que no se
contaba con licencia completa del software de programacin del microcontrolador para el uso
de las aplicaciones de pantalla, fue necesaria la implementacin de rutinas en lenguaje C para
el manejo de la misma.
Las funciones de direccionamiento de los caracteres a imprimir en la pantalla y el
control de las funciones de escritura, lectura de datos y borrado de sta a travs del
microcontrolador, se logr sin mayores inconvenientes. Slo se tuvieron que realizar ajustes
en cuanto a las posiciones virtuales de la pantalla, debido a que en ocasiones no se lograban
visualizar algunos caracteres; y tener muy en cuenta los tiempos de estabilizacin de sta
inmediatamente despus de recibir una instruccin de control.
6.1.4 Resultados del mdulo de Manejo de Teclado Alfanumrico.
Debido a que el manejo del teclado no iba a ser llevado a cabo de forma asncrona, con
el uso de interrupciones externas al microcontrolador, fueron necesarios ajustes de tiermpo
entre las mediciones peridicas efectuadas por el ADC y el procesamiento de dichas lecturas.
132
CAPTULO VI
Adicionalmente, se verific que en cada entrada del ADC correspondiente a cada

columna (ver figura 2.38), se obtuvieran valores de voltaje bien diferenciados y espaciados
para cada tecla de la misma columna. En este paso, se presentaron inconvenientes en cuanto al
espaciamiento mencionado debido a que se generaba el voltaje esperado en la columna
correspodiente a la tecla presionada, pero adems se generaban voltajes parsitos o ruido en
las columnas restantes.
Para solucionar este problema, se llevaron a cabo ajustes en los tamaos de las
ventanas de voltaje y en el plano de tierra del circuito. Seguidamente, se procedi a imprimir
en la pantalla los caracteres numricos correspondientes.
Una vez implementado el teclado numrico, se procedi a aadir la introduccin de
caracteres alfanumricos a travs de la manipulacin de temporizadores del microcontrolador.
En este punto, el problema que se present es que si se presionaba la tecla en un tiempo mayor
al tiempo promedio (hasta un segundo, aproximadamente), el teclado entraba automticamente
en modo alfanumrico, por lo cual no estaba preparado para recibir inmediantamente, el
siguiente caracter. A la vista del usuario, esto resultaba como un retardo en el tiempo de
respuesta del teclado.
No obstante, si se presionaban las teclas dentro del tiempo promedio, la respuesta del
teclado era inmediata, y si sta permaneca presionada le permita al usuario recorrer todas las
opciones de caracteres de forma cclica, hasta encontrar la opcin deseada. En caso de que el
usuario se equivocara al momento de introducir un caracter, a travs de la tecla numeral (#) le
es permitido borrar las opciones que desee de la pantalla y del arreglo donde estn siendo
almacenada la informacin. De este proceso se obtienen los resultados deseados.
6.1.5 Resultados del mdulo de Manejo de Interrupciones externas.
Pese a que las interrupciones externas tuvieron que ser manejadas a travs de un solo
pin de interrupcin, debido a los problemas de licencia del software de programacin del
microcontrolador ya mencionados. Slo tuvo que prestarse atencin al hecho de colocar un 1
133
CAPTULO VI
lgico en el pin de interrupcin mientras no se estuviera presionando ningn botn, para

garantizar que no se generaran falsas interrupciones.
Este mdulo origin los resultados esperados:
9 No se originan interrupciones indeseadas.
9 Se distingue el tipo de interrupcin originada.
9 Son captadas por el microcontrolador de forma inmediata.
6.1.6 Resultados del mdulo de Manejo de la Comunicacin Serial.
La interfaz de comunicacin serial-usb tuvo un comportamiento ptimo. Adems de
ofrecer distintos valores de velocidad de comunicacin, algunos de ellos en concordancia con
los ofrecidos por parte del microcontrolador, fue posible manejar dicha interfaz, sin mayores
esfuerzos, como un puerto serial virtual. Adicionalmente, se logr satisfacer el consumo de
energa de toda la circuitera del hardohone a travs de la alimentacin proporcionada por esta
interfaz serial-USB.
Sin embargo, fue necesario hacer ajustes en el manejo del flujo de datos de
comunicacin serial del microcontrolador, en particular de los tiempos entre la transmisin y
recepcin de cada paquete, debido a que el microcontrolador no dispone de capacidad de
almacenamiento de los datos a ser transmitidos o recibidos, lo que poda ocasionar prdida de
informacin.
6.2 Resultados Parciales en Software.
Es importante destacar que debido a que la solucin sipXezphone est conformada por
varios proyectos, los cuales a su vez contienen mltiples archivos relacionados entre s, todos
desarrollados bajo un lenguaje orientado a objetos, tanto la comprensin como la corrida en
fro de sta present un alto grado de dificultad. Esto a consecuencia de que no se dominaba
este ambiente de programacin, es decir, no se contaba con las herramientas necesarias para
134
CAPTULO VI
entender a profundidad el cdigo y as poder realizar una emulacin del mismo adaptada a las
caractersticas particulares de este proyecto de grado.
No obstante esta dificultad, aunada a la insuficiente documentacin existente sobre esta
solucin, al cabo de varias semanas se logr identificar los mdulos de inters y las
modificaciones que eran posibles introducir de acuerdo a las necesidades planteadas.
Posteriormente, de forma progresiva, se fue adquiriendo mayor habilidad en la introduccin de
cambios de rigor en el cdigo fuente.
6.2.1 Instalacin de la central IP y softphones de prueba.
Estas instalaciones, adems de que resultaron ser sencillas, fueron operativas en muy
poco tiempo.
La primera instalacin de la central IP Asterisk, estuvo en prueba por dos meses y
funcion correctamente, excepto porque en el registro de eventos (logs) se not que en varias
ocasiones se haba apagado por lapsos de tiempo. Sin embargo, esto sucedi porque la central
tena habilitada una funcin de ahorro de energa que forzaba al equipo a un estado de bajo
consumo. Una vez deshabilitada dicha funcin el comportamiento de la central era ptimo.
Las dos versiones siguientes que fueron instaladas, estuvieron en prueba dos semanas
la segunda, y el tiempo restante la tercera. De ambas instalaciones se obtuvieron
comportamientos deseables.
Por su parte, las pruebas con los softphones fueron exitosas en el estableciendo de
llamadas salientes, entrantes, sealizacin, etc. Estos resultados hicieron un gran aporte en lo
que respecta a la comprensin de las funciones que deben realizar estos componentes de la
comunicacin digital. Con la ayuda de stos, y el empleo de un programa analizador de
paquetes, se pudo verificar el tipo de los paquetes de datos que circulan entre un softphone y la
central Asterisk, as como la estructura y contenidos de los paquetes, en particular de los
paquetes SIP.
135
CAPTULO VI
La figura 6.7 muestra un ejemplo de captura de paquetes a travs del programa

analizador de paquetes Ethereal, entre un softphone y la central IP durante el registro y la
primera etapa de la llamada (establecimiento).
Figura 6.7 Intercambio de paquetes entre un softphone y la central IP.

Se muestra el intercambio de paquetes entre un softphone y la central IP durante el registro y establecimiento
de una llamada. Ntese en la columna llamada Protocol el tipo de paquetes intrcambiados.
6.2.2 Compilacin de la solucin sipXezphone para Windows.

Se generaron algunas dificultades en la compilacin de la solucin sipXezphone bajo el
ambiente Windows.
En primer lugar, la falta de uno de los proyectos requeridos para la solucin, el
proyecto sipXmediaAdapterLib. Para solventar este problema, se solicit a Sipfoundry su
publicacin, la cual se realiz semanas despus. Luego, se procedi a su compilacin y
correcin de algunos errores a travs de la inclusin de libreras y ajustes en las conversiones
de tipos de variables.
Una vez compilado el softphone, se ejecutaron pruebas y se encontr que ste realizaba
las funciones de sealizacin correctamente pero haba problemas con el audio. Para solventar
este inconveniente:
136
CAPTULO VI
Se coment la lnea de instruccin #def DOING_ECHO_SUPPRESSION en el archivo

MpCallFlowGraph.cpp del proyecto sipXmediaLib. Esto debido a que las funciones de
supresin de eco no estaban soportadas completamente en el softphone cuyas fuentes datan de
los primeros das del mes de Septiembre de 2005.
Se solucion por libreras dinmicas de igual nombre, debido a la existencia de una copia de
la original en el mismo equipo, que generaba conflicto en el momento de la corrida del
programa.
Una vez compilado el softphone, se requiri comentar tambin #define
SIPXTAPI_EVAL_EXPIRATION en el archivo sipXtapiInternal.h, del proyecto sipXtapi,
que le daba fecha de expiracin al cdigo, lo cual, deshabilitaba todas las funciones del
softphone.
6.2.3 Simplificacin de Funciones de la Solucin sipXezphone.
Conforme se fueron simplificando funciones, se fue verificando el desempeo del
softphone en cuanto al manejo de la sealizacin entre ste y la central IP.
Finalmente, se logr identificar de forma precisa los aspectos que deban tomarse en
consideracin para la aplicacin cliente de este proyecto, y aquellos de los cuales poda
prescindirse.
En esta etapa, los resultados parciales fueron los siguientes:
Al descartar las funciones de micrfono, verificando que las funciones de sealizacin no
resultaran alteradas, se obtuvo que, cuando se estableca una llamada, en el otro softphone no
se tena audio del softphone modificado.
137
CAPTULO VI
Al descartar las funciones de audfono (speaker), manteniendo sin cambios las funciones de
sealizacin, se obtuvo que, cuando se estableca una llamada, en el otro softphone no se tena
audio del softphone modificado, y en este ltimo no se tena audio del primero tampoco.
Lo expuesto en la seccin 5.4.5, se pudo verificar en la corrida en fro del cdigo, tal que los
paquetes de voz eran transferidos de una etapa a la siguiente, sin ser alterados los datos de voz
provenientes del hardphone, slo siendo etiquetados de la manera esperada (como paquetes de
tipo PCM Ley A).
6.2.4 Clase Puerto Serial.
Con respecto a la clase de puerto serial se verificaron los siguientes aspectos:
La apertura del puerto: se comprob abriendo otra aplicacin de comunicacin que usa el
puerto serial (hiperterminal), obteniendo que sta lo reportaba en uso.
La habilitacin de la hebra de puerto serial: se comprob mediante la corrida en fro del
programa, obteniendo que el identificador y manejador de dicho hilo fuera distinto de cero
(nulo).
La rutina de recepcin y revisin de caracteres recibidos: a travs de la transmisin de
caracteres por puerto serial por parte del microcontrolador, se verific que se recibieran los
caracteres enviados y que stos fueran procesados de forma distinta dependiendo de si se
trataba de un caracter de sealizacin o dato de voz.
Transmisin de datos de sealizacin y voz por puerto serial: a travs de hiperterminal se
verific el envo correcto de los datos por parte de la rutina de escritura en puerto serial.
Redireccionamiento de la invocacin del hilo de micrfono a la funcin de recepcin por
puerto serial: a travs de la corrida en fro del cdigo y del uso de hiperterminal para la
introduccin de datos por puerto serial, se verific que la rutina de recepcin de caracteres va
138
CAPTULO VI
llenando los buffers que emplea el hilo de micrfono, este ltimo inserta los paquetes en la
cola pMicQ y este paquete sigue la trayectoria desde el recurso Desde Micrfono (From
Mic) hasta la central IP (ver figura 5.11).
Redireccionamiento de la invocacin del hilo de audfono a la funcin de envo de los datos
de voz por el puerto serial: a travs de la corrida en fro del cdigo, se hizo seguimiento de un
grupo de paquetes de voz (identificados por su contenido) desde que fueron sacados de la cola
pSpkQ hasta que fueron recopilados en los buffers que se envan al hardphone por el puerto
serial.
6.2.5 Comunicacin entre hebras ToCom_Write y FromCom.

La existencia de estos hilos se verific en la corrida en fro del programa observando
que los manejadores (handles) e identificadores fueran distintos de cero (nulo). Se verific
tambin que los mensajes que ellos se envan entre s (para ser puentes entre los proyectos
sipXmediaLib y sipXtapi con el proyecto principal sipXezphone) llegaran con xito, a travs
de puntos de ruptura en stos casos y que adems se tomaran las acciones deseadas de acuerdo
a cada mensaje.
6.3 Integracin y pruebas.
Al realizar la integracin entre la aplicacin cliente y el hardphone fue necesario

realizar ajustes en los tiempos de envo de los datos de sealizacin y del nmero de veces de
envo de dichos datos, a modo de garantizar que fueran recibidos y procesados por parte del
microcontrolador.
Una vez recibidos estos datos en el microcontrolador, se tomaban decisiones y se
generaban diversas acciones, como por ejemplo: mensajes de pantalla, habilitacin de los
tonos, habilitacin de seales de control del CODEC, manipulacin de los datos en el caso en
que se recibieran bytes de voz.
139
CAPTULO VI
De igual manera en el envo de datos del microcontrolador hacia el programa cliente,

se tuvo que tomar en cuenta la generacin de interrupciones internas del microcontrolador, a
fin de garantizar que dicho procesamiento se llevara a cabo de forma exitosa.
Se realizaron varias pruebas, de las que se obtuvieron resultados satisfactorios,
principalmente en la recepcin, envo e interpretacin de la sealizacin, tanto por el
microcontrolador como por el programa cliente. A continuacin se describen algunos ejemplos
correspondientes a las pruebas realizadas.
Ejemplo 1: Establecimiento de llamada saliente.
Se descolgaba el telfono a travs del botn y si el hardphone estaba registrado, se
generaba el tono de invitacin a marcar y apareca el mensaje de pantalla Marque el nmero.
En caso contrario, se esperaba el registro (con un mensaje Espere registro en la LCD) para
dar el tono de invitacin a marcar.
Luego, se introduca por teclado el nmero de la extensin a la cual se quera llamar y
se presionaba la tecla enter. Inmediatamente apareca tanto en la interfaz del programa
cliente como en la pantalla LCD del hardware el mensaje Llamando tal como lo ilustran
las figura 6.8 y 6.9 respectivamente.
Figura 6.8 Mensajes de Llamada saliente (dialing) en softphone.

140
CAPTULO VI
Figura 6.9 Mensajes de Llamada saliente en hardphone.

Al cabo de unos segundos, en el softphone de destino apareca la sealizacin de

llamada entrante o repique mientras que el hardphone imprima en pantalla el mensaje
repicando y generaba el tono de repique; y al contestar la llamada, en la aplicacin cliente
origen, en el softphone destino y en la pantalla del hardphone se genera el mensaje de
sealizacin Conectado, como lo muestran las figuras 6.10 y 6.11 respectivamente.
Finalmente, al hacer la desconexin de la llamada, tanto en el lado origen como destino se
visualizaba el mensaje de desconexin.
Figura 6.10 Mensaje de Conexin de Llamada en softphone.

En la parte superior, se observa en el mensaje Connected o conectado, el cual muestra el softphone al
momento de ser aceptada la llamada saliente en el destino.
141
CAPTULO VI
Figura 6.11 Mensaje de Conexin de Llamada en hardphone.

El hardphone confirma el establecimiento de la conexin al momento en que la llamada saliente ha sido
aceptada en el destino.
Ejemplo 2: Llamada entrante.

Al ser discado el nmero de la extensin desde el softphone de origen, se visualizaba
un momento despus en la aplicacin y en la pantalla del hardphone, el mensaje de
sealizacin Llamada entrante, y al descolgar por medio del botn, se generaba el
mensaje Conectado en la pantalla LCD, en la aplicacin y en el spftphone de origen. Para
la desconexin, el comportamiento es similar al descrito en el ejemplo 1.
Ejemplo 3: Desconexin de cable de red.
Desconectando el cable de red, tanto la aplicacin cliente como el hardphone pierden
conexin con la central IP. El hardphone muestra por pantalla el mensaje Falla de red como
se ilustra en la figura 6.12.
Figura 6.12 Mensajes de Falla de Red.

En caso de falla de red, debido a desconexin del cable o ausencia de red, el hardphone lo notifica a travs de
la pantalla de cristal lquido.
142
CAPTULO VI
Ejemplo 4. Softphone de destino ocupado.

Cuando se discaba una extensin de destino y ste estaba descolgado, se mostraba un
mensaje Ocupado tanto en la aplicacin como en la pantalla del hardphone y adems se
generaba el tono correspondiente a este evento.
Ejemplo 5. Configuracin del telfono.
Presionando la tecla Conf se entraba al men de configuracin, el cual iba mostrando
progresivamente en pantalla, los mensajes correspondientes a cada parmetro de
configuracin. A travs de la tecla enter eran enviados estos datos a la aplicacin cliente,
donde se logr verificar la llegada y carga de estos nuevos valores de parmetros. Al ser
completados todos los campos, la aplicacin lograba registrarse con la central IP para ms
tarde enviar el mensaje Registrado al hardphone, para as autorizarlo para hacer llamadas.
Los mensajes de pantalla correspondientes al proceso de configuracin se muestran en
la figura 6.13.
Figura 6.13 Mensajes de Configuracin del Hardphone.

A la izquierda los mensajes de solicitud de ingreso de parmetros de configuracin. A la derecha, ejemplos
de valores introducidos va teclado y mostrados en pantalla.
143
CAPTULO VI
Otros ejemplos.
Adicionalmente, se logr verificar la recepcin en el hardphone de todos los otros
mensajes de sealizacin enviados desde la central IP (nmero invlido, congestin, timeout,
no registrado, etc.) y la ejecucin de las acciones correspondientes por parte del hardphone.
CAPTULO VII
CAPTULO VII. CONCLUSIONES Y RECOMENDACIONES

El conocimiento y las destrezas adquiridas en el manejo de un ambiente de
programacin orientado a objetos, ha contribuido significativamente en la formacin integral
de un profesional del rea de electrnica, que viene a ser complemento para el desarrollo de
aplicaciones que requieren interfaz de usuario, en donde sea necesaria la implementacin de
procesos concurrentes en tiempo y otras funciones interactivas que exijan ejecucin en tiempo
real.
Es evidente que la tecnologa de redes IP ha ido ganando progresivamente cada vez
ms y ms terreno como opcin de simplificacin e integracin de servicios en el
planteamiento de soluciones que generen beneficios econmicos y variedad de aplicaciones.
Los problemas asociados a la calidad de servicio cada vez estn ms cerca de ser
solventados, en particular, a travs de la creacin e implementacin de nuevos protocolos de
control de flujo sobre plataformas compatibles e interoperables con tecnologas nuevas y con
las tradicionales.
Con el desarrollo de este proyecto ha sido posible verificar la factibilidad asociada al
hecho de realizar funciones de procesamiento de datos (en particular, de voz) a travs de una
circuitera externa, que disminuye la carga de trabajo de la computadora, en especial en los
casos en que se desee o se requiera la implementacin de servicios ms complejos como
videoconferencias, chat, reproduccin de msica y videos, etc., todo integrado en una sola
aplicacin.
Para la optimizacin en la ejecucin de las funciones llevadas a cabo por el prototipo
de terminal IP diseado en este trabajo de grado, se proponen las siguientes recomendaciones:
El uso de un microcontrolador ms rpido o, en su lugar, el uso de un procesador digital de
seales DSP (Digital Signal Processing) con el cual puedan llevarse a cabo clculos y rutinas
de procesamiento en tiempo real y de gran precisin. Por ejemplo, el dspic30F3014, el cual
145
CAPTULO VII
ofrece un mximo de 40MHz de velocidad de procesamiento frente al Motorola

MC68HC908GP32 empleado en este diseo, el cual ofrece un mximo de 8MHz.
El uso de un CODEC de otra tecnologa, que permita mayores valores de compresin de la
voz con el fin de garantizar mayor calidad y servicio y manejo de ms canales de voz con el
mismo ancho de banda.
La programacin del manejo de teclado en dos modos distintos: numrico y alfanumrico,
seleccionables por parte del usuario de acuerdo a la funcin en uso. Esto ofrecera mayor
velocidad y mejor desempeo del teclado dependiendo del modo configurado.
El uso de mdulo USB en lugar de una interfaz serial-USB, con el fin de obtener mayor
velocidad en la transmisin de datos ya que se tiene inters de ejecucin en tiempo real.
El manejo de un modo de bajo consumo en el mdulo de generacin de los tonos, con la
finalidad de disminuir el consumo de energa en los lapsos de tiempo en que la aplicacin
telefnica est inactiva.
En lo relativo al desarrollo aqu presentado, quedan por concluir las pruebas
relacionadas a la tarjeta interfaz con la red de telefona tradicional Intel Dialogic D 41JCT-LS,
las cuales no se llevaron a cabo por no disponer de dicho recurso dentro del tiempo asignado
para la conclusin de este proyecto de grado.
BIBLIOGRAFA
REFERENCIAS BIBLIOGRAFICAS
[1] SOTO, M. "Protocolos TCP/IP".
<http://usuarios.lycos.es/janjo/janjo1.html>
[2] ARES, R. "Telefona IP: Protocolos de Sealizacin".
<http://www.monografias.com/trabajos16/telefonia-senalizacion/telefonia-senalizacion.shtml>
[3] VAN B., J. "Signaling in Telecommunication Networks", John Wiley & Sons, INC.,
Captulos: 7, 8, 9, 10 y 11 (1998)
[4] STOKLE, M. THIS IS THE WAY: Session Initiation Protocol Tutorial versin 3 [en
lnea].
<http://www.frlp.utn.edu.ar/materias/internetworking/apuntes/SIP/Session%20Initiation%20Pr
otocol%20(SIP)%20Tutorial%20-%20Slides.pdf>
[5] COLLINS, D. Carrier Grade Voice Over IP. McGraw-Hill, Estados Unidos de Amrica,
Captulos: 5,6 y 7 (2.003)
[6]CANALIS, M. MPLS Multiprotocol Label Switching: Una Arquitectura de Backbone
para la Internet del Siglo XXI. [en lnea]. Argentina. Dpto. Informtica. Universidad
Nacional del Nordeste.
<http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MPLS.PDF>
[7] PEA, W. "Redes y telefona IP. Cambio de paradigma" [en lnea]. Publicado el 18 de
Diciembre de 2004.
<http://www.pcworld.com.ve/n88/articulos/telefoniaip.html>
[8] Asterisk@Home. "Asterisk@Home Handbook" [en lnea]. Publicado el 23 de Agosto de
2005.
<http://asteriskathome.sourceforge.net/handbook/index.html>
147
BIBLIOGRAFA
[9] Kng, S., Onken, L. y Large, S. TortoiseSVN: Un cliente de Subversion para Windows:
Version 1.3.0. [en lnea]. Publicado en Enero de 2006.
< http://tortoisesvn.sourceforge.net/docs/release/TortoiseSVN_es.pdf >
LIBROS
STALLINGS, W. "Redes e Internet de alta velocidad", Prentice Hall, 2 edicin, Espaa
(2002).
STALLINGS, W. "Comunicaciones y redes de computadoras", Prentice Hall, 7 edicin,
Espaa (2004).
COUGHLIN, R. Y DRISCOLL, F. Circuitos Integrados Lineales y Amplificadores
Operacionales, Prentice Hall, 2 edicin, Mxico (1982).
PGINAS DE INTERNET
http://ditec.um.es/laso/docs/tut-tcpip/
http://www.labredes.unb.br/material/APRC_OSDI/rtp.pdf
http://www.adiptel.com/soluciones/rtp.php
http://www.adiptel.com/doc/fxs_fxo.pdf
http://yate.null.ro/pmwiki/
http://www.infoworld.com/article/05/08/08/32FEossvoip_1.html?s=feature
http://www.gnutelephony.org/
http://es.wikipedia.org/wiki/Portada
http://www.telefonica.es/sociedaddelainformacion/pdf/publicaciones/telecomunicacionesng/ca
pitulos/07_la_capa_de_control.pdf
http://www.ati.es/novatica/2001/151/glovoip.pdf
http://ingenieria.udea.edu.co/CURSOS/IEO-614/Com_Senal.ppt
http://www.itu.int/opb/sector.aspx?lang=es&sector=2
http://www.tsares.net/docs/VoIP-Info/Que_es_VoIP.htm
148
BIBLIOGRAFA
http://www.monografias.com/especiales/telefoniaip/index.shtml
http://www.tldp.org/HOWTO/VoIP-HOWTO.html
http://www.eveliux.com/fundatel/analogdigital.html
http://www.monografias.com/trabajos17/tipos-transmision-datos/tipos-transmisiondatos.shtml
http://www.virtual.unal.edu.co/cursos/sedes/manizales/4040003/lecciones/cap5lecc7.htm
http://es.wikipedia.org/wiki/C%C3%B3dec_de_audio
http://html.rincondelvago.com/modulacion-pcm.html
http://html.rincondelvago.com/protocolos-de-telecomunicaciones.html
http://www.analog.com/processors/resources/technicalLibrary/manuals/training/materials/pdf/
dsp_book_Ch22.pdf
http://www.rares.com.ar/telecomunicaciones/archivos/albums/Manual%20de%20Telecomunic
aciones/2-01%20Codec%20telefonia%20PCM.PDF
http://www.comunicaciones.unitronics.es/tecnologia/voip.htm
http://www.usergioarboleda.edu.co/grupointernet/telefonia.htm
http://www.aui.es/biblio/bolet/bole025/art_4.htm
http://gl.wikipedia.org/wiki/Protocolo_IP
http://www2.okisemi.com/site/applications/VoIPPhone.html/view?searchterm=%22voip%22
http://www.monografias.com/trabajos16/telefonia-senalizacion/telefonia-senalizacion.shtml
http://www.telefoniaip.uchile.cl/capacitacion_modelos.htm
http://www.e-advento.com/soluciones/telefoniaip.php
http://www.unam.mx/enlinea/enlineap/Apoyo/medios.html
http://www.packetizer.com/voip/sip/papers/understanding_sip_voip/
http://www.packetizer.com/voip/sip/papers/
http://www.windowsnetworking.com/articles_tutorials/Session-Initiation-ProtocolFunctions.html
http://www.aui.es/biblio/bolet/bole025/art_4.htm
http://greco.dit.upm.es/~abgarcia/publications/2000TELECOM-BTI.pdf
http://216.239.51.104/search?q=cache:F0qJl49bLtkJ:www.uv.es/montanan/ampliacion/ampli_
4.doc+protocolo+RSVP&hl=es&gl=ve&ct=clnk&cd=20&client=firefox-a
149
BIBLIOGRAFA
http://pc21te.dte.uma.es:8100/edu/pub/casilari/infopers/pcongres/200311000/ariza_telecom1.p
df
http://www.bitmailer.com/productos/conectividad/bitvpn/ventajasmpls.html
http://eia.udg.es/~atm/bcds/pdf/yezid_02.pdf
http://www.terra.es/tecnologia/glosario/ficha.cfm?id_termino=41
http://www.entorno.es/phtml/vpn.phtml
http://www.monografias.com/trabajos11/repri/repri.shtml#tev
http://internetng.dit.upm.es/ponencias-jing/2002/salvachua/salvachua.PDF
http://sipx-wiki.calivia.com/index.php/SipXezPhone_Introduction_and_Screenshot
http://www.sipfoundry.org/sipXcallLib/
http://www.sipfoundry.org/sipXportLib/
http://www.sipfoundry.org/sipXtackLib/
http://www.linuxdevices.com/news/NS4301692594.html
MANUALES
Manual Tcnico del microcontrolador Motorola MC68HC908GP32, Revisin 6 (2002).
APNDICES
APENDICES
151
APNDICES
APNDICE A: ESQUEMATICOS DEL CIRCUITO GENERAL Y CIRCUITO DE PRUEBA

DEL CODEC.
Circuito General.
152
APNDICES
Circuito de Prueba del CODEC.
153
APNDICES
APNDICE B: CARACTERSTICAS PRINCIPALES DEL MICROCONTROLADOR

MC68HC908GP32 Y DEL CODEC TLV320AC37CN.

PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PDF

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD SIMN BOLVAR

Decanato de Estudios Profesionales

DESARROLLO DE UN SISTEMA VOIP Y DISEO DE

Sartenejas, Febrero de 2006.

UNIVERSIDAD SIMN BOLVAR

DESARROLLO DE UN SISTEMA VOIP Y DISEO DE

Sartenejas, Febrero de 2006.

UNIVERSIDAD SIMN BOLVAR

DESARROLLO DE UN SISTEMA VOIP Y DISEO DE

Un da escuch que el regalo ms grande que a sus hijos da el seor, es su madre y el

NDICE DE TABLAS Y FIGURAS

LISTA DE SMBOLOS Y ABREVIATURAS

condicionado por una calidad inferior en las comunicaciones frente a la conmutacin de

1.1 Informacin General de la Empresa.

AVLIS Consultores S.A. (ACSA) es una empresa venezolana, con ms de 8 aos de

Entre los productos desarrollados destacan:

1.2 Antecedentes y Justificacin.

Debido al panorama de grandes beneficios que proveen las soluciones basadas en la

1.3 Visin General del Proyecto.

En los pasados 100 aos, la comunicacin de voz se le haba confiado exclusivamente

El proyecto que se presenta, propone el desarrollo e implementacin de servicios y

Figura 1.1 Esquema General del Proyecto.

Ntese que se observan dos componentes fundamentales:

2.- Estacin Terminal HW/SW. Comprende:

1.4.2 Objetivos Especficos.

para la sincronizacin del CODEC de

voz con la unidad de control.

k.- Disear e implementar un protocolo para la comunicacin y sealizacin entre la

1.5 Alcance y Limitaciones.

El alcance de este trabajo es el diseo de un sistema VoIP y de un prototipo de equipo

Debido a que las labores desempeadas por la empresa tienen un carcter de

1.6 Estructura del informe.

En el primer captulo se presenta informacin general de la empresa donde se

principales empresas de telefona de Venezuela, y las ofertas libres propuestas en el mercado

CAPTULO II. FUNDAMENTOS TERICOS.

2.1 Protocolos de Internet.

Una red es una configuracin de computadoras que intercambian informacin. stas

establecer un conjunto de reglas formales para su interaccin.

Figura 2.1 Modelo OSI.

2.1.1 TCP / IP.

TCP/IP no es un nico protocolo, sino que es un conjunto de protocolos que trata de

Por ejemplo, una entidad de transporte TCP, acepta mensajes de longitud

a travs de la sta e incluye el concepto de direccionamiento de destino y enrutamiento. As, la

2.1.2 UDP / IP.

Figura 2.3 Esquema de empaquetamiento para los paquetes RTP.

El protocolo RTP puede trabajar en conjunto con el Protocolo de Reserva de Recursos

RTCP se fundamenta en la transmisin peridica de paquetes de control a todos los

2.2 Protocolos de Telefona tradicional.

Esta informacin de inters se denomina

El protocolo DTMF (Dual Tone Multi-Frequency), es un protocolo multifrecuencial

Figura 2.5 Tonos DTMF.

Est constituido por un conjunto de seales analgicas a determinadas frecuencias a las

El protocolo MFC-R2 tiene frecuencias asociadas a todos los mensajes de sealizacin

Figura 2.7 Frecuencias utilizadas en el protocolo MFC-R2.

2.2.1.3 Sealizacin #5.

Es tambin un protocolo de sealizacin multifrecuencial, constituido por seales hacia

Figura 2.8 Sealizaciones que se usan en el enrutamiento de una llamada.

Adicionalmente, en la telefona digital se introduce un nuevo concepto, el de

2.2.2.1 CCITT Recomendacin Q.931.

Figura 2.9 Modelo general de comunicacin entre centrales y usuarios ISDN.

Figura 2.10 Formato general de los mensajes correspondientes al protocolo Q.931.

Figura 2.11 Red ISDN con terminales analgicos y digitales.

2.2.2.2 Sealizacin #7.