Comment suivre un SMS SMPP

Ozeki SMS Gateway fournit plusieurs journaux pour découvrir ce qui est arrivé à un certain SMS qui est passé par le système. Si vous fournissez un service SMPP, parfois vous recevrez une demande de votre client concernant un SMS. Ce guide vous donne des informations sur la façon de découvrir ce qui est arrivé à un SMS unique.

Trouver le SMS envoyé par le client

Pour trouver le SMS du client, ouvrez d'abord le compte utilisateur SMPP du client. Ensuite, sélectionnez l'onglet des journaux d'événements, afin de voir la communication entre votre système et celui de votre client. Si vous ne voyez pas le message dans les journaux, vous pouvez ouvrir le fichier journal avec le Bloc-notes. Le fichier journal se trouve à :

C:\Program Files\Ozeki\Data\Logs\Connections\SMPP_user_smp1_localhost.txt

Figure 1 - Ouvrir le compte utilisateur SMPP

Figure 2 - Sélectionner l'onglet des événements

Figure 3 - Trouver l'entrée de journal correspondant au message.

Journal Submit SM

Cette entrée de journal contient généralement 5 lignes de code. La première ligne est la demande de soumission envoyée par le système du client, puis vous voyez notre réponse à cette demande, puis nous enregistrons les événements de routage et de livraison correspondant au message.

INFO smp1: 192.168.112.150:60724 -> 0000003700000004000000000000001C00010130303030303030000101313233
3435363700000001000001000000085465737420736D73
INFO smp1: Message accepted with SMPP ID: 6682891798
INFO smp1: 192.168.112.150:60724 <- 0000001B80000004000000000000001C3636383238393137393800
INFO smp1: Received: +0000000->+1234567 'Test sms'
INFO smp1: Sending. Route: defout_sms,Any_SMS_Connection@localhost +0000000 -> +1234567 'Test sms' Task ID: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112
INFO smp1: Submit accepted at HTTP_Server_1@localhost. Submit reference: 701dbf6a-30a4-4bd9-8409-848fd68ce1a3 +0000000 -> +1234567 'Test sms' Task ID: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112

Journal Submit SM / Demande de soumission

La première ligne du journal ci-dessus est les données que le système a reçues de votre client. Votre client a soumis son message SMS en utilisant la demande PDU SMPP SUBMIT_SM. Voici les données d'octets représentées en format HEX :

INFO smp1: 192.168.112.150:60724 -> 0000003700000004000000000000001C000101303030303030300001
013132333435363700000001000001000000085465737420736D73

Journal Submit SM / Réponse de soumission

Les trois lignes suivantes dans le journal sont liées à la réponse. Votre système attribue un ID SMPP au message. Cet ID est 6682891798 dans notre cas. Cet ID sera utilisé pour référencer ce message lorsqu'un rapport de livraison arrivera. Ensuite, il envoie une réponse à votre client sous la forme d'un PDU SUBMIT_SM_RESP. Ce PDU contient l'ID attribué. Votre client peut stocker cet ID pour référence ultérieure.

INFO smp1: Message accepted with SMPP ID: 6682891798
INFO smp1: 192.168.112.150:60724 <- 0000001B80000004000000000000001C3636383238393137393800
INFO smp1: Received: +0000000->+1234567 'Test sms'

Journal Submit SM / Journal de routage

Les deux lignes suivantes sont liées au routage du message. Le système vous donne des informations sur quelle route a été utilisée pour transférer le message vers le réseau mobile. Après la fin du routage, le système enregistrera également ce qui est arrivé au message à la connexion de destination. Dans notre cas, vous verrez que la route default_sms a été utilisée, et le message a été envoyé au réseau mobile via la connexion HTTP_Server_1@localhost.

INFO smp1: Sending. Route: defout_sms,Any_SMS_Connection@localhost +0000000 -> +1234567 'Test sms' Task ID: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112
INFO smp1: Submit accepted at HTTP_Server_1@localhost. Submit reference: 701dbf6a-30a4-4bd9-8409-848fd68ce1a3 +0000000 -> +1234567 'Test sms' Task ID: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112

Si vous voulez des informations plus détaillées sur ce qui est arrivé au message, vous pouvez ouvrir le journal de la connexion du réseau mobile et voir les événements de livraison correspondant au message dans ce fichier journal. Dans ce cas, vous ouvririez le journal de la connexion HTTP_Server_1@localhost.

Trouver le rapport de livraison SMPP

Après quelques minutes, lorsque le réseau mobile livre le SMS au téléphone du destinataire, un rapport de livraison sera renvoyé à votre système. Votre système transmettra ce rapport de livraison au client en utilisant une demande SMPP_DELIVER_SM. Ce rapport de livraison contiendra l'ID SMPP original du message. Dans notre cas, ce sera : 6682891798. Pour trouver le journal de rapport de livraison correspondant dans votre fichier journal, recherchez cet ID.

Figure 4 - Journal du rapport de livraison

Journal du rapport de livraison

Le journal de livraison correspondant dans ce cas contient 5 entrées de journal. La première entrée de journal imprime des informations pour vous qui indiquent que le message a été livré. La ligne suivante vous donne des informations sur quelle route entrante a été utilisée pour transférer le rapport de livraison entrant vers le compte de cet utilisateur. Les deux lignes suivantes contiennent la communication entre votre système et celui du client. Vous verrez que votre système envoie le PDU SMPP Deliver_SM au client, et le client renvoie une réponse pour accuser réception de cette demande.

2020-07-30 10:05:36.674 INFO smp1: Delivered. 'Delivered; To: +1234567; At: 2020-07-30 10:05:36; Ref: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112; Successful delivery at 30/07/2020 10:05:36' +0000000 -> +1234567 'Test sms' Task ID: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112
2020-07-30 10:05:36.674 INFO smp1: Message was successfully processed. No further jobs are necessary. Removing it from the Sent queue. Route: smp1@localhost->HTTP_Server_1@localhost (Move). Message: +0000000->+1234567 'Test sms' Task ID: 1326c0f0-e8fd-4ddd-97d2-68ff9401b112
2020-07-30 10:05:36.674 INFO smp1: 192.168.112.150:60724 <- 000000A6000000050000000000000001000101303030303030300001013132333435363700040000000000000 3007769643A36363832383931373938207375623A30303120646C7672643A303031207375626D697420646174 653A3230303733303130303020646F6E6520646174653A3230303733303130303520737461743A44454C49565 244206572723A30303020746578743A44656C697665727920737563636573732E
2020-07-30 10:05:36.674 INFO smp1: 192.168.112.150:60724 -> 0000001180000005000000000000000100
2020-07-30 10:05:36.674 INFO smp1: Delivery report sent. UD: id:6682891798 sub:001 dlvrd:001 submit date:2007301000 done date:2007301005 stat:DELIVRD err:000 text:Delivery success.

FAQ

Si j'envoie un SMS depuis un modem GSM, le protocole GSM permet un nombre maximum de 256 ID de rappel pour les rapports de livraison. Comment distinguez-vous les rapports de livraison qui ont le même ID ?

La correspondance traditionnelle des rapports de livraison SMS repose sur un ID de référence retourné par le réseau mobile lors de la soumission du message. Cet ID, généralement un nombre entre 0 et 255, sert de point de référence pour associer les rapports de livraison à leurs messages correspondants. Cependant, cette approche a une limitation : avec plus de 256 messages envoyés, des collisions d'ID peuvent se produire, entraînant des mises à jour inexactes de l'état de livraison.

Le logiciel SMS Ozeki relève ce défi en utilisant un mécanisme de correspondance plus robuste. Il combine le numéro de téléphone du destinataire avec l'ID de référence retourné. Cela crée un "ID de rappel" unique qui réduit considérablement le risque de collisions.

Au lieu de s'appuyer uniquement sur l'ID "0" (potentiellement attribué à plusieurs messages), Ozeki utilise un ID de rappel comme "+36201234567:0." Cet identifiant combiné permet une cartographie plus précise des rapports de livraison aux messages originaux envoyés au numéro de téléphone spécifique du destinataire "+36201234567" avec l'ID "0." En conséquence, le logiciel peut mettre à jour en toute confiance le statut du message en "livréàl'appareil."

Les connexions SMS IP offrent un avantage supplémentaire. Elles utilisent des ID de rappel beaucoup plus longs et uniques, souvent sous la forme d'identifiants globalement uniques (GUID). Cela élimine totalement le risque de collisions, garantissant une correspondance encore plus fiable des rapports de livraison.

More information