IOSOR ידע
DLT בהודו אינו מפת כיסוי רשת
הבן מדוע רישום DLT בהודו מסדיר זהות ישויות ותאימות כותרות ולא כיסוי גיאוגרפי בתשתית CPaaS מבוססת תשלום מראש.
DLT בהודו אינו מפת כיסוי רשת.
הבחנה בין תאימות DLT לבין ניתוב גיאוגרפי
טכנולוגיית ספר חשבונות מבוזר (DLT) ברגולציית התקשורת ההודית נתפסת לעיתים בטעות כמפת כיסוי רשתות או טבלת ניתוב אזורית. בפועל, DLT הינו שכבת זהות וממשל קריפטוגרפית מחייבת שנקבעה על ידי TRAI, המופרדת לחלוטין מנתיבי האיתות הפיזיים של רשתות הסלולר.
רישום במערכת ה-DLT אינו מעיד על זמינות אות סלולרי פיזי. ה-DLT פועל ברמת היישום כדי לאמת שהישות השולחת, הכותרת (Sender ID) ותבנית ההודעה מאושרים כדין בטרם הנתונים מועברים לתשתיות המפעילים הסלולריים בהודו.
קישור Principal Entity ו-Telemarketer בספר החשבונות
פעילות בהודו מחייבת רישום של מזהה ישות ראשית (Principal Entity - PE) וקישורו למזהה משווק מורשה (Telemarketer - TM). כותרות ותבניות הודעה חייבות להירשם באופן מפורש תחת צמד PE-TM זה בספר החשבונות הלאומי.
בעת שליחת בקשת API דרך IOSOR, מנוע הניתוב מוודא את תאימות הכותרת והתוכן מול נתוני ה-DLT. ללא שיוך PE-TM תקף, התעבורה תיחסם מידית ברמת הפרוטוקול בטרם תגיע לרשת היעד.
| סוג ישות | תפקיד ב-DLT | היקף אימות |
|---|---|---|
| Principal Entity (PE) | בעל המותג / העסק | רישום זהות, כותרות ותבניות |
| Telemarketer (TM) | שותף הפצה ותקשורת | שיוך נתיבי תעבורה ל-PE |
| ספר חשבונות DLT | שכבת אימות מרכזית | אימות קריפטוגרפי של תבניות והסכמות |
הקצאת JIT, שיוך מספרים ומצב ניתוב
מספרים וירטואליים וכתובות שולח ייעודיות ב-IOSOR פועלים על גבי ארכיטקטורת הקצאה דינמית Just-In-Time (JIT). במקום מאגרים סטטיים, IOSOR מיישמת רצף: הקצאת JIT + השהיית תשלום מראש + שיוך נכס E.164 לחשבון הלקוח יחד עם עלות חודשית (MRC).
הודעות דו-כיווניות, ניהול מילות מפתח STOP ושליחת הודעות OTP דורשים הגדרת נקודות קצה של webhook לקבלת דיווחי מסירה בזמן אמת וסנכרון מצבי ניתוב.
רצפת יתרה, השהיות תשלום מראש ואבני דרך להוצאות
IOSOR פועלת במודל יתרת תשלום מראש שקוף לחלוטין. על כל חשבון לשמור על רצפת יתרה מינימלית של USD 20 כדי להבטיח פעילות רציפה של ה-API, קליטת ה-webhooks וניתוב ההודעות.
במהלך שיגור תעבורה בהיקף גבוה, המערכת מפעילה השהיית יתרה זמנית לכיסוי עלויות המשלוח. הגעה לאבני דרך של הוצאה מאפשרת למערכת לבצע התאמה אוטומטית של קיבולת התעבורה.
אימות בסביבת ייצור ותלויות תהליך
לפני תחילת שידור תעבורת ייצור, מערכות הבדיקה מאמתות כי משתני התבנית, מזהי הכותרות ואסימוני ההסכמה תואמים במדויק לרישומי ה-DLT. המערכת מחזירה סטטוס Verify OK אך ורק כאשר מזהי ה-DLT ומצבי הניתוב מסונכרנים לחלוטין.
אי-התאמה תביא לעצירת התשדורת ברמת הפלטפורמה, ובכך תמנע עלויות מיותרות בגין חסימת הודעות על ידי מפעילות הסלולר בהודו.
חומרים קשורים: אי-התאמת כותרת DLT אינה נמסרת בניתוב CPaaS · שיוך PE-TM לפני שליחת תבניות DLT בהודו · שמירת יתרה מראש לפני החיוב הראשון.
התחל עם IOSOR
פתח את מסוף IOSOR והרשם את מזהה הישות הראשית (PE) שהונפק על ידי TRAI לצד קישור משווק הטלקום (TM) תחת לשונית ציות DLT. מיפה את מזהי שולח הכותרת המאושרים שלך ישירות לזוג PE-TM זה לפני קישור נכסי E.164 הפעילים שלך. הפעל מטען בדיקה כדי לוודא שמועכי DLT עוברים אימות מקדים לפני פתיחת צינורות תעבורת ייצור.
סיכום IOSOR
מדריך זה קובע כי רישום DLT הודי פועל אך ורק כשכבת ממשל וצינת קריפטוגרפית, המנותקת לחלוטין מניתוב ספקים פיזי ומפות כיסוי גיאוגרפיות. רישום מזהה ישות ראשית וקישור מזהי שולח למפתחות משווק טלקום ממלא את דרישות החוק של TRAI, אך ביצועי המסירה הגיאוגרפית תלחים לחלוטין בהגעה הרשתית התחתית.
חובה לקשר כל כותרת מזהה שולח ומועך תבנית לקשר ה-PE-TM המאומת שלך במסוף לפני שליחת תעבורה. אל תבלבל אישור כותרת DLT עם יכולת ניתוב גיאוגרפית או תנסה לעקוף בדיקות ציות על ידי התייחסות לרישומי כותרות כמתגים כיסוי אזוריים.
האם המדריך הזה עזר?
מדריכים קשורים
- אי-התאמת כותרת DLT אינה נמסרת בניתוב CPaaS
למדו מדוע אי-התאמה בכותרת DLT מובילה לדחיית הודעות SMS וכיצד IOSOR מונעת מרישומי delivered DLR שגויים לפגוע בספרי החשבונות של CPaaS.
- שיוך PE-TM לפני שליחת תבניות DLT בהודו
אכפו רישום קפדני של Principal Entity ו-Telemarketer תחת רגולציית DLT בהודו לפני שליחת תבניות A2P, למניעת חסימות רשת ונפילת הודעות.