Terminología de Telefonía Twilio: SIP Trunking, DIDs y A2P

La primera vez que abres la consola de Twilio para conectar voz o SMS a un producto real, la terminología te golpea toda de una vez: SIP trunk, DID, CNAM, 10DLC, STIR/SHAKEN, LNP, y la mayor parte suena como si perteneciera a un examen de redes, no a una integración backend. El error común es tratar esto como vocabulario para memorizar una vez y dejar atrás. No lo es. La telefonía tiene su propia realidad física y regulatoria por debajo de la API: una red PSTN real, operadores reales y marcos de cumplimiento reales que bloquearán silenciosamente tu tráfico si no los entiendes, sin importar qué tan correcto sea tu código.

Esta publicación cubre el mapa completo: qué significa realmente cada término, cómo se conectan las piezas en un flujo real de llamada o mensaje y —porque esta es la parte que la mayoría de las guías terminológicas omiten por completo— qué cambió en el cumplimiento de A2P 10DLC en 2026, ya que una configuración que funcionaba perfectamente en 2024 hoy puede hacer que tus mensajes sean bloqueados por completo.

Aprenderás:

• Qué es realmente SIP trunking y cómo Elastic SIP Trunking de Twilio reemplaza las líneas telefónicas físicas
• La diferencia entre un DID, un número toll-free, un short code y un número 10DLC, y cuándo usar cada uno
• Cómo funciona realmente la portabilidad numérica (LNP) y por qué puede tardar de días a semanas
• Cómo fluye realmente una llamada o un mensaje a través de TwiML, webhooks y tu propio servidor
• Qué exigen STIR/SHAKEN y el cumplimiento de A2P 10DLC en 2026, incluida la nueva regla de consentimiento de la FCC
• Los errores que hacen que las llamadas se marquen como spam o que los mensajes se bloqueen silenciosamente

Tabla de contenidos

1. Lo básico
2. La arquitectura completa
3. Capas principales explicadas
4. Recorrido de extremo a extremo
5. Casos especiales
6. Escalado y desafíos de producción
7. Ejemplos de código
8. Errores comunes
9. Buenas prácticas de producción

Lo básico

Qué cubre realmente la telefonía de Twilio

Twilio se sitúa entre tu aplicación y dos sistemas subyacentes muy distintos: la PSTN (la red global real de voz que usan las líneas fijas y las redes móviles) y el ecosistema de mensajería de operadores que enruta SMS entre números telefónicos. Tu código nunca toca directamente ninguno de esos dos sistemas: habla con la API de Twilio, y Twilio actúa como el operador, traduciendo tus instrucciones a señalización real sobre infraestructura telefónica real. Todo en este glosario existe para describir alguna parte de esa traducción: cómo se conecta una llamada, cómo se identifica un número, cómo se aprueba un mensaje para enviarlo y cómo se demuestra que una llamada es legítima.

Por qué la terminología es un problema de alto valor para entender

• Si te equivocas con los números, los mensajes no se degradan: se bloquean por completo. Desde febrero de 2025, los operadores de EE. UU. bloquean el 100% del tráfico A2P 10DLC no registrado. No hay entrega parcial ni advertencia: simplemente no llega.
• Los marcos de cumplimiento cambian según un calendario que no controlas. Los requisitos de atestación de STIR/SHAKEN y de registro 10DLC han cambiado varias veces desde su lanzamiento, más recientemente con la regla de consentimiento uno a uno de la FCC que entró en vigor el 27 de enero de 2026.
• Los errores de portabilidad causan tiempo de inactividad real. Mover incorrectamente un número entre operadores puede hacer que el número telefónico de una empresa quede fuera de servicio durante horas o días.

La arquitectura completa

Your App ──▶ Twilio API / TwiML ──▶ Twilio Platform
                                          │
                         ┌────────────────┼────────────────┐
                         ▼                                  ▼
                  SIP Trunk / PSTN                  Carrier Messaging Network
                (voice calls, real numbers)         (SMS/MMS, 10DLC/toll-free/short code)
                         │                                  │
                         ▼                                  ▼
                  Caller's Phone                      Recipient's Phone

El principio rector: Twilio es tu operador, no solo tu API. Cada término de esta guía describe cómo el lado de voz (SIP, PSTN, DIDs) o el lado de mensajería (10DLC, A2P, short codes) hace que tu tráfico llegue legítimamente a esa red del mundo real.

Capas principales explicadas

1. SIP Trunking y la entrega a la PSTN

Qué es: SIP (Session Initiation Protocol) es el lenguaje de señalización que establece, gestiona y termina llamadas sobre IP: el “apretón de manos” que dice “quiero llamarte”, “llamada aceptada”, “llamada finalizada”. Un SIP trunk es la línea virtual que transporta esa señalización entre tu sistema y Twilio, reemplazando las conexiones físicas de cobre. El producto Elastic SIP Trunking de Twilio consiste en que Twilio actúa como ese operador: conectas tu PBX o SBC a Twilio por SIP en lugar de comprar capacidad de troncales físicas. El audio real fluye por separado, sobre RTP (Real-time Transport Protocol), una vez que la señalización SIP ha establecido la llamada. Finalmente, las llamadas a números telefónicos reales llegan a la PSTN, la red telefónica física global que subyace a todo esto.

Por qué importa: Esta es la capa que convirtió la infraestructura de voz de un problema de adquisición de hardware en un problema de configuración de software: la capacidad de troncales escala mediante una llamada a la API en lugar de un contrato con un proveedor.

Consejo de producción: Los Elastic SIP Trunks de Twilio no admiten el método SIP REGISTER. Configuras las direcciones IP de señalización SIP de Twilio como peers de confianza en tu lado, en lugar de autenticarte mediante registro; si omites esto, tu trunk simplemente no se conectará.

2. DIDs, Caller ID y CNAM

Qué es: Un número DID (Direct Inward Dialing) es un número telefónico real que enruta directamente a un endpoint específico sin un operador humano; cuando compras un número a Twilio, eso es un DID. Caller ID es el número que se muestra a quien recibe una llamada; CNAM (Caller ID Name) es el nombre registrado detrás de ese número, que puedes consultar en llamadas entrantes.

Por qué importa: Los DIDs son el punto de entrada para cada llamada entrante que maneja tu sistema, y Caller ID/CNAM controlan lo que realmente ve la persona al otro lado. Si esto falla, las llamadas legítimas parecen spam antes de que alguien siquiera conteste.

Consejo de producción: Activa la consulta de CNAM en un trunk solo para el tráfico que la necesite: tiene un costo por consulta, y la mayoría del enrutamiento interno de alto volumen no necesita resolver un nombre en cada llamada entrante.

3. Portabilidad numérica (LNP)

Qué es: Local Number Portability es el proceso de mover un número telefónico existente de un operador a otro —por ejemplo, de un operador heredado a Twilio— sin cambiar el número en sí.

Por qué importa: La portabilidad no es una llamada a la API. Es un proceso entre operadores que implica documentación, verificación de cuenta y aprobación, y puede tardar desde unos pocos días hasta varias semanas, según el tipo de número y el operador saliente.

Consejo de producción: Nunca canceles el servicio con el operador saliente antes de que se complete la portabilidad. Una portabilidad que falla a mitad del proceso, con el servicio anterior ya cancelado, es la forma en que un número empresarial queda fuera de servicio.

4. Tipos y formatos de números

Qué es: No todos los números son el mismo producto. Los números toll-free (tipo 800/888) trasladan el costo a la parte receptora y requieren verificación separada. Los short codes son números de 5–6 dígitos diseñados para SMS de alto volumen, que requieren una larga aprobación de operadores y se usan típicamente para OTPs y campañas masivas de marketing. Los números 10DLC (10-Digit Long Code) permiten a las empresas enviar mensajes A2P desde un número local de apariencia estándar, bajo un marco de registro de operadores en lugar del proceso de aprobación de short code. Cada número que espera la API de Twilio está en formato E.164: +[country code][number], por ejemplo +923001234567.

Por qué importa: Elegir el tipo de número equivocado significa elegir el proceso de aprobación equivocado y el límite de throughput equivocado para tu caso de uso: un short code y un número 10DLC resuelven problemas superpuestos por rutas de registro completamente diferentes.

Consejo de producción: Normaliza cada número telefónico a E.164 en el borde de tu sistema —en el momento en que entra en tu base de datos o en tus llamadas a la API— en lugar de formatearlo ad hoc donde se use. El formato inconsistente es una fuente común de fallos silenciosos de enrutamiento.

5. Control de llamadas: TwiML, IVR y webhooks

Qué es: TwiML es el lenguaje de marcado basado en XML de Twilio que le dice a Twilio qué hacer con una llamada o mensaje: <Say>, <Dial>, <Record>, <Gather>. Un IVR (el sistema de “pulse 1 para ventas”) se construye usando <Gather> o Twilio Studio. Los webhooks son callbacks HTTP que Twilio hace a tu servidor cuando ocurre algo —una llamada entrante, un SMS, un cambio de estado— y así es como tu backend controla dinámicamente el comportamiento de la llamada en lugar de depender de TwiML estático.

Por qué importa: Esta es la capa donde vive la lógica real de tu aplicación. Todo lo demás en esta guía hace que una llamada o mensaje llegue a tu sistema; TwiML y los webhooks son lo que tu sistema hace con ello.

Consejo de producción: Diseña tu endpoint de webhook para responder rápido. Twilio espera una respuesta TwiML oportuna para continuar la llamada: la lógica lenta de aplicación debe ir en un trabajo en segundo plano que actualice el estado, no en línea dentro del propio handler del webhook.

6. Audio e input: codecs y DTMF

Qué es: Un codec es el formato de compresión de audio usado para una llamada —PCMU/PCMA para calidad estándar, Opus para mayor calidad— y es importante para el ancho de banda y la configuración del SIP trunk. DTMF (Dual-Tone Multi-Frequency) es el tono generado al pulsar un botón del teclado, que es cómo los sistemas IVR capturan entradas como “pulse 1 para inglés”.

Por qué importa: Las incompatibilidades de codec entre tu SBC y el trunk de Twilio son una fuente común de audio en un solo sentido o de fallos en el establecimiento de llamadas que no tienen absolutamente nada que ver con el código de tu aplicación.

7. Cumplimiento y verificación: STIR/SHAKEN y A2P 10DLC en 2026

Qué es: STIR/SHAKEN es el marco regulatorio de EE. UU. que firma criptográficamente las llamadas para verificar la legitimidad del Caller ID y combatir la suplantación, mientras que Twilio gestiona los niveles de atestación (A, B o C) en llamadas salientes. La mensajería A2P (Application-to-Person) es cualquier texto enviado desde una empresa o app a un consumidor, y cuando se ejecuta sobre un número 10DLC requiere el registro de Brand y Campaign a través de The Campaign Registry (TCR) antes de que puedas enviar absolutamente nada.

Por qué importa: Esta es la parte del stack que más se ha movido, y la mayoría de los textos existentes sobre el tema ya están desactualizados. Desde el 1 de febrero de 2025, los operadores de EE. UU. bloquean por completo el 100% del tráfico 10DLC no registrado. Además, 2026 introdujo requisitos de verificación Authentication+ para empresas públicas, IDs obligatorios de reseller al registrar en nombre de otra entidad, reglas más estrictas de coincidencia con la antigüedad del EIN y el requisito de que las páginas de consentimiento opt-in permanezcan siempre activas y verificables por los operadores. Lo más significativo es que la regla de consentimiento uno a uno de la FCC entró en vigor el 27 de enero de 2026, endureciendo considerablemente lo que cuenta como consentimiento válido para la mensajería A2P, mucho más allá del antiguo modelo de consentimiento compartido en el que muchas empresas se apoyaban.

Consejo de producción: Si registraste una campaña 10DLC en 2023 o 2024 y no la has revisado desde entonces, no asumas que sigue cumpliendo: vuelve a verificar tu flujo de opt-in y el lenguaje de consentimiento conforme a las reglas actuales en lugar de asumir que una aprobación pasada sigue siendo válida.

Recorrido de extremo a extremo

Sigue una llamada entrante real, desde el teléfono del llamante hasta la lógica de tu aplicación:

1. La persona llama a tu DID. La llamada entra en la PSTN y se enruta hacia Twilio, que posee ese número en tu nombre.
2. Twilio recibe la llamada y revisa tu configuración. Si el número está configurado para voz, Twilio envía un webhook HTTP a tu servidor anunciando la llamada entrante.
3. Tu servidor responde con TwiML. Un verbo <Gather> reproduce un saludo y espera una entrada DTMF: el menú IVR.
4. La persona pulsa una tecla. El tono DTMF se captura y se envía de vuelta a tu webhook como datos de formulario en una solicitud posterior.
5. La lógica de tu aplicación decide la ruta. Según el dígito pulsado, la hora del día o el Caller ID, tu servidor devuelve nuevo TwiML: ya sea <Dial> para conectar a la persona con un agente por un SIP trunk, o más indicaciones de IVR.
6. La llamada se conecta. La señalización SIP establece la sesión entre Twilio y el destino (el endpoint SIP de un agente, otro número PSTN o una cola); RTP transporta el audio real una vez establecido.
7. La atestación STIR/SHAKEN viaja con la llamada. Si este es un tramo saliente, Twilio adjunta un nivel de atestación según lo verificados que estén el número llamante y la cuenta, que los operadores posteriores usan para decidir si mostrarla como “Verified” o arriesgarse a marcarla como spam.
8. La llamada termina. Se dispara un webhook final de estado hacia tu servidor, permitiéndote registrar duración, costo y resultado.

Casos especiales

Mensajería A2P desde agentes conversacionales o de AI. Si un sistema impulsado por LLM genera dinámicamente el contenido de los mensajes salientes, los operadores siguen esperando que el caso de uso registrado coincida con lo que realmente se está enviando. Registrar una campaña como “customer care” y luego enviar cualquier cosa que derive hacia terreno promocional es exactamente el tipo de deriva de caso de uso que hace que una campaña sea marcada, independientemente de cómo se haya generado el mensaje.

SIP trunking internacional. Los requisitos regulatorios, los formatos numéricos e incluso qué codecs se admiten comúnmente varían según el país: una configuración de trunking que funciona limpiamente en EE. UU. a menudo necesita una reconfiguración real, no solo un número nuevo, para funcionar correctamente en otro lugar.

Portabilidad de números toll-free frente a números locales. Siguen procesos y cronogramas distintos con diferentes requisitos de operador: no asumas que una portabilidad de toll-free y una portabilidad de DID local se comportan igual operativamente.

Escalado y desafíos de producción

Límites de llamadas concurrentes y CPS. Las cuentas nuevas de Twilio sin un Business Profile aprobado tienen límites restringidos de llamadas concurrentes y no pueden autogestionar aumentos de calls-per-second; un lanzamiento que asuma escala ilimitada desde el primer día chocará con este muro.

SIP trunks regionales y residencia de datos. Los datos de llamadas de un trunk se procesan y almacenan dentro de la Twilio Region para la que ese trunk esté configurado: un trunk solo está activo en una región a la vez, lo cual importa directamente para los requisitos de residencia de datos en industrias reguladas.

Erosión del trust score a escala en 10DLC. Los operadores rastrean patrones de envío por campaña, y la deriva del caso de uso o las altas tasas de quejas degradan con el tiempo el throughput y la entregabilidad de una campaña, no solo en el momento del registro: el cumplimiento es una preocupación operativa continua, no una aprobación única.

Atestación STIR/SHAKEN a volumen. A medida que crece el volumen de llamadas salientes, niveles inconsistentes de atestación en tu pool de números pueden significar que algunas llamadas se muestren como verificadas y otras se marquen como posible spam, puramente en función del historial de la cuenta y del número, más que por cualquier cosa de la llamada en sí.

Ejemplos de código

Formatear y validar números telefónicos a E.164 antes de que lleguen a la API de Twilio:

import re

def to_e164(raw_number: str, default_country_code: str = "92") -> str:
    digits = re.sub(r"\D", "", raw_number)
    if raw_number.startswith("+"):
        return f"+{digits}"
    return f"+{default_country_code}{digits.lstrip('0')}"

Una respuesta TwiML mínima para un menú IVR de llamada entrante:

<Response>
    <Gather numDigits="1" action="/voice/menu" method="POST">
        <Say>Press 1 for sales, press 2 for support.</Say>
    </Gather>
</Response>

Un handler de webhook en FastAPI que recibe esa entrada DTMF:

from fastapi import FastAPI, Form
from fastapi.responses import Response

app = FastAPI()

@app.post("/voice/menu")
async def handle_menu(Digits: str = Form(...)):
    destination = "+15551234567" if Digits == "1" else "+15559876543"
    twiml = f'<Response><Dial>{destination}</Dial></Response>'
    return Response(content=twiml, media_type="application/xml")

Errores comunes

Error: asumir que un número comprado puede enviar SMS A2P inmediatamente. Un número 10DLC sin Brand y Campaign registrados tendrá sus mensajes bloqueados por completo, no retrasados. Solución: completa el registro en The Campaign Registry antes de enviar nada con volumen de producción, y trátalo como un prerrequisito, no como una formalidad.

Error: cancelar el operador anterior antes de que se complete una portabilidad. Esta es la causa más común de que un número quede fuera de servicio durante una migración. Solución: mantén activo el servicio del operador saliente hasta que la portabilidad esté totalmente confirmada del lado de Twilio.

Error: tratar short codes y 10DLC como intercambiables. Resuelven problemas superpuestos mediante procesos de aprobación y estructuras de costo completamente diferentes. Solución: elige short code para campañas masivas de marketing de alto volumen que necesiten máximo throughput, y 10DLC para mensajería estándar de aplicación desde un número con apariencia local.

Error: formatear números telefónicos de forma inconsistente en toda la base de código. El texto libre o el formato específico por locale provoca fallos silenciosos de enrutamiento y de lookup. Solución: normaliza a E.164 una sola vez, en el borde del sistema, y valida antes de almacenar.

Error: asumir que un registro A2P de 2023 o 2024 sigue cumpliendo completamente. Authentication+, reseller ID y las reglas de consentimiento han cambiado desde entonces. Solución: vuelve a auditar las campañas existentes frente a los requisitos actuales, especialmente la regla de consentimiento uno a uno de la FCC.

Buenas prácticas de producción

• Registra las campañas A2P antes de necesitarlas, no cuando los mensajes empiecen a bloquearse. La aprobación no es instantánea, y el tráfico no registrado se bloquea por completo, no se pone en cola.
• Mantén activas y precisas las páginas de consentimiento opt-in. Los operadores pueden volver a verificarlas en cualquier momento, y un flujo de opt-in obsoleto o faltante puede suspender una campaña que por lo demás estaba aprobada.
• Normaliza los números telefónicos a E.164 en el borde. Cada llamada descendente a la API y cada lookup dependen de que esto sea consistente.
• Supervisa la atestación STIR/SHAKEN y los trust scores de 10DLC como métricas continuas, no como comprobaciones únicas de configuración: ambos pueden degradarse con el tiempo según los patrones de envío.
• Nunca permitas una portabilidad sin un plan de respaldo. Confirma que la nueva configuración está activa y probada antes de liberar al operador anterior.

Cierre

Ninguno de estos términos es complicado de forma aislada: el desafío es que abarcan una red física, un protocolo de señalización, un sistema de numeración y un marco regulatorio que sigue cambiando, y la mayoría de las guías de integración solo cubren los dos primeros. El lado de cumplimiento en particular ha cambiado más en los últimos dieciocho meses que el lado técnico, y una configuración que cumplía totalmente en 2024 hoy puede estar bloqueando activamente tu propio tráfico sin un solo error en tu código.

¿Qué parte del stack de Twilio te dio más problemas cuando la configuraste por primera vez: el lado de SIP trunking o el lado de cumplimiento?