SMPP - Protokol Pesan Singkat Peer-to-Peer

Halo! Meskipun pesan instan dan jejaring sosial menggantikan metode komunikasi tradisional setiap hari, hal ini tidak mengurangi popularitas SMS. Verifikasi di situs populer, atau notifikasi transaksi berulang hidup dan akan hidup. Pernahkah Anda memikirkan cara kerjanya? Sangat sering, protokol SMPP digunakan untuk mengirim pesan massal, yang akan dibahas di bawah ini.

HabrΓ© sudah mempunyai artikel tentang smpp, 1,2, namun tujuannya bukan untuk mendeskripsikan protokol itu sendiri. Tentu saja, Anda dapat langsung memulai dari sumbernya - spesifikasi, tapi menurut saya alangkah baiknya jika ada rangkuman isinya. Saya akan menjelaskan menggunakan v3.4 sebagai contoh, saya senang atas kritik obyektif Anda.

Protokol SMPP adalah protokol pengiriman pesan peer-to-peer. Ini berarti bahwa setiap server peer/hub adalah sama. Dalam kasus paling sederhana, skema pesan SMS terlihat seperti ini:

SMPP - Protokol Pesan Singkat Peer-to-Peer

Namun, jika operator nasional tidak memiliki rute, ia meminta perantara ke suatu daerah terpencil - hub SMS. Terkadang, untuk mengirim satu SMS, Anda perlu membangun jaringan antara beberapa negara, atau bahkan benua.

Tentang protokol

SMPP adalah protokol lapisan aplikasi yang didasarkan pada pertukaran PDU dan ditransmisikan melalui TCP/IP, atau sesi X25 untuk mengirim pesan sms dan ussd. Biasanya SMPP digunakan dalam mode koneksi persisten, sehingga menghemat waktu. SMPP menggunakan model komunikasi client-server.

Π΅

SMPP - Protokol Pesan Singkat Peer-to-Peer

Pertukaran pesan antara pengirim dan pusat SMS melalui SMPP dapat dilakukan dengan cara sebagai berikut:

Pemancar (transmitter) - transmisi pesan dalam satu arah, secara bergantian
Penerima (receiver) - hanya menerima pesan dari pusat SMS.
Transreceiver (transceiver) - Pertukaran pesan antara pusat SMS dan pengguna

Struktur

SMPP - Protokol Pesan Singkat Peer-to-Peer

Panjang pesan

Satu pesan SMS dapat berisi 70 karakter saat mengetik dalam Cyrillic dan tidak lebih dari 157 karakter Latin + 3 UDH Jika Anda mengirim SMS dengan jumlah karakter yang banyak, maka akan dibagi menjadi beberapa segmen dan digabungkan di perangkat penerima. Dalam kasus segmentasi, jumlah karakter dikurangi dengan header pesan, yang menunjukkan bagian dari pesan. Oleh karena itu, saat mengirim pesan SMS berukuran besar, maksimal berisi 153 karakter Latin atau 67 karakter non-tipikal.

Skema Pengkodean Data

Namun, karakter perlu dikodekan untuk menyampaikan pesan. Dalam protokol SMPP, bidang khusus bertanggung jawab untuk pengkodean - Skema Pengkodean Data, atau DCS. Ini adalah bidang yang menentukan bagaimana pesan harus dikenali. Selain itu, bidang DCS meliputi:

  • kumpulan karakter yang mendefinisikan pengkodean;
  • kelas pesan;
  • permintaan penghapusan otomatis setelah membaca;
  • indikasi kompresi pesan;
  • bahasa pesan siaran;

Alfabet standar 7-bit (GSM 03.38). Ini dikembangkan untuk sistem pesan di GSM. Pengkodean ini cocok untuk bahasa Inggris dan sejumlah bahasa Latin. Setiap karakter terdiri dari 7 bit dan dikodekan menjadi oktet.

UTF-16 (dalam GSM UCS2) Untuk memasukkan karakter yang hilang dalam alfabet 7-bit, pengkodean UTF-16 dikembangkan, yang menambahkan karakter tambahan (termasuk karakter Cyrillic) dengan mengurangi ukuran pesan dari 160 menjadi 70, jenis pengkodean ini hampir sepenuhnya mengulangi Unicode.

Data yang ditentukan pengguna 8-bit. Ini termasuk KOI8-R dan Windows-1251. Meskipun solusi ini nampaknya lebih ekonomis dibandingkan dengan UTF-16 yang sama. Ada pertanyaan yang masuk akal tentang kompatibilitas pada perangkat yang berbeda. Karena dalam hal ini kedua perangkat harus dikonfigurasi terlebih dahulu.

Kelas pesan

  • Class0, atau flash, pesan yang disimpan dalam memori telepon atas permintaan pengguna;
  • Class1, atau yang tersimpan di memori telepon;
  • Class1, atau yang tersimpan di memori telepon;
  • Kelas2, harus memastikan bahwa pesan disimpan dalam memori terminal seluler, jika tidak, harus memberikan pemberitahuan ke pusat SMS tentang ketidakmungkinan penyimpanan;
  • Kelas3 - dalam hal ini, telepon harus mengirimkan pemberitahuan bahwa pesan dapat disimpan, berapa pun jumlah memori di perangkat. Jenis pesan ini menyiratkan bahwa pesan tersebut telah mencapai tujuannya;

Jenis pesan

Pesan senyap (SMS0) Jenis pesan SMS tanpa isi. SMS tersebut datang tanpa pemberitahuan dan tidak ditampilkan di layar perangkat.

PDU

Setiap operasi pdu dipasangkan dan terdiri dari permintaan dan respons. Misalnya: perintah yang menyatakan koneksi telah dibuat (bind_transmitter/bind_transmitter_resp), atau pesan telah terkirim (deliver_sm/deliver_sm_resp)

SMPP - Protokol Pesan Singkat Peer-to-Peer

Setiap paket pdu terdiri dari dua bagian - header (header) dan body (badan). Struktur headernya sama untuk semua paket pdu: panjang perintah adalah panjang paket, id adalah nama paket, dan perintah status menunjukkan apakah pesan berhasil dikirim atau gagal.

Parameter TLV tambahan

TLV (Nilai Panjang Tag), atau kolom tambahan. Parameter tersebut digunakan untuk memperluas fungsionalitas protokol dan bersifat opsional. Bidang ini ditentukan di akhir bidang pdu. Sebagai contoh, dengan menggunakan TLV dest_addr_np_information, Anda dapat mengatur transfer informasi tentang porting nomor tersebut.

Ton dan Npi

Parameter TON (Jenis Nomor) menginformasikan SMSC tentang format pengalamatan dan jenis jaringan.
Parameter NPI (Numbering Plan Identification) yang menunjukkan rencana penomoran.

SMPP - Protokol Pesan Singkat Peer-to-Peer

Alamat sumber pesan, atau nama alfa

Pesan yang dikirim ke telepon tersedia dalam dua jenis: numerik dan alfabet. Nomor bisa panjang (mirip dengan nomor telepon) atau pendek. Terkadang operator memiliki batasan pengiriman dari nama netral, seperti Infosms, Alert dll. Terkadang operator tidak mengizinkan lalu lintas jika nama tersebut tidak terdaftar di jaringan mereka. Namun, ini lebih merupakan fitur operator.

Tahapan penyerahan

SMPP - Protokol Pesan Singkat Peer-to-Peer

SMS-KIRIM sedang mengirim pesan MO FSM (pesan singkat dari terminal seluler)
LAPORAN KIRIM SMS β€” konfirmasi bahwa pesan telah dikirim melalui SMSC
SRISM (SendRoutingInfo) - SMSC menerima informasi dari HLR mengenai lokasi MSC/VLR pelanggan
SRI SM RESP β€” tanggapan dari HLR mengenai posisi pelanggan daging
MT-FSM - setelah menerima lokasi, pesan dikirim menggunakan operasi "Teruskan Pesan Singkat".
MT-FSM-ACK β€” respon dari SMSC bahwa pesan telah terkirim
LAPORAN STATUS SMS β€” SMSC mengirimkan status pengiriman pesan.

Status pengiriman pesan

LAPORAN STATUS SMS dapat mengambil beberapa nilai:
PENGIRIMAN pesan berhasil terkirim
DITOLAK β€” pesan ditolak oleh pusat SMS
Kedaluwarsa - pesan dihapus dari antrian pengiriman setelah akhir TTL (masa pakai pesan)
UNDELIV - kasus tidak terkirim lainnya
UNKNOWN- Tidak ada tanggapan yang diterima.

Kesalahan transmisi

Terkadang alasan pesan SMS tidak terkirim ke pelanggan. Akibat dari alasan tersebut adalah terjadinya kesalahan. Kesalahan dikembalikan dalam PDUs_sms_resp. Semua kesalahan dapat dibagi menjadi sementara (Temporary) dan permanen (Permanent).

Sebagai contoh, absen_subscriber bersifat sementara, pelanggan tidak tersedia atau tidak online, dan permanen - pelanggan tidak ada. Tergantung pada kesalahan yang terjadi, kebijakan untuk mengirim ulang pesan-pesan ini dibentuk.

Misalnya, jika pelanggan sedang sibuk berbicara dan menerima kesalahan handset MT sedang sibuk, pesan dapat dikirim ulang setelah beberapa menit, namun, jika pelanggan telah memblokir layanan penerimaan pesan, pengiriman ulang tidak masuk akal. Anda dapat menemukan daftar kesalahan di halaman SMSC, misalnya sebagai ini.

Sumber: www.habr.com

Tambah komentar