SMPP - Short Message Peer-to-Peer Protocol

שלום! למרות ששליחים מיידיים ורשתות חברתיות מחליפות מדי יום את שיטות התקשורת המסורתיות, אין בכך כדי לגרוע מהפופולריות של ה-SMS. אימות באתר פופולרי, או הודעה על עסקה חוזרת, הם חיים ויחיו. האם תהיתם פעם איך כל זה עובד? לעתים קרובות מאוד, פרוטוקול SMPP משמש לשליחת הודעות המוניות, אשר יידונו להלן.

כבר היו מאמרים ב-Habré על smpp, 1,2, אבל המטרה שלהם לא הייתה לתאר את הפרוטוקול עצמו. כמובן, אתה יכול להתחיל מיד מהמקור המקורי - מפרטים, אבל אני חושב שזה יהיה נחמד אם יהיה סיכום קצר של זה. אסביר את השימוש ב-v3.4 כדוגמה, אשמח לביקורת האובייקטיבית שלך.

פרוטוקול SMPP הוא פרוטוקול העברת הודעות עמית לעמית. המשמעות היא שלכל שרת עמית/רכז יש זכויות שוות. במקרה הפשוט ביותר, ערכת הודעות ה-SMS נראית כך:

עם זאת, אם למפעיל הארצי אין מסלול לאזור מרוחק כלשהו, ​​הוא מבקש זאת ממתווך - רכזת SMS. לפעמים, כדי לשלוח SMS אחד, צריך לבנות שרשרת בין מספר מדינות, או אפילו יבשות.

לגבי הפרוטוקול

SMPP הוא פרוטוקול שכבת יישומים המבוסס על חילופי PDU ומועבר דרך TCP/IP, או הפעלות X25 להעברת הודעות SMS ו-ussd. בדרך כלל, SMPP משמש במצב מתמשך, מה שעוזר לחסוך זמן. SMPP משתמש במודל תקשורת לקוח-שרת.

מצב תקשורת

החלפת הודעות בין השולח למרכז ה-SMS באמצעות SMPP יכולה להתבצע במצבים הבאים:

משדר (משדר) - העברת הודעה בכיוון אחד, אחד בכל פעם
מקלט - מקבל רק הודעה ממרכז ה-SMS.
מקלט משדר (משדר) - החלפת הודעות בין מרכז ה-SMS למשתמש

מבנה

אורך הודעה

הודעת SMS אחת יכולה להכיל 70 תווים בהקלדה בקירילית ולא יותר מ-157 תווים לטיניים + 3 UDH אם תשלחו הודעת SMS עם מספר רב של תווים, היא תחולק למספר מקטעים ותשולב במכשיר המקבל. במקרה של פילוח, מספר התווים מצטמצם על ידי כותרות ההודעה, המציינות חלק מההודעה. לכן, כששולחים הודעת SMS גדולה, היא מכילה לכל היותר 153 תווים לטיניים או 67 תווים לא טיפוסיים.

תוכנית קידוד נתונים

עם זאת, סמלים דורשים קידוד כדי להעביר מסר. בפרוטוקול SMPP, שדה מיוחד אחראי על הקידוד - Data Coding Scheme, או DCS. זהו שדה המציין כיצד יש לזהות הודעות. בנוסף, שדה DCS כולל:

• ערכת התווים שמגדירה את הקידוד;
• מעמד הודעה;
• בקשה למחיקה אוטומטית לאחר קריאה;
• אינדיקציה של דחיסת הודעה;
• שפת הודעות שידור;

אלפבית רגיל של 7 סיביות (GSM 03.38). הוא פותח עבור מערכת העברת ההודעות GSM. קידוד זה מתאים לאנגלית ולמספר שפות לטיניות. כל תו מורכב מ-7 ביטים ומקודד לאוקטטה.

UTF-16 (ב-GSM UCS2) כדי לכלול תווים חסרים באלפבית של 7 סיביות, הקידוד UTF-16 פותח, המוסיף תווים נוספים (כולל קירילי) על ידי הקטנת גודל ההודעה מ-160 ל-70; סוג זה של קידוד כמעט משכפל לחלוטין את Unicode.

נתונים המוגדרים על ידי משתמש 8 סיביות. אלה כוללים KOI8-R ו-Windows-1251. למרות שהפתרון הזה נראה חסכוני יותר בהשוואה לאותו UTF-16. מתעוררת שאלה סבירה לגבי תאימות במכשירים שונים. כי במקרה זה, שני המכשירים חייבים להיות מוגדרים מראש.

שיעור מסרים

• הודעה Class0, או פלאש, המאוחסנת בזיכרון הטלפון לפי שיקול דעתו של המשתמש;
• Class1, או אלה המאוחסנים בזיכרון הטלפון;
• Class1, או אלה המאוחסנים בזיכרון הטלפון;
• Class2 חייבת לוודא שההודעה נשמרת בזיכרון של המסוף הנייד, אחרת עליה להתריע בפני מרכז ה-SMS על חוסר האפשרות לשמור;
• Class3 - במקרה זה, על הטלפון לשלוח הודעה שניתן לאחסן את ההודעה, ללא קשר לכמות הזיכרון במכשיר. סוג זה של הודעה מרמז שההודעה הגיעה לנמען;

סוג הודעה

הודעה שקטה (SMS0) סוג הודעת SMS ללא תוכן. SMS זה מגיע ללא התראה ואינו מוצג על מסך המכשיר.

PDU

כל פעולת pdu מותאמת ומורכבת מבקשה ותגובה. לדוגמה: פקודה האומרת כי נוצר חיבור (bind_transmitter / bind_transmitter_resp), או שנשלחה הודעה (deliver_sm / delivery_sm_resp)

כל חבילת pdu מורכבת משני חלקים - כותרת וגוף. מבנה הכותרת זהה לכל חבילת pdu: אורך הפקודה הוא אורך החבילה, id הוא שם החבילה, ופקודת הסטטוס מציינת אם ההודעה הועברה בהצלחה או עם שגיאה.

פרמטרים נוספים של TLV

TLV (ערך אורך תג), או שדות נוספים. פרמטרים כאלה משמשים להרחבת הפונקציונליות של הפרוטוקול ואינם נדרשים. שדה זה מופיע בסוף שדה ה-pdu. כדוגמה, באמצעות ה-TLV dest_addr_np_information, אתה יכול לארגן את העברת המידע על הניוד של מספר.

טון ו-Npi

פרמטר TON (סוג מספר) מודיע ל-SMSC על פורמט הכתובת וסוג הרשת.
פרמטר NPI (זיהוי תוכנית מספור) המציין את תוכנית המספור.

כתובת מקור ההודעה, או שם אלפא

הודעות שנשלחות לטלפון שלך מגיעות בשני סוגים: דיגיטלי ואלפביתי. מספרים דיגיטליים יכולים להיות ארוכים (בדומה למספר טלפון) או קצרים. לפעמים למפעילים יש הגבלות על שליחה משמות ניטרליים, למשל Infosms, Alert וכו'. לפעמים מפעילים לא יאפשרו תעבורה אם השם לא רשום ברשת שלהם. עם זאת, אלה הם מאפייני מפעיל.

שלבי הגשה

SMS-SUBMIT - זה שליחת הודעת MO FSM (הודעה קצרה ממסוף נייד)
דוח SMS-שלח — אישור שההודעה נשלחה על ידי SMSC
SRI SM (SendRoutingInfo) - SMSC מקבל מידע מ-HLR לגבי מיקום MSC / VLR של המנוי
SRI SM RESP - תגובת HLR בנוגע לבשר עמדת המנוי
MT-FSM - לאחר קבלת המיקום, נשלחת הודעה באמצעות פעולת "העבר הודעה קצרה".
MT-FSM ACK - תגובה מ-SMSC שההודעה נשלחה
דוח סטטוס SMS — SMSC שולח סטטוס מסירת הודעות.

מצב מסירת הודעות

דוח סטטוס SMS יכול לקחת מספר ערכים:
DELIVRD ההודעה נמסרה בהצלחה
נדחה — הודעה נדחתה על ידי מרכז ה-SMS
לא בתוקף - ההודעה מוסרת מתור השליחה לאחר תום ה-TTL (משך חיי ההודעה)
בטל - מקרים אחרים של אי אספקה
לא ידוע-לא התקבלה תשובה בנוגע למשלוח.

שגיאות העברה

לפעמים יש סיבות לכך שהודעות SMS לא נמסרות למנוי. התוצאה של סיבות אלה היא התרחשות של טעויות. שגיאות מוחזרות ל-PDUs_sms_resp. ניתן לחלק את כל השגיאות לזמניות (זמניות) ולקבועות (קבועות).

כדוגמה, absent_subscriber יכול להיות מסווג כזמני - המנוי אינו זמין או אינו מקוון, וקבוע - המנוי אינו קיים. בהתאם לשגיאות המתרחשות, נוצרת מדיניות לשליחת הודעות אלו מחדש.

לדוגמה, אם המנוי היה תפוס בשיחה וקיבל את השגיאה טלפון MT תפוס, ניתן לשלוח שוב את ההודעה לאחר מספר דקות, אולם אם שירות קבלת ההודעות של המנוי חסום, שליחת שוב שוב לא תהיה הגיונית. אתה יכול למצוא רשימה של שגיאות בדפי SMSC, למשל, כמו זה.

מקור: www.habr.com