Anatomi delivery receipt SMPP
Saat Anda mengirim SMS dengan registered_delivery diatur ke 1, SMSC nantinya mengirim PDU deliver_sm kembali melalui bind receiver atau transceiver. Bit 0x04 pada esm_class menandainya sebagai delivery receipt, bukan pesan masuk, dan short_message-nya berisi receipt dalam bentuk teks. Lampiran B spesifikasi SMPP v3.4 memberikan format ini sebagai contoh, dan hampir semua SMSC mengikutinya: id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:E text:….
Karena Lampiran B hanya contoh dan bukan aturan yang ketat, receipt di lapangan bervariasi: key huruf kecil, spasi tambahan, submit_date dengan garis bawah, tanggal 12 digit dengan detik, atau text yang hilang. Decoder ini menerima semua variasi tersebut dan memberi tahu Anda field mana yang tidak ada.
- id: ID pesan yang dikembalikan SMSC dalam submit_sm_resp. Gunakan untuk mencocokkan receipt dengan pesan Anda. Contoh di spesifikasi menunjukkan 10 karakter, tetapi banyak SMSC memakai ID yang lebih panjang, kadang dalam format hex.
- sub dan dlvrd: jumlah pesan yang awalnya dikirim dan yang terkirim, dalam 3 digit. Field ini terutama relevan untuk distribution list; untuk satu SMS biasanya bernilai 001 dan 001 (atau 000).
- submit date dan done date: waktu pesan dikirim dan waktu pesan mencapai status akhirnya, menurut jam SMSC.
- stat: status akhir atau status sementara, berupa kode 7 huruf seperti DELIVRD.
- err: kode error 3 karakter, spesifik untuk jaringan atau SMSC; 000 berarti tidak ada error.
- text: 20 karakter pertama dari pesan asli, sering terpotong atau kosong.
- TLV opsional dapat mengulang data ini dalam bentuk yang lebih rapi: receipted_message_id (0x001E), message_state (0x0427), dan network_error_code (0x0423).
Kode stat DLR dan artinya
SMPP v3.4 mendefinisikan delapan status pesan. ENROUTE dan ACCEPTD bersifat sementara; sisanya final. API kami menormalkan setiap kanal ke enam status webhook (SUBMITTED, SENT, DELIVERED, READ, FAILED, REJECTED), dan decoder menampilkan padanan terdekat untuk setiap nilai stat. Anggap pemetaan ini sebagai indikasi: aturan pastinya untuk akun Anda dikonfirmasi saat onboarding (aktivasi akun).
- DELIVRD (message_state 2): terkirim ke handset. Status webhook terdekat: DELIVERED.
- ACCEPTD (6): secara formal berarti 'dibaca secara manual atas nama pelanggan oleh layanan pelanggan', tetapi sebagian besar SMSC mengirimnya sebagai receipt sementara 'diterima oleh jaringan'. Terdekat: SENT.
- ENROUTE (1): masih dalam perjalanan, misalnya antre untuk dicoba ulang. Terdekat: SENT.
- UNDELIV (5): tidak dapat dikirim, misalnya karena nomor tidak valid atau tidak aktif. Terdekat: FAILED.
- EXPIRED (3): masa berlaku pesan habis sebelum handset dapat dijangkau, sering karena handset mati atau di luar jangkauan sinyal. Terdekat: FAILED.
- DELETED (4): dihapus sebelum terkirim, misalnya melalui cancel_sm. Terdekat: FAILED.
- REJECTD (8): ditolak oleh jaringan atau firewall, misalnya karena Sender ID belum terdaftar atau konten diblokir. Terdekat: REJECTED.
- UNKNOWN (7): SMSC tidak memiliki status akhir. Anggap sebagai belum terkonfirmasi, bukan kegagalan yang terbukti.
Kode err: mengapa tidak ada daftar universal
Field err lebarnya tiga karakter dan spesifikasi SMPP tidak mendefinisikan nilainya. 000 selalu berarti tidak ada error, tetapi nilai selain nol berasal dari vendor SMSC, operator, atau agregator di antaranya. Sebagian SMSC meneruskan penyebab error GSM MAP (misalnya, MAP error 1 berarti unknown subscriber dan 27 berarti absent subscriber), sementara yang lain memetakan semuanya ke tabel milik mereka sendiri.
Jika receipt membawa TLV network_error_code (0x0423), TLV ini lebih andal: oktet pertamanya menunjukkan jenis jaringan (3 berarti GSM) dan dua oktet berikutnya berisi kode error. Receipt DELIVRD dengan err selain nol itu tidak konsisten dan perlu ditanyakan ke provider Anda; decoder akan menandainya.
command_status error versus delivery receipt
SMPP melaporkan masalah pada dua momen. command_status dalam submit_sm_resp tiba dalam hitungan milidetik dan menyatakan apakah SMSC menerima permintaan Anda; 0x00000000 (ESME_ROK) berarti diterima, bukan terkirim. Delivery receipt tiba beberapa detik hingga beberapa hari kemudian dan membawa hasil akhirnya.
Nilai command_status didefinisikan di bagian 5.1.3 SMPP v3.4. Yang paling umum di produksi adalah 0x00000058 ESME_RTHROTTLED (Anda melampaui jumlah pesan per detik yang disepakati: perlambat dan coba lagi dengan exponential backoff), 0x00000014 ESME_RMSGQFUL (antrean penuh: kurangi kecepatan), 0x0000000A dan 0x0000000B (alamat pengirim atau tujuan tidak valid), serta 0x0000000D atau 0x0000000E (bind gagal atau password salah). Nilai 0x00000400 sampai 0x000004FF dicadangkan untuk error spesifik vendor SMSC, jadi tanyakan hal itu kepada provider Anda.
Tanggal, zona waktu, dan latensi pengiriman
Tanggal pada receipt memakai format YYMMDDhhmm, dan banyak SMSC menambahkan detik (YYMMDDhhmmss). Receipt tidak membawa zona waktu: waktunya mengikuti jam SMSC, biasanya UTC. Decoder menampilkan tanggal persis seperti yang tertulis dan menghitung latensi sebagai done date dikurangi submit date, yang tidak terpengaruh zona waktu selama keduanya berasal dari jam yang sama.
Latensi adalah sinyal kualitas yang berguna. Trafik OTP yang sehat ke handset yang dapat dijangkau biasanya selesai dalam hitungan detik. Latensi panjang yang diikuti EXPIRED menunjukkan handset yang mati atau sedang roaming, dan done date yang lebih awal dari submit date berarti kedua jam tidak sinkron. Tanggal tingkat menit tidak dapat mengukur latensi di bawah satu menit, jadi pilih SMSC yang mengirim detik.
Menangani receipt secara andal di produksi
Balas setiap deliver_sm dengan deliver_sm_resp, bahkan jika pemrosesan Anda gagal. Jika tidak, SMSC akan mengirim ulang dan dapat membatasi (throttle) bind Anda. Simpan receipt mentah, lalu proses secara asinkron dan idempoten berdasarkan ID pesan, karena receipt bisa tiba dua kali atau tidak berurutan: ENROUTE yang terlambat tidak boleh menimpa DELIVRD.
Jika Anda tidak ingin mem-parsing receipt sama sekali, REST SMS API kami menyampaikan informasi yang sama sebagai status webhook yang sudah dinormalkan, dan receipt yang terlewat dapat dikirim ulang dengan POST /sms/resendDlr. Bind SMPP melalui TLS tersedia untuk pengirim bervolume tinggi dan reseller.