يصال التسليم (DLR) هو رسالة حالة تُعاد بعد إرسال رسالة نصية قصيرة (SMS)، تُبلغ عن حالتها النهائية - مُسلّمة، غير مُسلّمة، منتهية الصلاحية، محذوفة، مقبولة، غير معروفة، أو مرفوضة - وفقًا لبروتوكول SMPP. يصدر إيصال التسليم الأصلي من مشغّل الشبكة المُستقبِل، وليس من البوابة، لذا فهو يُخبرك ما إذا كان الهاتف قد استلم الرسالة، ومن خلال حقل الخطأ، يُوضح سبب عدم استلامها.
ما هو إيصال التسليم - وما ليس كذلك
لحظة إرسال رسالة، تتلقى إشارتين مختلفتين، والخلط بينهما هو السبب الأكثر شيوعًا لانقطاعات الخدمة الوهمية. الأولى هي إشعار الإرسال: في بروتوكول SMPP، يُعيد مركز خدمة الرسائل القصيرة (SMSC) استجابة submit_sm_resp مع حالة الأمر ESME_ROK (0x00000000)؛ أما في واجهة برمجة تطبيقات HTTP، فتتلقى رمز 202 ومعرّف الرسالة. هذا يعني فقط أن المنصة قبلت الرسالة للمعالجة. الإشارة الثانية، التي تصل لاحقًا، هي إيصال التسليم - وهو تقرير خارج النطاق لما فعلته الشبكة بالرسالة. في بروتوكول SMPP، يعود كوحدة بيانات بروتوكول deliver_sm (PDU) التي يُشير esm_class فيها إلى أنها إيصال؛ أما في واجهة برمجة تطبيقات REST، فيتم تسليمها إلى رابط الويب الخاص بك. اربط نظامك بإيصال التسليم (DLR)، وليس باستجابة الإرسال - راجع دليل مطوري SMPP (/developers/smpp) لمعرفة المزيد عن علامتي bind وreceipt-request.
تأكيد البوابة مقابل إيصال تسليم البيانات للمشغّل الحقيقي
لا يتم إنشاء جميع تقارير DLR في نفس المكان على الشبكة، وهنا تكمن مشكلة جودة المسار. يتم إنشاء تقرير DLR حقيقي على مستوى المشغّل بواسطة الشبكة المُستقبِلة بعد أن يُقرّ الهاتف باستلام الرسالة القصيرة على مستوى SS7/MAP أو Diameter؛ ويقوم مركز خدمة الرسائل القصيرة (SMSC) التابع للمشغّل بربط تقرير طبقة الشبكة هذا بإيصال SMPP الذي تتلقاه. في المقابل، يتم إنشاء تقرير DLR الوسيط أو تقرير بوابة DLR بواسطة مُجمِّع عند تسليم الرسالة إلى الوجهة التالية - قبل أن يؤكد المشغّل المُستقبِل أي شيء. في المسار المباشر الواضح، يتطابق التقريران؛ أما في المسار الرمادي، فلا يتطابقان.
لهذا السبب تُعدّ "إيصالات التسليم المزيفة" خطيرة. فغالبًا ما يقوم مُجمّع المسارات غير الموثوقة، الذي لا يستطيع الحصول على إيصال تسليم حقيقي من المشغّل، بتزوير إيصال تسليم عند التحويل، ليظهر لوحة التحكم الخاصة به سليمة، حتى وإن تمّ تجاهل الرسالة أو تصفيتها أو إنهاء اتصالها. والدليل على ذلك هو معدل تسليم مثالي بشكل مريب، مصحوبًا بمستخدمين حقيقيين لم يستلموا الرسالة أبدًا، أو مسار يُعيد حالة "غير معروف" بشكل جماعي (حيث لا يملك مركز خدمة الرسائل القصيرة حالة صالحة لأنّ أي قفزة لاحقة لم تُرجع تقريرًا حقيقيًا). الصق أي سلسلة إيصال في أداة فك ترميز إيصال التسليم (DLR decoder) لمعرفة ما يدّعيه المسار بالضبط، ومقارنته بإيصال التسليم الحقيقي من المشغّل.
كيف تعود إليك إيصالات التسليم (DLR)
يوجد مساران للنقل ومصدر أساسي واحد. عبر بروتوكول SMPP، تُعاد بيانات الاستلام بشكل غير متزامن كوحدة بيانات بروتوكول (PDU) باسم deliver_sm في جلستك المرتبطة، مع تضمين الحالة النهائية في نص الرسالة القصيرة (سلسلة نصية كلاسيكية تتضمن id:… stat:… err:…)، وفي الإصدار 5.0 والعديد من تطبيقات الإصدار 3.4، في قيم TLV الخاصة بحالة الرسالة ورمز خطأ الشبكة. عبر واجهة برمجة تطبيقات HTTP، تُرسل نفس المعلومات عبر طلب POST إلى رابط ويب تقوم بتسجيله، عادةً بصيغة JSON. كلا المسارين مستمدان في النهاية من تقرير حالة الشبكة: يحدد معيار 3GPP TS 23.040 تقرير حالة الرسائل القصيرة (SMS-STATUS-REPORT) وحقل حالة نقطة النقل (TP-Status)، والذي يترجمه مركز خدمة الرسائل القصيرة (SMSC) إلى حالة رسالة SMPP التي تقرأها. تُعد طبقة SMPP ناقلاً أميناً لتقرير يُنشأ فعلياً على شبكة الهاتف المحمول.
بغض النظر عن وسيلة النقل، سجل نفس البيانات في كل إيصال حتى تتمكن من التشخيص من خلال النمط بدلاً من القصص الفردية:
- معرف الرسالة، حتى تتمكن من ربط DLR برسالة submit_sm الأصلية.
- قيمة الحالة (حالة الرسالة النهائية) وقيمة الخطأ (رمز خطأ الشبكة/المشغّل).
- مشغّل الوجهة (MCC/MNC)، ومعرّف المُرسِل، والمسار أو الربط المستخدم.
- الطوابع الزمنية لتاريخ الإرسال وتاريخ الانتهاء، حتى تتمكن من قياس زمن الاستجابة من البداية إلى النهاية واكتشاف أنماط انتهاء الصلاحية.
المعرّف: 1a2b3c4d5e، الفرع: 001، تاريخ التسليم: 001، تاريخ الإرسال: 2608031200، تاريخ الانتهاء: 2608031201، الحالة: تم التسليم، الخطأ: 000، النص: رمز BroadNet الخاص بكالمعرّف: 9f8e7d6c5b، الفرع: 001، تاريخ التسليم: 000، تاريخ الإرسال: 2608031200، تاريخ الانتهاء: 2608031205، الحالة: لم يتم التسليم، الخطأ: 062، النص: رمز BroadNet الخاص بكيحتوي حقلان على التشخيص. حقل الحالة (stat) هو حالة الرسالة النهائية الموحدة (الموضحة أدناه). أما حقل الخطأ (err) فهو رمز خاص بالشبكة/المشغّل - قد تصل نفس رسالة UNDELIV بقيم خطأ مختلفة على مشغّلين مختلفين، لذا فإن قيمة الخطأ (err) لا تكون ذات معنى إلا في سياق الشبكة التي تصل إليها. لاحظ أن رمز الخطأ هذا يختلف عن رمز حالة أمر SMPP الذي تحصل عليه عند إرسال استجابة SMPP (مثل ESME_RINVDSTADR وESME_RTHROTTLED وما شابهها)؛ إذ يُفسَّر كلٌّ منهما بطريقة مختلفة. استخدم أداة البحث عن رموز أخطاء SMPP (/tools/smpp-error-codes) لمعرفة قيم حالة الأمر، واستخدم أداة فك ترميز DLR لمعرفة سلسلة الإيصال.
حالات الرسائل في بروتوكول SMPP، مشروحةً
يُعرّف بروتوكول SMPP مجموعةً صغيرةً ومغلقةً من الحالات النهائية، بالإضافة إلى حالة ENROUTE العابرة التي قد تظهر قبل استقرار الرسالة. الحالات السبع الموضحة أدناه هي التي تُنهي دورة حياة الرسالة، مع ذكر السبب النموذجي والإجراء الذي ينبغي أن تُفعّله كل حالة. اقرأها كتوزيعٍ عبر المشغّل، ومعرّف المُرسِل، والمسار - حالة UNDELIV واحدة تُعتبر تشويشًا؛ أما المسار الذي تبلغ نسبة حالات UNDELIV فيه 40% على مشغّل واحد فيُشير إلى وجود مشكلة في المسار.
| حالة إيصال التسليم (DLR) | ماذا يعني ذلك؟ | السبب النموذجي | ما يجب القيام به |
|---|---|---|---|
| تم التسليم | أكد الهاتف استلام الطلب | وصلت الرسالة إلى الجهاز | لا شيء - هذا نجاح؛ تحقق عشوائيًا من تقارير المستخدمين الحقيقيين لكشف عمليات التسليم المزيفة |
| مقبول | تم قبولها نيابة عن المشترك (على سبيل المثال، تمت قراءتها من قبل خدمة العملاء) | قام المشغّل بتسجيل الطلب كقبول دون تأكيد فعلي من جهاز الهاتف. | تعامل مع الأمر على أنه نجاح جزئي؛ ابحث في أي مسار يُعيد عبارة "تم القبول" بكميات كبيرة - فغالباً ما يُخفي ذلك عدم التسليم. |
| منتهي الصلاحية | انقضت فترة الصلاحية قبل التسليم | تم إيقاف تشغيل الهاتف أو كان خارج نطاق التغطية طوال فترة التشغيل، أو تم استنفاد محاولات إعادة الاتصال بمركز خدمة الرسائل القصيرة | أعد المحاولة لاحقًا أو استخدم قناة أخرى؛ تأكد من أن فترة صلاحية اشتراكك ليست قصيرة جدًا |
| تم الحذف | تمت إزالة الرسالة في مركز خدمة الرسائل القصيرة قبل التسليم | الحذف اليدوي/الخاص بالمسؤول، أو إزالة فلتر البريد العشوائي | تحقق من إعدادات تصفية المحتوى الخاصة بالمشغّل وسياسة معرّف المُرسِل/المحتوى الخاصة بك |
| غير قابل للتوصيل | الرسالة غير قابلة للتسليم | رقم هاتف غير صالح أو غير مخصص، أو لا يوجد مسار، أو رفض على مستوى الشبكة، أو حظر جدار حماية SMS | تحقق من صحة الرقم (عن طريق البحث في سجل موقع المشترك)، ثم تحقق من جودة المسار وتسجيل معرّف المُرسِل. |
| مرفوض | رفض الموظف الرسالة | معرّف مُرسِل غير مسجل، أو فلتر محتوى، أو تصنيف بريد عشوائي، أو قائمة عدم الإزعاج/الموافقة | قم بتسجيل معرّف المُرسِل، وتصحيح القالب، وتأكيد الاشتراك للوجهة. |
| مجهول | لا يوجد لدى مركز خدمة الرسائل القصيرة حالة صالحة للرسالة | لم تُسفر عملية النقل اللاحقة عن أي تقرير حقيقي - وغالبًا ما تكون عبارة عن ثقب أسود ذي مسار رمادي | شكك في المسار؛ فالمسار المباشر السليم نادراً ما يعود إلى المجهول. |
قراءة إيصالات التسليم (DLR) كمؤشر على جودة المسار
بمجرد التسليم بأن سجل تسليم البيانات (DLR) على مستوى المشغّل هو الوحيد الموثوق به، يصبح سجل الاستلام أفضل أداة لديك لتقييم جودة المسار، متفوقًا على أي خريطة تغطية أو عرض تقديمي للمبيعات. تُرجع المسارات المباشرة رموز خطأ محددة ومتسقة، ومعدل تسليم ثابت؛ بينما تُرجع المسارات الرمادية حالات فشل عامة، وتشتتًا لحالات "غير معروف"، ومعدل تسليم متذبذب أسبوعيًا، حيث تعترض جدران الحماية الخاصة بالمشغّلين حركة البيانات، ويقوم المجمع بإعادة توجيهها تلقائيًا. قسّم توزيع سجل تسليم البيانات (DLR) حسب المشغّل النهائي ومعرّف المُرسِل بمرور الوقت: المشغّلون الذين تلاحظ لديهم ارتفاعًا في حالات "غير مُسلّم/غير معروف" أو اختفاء تفاصيل الخطأ هم من يسلكون مسارًا متدهورًا. بالنسبة لأسواق دول مجلس التعاون الخليجي الخاضعة للتنظيم - الإمارات العربية المتحدة بموجب هيئة تنظيم الاتصالات والحكومة الرقمية (TDRA)، والمملكة العربية السعودية بموجب هيئة الاتصالات والفضاء والتقنية (CST) - فإن تركيز حالات "مرفوض" على معرّف مُرسِل واحد يعني غالبًا وجود فجوة في التسجيل أو الموافقة على النموذج، وليس عطلًا في الشبكة.
تقوم BroadNet بإرجاع DLRs حقيقية على مستوى المشغّل - وليس acks البوابة - عبر أكثر من 1000 اتصال مشغّل في أكثر من 200 دولة، مع عرض حقول stat و err لكل رسالة بحيث تكون جودة المسار مرئية في الوقت الفعلي، مدعومة باتفاقية مستوى خدمة للمنصة بنسبة 99.99٪ ومسارات A2P مباشرة يتم الحفاظ عليها منذ عام 2003. استكشف SMS API أو دليل مطور SMPP.
الأسئلة الشائعة
ما هو إيصال التسليم في رسائل SMS؟
إيصال التسليم (DLR) هو تقرير حالة يُرسل بعد إرسال رسالة نصية قصيرة (SMS)، يوضح النتيجة النهائية للرسالة - تم تسليمها، أو تعذر تسليمها، أو انتهت صلاحيتها، أو تم رفضها، وما إلى ذلك. يصل هذا الإيصال بعد تأكيد الإرسال، إما كوحدة بيانات بروتوكول SMPP (pDU) أو كرابط ويب HTTP. يُصدر الإيصال الأصلي من مشغّل الشبكة المُرسِل، وليس من بوابة الشبكة، مما يؤكد استلام الهاتف للرسالة بالفعل.
ماذا تعني DLR؟
يشير اختصار DLR إلى إيصال التسليم (أو إيصال التسليم). في بروتوكول SMPP، هو تقرير حالة الرسالة الذي يُرجعه مركز خدمة الرسائل القصيرة (SMSC) للرسالة المُرسلة، ويتضمن حقل الحالة (تم التسليم، لم يتم التسليم، منتهية الصلاحية، محذوف، مقبول، غير معروف، مرفوض) ورمز خطأ خاص بالمشغّل. وهو الفرق بين معرفة أن الرسالة قد قُبلت للمعالجة ومعرفة أنها قد سُلمت بالفعل إلى الجهاز.
لماذا تظهر رسالة SMS الخاصة بي كـ "غير مُسلّمة" / "مرفوضة"؟
يشير الخطأ UNDELIV عادةً إلى عدم وصول الرسالة إلى الهاتف، إما بسبب رقم MSISDN غير صالح أو غير مخصص، أو عدم وجود مسار، أو حظر من طبقة الشبكة أو جدار حماية SMS. أما الخطأ REJECTD فيعني أن المشغّل رفض الرسالة رفضًا قاطعًا، عادةً بسبب معرّف مُرسِل غير مسجل، أو ورودها في فلتر المحتوى، أو تصنيفها كرسالة غير مرغوب فيها، أو إدراجها في قائمة عدم الإزعاج/الموافقة. اقرأ حقل الخطأ وقارن حالات الفشل بمعرّف المُرسِل والمشغّل والمسار لتحديد السبب الحقيقي.
ما الفرق بين إشعار تأكيد البوابة وإيصال التسليم الخاص بالمشغّل؟
لا يُؤكد إشعار البوابة (submit_sm_resp مع ESME_ROK، أو HTTP 202) سوى قبول المنصة لرسالتك للمعالجة. أما إشعار DLR من المشغّل فيُؤكد ما فعلته الشبكة المُستقبلة بها فعليًا. في بعض الأحيان، تُزوّر مُجمّعات البيانات على المسارات الرمادية إشعارات DELIVRD عند التسليم، لذا يُعدّ إشعار DLR الصادر من المشغّل الإشارة الوحيدة الموثوقة التي تُثبت استلام الهاتف المحمول للرسالة.
مراجع
- مواصفات SMPP الإصدارين 3.4 و 5.0 — تنسيق إيصال التسليم، وحالة الرسالة، ورمز خطأ الشبكة: smpp.org
- 3GPP TS 23.040 — التنفيذ التقني لخدمة الرسائل القصيرة (SMS-STATUS-REPORT، TP-Status): 3gpp.org
- أدوات BroadNet — DLR decoder و SMPP error-code lookup.
- BroadNet — دليل مطور SMPP وSMS API.