Vicidial con 150 posiciones en San Juan, PR
Nos por la mañana nos desmadrugó un cliente que tenemos en Puerto Rico (en México estamos 2 atrasados con respecto de ellos), indicándonos que los agentes no podian sacar llamadas al exterior en ocasiones. Algunas veces podían marcando manualmente, otras no.
Como antecedente, el cliente tiene 8 T1s en ISDN PRI, dándole un total de 23*8=184 canales totales. De ese total de canales, tiene 10 reservados en los primeros 2 T1s para solo inbound, y lo demás es outbound libre, de manera que los agentes toman cualquiera de los canales que estén disponibles para marcar al exterior.
Los T1s de salida estaban agrupados en uno solo, el grupo 0 (cero), con lo cual yo mandaba la llamada así:
[codesyntax lang=»php»]
exten => _787ZXXXXXX,n,Dial(DAHDI/r0/${EXTEN})
[/codesyntax]
De esta manera, no tengo que preocuparme por ver por cual canal mandar la llamada, sino que en round robin se irá rotando por el total de canales disponibles para outbound. En teoría todo está bien, pero…
Al momento de hacer pruebas, efectivamente, algunos agentes en ocasiones no podian sacarlas. El sistema no les daba error, sino que se quedaba en vacio, sin que nada apareciera o se escuchara. Si colgábamos y volviamos a marcar el mismo número, el resultado era diferente y la llamada ya pasaba.
¿Qué podía estar pasando?
Dedicimos probar uno por uno los T1s. Sin embargo, dado que sus canales estaban todos agrupados en uno solo, no nos era posible enviar llamadas que se distinguieran por cada uno de ellos. La solución fue modificar el chan_dahdi.conf para que se viera así:
[codesyntax lang=»bash»]
;;;;;;;;;;;;;;;;;;;;;;;;; ;; Llamadas de outbound ;;;;;;;;;;;;;;;;;;;;;;;;; switchtype=national context=trunkinbound group=0,21 echocancel=yes faxdetect=incoming signalling=pri_cpe channel =>13-23 group=0,22 channel =>38-47 group=0,23 channel =>49-71 group=0,24 channel =>73-95 group=0,25 channel => 97-119 group=0,28 channel => 169-191 ;;;;;;;;;;;;;;;;;;;;;;;;; ;; Llamadas de outbound - Marcacion especial ;;;;;;;;;;;;;;;;;;;;;;;;; switchtype=national context=trunkinbound group=1 echocancel=yes faxdetect=incoming signalling=pri_cpe group = 1,26 channel =>121-143 group = 1,27 channel => 145-167 ;;;;;;;;;;;;;;;;;;;;;;;;; ;; Llamadas de inbound ;;;;;;;;;;;;;;;;;;;;;;;;; switchtype=national context=trunkinbound group=9 echocancel=yes faxdetect=incoming signalling=pri_cpe channel =>1-12,25-37
[/codesyntax]
Observando el primer bloque de llamadas de outbound, veremos que los canales ahora siguen estando agrupados en el 0, pero también lo separé y cree los grupos 21-27. De esta manera, yo puedo escoger cuando marcar por cada uno de esos grupos y saber si el T1 está mal (recordemos que en señalización están perfectos porque no tienen alarmas, pero administrativamente la telefónica no le está dando servicio por alguno de ellos). La parte de las llamadas la resolví con esto dentro del extensions.conf:
[codesyntax lang=»bash»]
exten => _8Z787ZXXXXXX,1,Dial(DAHDI/r2${EXTEN:1:1}/${EXTEN:2});
[/codesyntax]
La idea es que marcando por ejemplo, 81 + 10 digitos estamos obligando a que la llamada salga por el T1 1. Si marcáramos con 82 saldría por el 2 y así sucesivamente. Esto le da la opción al administrador de hacer un debug y determinar si las llamadas por allí son efectivamente válidas.
Tras unos intentos de llamada fue posible notar que los T1s 3 y 5 no tenían salida a pesar de no estar alarmados. Como el formato de round robin se brinca aquellos canales que están alarmados, la solución sencilla fue desconectar físicamente esos T1s y reportarlos con la telefónica. Cundo le restauren el servicio, el administrador podrá conectarlos nuevamente y probarlos con 83 u 85 para comprobar que esos si sirven.
En este momento, el callcenter está operando correctamente y los agentes hacen llamadas de manera normal. Ahora solo resta a la telefónica resolver el problema para que todo esté al 100%.
¡Suerte!