1

Anlisis de trfico en un servidor de VoIP

Orlando Micolini, Member, IEEE; Augusto J. Herrera, GSM, IEEE; Vctor Sauchelli
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.
Resumen El presente trabajo busca realizar un estudio de
trfico sobre un servidor de VoIP. Lo que se pretende realizar es
un estudio que permita conocer cul es el trfico de
comunicaciones del sistema actual instalado y de esta manera cual
es el ancho de banda necesario para reemplazar un sistema de
telefona tradicional actualmente instalado por un sistema de
telefona IP. Luego de este estudio se utilizar un simulador para
conocer cul es el trfico mximo soportado por el servidor de
VoIP, de maneras de saber si puede soportar la carga del sistema
completo. Por ltimo se har un estudio que permita conocer cul
es el ancho de banda necesario para establecer un enlace entre dos
servidores de VoIP ubicados en dos sedes separadas por una
distancia de 3 Km.
Keyword VoIP, ancho de banda, BW, trfico, Erlang, SIP,
IAX, cRTP, cdec, g.711, g.729.

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 PSTN, 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.
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.

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

2
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
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.
1=

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

C. Estimacin del ancho de banda necesario

Conociendo la cantidad de canales estamos en condiciones
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.

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

V tVi c dm = 834 minutos

10

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:

V 1 n
ti V c d m Erlang
A
T T i 1
T
T

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
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.

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

V tV
i } c d m = 1600 min * 0,20 = 320 min
10

i 1

V 1 n
V c dm
A
ti
Erlang
T T i 1
T
T

La intensidad de trfico en la hora cargada ser entonces:

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

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.

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

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.
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].
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 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
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.

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

utilizando compresin IAX trunked.

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.

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.

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.

4
III. TRFICO MXIMO SOPORTADO POR EL SERVIDOR DE
VOIP
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
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
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 figura 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.
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.

5
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 figura 3 muestra la distribucin en el tiempo de las
llamadas generadas en funcin del nmero de llamadas totales.
Fig. 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.

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
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.
$ ./sipp -sn auc pacp -d 30000 -s 502 200.16.19.19 -l
200.16.19.24

Fig. 3 Llamadas totales y llamadas simultneas generadas por el simulador y

cursadas por el servidor de VoIP.

Como se observa en la figura, las llamadas llegan al

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.

Fig. 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

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 figura 4 se represetan los
datos de la tabla.

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.
REFERENCIAS
[1]
[2]

[3]
[4]
[5]
Fig. 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).

[6]
[7]

[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

7
BIBLIOGRAFA
Victor Sauchelli. Recibi su ttulo de Ingeniero Electricista Electrnico en
la Facultad de Ciencias Exactas, Fsicas y Naturales (FCEFyN) de la
Universidad Nacional de Crdoba (UNC) el ao 1971. Posteriormente recibi
su ttulo de Especialista en Educacin Universitaria en la Universidad
Tecnolgica Nacional Fac. Regional Crdoba en el ao 1999. En el ao
1997 recibi el ttulo de Doctor en Ciencias de la Ingeniera, tambin en
FCEFyN de la UNC. Actualmente es docente e investigador en la FCEFyN y
director de la Maestra en Telecomunicaciones de la misma Universidad.
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, tambin
de la UNC. Actualmente es alumno del doctorado en Ciencias Informticas de
la Universidad Nacional de La Plata y investigador de la Secretaria de Ciencia
y Tecnologa (SECyT), Director de la carrera Ingeniera en Computacin
(FCEFyN-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.
En sus aos de estudiante realiz una pasanta en el Departamento
Universitario de Informtica de la UNC y particip del proyecto
Implementacin de Software y Hardware para la optimizacin y
paralelizacin de Sistemas Computacionales aplicado a la Ingeniera
Hidrulica y Aeronutica, un proyecto de computacin distribuida
patrocinado por la Secretaria de Ciencia y Tecnologa (SECyT) de la
provincia de Crdoba. Actualmente es becario del Laboratorio de
Arquitectura de Computadores de la FCEFyN, donde realiza su trabajo final
de maestra.