---
title: "Decoder laporan pengiriman SMS (DLR)"
description: "Decode DLR SMPP: kode stat seperti DELIVRD dan UNDELIV, err, tanggal submit dan done, latensi, serta error command_status. Gratis, langsung di browser."
canonical: "https://omnichannels.ai/id/tools/sms-delivery-report-decoder/"
language: "id"
updated: "2026-10-10"
publisher: "BroadNet Technologies"
brand: "OmniChannels.ai"
---

# Decoder laporan pengiriman SMS (DLR)

Canonical: https://omnichannels.ai/id/tools/sms-delivery-report-decoder/
Language: id
Publisher: OmniChannels.ai by BroadNet Technologies

Laporan pengiriman (DLR) SMPP adalah tanda terima yang dikirim balik oleh SMSC dalam PDU deliver_sm setelah Anda mengirim SMS. Teksnya mengikuti pola id, sub, dlvrd, submit date, done date, stat, err, dan text. Field stat berisi hasil pengiriman: DELIVRD berarti terkirim ke handset; UNDELIV, EXPIRED, DELETED, dan REJECTD adalah kegagalan final; ENROUTE dan ACCEPTD bersifat sementara. Format tanggalnya YYMMDDhhmm, kadang disertai detik.

## Cara men-decode delivery receipt SMS
1. **Salin teks receipt:** Ambil short_message dari PDU deliver_sm di klien SMPP atau log SMSC Anda, misalnya id:… sub:001 dlvrd:001 … stat:DELIVRD err:000. Awalan log akan diabaikan.
2. **Tempel satu receipt per baris:** Tempel satu receipt atau ratusan sekaligus. Anda juga bisa menempel nilai command_status seperti 0x00000058 atau ESME_RTHROTTLED pada barisnya sendiri.
3. **Baca field yang sudah di-decode:** Setiap receipt menampilkan arti status, apakah status itu final, status webhook terdekat, tanggal yang mudah dibaca, latensi pengiriman, serta peringatan untuk field yang hilang atau tidak konsisten.
4. **Periksa ringkasan batch:** Lihat jumlah per stat dan per status webhook, tingkat pengiriman, dan median latensi, lalu salin semuanya sebagai JSON untuk tiket atau test fixture.

## 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.

## Pertanyaan seputar laporan pengiriman

### Apa arti stat:DELIVRD dalam laporan pengiriman SMS?

DELIVRD adalah status pesan SMPP 'delivered': SMSC memiliki konfirmasi bahwa pesan sudah sampai di handset penerima. Ini tidak berarti pesan dibuka atau dibaca; SMS biasa tidak memiliki tanda baca. Di webhook kami, status ini sesuai dengan DELIVERED.

### Apa perbedaan antara UNDELIV, EXPIRED, dan REJECTD?

UNDELIV berarti jaringan tidak dapat mengirim pesan, misalnya karena nomor tidak valid atau tidak aktif. EXPIRED berarti upaya pengiriman berlanjut hingga masa berlaku habis, biasanya karena ponsel mati atau di luar jangkauan sinyal. REJECTD berarti jaringan atau firewall menolak pesan, misalnya karena Sender ID belum terdaftar atau konten diblokir.

### Apa arti ACCEPTD dalam DLR SMPP?

Dalam spesifikasi SMPP v3.4, ACCEPTD berarti pesan dibaca secara manual atas nama pelanggan oleh layanan pelanggan. Dalam praktiknya, sebagian besar SMSC dan agregator memakainya sebagai receipt sementara yang berarti jaringan menerima pesan, lalu receipt DELIVRD final atau receipt kegagalan menyusul.

### Apa itu error SMPP 0x00000058?

0x00000058 adalah ESME_RTHROTTLED: Anda mengirim lebih banyak pesan per detik daripada yang diizinkan bind Anda. Sifatnya sementara. Kurangi kecepatan pengiriman, jaga jumlah PDU submit_sm yang belum dibalas pada batas yang wajar, dan kirim ulang pesan yang ditolak dengan exponential backoff, bukan langsung saat itu juga.

### Apa arti err:000, dan di mana saya bisa menemukan kode err lainnya?

err:000 berarti tidak ada error. Nilai err selain nol tidak didefinisikan oleh spesifikasi SMPP; nilai tersebut berasal dari vendor SMSC, operator, atau agregator, dan sebagian meneruskan penyebab error GSM MAP. Minta tabel error dari provider Anda, dan periksa TLV network_error_code jika ada.

### Format tanggal apa yang dipakai delivery receipt SMPP?

submit date dan done date memakai YYMMDDhhmm, misalnya 2610101201 untuk 10 Oktober 2026 pukul 12.01. Banyak SMSC menambahkan detik (YYMMDDhhmmss). Zona waktu tidak disertakan; waktunya mengikuti jam SMSC, biasanya UTC.

### Mengapa saya tidak menerima laporan pengiriman?

Penyebab yang umum adalah registered_delivery tidak diatur ke 1 di submit_sm, penggunaan bind transmitter saja tanpa bind receiver, jaringan tujuan yang tidak mengembalikan receipt, atau klien Anda tidak membalas deliver_sm. Beberapa jalur hanya mengembalikan receipt sementara. Untuk trafik REST, periksa endpoint webhook Anda dan kirim ulang receipt dengan /sms/resendDlr.

### Apakah teks receipt saya dikirim ke mana pun saat saya memakai alat ini?

Tidak. Decoder berjalan sepenuhnya di browser Anda. Tidak ada yang Anda tempel, termasuk ID pesan atau teks pesan, yang dikirim ke server kami.