Résolution des problèmes de SMS troubleshooting-sms

Le problème est apparu sur un ou plusieurs comptes.

Dans ce cas, vous pouvez appliquer d'autres procédures de résolution des problèmes individuellement sur chaque compte. Il est préférable de désactiver les autres comptes lors du diagnostic d'un compte afin de réduire le trafic réseau et le nombre de logs.

Le problème ne s'affichait pas lorsqu'un seul compte était actif à un moment donné.

Vous avez un conflit entre les comptes. Comme nous l'avons déjà mentionné, Adobe Campaign traite les comptes individuellement, mais le fournisseur peut les traiter comme un compte unique.

• Vous utilisez des combinaisons nom d'utilisateur / mot de passe différentes entre tous vos comptes.
  Vous devrez contacter le fournisseur pour qu'il diagnostique les conflits potentiels de son côté.

• Certains comptes externes partagent la même combinaison nom d'utilisateur / mot de passe.
  Le fournisseur n'a aucun moyen de savoir de quel compte externe provient le BIND PDU, de sorte qu'il traite toutes les connexions à partir de plusieurs comptes comme une seule. Il se peut qu'il ait redirigé les MO et SR de manière aléatoire sur les deux comptes, ce qui a provoqué des problèmes.
  Si le fournisseur prend en charge plusieurs codes courts pour le même nom d'utilisateur / mot de passe, vous devrez leur demander où placer ce numéro court dans le BIND PDU. Notez que cette information doit être placée dans le BIND PDU et non dans SUBMIT_SM, puisque le BIND PDU est le seul endroit qui permettra d'utiliser correctement les MO de routage.
  Consultez la section Informations dans chaque type de PDU ci-dessus pour savoir quel champ est disponible dans le BIND PDU, en général vous ajoutez le numéro court dans address_range, mais cela nécessite une assistance spéciale de la part du fournisseur. Contactez-le pour savoir comment il s'attend à acheminer de manière indépendante plusieurs numéros courts.
  Adobe Campaign prend en charge la gestion de plusieurs numéros courts sur le même compte externe.

Vérifiez si le connecteur a été changé récemment et par qui (vérifiez les comptes externes en tant que groupe).

select saccount, (sserver ||':'||sport) as serverPort, iextaccountid, CASE WHEN N0.iactive=1 THEN 'Yes' ELSE 'No' END as "(x) Enabled",

(select X1.sname from xtkoperator X1 where N0.icreatedbyid = X1.ioperatorid) as "Created By",

(select X1.sname from xtkoperator X1 where N0.imodifiedbyid = X1.ioperatorid) as "Last Modified By",

N0.slabel as "External Account", N0.tslastmodified as "LastModifiedDate"

from nmsextaccount N0 LEFT JOIN xtkoperator X0 ON (N0.icreatedbyid=X0.ioperatorid) order by 8 DESC LIMIT 50;

Recherchez (dans le répertoire /postupgrade) si le système a été mis à niveau et quand.

Déterminez si des packages affectant les SMS ont pu être mis à jour récemment (https://experienceleague.adobe.com/var/log/dpkg.log?lang=fr).

Si le problème se produit dans un environnement de mid-sourcing, vérifiez que les logs de diffusion et les broadlogs sont correctement créés et mis à jour sur le serveur de mid-sourcing. Si ce n'est pas le cas, il ne s'agit pas d'un problème de SMS.

Si tout fonctionne sur le serveur de mid-sourcing et que les SMS sont correctement envoyés, mais que l'instance marketing n'est pas correctement mise à jour, il est possible qu'un problème de synchronisation mid-sourcing se produise.

Si le BIND PDU renvoie un code non nul command_status, demandez d'autres informations au fournisseur.

Vérifiez que le réseau est correctement configuré pour que la connexion TCP puisse être établie avec le fournisseur.

Demandez au fournisseur de vérifier s'il a correctement ajouté les adresses IP à la liste autorisée de l'instance Adobe Campaign.

Vérifiez les paramètres Compte externe. Demandez au fournisseur la valeur des champs.

Si la connexion est réussie mais instable, consultez la section Problème de connexion instable.

Si les problèmes de connexion sont difficiles à diagnostiquer, une capture réseau peut fournir des informations. Assurez-vous que la capture du réseau s'exécute simultanément pendant que le problème s'affiche pour pouvoir être analysé efficacement. Notez également l'heure exacte à laquelle le problème apparaît.

La connexion dure moins d'une heure. Les connexions d'émetteur Adobe Campaign Classic constituent une exception en raison du fonctionnement du MTA Adobe Campaign Classic.

Le fournisseur envoie UNBIND PDU.

enquire_link expire, soit du côté d'Adobe Campaign, soit du côté du fournisseur. Dans ce cas, ENQUIRE_LINK_RESP peut s'afficher avec un code d'erreur non nul.

Il y a beaucoup de BIND PDU.Il ne doit pas y en avoir plus de quelques-uns durant une journée, selon le nombre de connexions. L'apparition de plusieurs PDU BIND par heure doit attirer l'attention.

Les connexions instables sont rarement la cause première, il s'agit souvent du résultat d'un autre problème qui déclenche une déconnexion. Il est prioritaire d'identifier la cause première.

Activez les traces SMPP de verbose. Vous aurez besoin d'elles pour voir ce qui se passe au redémarrage de la connexion.

Si le fournisseur envoie BIND PDU, il se peut qu'il y ait un problème. Demandez à votre fournisseur pourquoi UNBING est envoyé.

La capture du réseau est parfois la seule façon de voir comment la connexion est fermée.

Si le fournisseur ferme les connexions en envoyant un paquet TCP FIN ou TCP RST packet, demandez à votre fournisseur de plus amples informations.

Si le fournisseur ferme la connexion après avoir envoyé une erreur de nettoyage telle que DELIVER_SM_RESP avec un code d'erreur, il doit réparer son connecteur sinon il empêchera la transmission d'autres types de messages et déclenchera le ralentissement du MTA. Ceci est particulièrement important en mode émetteur-récepteur où la fermeture de la connexion a un impact à la fois sur les MT et SR.

Vérifiez que la connexion est stable. Une connexion SMPP doit durer au moins une heure en continu, sauf pour les émetteurs sur Adobe Campaign Classic. Pour plus d'informations, consultez la section Problème de connexion instable.

Si le redémarrage du MTA entraîne l'envoi de MT à nouveau opérationnel pendant une petite période de temps, vous avez probablement un ralentissement dû à une connexion instable. Pour plus d'informations, consultez la section Problème de connexions instables.

Vérifiez que le broadlog est présent et que son statut est correct avec les dates correctes. Si ce n'est pas le cas, il peut s'agir d'un problème de préparation de diffusion ou de diffusion.

Vérifiez que le MTA traite réellement le message. Si ce n'est pas le cas, il est possible qu'il ne s'agisse pas d'un problème de SMS.

Vérifiez que le connecteur SMS est effectivement lié à l'équipement du fournisseur. Demandez au fournisseur de faire part de ses commentaires pour assurer que tous les systèmes communiquent correctement. Pour plus d'informations sur le processus de liaison, consulter BIND_TRANSMITTER et BIND_TRANSCEIVER PDU. Vous devrez peut-être activer les traces SMPP pour résoudre correctement les problèmes.

Lorsque les traces SMPP sont activées, vérifiez que SUBMIT_SM PDU contient les informations appropriées.

Vérifiez que le fournisseur répond par une valeur SUBMIT_SM_RESP PDU avec une valeur "OK" (code 0). Assurez-vous que le PDU arrive avec un délai raisonnable : tout ce qui dure plus d'une seconde doit faire l'objet d'une discussion avec le fournisseur (il arrive habituellement en moins de 100 ms).

Si toutes ces étapes fonctionnent, vous pouvez être certain que le problème est du côté fournisseur. Il devra effectuer la résolution des problèmes sur sa plateforme.

Si cela fonctionne mais que le débit n'est pas constant, essayez d'ajuster la fenêtre d'émission et d'abaisser le débit MT. Vous devrez travailler avec le fournisseur pour l'ajuster. Adobe Campaign peut envoyer des messages très rapidement de sorte que des problèmes de performances peuvent survenir sur l'équipement du fournisseur.

Si vous voyez des doublons envoyés exactement à 60 secondes d'intervalle, il s'agit probablement d'un problème du côté fournisseur. L'envoi de SUBMIT_SM_RESP n'est pas assez rapide.

Si vous voyez beaucoup de BIND/UNBIND, vous avez une connexion instable. Consultez la section Problème de connexion instable pour connaître les solutions avant de tenter de résoudre les problèmes de doublons de messages.

Vous aurez besoin de traces SMPP activées pour tous les types de résolution des problèmes SR.

Vérifiez que le DELIVER_SM PDU vient du fournisseur et qu'il est correctement formé.

Vérifiez que Adobe Campaign répond avec succès DELIVER_SM_RESP PDU dans les délais impartis. Sur Adobe Campaign Classic, cela garantit que le SR a été inséré dans la table providerMsgId pour le traitement différé par le processus SMS.

Vérifiez l'expression regex associée à l'extraction des identifiants et au traitement des erreurs dans le compte externe. Vous devrez peut-être les valider par rapport au contenu de DELIVER_SM PDU.

Vérifiez que les erreurs sont correctement configurées dans le tableau broadLogMsg.

Activez les traces SMPP pendant les tests. Si vous n'activez pas le protocole TLS, vous devez effectuer une capture réseau lors de la résolution des problèmes de MO pour vérifier que les PDU contiennent les informations correctes et sont correctement formatées.

Lors de la capture du trafic réseau ou de l'analyse des traces SMPP, veillez à capturer l'ensemble de la conversation avec le MO et sa réponse MT si une réponse est configurée.

Si le MO (DELIVER_SM PDU) n'apparaît pas dans les traces, le problème est du côté fournisseur. Il devra effectuer une résolution des problèmes sur sa plateforme.

Si le DELIVER_SM PDU apparaît, vérifiez qu'Adobe Campaign a confirmé sa réception avec un DELIVER_SM_RESP PDU indiquant un succès (code 0). Ce RESP garantit que toute la logique de traitement a été appliquée par Adobe Campaign (réponse automatique et liste autorisée / liste bloquée). Si ce n'est pas le cas, recherchez un message d'erreur dans les logs de processus SMS.

Si les réponses automatiques sont activées, vérifiez que SUBMIT_SM a été envoyé au fournisseur. Si ce n'est pas le cas, il est garanti qu'un message d'erreur se trouvera dans les logs de processus SMS.

Si le SUBMIT_SM MT PDU contenant la réponse se trouve dans les traces mais que le SMS ne parvient pas au téléphone portable, vous devez contacter le fournisseur pour obtenir de l'aide sur la résolution des problèmes.

Vérifiez que le format du numéro de téléphone est exactement le même dans la table de quarantaine et dans le log de diffusion. Si ce n'est pas le cas, consultez cette section si vous rencontrez des problèmes avec le préfixe plus du format de numéro de téléphone international.

Vérifiez les numéros courts. Des exclusions peuvent se produire si le numéro court du destinataire est identique à celui défini dans le compte externe ou s'il est vide (vide = tout numéro court). Si un seul numéro court est utilisé pour l'ensemble de l'instance Adobe Campaign, il est plus facile de laisser tous les champs de numéro court vides.

Activez les messages SMPP de verbose lorsque le problème apparaît. La plupart des problèmes de SMS sont impossibles à résoudre sans cela.

Si le problème est lié au trafic SMS, contactez d'abord le fournisseur. Sa plateforme est la mieux adaptée pour un diagnostic efficace des problèmes de trafic SMS en temps réel.

Incluez une description brève mais factuelle du problème.

Incluez une description du résultat attendu.

Incluez les commentaires du fournisseur.

Incluez les logs et/ou les captures réseau appropriés. Lorsque vous effectuez des captures, veillez à reproduire le problème pendant ces captures.

Si vous incluez des logs, des traces ou des captures, indiquez l'emplacement exact dans le fichier lorsque le problème apparaît.

Si vous référencez des messages, des PDU ou des logs, indiquez clairement la date et l'heure pour les rendre plus faciles à trouver.

Essayez de reproduire le problème sur un environnement de test. Si vous n'êtes pas sûr d'un paramètre, essayez-le sur l'environnement de test et vérifiez le résultat avec les traces SMPP. Il est généralement préférable de signaler les problèmes reproduits dans les environnements de test que de les signaler directement dans les environnements de production.

Incluez les modifications ou les ajustements apportés sur la plateforme. Incluez également toute modification que le fournisseur peut avoir apportée de son côté.

Problèmes de connexion, mais les messages en mode verbose n'affichent aucun BIND_RESP PDU.

Déconnexions inexpliquées sans message d'erreur, comportement habituel du connecteur lorsqu'il détecte une erreur de protocole de bas niveau.

Le fournisseur se plaint du processus de déconnexion / déconnexion.

Problèmes d'encodage dans les champs facultatifs TLV.

Il est possible qu'il y ait un trafic mixte entre les différentes connexions.

TLS activé : par définition, le trafic TLS est chiffré, et il ne peut pas être capturé.

Problèmes de performances : les logs contiennent toutes les informations nécessaires pour tracer les problèmes de performance.

Problèmes de minutage (retry timing, enquire_link période, limitation du débit, etc.)

Analyse et traitement SR : les logs explicites offrent beaucoup plus de contexte et une meilleure présentation.

Traitement MO (réponses automatiques, quarantaine).

Erreurs n'impliquant pas de trafic SMPP réel : préparation de la diffusion, problèmes d'API du Message Center, problèmes de workflow, etc.

Reçu sur mobile :
Le message a été correctement remis à l’appareil de l’utilisateur, avec une confirmation fournie à la fois par la diffusion Mobile Terminated (MT) et un rapport d’état (SR).

Envoyé :
Le message a été traité avec succès à l’étape Mobile Terminated (MT) , mais un rapport d’état (SR) confirmant la diffusion sur l’appareil mobile n’a pas encore été reçu.

Envoyé au fournisseur :
Le message a été envoyé au fournisseur à l'aide de SUBMIT_SM command, mais aucun accusé de réception SUBMIT_SM_RESP n'a été reçu de la part du fournisseur.

En attente : le message n’a pas encore été envoyé à l’agrégateur.

Pris en compte par Provider : le message a été envoyé à l’agrégateur et l’agrégateur a confirmé la réception.

Envoyé : l’agrégateur a confirmé que le message a bien été transmis au réseau mobile de l’utilisateur sans erreur immédiate.

Reçu sur mobile : l’appareil mobile de l’utilisateur a reçu un accusé de réception, ce qui a été vérifié par l’agrégateur.

Échec : le message a été envoyé à l’agrégateur, qui a tenté de le diffuser sur le périphérique mobile de l’utilisateur pendant une période définie (par exemple, plusieurs heures). La diffusion a finalement échoué en raison de problèmes de réseau, de l’indisponibilité du périphérique utilisateur ou pour d’autres raisons.