BroadNet
الوثائق·/troubleshooting-queued-messages

لماذا تبقى رسائلي عالقة في قائمة الانتظار؟.

الرسالة التي تبقى في حالة "queued" (قيد الانتظار) — أي لا تصل أبدًا إلى DELIVRD أو UNDELIV — تعني عادةً أنها قُبلت من قِبل البوابة ولكن لم يتم تسليمها بعد من قِبل مشغّل الشبكة المُستهدفة. ويرجع ذلك غالبًا إلى جدولة إرسالها لاحقًا، أو خنقها عند حد TPS الخاص بك، أو انتظار انتهاء فترة صلاحيتها على جهاز مغلق أو خارج نطاق التغطية، أو وجودها على مسار مزدحم. تحقق من schtime، وسقف معدل النقل (TPS)، وإيصال التسليم (DLR) — فلا تغادر الرسالة قائمة الانتظار إلا عندما يُعيد المشغّل إيصالًا نهائيًا.

قراءة لمدة 5 دقائق·تم التحديث في مايو 2026مركز المطورين

Overview

الرسالة التي تبقى في حالة "queued" (قيد الانتظار) — أي لا تصل أبدًا إلى DELIVRD أو UNDELIV — تعني عادةً أنها قُبلت من قِبل البوابة ولكن لم يتم تسليمها بعد من قِبل مشغّل الشبكة المُستهدفة. ويرجع ذلك غالبًا إلى جدولة إرسالها لاحقًا، أو خنقها عند حد TPS الخاص بك، أو انتظار انتهاء فترة صلاحيتها على جهاز مغلق أو خارج نطاق التغطية، أو وجودها على مسار مزدحم. تحقق من schtime، وسقف معدل النقل (TPS)، وإيصال التسليم (DLR) — فلا تغادر الرسالة قائمة الانتظار إلا عندما يُعيد المشغّل إيصالًا نهائيًا.

الرسالة مجدولة لوقت لاحق

إذا ضبطت schtime (مع gmt)، فإن البوابة تحتجز الرسالة عمدًا حتى تلك اللحظة، لذا تبقى في قائمة الانتظار حتى يحين الموعد. تحقق من قيمتي schtime/gmt اللتين أرسلتهما — فإزاحة GMT خاطئة أو تاريخ مستقبلي هما أبسط سبب لعدم إرسال الدفعة. احذف schtime للإرسال الفوري؛ وتُرجع REST API قيمة ScheduleId عند جدولة الإرسال.

  • schtime (yyyyMMddhhmm) + gmt يحتفظ بالرسالة حتى ذلك الوقت.
  • إزاحة GMT خاطئة قد تؤخر الإرسال لساعات.
  • احذف schtime لإرسال الرسالة الآن.
  • تُرجع الدفعة المجدولة ScheduleId، لا تسليمًا فوريًا.

يتم تقييدها وفقًا لحدود معدل نقل الرسائل (TPS) الخاصة بك

يتم استهلاك دفعة كبيرة من الرسائل وفقًا لمعدل نقل الرسائل المسموح به لحسابك (عدد الرسائل في الثانية)، لذا تبقى الرسائل اللاحقة في قائمة الانتظار بينما تُرسل الرسائل السابقة - وهذا استهلاك طبيعي، وليس عطلًا. إذا كان حجم البيانات المستمر مهمًا، فاطلب معدل نقل بيانات أعلى. من الأفضل إرسال الدفعات الكبيرة جدًا كملف مستلمين إلى نقطة نهاية الإرسال الجماعي /sms/sendbulk بدلًا من إرسالها كطلب واحد ضخم.

  • يتم تصريف الدفعات الكبيرة عند غطاء TPS الخاص بك - وتنتظر الأجزاء اللاحقة.
  • هذا تنظيم متوقع لوتيرة الإرسال، وليس خطأً.
  • اطلب معدل نقل بيانات أعلى للحفاظ على حجم البيانات.
  • استخدم /sms/sendbulk للقوائم الكبيرة جدًا.

لا يمكن الوصول إلى الهاتف خلال فترة الصلاحية

إذا كان هاتف المستلم مغلقًا أو خارج نطاق التغطية، يقوم مركز خدمة الرسائل القصيرة (SMSC) التابع للمشغّل بتخزين الرسالة وإعادة إرسالها حتى يعود الهاتف للظهور أو تنتهي صلاحية الرسالة. خلال هذه الفترة، تُوضع الرسالة في قائمة الانتظار بشكل صحيح. عند انتهاء صلاحية الرسالة دون تسليمها، يتحول إيصال التسليم (DLR) إلى حالة "غير مُسلّم/منتهية الصلاحية" - لذا غالبًا ما تُحل مشكلة الرسائل المُعلقة لفترة طويلة تلقائيًا بمجرد عودة الهاتف للاتصال بالإنترنت.

  • يعيد SMSC (بآلية التخزين والتمرير) محاولة التسليم إلى الهاتف غير المتاح.
  • تبقى الرسالة في قائمة الانتظار حتى يتم تسليمها أو انتهاء صلاحيتها.
  • عند انتهاء الصلاحية، تصبح DLR غير مُسلّمة/منتهية الصلاحية.
  • غالباً ما يتم حل المشكلة عندما يعود الهاتف إلى نطاق التغطية.

تحقق من الرصيد والمسار والحالة الفعلية

إذا لم يحدث أي تغيير، فتأكد من الرصيد - فقد تفشل عملية الإرسال برمز HTTP18 (رصيد غير كافٍ) - ومن أن معرّف المُرسِل والمسار مُعتمدان للوجهة. لا تستنتج الحالة من غياب استدعاء خطاف الويب: اسحب حالة كل رسالة مباشرةً (عبر واجهة HTTP القديمة: /websmpp/websmsstatus مع معرّف الاستجابة).

  • لا يوجد أي حركة على الإطلاق؟ تحقق من الرصيد — HTTP18 يعني أن الرصيد غير كافٍ.
  • تأكد من أن معرّف المُرسِل والمسار معتمدان للبلد.
  • اقرأ الحالة الفعلية بسحبها مباشرة (واجهة HTTP القديمة: /websmpp/websmsstatus).
  • لا تفترض الحالة من غياب استدعاء خطاف الويب — اسحب الحالة.
وصول تجريبي · نرد خلال يوم عمل واحد

اطلب وصولاً تجريبياً وابنِ بثقة.

سنرد عليك خلال يوم عمل واحد ببيانات اعتماد الاختبار. بعد ذلك، ثبّت TypeScript SDK أو استدعِ REST API من أي لغة، وأرسل رسالتك التجريبية الأولى إلى رقمك الخاص.

$npm install @broadnet/cpaas-sdk axiosready