Contact Us

Prueba de Capacidad

21
Dic

Se empeñan los usuarios de Grandes empresas, revendedores, y similares de preocuparse primero por la capacidad del servicio que les podemos brindar para la terminación de su trafico, así como para el acceso geográfico. Pues bien, aquí nos ocuparemos tan sólo de la capacidad de terminación.

Las cuentas SipCel, por defecto son limitadas a apenas dos llamada simultaneas, pudiendo ampliarse esa capacidad tanto que el cliente necesite, en razón de capacidades de facturación simultanea, así como capacidades por IP de origen, o canal SIP, sin coste añadido, a petición del cliente, y según sus necesidades, es decir, es un servicio adhoc, pero gratuito.

Ahora bien, sobre la capacidad simultanea asignada teóricamente existen muchos otros factores que pueden afectar a la interoperatibilidad real del servicio, y su interacción con la red del cliente. Tales como la latencia del Jitter, la capacidad del ancho de banda del propio cliente final, así como y desde luego el codec usado para transmisión de los paquetes.

Para hacer efectivo todo ello, no basta la simple puesta en marcha del trafico real. Pues antes de ello, cabe la posibilidad de realizar ciertas pruebas gratuitas para garantizar la interoperabilidad, una vez interconectados. Pues para ello estamos aquí en ese tutorial donde vamos a usar la aplicación SIPP, que es una muy valiosa y últil herramienta de pruebas, que nos generará llamadas reales desde el cliente, en varias opciones y modalidades hacía la red de SipCel, para efectuar una simulación de trafico real y comprobar la capacidad operativa del servicio.

Primero tendremos que instalar el SIPP, para ello. Pues para ello, primero necesitamos preparar los paquetes necesarios, previos a la compilación. Pues dependiendo de su SO, usando el yun en el Redhat y compañía, el apt, o aptitude en los Debians, necesitamos cargar e instalar los siguientes paquetes:

 
yum install make gcc gcc-c++ ncurses ncurses.x86_64 ncurses-devel ncurses-devel.x86_64 openssl libnet libpcap libpcap-devel libpcap.x86_64 libpcap-devel.x86_64 gsl gsl-devel

Ahora bien, el paquete del SIPP esta disponible en el sourceforge, necesitamos comprobar aquí, la ultima versión disponible, y lo descargamos. En este ejemplo, y a fecha de redacción de este tutorial la ultima versión es la 3.3.9, por lo que vamos a dar a:

wget http://downloads.sourceforge.net/project/sipp/sipp/3.3/sipp-3.3.tar.gz

Untaremos el tar, y accedemos al fichero. Una vez allí, le damos el ./configure, luego el make, y una vez hecho, y que veamos todo correcto, instalamos con el make install

Una vez instalado, o si ya lo tiene instalado en su maquina, a continuación vamos a poner la prueba de simulación en marcha.

Dentro del directorio del sipp, podemos en cualquier momento darle al:

./sipp –help

Si queremos que nos imprime las opciones.

Lo que nos importa en esa prueba es:

  1. Que su cuenta en SipCel este activada, y que haya tramitado el servicio multicanal, y que se le hayan asignado los canales necesarios para su necesidad. En este ejemplo, vamos a suponer que su cuenta ya tiene activados 100 canales simultáneos.
  2. Que su servidor ya esta autorizado, y asociado a esa cuenta SIP, bajo autenticación IP.
  3. En SipCel se acepta la prueba de simulación llamando al número 2005, que es el número de simulación de llamadas sin coste ninguno. Esa simulación no aparecerá en el CDR de su cuenta, por lo que no se preocupe por sus estadísticas, ni facturación.

Para arrancar el test, y probar la capacidad operativa de 100 llamadas simultaneas, ponemos ese comando, donde hemos de sustituir la IP de SipCel, por la IP indicada por el NOC para su referencia geográfica:

./sipp -sn uac -d 20000 -s 2005 la-IP-de-SipCel -l 10000 -trace_err -m 2000 -r 100

En esa prueba, el programa generará un total de 2000 llamadas, con un flujo de 100 llamadas simultaneas, y las impulsará en varios paquetes, para una duración de 2000 milisegundos para cada llamada, con la opción de cliente final, UAC, es decir, esa es la opción real que usaremos para el servicio, como cliente de sofrphone, dispositivo IP, o cualquier otro.

Hemos de esperar, el programa correrá y nos ofrecerá los resultados él mismo con varios datos, de los cuales lo que más nos concierne aquí es:

Successful call, que se refiere al número de llamadas correctamente cursadas, en la columna del acumulativo, en referencia con la siguiente línea del: Failed call.

También, en la primera línea, podemos leer el Call Rate, que se refiere al ratio promedio de llamadas por segundo cursadas durante la prueba. OJO a que el CPS se refiere a las llamadas por segundo, y NO las llamadas simultaneas, que es otra cosa. Las llamadas por segundo, son las llamadas que se hayan generado por un promedio del segundo. Las llamadas simultaneas se refiere a las llamadas acumulado en un periodo de un segundo, dentro del ratio de capacidad, del canal. Hay que considerar ese número, en referencia al total de llamadas correctas, y si existen llamadas fallidas, a ver el motivo de los fallos. Si el número de las llamadas fallidas es elevado, el CPS es bajo, querrá decir que estamos sufriendo algún problema de ancho de banda, latencia del jitter, en caso de elevado número de timeout, o en caso de que el CPS es alto, y no existen llamadas fallidas, sería todo lo contrario, que alegremente el ancho de bando ha sido muy tranquilo, y que el trafico podrá fluir con ligereza. Además, el resultado de esa prueba, no es del todo concluyente, pero su estimación superaría el 90%, pues por un lado, influye el tiempo promedio de respueta de las llamadas, así como la hora de la prueba peak/unpeak. Es recomendable, por ejemplo, a la vez de realizar esa prueba, y simultáneamente, intentar emitir una llamada real, por el mismo canal, a un número real, o por lo menos al número 123, de prueba del eco, para comprobar la calidad del media, simultáneamente con la prueba, ya que así podemos saber tanto la capacidad, como la constancia de la calidad de la voz en máxima sobrecarga.

Desde luego, es posible realizar la prueba con llamadas reales, pero evidentemente, esas llamadas reales serán facturadas a la cuenta del cliente, y a tener en cuenta, que el número final llamado, que tenga una capacidad real, y simultanea de recibir tanto número de llamadas simultaneas, salvo que sea otra máxima, para probar esa terminación.

Por ejemplo, si queremos hacer una prueba con tráfico real, o sea, a un destino real, que será facturable, como por ejemplo el número +51 16409003, suponiendo que ese número es un DID, o un RDSI con 100 canales, conectado a IVR, o similar, sería que hagamos lo hagamos con el siguiente comando:

./sipp -sn uac -d 20000 -s 5116409003 la-IP-de-SipCel -l 10000 -trace_err -m 2000 -r 100

De esta manera, el SIPP emitirá 2000 llamadas con un flujo de 100 simultaneas, por duración de 20000 ms al número indicado.

Esperemos que esa prueba les sirva de utilidad para corroborar la interoperabilidad con la red, y la capacidad de ésta.

Leave A Reply

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Time limit is exhausted. Please reload the CAPTCHA.