Muy buenas noches con todos, hoy 30 de Enero y aún veo que no logro captar el interés de algún seguidor o lector....
Espero que está nueva publicación sea útil y de interés para uds ya que ASTERISK no es nada complejo ni ABURRIDO....
Si ya están trabajando podrán haber notado que a cada momento se nos presentan requerimientos... en mi caso la mayoría les diré que son de configuración ( ya sea por caídas con las llamadas al enrutarnos al proveedor, configurando nuevos servicios...) como de parte de mi trabajo, tengo que estar siempre en búsqueda de información y ayuda ya sea por parte de amigos que manejen el asterisk (que a cada momento lo solicito, como comprenderán soy nueva en esto también...) pero también una gran ayuda para mi es la web, aquí podemos encontrar de todo....
Especialmente para nosotros que recién empezamos en ASTERISK y
Pues les comentaré porque les digo esto, el día de ayer me pasó algo que no supe detectar a tiempo su origen (justo cuando ya me estaba retirando a la universidad PLOP!).
Las llamadas de un momento a otro se cayeron; empecé con lo que críe mas obvio verificar que el Internet no se haya caído (cosa que si hubiera sido ello tan solo era contactarme con el proveedor de este servicio) como anteriormente ya me había pasado hice pruebas tanto en la configuración del extension.conf y el sip.conf ( que es donde están configuradas las salidas y el tráfico de las llamadas hacia los proveedores de voz); pero no veía cual era el origen de las caídas, el tiempo pasaba y nesecitaba respuesta y una solución inmediata, opte por llamar al proveedor de voz, el cual optó por cambiarnos de plataforma , .. pero aún así el problema persistía ...... al revisar el tráfico de la empresa vio que las llamadas no salían por parte de nuestra ip hacia la de ellos para hacer la conexión ¿?, el ASTERISK!! lo revise y era que se había sobrecargado (el predictivo estaba emanando mucha carga lo cual hizo que se cayera) pues al revisarlo opte por levantarlo , y darle una refrescada tanto al ASTERISK como al predictivo GNUDIALER dándole la sentencia que ya conocemos
aterisk -rvvvvvvvvv
stop now //para detenerlo
asterisk //levantarlo nuevamente
gnudialer --stop //para detenerlo
gnudialer //levantar el predictivo
Pero para enrutar nuevamente nuestras llamadas hacia el el proveedor no fue inmediato,... teníamos que esperar que se refresque por su parte también ya que ahora estábamos con otra plataforma, ... esto tardo un promedio de 15 minutos (mucho tiempo tan solo para refrescar por parte del servidor del proveedor..) bueno las llamadas se estabilizaron...
Pero.... seguía con la incógnita que causó que se sobrecargara el predictivo ¿el tráfico? NOOO fue algo muy obvio el Switch se había sobre calentado cosa que no previne antes de que pasara esto .
Y como mi curiosidad es mucha entre a
Y que es esto se preguntarán ¿?; pues es en una red de estándar la información de voz y video se transmite junto con el resto de los datos de la empresa, si llegamos a cierto volumen que logre saturar los enlaces, los paquetes de voz y video que son altamente sensibles al jitter y delay producirán una calidad de sonido inaceptable.
Por ello al momento de escoger un códec en una instalación de telefonía IP debemos de tomar en cuenta 3 puntos muy importantes,
- El ancho de banda que requiere,
- El uso de Procesador
- La calidad.
Por ejemplo para una central que únicamente se comunica en una LAN es recomendable usar el Códec G.711 (uLaw y aLaw) que además de ser libre tiene muy buena calidad y hace poco uso del procesador al momento de codificarse.
Espero que a uds no les suceda........así que mucho ojo al momento de dar un diagnóstico, debemos ver todas las posibilidades hasta las más obvias.......
Entradas
