Le fonctionnement du DLR-URL de kannel

Résolu/Fermé

metboriano - Modifié par mamiemando le 14/09/2015 à 10:45
mamiemando Messages postés 33346 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 8 novembre 2024 - 17 sept. 2015 à 11:52

Bonjour,

Après avoir configuré kannel qui fonctionne correctement, j'ai décidé d'avoir les rapports de livraisons pour savoir les messages envoyés avec succès, échoués ou en attente.
Selon le userguide de kannel. Il faut passer par 03 étapes pour faire cela.

1- Demander à kannel de faire un stockage des DLR dans une base de données Mysql puis lui fournir les paramètres de connexion à la Mysql.

dlr-storage = mysql
group = mysql-connection
id = mydlr
host = localhost
username = root
password = xxxx
database = dlr
max-connections = 1

2- Créer une table et ses champs

group = dlr-db
id = mydlr
table = dlr
field-smsc = smsc
field-timestamp = ts
field-destination = destination
field-source = source
field-service = service
field-url = url
field-mask = mask
field-status = status
field-boxc-id = boxc

3- Fournir à l'url qui permet d'envoyer les SMS les paramètres dlr-mask et dlr-url=(url encodée qui sera appelée lorsque kannel va vouloir délivré les DLR.

http://192.168.10.11/

cet URL en clair est : http://192.168.10.11:13014/cgi-bin/sendsms?username=xxx&password=xxx&to=111111111&text=Mercredi+09+sept+14h45&dlr-mask=7&dlr-url=http://localhost/cgi/dlr/index.php?mydlr=123456&type=%d

le script relié à cet url est ci-dessous

<?php
$myId= $_GET['myId'];
$type = $_GET['type'];
$data= 'mysId = '.$myId.'; type = '.$type.'\n';
$File = fopen("dlr.txt", "a+");
fwrite($File,$data);
fclose($File);

Après cette configuration je m'attendais à ce que Kannel me renvoie dans ma base donnée dans le champ url l'url que je lui ai passé pour qu'il m'envoie le dlr du message spécifique sur le paramètre type=%d. Donc je devrais avoir type=1 ou 2 ou 4 ainsi de suite. Mais je n'ai rien. Il me renvoie tout le temps type=%d.

Aidez moi SVP les amis si possible me fournir le script qu'il faudrait. Merci d'avance

A voir également:

Le fonctionnement du DLR-URL de kannel
Lien url - Guide
Url masquée pour votre sécurité - Forum Programmation
Fonctionnement du protocole http - Guide
Iptv url invalide - Forum Box et Streaming vidéo
Atlas pro url serveur invalide ✓ - Forum Box et Streaming vidéo

2 réponses

Réponse 1 / 2

mamiemando Messages postés 33346 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 8 novembre 2024 7 803
Modifié par mamiemando le 14/09/2015 à 10:49

Bonjour

As-tu regardé dans les logs de kannel (sans doute dans /var/log/kannel) ? Une explication possible serait que kannel n'arrive pas à se connecter à ta base de données, auquel cas le fichier de log nous permettra de comprendre ce qui ne va pas.

En particulier, un serveur mysql n'écoute par défaut que le trafic local à la machine (ce qui correspond à l'interface

127.0.0.1

, comme stipulé dans le champ

bind-address

/etc/mysql/my.cnf

). En admettant que l'erreur vienne de là :

- Si le serveur mysql et kannel sont sur la même machine, alors kannel devrait contacter le serveur mysql via

127.0.0.1

.

- Sinon, il faut corriger le champ

bind-address

dans ce fichier avec l'une des IPs de la machine hébergeant mysql (voir

/sbin/ifconfig -a

), puis redémarrer le serveur mysql (

service mysql restart

).

Vérifie également que le username et le password mysql sont correct (par exemple via la commande

mysql -u username -p

)

Si ce n'est pas un problème de connexion à mysql, vérifie que ta base de donnée est fonctionnelle avec un client mysql, et que les tables contiennent des records corrects.

Bonne chance

metboriano
15 sept. 2015 à 18:55

Merci pour ton apport mamiemando, mais la connexion avec la base de donnée se passe correctement. j'ai des informations dans tous les champs de la table. Mais au niveau du champ url, il doit renseigner un paramètre type=''une valeur'' ce qui ne vient pas ou du moins ne change pas. j'ai toujours type=%d.

Mais entre temps j'ai commencé par avoir des informations de DLR dans mes fichiers log notamment dans access.log et smsbox.log.
Mais un problème reste posé. si je mets mon dlr-mask à 15 ou à 31, j'ai toujours la valeur 8 devant le type quelque soit ce qui se passe à la réception du message c'est à dire si le téléphone ne reçoit ou pas le message. Mais quand je mets dlr-mask à 3 ou 7 je ne recois pas du tout de DLR. j'ai huste ''sent'' dans les log

access.log
Receive DLR [SMSC:LG-E610] [SVC:mms] [ACT:] [BINF:] [FID:105] [META:] [from:13014] [to:96743603] [flags:-1:-1:-1:-1:8] [msg:4:ACK/] [udh:0:]

smsbox.log
2015-09-15 15:49:57 [6331] [9] DEBUG: Scheme: http://
2015-09-15 15:49:57 [6331] [9] DEBUG: Host: 192.168.10.11
2015-09-15 15:49:57 [6331] [9] DEBUG: Port: 80
2015-09-15 15:49:57 [6331] [9] DEBUG: Username: (null)
2015-09-15 15:49:57 [6331] [9] DEBUG: Password: (null)
2015-09-15 15:49:57 [6331] [9] DEBUG: Path: /dlr/index.php
2015-09-15 15:49:57 [6331] [9] DEBUG: Query: myID=lg&type=8

2015-09-15 15:49:57 [6331] [9] DEBUG: Fragment: (null)
2015-09-15 15:49:57 [6331] [9] DEBUG: Connecting nonblocking to <192.168.10.11>
2015-09-15 15:49:57 [6331] [9] DEBUG: HTTP: Opening connection to `192.168.10.11:80' (fd=28).
2015-09-15 15:49:57 [6331] [9] DEBUG: Socket connecting
2015-09-15 15:49:57 [6331] [8] DEBUG: Get info about connecting socket
2015-09-15 15:49:57 [6331] [8] DEBUG: HTTP: Sending request:
2015-09-15 15:49:57 [6331] [8] DEBUG: Octet string at 0x7fc7100008e0:
2015-09-15 15:49:57 [6331] [8] DEBUG: len: 121
2015-09-15 15:49:57 [6331] [8] DEBUG: size: 1024
2015-09-15 15:49:57 [6331] [8] DEBUG: immutable: 0
2015-09-15 15:49:57 [6331] [8] DEBUG: data: 47 45 54 20 2f 64 6c 72 2f 69 6e 64 65 78 2e 70 GET /dlr/index.p
2015-09-15 15:49:57 [6331] [8] DEBUG: data: 68 70 3f 6d 79 49 44 3d 6c 67 26 74 79 70 65 3d hp?myID=lg&type=
2015-09-15 15:49:57 [6331] [8] DEBUG: data: 38 0d 0a 0d 0a 20 48 54 54 50 2f 31 2e 31 0d 0a 8.... HTTP/1.1..
2015-09-15 15:49:57 [6331] [8] DEBUG: data: 48 6f 73 74 3a 20 31 39 32 2e 31 36 38 2e 31 30 Host: 192.168.10
2015-09-15 15:49:57 [6331] [8] DEBUG: data: 2e 31 31 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a .11..Connection:
2015-09-15 15:49:57 [6331] [8] DEBUG: data: 20 6b 65 65 70 2d 61 6c 69 76 65 0d 0a 55 73 65 keep-alive..Use
2015-09-15 15:49:57 [6331] [8] DEBUG: data: 72 2d 41 67 65 6e 74 3a 20 4b 61 6e 6e 65 6c 2f r-Agent: Kannel/
2015-09-15 15:49:57 [6331] [8] DEBUG: data: 31 2e 35 2e 30 0d 0a 0d 0a 1.5.0....
2015-09-15 15:49:57 [6331] [8] DEBUG: Octet string dump ends.
2015-09-15 15:49:57 [6331] [8] DEBUG: Failed while reading status
2015-09-15 15:49:57 [6331] [8] ERROR: Couldn't fetch <http://192.168.10.11/dlr/index.php?myID=lg&type=8

J'espère que mon chers mamiemando pourra toujours m'aider. Pourquoi ce couldn't fetch dlr-url alors que mon serveur web fonctionne correctement et que l'adresse est bien écrite?

Réponse 2 / 2

mamiemando Messages postés 33346 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 8 novembre 2024 7 803
16 sept. 2015 à 10:13

Je ne sais pas si je peux t'aider vu que je ne comprends pas ce que c'est sensé faire :-)
Voici ce que je peux te dire : en PHP, %d est le format utilisé pour écrire un entier :

<?php
printf("%d", my_int);
?>

J'imagine donc que si ta valeur est un entier, le fait que type soit égal à %d est légitime. Ce qui est moins normal c'est ceci :

2015-09-15 15:49:57 [6331] [8] DEBUG: Failed while reading status 
2015-09-15 15:49:57 [6331] [8] ERROR: Couldn't fetch

C'est ça que je chercherais sur google. On dirait que kannel s'attend à trouver un status, qui est probablement l'entier que tu aimerais récupérer (enfin si j'ai bien compris).

Bonne chance

metboriano
16 sept. 2015 à 10:53

Ok je t'explique brièvement. Après avois configuré kannel pour l'envoie de messages, j'aimerais configuré le DLR (Delivery Report) de kannel pour connaître les messages arrivés a destination, échoués ou en attentes.
Pour faire donc cela, la documentation de kannel dit qu'il faut ajouter deux paramètres à l'url qui permettait d'envoyer les messages. il s'agit des paramètres dlr-mask et dlr-url
le dlr-mask permet de demander les types de rapport qu'on veut et le dlr-url est l'url qui indexe le lien qu'il va appeler pour livrer le rapport. ce lien doit avoir un paramètre type à la fin comme ceci
dlr-url=http://localhost/dlr.php?&type=%d (à encoder avant de la passer à l'url d'envoie de message)
si kannel envoie un retour:
type=1 cela veut dire que le destinataire a reçu le message
type=2 message échoué
type=4 message en attente
Auparavant il faut aussi mettre le dlr-mask=7. le 7 est obtenu en faisant la somme des trois types de rapport qu'on veut c'est à dire 1+2+4. On peut avoir dlr-mask=15 ou 31 ou 63 si on veut avoir d'autres types de rapport en plus.
Donc pour avoir les rapports de livraison, on doit avoir une url d'envoie de message qui ressemble à ceci
http://192.168.10.11/...

Actuellement j'ai deux problèmes quand je met mon dlr-mask=7 je ne reçois aucun type de rapport de livraison. Mais quand je le mets à 15 ou 31 j'ai toujours type=8 avec
une erreur couldn't fetched dlr-url et un DEBUG:Failed while reading status.

J'apprécierais vraiment la personne qui pourrait m'aider à résoudre ces soucis.
Mamiemando je suis ta piste déjà sur le DEBUG: Failed while reading status. mais j'aimerais que tu m'aides sur l'erreur couldn't fetched dlr-url. Merci d'avance

mamiemando Messages postés 33346 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 8 novembre 2024 7 803
16 sept. 2015 à 11:24

Cette erreur signifie qu'il ne parvient pas à extraire dlr-url de l'url que kannel reçoit. Pour moi l'erreur vient du fait que ton url est mal encodée, mais ça je pense que tu l'avais déjà compris.

As-tu un lien vers la documentation de kannel qui explique ce que tu dis ?

Un exemple qui t'aidera peut-être :
http://www.kannel.org/pipermail/users/2009-October/008957.html

Bonne chance

metboriano > mamiemando Messages postés 33346 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 8 novembre 2024
Modifié par metboriano le 16/09/2015 à 19:22

J'ai vu le problème qui était à la base de l'erreur couldn't fetched dlr-url. c'était un problème d'accès au serveur web. j'ai mis mon index.php sur un autre serveur web et je n'ai plus cette erreur. je conclus que c'était une restriction sur mon serveur que j'utilisais.
Mais un problème reste d'actualité. c'est celui de type=8 que je reçois tout le temps une fois que je demande un rapport pouvant m'envoyer un rapport de type 8. selon la documentation de kannel, type=8 siginfie que le smsc de l'opérateur accepté de délivrer mon message. mais quand je met un dlr-mask ne pouvant pas me renvoyer un type=8, je ne reçois plus rien. donc je ne peux pas savoir si le message a été effectivement reçu ou pas. c'est mon problème xa.

Mamiemando tu as des idées? je commence par penser à un blocage des autres types de rapport par mon opérateur.
je voudrais aussi avoir ton adresse électronique mamiemando. La mienne c'est ***@***

mamiemando Messages postés 33346 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 8 novembre 2024 7 803
16 sept. 2015 à 20:38

Tu as regardé le fil de discussion cité dans mon message précédent ? Car apparemment tu n'es pas le seul à systématiquement type=8.

Bonne chance

metboriano > mamiemando Messages postés 33346 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 8 novembre 2024
Modifié par metboriano le 17/09/2015 à 09:52

Oui bien sur que je l'ai regardé et dans ce fil de discussion il n'y a pas la solution ou même des idées qui pourraient m'aider. Je viens quand même d'avoir une information même si elle n'est pas encore certaine. Il parait que c'est mon opérateur qui a mis des restrictions sur son SMSC pour qu'il ne nous donne pas le retour des MT (Messages terminating) mais seulement des MO (Messages Originating).
En effet il y a deux séquences dans l'envoie d'un message .
La première séquence est entre l'origine du message et le SMSC. Les messages sur ce tronçon sont qualifiés de MO
La deuxième séquence est entre le SMSC et la destination ou terminaison d'où le nom de MT aux messages sur ce tronçon.
en réalité pour avoir accès aux rapports de type envoyé (1), échoué (2), en attente (4), il faudrait que le SMSC de l'opérateur nous le permette puisque c'est déjà sur leur réseau et c'est seulement eux qui ont le contrôle. On comprend donc aisément pourquoi on a tout le temps le type 8 qui veut dire que le message est soumis au SMSC. Mais on a pas de retour sur les actions (envoyé, échoué, en attente) que le SMSC a effectué.
Merci à tous et spécialement à Mamiemando

Discussions similaires

Sécurité de l'URL

Durée de Fonctionnement cpu

La nouvelle messagerie du Boncoin....

comment lire un message masqué????

url bloqué par avast