DEV Community: Ivan Labasok

Validar números de teléfono en JavaScript: por qué tu expresión regular está mal

Ivan Labasok — Sun, 02 Aug 2026 23:37:12 +0000

En corto

Si en tu proyecto hay una expresión regular validando teléfonos, está mal. No «mejorable»: mal. Y lo peor es que falla en silencio — acepta basura y rechaza números perfectamente válidos de usuarios reales que se van sin registrarse.

Te cuento por qué el problema es irresoluble con regex, qué es E.164, cómo usar libphonenumber-js sin los tres errores habituales, y qué columna deberías tener realmente en la base de datos.

1. Por qué tu expresión regular para teléfonos está mal

Esta es, con variaciones, la regex que aparece en casi todos los tutoriales en español:

const regex = /^\+?[0-9]{9,15}$/;

Parece razonable. Veamos qué hace con números reales:

Entrada	Qué es	Tu regex dice
`+34 612 345 678`	Móvil español válido	❌ Rechazado (espacios)
`+390212345678`	Fijo de Milán, el cero es parte del número	✅ Aceptado, pero si «normalizas» quitando el cero lo rompes
`+521234567890`	México, con el prefijo móvil `1` que ya no se usa	✅ Aceptado, y no se puede llamar
`+999999999999`	No existe ese código de país	✅ Aceptado
`+34612345678901`	Español con seis dígitos de más	✅ Aceptado
`+1 (213) 373-4253 ext. 42`	Número con extensión	❌ Rechazado

Cuatro falsos positivos y dos falsos negativos en seis casos. Y el problema no es que la regex sea mala: es que la pregunta no tiene respuesta regular. La longitud válida depende del país, dentro del país depende del prefijo, y dentro del prefijo depende de si es fijo, móvil o servicio. Son miles de reglas que además cambian: los países reasignan rangos, abren prefijos nuevos y deprecan otros.

Google mantiene un documento entero dedicado a esto, FALSEHOODS.md, con 27 suposiciones falsas sobre teléfonos. Mis favoritas, porque casi todos las hemos cometido:

«Los ceros iniciales del formato nacional siempre se pueden descartar en formato internacional.» Falso — Italia los conserva.
«Ningún prefijo de un número válido puede ser a su vez un número válido.» Falso.
«Un número inválido no llegará a ningún destino.» Falso.
«Los números de teléfono son números.» Falso, y esta es la que más daño hace en producción.

2. E.164: el único formato que deberías guardar

E.164 es el estándar de la UIT y es una definición corta: un +, el código de país, y hasta 15 dígitos en total. Sin espacios, sin guiones, sin paréntesis, sin prefijos de marcación nacional.

+34612345678      ← esto
+34 612 34 56 78  ← esto no, es presentación
(612) 345 678     ← esto tampoco, ni siquiera dice de qué país es

La regla mental es sencilla: E.164 es cómo se almacena, el formato bonito es cómo se muestra. Son dos cosas distintas y confundirlas es el origen de la mitad de los bugs de esta categoría. El formato de presentación se calcula al renderizar; nunca se guarda.

3. `libphonenumber-js` en cuatro líneas

La biblioteca de Google (libphonenumber) es la fuente de verdad, y en JavaScript la versión práctica es libphonenumber-js — una reescritura más pequeña que carga los metadatos reales de numeración.

npm install libphonenumber-js

import { parsePhoneNumberFromString } from 'libphonenumber-js';

const phone = parsePhoneNumberFromString('612 345 678', 'ES');

phone.number;               // '+34612345678'   ← E.164, esto va a la BD
phone.country;              // 'ES'
phone.countryCallingCode;   // '34'
phone.nationalNumber;       // '612345678'
phone.isValid();            // true
phone.formatInternational(); // '+34 612 34 56 78'  ← esto se muestra
phone.formatNational();      // '612 34 56 78'
phone.getURI();              // 'tel:+34612345678'

Tres cosas que conviene saber desde el primer día:

parsePhoneNumberFromString devuelve undefined si no puede parsear, no lanza. Si prefieres excepciones tipadas, existe parsePhoneNumberWithError, que lanza un ParseError con un message legible.

El segundo argumento es el país por defecto, y solo se usa cuando la entrada no viene en formato internacional. Si el usuario escribe +34..., el país sale del número y el argumento se ignora. Si escribe 612345678 a secas, sin ese 'ES' no hay forma de saber de dónde es.

Hay tres paquetes de metadatos y elegir mal te cuesta o peso o exactitud:

import { parsePhoneNumberFromString } from 'libphonenumber-js/min';    // ~80 kB
import { parsePhoneNumberFromString } from 'libphonenumber-js/mobile'; // ~95 kB
import { parsePhoneNumberFromString } from 'libphonenumber-js/max';    // ~145 kB

El import por defecto usa min. Si necesitas saber si un número es móvil o fijo, necesitas max — con min, getType() no te va a servir:

import { parsePhoneNumberFromString } from 'libphonenumber-js/max';

parsePhoneNumberFromString('+34612345678').getType(); // 'MOBILE'
parsePhoneNumberFromString('+34911234567').getType(); // 'FIXED_LINE'

Esto importa de verdad si vas a mandar un SMS: gastar el envío contra un fijo es tirar el dinero, y el error es invisible hasta que miras la factura.

4. `isPossible` vs `isValid`: cuál usar y cuándo

Aquí es donde casi todo el mundo elige mal, porque los nombres no ayudan.

import { isValidPhoneNumber, isPossiblePhoneNumber } from 'libphonenumber-js';

isPossiblePhoneNumber('+34 999 999 999');  // true  — la longitud cuadra
isValidPhoneNumber('+34 999 999 999');     // false — ese rango no existe en España

isPossible mira solo la longitud para ese país. Es rápido, tolerante y sobrevive mejor al paso del tiempo.
isValid comprueba longitud y prefijo contra el plan de numeración. Es estricto y mucho más exacto.

La elección no es de gusto, depende de qué estés protegiendo:

Usa isValid en el formulario de registro, donde quieres frenar erratas antes de gastar un SMS de verificación. Usa isPossible al importar datos existentes o al validar algo que ya está en tu base de datos, porque isValid rechaza números legítimos que se asignaron después de la última actualización de metadatos. Los planes de numeración se amplían constantemente, y tu package-lock.json no.

Ese matiz tiene una consecuencia operativa que conviene asumir: libphonenumber es una dependencia que caduca. Si la fijaste hace tres años, hoy está rechazando clientes reales. Actualízala como actualizarías una base de datos de zonas horarias.

Para mensajes de error útiles existe además:

import { validatePhoneNumberLength } from 'libphonenumber-js';

validatePhoneNumberLength('612', 'ES');        // 'TOO_SHORT'
validatePhoneNumberLength('6123456789', 'ES'); // 'TOO_LONG'
validatePhoneNumberLength('612345678', 'ES');  // undefined → longitud correcta

Decir «te faltan dígitos» convierte mucho mejor que «número inválido».

5. Formatear mientras el usuario escribe

El campo que se va formateando solo mientras tecleas no es cosmética: reduce erratas de forma medible, porque el usuario ve los grupos de dígitos y detecta él mismo el que falta.

import { AsYouType } from 'libphonenumber-js';

new AsYouType('ES').input('612345');   // '612 345'
new AsYouType().input('+3461234');     // '+34 61 23 4'

Un input de React completo, con validación en vivo:

import { useState } from 'react';
import { AsYouType, parsePhoneNumberFromString } from 'libphonenumber-js';

function TelefonoInput({ pais = 'ES', onChange }) {
  const [texto, setTexto] = useState('');

  function handleInput(e) {
    const formateado = new AsYouType(pais).input(e.target.value);
    setTexto(formateado);

    const parsed = parsePhoneNumberFromString(formateado, pais);
    // Al padre le entregamos SIEMPRE E.164, nunca el texto formateado
    onChange(parsed?.isValid() ? parsed.number : null);
  }

  const parsed = parsePhoneNumberFromString(texto, pais);
  const error = texto.length > 3 && !parsed?.isValid();

  return (
    <>
      <input
        type="tel"
        inputMode="tel"
        autoComplete="tel"
        value={texto}
        onChange={handleInput}
        aria-invalid={error}
      />
      {error && <span role="alert">Revisa el número</span>}
    </>
  );
}

Dos detalles de accesibilidad que se olvidan siempre: type="tel" con inputMode="tel" saca el teclado numérico en móvil, y autoComplete="tel" permite que el navegador rellene el campo. Cada uno de los dos vale más que cualquier validación que escribas.

Y una advertencia sobre AsYouType: está pensado para escritura hacia delante. Si el usuario borra por el medio o pega un número entero, el formateo se comporta de forma extraña. La solución habitual es reiniciar el formateador cuando detectas un pegado o un borrado no terminal, en lugar de pelearte con el estado.

6. México, Argentina e Italia: los tres casos que rompen todo

México. Durante años, para llamar a un móvil mexicano desde el extranjero había que intercalar un 1 tras el código de país: +52 1 55 .... Esos prefijos de marcación se deprecaron y se eliminaron del plan. Si tu base de datos se llenó antes del cambio, tienes números guardados que ya no se pueden marcar. Y como pasan el filtro de cualquier regex, nadie se entera hasta que un cliente se queja de que no le llegan los SMS.

Argentina. El caso inverso y aún vivo: los móviles llevan un 9 después del 54 en formato internacional, pero domésticamente ese 9 desaparece y se marca 15 entre el prefijo de zona y el número. +54 9 2982 123456 se marca localmente como 02982 15 123456. Son el mismo teléfono con dos representaciones que no se parecen. Si comparas cadenas para deduplicar contactos, te salen dos personas donde hay una.

Italia. El cero inicial del fijo no se descarta al internacionalizar: es parte del número. +39 02 1234567 es correcto. Si aplicas la regla «quitar el cero inicial» que funciona en España, Francia o Reino Unido, rompes Italia entera.

La conclusión práctica no es memorizar estos tres. Es que existen decenas de casos así y ninguno cabe en tu cabeza ni en tu regex — por eso se delega en una biblioteca con metadatos mantenidos.

// La forma correcta de normalizar es no normalizar a mano:
const e164 = parsePhoneNumberFromString(entrada, paisPorDefecto)?.number ?? null;

7. Validar no es lo mismo que poder llamar

Este es el límite del artículo y conviene decirlo claro: isValid() responde «este número encaja en el plan de numeración», no «este número existe y suena en el bolsillo de alguien».

Un número puede ser perfectamente válido y estar sin asignar, dado de baja, portado a un operador que lo tiene desconectado, o pertenecer a un rango que no acepta SMS. La lista de falsedades de Google lo recoge en dos entradas distintas — «se puede llamar a cualquier número» y «un número inválido no llegará a ningún destino», ambas falsas.

Lo único que demuestra que un número es alcanzable es mandarle algo y ver qué pasa. Si tu producto depende de ello, la verificación real es un código por SMS o una llamada; la validación de formato solo sirve para no desperdiciar esos envíos. Son dos capas y hacen falta las dos.

8. Qué guardar en la base de datos

Tres reglas y una columna que no debes crear.

Guarda E.164 como texto. Nunca como entero: los ceros iniciales desaparecen, el + no cabe, y quince dígitos se salen de un INT. Un VARCHAR(16) sobra.

Guarda el país por separado. Sí, se puede deducir del número, pero es una operación con casos ambiguos —hay códigos de país compartidos por varios territorios, otra de las falsedades de la lista— y lo vas a necesitar para formatear, para elegir idioma y para tarificar. Deducirlo en cada consulta es trabajo repetido.

No guardes el formato de presentación. Se calcula al renderizar con formatInternational(). Si lo guardas, tendrás dos fuentes de verdad que divergirán.

CREATE TABLE contactos (
  id            BIGSERIAL PRIMARY KEY,
  telefono_e164 VARCHAR(16) NOT NULL,   -- '+34612345678'
  pais_iso      CHAR(2)     NOT NULL,   -- 'ES'
  verificado_en TIMESTAMPTZ,            -- NULL = formato válido, alcance NO probado
  CONSTRAINT telefono_e164_formato CHECK (telefono_e164 ~ '^\+[1-9][0-9]{6,14}$')
);

CREATE UNIQUE INDEX ON contactos (telefono_e164);

Fíjate en verificado_en. Esa columna es la que separa «pasó la validación de formato» de «le llegó un SMS y contestó», y tenerlas separadas te ahorra la conversación de soporte más incómoda que existe.

Y sí, ahí arriba hay una expresión regular. Es el CHECK de integridad de E.164 — comprueba que la cadena tiene forma de E.164, no que el número exista. Ese es exactamente el trabajo que una regex sí sabe hacer.

Checklist para llevarte

Guarda E.164 como texto, muestra el formato bonito, y no confundas las dos cosas.
Nunca una columna numérica para teléfonos.
Guarda el país en su propia columna.
isValid en el registro; isPossible al importar y al releer datos antiguos.
Necesitas el paquete /max si vas a usar getType() para distinguir móvil de fijo.
Actualiza libphonenumber periódicamente: los planes de numeración cambian y una versión vieja rechaza clientes reales.
No inventes reglas de normalización por país. México, Argentina e Italia ya demuestran por qué.
type="tel" + inputMode="tel" + autoComplete="tel". Tres atributos, mucho más impacto que la validación.
Validar el formato no es verificar que el número existe. Para eso hace falta mandar algo.

Si has llegado hasta aquí es probable que estés montando algo que además de validar necesita llamar o mandar SMS a esos números, que es donde empieza otra categoría entera de problemas. Escribí sobre esa parte —WebRTC hasta la red telefónica, CDR y el redondeo de facturación— en otro artículo. Y si prefieres no montarlo, Twin Phone resuelve la parte de llamadas y números virtuales; es en lo que trabajo, así que ya sabes con qué descuento leerme.

¿Qué caso raro de numeración te ha roto un formulario? Los de Argentina y México me costaron una tarde cada uno — cuéntame el tuyo en los comentarios.

Llamar a un teléfono real desde el navegador: WebRTC, SIP y lo que nadie te cuenta de la facturación

Ivan Labasok — Sun, 02 Aug 2026 23:24:42 +0000

En corto

Conectar WebRTC con la red telefónica de verdad es engañosamente fácil de empezar y sorprendentemente difícil de terminar. El demo sale en una tarde. Lo que se lleva las semanas es lo otro: llamadas que se establecen y no se oyen, llamadas de cero segundos que sí aparecen facturadas, y un redondeo en el CDR que no coincide con lo que tú calculaste.

Este artículo es el mapa que me habría gustado tener. Todo el código va contra APIs públicas y documentadas, con enlaces a la fuente en cada paso.

El stack en una frase

Navegador (WebRTC) → credencial SIP del proveedor → PSTN, la red telefónica real. En paralelo, la compra y configuración de números virtuales se hace por API REST.

Tres piezas y ni una más:

WebRTC captura el micrófono y transporta el audio desde el navegador.
Un proveedor de telefonía hace de puente entre WebRTC y la red telefónica tradicional. Aquí uso Telnyx para los ejemplos y Twilio donde el contraste ayuda.
Tu backend, que emite las credenciales efímeras. El navegador nunca ve tu API key.

Esa última frase es la única regla de seguridad de este artículo, y es innegociable: la API key vive en el servidor, siempre. El navegador recibe un JWT de corta duración y nada más.

1. Autenticar el navegador sin filtrar tu API key

En Telnyx son dos pasos, y conviene entender por qué son dos. Primero se crea una telephony credential asociada a una Credential Connection — esto se hace una vez, no en cada llamada:

import Telnyx from 'telnyx';

const telnyx = new Telnyx({ apiKey: process.env.TELNYX_API_KEY });

// Una vez por usuario (o una compartida, según tu modelo)
const credential = await telnyx.telephonyCredentials.create({
  connection_id: process.env.TELNYX_CONNECTION_ID,
  name: 'browser-client',
});

Y después, en cada sesión, se acuña el JWT que sí viaja al navegador:

// POST /api/voice-token — detrás de tu autenticación
const jwt = await telnyx.telephonyCredentials.createToken(credential.id);
res.json({ token: jwt });

Dos detalles que cuestan una tarde si no los sabes:

createToken devuelve text/plain, no JSON. El valor de retorno es la cadena del JWT. Si escribes response.data.token, obtienes undefined y un error de autenticación cuatro capas más abajo, donde ya no se parece a la causa.

El JWT vive 24 horas — o menos, si la credencial padre tiene expires_at y caduca antes. No hay parámetro documentado para acortar el TTL del token en sí; el único control real de caducidad está en expires_at de la credencial. Si necesitas ventanas más cortas, tu palanca es la credencial, no el token.

Docs: telephony credentials · create an access token

2. La primera llamada

Con el JWT en mano, el cliente es corto:

import { TelnyxRTC } from '@telnyx/webrtc';

const client = new TelnyxRTC({
  login_token: await fetchTokenFromMyBackend(), // nunca hardcodeado
});

client
  .on('telnyx.ready', () => console.log('listo para llamar'))
  .on('telnyx.error', (e) => console.error(e))
  .on('telnyx.notification', (notification) => {
    if (notification.type === 'callUpdate') {
      console.log('estado:', notification.call.state);
    }
  });

client.connect();

Los eventos van en el cliente, no en el objeto call. Es el error más repetido en los ejemplos que circulan por ahí: se ve mucho call.on('telnyx.notification', ...), y eso no existe. El SDK emite las notificaciones a nivel de sesión y te entrega el call dentro de la notificación. Si quieres un callback por llamada, el SDK sí ofrece la opción onNotification dentro de newCall() — pero es otra cosa distinta del listener de sesión.

Los estados que verás en notification.call.state son cadenas en minúscula, no un enum: new, trying, requesting, recovering, ringing, answering, early, active, held, hangup, destroy, purge. Los tres que de verdad usarás son ringing, active y hangup. Y ojo con early: significa que hay media antes de que descuelguen — es el tono de llamada, no una conversación.

Docs: TelnyxRTC · INotification

3. «La llamada se establece pero no hay audio»

Este es el bug que más gente busca y del que menos se escribe. El síntoma es desconcertante: el estado llega a active, el contador de duración corre, la otra persona te oye perfectamente… y tú no oyes absolutamente nada.

La causa, en el caso de Telnyx, es prosaica: el SDK no engancha el stream remoto a ningún elemento del DOM por su cuenta. La negociación va bien de principio a fin —getUserMedia concede el micrófono, el RTCPeerConnection llega a connected, el SDP se intercambia sin errores— y el remoteStream acaba en un MediaStream que no está conectado a ningún reproductor. No hay salida de audio. No hay error. No hay nada en consola.

La solución es una línea, y hay que ponerla en dos sitios:

<!-- En tu página -->
<audio id="remote-audio" autoPlay playsInline></audio>

const call = client.newCall({
  destinationNumber: '+34911234567',  // E.164, siempre
  callerNumber: miNumeroVirtual,
  remoteElement: 'remote-audio',      // ← sin esto: silencio
});

Hay un remoteElement por defecto a nivel de sesión (client.remoteElement), pero si manejas más de una llamada a la vez necesitas el remoteElement por llamada: el de sesión es compartido y la última llamada gana. Lo mismo aplica al contestar una entrante — call.answer({ remoteElement: ... }).

Contraste útil: el SDK de Twilio reproduce su propia salida y no necesita esta fontanería. Si vienes de Twilio, esta es exactamente la diferencia que te va a morder.

Docs: ICallOptions · README con el ejemplo de llamadas concurrentes

4. Audio unidireccional: cuando el problema sí es la red

Si el remoteElement está puesto y aun así hay silencio —o peor, silencio en un solo sentido— ya estás en territorio de ICE, y el diagnóstico cambia por completo.

El caso clásico: alguien detrás de un NAT simétrico, o en una red corporativa que bloquea UDP. La señalización funciona (va por WebSocket, puerto 443, nadie la bloquea), la llamada aparece como establecida, y el RTP no llega a ningún lado. Sin TURN, esa llamada no tiene arreglo.

La trampa concreta: si sobrescribes iceServers, en la mayoría de SDKs estás reemplazando la lista por defecto, no añadiéndote a ella. Y esa lista por defecto suele traer los servidores TURN con credenciales del proveedor. Poner un iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] que copiaste de un tutorial deja tu aplicación con STUN y sin TURN — perfecta en tu portátil, rota para todo el que esté detrás de un NAT simétrico. Si no vas a aportar tu propio TURN con credenciales, no toques iceServers.

Cómo distinguir un caso del otro en treinta segundos:

const pc = call.peer.instance; // RTCPeerConnection subyacente

pc.addEventListener('iceconnectionstatechange', () => {
  console.log('ICE:', pc.iceConnectionState);
});

// Y si quieres saber si de verdad entra audio:
setInterval(async () => {
  const stats = await pc.getStats();
  stats.forEach((r) => {
    if (r.type === 'inbound-rtp' && r.kind === 'audio') {
      console.log('paquetes recibidos:', r.packetsReceived, '| bytes:', r.bytesReceived);
    }
  });
}, 2000);

La lectura es directa: si iceConnectionState se queda en checking y no pasa a connected, es un problema de red y necesitas TURN. Si llega a connected pero packetsReceived se queda clavado en cero, el media no fluye. Y si packetsReceived sube alegremente pero el usuario no oye nada — vuelve a la sección 3, es el elemento de audio.

5. Llamadas de 0 segundos que sí te facturan

Ahora la parte que duele en la cuenta de resultados.

El primer descubrimiento incómodo: tu base de datos y el CDR del proveedor cuentan cosas distintas. Un intento fallido puede quedar registrado como llamada. Un duration de 0 no significa gratis. Y en telefonía tradicional existe una distinción que en las APIs modernas queda medio escondida: duration es el tiempo total desde que se inició el intento, mientras que billsec es solo el tiempo desde que alguien descolgó. Facturar contra el campo equivocado es un error clásico y sistemático.

Twilio, para su honra, lo documenta con todas las letras: desde julio de 2021, cualquier llamada completada de menos de un segundo se redondea a un segundo y genera evento de facturación (changelog). No existe la llamada de cero segundos gratuita.

Hay un fenómeno con nombre propio que conviene conocer aunque no lo sufras: FAS, *false answer supervision* — el operador marca la llamada como contestada antes de que nadie descuelgue, y el contador empieza a correr contra un teléfono que sigue sonando. Está bien documentado en el mundo SIP y es una de las razones por las que auditar tus propios CDR contra los del proveedor no es paranoia.

La regla práctica: no te fíes de tu tabla, pregúntale al proveedor.

// Telnyx: CDRs reales, filtrados por tipo de registro
const records = await telnyx.detailRecords.list({
  filter: { record_type: 'webrtc', date_range: 'yesterday' },
  sort: '-created_at',
});

// Twilio: registros de llamada con filtros
const calls = await client.calls.list({
  status: 'completed',
  startTimeAfter: new Date('2026-08-01'),
  limit: 500,
});

const sospechosas = calls.filter((c) => Number(c.duration) === 0);
console.log(`${sospechosas.length} llamadas "completadas" con duración 0`);

Ese console.log es el que te va a estropear la tarde la primera vez que lo ejecutes.

Docs: Telnyx detail records · Twilio Call resource

6. Facturación por minuto: el redondeo que te cuesta dinero

Aquí está el error de cálculo más común, y es de una línea:

// MAL: asume prorrateo perfecto al segundo
const coste = (duracionSeg / 60) * tarifaPorMinuto;

Casi ningún operador factura así. Lo normal es un incremento mínimo (bloques de 6, 30 o 60 segundos) y a menudo también una duración mínima facturable. Una llamada de 1 minuto y 5 segundos no cuesta 65 segundos: cuesta dos minutos.

// BIEN: respeta el incremento y el mínimo de TU contrato
function costeReal(duracionSeg, tarifaPorMinuto, { incrementoSeg = 60, minimoSeg = 0 } = {}) {
  const bloques = Math.ceil(duracionSeg / incrementoSeg) * incrementoSeg;
  const facturables = Math.max(bloques, minimoSeg);
  return (facturables * tarifaPorMinuto) / 60;
}

Los dos valores de esa función salen de tu contrato con el operador, no de este artículo. Búscalos, ponlos en configuración, y haz que tu estimación en cliente y tu cálculo en servidor usen la misma fórmula — si divergen, el usuario ve un precio durante la llamada y otro en su historial, y esa es una incidencia de soporte que se repite eternamente.

Y el detalle que menos gente comprueba: las tarifas se resuelven por prefijo, no por país. El mismo indicador puede cubrir varios destinos con precios muy distintos —fijo contra móvil, o territorios con recargo que comparten código con la metrópoli—, así que un longest-prefix match mal implementado te coloca en la tarifa equivocada de forma silenciosa. Audita tu tabla de tarifas contra la del operador prefijo a prefijo, no país a país.

7. Comprar números por API: fácil comprar, difícil configurar

Buscar y comprar es trivial:

const disponibles = await telnyx.availablePhoneNumbers.list({
  filter: { country_code: 'ES', phone_number_type: 'local', limit: 10 },
});

const order = await telnyx.numberOrders.create({
  phone_numbers: [{ phone_number: disponibles.data[0].phone_number }],
  connection_id: process.env.TELNYX_CONNECTION_ID,
  messaging_profile_id: process.env.TELNYX_MESSAGING_PROFILE_ID,
});

Fíjate en que en el momento del pedido sí puedes mandar connection_id y messaging_profile_id juntos. Es después cuando se separan, y esto sorprende a casi todo el mundo:

// Voz — endpoint base
await telnyx.phoneNumbers.update(phoneId, { connection_id: CONNECTION_ID });

// SMS — endpoint DISTINTO
await telnyx.phoneNumbers.messaging.update(phoneId, {
  messaging_profile_id: MESSAGING_PROFILE_ID,
});

messaging_profile_id no está entre los campos aceptados por PATCH /phone_numbers/{id} — el cuerpo de esa petición admite address_id, billing_group_id, connection_id, customer_reference, external_pin, hd_voice_enabled y tags, y nada más. Si lo mandas ahí, en el mejor de los casos se ignora en silencio y te quedas con un número que hace llamadas y no recibe SMS. Es un fallo particularmente cruel porque el número funciona: solo falla la mitad que el usuario probará tres días después, cuando espere un código de verificación que nunca llega.

De ahí salen las dos reglas que de verdad importan al aprovisionar:

Comprar cuesta dinero; configurar, no. El pedido es la operación irreversible. Si la configuración posterior falla, reintenta con backoff, y si sigue fallando, deja el número marcado como degradado y avisa — pero no conviertas un fallo de configuración en un fallo de compra, porque acabas con un número comprado y facturado que nadie liberó.

Verifica leyendo, no asumiendo. Después de asignar el perfil de mensajería, vuelve a leerlo del proveedor y compáralo. Un PATCH que devuelve 200 no garantiza el estado final que esperas.

Y si algo se tuerce de verdad, libera el número explícitamente — en Twilio, borrar el recurso es liberarlo, y el operador puede reasignarlo a otro cliente:

await client.incomingPhoneNumbers(sid).remove();

Docs: buscar números · crear pedido · actualizar número · perfil de mensajería · liberar número en Twilio

8. Entonces… ¿lo construyo o no?

Constrúyelo si la telefonía es tu producto, necesitas control del enrutado, o tienes volumen suficiente para que la complejidad se pague sola.

No lo construyas si lo que quieres es «que mis usuarios puedan llamar» como una función más del producto. El coste oculto nunca es el código del demo: es el ciclo de vida. CDR, reintentos, cumplimiento normativo por país, tarifas por prefijo, el número que se compró y no se configuró. Eso es lo que se come los meses.

Si estás en el segundo grupo y lo que necesitas es simplemente un segundo número o llamadas internacionales sin montar nada, hay productos que ya resolvieron todo esto — Twin Phone es uno de ellos, y es en lo que trabajo, así que tómalo con el descuento que corresponda.

Checklist para llevarte

La API key vive en el servidor. El navegador recibe un JWT efímero y nada más.
createToken devuelve texto plano, no JSON.
Los eventos de Telnyx se escuchan en el cliente, no en el objeto call.
Sin remoteElement, la llamada conecta y no se oye nada. Uno por llamada si hay concurrencia.
No sobrescribas iceServers salvo que aportes tu propio TURN: reemplaza, no añade.
iceConnectionState + packetsReceived distinguen «problema de red» de «problema de DOM» en treinta segundos.
Factura contra el tiempo de conversación, no contra el tiempo de intento.
Respeta el incremento y el mínimo facturable de tu contrato. Misma fórmula en cliente y servidor.
Resuelve tarifas por prefijo, no por país.
connection_id y messaging_profile_id van juntos al pedir, separados al reconfigurar.
Después de configurar, vuelve a leer del proveedor y compara.

¿Has peleado con VoIP y te has topado con otros fantasmas? Cuéntamelo en los comentarios — colecciono formas creativas en las que la telefonía se rompe.

Calling Abroad Without an App: A Practical Guide to Browser-Based International Calls

Ivan Labasok — Mon, 01 Jun 2026 20:55:15 +0000

Staying in touch across borders used to come down to two bad options: a phone bill that made you wince, or yet another messaging app that only works if the person on the other end installs it too. Neither helps much when you just need to reach a relative, a client, or a supplier sitting next to an ordinary phone in another country.

There is a third option that has quietly become practical: calling straight from your web browser. No SIM card, no downloads, no contract. You open a page, sign in, and dial. Here is a plain look at how it works, when it makes sense, and what to check before you depend on it.

What "calling from the browser" actually means

Modern browsers can carry voice over the internet using a built-in technology called WebRTC — the same thing that powers in-browser video meetings. On its own, that only connects two browsers. The useful part is when a service bridges that internet leg onto the real telephone network, so the person you are calling receives a normal call on their landline or mobile. They do not need an app, an account, or anything installed. To them, the phone simply rings.

That distinction matters more than it sounds. App-to-app calls — the kind most messengers offer — only work if both sides use the same app. Browser-to-phone calling reaches anyone who has a phone number, which is still almost everyone.

Why it tends to be cheaper

Traditional plans charge you every month whether you make international calls or not, and roaming rates can be brutal. The browser-based model usually flips that to pay-as-you-go: you top up a small balance and pay per minute only for the calls you actually make, often from a few cents a minute.

Services like Twin Phone, for example, start from around 0.02 USD per minute with no monthly fee, and show the exact per-country rate before you dial — so there is no bill shock after the fact. For someone who makes a handful of international calls a month, paying only for those minutes is dramatically cheaper than a flat subscription.

It works on whatever you already own

Because everything runs in the browser, the same setup works on Windows, macOS, Android, and iPhone. There is nothing to install and nothing taking up storage on your phone, and you are always on the latest version because there is no app to update. If you switch from your laptop to your phone, you just open the page again and sign in.

A typical first call, step by step

Create a free account — it takes seconds and does not require a card up front.
Add a small amount of credit to your balance.
Check the rate for the country you are calling so you know the price before you dial.
Enter the full international number and talk.

That is the whole flow. The friction that used to come with international calling — buying a calling card, topping up a SIM, configuring a VoIP client — mostly disappears.

What to check before you rely on it

A few practical things separate a service you can trust from one that frustrates you:

Transparent per-country pricing, shown before the call rather than buried in a statement afterward.

Real termination to the phone network, so the recipient gets an ordinary call and does not need to install anything.

Clear audio on a stable connection. Browser calling is only as good as your internet at that moment, so a decent Wi-Fi or mobile-data connection matters.

No lock-in. Pay-as-you-go credit you control beats a contract you have to cancel, especially if your calling needs are seasonal.

When this is the right tool

Browser-based calling fits best when you make occasional international calls, when you need to reach someone who will not install an app, when you work across time zones, or when you are traveling and do not want roaming charges. It is not meant to replace a full business phone system with queues and extensions, but for reaching a real phone number cheaply and quickly, it is hard to beat.

The short version: if you have a browser and a few dollars of credit, you can call almost any phone in the world today, without installing a thing. For anyone tired of monthly plans and app-only calls, it is worth trying once — the first call usually answers the question better than any explanation can.

DEV Community: Ivan Labasok

Validar números de teléfono en JavaScript: por qué tu expresión regular está mal

En corto

1. Por qué tu expresión regular para teléfonos está mal

2. E.164: el único formato que deberías guardar

3. libphonenumber-js en cuatro líneas

4. isPossible vs isValid: cuál usar y cuándo

5. Formatear mientras el usuario escribe

6. México, Argentina e Italia: los tres casos que rompen todo

7. Validar no es lo mismo que poder llamar

8. Qué guardar en la base de datos

Checklist para llevarte

Llamar a un teléfono real desde el navegador: WebRTC, SIP y lo que nadie te cuenta de la facturación

En corto

El stack en una frase

1. Autenticar el navegador sin filtrar tu API key

2. La primera llamada

3. «La llamada se establece pero no hay audio»

4. Audio unidireccional: cuando el problema sí es la red

5. Llamadas de 0 segundos que sí te facturan

6. Facturación por minuto: el redondeo que te cuesta dinero

7. Comprar números por API: fácil comprar, difícil configurar

8. Entonces… ¿lo construyo o no?

Checklist para llevarte

Calling Abroad Without an App: A Practical Guide to Browser-Based International Calls

3. `libphonenumber-js` en cuatro líneas

4. `isPossible` vs `isValid`: cuál usar y cuándo