Specyfikacja techniczna SMPP
Poznaj specyfikację techniczną rozwiązania SMPP OVHcloud
Wprowadzenie
Poznaj specyfikację techniczną rozwiązania SMPP OVHcloud.
Glosariusz
- PDU: Protocol Data Unit to obiekt/jednostka służąca do wymiany żądań i odpowiedzi
- SMPP: Short Message Peer to Peer Protocol
- SMSC: Short Message Service Centre (serwer)
- ESME: External Short Message Entity (klient)
- UDH: User Data Header
- SM: Short Message
- DLR: Delivery Receipt
- PTT: Premium Tracking Technical to kod błędu przekazywany w treści DLR
- MT: Mobile Terminated
- MO: Mobile Originated
Aby uzyskać więcej informacji na temat skrótów, zapoznaj się ze stroną 10 specyfikacji SMPP serwisu smpp.org.
Prezentacja
Do czego służy SMPP?
SMPP (Short Message Peer-to-Peer) to protokół umożliwiający wymianę wiadomości SMS z operatorami telefonicznymi oraz przez dostawców treści. Zazwyczaj wykorzystuje dwa połączenia TCP/IP: jedno do wysyłania, drugie do odbierania danych.
Jakie są korzyści z SMPP w porównaniu ze standardową ofertą SMS?
- Protokół jest ustandaryzowany i umożliwia integrację z wieloma narzędziami dostępnymi na rynku
- Zapewnia wysoką przepustowość przy niskim opóźnieniu
Jak wygląda typowe zastosowanie wysyłania SMS przez SMPP?
Aplikacja klienta do wysyłania SMS (ESME) ma trzy sposoby komunikacji z SMSC:
- Transmitter: wysyłanie wiadomości
- Receiver: odbieranie wiadomości
- Transceiver: wysyłanie i odbieranie wiadomości
Więcej informacji o sposobach komunikacji znajdziesz w rozdziale Lista PDU.
Po nawiązaniu połączenia między ESME a SMSC OVHcloud można wysyłać i/lub odbierać wiadomości.
Uwierzytelnianie połączenia z SMSC odbywa się za pomocą system_id (identyfikator), password oraz adresu IP Twojej aplikacji.
Rozwiązanie SMPP OVHcloud umożliwia:
- Wysyłanie wiadomości SMS z potwierdzeniem odbioru (DLR) lub bez niego
- Odbieranie wiadomości wysłanej z telefonu komórkowego
Numer wirtualny*: wyłącznie kanał transakcyjny
Specyfikacja techniczna
Opis protokołów
Bind Request
ESME może połączyć się w jednym z trzech trybów: Transmitter, Receiver, Transceiver.
Te żądania połączenia są obsługiwane zgodnie ze specyfikacją protokołu SMPP v3.4.
Bind Response
Podczas procesu logowania ESME wysyła żądanie Bind, podając system_id (identyfikator) oraz swoje password.
Te informacje, wraz z IP Twojej aplikacji, służą do uwierzytelnienia żądania połączenia.
Następnie SMSC wysyła odpowiedź ze statusem określającym, czy uwierzytelnianie powiodło się, czy nie.
Lista PDU
bind_transceiver i bind_transceiver_resp
Ten typ bind służy do zainicjowania połączenia umożliwiającego dwukierunkową komunikację między SMSC a ESME (jest to połączenie trybów transmitter i receiver).
bind_transmitter i bind_transmitter_resp
Ten typ bind służy do zainicjowania połączenia umożliwiającego wyłącznie komunikację z ESME do SMSC (wysyłanie SMS na telefon komórkowy). SMSC wysyła odpowiedzi powiązane z żądaniami PDU za pośrednictwem tego samego połączenia.
bind_receiver i bind_receiver_resp
Ten typ bind służy do zainicjowania połączenia umożliwiającego wyłącznie komunikację z SMSC do ESME (wysyłanie potwierdzenia odbioru (DLR) lub wiadomości wysłanych z telefonu komórkowego). ESME wysyła odpowiedzi powiązane z żądaniami PDU za pośrednictwem tego samego połączenia.
unbind i unbind_resp
Żądanie zamknięcia połączenia inicjowane przez SMSC lub ESME. Strona otrzymująca żądanie odsyła odpowiedź, gdy jest gotowa do przerwania połączenia.
SMSC OVHcloud zamyka (unbind) połączenia co 24 godziny; ESME musi połączyć się ponownie automatycznie.
outbind
Nieobsługiwany
submit_sm i submit_sm_resp
submit_sm jest używany przez ESME do przesłania SMS do SMSC w celu przekazania go na numer telefonu komórkowego.
Parametry obowiązkowe:
source_addrmoże być numerem międzynarodowym, numerem alfanumerycznym lub numerem shortcode:- alfanumeryczny: te numery telefonu składają się z liter i cyfr (np. ovh123).
source_addr_ton= 5source_addr_npi= 0
- shortcode: te numery telefonu zawierają od 3 do 8 cyfr (np. 38069). Shortcode służy jedynie do poinformowania naszej usługi, że będziemy musieli go użyć. Rzeczywisty shortcode użyty do wysłania SMS zostanie określony przez operatora telekomunikacyjnego.
source_addr_ton= 3source_addr_npi= 1
- międzynarodowy: te numery telefonu składają się z identyfikatora kraju i zwykłego numeru bez początkowego 0 (na przykład 33601020304).
source_addr_ton= 1source_addr_npi= 1
- alfanumeryczny: te numery telefonu składają się z liter i cyfr (np. ovh123).
destination_addrmusi być numerem międzynarodowym (np. 33600000001)dest_addr_ton= 1dest_addr_npi= 1
Parametry opcjonalne:
submit_sm_resp jest potwierdzeniem prawidłowego odebrania submit_sm przez SMSC.
Zawiera message_id, który jest identyfikatorem wiadomości SMSC umożliwiającym powiązanie z potwierdzeniem odbioru (DLR) wysłanym później, gdy telefon komórkowy odebrał SMS (pod warunkiem że żądanie DLR zostało określone w submit_sm).
deliver_sm i deliver_sm_resp
deliver_sm jest wysyłany przez SMSC w celu przesłania potwierdzenia odbioru (DLR) do ESME, jeśli ten zażądał go w submit_sm, lub w przypadku wiadomości przychodzącej (odpowiedź na shortcode lub SMS wysłany na numer wirtualny).
Parametry obowiązkowe:
Parametry opcjonalne:
Parametry specyficzne dla OVHcloud:
Nasza usługa próbuje wysyłać deliver_sm do ESME przez maksymalnie 7 dni.
Kody błędów potwierdzeń odbioru (DLR)
enquire_link i enquire_link_resp
PDU używany przez SMSC i ESME do sprawdzenia, czy połączenie jest nadal aktywne.
Zaleca się zachowanie 30-sekundowego odstępu między poszczególnymi żądaniami.
generic_nack
PDU zwracany przez SMSC, gdy PDU jest nieobsługiwany lub uszkodzony.
query_sm i query_sm_resp
Nieobsługiwane.
cancel_sm i cancel_sm_resp
Nieobsługiwane.
replace_sm i replace_sm_resp
Nieobsługiwane.
alert_notification
Nieobsługiwany.
submit_multi i submit_multi_resp
Nieobsługiwane.
data_sm i data_sm_resp
Nieobsługiwane.
Statusy PDU odpowiedzi
Każdy PDU odpowiedzi (te kończące się na _resp) ma status. Specyfikacja SMPP zawiera listę ogólnych statusów (SMPP 3.4, 5.1.3 command_status) wspólnych dla wszystkich SMSC.
Określony zakres statusów jest zarezerwowany dla SMSC. Oto te używane przez OVHcloud:
Data Coding Scheme
Data coding jest używany przez submit_sm i deliver_sm do kodowania wiadomości.
Lista obsługiwanych data coding:
- GSM 03.38 (GSM 7 bits)*
- UCS2
GSM 03.38*: to kodowanie reprezentuje każdy znak za pomocą septetu, ale niektóre klienty SMPP reprezentują go za pomocą oktetu. Ponieważ format oktetowy jest najczęściej używany, Twoje konto SMPP jest domyślnie skonfigurowane na ten format. Jeśli napotkasz problemy z kodowaniem w swoim kliencie SMPP, skontaktuj się z pomocą techniczną OVHcloud, aby zmienić format.
TLV
TLV (Tag, Length, Value) umożliwia wzbogacenie PDU o dodatkowe, opcjonalne informacje. Niektóre są wspólne i używane przez wiele SMSC, a inne mogą być bardziej specyficzne dla OVHcloud.
System identyfikacji
System ID
system_id to identyfikator połączenia SMPP; jest generowany w postaci losowego ciągu znaków.
Password
Password jest generowane i dostarczane przy każdym utworzeniu konta SMPP.
Lista autoryzowanych adresów IP
Lista adresów IP jest wymagana, aby autoryzować maszynę lub maszyny do łączenia się z SMSC.
Typ połączenia
- Połączenie zabezpieczone: połączenie szyfrowane za pomocą co najmniej TLS 1.3.
- Połączenie niezabezpieczone: połączenie, które nie korzysta z szyfrowania TLS ze względu na potrzeby wstecznej kompatybilności (wszystkie wymiany odbywają się w postaci jawnej i są w związku z tym widoczne dla osób trzecich).
Limity wysyłania
Połączenie na strefę
Domyślnie konto SMPP może mieć tylko jedną parę Transmitter/Receiver lub jeden Transceiver na strefę.
Windowing
Domyślnie konto SMPP może przetwarzać maksymalnie 10 wiadomości jednocześnie.
Przepustowość
Domyślnie konto SMPP może przetwarzać maksymalnie 20 wiadomości na sekundę na połączenie.
Wersja protokołu
Wersja protokołu to 3.4.
Lista klientów SMPP przetestowanych przez OVHcloud
- Kannel 1.4.5
Sprawdź również
Dołącz do grona naszych użytkowników.