Vérification de la capacité de l'appareil RCS

Une vérification des capacités peut être effectuée pour s'assurer que l'appareil cible supporte les fonctionnalités de messagerie RCS. Il existe actuellement deux façons d'effectuer une vérification des capacités d'un appareil :

• Contrôle individuel des appareils
• Contrôle en vrac

Vérification de la capacité de chaque appareil

Le contrôle s'effectue par l'intermédiaire d'un GET à l'URL suivante :

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

Deux paramètres sont requis pour le chemin d'accès :

• vonage_id. Il s'agit de l'identifiant de l'expéditeur pour l'agent RCS, qui vous sera fourni dans le cadre de l'appel d'offres. Processus d'installation et d'intégration du RCS.
• phone_number. Le numéro de l'appareil pour lequel le contrôle de capacité est effectué.

A Authorization est requis dans le cadre de la demande. La valeur de l'en-tête doit contenir un JWT (JSON Web Token) valide au format Bearer ${JWT}. Le JWT peut être créé en utilisant l'identifiant de l'application et la clé privée de votre application Vonage à laquelle l'identifiant de l'expéditeur RCS est associé. Voir Authentification pour plus d'informations sur la création de JWT.

Voir le Spécification de l'API du gestionnaire de canaux pour obtenir tous les détails techniques de ce critère d'évaluation.

Exemple de demande

Vous trouverez ci-dessous un exemple de requête cURL vers le point final de vérification des capacités :

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

Réponses

200 OK

Si l'appareil est joignable par le RCS, un 200 OK Une réponse HTTP sera reçue. Le corps de la réponse contiendra un tableau des fonctionnalités RCS prises en charge par l'appareil, par exemple :

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

400 Mauvaise demande

Il existe diverses circonstances dans lesquelles un 400 Bad Request Une réponse HTTP sera reçue, par exemple l'ID de l'expéditeur de l'agent n'est pas valide ou le format du numéro de téléphone vérifié n'est pas valide.

403 Interdit

Si vous utilisez un agent de test et que le numéro n'est pas inscrit sur la liste des numéros autorisés pour cet agent, ou si vous utilisez un agent en direct et que le numéro n'est pas connecté à un réseau pris en charge dans le pays dans lequel l'agent a été lancé, un message d'avertissement est envoyé à l'agent. 403 Forbidden Une réponse HTTP sera reçue.

404 Non trouvé

Si l'appareil n'est pas joignable par le RCS, un message 404 Not Found Une réponse HTTP sera reçue.

Vérification de la capacité des dispositifs en vrac

Le contrôle s'effectue par l'intermédiaire d'un POST à l'URL suivante :

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

Deux paramètres sont requis pour le chemin d'accès :

• vonage_id. Il s'agit de l'identifiant de l'expéditeur pour l'agent RCS, qui vous sera fourni dans le cadre de l'appel d'offres. Processus d'installation et d'intégration du RCS.
• operation. L'opération à effectuer par l'agent RBM. Dans le cas présent, il s'agit de users:batchGet.

A Authorization est requis dans le cadre de la demande. La valeur de l'en-tête doit contenir un JWT (JSON Web Token) valide au format Bearer ${JWT}. Le JWT peut être créé en utilisant l'identifiant de l'application et la clé privée de votre application Vonage à laquelle l'identifiant de l'expéditeur RCS est associé. Voir Authentification pour plus d'informations sur la création de JWT.

A Content-Type doit faire partie de la demande. La valeur de l'en-tête doit être application/json.

La demande doit contenir un corps JSON, qui possède une propriété : users. Il s'agit d'un réseau de chaînes représentant les numéros de téléphone à échantillonner lors de la vérification en bloc.

Contrairement à la vérification individuelle des capacités, la vérification en bloc ne renvoie pas de liste des fonctionnalités prises en charge. Pour estimer le nombre d'utilisateurs joignables par RBM, effectuez un contrôle de capacité en bloc. Les contrôles en bloc indiquent si un numéro de téléphone est joignable, mais pas les fonctions qu'il prend en charge.

• Chaque vérification en bloc doit inclure entre 500 et 10 000 numéros de téléphone uniques. Pour un plus grand nombre, effectuez plusieurs vérifications.
• Notez également que les demandes comportant moins de 500, plus de 10 000 ou des numéros en double renverront une erreur.
• Les vérifications de masse renvoient une liste de numéros que votre agent peut joindre sur les opérateurs lancés et des estimations du nombre total d'utilisateurs joignables sur l'ensemble des opérateurs.

Estimation du nombre total d'utilisateurs joignables

Alors que les réponses aux chèques en vrac comprennent une liste de numéros de téléphone immédiatement joignables sur les supports lancés par votre agent (reachableUsers), les réponses comprennent également deux valeurs qui permettent d'estimer le nombre total d'utilisateurs joignables sur l'ensemble des opérateurs.

Comment cela fonctionne-t-il ?

1. RBM prélève de manière aléatoire ~75% des nombres à partir d'une vérification globale des capacités (totalRandomSampleUserCount).
2. RBM renvoie également le nombre de Numbers accessibles par RBM à partir de l'échantillon (reachableRandomSampleUserCount).
3. En divisant reachableRandomSampleUserCount par totalRandomSampleUserCountvous pouvez estimer le pourcentage de numéros que votre agent pourrait atteindre s'il était lancé sur tous les transporteurs.

Exemple :

Si vous soumettez 5 000 numéros de téléphone, RBM peut en sélectionner 3 750 au hasard. Si 3 000 d'entre eux sont joignables, alors 80 % des numéros échantillonnés étaient joignables.

Voir le Spécification de l'API du gestionnaire de canaux pour obtenir tous les détails techniques de ce critère d'évaluation.

Exemple de demande

Vous trouverez ci-dessous un exemple de requête cURL vers le point d'arrivée de la vérification globale des capacités :

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"
  ]
}'

Réponses

200 OK

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

400 Mauvaise demande

Il existe diverses circonstances dans lesquelles un 400 Bad Request Une réponse HTTP sera reçue, par exemple l'ID de l'expéditeur de l'agent n'est pas valide, ou un ou plusieurs des numéros de téléphone vérifiés ont un format non valide.