одтверждение доставки (DLR) — это сообщение о статусе, возвращаемое после отправки SMS, которое сообщает о его конечном состоянии — DELIVRD, UNDELIV, EXPIRED, DELETED, ACCEPTD, UNKNOWN или REJECTD — в соответствии с протоколом SMPP. Подлинное подтверждение доставки (DLR) поступает от оператора-получателя, а не от шлюза, поэтому оно сообщает, получил ли телефон сообщение и, через поле err, почему оно не было получено.
Что такое отчёт о доставке — и чем он не является.
В момент отправки сообщения вы получаете два разных сигнала, и их путаница является наиболее распространенной причиной фантомных сбоев. Первый — это подтверждение отправки: в SMPP SMSC возвращает submit_sm_resp с command_status ESME_ROK (0x00000000); в HTTP API вы получаете 202 и идентификатор сообщения. Это означает лишь то, что платформа приняла сообщение для обработки. Второй сигнал, который приходит позже, — это подтверждение доставки — внеполосный отчет о том, что сеть в конечном итоге сделала с сообщением. В SMPP он возвращается как PDU deliver_sm, чей esm_class помечает его как подтверждение доставки; в REST API он доставляется вашему веб-хуку. Настройте свою систему на основе DLR, а не ответа на отправку — см. руководство разработчика SMPP для флагов bind и receipt-request.
Подтверждение шлюза в сравнении с реальным оператором DLR
Не каждый DLR создается в одном и том же месте на линии связи, и именно здесь проявляется проблема качества маршрута. Реальный DLR на уровне оператора генерируется конечной сетью после того, как телефон подтверждает короткое сообщение на уровне SS7/MAP или Diameter; оператор SMSC преобразует этот отчет сетевого уровня в полученное вами подтверждение SMPP. Промежуточный или шлюзовой DLR, напротив, синтезируется агрегатором при передаче сообщения следующему узлу — до того, как конечный оператор что-либо подтвердит. На чистом прямом маршруте эти два типа DLR совпадают; на сером маршруте — нет.
Вот почему «поддельные DLR» опасны. Агрегатор «серых» маршрутов, не способный получить подлинное подтверждение от оператора, часто подделывает DELIVRD при передаче, чтобы его панели мониторинга выглядели исправными — даже если сообщение было незаметно отброшено, отфильтровано или завершено SIM-боксом. Признаком является подозрительно высокий процент доставки в сочетании с реальными пользователями, которые никогда не получали сообщение, или маршрут, который возвращает UNKNOWN в пакетном режиме (у SMSC нет действительного состояния, потому что нижестоящий узел никогда не возвращал реальный отчет). Вставьте любую строку подтверждения в декодер DLR, чтобы увидеть, что именно утверждает маршрут, и как выглядит подлинное подтверждение от оператора.
Как DLR-каналы возвращаются к вам
Существует два транспортных протокола и один базовый источник. При использовании SMPP получение возвращается асинхронно в виде PDU deliver_sm в привязанной сессии, при этом конечное состояние передается в теле short_message (классическая строка id:… stat:… err:…) и, в версиях 5.0 и многих версиях 3.4, в TLV message_state и network_error_code. При использовании HTTP API та же информация отправляется POST-запросом на зарегистрированный вами веб-хук, обычно в формате JSON. В конечном итоге, оба протокола формируются на основе собственного отчета о состоянии сети: стандарт 3GPP TS 23.040 определяет SMS-STATUS-REPORT и его поле TP-Status, которое завершающий SMSC преобразует в состояние сообщения SMPP, которое вы читаете. Уровень SMPP является надежным носителем отчета, который фактически формируется в мобильной сети.
Вне зависимости от способа транспортировки, регистрируйте одни и те же поля во всех отчётах о доставке, чтобы можно было проводить диагностику по закономерностям, а не на основе отдельных случаев:
- Идентификатор сообщения, чтобы вы могли связать DLR с исходным submit_sm.
- Значение stat (итоговое состояние сообщения) и значение err (код ошибки сети/оператора).
- Оператор назначения (MCC/MNC), идентификатор отправителя и используемый маршрут или привязка.
- Отметки времени отправки и завершения позволяют измерить сквозную задержку и выявить случаи истечения срока действия.
id:1a2b3c4d5e sub:001 dlvrd:001 submit date:2608031200 done date:2608031201 stat:DELIVRD err:000 text:Ваш код BroadNetid:9f8e7d6c5b sub:001 dlvrd:000 submit date:2608031200 done date:2608031205 stat:UNDELIV err:062 text:Ваш код BroadNetДиагноз содержится в двух полях. Поле stat — это стандартизированное конечное состояние сообщения (см. ниже). Поле err — это код, специфичный для сети/оператора: один и тот же UNDELIV может поступать с разными значениями err у разных операторов, поэтому err имеет смысл только в контексте сети, в которой он завершается. Обратите внимание, что этот код ошибки отличается от SMPP command_status, который вы получаете при submit_sm_resp (ESME_RINVDSTADR, ESME_RTHROTTLED и другие); они декодируются по-разному. Используйте поиск кодов ошибок SMPP для значений command_status и декодер DLR для строки подтверждения.
В сообщении SMPP указано: расшифровано
SMPP определяет небольшой замкнутый набор конечных состояний, а также переходное состояние ENROUTE, которое может наблюдаться до завершения обработки сообщения. Семь состояний, перечисленных ниже, — это состояния, завершающие жизнь сообщения, с указанием типичной причины и действий, которые должно вызывать каждое из них. Рассматривайте их как распределение по оператору, идентификатору отправителя и маршруту — единичный случай UNDELIV означает шум; маршрут, в котором 40% случаев UNDELIV приходится на одного оператора, — это проблема маршрута.
| Штат DLR (стат) | Что это значит | Типичная причина | Что делать |
|---|---|---|---|
| ДОСТАВИТЬ | Телефон подтвердил получение. | Сообщение дошло до устройства. | Ничего — это успех; выборочная проверка по реальным отзывам пользователей для выявления сфабрикованных DELIVRD. |
| ПРИНЯТО | Принято от имени абонента (например, прочитано службой поддержки клиентов). | Оператор отметил сообщение как принятое без подтверждения со стороны мобильного телефона. | Рассматривайте как «мягкий успех»; исследуйте любой маршрут, который массово возвращает ACCEPTD — это часто маскирует недоставку. |
| ИСТЕКШИЙ | Срок действия истек до доставки | Телефон абонента выключен или находится вне зоны покрытия в течение всего периода действия сигнала, или исчерпаны все попытки повторного подключения SMSC. | Попробуйте позже или переключитесь на другой канал; убедитесь, что срок действия вашего предложения не слишком короткий. |
| УДАЛЕНО | Сообщение удалено в SMSC перед доставкой. | Удаление вручную/администратором или отключение спам-фильтра | Проверьте настройки фильтрации контента оператора и вашу политику идентификатора отправителя/контента. |
| ДОСТАВИТЬ | Сообщение не доставлено. | Недействительный или нераспределенный MSISDN, отсутствие маршрута, отклонение на сетевом уровне или блокировка брандмауэром. | Проверьте номер (с помощью HLR-проверки), затем проверьте качество маршрута и регистрацию идентификатора отправителя. |
| ОТКЛОНЕНО | Оператор отклонил сообщение. | Незарегистрированный идентификатор отправителя, контент-фильтр, классификация спама или список «Не беспокоить»/список согласия | Зарегистрируйте идентификатор отправителя, исправьте шаблон и подтвердите согласие на получение рассылки для получателя. |
| НЕИЗВЕСТНЫЙ | В SMSC отсутствует допустимое состояние для сообщения. | Нисходящий звено так и не предоставил достоверного отчета — зачастую это «черная дыра» в «сером маршруте». | Поставьте под сомнение маршрут; хороший прямой маршрут редко возвращается в неизвестном направлении. |
Считывание сигналов DLR как индикатора качества маршрута.
Как только вы поймете, что только DLR на уровне оператора заслуживает доверия, поток отчётов о доставке станет вашим лучшим инструментом оценки качества маршрутов — лучше любой карты покрытия или презентации. Прямые маршруты возвращают конкретные, согласованные коды ошибок и стабильный уровень доставки; серые маршруты возвращают общие сбои, разброс неизвестную информацию и уровень доставки, который колеблется от недели к неделе, поскольку межсетевые экраны операторов перехватывают трафик, а агрегатор незаметно перенаправляет его. Проанализируйте распределение DLR, отслеживая идентификаторы операторов и отправителей с течением времени: операторы, у которых вы видите рост неизвестных/неизвестных сообщений или исчезновение подробной информации об ошибках, используют маршруты с ухудшающимся качеством. Для регулируемых рынков стран Персидского залива — ОАЭ в соответствии с TDRA, Саудовская Аравия в соответствии с CST — REJECTD, сконцентрированный на одном идентификаторе отправителя, почти всегда означает пробел в регистрации или утверждении шаблона, а не сбой в сети.
BroadNet возвращает реальные DLR на уровне оператора — а не подтверждения шлюза — по 1,000+ соединениям операторов в 200+ странах, при этом поля stat и err отображаются для каждого сообщения, что позволяет видеть качество маршрута в режиме реального времени. Это подкреплено соглашением об уровне обслуживания платформы (SLA) на уровне 99,99% и прямыми маршрутами A2P, поддерживаемыми с 2003 года. Изучите SMS API или руководство разработчика SMPP.
Часто задаваемые вопросы
Что такое подтверждение доставки в SMS?
Подтверждение доставки (DLR) — это отчет о состоянии, возвращаемый после отправки SMS-сообщения, в котором указывается окончательный результат отправки сообщения: доставлено, недоставлено, истек срок действия, отклонено и так далее. Оно приходит после подтверждения отправки, либо в виде PDU подтверждения доставки SMPP deliver_sm, либо в виде HTTP-веб-хука. Подлинное подтверждение поступает от оператора-получателя, а не от шлюза, поэтому оно подтверждает, действительно ли телефон получил сообщение.
Что означает DLR?
DLR расшифровывается как «подтверждение доставки» (иногда «отчет о доставке»). В SMPP это отчет о состоянии сообщения, который SMSC возвращает для отправленного сообщения, содержащий поле статистики (DELIVRD, UNDELIV, EXPIRED, DELETED, ACCEPTD, UNKNOWN, REJECTD) и код ошибки, специфичный для оператора. Это разница между знанием того, что сообщение было принято к обработке, и знанием того, что оно фактически было доставлено на устройство.
Почему в моем SMS отображается сообщение UNDELIV / REJECTD?
UNDELIV обычно означает, что сообщение не удалось доставить на устройство — недействительный или нераспределенный MSISDN, отсутствие маршрута или блокировка на сетевом уровне или в брандмауэре. REJECTD означает, что оператор отклонил его, как правило, из-за незарегистрированного идентификатора отправителя, попадания в контент-фильтр, классификации как спам или включения в список «Не беспокоить»/список согласия. Прочитайте поле err и сопоставьте сбои по идентификатору отправителя, оператору и маршруту, чтобы выявить истинную причину.
Чем отличается подтверждение шлюза от DLR оператора?
Подтверждение шлюза (submit_sm_resp с ESME_ROK или HTTP 202) лишь подтверждает, что платформа приняла ваше сообщение для обработки. DLR оператора подтверждает, что фактически сделала с ним принимающая сеть. Агрегаторы на «серых» маршрутах иногда подделывают отчёты DELIVRD при передаче данных, поэтому DLR, полученный от оператора, является единственным достоверным сигналом того, что мобильное устройство получило сообщение.
Ссылки
- Спецификации SMPP v3.4 и v5.0 — формат подтверждения доставки, message_state и network_error_code: smpp.org
- 3GPP TS 23.040 — техническая реализация службы коротких сообщений (SMS-STATUS-REPORT, TP-Status): 3gpp.org
- Инструменты BroadNet — декодер DLR и поиск кодов ошибок SMPP.
- BroadNet — Руководство для разработчиков SMPP и SMS API.