Preguntas frecuentes sobre los SBC
Las sesiones determinan el número de llamadas simultáneas que el SBC puede gestionar.
Las sesiones se pueden ampliar en los SBC mediante un cambio de configuración, una vez gestionadas administrativamente con el fabricante:
Ejemplo de sesiones activadas en Oracle:
SBCsSBC # mostrar derechos Derechos
aprovisionados:
——– —————–
Controlador de borde de sesión empresarial Base: habilitado
Capacidad de sesión: 100
Avanzado: habilitado
Seguridad de administrador:
Derechos con clave (con licencia)
———– ——————
SBCM #Al planificar un aumento de sesiones, es importante tener en cuenta la capacidad de los elementos circundantes y la propia red que soporta el servicio. Es decir, por un lado, tanto la centralita como el núcleo central deben tener un número de licencias igual o menor al configurado en el SBC. Por otro lado, el acceso proporcionado por el operador para soportar el servicio debe estar dimensionado con el ancho de banda necesario.
La configuración del aumento de sesiones podría implicar un corte del servicio en caso de que sea necesario ampliar el número de puertos dedicados y este aumento implique un cambio de rango.
Para monitorear el servicio, Oracle cuenta con la herramienta Operation Monitor (EOM en su versión empresa, OCOM en su versión operador) que permite analizar sistemas VoIP en tiempo real y almacenar datos históricos para estudios posteriores.
El Monitor de Operación proporciona la visualización de las trazas en formato diagramático y la correlación de la llamada entre los diferentes elementos de la red, proporcionando una visión completa de la llamada para su análisis.
Además, ofrece la posibilidad de definir umbrales y generar y enviar alertas en función de diversos KPIs, simplificando las tareas de monitorización de los servicios.
También permite funcionalidades como análisis de tráfico por elemento, análisis por troncal, estadísticas, filtrado de datos históricos por numeración, filtrado por fecha o periodo de tiempo, análisis de QoS de llamadas, jitter, etc.
Los distintos fabricantes de SBC incorporan mecanismos para verificar su uso. Por ejemplo, Oracle cuenta con estadísticas que muestran la capacidad total de sesiones configuradas en las máquinas, el consumo actual de sesiones y los picos de sesiones simultáneas consumidas desde el último reinicio.
SBC # show sessions Capacity = 100 Session Statistics - Period - -------- Lifetime -------- Active High Total Total PerMax High Total Sessions 6 8 14 457 861 66 69 SIP Sessions 6 8 14 457 861 66 69 H.323 Calls 0 0 0 0 0 0 IWF Statistics - Period - -------- Lifetime -------- Active High Total Total PerMax High H.323-to-SIP Calls 0 0 0 0 0 0 SIP-to-H.323 Calls 0 0 0 0 0 0 SIP Audio / Video Statistics - Period - -------- Lifetime -------- Active High Total Total PerMax High Audio Calls 6 8 12 371 699 57 68 Video Calls 0 0 0 0 0 0 SBC #En los casos en que se requiera un análisis más exhaustivo de las estadísticas de uso, recomendamos instalar la herramienta de monitoreo de tráfico Oracle Operation Monitor. Con esta herramienta, el cliente puede monitorear llamadas, obtener informes por troncal, por mes, por numeración, etc., y obtener una amplia gama de estadísticas e informes.
Los distintos fabricantes de SBC incorporan distintos mecanismos para la detección y corrección de errores de hardware. Por ejemplo, los SBC de Oracle cuentan con imágenes de diagnóstico que pueden cargarse y ejecutarse para analizar el hardware del equipo y verificar su estado.
En caso de detectar problemas en el SBC, ya sea por la ejecución de un diagnóstico o por inoperatividad del equipo, se articulan RMAs con el fabricante, completas o parciales según el fabricante del SBC, modelo del equipo y el elemento afectado.
El fabricante gestiona el envío del recambio en cuestión a la sede del cliente para proceder a la sustitución y recuperación del servicio afectado.
Sí. Existe la falsa creencia de que solo los SBC Ribbon o Audiocodes lo admiten. Desde la versión 8.3, Oracle proporciona las funcionalidades necesarias para adaptarse a los requisitos de Microsoft Teams y configurar el enrutamiento directo. Esta funcionalidad de Teams permite a los usuarios comunicarse con la PSTN.
El SBC permite adaptar la codificación de los mensajes en función de las negociaciones entre la centralita y la red del operador.
Si es necesario negociar diferentes códecs en ambos extremos de la llamada, el SBC puede realizar la transcodificación. En algunos casos, se requiere un módulo de hardware específico o licencias específicas. Puede consultar más información sobre las capacidades de su SBC con el equipo de Quobis.
Ejemplo: verificación de la capacidad de transcodificación en un SBC de Oracle:
> show prom-info all
(...)
PCB Family Type: Low Capacity Transcoding DSP
ID : Low Capacity Transcoding DSP
(...)La solución de cluster HA (alta disponibilidad) consiste en tener dos computadoras con configuraciones replicadas desempeñando diferentes roles; activo y en espera.
Con esta configuración ninguno de los dos SBC asume el rol de equipo principal y equipo de backup, sino el rol activo/standby, compartiendo las mismas IP virtuales.
Los SBC mantienen comunicación sobre el estado de cada uno, lo que permite que, al detectarse problemas como una caída de interfaz, problemas de alimentación, problemas con el ventilador, etc. en el equipo activo, el servicio cambie automáticamente al otro SBC, evitando así la pérdida de servicio.
Dependerá del tipo de cambio y del fabricante del SBC. Por ejemplo, en los SBC de Oracle se definen dos tipos de cambios: con soporte RTC y sin soporte RTC, según sea necesario reiniciar el equipo para que el cambio de configuración sea efectivo.
Algunos ejemplos de cambios de configuración que no implican reinicio son la aplicación de HMRs, cambios en LRTs, inclusión de nuevas PBXs en troncales establecidas, adición de servidores NTP, etc.
Ejemplos de cambios no soportados por RTC serían cambios de negociación de una interfaz física, configuración de la herramienta de monitoreo, cambios en HA, establecimiento de nuevos troncales asociados a una nueva interfaz física, etc.
Aunque algunos SBC pueden reproducir locuciones, esta funcionalidad se centra principalmente en resolver problemas en situaciones específicas, como la ausencia de tono de llamada en ciertas llamadas. No se recomienda su uso para implementar un IVR o un servicio de locución. Puede consultar más información sobre las capacidades de su SBC con el equipo de Quobis.
El cluster de SBCs en HA permite conmutar el servicio entre los dos equipos, ya sea de forma automática por problemas de salud en uno de ellos o de forma intencionada por trabajos de mantenimiento.
Cambiar entre ambos SBC en el cluster no provoca pérdida de servicio, es decir, las llamadas en curso en el momento del cambio permanecerían establecidas sin ningún impacto.
Los SBC disponen de una interfaz web con un dashboard configurable en el que se pueden mostrar diversos parámetros como el estado de la interfaz, sesiones consumidas en tiempo real, estado físico del equipo (como temperatura, consumo de memoria o CPU), etc.
Los SBC permiten la monitorización del sistema a través del protocolo SNMP.
La configuración SNMP en los SBC permite realizar consultas SNMP y enviar Traps a la comunidad especificada:
snmp-community
community-name Community
access-mode READ-ONLY
ip-addresses 10.1.2.251
trap-receiver
ip-address 10.1.2.251:162
filter-level Critical
community-name CommunityA través de las diferentes MIBs es posible monitorizar en el SBC, por ejemplo, el consumo de CPU, uso de memoria, nivel de salud, sesiones activas, temperatura, etc. Quobis colabora con los clientes configurando estos Traps para que los responsables de monitorización y soporte de primer nivel puedan detectar estas incidencias.
El proceso de actualización de firmware consiste en realizar un cambio en la imagen que se ejecuta en el SBC por una versión más actualizada.
Cada actualización publicada por el fabricante contiene mejoras y corrección de errores respecto a versiones anteriores, lo que supone evitar posibles problemas en el funcionamiento del servicio.
En el caso de clusters en HA, la actualización de firmware no supondría una caída del servicio, ya que actúa sobre el equipo en standby en primera instancia, conmutando el servicio y repitiendo el proceso en el resto de equipos en rol de standby tras la conmutación.
El proceso a seguir para esta tarea sería:
Tareas preliminares:
1. Verificación de la versión actual del FW del equipo
2. Descarga de la nueva versión de firmware, verificación de las release notes y subida de la nueva versión por FTP a los SBCs en la partición correspondiente
Ejecución de la actualización:
1. Sustitución del archivo bootloader antiguo por el nuevo descargado, renombrándolo acordemente en cada uno de los SBCs
2. Modificación de los bootparams de los SBCs para que al reiniciar arranquen con la nueva versión de FW
3. Reinicio
4. Tras finalizar la actualización en el SBC standby, balancear el tráfico y repetir el proceso en los demás equipos.
Revertir
1. Restaurar el valor de bootparams
Ordenado 2. Reiniciar las computadoras
El tiempo estimado para el proceso de actualización es de aproximadamente 1 hora (tiempo condicionado a la velocidad de subida del nuevo firmware que permita la conexión)