Tu plataforma puede seguir sobre Twilio mientras netelip aporta numeración, conectividad y tráfico. Sin migrar toda la aplicación —aunque la interconexión SIP debe configurarse y validarse técnicamente.

Tu plataforma lleva meses —o años— funcionando sobre Twilio. Tienes los flujos, los webhooks, las grabaciones, las automatizaciones y toda la lógica de negocio construida encima. Cambiarlo todo para trabajar con otro operador no es una opción razonable.

Existe otra posibilidad: mantener Twilio como plataforma programable y conectar netelip como proveedor de numeración y tráfico telefónico mediante Twilio BYOC. Sin migrar toda la aplicación ni reconstruir la lógica que ya funciona, aunque la interconexión SIP debe configurarse y validarse técnicamente.

Twilio confirma que el modelo BYOC existe y funciona en los dos sentidos; lo que aquí describimos es cómo encajaría netelip dentro de ese modelo. La interconexión concreta entre netelip y Twilio se valida con un piloto. Con eso claro, este artículo explica la arquitectura posible, qué conserva Twilio, qué aportaría netelip, cuánto cuesta de verdad y cómo probarlo antes de escalar.

LA IDEA EN UNA FRASE

BYOC te permite separar la plataforma programable del operador telefónico. Twilio sigue ejecutando tu lógica de llamadas; netelip puede colocarse debajo como capa de numeración y conectividad con la red telefónica, una vez validada la interconexión.

1. El problema: tu plataforma ya depende de Twilio

Cuando una plataforma lleva tiempo construida sobre Twilio, el operador telefónico deja de ser una pieza que se cambia sin más. Migrar de proveedor no significa «apuntar a otra IP»: significa mover, revisar y volver a probar todo lo que hay encima.

Ese trabajo incluye normalmente:

• El código y los webhooks que reaccionan a cada evento de llamada.
• Los flujos de llamada, IVR y enrutamientos ya afinados.
• Las integraciones con tu CRM y tus sistemas internos.
• Las grabaciones y las funcionalidades de voz que ya usas.
• La lógica específica de cada cliente o campaña.
• Una infraestructura que ya está probada en producción.

El punto de partida de este artículo es justo el contrario a «cámbialo todo»: el objetivo no es migrar la aplicación. Es cambiar solo la capa que conecta con la red telefónica, manteniendo la plataforma programable y realizando los cambios de integración necesarios.

2. Qué es Twilio BYOC

BYOC significa Bring Your Own Carrier, «trae tu propio operador». Es un troncal SIP que permite seguir usando Twilio Programmable Voice mientras otro operador aporta la conexión con la red telefónica pública.

Funciona en los dos sentidos:

• Entrantes: el cliente llama a un número de netelip → netelip entrega el tráfico a Twilio → Twilio aplica la lógica de tu aplicación.
• Salientes: tu aplicación lanza la llamada en Twilio → Twilio la entrega a netelip por BYOC → netelip la conecta con el fijo o el móvil de destino.

No es una función experimental: Twilio tiene BYOC Trunking disponible de forma general desde el 30 de abril de 2020, y su documentación oficial describe tanto la terminación (tráfico que entra en Twilio desde el operador) como la originación (tráfico que sale de Twilio hacia el operador). Eso sí, Twilio exige que el operador pueda intercambiar tráfico SIP directamente con su plataforma: confirmar y probar esa interconexión con netelip es exactamente lo que resuelve un piloto.

3. Qué conserva Twilio y qué aporta netelip

La propuesta se entiende casi sola con una tabla. Twilio se queda con todo lo programable; netelip se ocuparía del tramo de operador.

Dicho de otra forma: netelip no sustituye lo que ya has construido. Se situaría debajo como capa de telefonía, numeración y tráfico, una vez validada la interconexión.

4. Arquitectura de la integración

La arquitectura es sencilla de explicar; la interoperabilidad real solo se demuestra con un piloto. Hay dos flujos de llamada y una capa adicional de gestión.

Llamada entrante:

Llamante → número de netelip → red de netelip → dominio SIP del BYOC Trunk de Twilio → Twilio Programmable Voice → aplicación

Llamada saliente:

Tu aplicación → Twilio Programmable Voice → BYOC Trunk → red de netelip → red telefónica (fijo o móvil)

Gestión y aprovisionamiento:

Plataforma SaaS → API Cloud de netelip → numeración y servicios

Aquí conviene tener clara una distinción: BYOC transporta las llamadas; API Cloud automatiza la operativa. Son complementarios, pero no son lo mismo.

5. BYOC no es Elastic SIP Trunking

Este apartado es obligatorio porque los dos conceptos se confunden constantemente, y no son intercambiables:

• BYOC: Twilio conserva la capa programable y se conecta a un operador externo, que aporta la conectividad telefónica.
• Elastic SIP Trunking: Twilio actúa como operador para conectar una infraestructura SIP externa con la red telefónica.

DÓNDE MIRAR ANTES DE EMPEZAR

Si tu plataforma origina las llamadas mediante Programmable Voice (Calls API, TwiML o Conference), lo que necesitas es seleccionar un BYOC Trunk. Si en cambio usas un Elastic SIP Trunk conectado a infraestructura SIP propia, el diseño es distinto. Conviene confirmarlo antes de configurar nada.

Un apunte de implementación: aunque BYOC está disponible de forma general desde 2020, el parámetro byoc sigue marcado como Beta en algunas operaciones de la Calls API y de Conference Participants. No cambia el modelo, pero conviene tenerlo presente si vas por esas rutas de implementación.

6. Para quién tiene sentido

BYOC puede usarse incluso con un solo número, pero suele tener más sentido económico y operativo en plataformas con volumen, varios clientes o presencia en diferentes países que ya tienen su lógica construida sobre Twilio:

• Plataformas SaaS de ventas o atención al cliente.
• Contact centers construidos sobre Twilio.
• Plataformas de agentes de voz con inteligencia artificial.
• Empresas con operaciones en varios países.
• Productos que gestionan numeración para múltiples clientes.
• Proyectos con un volumen significativo de llamadas.

Si tu caso es alguno de estos, separar la plataforma del operador telefónico deja de ser un tecnicismo y pasa a ser una variable relevante de coste, control y capacidad.

7. Escalar con API Cloud

Conectar el tráfico por BYOC resuelve el transporte de las llamadas. La operativa —dar de alta numeración, consultar servicios, cambiar configuraciones— es el segundo frente, y ahí entra API Cloud.

API Cloud es la API de aprovisionamiento de netelip. Su documentación actual incluye operaciones de:

• Consulta de servicios y numeración.
• Compra de numeración.
• Edición de configuraciones.
• Gestión de servicios.

Con eso, una plataforma puede automatizar parte de la operativa y reducir tareas manuales. Ahora bien, seamos honestos con el alcance: que existan esas operaciones no significa que toda la gestión sea automática. El alta multipaís, la documentación regulatoria, la separación por cliente, los límites o la facturación no se resuelven solos, y hay que definir país por país qué se automatiza y qué requiere operación manual.

Si quieres el detalle de qué permite hoy la API, lo tienes en API Cloud de netelip: guía completa de integración.

8. Numeración, países y titularidad

Aquí es donde se separa una demo tecnológica de una integración real. La numeración no funciona igual en todos los países, y cualquier plataforma multicliente tiene que ordenar esto desde el principio:

• Los requisitos de numeración cambian según el país.
• Hay que definir quién es el titular de cada número.
• No todos los países ofrecen los mismos canales.
• Las rutas a fijo y a móvil pueden tener precios distintos.
• Una plataforma con varios clientes necesita separar numeración, consumo y documentación.

Hay además un detalle técnico que conviene validar en el piloto: Twilio descarta las cabeceras SIP personalizadas que llegan desde un BYOC Trunk antes de enviar el webhook a tu aplicación. Es decir, una plataforma multicliente no debería depender de una cabecera personalizada para identificar al cliente o la campaña; lo habitual es identificar por el número llamado y comprobarlo en las pruebas. Lo detalla la documentación de Twilio sobre cabeceras SIP.

Estos puntos pueden condicionar la disponibilidad, la activación y el modelo operativo, por lo que deben revisarse país por país.

9. Tarifas de netelip en España y canales

El coste de usar netelip como operador depende del país y de la ruta. Estas son las tarifas de netelip para España (IVA no incluido).

Numeración fija en España: 23,40 €/año en contratación anual. Puedes contratar tantos números fijos virtuales como necesites; no estás limitado a uno.

Las llamadas salientes no tienen coste adicional de canal. A estas tarifas se suma lo que sigas usando en tu plataforma programable de Twilio, así que lo sensato es mirar el coste completo y no una tarifa suelta.

LA FORMULACIÓN CORRECTA

BYOC permite elegir qué operador presta la conectividad telefónica sin renunciar a la plataforma programable de Twilio. La pregunta no es «quién es más barato por minuto», sino qué operador y qué ruta te dan el mejor coste total para tus países y tu volumen.

10. Cómo empezar: un piloto controlado

BYOC se demuestra con tráfico real, no con una hoja de cálculo. El camino sensato es un piloto acotado antes de mover volumen:

1. Definir países y rutas.
2. Seleccionar una numeración de prueba.
3. Configurar el BYOC Trunk.
4. Validar llamadas entrantes y salientes.
5. Comprobar identificador de llamada, cabeceras, formato E.164 y DTMF.
6. Probar errores y failover.
7. Reconciliar los CDR de Twilio y de netelip.
8. Comparar el coste completo, no solo la tarifa por minuto.
9. Escalar únicamente después de validar el piloto.

Un piloto así responde a la única pregunta que importa antes de escalar: ¿esto funciona, con calidad y con un coste que cuadra, para mis países y mi volumen?