Sunteți pe pagina 1din 0

90

Captulo 3

ANLISIS DE TRFICO.
3.1. Introduccin.

Un anlisis de trfico en redes basadas en tecnologa Ethernet se basa nor-
malmente en el uso de sondas (software) con interfaz Ethernet. Dichas sondas
capturan el trfico a ser analizado y constituye la plataforma en la que se pueden
ejecutar aplicaciones propietarias o de dominio pblico; Con dichas aplicaciones
se puede determinar el tipo de informacin que circula por la red y el impacto
que tiene sobre la misma.

Para realizar un anlisis de trfico existe una gran diversidad de alternativas
que van desde productos con licencia que incluyen hardware y software, hasta
soluciones gratuitas y de cdigo abierto utilizada bajo sistemas Linux-UNIX.
3.2. Protocolo IPv4.

La versin 4 de IP (IPv4) es la versin de IP ms ampliamente utilizada,
siendo el nico protocolo de Capa 3 que se utiliza para llevar datos de usuario a
travs de Internet. La versin 6 de IP (IPv6) est desarrollada y se est imple-
mentando en algunas reas. IPv6 operar junto con el IPv4 y podr reemplazarlo
en el futuro. Los servicios provistos por IP, as como tambin la estructura y el
contenido del encabezado de los paquetes estn especificados tanto por el proto-
colo IPv4 como por el IPv6. Estos servicios y estructura de paquetes se usan para


60

CAPTULO 3. ANLISIS DE TRFICO.
encapsular datagramas UDP o segmentos TCP.
El Protocolo de Internet provee slo las funciones necesarias para enviar un
paquete desde un origen a un destino a travs de un sistema interconectado de
redes. El protocolo no fue diseado para rastrear ni administrar el flujo de pa-
quetes. Estas funciones son realizadas por otros protocolos en otras capas.
El protocolo IP define muchos campos diferentes en el encabezado del pa-
quete. Estos campos contienen valores binarios que los servicios IP toman como
referencia a medida que envan paquetes a travs de la red.
Figura 3.1: Campos del encabezado de paquetes IP[8].
Caractersticas bsicas de IP:
Sin conexin: No establece conexin antes de enviar los paquetes de datos.

Mximo esfuerzo: No se usan encabezados para garantizar la entrega de
paquetes (no confiable).

Medios independientes: Operan independientemente del medio que lleva los
datos.
3.3. Protocolo RTP.

El protocolo de transporte en tiempo real (RTP) es un protocolo basado en
IP que proporciona soporte para el transporte de datos en tiempo real (flujos de
vdeo y de audio). Fue sido diseado para funcionar junto con el protocolo de
control auxiliar RTCP para conseguir mantener la calidad en la transmisin de
61

CAPTULO 3. ANLISIS DE TRFICO.
datos y proporcionar informacin sobre los participantes al iniciarse la sesin.
Funcionamiento de RTP
Los paquetes enviados por Internet sufren un retardo y jitter impredecible que
las aplicaciones en tiempo real no pueden aceptar. Por eso, RTP proporciona un
mecanismo llamado TimeStamping que ofrece un transporte end-to-end para los
datos en tiempo real.
TimeStamping es la informacin ms importante de las aplicaciones en tiempo
real. El emisor establece el TimeStamp segn el instante en que se muestra el
primer octeto en el paquete. El receptor despus de recibir los paquetes de datos
utiliza el TimeStamp para reconstruir el tiempo original.
El paquete RTP se encapsula en un paquete UDP/IP, tal y como se muestra en
la siguiente figura:
Figura 3.2: Encapsulacin de un paquete RTP.

Para establecer una sesin RTP, la aplicacin define un par particular de di-
recciones de transporte destino. En una sesin multimedia cada mitad es llevada
en una sesin RTP separada, por ejemplo, audio y vdeo podran viajar en sesio-
nes RTP separadas teniendo la posibilidad un receptor de seleccionar o0 no una
mitad en concreto.
RTP se caracteriza por:
RTP proporciona un servicio end-to-end para informacin con la carac-
terstica del tiempo real, como audio y vdeo interactivo.
RTP no es un protocolo completo. Est abierto a nuevos formatos y soft-
ware multimedia.
62

CAPTULO 3. ANLISIS DE TRFICO.
RTP/RTCP no es responsable de las tareas de alto nivel como la sincroni-
zacin, recuperacin de paquetes perdidos y control de congestin que debe
realizarse en el nivel de aplicacin.
La informacin de control de ujo y congestin de RTP es proporcionada
por los informes del emisor y receptor de RTCP.
3.4. Tramas Ethernet.

Ethernet es una arquitectura basada en la especificacin de la IEEE 802.3 y
utiliza tres conceptos esenciales para su operatividad:
La difusin.- Hace que una trama Ethernet se difunda por todo el medio de
comunicacin (broadcast), con la particularidad de que slo la tarjeta con
la direccin Ethernet que coincide con la direccin indicada en la trama la
aceptar, las dems lo ignorarn.
El direccionamiento Ethernet.- Con el que se logra que una tarjeta sea nica
en la red y que le corresponda una sola direccin fsica.
Trama Ethernet.- Es el medio de transporte de todos los protocolos que se
definen en las capas superiores, adems representa el formato en que los
datos son encapsulados para ser transmitidos al medio fsico, el esquema de
una trama Ethernet es:
Figura 3.3: Trama Ethernet.

Ether. Dest. (6 bytes).- Es la direccin Ethernet (direccin fsica) de la
tarjeta destino.

63

CAPTULO 3. ANLISIS DE TRFICO.
Dir. Ether. Orig. (6 bytes).- Es la direccin Ethernet (direccin fsica) de
la tarjeta destino.

Proto (2 bytes).- Es el indicador del protocolo transportado en la trama
Ethernet.

Datos (46-1500 bytes).- Son los datos transportados (protocolos: IP, Net-
Beui, etc).

CRC (4 bytes).- Es el clculo de la suma de comprobacin la cual asegura
la integridad de la trama.
3.5. Medicin de QoS.

La calidad de servicio (QoS) es el rendimiento de extremo a extremo de los
servicios electrnicos tal como lo percibe el usuario final. La implementacin de
Polticas de Calidad de Servicio se puede enfocar en varios puntos segn los re-
querimientos de la red, los principales son:
Asignar ancho de banda en forma diferenciada

Evitar y/o administrar la congestin en la red

Manejar prioridades de acuerdo al tipo de trfico

Modelar el trfico de la red
La Calidad de Servicio (QoS) se experimenta en el usuario final y es inuen-
ciada por dos factores fundamentales:
Calidad de la voz extremo a extremo.- Es determinada por los sucesivos
procesos de codificacin y decodificacin incluyendo la prdida de paquetes
en la red.
64

CAPTULO 3. ANLISIS DE TRFICO.
Demora extremo a extremo.- Se produce por los sucesivos procesos de codifi-
cacin, decodificacin, paquetizacin, encolamiento, afecta la interactividad
en la conversacin y a la calidad de servicio.
3.5.1. Eco.

El odo humano detecta el eco cuando la seal original y la seal de eco tienen
una diferencia igual o mayor a los 10ms, pero si supera los 30 [ms], llega a ser
significativo y afecta el normal desempeo de la conversacin. Como se ha men-
cionad para solucionar este inconveniente se utilizan canceladores y supresores de
eco.
3.5.2. Latencia.

Para poder reducir el retraso se implementa buenas polticas de calidad de
servicio en los enrutadores (routers) y conmutadores (switches) por los que atra-
viesa tu trfico de voz. Una regla de oro para minimizar la latencia es colocar tu
central (PBX) en el segmento menos congestionado o saturado de la red.
3.5.3. Jitter.

Muchos equipos de VoIP dejan ajustar el tamao del "jitter buffer..
El
buffer es
esa rea donde los paquetes se almacenan para luego ser enviados al procesador
de voz en intervalos constantes. El tamao del buffer se mide en milisegundos.
Si el buffer es de 200 ms significa que introducimos un retraso (esperamos) ese
tiempo antes de reproducir la voz.

Un valor comn del jitter buffer es de 100 ms. Al incrementar el buffer se
mejora la calidad de la conversacin pero lo que se est haciendo es incrementar
el retardo total (latencia). Un retraso total muy por encima de 300 ms hace muy
difcil tener una conversacin.

La uctuacin del retardo (jitter) se puede controlar con memorias temporales
(buffers), a expensas de un aumento del retardo, en la tabla a continuacin se
65

CAPTULO 3. ANLISIS DE TRFICO.
presenta el retardo debido al algoritmo en ms, el cul es producido en los dispo-
sitivos debido al muestreo de la seal (retardo intrnseco):
Cuadro 3.1: Tipos de Cdec con tipo de codificacin generan un retardo intrnseco.
3.5.4. Prdida de Paquetes.

El principal problema es cuando las prdidas de paquetes se dan por rfagas.
Adems el uso de un tipo de cdec de alta compresin como el G.729 permite
apenas el 1 % de paquetes perdidos o de un cdec de baja compresin como el
G.711 que permite un 5 % de prdida de paquetes. Una solucin para este pro-
blema est en la supresin de silencios evitando as la carga en la transmisin y
por ende el descongestionamiento de los enlaces.
3.6. Software para medicin de QoS (Ingeniera
de trfico).

VQManager es una potente herramienta de monitorizacin de VoIP basada
en web y pasiva para las redes de VoIP. Puede monitorizar cualquier dispositivo
o agente que soporte SIP (RFC 3261) y RTP/RTCP(RFC 3550). VQManager
monitoriza en tiempo real las mediciones de VoIP QoS para proporcionar infor-
mes instantneos, alertas auto configurables y muestreo de fallos en profundidad,
todo desde una interfaz web.

El anlisis completo de los niveles de llamada y el punto final de QoS 24 horas
al da y 7 das a la semana hace posible el muestreo de fallos en profundidad a

66

CAPTULO 3. ANLISIS DE TRFICO.
travs del seguimiento de llamadas y resmenes de llamadas.
Los potentes y exibles informes de la herramienta generan ms de 30 informes
diferentes dando una vista en profundidad de las tendencias de uso, utilizacin
de ancho de banda y planificacin de la capacidad.
VQManager no requiere ningn otro hardware/software especial para soportar
y es accesible de forma remota, su interfaz amigable ahorra un tiempo y mejora
enormemente la productividad del administrador.
3.7. Protocolos de Qos.

La construccin de una red que pueda soportar Calidad de Servicio (QoS)
requiere cierto nmero de tecnologas QoS las cuales se encuentran divididas de
acuerdo a las diferentes capas de tecnologa de un modelo casi-OSI:
Cuadro 3.2: Tecnologas QoS de acuerdo a un modelo casi - OSI.
3.7.1. RSVP.

El protocolo de reserva de recursos (RSVP), descrito en RFC 2205, es un pro-
tocolo de la capa de transporte diseado para reservar recursos de una red bajo
la arquitectura de servicios integrados (IntServ). RFC 2205 se describe a RSVP
como un protocolo de control de internet, como ICMP, IGMP, o protocolos de
enrutamiento. RSVP reserva los canales o rutas en redes internet para la trans-
misin por unidifusin y multidifusin con escalabilidad y robustez.
67

CAPTULO 3. ANLISIS DE TRFICO.
RSVP puede ser utilizado tanto por hosts como por routers para pedir o en-
tregar niveles especficos de calidad de servicio (QoS) para los ujos de datos de
las aplicaciones. RSVP define como deben hacer las reservas las aplicaciones y
como liberar los recursos reservados una vez que han terminado.
Caractersticas:
Pide recursos para los ujos simplex: un ujo de trfico en una sola direccin
desde el emisor a uno o ms receptores.

Est orientada hacia el receptor: es el receptor de un ujo de datos el que
inicia y mantiene la reserva de recursos para ese ujo.

Es soft state (la reserva en cada nodo necesita refresco peridico), mantiene
solo temporalmente es estado de las reservas de recursos del host y de los
routers, de aqu que soporte cambios dinmicos de la red.

Transporta y mantiene parmetros del trfico y de la poltica de control que
son opacos a RSVP. Los dos conceptos clave del modelo RSVP son owspec
y filterspec:

Flowspec.- RSVP reserva recursos para un ujo.

Filterspec.- Filterspec define el conjunto de paquetes que sern afec-
tados por un owspec (es decir, los paquetes de datos para recibir la
QoS definida por el owspec).
3.7.2. MPLS.

MPLS (Multi-Protocol Label Switching) es una red privada IP que combina la
exibilidad de las comunicaciones punto a punto o Internet y la fiabilidad, calidad
y seguridad de los servicios Prvate Line, Frame Relay o ATM.

MPLS es hoy da una solucin clsica y estndar al transporte de informacin
en las redes, ha sido hasta hoy una solucin aceptable para el envo de informa-
cin, utilizando Routing de paquetes con ciertas garantas de entrega.
68

CAPTULO 3. ANLISIS DE TRFICO.
Asigna a los datagramas de cada ujo una etiqueta nica que permite una
conmutacin rpida en los routers intermedios (solo se mira la etiqueta, no la
direccin de destino).
El etiquetado de los paquetes en base a criterios de prioridad y/o calidad (QoS).
Ofrece niveles de rendimiento diferenciados y aplicaciones de voz y multimedia.
Y todo ello en una nica red.
Las principales aplicaciones de MPLS son:
Funciones de ingeniera de trfico (a los ujos de cada usuario se les asocia
una etiqueta diferente)

Policy Routing

Servicios de VPN

Servicios que requieren QoS

Por tanto MPLS es una tecnologa que permite ofrecer QoS, independiente-
mente de la red sobre la que se implemente. El etiquetado en capa 2 permite
ofrecer servicio multiprotocolo y ser portable sobre multitud de tecnologas de
capa de enlace: ATM, Frame Relay, lneas dedicadas, LANs. Las principales de
MPLS son:
Redes de alto rendimiento: las decisiones de encaminamiento de los routers
MPLS son en base a la LIB son mucho ms sencillas y rpidas que las que
toma un router IP ordinario (la LIB es mucho ms pequea que una tabla
de rutas normal).

Ingeniera de Trfico: se conoce con este nombre la planificacin de rutas
en una red en base a previsiones y estimaciones a largo plazo con el fin de
optimizar los recursos.

QoS: es posible asignar a un cliente o a un tipo de trfico una FEC a la que
se asocie un LSP que discurra por enlaces con bajo nivel de carga.
69

CAPTULO 3. ANLISIS DE TRFICO.
3.7.3. TOS.

TOS (por sus siglas en ingls Type of Service) se encuentra en el datagrama
IP y consta de 8 bits que se dividen en 5 sub-campos:
Cuadro 3.3: Campos del TOS.

Los primeros 3 bits especifican la prioridad de datagramas que varan de 0 a
7. Permitiendo a los remitentes indicar la importancia de cada datagrama. TOS
constituye un mecanismo para permitir un control de la informacin.
Los otros 3 bits restantes representan lo siguiente:
D - las solicitudes de baja retraso.

T - las solicitudes de alto rendimiento.

R - las solicitudes de alta fiabilidad.

Los bits de prioridad (bits 0, 1, 2) son importantes para tener un efecto sobre
la carga. Estos bits varan y tratan de controlar los cambios en el RTT (Round
Trip Time) para cargas variables.
Con cargas bajas, el trfico no es suficientemente significativo para el TOS a
tener ningn efecto sobre el ping porque los paquetes pasarn a travs de todos
modos. Del mismo modo con cargas altas, el TOS no tendr un efecto sobre las
estadsticas de ping pero en este caso hay demasiado trfico habr una cantidad
importante de prdida de paquetes y tiempos de viaje alargados con independen-
cia de la precedencia establecida. Algn punto intermedio de estos dos extremos
esperamos ver una ventana.
70

CAPTULO 3. ANLISIS DE TRFICO.
3.7.4. Ethereal.

EtheReal garantiza ancho de banda basado en conexin a las aplicaciones que
requieran de comunicacin en tiempo real usando los controladores y adaptadores
normales de Ethernet. La clave de EtheReal se encuentra en el uso de los con-
mutadores para garantizar conexiones que requieran de comunicacin en tiempo
real. Las modificaciones en las que se basa EtheReal pueden ser implementadas
en software, de manera que no hace falta ningn requerimiento hardware especial.
A los usuarios, simplemente se les instalan libreras que sern capaces de estable-
cer dichas conexiones desde el origen hasta el destino sin involucrar los kernel de
ningn nodo.

En el diseo de EtheReal se asume lo siguiente:

Los nodos estn conectados a los conmutadores EtheReal mediante cone-
xiones punto a punto. De esta manera se elimina la mayor fuente de inde-
terminismo debida al protocolo de acceso al medio CSMA/CD .

Todo el ancho de banda requerido por un nodo, tanto real-time como non-
real-time, ser menor que el total del ancho de banda de la red. Eliminando
la mayor fuente de problemas para garantizar un comportamiento adecuado
para las aplicaciones en tiempo real.

Se soportaran dos tipos de servicios sobre la red: conexiones en tiempo real
con tasa de transferencia variable, las cuales requerirn de un proceso de
setup, y conexiones sin requerimientos de tiempo real con las cuales no
ser necesaria ninguna fase de configuracin, y por lo tanto, no tendrn
ninguna garanta.

Los nodos debern soportar los protocolos TCP/UDP e IP.
3.8. Simulacin red CNT Cuenca.

La presente simulacin se realizar con el fin de comprobar el funcionamiento
de la central de VoIP en la infraestructura actual de la CNT - Azuay, adems
la interoperabilidad que presenta un servidor asterisk al trabajar con equipos de
diferentes marcas.
71

CAPTULO 3. ANLISIS DE TRFICO.
3.8.1. Introduccin.

La simulacin implicar probar el diseo que se presenta a la CNT - Azuay
para uso de una central de voz sobre IP, el servidor Asterisk (con distribucin
Trixbox) ser colocado en un puerto del switch 3COM de empresa y a varios
terminales IP se les configuraran extensiones basadas en la limitacin de la tesis,
las mquinas sern tanto de la ciudad de Cuenca, como en Paute en un segmento
de la red. Los terminales IP consisten en: softphone (X-Lite), ATA (Cisco ATA
186), Telfono IP (Cisco). Al realizar pruebas de llamadas debemos conseguir la
interconexin entre extensiones IP y con la PSTN mediante la tarjeta interfaz
Digium TDM 400P bajo el protocolo de sealizacin SIP. La interconexin con
la PSTN nos permitir realizar llamadas internas, locales, regionales, nacionales,
celulares e internacionales desde nuestro terminal IP.
72

CAPTULO 3. ANLISIS DE TRFICO.
3.8.2. Esquema de Simulacin.
Figura 3.4: Esquema de Simulacin.
73

CAPTULO 3. ANLISIS DE TRFICO.
3.8.3. Configuracin del servidor Asterisk.

Con el archivo ISO (Trixbox 2.6) quemado en un CD, procedemos a cargar en
la PC que nos servir de servidor con previa verificacin de que la PC arranque
con lectura desde el CDROM. En las pantallas que aparecern se podr elegir
el tipo de teclado (espaol = es), la zona horaria (Amrica/Guayaquil), la con-
trasea (password = .tesis.). El proceso de instalacin se completar cuando el
sistema reinicie.
Figura 3.5: Instalacin de Trixbox.

En su reinicio el sistema nos presenta una pantalla en la que nos permite
escoger entre las opciones de boot, ingresamos como usuario root y con la contra-
sea antes indicada al momento de instalacin. El servidor consta de una tarjeta
Digium TDM - 400P (un solo puerto FXO), adems de dos tarjetas de red, a
las cuales se les puede configurar con el comando system-config-network. Para
nuestro caso la tarjeta Eth0 ser la que conecte la red LAN de la empresa con el
servidor Asterisk. Mientras que la Eth1 ser conectada hacia una red WAN para
interconectar dos centrales (Cuenca - Paute).
3.8.4. Configurando Hardware.

El hardware que se utiliza en esta tesis como se ha mencionado es una tarjeta
Digium TDM400P con 4 puertos FXO, pero slo un puerto FXO est activo.

74

CAPTULO 3. ANLISIS DE TRFICO.
Instalacin de la Tarjeta.
Para configurar esta tarjeta con Trixbox se utiliza el utilitario de configura-
cin automtica de la tarjeta de Dahdi para configurar el controlador Dahdi.
1. Se instala la tarjeta en la ranura para el PCI. Una de las ventajas de este
tipo de tarjetas es que no necesita una fuente de poder para funcionar.

2. Inicie una sesin en Centos con una cuenta raz

3. Corra los siguiente comandos:

root@asterisk1]# dahdi genconf

root@asterisk1]# dahdi cfg

root@asterisk1]# dahdi tool

Los resultados de dahdi tool debern mostrar su tarjeta dahdi como configu-
rada y procedemos a editar el archivo dahdi-auto.conf:
Usando un navegador Web y nos conectamos a Trixbox:

1. Haga clic en el portal de Administracin del Asterisk y haga clic en
"PBX"

2. Haga clic en C5onfig File Editor".

3. Haga clic en "dahdi-dahdi.conf"

4. Observar la siguiente configuracin:

Span 1: WCTDM/4 "Wildcard TDM400P REV I Board 5"(MAS-
TER)
;;; line="4 WCTDM/4/3 FXSKS"
signalling=fxs ks
callerid=asreceived
group=0
context=from-pstn
channel =>4

75

CAPTULO 3. ANLISIS DE TRFICO.
callerid=
group=
context=default
3.8.5. Creando una Extensin.

Un servidor asterisk soporta cuatro tipos de dispositivos: SIP, IAX2, ZAP y
C5USTOM", la limitacin de la tesis se estableci como protocolo de sealizacin
SIP, al momento de crear una extensin seleccionaremos "Generic SIP Device
2

a continuacin obtendremos un listado de parmetros necesarios y otros no tan
necesarios; lo ms importantes son:
Figura 3.6: Creacin de extensiones en Trixbox.

Extensin del Usuario: Es el nmero al que se va a marcar desde cualquier
extensin, debe ser nico y puede ser de cualquier cantidad de dgitos.

Nombre para Mostrar: Es el nombre del Caller ID, adems es la informacin
que enviar al receptor.

Secret: Es la contrasea usada por el terminal para autenticarse al servidor
de Asterisk. El usuario debe saber siempre y cuando sea quin configure el
softphone o de lo contrario esa clave la registra el administrador.

Para realizarlo desde el CLI de Asterisk se utiliza la siguiente estructura del
comando:

76

CAPTULO 3. ANLISIS DE TRFICO.
"dialplan add extension <exten>,<priority>,<app>,<app-data>into <context>[replace]"
Por ejemplo: trixbox1*CLI>dialplan add extension 1135,1,Dial,SIP/192.168.1.1/1135
into from-internal Extension '1135,1,Dial,SIP/192.168.1.1/1135dded into 'from-
internal'context { Added extension '1135'priority 1 to from-internal (0x9d42ab8)
El sistema Asterisk posee nmeros de extensiones reservados y es necesario cono-
cer para no presentar problemas ente el sistema y una extensin.
Cuadro 3.4: Numeracin Reservada en Trixbox.
3.8.6. Configuracin softphone.

Debemos tener presente que antes de configurar un terminal haber creado la
extensin en nuestro servidor Asterisk. En la configuracin de nuestro softphone
X-lite crearemos una extensin 1001 con tecnologa SIP y secret 1001 para la
Gerencia. Con X-lite instalado en la PC seleccionamos la opcin SIP Account
Settings (Parmetros de la cuenta SIP).
Figura 3.7: Softphone X-Lite.

En la ventana de los parmetros ingresamos los datos previamente menciona-
dos, sin olvidarnos de que nuestro dominio y nuestro Proxy hacen referencia al

77

CAPTULO 3. ANLISIS DE TRFICO.
servidor Asterisk.
Figura 3.8: Configuracin X-Lite.
3.8.7. Configuracin Telfono IP.

Para configurar un telfono IP se debe tener en cuenta la configuracin en la
red y el registro del terminal con el servidor Asterisk.

La configuracin en la red se lo puede hacer mediante: DHCP en la que el
terminal obtendr una direccin IP de manera automtica, o con una direccin
IP esttica con la cual se podr contar con un registro exacto de las direcciones
IP de los terminales.
Para la configuracin del terminal debemos ingresar en la interfaz web y proceder
a ingresar y modificar las caractersticas; lo referente a la direccin del Proxy y
del Server, corresponde a la direccin IP de Asterisk (192.168.1.1/24) y el puerto
de registro para la extensin es 5060, a continuacin procedemos con los datos
de la extensin: Display name (Nombre), Address y Auth User ID equivalen al
nmero de extensin y por ltimo el password que es utilizado generalmente por
el administrador.
3.8.8. Configuracin de cola.

El uso de cola hacia un grupo de usuarios tiene que ver con las llamadas en-
trantes regidos por ciertas polticas, el grupo de usuarios puede estar compuesto
por usuarios estticos o dinmicos.
Las polticas que definen la distribucin de las llamadas entrantes son las siguien-
tes:

78

CAPTULO 3. ANLISIS DE TRFICO.
ringall: Timbran todas las extensiones habilitadas hasta que una conteste
(default).

roundrobin: El timbrado lo hace por extensin por extensin habilitada en
la cola.

leastrecent: Timbra la extensin que fue la ltima en haber sido llamada

fewestcalls: Timbra la extensin que ha completado menos llamadas.

random: Timbra una extensin de la cola aleatoriamente.

rrmemory: Es parecido al roundrobin con la diferencia que la memoria que
utiliza es con las ltimas extensiones que recibieron llamadas.

La cola (cola1) configurada en la presente simulacin se da entre las exten-
siones 1001-Gerencia, 1125-Transmisiones, 1014-Financiero. En este caso los tres
usuarios son estticos, y correspondern a una cola de timbrado para las llama-
das entrantes, en este caso se est utilizando la poltica de ringall (todos contra
todos) y es llamada cola1 con nmero 6001.
Figura 3.9: Configuracin de un cola de llamada.
79

CAPTULO 3. ANLISIS DE TRFICO.
3.8.9. Grabaciones para IVR.

Un IVR es una contestadora digital que nos permite tener un mensaje hablado
en el cul est toda la informacin que deseamos compartir con los usuarios, por
ejemplo un mensaje de bienvenida que nos gue por las reas y extensiones ms
importantes de la empresa. Para acceder al mdulo de grabacin, nos guiamos
por la 5configuracin PBX
2
escogemos "System Recordings", ya en el panel, se-
leccionamos la extensin desde la cual se desee realizar la grabacin. Al marcar
al *77 empieza la grabacin desde la extensin antes indicada, para escuchar la
grabacin llamamos al *99 y guardamos la cola. Otra opcin que se tiene es tener
un mensaje previamente grabado en formato WAV o MP3 y cargarlo en el IVR
y de la misma manera lo guardamos.

La IVR nos permite desplegar un men controlado por teclado telefnico a
travs de los 10 dgitos (0 al 9) y los smbolos (# y *), con lo cual es posible
enviar la llamada hacia otro destino o a un IVR.

Para generar el IVR es necesario ingresar los datos necesarios, entre ellos:
Change Name: Cambiar nombre (Inicio).

Announcement: Grabacin para el IVR (CNT Bienv-fin).

Timeout: Tiempo de espera (en segundos) antes de enrutar la llamada a un
operador despus de ser escuchado el mensaje de entrada. (10).

Enable direct dial: Opcin que permite a quien llama marcar una extensin
directamente en caso de que la conozcan sin tener que esperar al operador.

Announcement: Es el anuncio o mensaje de entrada que se grab anterior-
mente.
80

CAPTULO 3. ANLISIS DE TRFICO.
Figura 3.10: Configuracin de un IVR.
3.8.10. Rutas Entrantes.

Mediante el establecimiento de las rutas entrantes se puede definir el com-
portamiento de las llamadas que ingresan a nuestro sistema, es decir enrutar la
llamada hacia una recepcionista digital (IVR), extensin, cola de llamada u otra
aplicacin.

En nuestro servidor se configur la ruta "todos"la cual nos dirige toda llamada
hacia nuestra IVR, tal como se observa:
81

CAPTULO 3. ANLISIS DE TRFICO.
Figura 3.11: Configuracin de una ruta de entrada.
3.8.11. Ruta Saliente.

Una ruta saliente es creada con el fin de poder conectarse con la PSTN a
travs de troncales.
Troncales.- Es una lnea telefnica que puede usarse para realizar llamadas al
exterior desde nuestra central.
Una ventaja de Trixbox es que detecta automticamente las tarjetas Digium y
las configura de la misma manera, adems existe la opcin Troncales para definir
las troncales del sistema, los puertos de las tarjetas Digium se agrupan como el
grupo 0 (g0), la cul ser nuestra troncal para hacer y recibir llamadas.
Para la configuracin de la ruta de salida previa configuracin de la Troncal, se-
leccionamos en Rutas salientes la opcin nueva ruta.
El nombre de la ruta es 01 salida. Lo que se debe tener en cuenta son las reglas
de marcacin y son especificadas mediante la siguiente sintaxis:
82

CAPTULO 3. ANLISIS DE TRFICO.
Cuadro 3.5: Reglas de Marcado.

Para el desarrollo de la presente tesis se han procedido a configurar reglas de
marcacin que puedan satisfacer los objetivos planteados (llamadas locales, na-
cionales, celulares e internacionales. Los campos para generar la ruta y las reglas
de marcado se observan en la siguiente figura:
Figura 3.12: Configuracin de una ruta de salida.
3.8.12. Networking.

En la presente tesis es necesaria la configuracin de algunos equipos para el
intercambio de paquetes entre diferentes subredes existentes en una red empresa-
rial, debido a que los enlaces dentro de la red WAN llevan tipos de redes diferentes
a los de la red LAN, en nuestro caso se ha configurado un router CISCO 877-M y
83

CAPTULO 3. ANLISIS DE TRFICO.
nuestro servidor Asterisk para enrutar el trfico por medio de dos tarjetas de Red.
Router CISCO 877-M.
Este tipo de router posee una sola interfaz fsica, pero por nuestra necesidad
configuraremos interfaces virtuales dentro de una Vlan, adems se crearn rutas
para la circulacin de los paquetes, la configuracin fundamental ser la siguiente:
Router enable

Router#configure terminal

Router(config)#interface fa 0

Router(config-if)#vlan1

Router(config-if)#ip address 170.0.0.2 255.255.255.248

Router(config-if)#ip address 10.0.0.1 255.255.255.0 secondary

Router(config-if)#exit

Router(config)#ip route 0.0.0.0 0.0.0.0 170.0.0.1

Router(config)#ip route 192.168.1.0 255.255.255.0 170.0.0.1

Router(config)# end
Asterisk (Centos).
Nuestro servidor posee dos tarjetas de red, con lo cual podemos utilizarlo como
ruteador, ante esta necesidad debemos tener en cuenta que se debe ingresar en el
sistema operativo y declararlo como ruteador, en primera instancia nos localiza-
mos en: /etc/rc.d y visualizamos el archivo rc.local y se agrega la sentencia: echo
"1))/proc/sys//net/ipv4/ip forward la ruta que se ha agregado es: route add -net
10.0.0.0 netmask 255.255.255.0 gw 170.0.0.2 de la misma manera ser insertada
en rc.visual con la finalidad de que a cada reinicio del servidor se configure como
ruteador y con la ruta para transportar trfico.
84

CAPTULO 3. ANLISIS DE TRFICO.
3.8.13. Resultados de la simulacin.

Despus de la configuracin del servidor, podemos realizar la administracin
del mismo desde un navegador (192.168.1.1) y podremos visualizar todas las con-
figuraciones, y el status del sistema.
Figura 3.13: Status del Sistema.

Para el caso de las extensiones que creamos podremos visualizar las activas y
las que no tienen la sesin activa:
Figura 3.14: Administracin de las extensiones.

85

CAPTULO 3. ANLISIS DE TRFICO.
Otra gran caracterstica que nos permite Asterisk es la generacin de reportes
por fecha o por extensin, con lo cual tenemos un registro de todas las activi-
dades. Adicionalmente se tiene la opcin de que cada llamada sea grabada, pero
esto requiere que el servidor tenga una gran capacidad de disco duro.
Figura 3.15: Reporte de llamadas.

Para recolectar resultados de nuestra simulacin visto desde el punto de trfi-
co se ha procedido a utilizar el software Wireshark desde la PC de un usuario
que pudiese ser el administrador de la red, con el fin de obtener resultados vi-
suales del ujo de protocolos e intercambio de mensajes que se mencionaron en
el primer captulo y sern analizados en diferentes escenarios como son: registro
de un usuario, establecimiento y terminacin de llamadas que sern presentados
a continuacin:
La extensin 1001 - Gerencia se est registrando en el servidor y el proceso
real es:
86

CAPTULO 3. ANLISIS DE TRFICO.
Figura 3.16: Registro de un usuario (extensin 1001-Gerencia) en servidor.
Para el establecimiento y terminacin de una llamada se realiz una llamada
entre dos softphones correspondientes a las extensiones 1001 - Gerencia y 1155 -
Conmutacin.
Figura 3.17: Establecimiento de llamada.

Para la finalizacin se ha tomado una llamada entre la red IP (ext 1001 -
Gerencia) y la PSTN (2807107).
87

CAPTULO 3. ANLISIS DE TRFICO.
Figura 3.18: Finalizacin de llamada.

A pesar de que no fue incluido en los objetivos de la tesis, se ha procedido a
realizar una video llamada entre softphones (Express Talk demo). Y de la misma
manera se analiz el trfico, los tipos de mensajes que circulan dentro de una
videollamada.
Figura 3.19: Establecimiento de videollamada.
88

CAPTULO 3. ANLISIS DE TRFICO.
Figura 3.20: Finalizacin de videollamada.

La generacin de una video llamada nos demuestra las bondades que pueden
ser entregadas por nuestro servidor Asterisk, el inconveniente que se presenta es
el terminal IP ya que sea un softphone (existen demos) o un telfono IP este
tiene su costo, pero de parte de nuestro servidor no existe restriccin alguna para
brindar este servicio.
Al visualizar todos los resultados podemos comprobar que todos los procesos
para la sealizacin se realizaron bajo el protocolo SIP con todos sus mensajes de
establecimiento de una llamada, mientras que para el transporte de la informa-
cin se realiz mediante el uso del protocolo RTP, recordemos que nuestro proxy
server (pedidos de sesin), redirect server (entrega direcciones ante pedidos de
clientes) y registrar server (acepta un registro) estn implementados sobre nues-
tro servidor Asterisk
Los resultado de la configuracin para el ruteo de trfico de nuestro servidor
se ver de la siguiente manera con la utilizacin del comando route -n.
Figura 3.21: Tabla de enrutamiento del Servidor Asterisk.
89
CAPTULO 3. ANLISIS DE TR 0AFICO.
La tabla de enrutamiento antes visualizada nos confirma que el trfico corres-
pondiente a la red 10.0.0.0 / 24 (paute) pueda comunicarse con la red 192.168.0.0
/ 24 (cuenca) a travs de la red 170.0.0.0/29 (red WAN).
90

S-ar putea să vă placă și