Как валидация номеров в SMPP-шлюзе экономит бюджет компании
Валидация номеров на этапе передачи в SMPP-шлюз предотвращает отправку невалидных запросов, которые все равно могут тарифицироваться оператором как неудачные попытки или создавать лишнюю нагрузку на инфраструктуру. Ошибка в формате номера приводит к Reject-ответам от SMSC, потере времени на повторные попытки и оплате за сообщения, которые гарантированно не дойдут до получателя. Настройка строгих правил проверки на вашей стороне позволяет отсекать заведомо некорректные пакеты данных и сокращать расходы на технический трафик.
Почему формат номера влияет на стоимость рассылки?
Протокол SMPP оперирует на уровне PDU-пакетов. Если система пытается отправить сообщение на номер с неверным количеством знаков или недопустимыми символами, SMS-центр возвращает ошибку доставки. Хотя структура TLV в протоколе 3.4 позволяет передавать статусную информацию, многие операторы выставляют счета за сам факт попытки обработки запроса. Регулярная отправка «мусорных» данных на стороне отправителя без фильтрации приводит к росту нецелевых расходов.
Кодировка также имеет значение, так как напрямую определяет объем сообщения:
| Кодировка | Макс. длина (символов) |
|---|---|
| GSM 3.38 (Default) | 160 |
| Latin 1 (ISO-8859-1) | 140 |
| Unicode (UTF-16/UCS-2) | 70 |
Технические нюансы передачи адресата
В рамках SMPP поля source_addr и destination_addr должны соответствовать стандартам формата адресации (TON — Type of Number, NPI — Numbering Plan Indicator). Ошибочная установка параметров TON/NPI приводит к тому, что SMSC отклоняет корректный номер, воспринимая его как локальный, а не международный. Грамотная настройка шлюза требует жесткого соответствия значений TON=1 (international) и NPI=1 (ISDN/E.164). Игнорирование этого правила влечет за собой "отбраковку" пакетов на стороне оператора еще до стадии проверки валидности абонента.
Как настроить первичную проверку данных?
Начинайте валидацию с приведения всех номеров к международному формату E.164 для исключения региональных ошибок. Простой парсинг на наличие пробелов, скобок или кириллических символов в поле адресата избавит от большинства сбоев при передаче PDU. Дополнительно стоит внедрить проверку длины строки, чтобы сообщение не дробилось на части из-за случайного символа в номере. Если система не может однозначно определить формат, лучше заблокировать отправку на этапе формирования запроса, чем ожидать ответа об ошибке от шлюза.
Алгоритм предварительной очистки (Normalization)
Для предотвращения расхода ресурсов системы выполните следующие операции до формирования пакета SMPP Submit_SM:
- Удаление всех символов, кроме цифр, для входящих данных с пользовательских форм.
- Добавление символа "+" или префикса "00" для соответствия стандарту E.164.
- Проверка длины строки: для большинства мобильных сетей она должна составлять от 7 до 15 цифр.
- Исключение номеров, попадающих в "черные списки" (специальные сервисные номера, которые могут тарифицироваться по повышенным ставкам).
Типичные ошибки при работе с номерами
- Использование локальных префиксов вместо международного формата, принятого в SMPP.
- Отсутствие фильтрации непечатаемых символов и пробелов, которые воспринимаются системой как часть номера.
- Игнорирование статусов ошибок в TLV-параметрах для номеров, которые уже были помечены как «недостижимые».
- Отправка большого количества UCS-2 символов на номера, которые технически не могут их корректно отобразить.
- Отсутствие контроля версии протокола SMPP (3.3 vs 3.4): попытка использования TLV-параметров в урезанной версии протокола приводит к ошибкам парсинга пакета.
Практические шаги по оптимизации
Для снижения нагрузки на БД при обработке большого количества DLR, внедрите механизм кэширования последнего известного статуса абонента. Если номер был помечен как "недоставленный" из-за ошибки в формате, нет смысла пытаться отправить на него сообщение повторно в течение ближайших 24 часов.
FAQ: Вопросы и ответы
Как понять, что номер отклонен из-за проблем с форматом, а не из-за временной недоступности абонента?
Анализируйте поле "command_status" в ответе Submit_SM_Resp. Коды ошибок, такие как 0x0000000B (ESME_RINVDSTADR), прямо указывают на некорректный формат адресата, в то время как временные сбои возвращают коды, связанные с перегрузкой узлов.
Нужно ли проверять каждый номер через запрос к HLR?
Это зависит от масштабов. Запросы HLR (Home Location Register) стоят денег, поэтому их использование оправдано только для высокобюджетных маркетинговых кампаний. Для большинства задач достаточно регулярных выражений (regex) и проверки соответствия длины строки стандарту E.164.
Как не допустить критических задержек при обработке?
Даже при правильной валидации номеров важно отслеживать состояние соединения. Если шлюз начинает медленно отвечать на запросы валидации, это может привести к накоплению очереди в вашей системе. Для предотвращения узких мест и деградации пропускной способности рекомендуется разделять очередь валидации и основную очередь отправки сообщений. Использование асинхронных проверок позволит вашей основной программе не ждать ответа от шлюза, а мгновенно переходить к следующим бизнес-задачам.
3 шага, которые можно сделать сегодня:
- Проверьте PDU-логи за последние 7 дней на наличие кодов ошибок, связанных с неверным форматом номера (ищите коды ESME_RINVDSTADR).
- Добавьте в свой код регулярное выражение, которое отсекает все символы, кроме цифр и знака «+» перед отправкой запроса.
- Настройте автоматическое логирование отклоненных номеров, чтобы выявить основные источники ошибок в ваших базах данных.
