Ce document décrit le protocole SMS et la manière dont les paramètres du compte externe affectent le protocole ou le comportement du connecteur.

Dans ce document, toutes les références aux détails du protocole, noms de champs et valeurs se réfèrent à la spécification SMPP 3.4.

Ce document s’applique à Adobe Campaign Standard et à Adobe Campaign Classic (SMPP générique étendu), sauf indication contraire. Si une option est également disponible sur l’ancien connecteur v6 (SMPP générique), il est indiqué comment il se comporte.

Lorsque ce document mentionne Adobe Campaign Classic, cela concerne également Campaign v6 et v7 puisque ces versions fonctionnent de la même manière pour les SMS.

Description du protocole SMPP

Adobe Campaign Classic et Standard prennent en charge la version 3.4 du protocole SMPP. Il s’agit d’un protocole très répandu qui permet d’envoyer des SMS à un fournisseur (SMSC) et de recevoir des SMS ainsi que des accusés de réception.

Trois types de SMS

Lors de l’envoi de masse de SMS via un fournisseur SMS, vous rencontrerez trois types de SMS différents :

  • SMS MT (Mobile Terminated) : SMS envoyé par Campaign vers les téléphones portables.
  • SMS MO (Mobile Originated) : SMS envoyé par un téléphone portable à Campaign.
  • SMS SR (Status Report, rapport d’état) ou DR ou DLR (Delivery Receipt, accusé de réception) : un accusé de réception envoyé par téléphone portable indique que le SMS a été reçu correctement. Campaign peut également recevoir un SR (rapport d’état) indiquant que le message n’a pas pu être diffusé, souvent accompagné d’une description de l’erreur.

Il faut faire la distinction entre les accusés de réception et le SR : un SR est un type de SMS envoyé via le réseau, tandis qu’un accusé de réception est la confirmation du succès d’un transfert.

Les accusés de réception et les SR peuvent déclencher des erreurs, la distinction entre les deux aide à résoudre les problèmes.

Informations fournies par un SMS

SMS contient d’autres informations en plus du texte. Liste de ce que vous pouvez rencontrer dans un SMS :

  • Le texte, limité à 140 octets, c’est-à-dire entre 70 et 160 caractères en fonction du codage. Consulter le codage de texte SMS ci-dessous pour avoir des informations détaillées et connaître les restrictions.
  • L’adresse du destinataire, parfois appelée ADC ou MSISDN. Le nombre de périphériques mobiles qui recevront le SMS.
  • L’adresse de l’expéditeur, qui peut être appelée oADC ou ID de l’expéditeur. Il peut s’agir d’un numéro de téléphone (dans l’utilisation quotidienne), d’un code court (lorsqu’il est envoyé via un fournisseur) ou d’un nom (il s’agit d’une fonctionnalité facultative, dans ce cas vous ne pouvez pas répondre au SMS).
  • Un indicateur précisant si le message est un message Flash. Un message Flash est une fenêtre contextuelle qui n’est pas stockée dans la mémoire.
  • Un indicateur précisant si un SR est attendu ou non.
  • Une date de validité, après laquelle aucun équipement réseau n’est autorisé à réessayer (pas toujours présent ou respecté).
  • Un champ data_coding, qui indique le codage du texte.

L’aspect réseau du protocole SMPP

Le protocole SMPP établit des connexions TCP permanentes depuis Campaign jusqu’au SMSC. Les connexions TCP sont toujours lancées par Campaign, même pour recevoir des messages.

SMPP ouvre 1 ou 2 connexions TCP, selon le mode. Toutes les connexions sont toujours lancées par Campaign.

Le protocole SMPP peut fonctionner dans deux modes :

  • Émetteur + récepteur (souvent abrégé par TX+RX) : deux connexions TCP distinctes sont utilisées pour l’émission et la réception de messages.
  • Émetteur-récepteur (abrégé TRX) : une connexion TCP est utilisée pour émettre et recevoir des messages.

Remarque :

Adobe Campaign Classic (à la fois l’ancien connecteur SMPP et le connecteur SMPP étendu) et les versions antérieures de Campaign ne prennent en charge que le mode TX+RX distincts. Cette limitation est due à l’architecture technique.

La description du protocole SMPP s’applique à toutes les versions de Campaign car il s’agit d’un protocole standard.

Les unités de transmission SMPP (« paquets ») sont appelés PDU : un PDU contient une commande, un état, un numéro de séquence et des données.

Chaque PDU doit être confirmé par un SMPP RESP PDU (réponse synchrone). Les demandes peuvent être acheminées à la suite : l’expéditeur peut envoyer de nombreuses commandes sans attendre de réponse, le nombre de demandes pouvant être envoyées à tout moment est appelé fenêtre. PDU RESP peut arriver dans tout ordre, sans rapport avec l’ordre du PDU initiateur correspondant.

En mode émetteur et récepteur distincts, la connexion utilisée dépend du type de message transmis. La connexion de l’émetteur est utilisée pour MT et la connexion du récepteur est utilisée pour MO et SR. Les demandes et les réponses pour chaque type de message sont envoyées via la même connexion TCP.

Par exemple, lors de l’envoi d’un MT, la connexion de l’émetteur est utilisée et RESP qui accuse réception du MT est également envoyé via le canal de l’émetteur. Lorsque vous recevez un MO (ou un SR), la connexion du récepteur est utilisée pour recevoir le MO et envoyer RESP qui accuse réception du MO.

smpp_transmitterreceiver

Dans Adobe Campaign Classic, pour associer SR au MT correspondant, un ID est renvoyé par le SMSC avec les étapes SUBMIT_SM_RESP DELIVER_SM. L’identifiant est stocké dans le champ providerId du tableau nms::providerMsgId et est associé à broadLogId et deliveryId. Cette opération est effectuée par le processus SMS lors de l’écriture dans la base de données.

Dans Adobe Campaign Standard, le rapprochement MT↔SR est natif du MTA, de sorte qu’il n’existe pas de processus SMS dédié.

Aspects liés à la sécurité

Le seul mécanisme d’authentification généralisé est le champ connexion/mot de passe transmis pendant la phase de liaison.

Le protocole n’est pas chiffré. IP sur liste blanche, VPN et IPsec sont les mesures de sécurité les plus utilisées. Cela est généralement géré par le service d’hébergement ou les composants réseau externes.

ACS prend désormais en charge le SMPP plutôt que le TLS, bien que sa mise en œuvre ne soit pas entièrement conforme au TLS en raison des limites de la structure sous-jacente. Avant de déployer le TLS, une phase de test et un test de stress de grande envergure doivent être effectués par ACS et le fournisseur.

 

Informations dans chaque type de PDU

Chaque type de PDU possède des champs distincts qui contiennent différentes informations. Ces PDU sont détaillés dans la spécification SMPP 3.4. Ce document donne un aperçu des champs utiles de la plupart des PDU utilisés.

Chaque section ci-dessous décrit à la fois le PDU et la réponse synchrone correspondante (*_RESP PDU). Tous les PDU doivent être confirmés par un RESP correspondant, il s’agit d’une partie obligatoire de la spécification.

Les PDU peuvent comporter des champs facultatifs. Seuls les champs les plus courants sont décrits ici. Consulter la spécification SMPP et la documentation du fournisseur pour obtenir des informations plus détaillées.

BIND_TRANSMITTER/BIND_RECEIVER/BIND_TRANSCEIVER

Ce PDU est utilisé pour établir une connexion avec le SMSC. Les modes Émetteur, Récepteur et Émetteur-récepteur ne changent que le type de SMS qui peut être transféré par le biais de cette connexion, en particulier :

Mode Types de SMS permis
Émetteur MT
Récepteur MO + ST
Émetteur-récepteur MT + MO + SR

Champs significatifs d’un PDU BIND_* :

  • system_id : ID utilisé pour l’authentification. Défini dans le compte externe, disponible dans toutes les versions.
  • Mot de passe : mot de passe utilisé pour l’authentification. Défini dans le compte externe, disponible dans toutes les versions.
  • system_type : doit être défini sur une valeur spécifique pour certains fournisseurs. Défini dans le compte externe, disponible dans toutes les versions. Distinction courante entre différents types de contrats, canaux, pays, etc.
  • addr_ton et addr_npi : sont requis par certains fournisseurs. Défini par les paramètres « Bind TON » et « Bind NPI » dans le compte externe (Adobe Campaign Classic SMPP étendu et Adobe Campaign Standard uniquement).
  • address_range : requis par certains fournisseurs. Sa signification peut varier. La plupart du temps, il s’agit d’une liste de codes courts autorisés pour cette connexion. Définie dans le compte externe (Adobe Campaign Classic SMPP étendu et Adobe Campaign Standard uniquement).

BIND_*_RESP n’a pas de champ spécifique, il confirme si la connexion a réussi ou non.

UNBIND

Ce PDU doit être envoyé par le système avant la déconnexion. Il doit attendre le PDU UNBIND_RESP correspondant avant de fermer la connexion.

Le SMSC conforme ne doit pas fermer la connexion, la connexion TCP est gérée par le connecteur de Campaign.

SUBMIT_SM

Ce PDU envoie un MT au SMSC. La réponse du PDU donne l’identifiant du MT.

Champs significatifs dans le PDU SUBMIT_SM :

  • service_type : requis par certains fournisseurs, sa signification peut varier. Défini dans les propriétés de diffusion (toutes versions).
  • source_addr_ton et source_addr_npi : indiquent le type d’adresse source transmis. La signification de ces champs est normalisée, mais puisque certains fournisseurs l’utilisent différemment, vous devez demander au fournisseur quelle est la valeur adéquate. Défini dans le compte externe (toutes versions).
  • source_addr : l’adresse source/oADC du MT sera affichée sur le téléphone portable. Défini dans le compte externe et la diffusion, la valeur de la diffusion est prioritaire par rapport à la valeur du compte externe (toutes versions).
  • dest_addr_ton et dest_addr_npi : indiquent le type d’adresse de destination transmis (par exemple format local ou international). La signification de ces champs est normalisée, mais puisque certains fournisseurs l’utilisent différemment, vous devez demander au fournisseur quelle est la valeur adéquate. Défini dans le compte externe (toutes versions).
  • destination_addr : l’adresse du destinataire (son numéro de téléphone ou MSISDN).
  • esm_class : utilisé pour indiquer si UDH est utilisé ou non dans le champ de texte. Activé automatiquement par le connecteur pour les SMS fractionnés si le mode message_payload n’est pas utilisé. Disponible dans toutes les versions.
  • priority_flag : priorité du présent message par rapport aux autres. C’est lié à la priorité de la diffusion elle-même dans Campaign (toutes versions).
  • validity_period : horodatage après lequel aucun nouvel essai ne doit être tenté. Défini dans la diffusion de Campaign (toutes versions).
  • registered_delivery : indique si un SR est requis ou non. Campaign définit toujours cet indicateur, sauf pour les réponses automatiques. Pour les messages en plusieurs parties, l’indicateur n’est défini que pour la première partie. Toutes les versions ont le même comportement.
  • data_coding : indique le codage utilisé dans le champ de texte. Consulter la section encodage du texte SMS dans la présente documentation pour plus d’informations (différente selon la version).
  • short_message : le texte du message. Si UDH est utilisé, l’en-tête est également contenu.

Campaign prend en charge les champs facultatifs suivants :

  • dest_addr_subunit : utilisé pour spécifier la cible du SMS : carte flash, périphérique mobile ou SIM. Défini dans les propriétés de diffusion (toutes versions).
  • message_payload : lorsque cette option est activée dans le compte externe, les messages longs seront envoyés dans un seul PDU et le texte sera transmis dans ce champ plutôt que dans le champ short_message (Adobe Campaign Classic SMPP étendu et Adobe Campaign Standard uniquement).

SUBMIT_SM_RESP

Ce PDU contient l’identifiant du MT. C’est pratique pour le faire correspondre avec les SR entrants.

Attention :

De nombreux fournisseurs transmettent l’identifiant du MT au format hexadécimal. Veiller à définir correctement le paramètre « format d’ID de l’accusé de réception du MT » dans le compte externe.

 

DELIVER_SM

Ce PDU est envoyé par le SMSC à Campaign. Il contient soit un MO, soit un SR.

La plupart des champs ont la même signification que leur équivalent SUBMIT_SM. Liste des champs utiles :

  • source_addr : l’adresse source du MO et du SR. Il s’agit généralement d’un numéro de téléphone.
  • destination_addr : le code court qui a reçu le MO ou le SR.
  • esm_class : utilisé pour indiquer si le PDU est un MO ou un SR.
  • short_message : le texte du message. Pour le SR, ceci contient les données décrites dans l’Annexe B de la spécification du protocole SMPP. Consulter la gestion des erreurs SMPP : Annexe B pour plus de détails.

Campaign peut lire les identifiants de message dans le champ facultatif receipted_message_id avec quelques réglages de configuration (Adobe Campaign Classic SMPP étendu et Adobe Campaign Standard uniquement).

DELIVER_SM_RESP

Ce PDU ne transfère aucune information significative, à part le fait d’accuser réception ou non du SR et du MO.

Ce PDU est uniquement utilisé pour vérifier que la connexion perdure. Sa fréquence doit être définie en fonction des besoins du fournisseur.

La valeur par défaut de 60 secondes doit correspondre à la plupart des configurations définies dans le compte externe dans le backport et dans le connecteur d’Adobe Campaign Standard. L’ancien connector v6 est configuré dans le serverConf et la valeur par défaut est de 25 secondes.

ENQUIRE_LINK_RESP

Ce PDU vérifie que la connexion perdure.

Paramètres du compte externe SMPP

Chaque mise en œuvre du protocole SMPP comporte de nombreuses variantes. Pour améliorer la compatibilité et l’adaptabilité, de nombreux paramètres sont disponibles pour modifier le comportement du connecteur SMPP. Cette section décrit chaque paramètre et ses effets sur le connecteur.

 

Paramètres de connexion

Mode de connexion SMPP

Définir la connexion en mode émetteur + récepteur ou en mode émetteur et récepteur distincts. Lorsque vous passez en mode émetteur et récepteur distincts, les paramètres dans la section Mode de connexion SMPP s’appliquent à l’émetteur et les paramètres dans la section Paramètres de connexion du récepteur s’appliquent à la connexion du récepteur (uniquement si vous avez coché la case Utiliser des paramètres différents pour le récepteur).

S’applique uniquement à Adobe Campaign Standard. Les deux connecteurs d’Adobe Campaign Classic ne prennent en charge que les émetteurs et récepteurs distincts en raison de limites d’architecture.

Nom de l’implémentation du SMSC

Définit le nom de l’implémentation SMSC. Il doit être défini sur le nom de votre fournisseur. Contacter l’administrateur ou l’équipe de délivrabilité pour savoir comment intégrer ce champ. Le rôle de ce champ est décrit dans la section gestion des erreurs SMPP ci-dessous.

S’applique à Adobe Campaign Classic SMPP étendu et à Adobe Campaign Standard.

Serveur

Nom DNS ou adresse IP du serveur auquel se connecter.

Dans l’ancien connecteur v6, vous pouvez ajouter une liste séparée par des virgules d’IP pour vous connecter aux serveurs multiples en parallèle.

Adobe Campaign Standard et backport v6 n’autorisent qu’une seule adresse. Cela peut être modifié ultérieurement.

Port

Le port TCP auquel se connecter.

Applicable à toutes les versions.

Compte

L’identifiant de la connexion. Transmis dans le champ system_id du PDU BIND.

Applicable à toutes les versions.

Mot de passe

Mot de passe de la connexion SMPP. Transmis dans le champ mot de passe du PDU BIND.

Applicable à toutes les versions.

Type de système

Valeur transmise par le champ system_type du PDU BIND. Certains fournisseurs ont besoin ici d’une valeur spécifique.

Applicable à toutes les versions.

Connexions simultanées

Nombre de connexions par thread SMS et par processus MTA.

Attention :

Le connecteur d’Adobe Campaign Classic SMPP Générique ne contrôle pas le nombre de connexions simultanées. Les connexions sont créées selon de nombreux paramètres hors de contrôle.

 

Le nombre de processus MTA est déterminé par le déploiement de TechOps (en règle générale, il y a 2 MTA et 1 thread). Le nombre de threads peut être modifié dans le fichier config-instance.xml.

Le connecteur d’Adobe Campaign Classic SMPP étendu peut contrôler le nombre de connexions par enfant MTA. Pour contrôler la limite globale des connexions, vous devez limiter le nombre de processus enfants MTA, ce qui signifie souvent avoir une plate-forme mid-sourcing dédiée aux SMS.

Formule de connexions totales pour Adobe Campaign Standard :

  • Nombre total de connexions = connexions simultanées * nombre de threads x nombre de MTA

Nombre total de connexions pour le connecteur d’Adobe Campaign Classic SMPP étendu :

  • Nombre total de connexions = connexions simultanées * nombre de processus enfants MTA x nombre de MTA

Dans Adobe Campaign Classic, le processus SMS ouvre également les connexions. Il traite un seul processus ou thread. Dans la mesure où vous pouvez disposer d’un seul processus SMS par instance, cela signifie que le paramètre Connexions simultanées est directement le nombre de connexions ouvertes par le processus SMS.

Remarque :

Si vous configurez des réponses automatiques, le processus SMS ouvre les paires émetteur/récepteur, augmentant ainsi le nombre de connexions de l’émetteur. Mais si vous n’avez pas configuré de réponse automatique, il n’ouvre que les connexions du récepteur.

 

Activer le protocole TLS au lieu de SMPP

Utiliser TLS pour vous connecter au fournisseur. La connexion sera chiffrée.

Uniquement disponible dans Adobe Campaign Standard depuis 18.6.

Activation des commentaires SMPP détaillés dans le fichier journal

Ce paramètre sauvegarde tout le trafic SMPP dans les fichiers journaux. Il est souvent nécessaire de régler les paramètres lors de la configuration initiale. Ce contenu doit être activé en cas de dépannage du connecteur et comparé au trafic affiché par le fournisseur.

Dans Adobe Campaign Standard, la sortie de journal est disponible dans Splunk. Dans Adobe Campaign Classic, la sortie de journal se trouve dans le journal MTA pour le trafic lié à MT et dans le journal SMS pour le trafic lié à MO et SR.

Paramètre de connexion du récepteur

Cette section est uniquement visible dans le mode émetteur + récepteur (voir ci-dessus). Disponible uniquement dans le connecteur d’Adobe Campaign Classic SMPP étendu et le connecteur d’Adobe Campaign Standard.

Utiliser différents paramètres pour le récepteur

Lorsque la case est désélectionnée, les mêmes paramètres sont utilisés pour l’émetteur et le récepteur.

Lorsque la case est cochée, les paramètres de la section Paramètres de connexion s’appliquent à l’émetteur et les paramètres définis dans Paramètres de connexion du récepteur s’appliquent au récepteur.

Serveur récepteur, port, compte, mot de passe, type de système

Ces paramètres s’appliquent au récepteur en mode émetteur + récepteur. Ils fonctionnent comme l’élément émetteur, voir ci-dessus pour plus de détails.

Paramètres de canal SMPP

Autoriser la translitération des caractères

La translitération est le processus de recherche de caractères équivalents à des caractères manquants. Par exemple, le caractère français « ê » (e avec accent circonflexe) est manquant dans le codage GSM, mais il peut être remplacé par « e » sans trop altérer la lisibilité.

Lorsque cette case est désélectionnée, le codage de texte échoue s’il ne parvient pas à coder la chaîne avec précision.

Lorsque cette case est cochée, le codage de texte tente de convertir la chaîne en une version approximative au lieu d’échouer.

Pour plus d’informations sur le processus de codage, consulter Définition d’un mappage spécifique des paramètres de codage.

Disponible pour le connecteur d’Adobe Campaign Classic SMPP étendu et Adobe Campaign Standard.

Le connecteur d’Adobe Campaign Classic SMPP Générique propose toujours la translitération des caractères.

Stockage d’un MO entrant dans la base de données

Lorsque cette option est activée, le MO entrant est stocké dans le tableau inSMS de la base de données. Ce tableau peut être interrogé en utilisant l’activité de requête de tout processus.

Disponible dans Adobe Campaign Standard depuis la version 18.1.

Adobe Campaign Classic stocke toujours tous les MO dans la base de données inSMS, de sorte que cette option n’est pas disponible.

Activer les mises à jour KPI en temps réel lors du traitement SR

Lorsque cette option est activée, les KPI sont mis à jour en temps réel sur la page de diffusion principale lors de la réception de l’erreur SR.

Les performances peuvent être faibles en raison de la limitation de la base de données générée. En cas de désactivation, les statistiques sont mises à jour par le processus syncfromexec, normalement toutes les 20 minutes.

Disponible dans Adobe Campaign Standard depuis la version 18.2.

Adobe Campaign Classic est doté d’un mécanisme entièrement différent pour les KPI. Cette option n’est donc pas disponible.

Numéro de source

Définit l’adresse source par défaut des messages. Ce paramètre s’applique uniquement si le numéro de source a été laissé vide lors de la diffusion.

Par défaut, le champ du numéro source n’est pas transmis. Le fournisseur le remplace par un code court.

Cela permet d’activer la fonction de remplacement de l’adresse de l’expéditeur/oADC.

Applicable à toutes les versions.

Code court

Indique le code court principal du compte. Si plusieurs codes courts sont utilisés pour ce compte ou si le code court est inconnu, laisser ce champ vide.

La définition du code court est utile pour 2 fonctionnalités :

  • L’aperçu affiche le code court si aucun numéro source n’est fourni. Cela reflète le comportement réel sur le téléphone mobile.
  • Le paramètre blacklisting de la fonction de réponse automatique (décrit ci-dessous) concerne uniquement l’utilisateur pour un code court spécifique. C’est pour respecter les lois en vigueur aux États-Unis et en France que cette fonction a été développée.

Disponible uniquement pour le connecteur d’Adobe Campaign Classic SMPP étendu et Adobe Campaign Standard.

Source TON/NPI, Destination TON/NPI

TON (type de nombre) et NPI (indicateur de modèle de numérotation) sont décrits dans la section 5.2.5 de la spécification SMPP 3.4. Ces valeurs doivent être définies en fonction des besoins du fournisseur.

Ils sont transmis tels quels dans les champs source_addr_ton, source_addr_npi, dest_addr_ton et dest_addr_npi du PDU SUBMIT_SM.

Applicable à toutes les versions.

Type de service

Ce champ est transmis tel quel dans le champ service_type du PDU SUBMIT_SM. Définir ce paramètre en fonction des besoins du fournisseur.

Applicable à toutes les versions.

Débit et délais d’expiration

Ces paramètres contrôlent tous les aspects de délais du canal SMPP. Certains fournisseurs exigent un contrôle très précis du taux de messages, des fenêtres et des délais de nouvelles tentatives. Ces paramètres doivent être définis sur les valeurs correspondant à la capacité du fournisseur et les conditions indiquées dans leur contrat.

Les paramètres de cette section ne s’appliquent pas au connecteur d’Adobe Campaign Classic SMPP Générique. C’est toujours envoyé rapidement.

Envoi de la fenêtre

La fenêtre est le nombre de PDU SUBMIT_SM pouvant être envoyés sans qu’il soit nécessaire d’attendre un SUBMIT_SM_RESP correspondant.

Exemple d’envoi avec une fenêtre maximale de 4 :

smpp_window

La fenêtre contribue à augmenter le débit lorsque le lien réseau a une latence élevée.

Si la fenêtre est trop grande, vous pouvez envoyer davantage de messages en double en cas de problèmes de connexion (cas rare). En outre, la plupart des fournisseurs disposent d’une limite très stricte pour la fenêtre et rejettent les messages qui dépassent la limite.

S’applique au connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard. L’ancien connecteur d’Adobe Campaign Classic SMPP Générique ne contrôle pas sa fenêtre.

Débit MT maximum

Nombre maximal de MT par seconde. Ce paramètre est strictement appliqué, le MTA ne pousse jamais les messages plus rapidement que cette limite. C’est utile pour les fournisseurs qui exigent un ralentissement précis.

0 signifie qu’il n’y a pas de limite, le MTA enverra un MT aussi rapidement que possible.

S’applique au connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard. L’ancien connecteur d’Adobe Campaign Classic SMPP Générique ne contrôle pas son débit.

Durée avant reconnexion

Lorsque la connexion TCP est perdue, le connecteur attend ce nombre de secondes avant de tenter d’établir une connexion.

S’applique au connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

Délai d’expiration du MT

Il s’agit du délai d’attente entre SUBMIT_SM et le SUBMIT_SM_RESP correspondant. Si RESP n’est pas reçu à temps, le message est considéré comme ayant échoué et la politique de nouvelle tentative du MTA s’applique.

Concerne le connecteur d’ACC Extended SMPP et Adobe Campaign Standard.

Délai d’attente de liaison

Délai d’attente entre la tentative de connexion TCP et la réponse BIND_*_RESP. Lorsque le délai a expiré, la connexion est fermée par le connecteur de Campaign et il attendra le temps de la Durée avant reconnexion avant de réessayer.

S’applique au connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

enquire_link est un type spécial de PDU envoyé pour conserver la connexion active. Cette durée est en secondes. Le connecteur de Campaign envoie uniquement enquire_link lorsque la connexion est inactive afin d’économiser la bande passante. Si aucune valeur RESP n’est reçue après deux fois cette durée, la connexion sera considérée comme inactive et un processus de reconnexion est déclenché.

S’applique au connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

L’ancien connecteur d’Adobe Campaign Classic SMPP Générique peut être configuré par un paramètre dans le fichier serverConf.

Spécifications de SMSC

Ces paramètres sont des paramètres avancés qui permettent d’adapter le connecteur de Campaign à la plupart des particularités d’implémentation du SMPP.

Définition d’un mappage spécifique de codages

Consulter la section Codage de texte SMS suivante pour plus d’informations sur le codage de texte.

Ce paramètre vous permet de définir un mappage de codage personnalisé, différent de la spécification. Vous pouvez déclarer une liste de codages, avec leur valeur data_coding.

Le MTA essaie d’effectuer un codage à l’aide du premier codage de la liste. S’il échoue, il essaie d’utiliser le codage suivant de la liste, etc. Si aucun codage ne peut être utilisé pour coder le message, une erreur se produit. Une fois que le codage est trouvé, le MTA établit le PDU SUBMIT_SM avec le texte codé et le champ data_coding avec la valeur spécifiée dans le tableau.

L’ordre des éléments dans le tableau est important : les codages sont des tentatives de haut en bas. Il est recommandé de placer le codage le plus économique ou le plus recommandé en haut de la liste, puis d’effectuer des codages de plus en plus chers (ou moins intéressants).

L’UCS-2 n’échoue jamais, car il peut coder tous les caractères pris en charge dans Campaign et que la longueur maximale d’un SMS UCS-2 est bien plus petite (70 caractères seulement).

Il est également possible d’utiliser ce paramètre pour forcer l’utilisation d’un codage spécifique en indiquant une seule ligne dans le tableau de mappage.

Le mappage par défaut utilisé lorsque la case n’est pas cochée équivaut au tableau suivant :

data_coding Codage
0 GSM
9 UCS-2

Cela signifie que le MTA essaie de coder le message dans GSM. S’il réussit, il l’envoie avec data_coding défini à 0.

Si le message ne peut pas être converti en GSM, il va être encodé en UCS-2 et définira data_coding à 8.

Cette mappage dynamique est uniquement disponible dans le connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

L’ancien connecteur d’Adobe Campaign Classic SMPP Générique utilise un mappage fixe :

data_coding Codage
0 GSM
1 ASCII
3 ISO-8859-1
6 ISO-8859-5
7 ISO-8859-8
8 UTF-16BE

Activer message_payload

Lorsque cette option est désactivée, les SMS longs sont divisés par le MTA et envoyés dans plusieurs PDU SUBMIT_SM avec UDH. Le message sera recomposé par le téléphone mobile en suivant les données UDH.

Lorsque cette option est cochée, les SMS longs sont envoyés dans un seul PDU SUBMIT_SM, mettant le texte dans le champ facultatif message_payload (voir la spécification SMPP pour plus d’informations sur cette opération).

Si cette fonction est activée, Campaign ne peut pas compter les parties de SMS individuellement : tous les messages sont comptabilisés en une seule partie.

Sélectionnable uniquement dans le connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

L’ancien connector v6 utilise les deux méthodes en fonction du fournisseur. L’ancien paramètre « SMPP Générique » utilise UDH (pas de message_payload).

Envoyer le numéro de téléphone complet

Lorsque cette case n’est pas cochée, seuls les chiffres du numéro de téléphone sont envoyés au fournisseur (champ destination_addr du champ SUBMIT_SM). Il s’agit du comportement par défaut dans lequel l’indicateur de numéro international (généralement un préfixe +) est remplacé par des champs TON et NPI dans SMPP.

Lorsque la case est cochée, le numéro de téléphone est envoyé tel quel, sans traitement préalable (avec espaces potentiels, préfixe +, signes dièse ou étoile).

S’applique au connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

L’ancien connecteur d’Adobe Campaign Classic SMPP Générique supprime le préfixe et les espaces automatiquement.

Ignorer la vérification du certificat TLS

Lorsque TLS est activé, ignorer toutes les vérifications de certificat. Lorsque cette option est activée, la connexion n’est plus sécurisée. Elle ne doit donc pas être activée dans la production.

Cela peut être utile pour un débogage ou un test.

Lier TON/NPI

TON (type de nombre) et NPI (indicateur de modèle de numérotation) (décrit dans la section 5.2.5 de la spécification SMPP 3.4). Ces valeurs doivent être définies en fonction des besoins du fournisseur.

Elles sont transmises telles quelles dans les champs addr_ton et addr_npi du PDU BIND.

Disponible uniquement dans le connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

Plage d’adresses

Envoyé tel quel dans le champ address_range du PDU BIND. Cette valeur doit être définie en fonction des besoins du fournisseur.

Disponible uniquement dans le connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

Regex d’extraction de l’identifiant dans le SR

Le format SR n’est pas strictement appliqué par la spécification de protocole SMPP. Il s’agit simplement d’une recommandation décrite dans la section annexe B des spécifications. C’est pourquoi certaines implémentations SMPP mettent ce champ en forme différemment, de sorte que Campaign a besoin d’un moyen d’extraire le champ adéquat.

Par défaut, cette commande saisit jusqu’à 10 caractères alphanumériques après « id : ».

Le regex doit avoir exactement une parenthèse de saisie. Le format regex est PCRE.

Disponible uniquement dans le connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

Le regex est appliqué pour déterminer l’état de réussite ou d’erreur.

Lorsque les messages contenant une combinaison de champs stat/err inconnus sont détectés, ces regex sont appliqués sur le champ État afin de déterminer si SR a été un succès ou une erreur.

Par défaut, les valeurs d’état qui commencent par DELIV (par exemple DELIVRD dans l’annexe B) sont considérées comme correctement envoyées et toutes les valeurs d’état qui correspondent à des erreurs (par exemple REJECTED, UNDELIV,…) sont considérés comme des erreurs.

Disponible uniquement dans le connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

Format de l’identifiant dans un accusé de réception MT

Cela indique le format de l’identifiant renvoyé dans le champ message_id du PDU SUBMIT_SM_RESP.

  • Ne pas modifier : l’identifiant est stocké tel quel dans la base de données, au format de texte codé ASCII. Aucun pré-traitement ni filtrage ne se produit.
  • Nombre décimal : l’identifiant doit être un nombre décimal au format ASCII. Les espaces avant et après et les zéros du début sont supprimés lorsque ce paramètre est utilisé.
  • Nombre hexadécimal : l’identifiant doit être un nombre hexadécimal au format ASCII, sans interligne 0x ni fin h. L’identifiant est ensuite converti en nombre décimal avant d’être stocké dans la base de données.
  • Chaîne hexadécimale : l’identifiant doit être un texte codé en ASCII qui correspond à une chaîne d’octets codés en hexadécimal. Par exemple, dans le PDU vous trouverez 0x34 0x31 0x34 0x32 0x34 0x33, qui se traduit en ASCII par « 414243 ». Ensuite, cette chaîne est décodée comme une chaîne hexadécimale d’octets, et vous obtenez « ABC » comme résultat : vous stockez l’identifiant « ABC » dans la base de données.

Disponible uniquement dans le connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

Format de l’identifiant dans SR

Indique le format de l’identifiant capturé par le Regex d’extraction de l’identifiant dans le SR. Les valeurs ont la même signification et le même comportement que le format MT ci-dessus.

Disponible uniquement dans le connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

Identifiant du SR ou code d’erreur dans un champ facultatif

Si cette option est activée, le contenu des champs facultatifs est ajouté au texte traité par les regex ci-dessus. Le texte est au format « 0xTAG:VALUE », 0xTAG étant la valeur hexadécimale à 4 chiffres de la balise en majuscules (par exemple 0x002E).

Il est possible, par exemple, de capturer l’identifiant dans le champ receipted_message_id. Pour le faire, cocher la case et le texte suivant sera ajouté à l’état :

0x001E:05e3299e-8d37-49d0-97c6-8e4fe60c7739

Dans cet exemple, 0x001E est la balise du champ facultatif et UUID correspond à la valeur du champ.

Pour capturer cette valeur, vous pouvez maintenant définir le regex suivant dans le champ Regex d’extraction de l’identifiant dans le SR :

\b0x001E:([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})\b

Attention :

Il est possible de capturer uniquement les champs facultatifs ayant des valeurs de texte (ASCII/UTF-8). En particulier, les champs binaires ne peuvent pas être capturés de manière fiable avec le système regex actuel.

Disponible uniquement dans le connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

Identifiant du SR ou code d’erreur dans le champ de texte

Si cette option est cochée, le champ Texte : est conservé durant le traitement de l’état du texte du SR.

Cette méthode est utile si le fournisseur place des données importantes dans ce champ comme l’identifiant ou l’état. En règle générale, ce champ peut être abandonné en toute sécurité, car il peut contenir du texte avec un codage non ASCII et perturber le traitement des regex.

Disponible uniquement dans le connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

Balise du service ID

Permet d’ajouter un TLV personnalisé. Ce champ définit la partie de la balise. La valeur peut être personnalisée pour la diffusion.

Disponible uniquement dans le connecteur d’Adobe Campaign Classic Extended SMPP et Adobe Campaign Standard.

Réponse automatique envoyée au MO

Cette fonction permet de répondre rapidement au texte du MO et de traiter les blacklists de code court.

Les colonnes Mot-clé et Code court définissent les conditions de déclenchement de la réponse automatique. Si les deux champs correspondent, le MO est envoyé et l’action supplémentaire est déclenchée. Pour spécifier un caractère générique, vous devez laisser le champ vide. Le mot-clé correspond au premier mot alphanumérique du texte du MO, en ignorant la ponctuation et les espaces.

La colonne Réponse est le texte de réponse. Aucune personnalisation n’est disponible dans ce champ. Si vous ne renseignez pas ce champ, aucun message ne sera répondu mais l’action supplémentaire est tout de même déclenchée.

La colonne Action supplémentaire offre une action supplémentaire à faire lorsque mot-clé et code court correspondent. Actuellement, vous pouvez exclure (blacklist) ou réintégrer (unblacklist) le destinataire ; aucun répond uniquement au texte. L’action est déclenchée même si vous ne spécifiez pas de réponse. Le blacklistage ne s’applique qu’au numéro court spécifié, et non au profil entier (il s’agit de la configuration légale minimale requise dans la plupart des pays).

Toutes les entrées du tableau sont traitées dans l’ordre spécifié jusqu’à ce qu’une règle corresponde. Si plusieurs règles correspondent à un MO, seule la règle supérieure est appliquée.

L’ancien connecteur d’Adobe Campaign Classic SMPP Générique est doté d’une fonction de réponse automatique, mais ne blackliste pas. Cet élément fonctionne différemment. Consulter la documentation de Campaign Classic pour plus d’informations.

Paramètres du modèle de diffusion des SMS

Certains paramètres peuvent être définis par modèle de diffusion.

A partir du champ

Ce champ est facultatif. Il permet de remplacer l’adresse de l’expéditeur (oADC). Le contenu de ce champ est défini dans le champ source_addr du PDU SUBMIT_SM.

Le champ est limité à 21 caractères par la spécification SMPP, mais certains fournisseurs peuvent autoriser des valeurs plus longues. Des restrictions très strictes peuvent être appliquées dans certains pays (longueur, contenu, caractères autorisés, etc.).

Paramètres de diffusion

Nombre maximal de SMS par message

Ce paramètre fonctionne uniquement si le paramètre Charge utile du message est désactivé (voir dans les paramètres du compte externe pour plus d’informations). Si le message nécessite plus de SMS que cette valeur, une erreur est déclenchée.

Le protocole SMS limite les SMS à 255 parties, mais certains téléphones portables ont des difficultés à assembler des messages avec plus de 10 parties environ (la limite dépend du model exact). Il est recommandé de ne pas dépasser 5 parties par message.

S’applique également à Adobe Campaign Classic (toutes les versions, tous les connecteurs).

Mode de transmission

Ce champ indique le type de SMS que vous souhaitez transférer : messages normaux ou flash, stockage sur le mobile ou sur la carte SIM.

Ce paramètre est transmis dans le champ facultatif dest_addr_subunit du PDU SUBMIT_SM.

  • Non spécifié n’envoie aucun champ facultatif dans le PDU.
  • Flash définit la valeur à 1. Envoie un message Flash qui s’affiche sur le périphérique mobile et n’est pas enregistré dans la mémoire.
  • Normal définit la valeur à 0. Envoie un message normal.
  • Enregistrer sur périphérique mobile définit la valeur à 2. Indique au téléphone de stocker le SMS dans la mémoire interne.
  • Enregistrer sur le terminal définit la valeur à 3. Indique au téléphone de stocker le SMS dans la carte SIM.

Les valeurs sont différentes pour ACC. Vérifier la documentation qui l’accompagne.

Durée de validité

La durée de validité est transmise dans le champ validity_period du PDU SUBMIT_SM. La date est toujours présentée sous un format d’heure UTC absolu (le champ de date se termine par « 00 + »).

La durée de validité s’applique également à Adobe Campaign Classic (toutes les versions, tous les connecteurs).

Codage de texte SMS

Vous devez toujours contacter le fournisseur SMSC en cas de problèmes de codage. Seuls les fournisseurs SMSC ont une connaissance précise du codage qu’ils prennent en charge et des règles spéciales pouvant s’appliquer en raison de limitations de leur plate-forme technique. Faites-leur vérifier les éléments que vous leur envoyez et ce qu’ils vous renvoient, c’est le seul chemin vers une interconnexion réussie et stable.

Les messages SMS utilisent un codage spécifique 7 bits, souvent appelé codage GSM7.

Dans le protocole SMPP, le texte GSM7 est augmenté à 8 bits par caractère pour un dépannage rapide. Le SMSC le conditionne en 7 bits par caractère avant de l’envoyer au périphérique mobile. Cela signifie que le champ short_message du SMS peut atteindre 160 octets dans l’image SMPP alors qu’il est limité à 140 octets lorsqu’il est envoyé sur le réseau mobile (le bit le plus significatif est simplement rejeté).

En cas de problèmes de codage, quelques éléments importants sont à vérifier :

  • Tout d’abord, reconnaître les caractères appartenant au codage. GSM7 ne prend pas complètement en charge les signes diacritiques (accents). Particulièrement en français, car é et è existent dans GSM7, mais pas ê, â ou ï. Le problème est le même en espagnol.
  • Le C cédille (ç) apparaît uniquement en majuscules dans l’alphabet GSM7, mais certains téléphones le proposent en minuscules : la recommandation générale consiste à l’éviter complètement et de retirer la cédille ou de basculer vers UCS-2.
  • Éviter l’utilisation de ASCII dans les SMS sauf demande explicite du fournisseur de SMSC. Ce codage gaspille l’espace, car il contient des caractères 8 bits et une couverture inférieure à celle du GSM7.
  • Latin-1 n’est pas toujours pris en charge. Vérifier la compatibilité avec votre fournisseur SMSC avant d’utiliser le Latin-1.
  • Les tableaux de changement de langue nationale ne sont pas pris en charge par le connecteur d’Adobe Campaign. Utiliser UCS-2 ou un autre data_coding à la place.
  • UCS-2 et UTF-16 sont souvent mélangés par les téléphones. C’est un problème pour les personnes qui envoient des émojis et d’autres caractères rarement utilisés non présents dans UCS-2.
  • La plupart des téléphones ne disposent pas de glyphes de police pour tous les caractères UCS-2. Les smartphones sont généralement en mesure d’afficher des caractères rares, mais les téléphones portables ont généralement limité la prise en charge à ce qui est utile dans la langue maternelle du pays dans lequel ils ont été achetés. Pour utiliser les émojis ou certains symboles dans ASCII, il faut le tester sur un large éventail de téléphones avant de l’envoyer. L’aperçu de Campaign ne simule pas les glyphes manquants et affichent les symboles disponibles sur le navigateur Web affichant l’aperçu.

Le champ data_coding indique le codage utilisé. Un problème majeur est que la valeur 0 signifie codage SMSC par défaut dans la spécification. En règle générale, cela signifie GSM7, mais ce n’est pas toujours le cas. Vérifier auprès du partenaire SMSC dont le codage est associé à data_coding = 0 (Adobe Campaign prend uniquement en charge GSM7 pour data_coding = 0). Les autres valeurs data_coding ont tendance à suivre la spécification, mais la seule façon d’être sûr consiste à vérifier auprès du fournisseur SMSC.

La taille maximale d’un message dépend de son codage. Le tableau suivant répertorie toutes les informations pertinentes :

Codage data_coding habituel Taille du message (caractères) Taille de la partie pour des SMS en plusieurs parties Caractères disponibles

GSM7

0

160

152

Jeu de caractères de base GSM7 et extension
(les caractères étendus utilisent 2 caractères)
 

Latin-1

3

140

134

ISO-8859-1


UCS-2
UTF-16


8

70

67

Unicode (varie d’un téléphone à un autre)

Gestion des erreurs SMPP : Annexe B

Le protocole SMPP définit des erreurs synchrones standard dans les PDU RESP, mais ne définit pas les codes d’erreur pour SR. Chaque fournisseur utilise ses propres codes d’erreur avec leur signification.

Une recommandation est formulée dans la section Annexe B de la spécification du protocole SMPP, mais cela ne répertorie pas les codes d’erreur réels ni leur signification.

Pour s’adapter à la gestion des erreurs, le grand système de messages du journal de Campaign a été exploité pour détecter correctement les erreurs et leur gravité (hard, soft, etc.).

Comme mentionné ci-dessus, il y a 2 types d’erreurs différents : les réponses synchrones dans le SUBMIT_SM_RESP qui se produisent immédiatement après l’envoi du message au SMSC et les reçus pouvant arriver beaucoup plus tard lorsque le périphérique mobile a reçu le message ou lorsque le message a expiré. Dans ce cas, l’erreur est trouvée dans un SR.

Lorsqu’un SR est reçu, l’état et l’erreur peuvent être trouvés dans le son champ short_message (exemple de mises en œuvre conformes à l’annexe B). Attention, le champ short_message du PDU est souvent appelé champ de texte car il contient du texte en MT. Mais en cas de SR, il contient des informations techniques plus une sous-rubrique nommée Texte (ce qui est inutile, à l’exception de certains dépannages). Ces 2 champs sont différents et short_message en réalité contient le champ Texte et d’autres informations.

Les anciens connecteurs d’Adobe Campaign Classic (à l’exception du SMPP étendu) utilisent un comportement codé en dur qui dépend du fournisseur sélectionné. SMPP Générique ne distingue que les réussites et les erreurs, sans aucun détail. Le journal de diffusion peut contenir des informations qui ne sont pas garanties.

Format du champ de texte SR décrit dans l’Annexe B

La spécification recommande d’utiliser ce format pour le champ de texte SR. Il s’agit d’une liste de sous-rubriques, séparés par deux points pour dissocier le nom du champ et sa valeur. Les noms de champ sont insensibles à la casse.

Exemple de champ de texte SR correspondant exactement à la recommandation de l’Annexe B :

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

La spécification recommande d’utiliser ce format pour le champ de texte SR. Il s’agit d’une liste de sous-rubriques, séparés par deux points pour dissocier le nom du champ et sa valeur. Les noms de champ sont insensibles à la casse.

Exemple de champ de texte SR correspondant exactement à la recommandation de l’Annexe B :

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

Le champ ID est l’identifiant reçu dans le PDU SUBMIT_SM_RESP (l’accusé de réception du MT).

sub et dlvrd sont censés compter le nombre de pièces et de messages diffusés, mais cela fonctionne rarement et n’est pas utilisé par Campaign puisque le grand système de journal est supérieur et donne des informations meilleures et mieux intégrées.

Les champs Date d’envoi et Date effectuée sont des horodatages indicatifs de la date d’envoi du MT et de l’envoi du SR par le périphérique mobile. Certains problèmes peuvent survenir avec les fuseaux horaires ou des horodatages incorrects, donnés par les périphériques mobiles avec une date incorrecte.

Le champ stat est important : il indique l’état du message. Les seuls statuts importants sont DELIVRD, UNDELIV et REJECTD. DELIVRD indique une réussite, les deux autres indiquent une erreur. Les autres valeurs sont possibles, mais sont généralement des notifications intermédiaires (par exemple, le MT a atteint l’opérateur mobile, mais pas le téléphone portable) : ces notifications intermédiaires sont ignorées par Campaign.

Le champ err contient le code d’erreur propre au fournisseur. Le fournisseur doit donner un tableau des codes d’erreur possibles ainsi que leur signification pour pouvoir interpréter cette valeur.

Enfin, le champ Texte contient généralement le début du texte du MT. Cette option est ignorée par Campaign et certains fournisseurs ne le transmettent pas pour éviter les fuites PII et la consommation inutile de bande passante du réseau. Le seul avantage apparaît au cours de la résolution des problèmes : vous pouvez repérer plus facilement le SR correspondant à un MT de test en lisant ce champ.

Exemple du mode de traitement d’un SR dans Adobe Campaign Standard

Ceci montre un exemple concret de la manière dont le MTA traite un SR. Cet exemple illustre le cas d’une mise en œuvre suivant exactement la recommandation de l’Annexe B, les valeurs par défaut du compte externe et un SMS MT réussi.

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

Tout d’abord, le regex d’extraction de l’identifiant est appliqué pour extraire l’identifiant et le réparer avec le MT correspondant.

Ensuite, le regex d’extraction d’état et le regex d’extraction de code d’erreur sont appliqués pour extraire ces champs et ils sont ajoutés à la chaîne.

Messages de journal est créé avec ces informations et la chaîne d’origine non modifiée est ajoutée pour référence :

SR ExampleProvider DELIVRD 000|MESSAGE=id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

Le message est ensuite normalisé, en supprimant la partie message afin de pouvoir faire correspondre plusieurs messages avec les mêmes codes d’état et d’erreur.

SR ExampleProvider DELIVRD 000|#MESSAGE#

Si le message n’est pas déjà enregistré dans le grand tableau de message de journal, une nouvelle entrée est créée en utilisant le message entier comme « firstText » et le message normalisé. Le connecteur utilise ensuite le regex de réussite et d’erreur pour déterminer s’il s’agit d’une réussite ou d’un échec.

Par défaut, toutes les erreurs sont interprétées en tant qu’erreurs hard. Cela signifie que les erreurs softs doivent être réglées manuellement pour permettre de nouvelles tentatives.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne