Un trunk es el límite donde el operador decide qué llamadas puede enviar y recibir tu equipamiento. Si tienes un PBX, el sistema telefónico empresarial que enruta tus llamadas, un session border controller, una plataforma de contact center o cualquier otro cliente SIP, el trunk es la vía por la que sus llamadas llegan al mundo exterior y por la que las llamadas externas llegan a él. Un session border controller es el dispositivo que protege el borde de una red de voz.
La primera pregunta suele ser si necesitas uno, y la respuesta es sí. Lo que varía es lo que pones detrás.
¿Realmente necesito un trunk?
Sí. Lo que cambia entre configuraciones es el cliente en tu lado, no si hay un trunk.
Toda llamada hacia o desde la red telefónica cruza uno, porque el trunk es donde la plataforma decide si acepta la llamada. Dos configuraciones son habituales:
- Tienes un sistema telefónico. Un PBX, softswitch o plataforma de contact center que ya gestiona llamadas y necesita una ruta hacia la red pública. Se conecta como peer, normalmente desde una dirección fija, y su propio dial plan, las reglas que enrutan sus llamadas, controla las llamadas.
- Tienes código de aplicación. Quieres que tu software haga o reciba llamadas sin operar infraestructura de telefonía. Sigues necesitando un trunk, y lo que habla con él puede ser pequeño: un softphone, un navegador, el CLI o un runtime de agente de voz. Se autentica con una credencial de sesión de corta duración, un usuario y contraseña temporales para un cliente SIP, en lugar de hacerlo desde un equipamiento en una dirección conocida.
La distinción está en dónde vive el control de llamadas, no en la escala, y ninguna de las dos configuraciones se salta el trunk. Lo que te ahorra un cliente ligero es operar un sistema telefónico, no la conexión en sí. Las propias herramientas de Bird lo demuestran dos veces: el teléfono del dashboard y la llamada de prueba del CLI son ambos clientes SIP que cursan llamadas reales a través de uno de tus trunks.
El trunk tampoco es una alternativa al API, porque ningún endpoint cursa una llamada hacia un destino que tú elijas. Qué es un API de voz explica cómo se reparten el trabajo la parte de configuración y la parte de señalización.
¿Qué hace exactamente un trunk?
Le da a tu equipamiento una dirección a la que enviar llamadas y decide cuáles acepta.
Bird asigna a cada trunk un dominio SIP fijo, que es lo que introduces en tu sistema telefónico para que las llamadas se asocien al trunk. Tu equipamiento envía a ese dominio por uno de tres transportes: UDP o TCP en 5060, o TLS en 5061 cuando quieres que la señalización viaje cifrada.
Un trunk nuevo rechaza toda llamada. Las dos direcciones están desactivadas y ningún remitente está autorizado. Es un valor predeterminado deliberado, no una configuración incompleta. Un trunk que aceptara llamadas en el momento de existir sería una invitación permanente, y el fraude de tráfico lo convierte en algo caro rápidamente.
¿Por qué se configuran por separado la dirección saliente y la entrante?
Porque son problemas distintos con modos de fallo distintos, y un trunk gestiona cada dirección de forma independiente.
Saliente es tu sistema telefónico cursando llamadas a través de Bird. Hasta que la habilites, el trunk rechaza todo intento saliente sin importar las credenciales, así que una llamada correctamente autenticada falla igualmente si la dirección está desactivada.
Entrante es Bird entregando llamadas a tu sistema telefónico para los números apuntados al trunk. Habilitarla no basta por sí sola: un trunk con la dirección entrante habilitada y sin gateway de entrega rechaza toda llamada entrante a sus números. Apuntar un número al trunk se hace en el número, no en el trunk, y esa es la otra mitad que se suele pasar por alto.
Desactivar la dirección entrante pone todos los números apuntados a este trunk de vuelta en rechazar, y volver a activarla no los restaura. Eliminar el trunk hace lo mismo. La reversión no es simétrica: si desactivas la dirección entrante para probar algo, planifica reasignar cada número después, y comprueba los números en lugar de asumir que el interruptor los restauró.
¿Cómo decide un trunk quién puede enviarle llamadas?
Lo deciden una lista de IPs permitidas, la autenticación con clave API y las credenciales de sesión. Se pueden combinar, y cada una se activa en cuanto tiene una entrada.
Una lista de IPs permitidas. Añade las direcciones públicas desde las que tu equipamiento envía a SIP. El filtrado empieza en el momento en que la lista tiene una entrada, y a partir de entonces solo los rangos incluidos pueden enviar llamadas. Para equipamiento detrás de NAT, esta es la dirección pública del router, no la privada del sistema telefónico. Las llamadas desde direcciones no incluidas se rechazan en la capa SIP y normalmente no llegan al registro de llamadas. Un registro vacío es, por tanto, un síntoma de esto y no evidencia de que no se intentó nada.
Autenticación con clave API. Bird desafía la llamada y tu sistema responde con un hash de la contraseña en lugar de la contraseña en sí. El hash se verifica contra una clave Bird API con acceso de voz a nivel de escritura. En tu PBX el usuario es siempre bird y la contraseña es el secreto de la clave. Como la lista de IPs, se vuelve exclusiva en cuanto se permite una clave.
De ahí se derivan dos detalles operativos. Quitar el permiso de voz a una clave detiene su autenticación de inmediato. La clave permanece en la lista de permitidas del trunk, marcada, para que la lista nunca parezca funcional cuando no lo es. Restaurar el permiso la reactiva sin cambiar nada. Revocar o eliminar la clave es inmediato en todos los trunks que la permitían, y es permanente. Para rotar, añade la nueva clave al trunk primero, migra tu equipamiento y revoca la antigua al final.
Credenciales de sesión. Un usuario y contraseña SIP de corta duración que responden al mismo desafío sin exponer un secreto de larga duración. Están desactivadas en un trunk nuevo y pertenecen al espacio de trabajo, no a un trunk concreto. La contraseña solo se devuelve en el momento en que se genera.
Activar las credenciales de sesión no cambia cómo se conecta el equipamiento en la lista de IPs permitidas. Una llamada desde una dirección incluida en un trunk sin claves API permitidas sigue siendo admitida sin ningún desafío de contraseña. Si pretendías que la credencial fuera la puerta de entrada, la lista de IPs sigue siendo silenciosamente la puerta de entrada.
¿Por qué mi navegador o softphone no logra autenticarse?
Casi siempre es el algoritmo de digest. Es el único ajuste que falla de una forma que parece un problema de credenciales.
Por defecto Bird ofrece SHA-256 primero y MD5 segundo, y tu equipamiento responde con el primero que soporta. Un trunk solo acepta los algoritmos que ofrece, así que reducir la oferta reduce lo que puede conectarse.
La trampa son los navegadores: un navegador responde con MD5 y nada más. Un trunk que solo ofrezca SHA-256 rechaza toda llamada desde un navegador, incluido el teléfono del propio dashboard. Así que mantén MD5 en la oferta en cualquier trunk desde el que pretendas llamar con un navegador, y recurre a MD5 exclusivo solo cuando un PBX gestione mal un desafío que empiece con SHA-256. Las claves API funcionan con cualquiera de los dos algoritmos y no necesitan reemitirse cuando cambias la oferta.
¿Qué configuro entonces?
- Un trunk, sea cual sea tu configuración. Toda llamada cruza uno, así que este paso no es opcional.
- Un peer, si operas un sistema telefónico. Conecta el PBX o la plataforma de contact center desde una dirección fija y deja que su dial plan controle las llamadas.
- Un cliente ligero, si tienes código de aplicación. Un softphone, un navegador, el CLI o un runtime de agente, autenticándose con una credencial de sesión de corta duración en lugar de una dirección conocida.
- Una regla de remitente, sea cual sea tu elección. Una lista de IPs permitidas, una clave API permitida o una credencial de sesión, recordando que cada una se vuelve exclusiva en cuanto tiene una entrada.
- MD5 en la oferta de digest en cualquier trunk desde el que pretendas llamar con un navegador.
Trunks SIP cubre cada ajuste y dónde encontrarlo. Clientes SIP cubre cómo conectar un solo cliente en lugar de un sistema telefónico, y resolución de problemas de voz aborda las llamadas que no llegan.
En resumen
Toda ruta hacia la red telefónica cruza un trunk.
Lo que cambia es el cliente en tu lado: un sistema telefónico conectado como peer, o un cliente SIP más ligero como un navegador o el CLI con una credencial de corta duración.
Un trunk nuevo rechaza todo.
Las dos direcciones están desactivadas y no hay ningún remitente autorizado hasta que añadas uno. Es deliberado, no un paso de configuración que puedas omitir.
Cada dirección se habilita por separado, y la entrante necesita un gateway.
Un trunk con la dirección entrante habilitada pero sin gateway de entrega rechaza toda llamada entrante a sus números.
Desactivar la dirección entrante no se deshace limpiamente.
Todos los números apuntados al trunk vuelven a rechazar, y volver a activar la dirección entrante no los restaura. Reasigna cada número tú mismo.