Aplikacja może wysłać wiadomość, zanim telefon odbiorcy stanie się osiągalny. Połączenie SMPP przenosi tę wysyłkę i późniejsze operacje raportujące, co się wydarzyło.
Co przenosi połączenie?
SMPP przenosi wysyłki wiadomości, wiadomości przychodzące i raporty doręczenia między połączonymi systemami.
Twoja aplikacja może połączyć się z bramką, która kieruje ruch dalej. Może też połączyć się bezpośrednio z centrum wiadomości, jeśli dostawca obsługuje taką konfigurację.
Dokumentacja SMPP opisuje te role i operacje. Centrum wiadomości przechowuje wiadomości i przekazuje je do odbiorców.
Bramka między Twoją aplikacją a centrum dodaje kolejny krok routingu. Sama nazwa protokołu nie mówi, ile systemów obsługuje wiadomość.
Jak działa sesja SMPP?
Twój klient otwiera połączenie. Uwierzytelnia sesję i utrzymuje ją dostępną dla operacji na wiadomościach.
Krok uwierzytelniania nazywa się bind. Sesja nadawcza (transmitter) wysyła wiadomości. Sesja odbiorcza (receiver) je odbiera. Sesja dwukierunkowa (transceiver) obsługuje oba kierunki.
Użyj typu sesji wymaganego przez Twój przepływ pracy. Połączenie tylko do wysyłki nie zastąpi sesji odbiorczej, gdy potrzebujesz operacji przychodzących.
Twój klient musi odzyskiwać połączenie po jego zerwaniu. Musi też potwierdzać odbiór otrzymanych operacji. Śledź żądania oczekujące na odpowiedź, aby opóźniona odpowiedź została dopasowana do właściwego żądania.
Czy odpowiedź na wysyłkę dowodzi doręczenia?
Odpowiedź na wysyłkę informuje, czy podłączona usługa przyjęła wysyłkę, a nie czy telefon odebrał wiadomość.
Operacja submit_sm wysyła wiadomość. Odpowiadająca jej submit_sm_resp raportuje wynik tego żądania.
Wiadomości przychodzące i potwierdzenia doręczenia mogą docierać przez deliver_sm. Dokumentacja potwierdzeń doręczenia opisuje operacje potwierdzeń i ich zawartość.
Oddzielaj wynik wysyłki od wyniku doręczenia w swojej aplikacji. Wiadomość może zostać przyjęta, a później nie dotrzeć, ponieważ odbiorca pozostaje nieosiągalny.
Co się zmienia, gdy użyję HTTP API?
HTTP udostępnia operacje żądań i odpowiedzi bez konieczności zarządzania bindem SMPP przez Twoją aplikację.
Twoja aplikacja nadal musi obsługiwać ponawianie żądań. Musi też przetwarzać późniejsze wyniki doręczenia. HTTP nie zamienia asynchronicznego doręczenia operatora w synchroniczną gwarancję.
Z Bird wysyłasz przez POST /v1/sms/messages i śledzisz zwrócony identyfikator wiadomości. Przewodnik wysyłania opisuje odpowiedź akceptacji 202. Zdarzenia SMS dostarczają kolejne raporty doręczenia.
Te obowiązki API są oddzielone od zarządzania połączeniem SMPP z dostawcą. API i bramki opisuje poszczególne warstwy.
Czy użycie SMPP sprawia, że dostawcy są wymienni?
Dostawcy nie są wymienni tylko dlatego, że korzystają z tego samego protokołu. Mogą obsługiwać różne operacje, kodowania i limity.
Przetestuj funkcje, z których korzysta Twoja aplikacja, zanim przeniesiesz ruch. Udany bind nie oznacza, że każda wymagana operacja działa u tego dostawcy.
Dokumentacja bramek zaleca testowanie obsługi implementacji i wydajności. Zachowaj sprawdzanie doręczenia przy zmianie połączeń, zamiast traktować nowy endpoint jako pełną migrację.
Kiedy wybrać SMPP?
Wybierz SMPP, gdy istniejący system potrzebuje trwałego bindu lub operacji przychodzących specyficznych dla SMPP.
- Użyj HTTP dla nowej aplikacji bez konkretnego wymagania dotyczącego SMPP.
- Użyj SMPP, gdy istniejący system potrzebuje trwałego bindu lub operacji przychodzących specyficznych dla SMPP.
- Przetestuj obsługę dostawcy i wyniki doręczenia przed przeniesieniem ruchu produkcyjnego.
W skrócie
Twój klient zarządza sesją.
Uwierzytelnia połączenie i obsługuje odzyskiwanie po jego zerwaniu.
Wysyłka i doręczenie to różne operacje.
Pomyślna odpowiedź na wysyłkę nie oznacza, że telefon odbiorcy odebrał wiadomość.
Obsługa różni się między dostawcami.
Testuj operacje, kodowanie i wydajność, zamiast zakładać, że protokół sprawia, iż dostawcy są wymienni.
HTTP pozwala uniknąć zarządzania sesją SMPP.
HTTP eliminuje zarządzanie bindem SMPP, ale Twoja aplikacja nadal obsługuje zdarzenia doręczenia.