IOSOR База знань

Індійський DLT не є картою географічного покриття

Чому DLT в Індії регулює ідентифікацію відправника та шаблони, а не фізичну зону покриття мереж: налаштування PE-TM, логіка JIT та правила балансу IOSOR.

Індійський DLT не є картою географічного покриття.

Відмінність між регулюванням DLT та фізичною мережею зв'язку

Реєстр розподіленої книги (DLT) в індійській телекомунікаційній системі не є картою географічного покриття чи списком доступних комутаторів. Це нормативно-криптографічний рівень контролю відправників, запроваджений регулятором TRAI, який функціонує окремо від фізичних маршрутів передачі пакетів.

Конфігурація ідентифікаторів Principal Entity та Telemarketer

Для відправлення SMS-трафіку обов'язково формується профіль Principal Entity (PE) ID із прив'язкою до сертифікованого Telemarketer (TM) ID. Усі альфанумеричні підписи реєструються виключно в межах цієї комбінації до початку відправлення запитів через API. Маршрутизатор платформи автоматично зіставляє заголовок повідомлення з національним реєстром DLT.

Механізм JIT-активації номерів та стан шлюзів

Виділення номерного ресурсу та альфа-підписів у сервісі IOSOR реалізовано за гнучкою моделлю Just-In-Time (JIT). Замість використання застарілих статичних резервів система виконує процес JIT + prepaid hold + assign, надійно закріплюючи номер формату E.164 за акаунтом разом із нарахуванням щомісячного MRC. Для обробки двосторонніх повідомлень, коректного відпрацювання стоп-слів STOP та високошвидкісної трансляції OTP необхідна реєстрація кінцевих точок webhook.

Балансові ліміти, холдування депозиту та перевірка обсягів

IOSOR використовує повністю прозору модель попередньої оплати послуг. Для безперебійної генерації запитів, реєстрації та надсилання пакетів встановлено мінімальний поріг USD 20 prepaid floor. При нарощуванні інтенсивності розсилок та досягненні показника soft review near USD 1,000/month запускається планова перевірка активності для безпечного підвищення пропускної спроможності без пауз у роботі шлюзу.

Готовність продакшн-середовища та супутні модулі

Перед запуском трафіку система перевіряє відповідність змінних шаблону, статус верифікації заголовків та наявність дозволів. Запит повертає результат Verify OK лише тоді, коли параметри DLT повністю відповідають поточному маршруту.

Пов’язані матеріали: Невідповідність DLT Header виключає статус Delivered · Фіксація PE-TM перед відправкою DLT-шаблонів в Індії · prepaid-резерв до першого списання.

Почніть з IOSOR

Зареєструйте ваш ідентифікатор Principal Entity (PE ID) та зв'яжіть його з авторизованим Telemarketer (TM ID) у консолі IOSOR. Додайте затверджені альфанумеричні хедери до створеної парної конфігурації перед відправкою першого SMS. Це активує автоматичну перевірку відповідності DLT на рівні шлюзу, зберігаючи при цьому географічну маршрутизацію трафіку.

Підсумок IOSOR

Реєстрація DLT в Індії є криптографічним шаром ідентифікації та комплаєнсу, а не картою географічного покриття операторів. Зв'язування PE-TM та валідація пар заголовок-шаблон гарантують легітимність розсилок, незалежно від конкретного регіонального маршруту чи мобільної мережі отримувача.

Не плутайте регуляторні вимоги DLT із фізичною географією зв'язку та не намагайтеся використовувати незареєстровані хедери для окремих регіонів. Завжди підтверджуйте прив'язку Sender ID до PE-TM у панелі керування до запуску продакшн-трафіку, щоб уникнути блокування повідомлень операторськими фільтрами.

Чи був матеріал корисним?

Пов’язані гіди