Dépannage des échecs de déplacement du numéro appelant Webex avec erreur HTTP 429

Problème

Lorsque vous essayez de déplacer un numéro de téléphone entre des emplacements d'appel Webex dans le Control Hub, l'opération de déplacement échoue avec des symptômes d'erreur spécifiques. L'interface du Control Hub affiche « Move in Progress » initialement, puis un message « The server is busy ». Veuillez patienter et réessayer." Aucune commande PSTN ou entrée du Gestionnaire des tâches n'est créée pendant l'échec de la tentative.

Les informations de débogage du navigateur affichent la réponse HTTP 429 « Too Many Requests » à partir du point de terminaison API de création de tâches admin-batch-service. Les détails d'erreur spécifiques capturés incluent :

Status: 429
Status Text: Too Many Requests
URL: https://admin-batch-service-r.wbx2.com/api/v1/customers/<org-id>/jobs
Message: The server is busy. Please wait and try again. TrackingID: ATLAS_1e6ae5c6-ca3c-4c1a-b40f-4b49668c74a9_27

En outre, l'analyse back-end révèle que le workflow de déplacement rencontre des échecs de validation de portabilité lorsque les emplacements source et de destination utilisent des fournisseurs de plans d'appel Cisco différents, même lorsque les deux emplacements sont configurés avec des plans d'appel Cisco.

Environnement

• Appels Webex avec plan d'appel Cisco

• Version du Control Hub : 20260812-0ec355

• Plusieurs sites professionnels avec différents fournisseurs PSTN sous-jacents

• Emplacement source utilisant IntelPeer comme fournisseur RTPC

• Emplacement de destination utilisant Telnyx comme fournisseur RTPC

• Le numéro de téléphone est actif, non attribué et non lié aux utilisateurs ou aux services d'appel

• Les emplacements source et de destination sont opérationnels

Résolution

Ce problème a été résolu par une intervention d'ingénierie principale. L'équipe d'ingénierie a constaté que le numéro était périmé dans le système Terminus, ce qui a entraîné l'échec des contrôles de validation préalables au transfert. Les étapes suivantes ont été suivies :

Réparation du back-end

Étape 1: L'équipe technique a identifié le numéro périmé dans Terminus

Étape 2: Le numéro a été mis à jour dans le système principal

Étape 3: Les contrôles de validation préalables au déménagement ont été corrigés pour indiquer que le numéro était admissible au déménagement

Nouvelle tentative et vérification du client

Étape 1: Le client a tenté à nouveau de déplacer le numéro après la correction du serveur principal

Étape 2: Le numéro a été déplacé vers l'emplacement de destination

Étape 3: Le client s'est attribué le numéro et a vérifié la fonctionnalité d'appel entrant

Analyse de dépannage effectuée

L'enquête a révélé plusieurs facteurs techniques :

Analyse de fichier HAR :

Motif

Ce problème est dû à des informations d'état de numéro périmé dans le système Terminus, ce qui a entraîné l'échec des contrôles de validation préalables au déplacement. Cette incohérence des données du serveur principal a empêché la reconnaissance du numéro comme éligible pour l'opération de déplacement.

En outre, le cas a montré que les déplacements entre des emplacements de plan d'appel Cisco avec différents fournisseurs RTPC sous-jacents (IntelPeer ou Telnyx) peuvent rencontrer des restrictions d'admissibilité dans le flux de travail de déplacement direct standard, même lorsque les deux emplacements utilisent des plans d'appel Cisco. Cependant, la résolution principale impliquait la correction des données obsolètes plutôt que l'adressage de la compatibilité du fournisseur.

Autres informations utiles

• Générer un fichier HAR dans votre navigateur

• Gestion des numéros de téléphone dans le Control Hub

• Premiers pas avec le plan d'appel Cisco

• Consignes et politiques relatives au portage du numéro du plan d'appel Cisco

• Assistance technique de Cisco et téléchargements

Historique de révision

Révision	Date de publication	Commentaires
1.0	10-Nov-2026	Première publication