Comprobación de la capacidad del dispositivo RCS

Se puede realizar una comprobación de capacidad para determinar si el dispositivo de destino es compatible con las funciones de mensajería RCS. Actualmente hay dos maneras de realizar una comprobación de la capacidad del dispositivo:

• Comprobación individual del dispositivo
• Comprobación a granel

Comprobación de la capacidad de los dispositivos individuales

La comprobación se realiza a través de un GET a la siguiente URL:

https://api.nexmo.com/v1/channel-manager/rcs/agents/{vonage_id}/google/phones/{phone_number}/capabilities

Hay dos parámetros de ruta necesarios:

• vonage_id. Este es el ID de remitente para el agente RCS, y se le proporcionará como parte de la Configuración de RCS y proceso de incorporación.
• phone_number. El número del dispositivo para el que se realiza la comprobación de capacidad.

A Authorization como parte de la solicitud. El valor del encabezado debe contener un JWT (JSON Web Token) válido con el formato Bearer ${JWT}. El JWT puede crearse usando el ID de aplicación y la clave privada de tu aplicación de Vonage con la cual está asociado el ID de remitente de RCS. Ver Autenticación para más información sobre la creación de JWTs.

Véase el Especificación de la API de Channel Manager para conocer todos los detalles técnicos de este punto final.

Ejemplo de solicitud

A continuación se muestra un ejemplo de solicitud cURL al punto final de comprobación de capacidades:

curl --location 'https://api.nexmo.com/v1/channel-manager/rcs/agents/VonageBasic/google/phones/447900000000/capabilities' \
--header 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJ...'

Respuestas

200 OK

Si el dispositivo es alcanzable RCS, un 200 OK Se recibirá una respuesta HTTP. El cuerpo de la respuesta contendrá un array de las características RCS soportadas por el dispositivo, por ejemplo:

{ 
  "features": 
   [ 
     "RICHCARD", 
     "RICHCARD_CAROUSEL", 
     "CREATE_CALENDAR_EVENT", 
     "DIAL_PHONE_NUMBER", 
     "OPEN_URL", 
     "SHARE_LOCATION", 
     "VIEW_LOCATION" 
   ] 
}

400 Solicitud errónea

Hay varias circunstancias en las que un 400 Bad Request Se recibirá una respuesta HTTP, como que el ID de remitente del agente no es válido o que el número de teléfono que se está comprobando tiene un formato no válido.

403 Prohibido

Si se utiliza un agente de prueba y el número no está en la lista de números permitidos para ese agente, o si se utiliza un agente activo y el número no está conectado a una red admitida en el país en el que se ha lanzado el agente, aparecerá un mensaje de error 403 Forbidden Se recibirá una respuesta HTTP.

404 no encontrado

Si el dispositivo no es alcanzable RCS, un 404 Not Found Se recibirá una respuesta HTTP.

Comprobación de la capacidad del dispositivo a granel

La comprobación se realiza a través de un POST a la siguiente URL:

https://api.nexmo.com/v1/channel-manager/rcs/agents/{vonage_id}/google/{operation}

Hay dos parámetros de ruta necesarios:

• vonage_id. Este es el ID de remitente para el agente RCS, y se le proporcionará como parte de la Configuración de RCS y proceso de incorporación.
• operation. La operación que debe realizar el agente RBM. En este caso es users:batchGet.

A Authorization como parte de la solicitud. El valor del encabezado debe contener un JWT (JSON Web Token) válido con el formato Bearer ${JWT}. El JWT puede crearse usando el ID de aplicación y la clave privada de tu aplicación de Vonage con la cual está asociado el ID de remitente de RCS. Ver Autenticación para más información sobre la creación de JWTs.

A Content-Type como parte de la solicitud. El valor de la cabecera debe ser application/json.

La solicitud debe contener un cuerpo JSON, que tiene una propiedad: users. Se trata de un matriz de cadenas que representan los números de teléfono que deben muestrearse durante la comprobación masiva.

A diferencia de la comprobación individual de capacidades, la comprobación masiva no devuelve una lista de funciones compatibles. Para calcular el número de usuarios accesibles mediante RBM, realice una comprobación masiva de capacidades. Las comprobaciones masivas indican si se puede acceder a un número de teléfono, pero no las funciones que admite.

• Cada comprobación masiva debe incluir entre 500 y 10.000 números de teléfono únicos. Para más, realice varias comprobaciones.
• Tenga en cuenta también que las solicitudes con menos de 500, más de 10.000 o números duplicados devolverán un error.
• Las comprobaciones masivas devuelven una lista de números a los que su agente puede llamar en las operadoras lanzadas y estimaciones del total de usuarios accesibles en todas las operadoras.

Estimación del total de usuarios alcanzables

Mientras que las respuestas de comprobación masiva incluyen una lista de números de teléfono inmediatamente localizables en las compañías lanzadas por su agente (reachableUsers), las respuestas también incluyen dos valores que ayudan a estimar el número total de usuarios accesibles en todas las operadoras.

Cómo funciona:

1. RBM muestrea aleatoriamente el ~75% de los números de una comprobación de capacidad masiva (totalRandomSampleUserCount).
2. RBM también devuelve el recuento de números alcanzables por RBM a partir de la muestra (reachableRandomSampleUserCount).
3. Al dividir reachableRandomSampleUserCount por totalRandomSampleUserCountpuede estimar el porcentaje de Numbers que su agente podría alcanzar si se lanzara en todas las compañías.

Ejemplo:

Si envía 5.000 números de teléfono, RBM puede muestrear aleatoriamente 3.750. Si 3.000 de ellos son localizables, entonces el 80% de los números muestreados eran localizables.

Véase el Especificación de la API de Channel Manager para conocer todos los detalles técnicos de este punto final.

Ejemplo de solicitud

A continuación se muestra un ejemplo de solicitud cURL al punto final de comprobación masiva de capacidades:

curl -X POST https://api.nexmo.com/v1/channel-manager/rcs/agents/VonageBasic/google/users:batchGet \
-H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJ..." \
-H "Content-Type: application/json" \
-d '{
  "users": [
    "34613994828",
    "34613994829"
  ]
}'

Respuestas

200 OK

{ 
  "reachableUsers": [ 
    "34613994828",
    "34613994829"
    // rest of reachableUsers list
  ],
  "totalRandomSampleUserCount": 632,
  "reachableRandomSampleUserCount": 324
}

400 Solicitud errónea

Hay varias circunstancias en las que un 400 Bad Request Se recibirá una respuesta HTTP, como que el ID de remitente del agente no es válido o que uno o varios de los números de teléfono comprobados tienen un formato no válido.