370

IEEE LATIN AMERICA TRANSACTIONS, VOL. 11, NO. 1, FEB. 2013

Traffic Analysis over a VoIP Server

O. Micolini, Member, IEEE, A. J. Herrera, IEEE
Abstract This paper describes a traffic study over a VoIP
server. The aim is to perform a study to know the traffic of
communications of the current system installed and so what is
the bandwidth needed to replace the existing traditional phone
system for a new IP telephony system. After this study we used a
simulator to know which is the maximum traffic supported by
the VoIP server, to know if the system can support all users
connected. Finally there will be a study to know what the
bandwidth needed to establish a link between two VoIP servers
located at two sites separated by a distance of 3 Km.
Keywords VoIP, bandwidth, BW, traffic, Erlang, SIP, IAX,
cRTP.

I. INTRODUCCIN

OS SISTEMAS de telefona IP han tenido un rpido

crecimiento y gran aceptacin en los ltimos aos, siendo
actualmente instalados y utilizados en una gran cantidad de
instituciones y universidades. El presente trabajo busca
conocer cules son las limitaciones que un servidor de VoIP,
de manera tal de conocer si es factible migrar el actual sistema
de telefona tradicional instalado en la Facultad de Ciencias
Exactas, Fsicas y Naturales (FCEFyN) de la Universidad
Nacional de Crdoba (UNC) por un nuevo sistema de
telefona IP.
El sistema actual instalado en la FCEFyN consiste en una
central de telefona tradicional con tres lneas directas
conectadas a la P STN, atendiendo 139 internos distribuidos
en la facultad. El estudio que se har busca conocer cual son
los requisitos necesarios para migrar este sistema a un sistema
de VoIP. Para ello se realizarn estudios estimado el trfico
cursado de manera de poder conocer cul es la cantidad de
canales que se deben utilizar como as tambin el ancho de
banda de cada canal.
Conocer el ancho de banda (BW) necesario para las
comunicaciones es uno de los puntos ms importantes de la
voz sobre IP, y depender en gran medida del protocolo y
cdec utilizado [1]. En nuestro caso realizaremos los clculos
utilizando el protocolo SIP, un estndar muy usado y
recomendado en varias RFCs, como as tambin el protocolo
IAX, un protocolo propuesto por los desarrolladores de
Asterisk como protocolo para usar en VoIP.
1

A. Ancho de banda de las comunicaciones de VoIP

Otro aspecto interesante es el cdec a utilizar en las
comunicaciones, el cual incidir directamente en el ancho de
banda necesario para implementar un sistema de VoIP. Al
momento de elegir un protocolo hay muchas opciones, entre
las ms importantes se encuentran los descriptos en la tabla I.

O. Micolini, Universidad Nacional de Crdoba, Crdoba, Argentina

omicolini@compuar.com
A. J. Herrera, Universidad Nacional de Crdoba, Crdoba, Argentina
augustojh@ieee.org

En nuestro caso solo no limitaremos realizar los clculos

con la suposicin de que utilizaremos los protocolo g.711 y
g.729, ya que realmente estos dos son los cdec que estn
utilizando el servidor de VoIP instalado. Sin embargo hay que
resaltar que el sistema maneja todos los protocolos arriba
mencionados.
B. Overhead agregado por los encabezados
Como vemos en la tabla I los cdec utilizan poco BW (a
excepcin del cdec g.711), sin embargo hay una sobrecarga
adicional introducida por los encabezados IP, UDP y RTP en
los paquetes de voz que termina incidiendo en el ancho de
banda final necesario para establecer las comunicaciones.
En nuestro caso, como ya dijimos, solo utilizaremos para
realizar las pruebas los cdec g.711 y g.729, dentro de la red
ethernet. De [2] [3] obtenemos que el ancho de banda
aproximado necesario para cada cursar cada comunicacion
ser de 95 kbps para el cdec g.711 (Ethernet + IP + UDP +
RTP + G.711) y 31,2 kbps para g.729 (Ethernet + IP + UDP +
RTP + G.729). Conociendo estos datos, haremos ahora un
estudio para estimar cuantos canales se necesitan y cul es el
ancho de banda necesario para cursar las comunicaciones.
II. ANLISIS DE TRFICO MTODO ERLANG
A. Mtodo Erlang
Erlang es una unidad de medida utilizada en teletrfico[ 4]
[5] para medir el trfico de las comunicaciones. En la prctica
es usado para describir el volumen de trfico por hora. Estas
medidas se hacen para establecer el tamao del troncal
necesario para cursar el trfico de las comunicaciones. En
nuestro caso lo utilizaremos para conocer cul es el volumen
de trfico cursado, cual es el ancho de banda necesario y
cuantos canales de datos o nmero de enlaces son necesarios
para reemplazar el sistema de telefona existente en la
FCEFyN.
Una de las variables que necesitamos conocer o estimar
para realizar los clculos es el grado de servicio (GoS), que
define la probabilidad de que las llamadas sean bloqueadas
por falta de lnea. En nuestro caso vamos a adoptar un GoS de
0,05 (5 llamadas bloqueadas cada 100 ofrecidas).
Con todo esto estamos en condiciones de calcular la

MICOLINI AND HERRERA : TRAFFIC ANALYSIS OVER A VOIP SERVER

cantidad de canales necesarios y el ancho de banda para

realizar las comunicaciones. Para ello estimaremos el trfico
ofrecido y el volumen de trfico.
B. Trfico ofrecido
Para realizar una estimacin de trfico ofrecido vamos a
suponer que cada uno de los 139 internos que hay en la
FCEFyN realiza dos llamadas de 3 minutos en la hora
cargada. El clculo utilizando esa estimacin suele ser
bastante acercado a la realidad. Con estos datos podemos
calcular el volumen de trfico, es decir el tiempo total
acumulado de las comunicaciones.

371

de estimar el ancho de banda necesario, el cual depender de

los cdec utilizados para las comunicaciones. Como vimos en
la seccin anterior solo se utilizarn dos cdec, g.711 y g.729,
que requieren un ancho de banda de 95 kbps y 31,2 kbps por
llamada, respectivamente. Con todo esto el ancho de banda
del enlace ser el mostrado en la tabla II.

10

V = ti =

(1)

i =1

V = 139 usuario * 2 llamada/usuario * 3 min/llamada

10

V = tVi = c d m = 834 minutos

(2)

i =1

Donde c es la cantidad de solicitudes de servicio y dm la

duracin media de cada llamada.
La intensidad de trfico (o simplemente trfico) ser
entonces:

A=

V
1
=
T T

t
i =1

V c dm
=
[ Erlang ]
T
T

(3)

A = 834 minutos/60 minutos = 13,9 Erl

Donde T = 60 minutos corresponde a la hora cargada.
Otra forma de calcular la intensidad de trfico es teniendo
en cuenta el trfico por usuario.
Trfico por usuario = 2 llam/hora * 3 min/llam/60 min
Trfico por usuario = 0,1 Erl = 100 mErl
Intensidad de Trfico = 139 usuarios *100 mErl = 13,9 Erl

Ancho de banda necesario para migrar el actual sistema de telefona de la

FCEFyN a un sistema de VoIP.

D. Enlace CU-Centro. Interconexin de dos server VoIP

Seguidamente vamos a estimar el ancho de banda necesario
para establecer un enlace que permita cursar trfico de
comunicaciones de VoIP entre las facultades del centro y
Ciudad Universitaria (CU). Cabe resaltar que esto est siendo
estudiado y hay un proyecto a futuro para unir las dos sedes
(Centro y CU) a travs de dos servidores de VoIP, utilizando
el protocolo IAX.
Para simular este enlace vamos a suponer que el volumen
de llamadas entre las dos sedes es de 1600 minutos por da,
siendo el 75 % de la carga en el trayecto C.U. - Centro y el
restante 25 % en el trayecto Centro CU.
Adems suponemos que la generacin de trfico es
aleatoria (algo aproximado a la realidad), que las llamadas
bloqueadas son rechazadas y que vamos a trabajar con un
grado de servicio estimado de 0,02 (GoS = 2 %).
En este caso para calcular la intensidad de trfico debemos
estimar la cantidad de llamadas realizadas en la hora cargada,
por lo que vamos a asumir que el 20 % de las llamadas se
realizaron en esta hora.
Como el volumen de trfico es conocido, en la hora cargada
tendremos
10

V = ti = c d m = 1600 min * 0,20 = 320 min

i =1

La intensidad de trfico en la hora cargada ser entonces:

A=

V
1
=
T T

t
i =1

V c dm
=
[ Erlang ]
T
T

A = 240 minutos/60 minutos = 5,33 Erl

Figura 1. Trfico ofrecido, cursado y canales necesarios para el caso

estudiado.

Utilizando el modelo Erlang B, y teniendo en cuenta un

grado de servicio de 0,02 %, la cantidad de canales necesarios
ser, utilizando la tabla, de 11 canales. Con todo esto, el ancho
de banda ser el mostrado en la tabla III.

De las tablas de Erlang B [6] para un trfico de 13,9 Erl y

una probabilidad de bloqueo del 5 % se obtienen la cantidad
de canales necesarios. En este caso se obtienen 19 canales
(Fig. 1) para cursar el trfico en el peor de los casos, que es la
hora cargada.
C. Estimacin del ancho de banda necesario
Conociendo la cantidad de canales estamos en condiciones

Ancho de banda necesario para establecer un enlace entre las sedes Centro y
Ciudad Universitaria (CU) de la FCEFyN.

372

IEEE LATIN AMERICA TRANSACTIONS, VOL. 11, NO. 1, FEB. 2013

Con lo cual alcanza con contratar un ancho de banda

dedicado de 1 MB para cursar el trfico estimado. Vale decir,
con un ancho de banda de 1 MB (utilizando codificacin
g.711) o 512 KB (utilizando codificacin g.729) se podrn
cursar 5,33 Erl de trfico con un bloqueo del 2 % en las
comunicaciones de VoIP entre ambas sedes de la FCEFyN.

comunicacin necesitar 81,2 kbps, mientras que las

siguientes solo 65,9 kbps. Vale decir, esta tcnica utiliza el
mismo encabezado cuando existe ms de una llamada.
Existen muchos estudios relacionados con la compresin
IAX [8], los cuales nos permiten calcular el ancho de banda
necesario para establecer las llamadas estimadas en el punto
anterior, mostrado en la tabla VI.

E. Estrategias de reduccin de ancho de banda

Se puede reducir el en gran medida el ancho de banda
utilizado en las comunicaciones de VoIP. Hay dos maneras
muy utilizadas para hacerlo, una de ellas es utilizar
compresin en el encabezado RTP, en el caso de utilizar el
protocolo SIP, y la otra es utilizar el modo IAX Trunked, solo
vlido en el caso de utilizar el protocolo IAX para las
comunicaciones [7].

Disminucin del ancho de banda necesario para el primer caso de estudio,

utilizando compresin IAX trunked.

1) Compresin RTP
Esta tcnica, denominada cRTP (Real Time Protocol
header Compression) permite llevar el overhead agregado por
los encabezados IP/UDP/RTP de 40 bytes a solo 2 o 4 bytes,
con lo cual el ancho de banda que ser necesario para cursar el
trfico estimado en el punto anterior ser mucho menor.
En el caso del cdec g.729 permite reducir el BW de cada
llamada de 31,2 kbps a 11,2 kbps, mientras que el cdec g.711
puede reducirse de 96 kbps a 70,4 kbps. Con todo esto, BW
necesario con compresin cRTP para cursar el trfico de VoIP
de la FCEFyN se muestra en la tabla IV.

Disminucin del ancho de banda necesario para el primer caso de estudio,

utilizando compresin cRTP.

En el caso del enlace entre los dos servidores VoIP de CU y

Centro, el ancho de banda necesario utilizando compresin
cRTP ser el mostrado en la tabla V.

Disminucin del ancho de banda necesario para el segundo caso de estudio,

utilizando compresin cRTP.

2) Compresin IAX Trunked

Actualmente se estn realizando pruebas entre dos
servidores de VoIP Asterisk con la idea de disponer uno en la
FCEFyN sede Centro y otro en la sede CU. Estos servidores
estn conectados mediante el protocolo IAX2 (propietario de
Asterisk) y la utilizacin del modo trunked permite disminuir
drsticamente el BW necesario para las comunicaciones. En el
caso de utilizar el cdec g.729 solo se utilizarn 30 kbps para
estableces la primera comunicacin y los dems encabezados
sern reaprovechados, haciendo que cada comunicacin nueva
no supere los 9,6 kbps. Para el cdec g.711 la primera

En el caso del enlace entre los dos servidores Asterisk de

CU y Centro, el ancho de banda necesario utilizando IAX
Trunked es el mostrado en la tabla VII.

Disminucin del ancho de banda necesario para el segundo caso de estudio,

utilizando compresin IAX trunked.

Como podemos observar el ancho de banda requerido es

levemente inferior en el caso de utilizar el cdec g.729 con
IAX trunked respecto de compresin cRTP mientras que en el
caso de utilizar el cdec g.711 el ancho de banda pasa a ser
levemente superior en el caso de utilizar IAX trunked.
III. TRFICO MXIMO SOPORTADO
VOIP

POR EL SERVIDOR DE

En la seccin anterior estimamos el trfico que puede ser

cursado y la cantidad de canales y ancho de banda necesario
para cursar ese trfico. Sin embargo desconocemos si el
servidor de VoIP soporta este trfico, vale decir, si puede
atender a los 139 internos que hay en la FCEFyN, sede CU.
Debido a esto haremos un estudio que nos permita conocer
cul es el trfico mximo que soporta el servidor, esto es
cuantas llamadas simultneas pueden ser cursadas sin tener
problemas de degradacin de rendimiento.
A. Limitaciones de trfico
Hay dos limitaciones en cuanto al trfico mximo de
llamadas que podrn cursarse. Uno es el ancho de banda, que
ya fue estimado en la seccin anterior y no presenta un
problema a la hora de atender todas las solicitudes. El otro
limitante es la capacidad del servidor para atender las
llamadas, ya que cada solicitud requiere una cierta cantidad de
procesamiento (ver tabla I).
Hay que tener en cuenta que cada llamada utiliza una cierta
cantidad de memoria y carga al servidor con una determinada

MICOLINI AND HERRERA : TRAFFIC ANALYSIS OVER A VOIP SERVER

cantidad de procesamiento. Si bien el BW puede ser

suficiente, veremos que el servidor tiene un lmite en cuanto a
cantidad de llamadas simultneas que puede atender ya que su
poder de procesamiento es limitado.
B. Medicin del trfico
Para medir el trfico mximo soportado por el servidor se
utilizar el simulador sipp y se generarn llamadas utilizando
el protocolo SIP, verificando el trfico que puede ser atendido
por el servidor de VoIP a medida que se incrementa de
manera gradual el trfico de las llamadas.
Lo que se simula con el software es el incremento en la
carga del sistema, vale decir que se simulan llamadas
telefnicas que son cursadas por el servidor. Estas llamadas
pueden ser incrementadas gradualmente en el tiempo, esto se
hace hasta llegar a un valor en el cual el servidor no puede
atender ms llamadas debido a la elevada carga que presenta
el sistema por la excesiva cantidad de llamadas que estn
siendo cursadas simultneamente. Este valor es el que se
quiere encontrar, el cual servir en un futuro para saber con
exactitud cuntos internos se pueden disponer para trabajar
sobre este servidor sin tener problemas de trfico.
Lo que haremos a continuacin es medir el desempeo del
servidor a medida que aumenta la cantidad de llamadas. Hay
que resaltar que Asterisk maneja un gran cantidad de
protocolos pero el que vamos a medir es este caso SIP, que es
el protocolo ms usado actualmente en telefona IP.
El generador de trfico sipp genera un nmero elevado de
llamadas simultneas al servidor de VoIP. Este nmero, en
cuanto a cantidad y duracin, es totalmente configurable, por
lo que permite incrementar las llamadas gradualmente y de
esa manera realizar las mediciones. Para realizar la medicin
haremos una llamada telefnica (real) entre dos usuario SIP y
con el programa sipp iremos aumentando gradualmente las
llamadas (simuladas) hasta llegar a un momento en que la
comunicacin establecida por los dos usuarios SIP presenta
una calidad totalmente inaceptable. Esto nos permitir
conocer el trfico mximo que el servidor puede cursar de
manera tolerable con el hardware que disponemos.
C. Simulador sipp
Esta herramienta permite enviar trfico RTP, lo cual hace
que los resultados obtenidos con el test sean totalmente
confiables y muy aproximados a lo que realmente sucede
cuando se cursa una llamada. Recordemos que el protocolo
SIP trabaja enviando trfico RTP en cada llamada. Hay que
tener en cuenta que esta herramienta utiliza un compilador de
C++, las libreras ncurses, libnet, etc., por lo que todas estas
aplicaciones deben estar instaladas en el servidor antes de
instalar el simulador sipp.
D. Configuracin del servidor de VoIP para la medicin
del trfico
Para poder utilizar el generador de trfico y poder realizar
las mediciones debemos generar un usuario SIP en el servidor.
Esto se hace modificando el archivo de configuracin
sip.conf, creando un usuario que se utilizar para realizar las
pruebas

373

Luego se debe definir que comportamiento tendr este

usuario cuando se llame a su extensin. En nuestro caso el
contexto [contexto] del archivo extension.conf, que es el
asignado a las llamadas que genera el simulador, solo
reproduce un archivo de audio, sin realizar alguna tarea til.
E. Diseo y configuracin del entorno de pruebas
Este es un proceso fundamental ya que del buen
planteamiento de las pruebas depende obtener resultados
confiables. El primer paso es disear el escenario sobre el cual
se van a realizar las pruebas, ya que nuestro objetivo es
simular una situacin real de trfico sobre el servidor. El
escenario mostrado en la Fig. 2 es el que vamos a utilizar,
donde una PC ataca al servidor con una cantidad creciente de
llamadas, simulando clientes que quieren realizar llamadas, y
de esta manera cargando al servidor.

Figura 2. Entorno de pruebas utilizado para la simulacin. En amarillo, la

llamada real cursada entre dos usuarios SIP. En rojo las llamadas simuladas
por el software sipp contra el servidor de VoIP.

Adems de esto estableceremos una llamada telefnica

entre dos usuarios SIP que se encuentran en la misma red.
Luego incrementaremos progresivamente la cantidad de
llamadas generadas por el simulador hasta el momento en que
la comunicacin se hace inaceptable. Esto nos permitir
conocer la cantidad de llamadas mximas que puede cursar el
servidor sin tener problemas de rendimiento.
Hay que resaltar que no se utilizar transcoding, por lo que
la carga del servidor ser menor y su rendimiento el mayor
que puede obtenerse.
F. Medicin del trfico mximo soportado
Una vez que estn los usuarios creados y su
comportamiento en el dialplan pasaremos a medir el trfico
mximo. Para ello utilizaremos uno de los escenario que trae
la herramienta que permite enviar trfico RTP utilizando el
cdec uLaw, uno de los ms comunes.
Para que el test resulte exitoso debemos elegir un promedio
de duracin de llamadas elevado de manera que el nmero de
llamadas que se crean por segundo sea mayor que las que

374

IEEE LATIN AMERICA TRANSACTIONS, VOL. 11, NO. 1, FEB. 2013

terminan, caso contrario ser imposible encontrar la capacidad

mxima del servidor. Con todo esto podremos encontrar el
momento en el cual el servidor de VoIP deja de funcionar
adecuadamente, haciendo imposible cursar una comunicacin
entre dos usuarios SIP.
1) Corrida del simulador
Para utilizar los escenarios que trae la aplicacin
simplemente se agrega la opcin -sn seguida del nombre del
escenario. Tambin se puede controlar la duracin de las
llamadas con la opcin -d y la cantidad mxima de llamadas
simultneas con la opcin -l. Con la opcin -s seguida de la IP
del servidor especificamos el interno al cual llamaremos
(definido en el archivo extensions.conf) y con la opcin -i el
IP de la PC que lanz el simulador, en caso de que no sea el
mismo servidor de VoIP.
Para correr el simulador con estos parmetros nos ubicamos
en la carpeta donde esta descomprimido y compilado y
ejecutamos la siguiente lnea de comandos.

servidor de forma progresiva (lnea roja). Luego de 30

segundos se alcanza el nmero mximo de llamadas
simultneas configurado (lnea azul), el cual se mantiene
durante un periodo de tiempo, ya que algunas llamadas
finalizan a la vez que otras cuantas son generadas. En ese
momento el servidor est consumiendo el mayor nmero de
recursos. Cuando el lmite de llamadas totales a realizar ha
sido alcanzado, el cliente sipp ya no genera ms llamadas y
las llamadas que estn llevndose a cabo van finalizando
progresivamente hasta que no queda ninguna en curso.
G. Resultados obtenidos
Mientras el simulador corra se observaron el consumo de
CPU y memoria en el servidor a medida que aumenta el
nmero de llamadas generadas. Las tablas VIII y IX muestran
los resultados obtenidos luego de varias simulaciones.

$ ./sipp -sn auc pacp -d 30000 -s 502 200.16.19.19 -l

200.16.19.24
y luego observamos la pantalla del simulador y del
servidor. La pantalla nos mostrar las llamadas generadas por
segundo y el lmite mximo que se puede cursas
simultneamente en el sistema. Las llamadas generadas se
pueden incrementar unitariamente con la tecla + o duplicar
con la tecla *. De la misma manera se pueden utilizar las
teclas y / para decrementar las llamadas generadas.
La duracin de cada llamada la setearemos en 30 segundos,
mientras que la cantidad mxima de llamadas simultneas ser
1000. Para las pruebas se aumentar el nmero de llamadas en
forma proporcional y progresiva, mantenindose el ratio de
llamadas (generacin de llamadas por segundo) constante,
comprobando en cada ejecucin el uso de CPU y memoria y
llamadas completadas, para as obtener el lmite mximo de
llamadas que se pueden cursar.
La Fig. 3 muestra la distribucin en el tiempo de las
llamadas generadas en funcin del nmero de llamadas
totales.

Como puede observarse en la primera corrida, con

intervalos de muestras cada 250 llamadas, el servidor empieza
a mostrar dificultades a las 500 llamadas, con un utilizacin
del CPU de ms del 80 %. En la Fig. 4 se represetan los datos
de la tabla.
Figura 3. Llamadas totales y llamadas simultneas generadas por el simulador
y cursadas por el servidor de VoIP.

Como se observa en la Fig. 3, las llamadas llegan al

MICOLINI AND HERRERA : TRAFFIC ANALYSIS OVER A VOIP SERVER

375

REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
Figura 4. Resultados de la primera corrida. Se puede observar que a las 500
llamadas el consumo de CPU es mayor al 80%.

Para encontrar un valor ms exacto se tomaron muestrascon

intervalos de 100 llamadas, mostrando en realidad a las 400
llamadas el servidor empieza a mostrar problemas, por lo que
no es capaz de cursar esta cantidad de llamadas simultneas,
ya que empieza a mostrar problemas de rendimiento (Fig. 5).

Figura 5. Resultados de la segunda corrida. Se puede con ms detalle que a

las 400 llamadas el consumo de CPU es mayor al 80%, mostrando el servidor
problemas de rendimiento.

Con todo esto, la cantidad mxima de llamadas simultneas

que pueden cursarse no debe exceder las 400 comunicaciones,
una cantidad ms que suficiente para atender los 139 internos
que presenta la sede CU de la FCEFyN.
IV. CONCLUSIONES
En la el presente informe se hace un estudio de trfico sobre
un servidor de VoIP. En la primera parte se estudia cuantos
canales se necesitan para migrar el sistema telefnico actual a
un sistema de VoIP y cul es el ancho de banda necesario,
llegndose a la conclusin de que con una lnea dedicada de 2
MB es suficiente, utilizando el protocolo SIP e IAX con los
cdec g.711 y g.729 para las comunicaciones. Se observ
adems que la compresin IAX trunked es mejor si utiliza el
cdec g.729, mientras que si utilizamos el cdec g.711 para
las comunicaciones lo mejor ser utilizar compresin cRTP.
En la segunda parte del informe se estudia la capacidad
mxima del servidor, para conocer si es capaz de soportar a
todos los internos actualmente instalados. Con el simulador
sipp se pudo observar que el servidor puede cursar ms de 400
llamadas simultneas sin tener problemas de rendimiento, con
lo cual puede atender a todos los internos sin presentar
problemas de degradacin en la calidad de las llamadas.

[8]

J. M. Gonzbal, Clculo de Ancho de Banda en VoIP, 2008.

M. A. Vasco Martnez, Dimensionamiento de una central telefnica IP
utilizando estndares abiertos y software libre, ESPOL, 2009, pp. 9395.
J. C. Varela, Trfico telefnico en redes VoIP, Univ. Costa Rica,
2006, pp. 135-136.
(Webpage/Online
sources)
Wiki,
Erlang.
Available:http://es.wikipedia.org/wiki/Unidad_Erlang.
(Webpage/Online
sources).
Wikitel.
Teletrfico.
Available:es.wikitel.info/wiki/Teletrfico.
(Basic Book/Monograph Online Sources) D. Tipper. Erlang B Traffic
Table. Available: www.sis.pitt.edu/~dtipper/2110/erlang-table.pdf
(E-bbok/Cisco) Cisco,Voice over IP - Per Call Bandwidth
Consumption.
Available:www.cisco.com/en/US/tech/tk652/technologies_tech_note091
86a0080094ae2.shtml
(Webpage/Online Sources) Voip-info.org. Asterisk Bandwidth iax2.
Available: www.voip-info.org/wiki/view/Asterisk+bandwidth+iax2

BIBLIOGRAFA
Orlando Micolini (M87) Naci en la ciudad de Crdoba,
Argentina, en el mes de diciembre, del ao 1956. Se gradu
de Ingeniero Electricista Electrnico en la Facultad de
Ciencias Exactas, Fsicas y Naturales de la Universidad
Nacional de Crdoba (UNC) el ao 1982. Recibi su ttulo de
Especialista en Telecomunicaciones en el ao 2000, en la
misma Universidad. En el ao 2006 recibi el ttulo de Magster en
Telecomunicaciones (UNC). Actualmente es alumno del doctorado en Cs.
Informticas de la Universidad Nacional de La Plata, Director de la carrera
Ing. en Computacin (UNC) y Asesor externo en las empresas SCS SRL y
Nutus.
Augusto Herrera (SM04GSM07) Naci en La Plata,
provincia de Bs. As., Argentina, en el ao 1980. Recibi su
ttulo de Ingeniero Electrnico en la Facultad de Ciencias
Exactas, Fsicas y Naturales de la Universidad Nacional
(UNC) de Crdoba el ao 2006. Actualmente se encuentra
finalizando los estudios de Maestra en Ciencias de la
Ingeniera, mencin Telecomunicaciones, en la misma Universidad.
Actualmente es becario del Laboratorio de Arquitectura de Computadores de
la FCEFyN, donde realiza su trabajo final de maestra.