APIs de CAMARA para Branded Calling: Diferencias entre Brand Registration y Verified Caller

La pérdida de confianza en el canal de voz es una realidad: se estima que hasta un 90% de las llamadas empresariales no son respondidas porque los usuarios desconocen quién llama. Para revertir esta tendencia, el sector de las telecomunicaciones impulsa la «apificación» de sus redes.

El Proyecto CAMARA, una iniciativa de código abierto para que los desarrolladores accedan a capacidades de red de los operadores, ha definido dos APIs críticas en la categoría de Authentication and Fraud Prevention:

• Verified Caller (en cuya definición ha participado Quobis)
• Brand Registration

Aunque ambas son pilares del Branded Calling, puede resultar complicado entender que cumplen funciones distintas e incluso complementarias. En este post, intentaremos aclarar cuáles son las funciones y limitaciones de cada una de ellas y en qué casos de uso aplica una, otra o ambas.

En el ecosistema de las APIs de red , la confusión entre términos es habitual debido a la velocidad de su desarrollo. Para los operadores y desarrolladores que buscan asegurar la confianza en las comunicaciones, es crítico distinguir entre Brand Registration y Verified Caller.

¿Qué es Brand Registration API?

La API de Brand Registration actúa como el proceso de identidad centralizado. Su objetivo es permitir que las empresas registren y validen su identidad de marca ante los proveedores de servicios de comunicación (CSP) de forma estandarizada.

• Propósito: Proporcionar una «fuente de verdad» para que el operador de origen pueda inyectar el nombre correcto de la marca en la señalización de la llamada o el mensaje. Asegura que el Display Name (el nombre que aparece en pantalla) sea coherente y esté validado por el operador de origen, evitando que sea modificado o marcado como «Desconocido».
• Funcionamiento: Vincula una identidad legal (nombre de empresa) a una serie de activos de comunicación (números de teléfono o nombres de remitente).
• Beneficio clave:  Actualmente, la especificación de CAMARA para Brand Registration se centra en activos alfanuméricos. En un futuro se pretende que facilite el despliegue de servicios de Branded Calling y Rich Business Messaging (RBM), que permitirán mostrar un logo en el terminal del usuario, ya verificado previamente por la red.

La API de Brand Registration está diseñada, en su fase inicial, para interoperar con sistemas que todavía tienen limitaciones en la señalización de red. Estos son los motivos que justifican qué se limite a caracteres alfanuméricos:

• Compatibilidad con protocolos legacy: Muchos de los sistemas de visualización de identidad (como el CNAM evolucionado o ciertos encabezados de SIP) están optimizados para texto. Registrar un «Nombre de Marca» (Brand Name) alfanumérico garantiza que la identidad se muestre correctamente incluso en dispositivos que no soportan gráficos enriquecidos.
• Enfoque en el «Display Name»: El objetivo primordial actual es asegurar que, en el «A-party» (el que llama), el nombre que aparece en la pantalla del receptor sea una cadena de texto validada por el operador, evitando que el terminal lo marque simplemente como «Fraude» o «Número desconocido».
• Estandarización de la cadena de confianza: Validar una cadena de texto alfanumérica contra bases de datos legales de empresas es un proceso más sencillo de estandarizar globalmente en esta primera fase que la gestión de archivos binarios (imágenes/logos), que requieren servidores de contenido (CDN) y protocolos de entrega de medios más complejos.

Se prevé que, en futuras iteraciones, esta API sirva como ancla para vincular certificados de marca verificados (VMC) y logotipos, pero hoy en día la especificación se centra exclusivamente en la identidad textual.

¿Qué es Verified Caller API?

Por otro lado, la API de Verified Caller es un mecanismo de verificación en tiempo real. Se centra en confirmar que una llamada específica es legítima y que el originador tiene derecho a usar ese número de teléfono.

• Propósito: Confirmar en tiempo real que el número de teléfono que aparece en el terminal no ha sido suplantado (spoofing).
• Funcionamiento: Permite a una aplicación consultar si una llamada entrante ha sido verificada mediante protocolos de red como STIR/SHAKEN (especialmente en regiones como EE.UU.) o mediante mecanismos de validación de tránsito en el resto del mundo. Esta API permite consultar si una llamada entrante ha sido autenticada por la red de origen. Verified Caller actúa como la API de exposición de esos resultados de red.
• Beneficio clave: Proporciona una capa de seguridad técnica que determina si la llamada debe marcarse como «Verificada» en la pantalla del smartphone, reduciendo drásticamente las tasas de llamadas bloqueadas por sospecha de spam.

Verified Caller no define cómo se muestra la marca, sino que valida si el origen de la llamada tiene derecho legítimo a utilizar ese identificador, detectando posibles intentos de spoofing.

El ecosistema de confianza “Authentication and Fraud Prevention APIs”: Del Registro a la «Business Card»

Para entender cómo estas dos APIs del subconjunto de APIs de “Autenticación y prevención del fraude” trabajan juntas, debemos visualizar el flujo de una comunicación empresarial legítima:

• Paso 1: Brand Registration: La empresa registra sus activos alfanuméricos (Nombre, Entidad Legal). Es una base de datos de identidad estática.
• Paso 2: Verified Caller: En el momento de la llamada, esta API confirma que el originador es legítimo.
• Paso 3: Operator-certified Business Card. Si la validación es positiva, el operador genera y entrega la «business card».

Operator-certified business card

La «operator-certified business card» que menciona la especificación de Verified Caller es la representación visual de la confianza (lo que el usuario final ve). Se compone de la identidad recuperada de Brand Registration y el sello de autenticidad generado por Verified Caller.

La especificación actual de CAMARA incluye:

• Identidad verificada: El nombre comercial que el operador garantiza.
• Contexto de llamada: El propósito (alfanumérico) de la comunicación.
• Garantía de origen: La seguridad de que no hay spoofing involucrado.

¿Se puede incluir un logotipo de la marca empleando estas APIs?

La ausencia del logotipo en la Operator-certified Business Card (dentro del marco actual de la API de Verified Caller) es una decisión de diseño basada en la arquitectura actual de las redes de telefonía.

Existen tres razones técnicas fundamentales por las que el logotipo no forma parte de esta «tarjeta» hoy en día:

1.  Limitaciones del Plano de Señalización (Protocolo SIP)

La llamada de voz viaja a través de protocolos de señalización (principalmente SIP). Estos protocolos están diseñados para transportar paquetes de datos extremadamente ligeros (texto y parámetros técnicos). No es eficiente, ni en muchos casos posible, «incrustar» un archivo de imagen (binario) directamente en el mensaje de señalización que establece la llamada.

La «Business Card» de Verified Caller se limita a lo que el protocolo puede transportar de forma segura y universal: metadatos alfanuméricos (nombre de la marca, motivo de la llamada y el estado de verificación).

2. El problema de la resolución de activos (Rendering)

Para que un logo aparezca en pantalla, el terminal (el smartphone) necesita descargar ese archivo desde un servidor. A día de hoy falta un estándar de alojamiento que lo facilite. La API de Verified Caller certifica la identidad, pero no define dónde se aloja la imagen ni cómo se garantiza que el enlace a esa imagen es seguro.

También existen razones vinculadas a la latencia: Una consulta de red para descargar un logo durante los milisegundos que tarda en sonar el teléfono podría retrasar la señalización o causar fallos en la visualización si la conexión de datos es inestable.

3. Dependencia del canal de datos (RCS vs. Voz Tradicional)

La visualización de elementos multimedia (logos, banners) depende de que la comunicación se realice sobre RCS (Rich Communication Services) o mediante soluciones propietarias de fabricantes (como el Samsung Smart Call o Apple Business Connect).

Verified Caller es una API de red agnóstica: debe funcionar tanto para un smartphone de última generación con 5G como para terminales más básicos. Al centrarse en una Business Card alfanumérica, la GSMA asegura que la certificación del operador sea compatible con la infraestructura global existente, sin obligar a que todo el ecosistema soporte multimedia de forma nativa e inmediata.

Aunque hoy se limita a la precisión alfanumérica para garantizar la compatibilidad global y la baja latencia, es el cimiento necesario para que, en un futuro cercano, el registro de marca pueda disparar la visualización de activos multimedia en terminales compatibles con RCS.

Modelo Detached: Verificación fuera de banda (Out-Of-Band)

Desde un punto de vista arquitectónico, las APIs de CAMARA están diseñadas para soportar modelos ‘detached’ o desacoplados. Esto es vital en escenarios internacionales donde la señalización de red suele degradarse o perderse. Al apoyarse en estructuras como los contenedores de datos auténticos (ACDC), Verified Caller puede validar la legitimidad de una comunicación a través de canales paralelos, asegurando que la ‘Business Card’ llegue íntegra al terminal del usuario final, independientemente de la complejidad de los saltos de red intermedios.

Este enfoque ‘detached’ no solo es la solución a la degradación de la señalización en tránsitos internacionales, sino que es el motor de los escenarios OTT. Al desacoplar la verificación del canal de voz, las aplicaciones móviles pueden consultar la legitimidad de una llamada a través del canal de datos. Esto permite que, incluso en redes que no soportan estándares modernos de señalización, el usuario reciba una Business Card enriquecida y verificada, permitiendo a las empresas mantener el control de su identidad de marca de forma universal.

Si bien la especificación actual (v0.1.0) se centra en el «esqueleto» alfanumérico, los documentos de visión de la GSMA Open Gateway y el Camara Steering Committee subrayan que el objetivo final es la identidad enriquecida (incluido logo). El modelo detached es el camino técnico reconocido para lograr esa evolución sin tener que actualizar cada switch telefónico del planeta.

Al desacoplar la validación de la identidad del canal de voz, el modelo ‘detached’ permite que activos multimedia —como logotipos verificados mediante VMC— sean invocados a través del canal de datos. De esta forma, la Operator-certified Business Card deja de ser una limitación alfanumérica de la red de señalización para convertirse en una identidad visual rica y segura, gestionada por aplicaciones que consumen las APIs de CAMARA de forma independiente a la antigüedad de la infraestructura de red intermedia.»

Mientras que las APIs de CAMARA ofrecen una interfaz simplificada para el consumo de servicios, su robustez técnica reside en el cumplimiento de estándares de red y criptografía como RCD y PASSporT. La evolución hacia contenedores ACDC y estándares  VVP/ OVC (estándares inspirados en el ecosistema de email (como BIMI y sus certificados VMC).) marcará la próxima generación de estas APIs, permitiendo una identidad visual móvil plenamente verificada y universal