Push API Technical Specifications V1.0

Transcription

1 Push API Technical Specifications V1.0 Page 1

2 1 PROTOCOLE SMPP Commandes supportées Paramètres optionnels supportés Connexion et authentification Requête client > serveur Requête serveur > client Enquire Link Format des adresses Jeux de caractères Rapport d envoi Codes d erreur Requêtes client Requêtes server Schéma de flux... 6 Page 2

3 1 PROTOCOLE SMPP 1.1 Commandes supportées L envoi et la réception de SMS en masse se fait via le protocole SMPP. Le serveur implémente la révision 3.4 du protocole. JMF (SMPP server) > PARTNER (SMPP client) generic_nack bind_transceiver bind_transmitter bind_receiver unbind enquire_link submit_sm deliver_sm_resp PARTNER (SMPP client) > JMF (SMPP server) generic_nack bind_transceiver_resp bind_transmitter_resp bind_receiver_resp unbind_resp enquire_link_resp submit_sm_resp deliver_sm F IGURE 1.1 Liste des commandes supportées 1.2 Paramètres optionnels supportés Paramètres receipted_message_id Référence F IGURE 1.2 Liste des paramètres optionnels supportés Page 3

4 1.3 Connexion et authentification La connexion se fait en TCP/IP. Les paramètres de connexion (ip/port) sont communiqués séparément. Paramètres system_id password system_type interface_version address_range Description Votre identifiant de connexion (obligatoire) Votre mot de passe (obligatoire) Paramètre ignoré 0x34 (obligatoire) Paramètre ignoré Ref F IGURE 1.3 Liste des paramètres de la commande BIND Le client peut ouvrir plusieurs connexions en transceiver. Un seul et unique 1 compte SMPP (system_id et mot de passe) sera fourni par Partenaire. Le nombre maximal de connexions TCP est fixé à Requête client > serveur Le client peut envoyer simultanément jusqu à 100 requêtes non acquittées par le serveur. Au delà, l erreur esme_rmsgqful est renvoyée Requête serveur > client Le serveur peut envoyer simultanément jusqu à 100 requêtes non acquittées par le client. Si leclient n a pas acquitté une commande après 30 secondes, le serveur oubliera cette transaction et procédera ultérieurement à une nouvelle tentative. 1.4 Enquire Link Le client est tenu d envoyer une requête ENQUIRE _ LINK toutes les 30 à 60 secondes, pour éviter une déconnexion automatique. Le serveur n enverra jamais cette requête. 1. Format des adresses Les adresses source et destination doivent être exclusivement composés de chiffres, les autres caractères ne sont pas autorisés. Le serveur utilisera systématiquement le format international pour les numéros des abonnés. TON NPI Numéro (exemple) Format 0x01 0x internationnal F IGURE 1.3 Format d adresse supporté pour le push Page 4

5 1.6 Jeux de caractères Les différents types d encodage supportés par le serveur, selon le paramètre data_coding (.2.19), sont : 0x00 : utf8 0x01 : gsm (selon etsi ) 0x04 : binary Les commandes deliver_sm envoient des messages encodés en UTF-8 avec un data_coding à 0x00. Seuls les caractères res contenus dans l'alphabet GSM sont acheminés. Les autres sont remplacés par des équivalences lorsque cela est possible. 1.7 Rapport d envoi Si le paramètre registered_delivery (.2.17) est renseigné lors d une commande SUBMIT _ SM ou DATA _ SM, un rapport d envoi (Delivery Receipt) sera envoyé à l émetteur. Seule la valeur 0x01 (SMSC Delivery Receipt requested where final delivery outcome is delivery success or failure) est supportée. Dans le rapport d envoi, le contenu de short_message respecte approximativement l annexe B. Exemple : id: sub:001 dlvrd:001 submit date: done date: stat:delivrd err:000 text: Le champ id sera toujours composé de 10 zéros. Pour associer un rapport d envoi au résultat de SM_SUBMIT (message_id,.2.23), le client devra utiliser le paramètre RECEIPTED _ MESSAGE _ ID ( ). Le champ sub sera toujours égal à 001, le serveur ne supportant pas les listes de distribution. Le champ dlvrd peut être soit 000 (échec), soit 001 (réussite). Le champ stat est conforme à la table B-2. Le champ err est une référence d erreur interne au serveur. Le champ text n est pas renseigné. 1.8 Codes d erreur Requêtes client Le paramètre command_status (.1.3) de la réponse renvoyée au client renseigne le succès ou l échec de la commande. En cas d échec (command_status différent de EMSE_ROK), et en fonction des cas, le client peut choisir de répéter ultérieurement la requête Requêtes server Lors de la requête serveur DELIVER_SM, le client peut retourner une erreur. Dans tous les cas d erreur (ainsi que sur non-réponse, au bout d un délai de 30 secondes), la requête est retentée jusqu à être acceptée ou jusqu à l expiration du SMS. Page

6 La seule exception est lorsque le client retourne le code d erreur ESME_RX_P_APPN (ESME Receiver Permanent App Error Code). Dans ce cas, aucune tentative ne sera effectuée et le SMS immédiatement supprimé. 1.9 Schéma de flux Voici un exemple d échange SMPP concernant le PUSH sur la plateforme JMF. Le partenaire initie une connexion avec une trame bind_transceiver, puis maintient cette connexion en envoyant des trames enquire_link (keep-alive) à intervalles réguliers (entre 30s et 60s). Le partenaire peut alors envoyer ses messages MT de push sur cette connexion (trames submit_sm). JMF bind_transceiver [1] bind_transceiver_resp [1] enquire_link [2] enquire_link_resp [2] PARTENAIRE submit_sm [3] submit_sm_resp [3] submit_sm [n] submit_sm _resp [n] enquire_link [n+1] enquire_link_resp [n+2] submit_sm [n+3] submit_sm_resp [n+3] submit_sm [m] submit_sm _resp [m] enquire_link [m+1] enquire_link_resp [m+1] Page 6

7 Une fois la connexion SMPP établie, la partenaire peut recevoir à tout moment des trames deliver_sm relative à la transmission d un sms MO ou d un deliver receipt. JMF PARTENAIRE deliver_sm [i] deliver_sm_resp [i] Page 7