Ожидаемый маршрут
Согласуем страну, сеть, тестовый номер и идентификатор маршрута. Промежуточных провайдеров подтверждаем только там, где их видно в логах партнёра.
Проверка доставки A2P SMS на тестовых телефонах
Проверяем, дошло ли сообщение до телефона, сколько времени заняла доставка и совпал ли результат с отчётом провайдера.
Начать проверкуГермания
Провайдер A → Deutsche Telekom
- Получено
- 2 из 3
- Медиана
- 2,4 с
- Расхождения
- 1
- Статус DLR
- Доставлено
- Альфа-имя
- Без изменений
- Flash call
- Не выявлен
Только A2POTP и подтверждение аккаунтов
Интеграция SMPPСогласованные параметры подключения
Трафик заказчикаОпределённые сценарии и лимиты
Сопоставляем ID сообщений, временные метки и DLR с данными точки приёма и доступными логами партнёров.
Готовим согласованный сценарий
Фиксируем направление, тестовый номер, отправителя и время. Используем собственный или явно разрешённый трафик заказчика.
Какие данные сверяем
Идентификатор сценария, событие отправки и исходный ID сообщения, если он доступен.
Проверяем участок провайдера
Если в согласованный маршрут входит хаб, сопоставляем предоставленные им записи. Связываем ID разных систем там, где эти данные доступны.
Какие данные сверяем
Ответ провайдера, соответствие ID сообщений и временные метки из логов партнёра.
Проверяем передачу оператору
Разбираем данные со стороны оператора и доступные статусы. Принятие запроса отличается от итогового результата доставки.
Какие данные сверяем
Ответ или логи оператора и финальный DLR, если они предоставлены для теста.
Подтверждаем получение в контрольной точке
Проверяем, что пришло на согласованный телефон или SMPP-узел. Сопоставляем наблюдение с отчётом о доставке и разбираем расхождения.
Какие данные сверяем
Событие получения, точка приёма и время. Приём по SMPP не подтверждает получение на телефоне.
Наблюдаемый результат
Фиксируем точку приёма, ID сообщения и доступные временные метки. Подтверждение от шлюза само по себе не означает доставку на телефон.
Повторная проверка
Сопоставляем DLR с данными о получении. Вместе с партнёром разбираем отсутствие сообщения или задержку, затем повторяем тот же сценарий после изменений.
Отчёт по доставке и рискам A2P
Структурированный результат по транспортному статусу, фактическому получению, проверке OTP и оценке риска для каждого теста.
6тестовых сценариев
5подтверждены устройством
3результата требуют разбора
8,6 сp95 полученных сообщений
TikTok
Великобритания Пример сценария без реального теста
- Транспортный статус
- DELIVERED_DLR
- Статус DLR
- DELIVRD
- Контрольная точка
- Подтверждено
- Результат OTP
- Не проверялся · нет логов приложения
- Время получения
- 1,4 с
- Оценка риска
- PASS
- Уровень доказательности
- E3 / Условные данные устройства
Порог примера: ≤ 5 сПорог условный. В каждом проекте он согласуется отдельно.
Следующее действие
Повторить тот же сценарий и проверить стабильность, прежде чем обсуждать расширение тестирования.
Amazon
Германия Пример сценария без реального теста
- Транспортный статус
- DELIVERED_DLR
- Статус DLR
- DELIVRD
- Контрольная точка
- Подтверждено
- Результат OTP
- Не проверялся · нет логов приложения
- Время получения
- 1,8 с
- Оценка риска
- PASS
- Уровень доказательности
- E3 / Условные данные устройства
Вывод
В этом примере значимых признаков проблем доставки или фрода не обнаружено.
Порог примера: ≤ 5 сПорог условный. В каждом проекте он согласуется отдельно.
Следующее действие
Повторить тот же сценарий и проверить стабильность, прежде чем обсуждать расширение тестирования.
Uber
Бразилия Пример сценария без реального теста
- Транспортный статус
- DELIVERED_DLR
- Статус DLR
- DELIVRD
- Контрольная точка
- Подтверждено
- Результат OTP
- Не проверялся · нет логов приложения
- Время получения
- 8,6 с
- Оценка риска
- WATCH
- Уровень доказательности
- E3 / Условные данные устройства
Вывод
Время получения превысило условный порог. Необходимо проверить задержку маршрута и повторить тот же сценарий.
Порог примера: ≤ 5 сПорог условный. В каждом проекте он согласуется отдельно.
Следующее действие
Передать временные метки команде маршрутизации, проверить задержку и повторить тот же сценарий после изменений.
Франция Пример сценария без реального теста
- Транспортный статус
- DELIVERED_DLR
- Статус DLR
- DELIVRD
- Контрольная точка
- Подтверждено
- Результат OTP
- Не проверялся · нет логов приложения
- Время получения
- 2,1 с
- Оценка риска
- PASS
- Уровень доказательности
- E3 / Условные данные устройства
Вывод
В этом примере значимых признаков проблем доставки или фрода не обнаружено.
Порог примера: ≤ 5 сПорог условный. В каждом проекте он согласуется отдельно.
Следующее действие
Повторить тот же сценарий и проверить стабильность, прежде чем обсуждать расширение тестирования.
ChatGPT
США Пример сценария без реального теста
- Транспортный статус
- DELIVERED_DLR
- Статус DLR
- DELIVRD
- Контрольная точка
- Не отмечено
- Результат OTP
- Не проверялся · нет логов приложения
- Время получения
- —
- Оценка риска
- SUSPECTED
- Уровень доказательности
- E3 / Условные данные устройства
Вывод
Получен положительный DLR, но SMS не зафиксирована в контрольной точке. Это сильное расхождение для расследования, но не автоматическое доказательство фрода.
Порог примера: ≤ 5 сПорог условный. В каждом проекте он согласуется отдельно.
Следующее действие
Сопоставить ID сообщения, DLR и данные о получении. Проверить расхождение и повторить тест; сам пример не устанавливает причину.
ОАЭ Пример сценария без реального теста
- Транспортный статус
- DELIVERED_DLR
- Статус DLR
- DELIVRD
- Контрольная точка
- Подтверждено
- Результат OTP
- Не проверялся · нет логов приложения
- Время получения
- 6,2 с
- Оценка риска
- WATCH
- Уровень доказательности
- E3 / Условные данные устройства
Вывод
Время получения превысило условный порог. Необходимо проверить задержку маршрута и повторить тот же сценарий.
Порог примера: ≤ 5 сПорог условный. В каждом проекте он согласуется отдельно.
Следующее действие
Передать временные метки команде маршрутизации, проверить задержку и повторить тот же сценарий после изменений.
Статусы сообщения
- 01ACCEPTED
SMSC принял запрос
- 02SENT
Передано в следующий участок маршрута
- 03DELIVERED_DLR
Получен положительный отчёт о доставке
- 04HANDSET_CONFIRMED
Получение подтверждено независимо
- 05OTP_VERIFIED
Отдельная проверка приложения: нужно событие успешной верификации
Исключения и ошибки
Отклонено платформой, политикой или оператором
Получен отрицательный финальный DLR
Финальный DLR не получен в согласованное окно
Положительный DLR без подтверждения в контрольной точке
Статусы оценки
PASSЗначимых признаков нет
WATCHЗадержка или слабая аномалия
SUSPECTEDСильный или повторяющийся признак
CONFIRMED_ANOMALYВоспроизводимая техническая аномалия
INCONCLUSIVEДанных недостаточно или они противоречат
Параметры примера
- ID отчёта
- RSM-DEMO-024
- Охват
- 6 сценариев / 6 стран
- Доказательства
- DLR + контрольная точка
- Итоговая оценка
- SUSPECTED
Демонстрационный отчёт с вымышленными данными. SMS не отправляются; это не реальные показатели представленных приложений.
Названия приложений используются в примерах и не означают партнёрство.
Правило доказательности. Расхождение доставки может подтвердить техническую аномалию. Для подтверждения фрода или атрибуции маршрута нужны сопоставленные данные оператора, SMSC, сигнализации, CDR или биллинга.
Что проверяем
Получение SMS, время доставки и точность DLR. Проверки отправителя, текста и обхода маршрута опираются на доступные данные сети.
Проверка маршрутов
Проверяем выбранные страны и мобильные сети на согласованных номерах и сценариях приложений.
Проверка доставки
Сопоставляем доступный отчёт о доставке (DLR) с получением SMS на тестовом номере. Отмечаем расхождения для проверки.
Анализ результатов
Фиксируем доступные данные о времени доставки. Сравниваем повторные тесты, чтобы выявить задержки и повторяющиеся проблемы.
Выявляем отклонения в маршрутах
Признаки обхода через SIM-box
Ищем признаки завершения A2P-трафика через локальные SIM-карты. Сопоставляем изменения отправителя и данные приёма с логами оператора.
Какие данные нужны
Согласованное исходное сообщение, наблюдения в точке приёма и данные маршрутизации или сигнализации оператора. Один локальный номер отправителя сам по себе не доказывает использование SIM-box.
Изменения отправителя и текста
Сравниваем полученные Sender ID, текст и кодировку с исходным сообщением. Отмечаем необъяснённые изменения.
Какие данные нужны
Исходный текст и Sender ID, принятое сообщение и применимые правила нормализации отправителя. Отделяем неожиданные изменения от согласованных преобразований. Одного DLR недостаточно для проверки полученного текста.
Верификация через flash calls
Проверяем короткие звонки верификации вместо ожидаемой SMS. Анализируем номера звонящих и время событий с оператором.
Какие данные нужны
Наблюдения с согласованного тестового устройства или записи о звонках оператора, включая номер вызывающей стороны и временные метки. SMPP сам по себе не фиксирует звонки. Flash call может быть штатным способом верификации; само событие не доказывает мошенничество.
От теста к отчёту
- 01
Сценарии приложений
Согласуем приложения, страны, сети, точки приёма и лимиты тестов.
- 02
Анализ SMSC и сообщений
Фильтруем предоставленные SMSC/SMPP-записи по ID, отправителю, получателю, времени и статусу.
- 03
Закономерности в тестах
Сравниваем задержки, отсутствие SMS и повторяющиеся изменения по приложениям, сетям и маршрутам.
- 04
Отчёты и повторные проверки
Фиксируем результаты и следующие действия. Повторяем тесты после изменений маршрутизации.
С кем работаем
Операторы, провайдеры сообщений и команды, отвечающие за собственный транзакционный трафик.
Мобильные операторы и MVNO
Проверяем доставку в вашей сети. Тесты MVNO согласуем с базовым оператором.
SMS-хабы и агрегаторы
Сравниваем маршруты и проверяем результат изменений маршрутизации.
CPaaS и платформы сообщений
Проверяем маршруты провайдеров, DLR и качество через вашу SMPP-инфраструктуру.
Оптовые операторы и MVNE
Проверяем интерконнект и сопоставляем доступные сторонам данные маршрутизации.
Провайдеры аутентификации и OTP
Измеряем задержки и фиксируем отсутствие SMS в ваших сценариях верификации.
Цифровые сервисы и корпоративные команды
Банки, финтех, e-commerce, логистика, транспорт и SaaS: проверяем ваши транзакционные SMS вместе с провайдером.
Как проходит тестирование
Сценарий
Согласуем измеримый тест
Что потребуетсяСтраны, сети, разрешённые тестовые номера и сценарии приложений.
Что делаемОпределяем время тестирования, лимиты объёмов и критерии результата.
Следующий шагОбщие рамки теста и понятная ответственность сторон.
Подключение
Готовим SMPP-подключение
Что потребуетсяПараметры подключения, IP для белого списка и настройки маршрута.
Что делаемПодтверждаем настройки с технической командой и согласуем окно первого теста.
Следующий шагОбе команды готовы к согласованному тесту.
Тест
Фиксируем и сопоставляем
Что потребуетсяСобственный или явно разрешённый трафик заказчика в рамках согласованного сценария.
Что делаемПроверяем получение, доступные временные метки и отчёты о доставке. Отмечаем расхождения.
Следующий шагВыводы, привязанные к конкретному маршруту и сценарию.
Follow-up
Доводим каждый тест до решения
Что потребуетсяID тестов, временные метки, данные о получении и описание проблемы.
Что делаемПередаём результаты → определяем ответственного за разбор → повторяем тот же сценарий после изменений.
Следующий шагПодтверждаем результат повторного теста, затем согласуем мониторинг, объёмы и коммерческие условия.
Тестирование проводится на собственном или явно разрешённом трафике заказчика. Направления, приложения и объёмы согласуются отдельно для каждого проекта.
Подключение по SMPP
Вы подтверждаете номера, доступ к сети и маршрутизацию. Вместе согласуем роли подключения и проверки доставки.
Пример: приём сообщений от оператора
Оператор направляет согласованный входящий A2P-трафик на выделенные тестовые номера в принимающий SMPP-узел Routesms.
- ОтправительСобственный / разрешённый трафикSMS
- Согласованный маршрутУчастки провайдеров, если применимоSMS
- Мобильный операторТестовые номера и шлюзSMPP
- RoutesmsПринимающий SMPP-узел
Данные для сверки: получение в Routesms, а также логи отправителя и DLR — только если соответствующая сторона их предоставила.
Подтверждаемое наблюдение: получение в SMPP-узле.Пример: отправка тестов оператору
Если это предусмотрено соглашением, Routesms отправляет тестовые сообщения через SMPP-узел партнёра в выбранную контрольную точку.
- RoutesmsСогласованная отправка тестовSMPP
- Узел партнёраОператор / SMS-шлюзSMS
- Согласованный маршрутМаршрутизация на стороне оператораSMS
- Тестовый получательСогласованный телефон или узел
Данные для сверки: ответ на отправку, доступный DLR и подтверждение от получателя. Подтверждения шлюза и наблюдаемое получение учитываются отдельно.
Подтверждаемый результат зависит от выбранной точки приёма.Схема показывает возможные роли подключения, а не настройки по умолчанию. Приём SMS на SMPP-узле подтверждает получение в этом узле, а не на физическом телефоне.
- 01
Определяем рамки теста
Страны, сети, разрешённые номера, сценарии отправителя, направление трафика и критерии результата.
- 02
Обмениваемся параметрами
Адреса подключения, IP для белого списка, порты, роли bind и учётные данные через согласованный защищённый канал. Уточняем защиту соединения и правила доступа.
- 03
Проверяем SMPP-сессию
Проверяем bind, состояние соединения и направление обмена. Согласуем лимиты скорости, адресацию, кодировки и обработку DLR.
- 04
Проводим ограниченный пилот
Выполняем согласованные тесты. Фиксируем ID, ответы шлюза, отчёты о доставке и доступные данные о получении.
- 05
Разбираем и повторяем
Определяем ответственную команду по каждой проблеме. Повторяем сценарии с ошибками или задержками и сравниваем результат.
- 06
Согласуем дальнейшую работу
По результатам пилота определяем периодичность мониторинга, ответственных за поддержку, лимиты, объёмы и коммерческие условия.
Что означает каждое подтверждение?
submit_sm_resp
Подтверждает обработку запроса на отправку. Успешный ответ ещё не означает, что SMS получена на телефоне.
DLR
Отчёт о доставке содержит результат, сообщённый провайдером. Сопоставляем его с ID исходного сообщения и данными о получении.
deliver_sm
Может содержать принятое сообщение или отчёт о доставке. Перед выводами учитываем тип сообщения и назначение согласованного узла.
Объём тестирования в месяц
Выберите объём. Цена зависит от стран, сетей, сценариев и подключения.
Focus
1 млн
тестов в месяцПроверка приоритетных маршрутов.
Цена по запросу- Согласованные маршруты и сценарии
- Получение, время доставки и DLR
- Ежемесячный отчёт
- Ежемесячный разбор результатов
Orbit
5 млн
тестов в месяцРегулярные проверки нескольких маршрутов.
Цена по запросу- Сравнение маршрутов и провайдеров
- Получение, время доставки и DLR
- Ежемесячный отчёт
- Повторные проверки в пределах объёма
Horizon
10 млн
тестов в месяцРасширенная программа по нескольким сетям.
Цена по запросу- Несколько сетей и сценариев
- Получение, время доставки и DLR
- Ежедневный отчёт
- Отчёт и разбор итогов за месяц
Custom
Более
10 млн / индивидуальноПрограмма под задачи вашей сети.
Цена по запросу- Индивидуальный объём тестов
- Свои окна и частота тестирования
- Согласованный формат отчётности
- Отдельное согласование интеграции
SMPP-подключение и тесты — на собственном или явно разрешённом трафике заказчика. До старта согласуем покрытие, номера, отчётность, цену и срок договора.
Один тест — одна попытка доставки SMS в одну точку приёма. Повторные тесты считаются отдельно; объём не гарантирует доставку.
Обсудим вашу задачу.
Связаться с экспертомРасскажите, что происходит с вашими SMS
Достаточно пары предложений: куда отправляете сообщения, через кого и что пошло не так.
info@routesms.pro
В этом примере значимых признаков проблем доставки или фрода не обнаружено.