Una guía en lenguaje sencillo para elegir entre sistemas PBX independientes, control centralizado de llamadas, teléfonos locales y conectividad compartida entre sedes.
Las implementaciones de 3CX en múltiples sitios suelen comenzar con la decisión de dónde se ubicará el control de las llamadas. Un puente conecta los PBXs independientes para que los sitios puedan comunicarse entre sí. Un SBC conecta los teléfonos locales a un PBX en otro sitio o en la nube. Ambos pueden admitir un diseño de múltiples sitios, pero resuelven necesidades diferentes en cuanto a conectividad y administración.
Antes de abrir la Consola de Administración, decida si cada sede necesita su propio PBX o si las sedes deben compartir un sistema central de control de llamadas. Es posible que una sucursal necesite sus propias extensiones, troncales, horarios de atención, colas y administración local. Es posible que otra sede solo necesite que sus teléfonos de escritorio se conecten a un PBX hospedado en la sede central o en la nube.
Se trata de distintos modelos operativos. Elegir el método de conexión una vez que se tiene claro el modelo de PBX facilita mucho la explicación de las decisiones relacionadas con la numeración, el enrutamiento y la red.
Separar la Conectividad del Sitio de la Ubicación del PBX
La conectividad entre sedes se refiere a cómo se transmiten las llamadas y el tráfico telefónico entre las distintas ubicaciones. La ubicación del PBX se refiere a dónde se administran las extensiones, las troncales, las colas, los horarios de oficina y el enrutamiento de llamadas. Un puente conecta dos sistemas 3CX. Un SBC conecta los teléfonos de una sede a un sistema 3CX remoto.
Esa distinción es importante porque un puente no convierte sistemas separados en un solo PBX, y un SBC no crea un PBX local con sus propias troncales o políticas de control de llamadas. Comience con el modelo operativo y, luego, seleccione el componente de conectividad que lo respalde.
Elección de Arquitectura: Puentes vs. SBC
Mantener Múltiples PBXs como Sistemas Independientes (Puentes)

Elija un puente cuando cada sede deba seguir siendo un sistema 3CX independiente, pero los usuarios aún necesiten realizar llamadas dentro de la organización. La guía actual sobre puentes de 3CX explica que dos sistemas remotos pueden utilizar la conexión a Internet existente para realizar llamadas entre sedes, con un prefijo o un plan de numeración que identifique la oficina de destino.
Un puente es una buena opción cuando cada PBX cuenta con sus propios administradores, troncales, horarios de oficina, colas o políticas de enrutamiento de llamadas locales. Mantiene explícita la frontera entre los sistemas, al tiempo que ofrece a los usuarios una forma predecible de comunicarse con sus colegas en otra sede.
Vaya a Consola de Administración > Voz y Chat > + Agregar puente. La configuración del puente utiliza una relación Maestro-Esclavo, un valor de autenticación compartido, un prefijo de salida y un FQDN seguro para el sistema remoto. Si se utiliza una conexión de túnel, el tráfico SIP y RTP puede transmitirse a través de la ruta de túnel configurada. Planifique la numeración y las reglas de salida antes de que los usuarios comiencen a marcar.
Planificación de Numeración, Enrutamiento y Presencia
Un plan basado en prefijos es fácil de explicar: el usuario marca el prefijo de la sucursal seguido de la extensión remota. Un plan de numeración basado en sedes puede parecer más natural cuando cada oficina cuenta con un rango de extensiones propio. Cualquiera de los dos enfoques funciona únicamente cuando las reglas de llamadas salientes, la eliminación de dígitos y las restricciones de códigos de país se ajustan al plan.
La presencia es una decisión aparte. Si se desea que los usuarios vean el estado de sus colegas en el otro PBX, habilite las opciones del puente que publican y reciben información de presencia. No dé por sentado que el hecho de realizar llamadas entre sitios por sí solo crea un directorio compartido o un único plano de control de llamadas.
Cómo Conectar Teléfonos Locales a una PBX Remoto (SBC)
Elija un SBC cuando sea necesario que el PBX permanezca en la nube o en otra ubicación, mientras que un grupo de teléfonos IP requiera una conexión local confiable. La guía del SBC de 3CX describe el SBC como un servicio local que combina la señalización SIP y los medios RTP desde una ubicación y los transmite a la instancia remota de 3CX.
Este suele ser el diseño más sencillo para una sucursal que no necesita su propio PBX. La sucursal conserva sus teléfonos locales y su red LAN, mientras que el control de llamadas, las extensiones, las troncales y la administración se mantienen centralizados. Para sitios más pequeños, un teléfono router compatible o las aplicaciones de 3CX pueden ser más adecuados que un SBC dedicado.
Un servidor SBC necesita una dirección IP estática de LAN y debe estar disponible siempre que los teléfonos locales necesiten servicio. Considérelo como parte de la ruta telefónica, junto con la LAN, el firewall, el DNS y la fuente de alimentación que lo respaldan.
En la Consola de Administración, vaya a Voz y Chat y seleccione + Agregar SBC. Configure el SBC y, a continuación, asígnele teléfonos locales. Mantenga el enfoque del diseño: el SBC resuelve la conectividad de los teléfonos remotos y el paso a través del firewall. No crea un segundo PBX ni replica la configuración del PBX.
Lista de Verificación para la Instalación y la Preparación Previa al Lanzamiento
Utilice un puente cuando cada sede necesite su propia identidad de PBX y control local, con marcación planificada entre las sedes a través de los sistemas. Utilice un SBC cuando la organización desee que un PBX administre las extensiones, las troncales, las colas y las políticas, mientras que los teléfonos permanezcan en otra ubicación.
Si las sucursales necesitan horarios de atención diferentes, colas locales o administradores independientes, lo más claro podría ser contar con sistemas PBX independientes. Si el objetivo principal es una administración uniforme y un sistema de extensiones compartido, un sistema PBX centralizado con teléfonos conectados a un SBC suele ser más fácil de manejar.
Planificación del DNS, las Troncales, los Teléfonos y las Pruebas
La resolución de nombres forma parte del diseño, no es un detalle posterior a la implementación. Las directrices de 3CX exigen el uso de FQDNs seguros para los sistemas conectados mediante puente y recomiendan el uso de DNS dividido para las implementaciones On-Premise. Utilice los mismos nombres documentados en el aprovisionamiento de teléfonos, el acceso a aplicaciones, los certificados, las conexiones de puente y la administración.
Revise la guía de 3CX sobre el firewall para cada sitio y ejecute el Verificador de Firewall una vez que se haya configurado la ruta de red. Evite el uso de SIP ALG, defina las ACLs correctas y registre qué puertos y flujos son necesarios para las troncales, los teléfonos remotos, los SBCs y la administración.
Por último, realice pruebas desde la perspectiva del usuario. Verifique los teléfonos de escritorio, el acceso al Cliente Web, las aplicaciones móviles y de escritorio, las notificaciones push, las colas, las transferencias, los IVRs, los procedimientos de llamadas de emergencia, las grabaciones, las integraciones y la presencia en todos los sitios.
Utilice Esta Lista de Verificación para la Toma de Decisiones
Antes de elegir una arquitectura, asegúrese de lo siguiente:
- Puente: los PBXs independientes requieren un sistema controlado de marcación entre sedes, numeración y, posiblemente, presencia compartida.
- SBC: los teléfonos IP locales deben poder conectarse a un PBX remoto o en la nube sin necesidad de instalar otro PBX en las instalaciones.
- Numeración: cada sitio cuenta con un rango de extensiones, un prefijo o una regla de marcación documentados que los usuarios pueden entender.
- Red: cada sitio cuenta con el FQDN requerido, la configuración de DNS, las reglas de firewall y una ruta telefónica documentada.
- Propiedad: el equipo sabe quién administra cada PBX, puente, SBC, ruta troncal y cambio de numeración.
- Pruebas: el equipo ha verificado las llamadas entre sedes, las llamadas entrantes y salientes, la presencia, el acceso a las aplicaciones y las funciones telefónicas de los representantes.
Errores Comunes en Arquitectura
Entre los errores típicos se incluyen: utilizar un puente cuando una sucursal realmente necesita extensiones centralizadas; utilizar un SBC cuando una sucursal necesita su propio PBX y troncales; permitir que cada sucursal establezca reglas de numeración incompatibles; basarse en una dirección IP en lugar del FQDN documentado; omitir los DNS divididos; y suponer que las llamadas entre sucursales crean automáticamente un directorio compartido o una presencia. Regla general: evalúe dónde recae la responsabilidad de la llamada.
Mantenga la arquitectura lo suficientemente clara como para que funcione. Cada PBX, puente, SBC, registro DNS, ruta de troncal y regla de numeración debe tener un responsable y una prueba documentada. Si nadie puede explicar cómo un usuario en una sede se comunica con la extensión o la troncal correcta en otra sede, el diseño no está terminado.
Comparta sus Comentarios
Únase a nuestro Foro para decirnos lo que piensa y no olvide seguirnos en X y LinkedIn para estar al tanto de las novedades y nuevas funciones.



