Référence du protocole de messagerie.
Un ouvrage de référence précis et conforme aux normes pour les protocoles de transmission des SMS, destiné aux ingénieurs chargés de leur câblage. Basé sur les spécifications SMPP v3.4/v5.0 et 3GPP TS 23.038/23.040, il propose des schémas d'octets, des tables de champs et des exemples de format de transmission.
65 documents sur 9 protocoles
SMPP
Le protocole Short Message Peer-to-Peer (SMPP) — le protocole de session binaire que les opérateurs et les agrégateurs exposent pour la messagerie A2P à haut débit.
- Fondamentaux
Vue d'ensemble du protocole SMPP
Ce qu'est le SMPP, comment fonctionne la session ESME↔SMSC, la différence entre v3.4 et v5.0, et pourquoi il reste la norme du SMS A2P à haut débit.
- Format binaire
Anatomie d'une PDU SMPP : en-tête et corps
La disposition exacte des octets d'une PDU SMPP : l'en-tête de 16 octets (command_length, command_id, command_status, sequence_number), le corps, et l'encodage des champs.
- Session
Opérations de bind SMPP et états de session
Comment une session SMPP s'authentifie : bind_transmitter, bind_receiver et bind_transceiver, les champs system_id/password/system_type, interface_version, les états de session et unbind.
- Opérations
SMPP submit_sm : tous les champs obligatoires
Une référence complète champ par champ de submit_sm — service_type, TON/NPI, esm_class, data_coding, registered_delivery, validity_period, short_message et le reste — avec les valeurs qui comptent vraiment.
- Opérations
SMPP deliver_sm : messages MO et accusés
deliver_sm porte deux choses du SMSC vers l'ESME : les messages mobile-originated (MO) et les accusés de réception. Comment les distinguer avec esm_class, et pourquoi il faut toujours répondre deliver_sm_resp.
- Erreurs
Codes d'erreur command_status SMPP
Le champ command_status du SMPP et la plage d'erreurs ESME_R* : ce que signifient les codes courants (ESME_RINVPASWD, ESME_RTHROTTLED, ESME_RMSGQFUL…) et comment réagir à chacun.
- Format binaire
Paramètres optionnels TLV SMPP
Les paramètres optionnels du SMPP utilisent un format Tag-Length-Value. La disposition d'octets du TLV plus les tags courants : message_payload, receipted_message_id, message_state, user_message_reference et l'ensemble sar_* de concaténation.
- Opérations
Format des accusés de réception SMPP (DLR)
Le format texte d'accusé de réception de l'Annexe B à l'intérieur de deliver_sm : id, sub, dlvrd, submit date, done date, stat, err et Text — plus les mots-clés stat et leurs numéros message_state.
- Session
SMPP enquire_link, fenêtrage et throttling
Comment le SMPP maintient une session en vie avec enquire_link, comment la fenêtre limite les PDU non acquittées en attente, et comment ESME_RTHROTTLED et le TPS par bind régissent votre débit réel.
- Sécurité
Sécuriser le SMPP : TLS, authentification et liste d'IP autorisées
Le SMPP n'a pas de chiffrement natif. Comment sécuriser un bind en production : SMPP sur TLS, authentification par identifiants et par IP, listes d'autorisation, et hygiène des identifiants.
- Fondamentaux
SMPP v3.4 vs v5.0 : ce qui a changé
Les différences pratiques entre SMPP v3.4 et v5.0 : contrôle de congestion, opérations de diffusion, états de message et TLV supplémentaires — et pourquoi la v3.4 reste l'interconnexion par défaut.
- Intégration
Bonnes pratiques d'intégration SMPP
Comment bâtir une intégration SMPP fiable en production : stratégie de bind, discipline du sequence_number, fenêtrage, réémissions avec temporisation, idempotence, gestion des DLR et reconnexion.
Encodage SMS
Comment le texte des SMS est encodé sur le réseau — GSM 7 bits, UCS-2, schémas de codage des données, segmentation et implications financières de chaque caractère.
- Jeux de caractères
Le jeu de caractères GSM-7
L'alphabet par défaut GSM 7 bits complet de GSM 03.38 : la table de base de 128 caractères, la table d'extension par échappement (| ^ € { } [ ] ~ \ et saut de page), et le fonctionnement du packing 7 bits.
- Jeux de caractères
UCS-2 et SMS Unicode
Comment le SMS transporte l'Unicode via UCS-2 (16 bits) : la limite de 70 caractères par message unique, 67 par segment concaténé, ce qui force l'UCS-2, et la subtilité des paires de substitution pour les emoji.
- Codage des données
Le schéma de codage des données (DCS)
L'octet de schéma de codage des données qui indique au réseau comment un SMS est encodé : GSM-7 (0x00), 8 bits (0x04), UCS-2 (0x08), plus les classes de message (0/flash à 3/SIM) de GSM 03.38.
- Segmentation
Segmentation, concaténation et UDH du SMS
Comment un long SMS est découpé et réassemblé : le User Data Header de 6 octets, les 153 (GSM-7) et 67 (UCS-2) caractères par segment qui en résultent, le numéro de référence et le séquencement des segments.
- Coût
Détection d'encodage et coût du SMS
Comment détecter si un texte est GSM-7 ou UCS-2, quels caractères forcent silencieusement l'UCS-2, et comment l'encodage pilote le nombre de segments — et donc le coût — de chaque SMS que vous envoyez.
SS7 / MAP
Système de signalisation n° 7 et couche MAP qui transportent les SMS à destination des mobiles, les requêtes HLR et la gestion de la mobilité sur les réseaux centraux existants.
- Fondamentaux
Vue d'ensemble de la pile SS7 : MTP, SCCP, TCAP, MAP, ISUP
Comment la pile SS7 est structurée en couches — transport MTP1-3, adressage SCCP, transactions TCAP, et les user parts MAP et ISUP — et ce que fait chaque couche pour le SMS, les appels et la mobilité.
- Transport
MTP : le Message Transfer Part (niveaux 1-3)
Les trois niveaux MTP qui transportent le SS7 : liaisons physiques MTP1, liaison de données à contrôle d'erreur MTP2 (unités de signal MSU/LSSU/FISU), et routage MTP3 par point code avec partage de charge et gestion réseau.
- Adressage
SCCP, traduction de global title et subsystem numbers
Comment le SCCP étend MTP3 avec l'adressage par global title : les Called/Calling Party Address, la Global Title Translation (GTT), les subsystem numbers (HLR/VLR/MSC), et les classes en mode connecté vs non connecté.
- Transactions
TCAP : transactions, dialogues et composants
Comment le TCAP structure les échanges applicatifs SS7 : la sous-couche transaction (Begin/Continue/End/Abort avec des identifiants de transaction), la portion dialogue (contexte applicatif) et la sous-couche composant (Invoke, ReturnResult, ReturnError, Reject).
- MAP
Opérations MAP : SRI-SM, ForwardSM, UpdateLocation et plus
Les opérations MAP qui font tourner les réseaux mobiles : SendRoutingInfoForSM et MT-ForwardSM pour le SMS, UpdateLocation pour l'itinérance, ProvideSubscriberInfo et AnyTimeInterrogation pour la localisation — avec leurs opcodes TS 29.002.
- Livraison SMS
Flux de livraison MT-SMS sur SS7, étape par étape
Le chemin complet d'un SMS mobile-terminated sur SS7 : SMSC vers HLR SendRoutingInfoForSM, le HLR renvoie IMSI + MSC de service, SMSC vers MSC MT-ForwardSM, paging et livraison, et la réémission en cas d'abonné absent via MWD et AlertServiceCentre.
- Adressage
Point codes SS7 et adressage réseau
Comment le SS7 adresse les points sémaphores : point codes ITU-T 14 bits vs ANSI 24 bits, leur structure zone/réseau, l'étiquette de routage OPC/DPC/SLS, et le lien entre point codes et global titles SCCP.
- Sécurité
Menaces de sécurité SS7 et catégories GSMA FS.11
Les principales classes d'attaques SS7 — traçage de localisation, interception SMS/OTP, redirection d'appels et fraude — et comment la GSMA FS.11 catégorise les messages MAP (catégories 1/2/3) pour que les pare-feu de signalisation puissent les filtrer.
- Fondamentaux
SS7 vs SIGTRAN : la signalisation TDM sur IP
Comment SIGTRAN se rapporte au SS7 classique : la même couche applicative MTP3/SCCP/TCAP/MAP, mais portée sur IP avec SCTP et M3UA (ou SUA) au lieu des liaisons TDM MTP1/MTP2.
SIGTRAN
Signalisation SS7 transportée sur IP — M3UA, SUA et SCTP — le pont entre la signalisation TDM et les cœurs de paquets modernes.
- Fondamentaux
Vue d'ensemble de SIGTRAN : la signalisation SS7 sur IP
Ce qu'est SIGTRAN : le cadre IETF (RFC 2719) pour porter la signalisation SS7 sur IP, avec le transport SCTP et des couches d'adaptation (M3UA, SUA, M2PA) qui préservent la pile applicative MTP3/SCCP/TCAP/MAP.
- Transport
SCTP : Stream Control Transmission Protocol
Comment fonctionne SCTP et pourquoi SIGTRAN l'utilise : remise orientée message, multi-streaming pour éviter le blocage de tête de ligne, multi-domiciliation pour le basculement de chemin, le format de paquet en chunks, et ses différences avec TCP.
- Adaptation
M3UA : couche d'adaptation des utilisateurs de MTP3
Comment M3UA porte SCCP et ISUP sur SCTP : les rôles SG/ASP/AS, routing keys et routing contexts, classes de message (Transfer, SSNM, ASPSM, ASPTM), et les modes IPSP vs passerelle de signalisation.
- Adaptation
Couches d'adaptation M2PA et SUA
Deux autres couches d'adaptation SIGTRAN : M2PA (RFC 4165) remplace MTP2 pour construire des liaisons IP entre STP faisant tourner MTP3 complet, et SUA (RFC 3868) porte les utilisateurs de SCCP (TCAP/MAP) directement sur SCTP, contournant MTP3.
- Architecture
Architecture de déploiement SIGTRAN : SG, ASP, AS
Comment un réseau SIGTRAN se construit : la passerelle de signalisation reliant TDM et IP, les serveurs d'application et leurs processus, les associations SCTP, et les modes de redondance (override, load-share, broadcast) qui offrent une disponibilité carrier-grade.
SIP / VoIP
Le protocole d'initiation de session (SIP) qui sous-tend la voix programmable, le SIP trunking et le contrôle des appels VoLTE, ainsi que la pile multimédia qui l'accompagne.
- Fondamentaux
Vue d'ensemble du protocole SIP
Ce qu'est le SIP et comment il fonctionne : un protocole de signalisation requête/réponse textuel (RFC 3261) qui établit, modifie et libère des sessions média, ses user agents, proxies et registrars, et ses transactions et dialogues.
- Requêtes
Méthodes et requêtes SIP
Chaque méthode de requête SIP et son rôle : les six méthodes de base de RFC 3261 (INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS) et les extensions courantes (INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE, PUBLISH).
- Réponses
Codes de réponse SIP (1xx-6xx)
Les six classes de code de réponse SIP et celles qui comptent : 1xx provisoire (100 Trying, 180 Ringing), 2xx succès (200 OK), 3xx redirection, 4xx erreur client (404, 486), 5xx erreur serveur et 6xx échec global.
- Messages
En-têtes SIP : Via, From, To, Call-ID, CSeq, Contact
Les en-têtes SIP essentiels et leur rôle : Via (avec le paramètre branch) pour router les réponses, From/To avec tags, Call-ID, CSeq, Contact, Max-Forwards, et comment dialogues et transactions en sont identifiés.
- Médias
SDP : le Session Description Protocol
Comment le SDP décrit une session média à l'intérieur du SIP : la structure de lignes v=/o=/s=/c=/t=/m=/a=, le modèle offre/réponse (RFC 3264), la négociation de codecs via rtpmap, et les attributs de direction média.
- Médias
RTP et SRTP : le flux média
Comment les médias circulent une fois l'appel SIP établi : l'en-tête et la charge utile RTP, les rapports de qualité RTCP, et le chiffrement et l'authentification SRTP avec keying via SDES ou DTLS-SRTP.
- Flux d'appel
Flux d'appel SIP : de l'INVITE au BYE
Un appel SIP complet décrit étape par étape : INVITE avec offre SDP, 100 Trying, 180 Ringing, 200 OK avec réponse SDP, l'ACK en trois temps, les médias RTP, et le démontage BYE/200 OK — plus comment CANCEL avorte un appel qui sonne.
- Déploiement
Trunking SIP et le session border controller
Ce qu'est un trunk SIP et le rôle du session border controller (SBC) : traversée de NAT avec STUN/TURN/ICE, masquage de topologie via B2BUA, sécurité et contrôle d'admission à la frontière du réseau, et transcodage.
DIAMETER
Le protocole AAA et de signalisation derrière la mobilité, la politique et la facturation 4G/5G (S6a, Gx, Gy), le contrôle IMS (Cx / Sh) et la sécurité d'itinérance Diameter à la périphérie IPX.
- Fondamentaux
Protocole de base Diameter : RFC 6733 expliqué
Le fonctionnement du protocole de base Diameter selon la RFC 6733 : en-tête de message de 20 octets, codes de commande et indicateurs R/P/E/T, échange de capacités CER/CEA, watchdog DWR/DWA et déconnexion DPR/DPA, sur SCTP ou TCP/TLS.
- Format de message
AVP Diameter, types de données et Result-Code
L'anatomie d'un AVP Diameter : code, indicateurs V/M/P, longueur, Vendor-Id optionnel et données ; les types de données de base (Enumerated, Unsigned32, OctetString, Address, Time) ; les AVP Grouped ; et le modèle d'erreur Result-Code / Experimental-Result.
- Fondamentaux
Diameter et RADIUS : pourquoi Diameter a remplacé RADIUS
Pourquoi Diameter (RFC 6733) a supplanté RADIUS (RFC 2865) pour l'AAA opérateur : transport SCTP fiable et bascule, négociation de capacités, espace d'AVP 32 bits bien plus vaste, découverte de pairs, gestion d'erreurs plus riche et sécurité renforcée — avec un tableau comparatif et des notes de migration.
- Mobilité (HSS)
Diameter S6a/S6d : mobilité LTE vers le HSS
Comment la mobilité LTE et la gestion des abonnements transitent par Diameter S6a (MME↔HSS) et S6d (SGSN↔HSS) selon 3GPP TS 29.272 : ULR/ULA, AIR/AIA, CLR/CLA, PUR/PUA et IDR/IDA, vecteurs d'authentification EPS-AKA, et les opérations SS7 MAP qu'ils remplacent.
- Politique et taxation
Diameter Gx et Gy : contrôle de la politique et de la taxation
Comment Diameter transporte le contrôle de la politique et de la taxation : Gx (PCEF↔PCRF, CCR/CCA installant les règles PCC), Gy (taxation en ligne vers l'OCS avec quota) et Rf (taxation hors ligne vers le CDF) — plus les rôles PCRF/PCEF/OCS/OFCS, la QoS/QCI et les interfaces Sy/Sd.
- IMS
Diameter Cx/Dx et Sh : enregistrement IMS et le HSS
Comment l'enregistrement et l'authentification IMS transitent par Diameter Cx/Dx (S-CSCF/I-CSCF↔HSS) selon 3GPP TS 29.228/29.229 — UAR/UAA, MAR/MAA, SAR/SAA, LIR/LIA — plus l'interface Sh (AS↔HSS) et leur articulation avec le SIP REGISTER.
- Sécurité
Sécurité du roaming Diameter : DRA, DEA et la frontière IPX
Comment le routage Diameter et la sécurité d'interconnexion fonctionnent à la frontière du roaming : le Diameter Routing Agent (DRA) et le Diameter Edge Agent (DEA), le routage par realm, les classes de menaces FS.19 (divulgation d'information, suivi de localisation, fraude), le masquage de topologie et le filtrage d'AVP.
Canaux de messagerie
Les canaux de messagerie de la couche application que les entreprises utilisent pour envoyer des messages : RCS Business Messaging / MaaP, WhatsApp Business Cloud API, MMS (MM1 / MM4 / MM7), expéditeur vérifié et de marque, et orchestration de repli des canaux.
- RCS
RCS Business Messaging et la plateforme MaaP
Le fonctionnement du RCS Business Messaging : le GSMA Universal Profile (RCC.07), l'architecture Messaging-as-a-Platform (RCC.71), les agents vérifiés, la découverte de capacités, les flux MO/MT et les événements de facturation — et en quoi l'API agent RBM diffère d'un bind SMPP.
- WhatsApp
Plateforme WhatsApp Business : Cloud API et modèles
Le fonctionnement de la plateforme WhatsApp Business : Cloud API vs On-Premises API, messages modèles (HSM) vs messages de session, la fenêtre de service client de 24 heures, les catégories marketing/utility/authentication, les webhooks, les paliers de qualité des numéros et l'opt-in.
- MMS
Architecture MMS : les interfaces MM1, MM4 et MM7
Le fonctionnement du MMS selon 3GPP TS 23.140 et OMA MMS : le MMSC/serveur-relais, MM1 (combiné↔MMSC via WAP/HTTP), MM4 (MMSC↔MMSC via SMTP pour l'inter-opérateur), MM7 (VASP↔MMSC via SOAP/XML), le contenu MIME/SMIL, les limites de taille et le MMS A2P.
- Confiance et marque
Messagerie à émetteur vérifié et de marque
Comment les marques prouvent leur identité sur tous les canaux : RCS Verified Sender et agents professionnels vérifiés, enregistrement de sender ID GSMA et vérification de marque, et certificats VMC avec BIMI pour des logos vérifiés dans l'e-mail — les contrôles qui combattent l'usurpation et l'imitation.
- Matrice de décision
RCS vs SMS vs WhatsApp : une matrice de décision de canal
Une comparaison neutre du RCS, du SMS et de WhatsApp pour la messagerie professionnelle : fonctionnalités, portée et couverture, chiffrement de bout en bout, accusés de lecture et saisie, médias riches, modèles de coût, comportement de fallback et contraintes réglementaires — avec des conseils sur le choix du canal.
- Orchestration
Fallback de canal et orchestration omnicanale
Comment la remise omnicanale s'enchaîne entre les canaux : vérifications de capacité, fallback RCS→SMS et WhatsApp→SMS, routage au moindre coût ou à la meilleure expérience, règles de reprise et d'expiration, et une vue de rapport de remise unifiée qui réconcilie le statut sur tous les canaux.
- Interactif
Cartes enrichies et messagerie interactive
Les briques interactives du RCS et de WhatsApp : cartes enrichies et carrousels, réponses et actions suggérées, boutons de réponse rapide et sélecteurs de liste — avec des exemples de charges utiles JSON pour chaque plateforme, plus des conseils d'UX et d'accessibilité.
Numérotation et identité
La couche de numérotation et d'identité sous chaque message et appel : codes E.164 / MSISDN, MCC-MNC / PLMN, identité de l'abonné IMSI / IMEI, ENUM (E.164 → URI) et routage de la portabilité des numéros mobiles.
- Numérotation publique
La numérotation E.164 et le MSISDN expliqués
Comment fonctionne le plan de numérotation international ITU-T E.164 : indicatifs pays, code national de destination (NDC) et numéro d'abonné, la limite de 15 chiffres, la structure du MSISDN, et comment normaliser les numéros au format E.164 pour la messagerie A2P.
- Identité de réseau
Les codes MCC, MNC et PLMN expliqués (E.212)
Comment fonctionne le plan d'identification ITU-T E.212 : le Mobile Country Code (MCC) de 3 chiffres et le Mobile Network Code (MNC) de 2 à 3 chiffres qui se combinent en une identité PLMN, comment ils identifient le réseau nominal, les plages de test, et en quoi MCC-MNC diffère du NDC du MSISDN.
- Identité de l'abonné
IMSI, IMEI et identité de l'abonné expliqués
Les identités qui distinguent un abonné d'un appareil : l'IMSI (MCC+MNC+MSIN, E.212), l'IMEI (TAC+numéro de série), la clé d'authentification Ki, les identités temporaires TMSI/GUTI, la SIM/USIM/eSIM (eUICC), et comment le HLR fait correspondre le MSISDN à l'IMSI.
- Acheminement de numéros
ENUM : faire correspondre des numéros E.164 à des URI
Comment ENUM (IETF RFC 6116) fait correspondre des numéros de téléphone E.164 à des URI via le DNS : le domaine e164.arpa à chiffres inversés, les enregistrements NAPTR avec réécriture regexp, et la différence entre ENUM public (utilisateur) et privé (opérateur/infrastructure) pour l'acheminement SIP et VoIP.
- Acheminement de numéros
Portabilité des numéros mobiles et acheminement
Comment la portabilité des numéros mobiles (MNP) rompt le lien entre un numéro composé et son réseau nominal : numéros d'acheminement (RN), All-Call-Query vs Onward Routing, bases de données MNP et requêtes, et comment l'interrogation HLR/MNP guide l'acheminement au moindre coût et une délivraison fiable.
API HTTP et webhooks
La couche HTTP/ REST au-dessus des protocoles réseau : conception d’API de messagerie REST, livraison de webhooks et vérification de signature HMAC, statut/charges utiles entrantes, authentification et signature, idempotence, limitation de débit et erreurs problem+json — fondée sur des normes (RFC 9457, brouillons de l’IETF).
- Conception d'API
Conception d'API de messagerie REST : ressources, méthodes, codes de statut
Comment se modélise une API de messagerie REST fondée sur les standards : une collection de messages, la sémantique des méthodes HTTP et des codes de statut selon RFC 9110, l'envoi synchrone vs asynchrone (202 Accepted plus un callback de statut), la négociation de contenu et le versionnage par URL ou par en-tête — avec un tableau de compromis REST vs SMPP.
- Webhooks
Livraison et fiabilité des webhooks : reprises, ordre, dead-letter
L'architecture standard de webhook/callback et son modèle de fiabilité : livraison at-least-once, backoff exponentiel avec jitter sur les reprises, délais d'expiration de livraison, garanties d'ordre, files de dead-letter, consommateurs idempotents et santé d'endpoint / coupe-circuit pour protéger un récepteur défaillant.
- Sécurité
Vérification de signature des webhooks : HMAC-SHA256 et protection contre le rejeu
Comment vérifier qu'un webhook est authentique et non altéré : HMAC-SHA256 sur le corps brut, les en-têtes de signature et de timestamp, la protection contre le rejeu avec une tolérance de timestamp et un nonce, la comparaison en temps constant pour déjouer les attaques temporelles, et la rotation sûre des secrets avec chevauchement des clés.
- Webhooks
Statut de message (DLR) et charges utiles des webhooks entrants (MO)
Les schémas de charge utile des deux callbacks de messagerie fondamentaux : l'événement de statut de livraison (DLR) avec son id de message, son énumération de statut, sa raison d'erreur et ses timestamps, et l'événement de message entrant (MO) — plus une taxonomie de types d'événements et comment un DLR HTTP se projette sur un accusé deliver_sm SMPP.
- Sécurité
Authentification et signature de requête d'API : tokens, HMAC, OAuth, mTLS
Les manières standard d'authentifier une API de messagerie HTTP : bearer tokens et clés d'API dans l'en-tête Authorization, signature de requête HMAC sur une requête canonique, cadrage et rotation des clés, TLS mutuel, et OAuth 2.0 client-credentials pour l'accès machine à machine.
- Fiabilité
Idempotence et limitation de débit : clés, 429, Retry-After, RateLimit
Deux motifs HTTP en voie de standardisation pour des clients sûrs et bien élevés : l'en-tête Idempotency-Key (draft IETF) pour une soumission exactly-once avec fenêtre de déduplication et rejeu de réponse, et la limitation de débit — 429 avec Retry-After, les en-têtes RateLimit / RateLimit-Policy (draft IETF), les token buckets et la contre-pression côté client.
- Conception d'API
Erreurs d'API (problem+json) et pagination (cursor, en-tête Link)
Deux standards qui gardent une API HTTP prévisible : RFC 9457 problem+json pour des erreurs lisibles par machine (type, title, status, detail, instance) avec une taxonomie rejouable vs terminal, et la pagination — cursor vs offset, l'en-tête Link de RFC 8288 pour next/prev, et les limites de taille de page.
De la spécification au câblage.
Ces références décrivent les protocoles que BroadNet exploite en qualité opérateur depuis 2003, dans 200+ pays et via 1 000+ connexions d'opérateurs. Lorsque vous serez prêt à envoyer des données, les documents et outils ci-dessous vous guideront de la lecture à l'expédition.