تنسيق تقرير تسليم SMPP

يتم إرسال تقارير تسليم SMPP بواسطة خادم SMPP، إلى عميل SMPP بعد تسليم الرسائل النصية بنجاح إلى الجهاز المحمول. يتم إرسال الرسالة الأصلية بواسطة عميل SMPP باستخدام طلب smpp submit_sm. عندما يتم قبول submit_sm من قبل خادم SMPP، فإنه يعيد استجابة submit_sm_resp، مع معرف مرجعي للرسالة. يصل تقرير التسليم في وقت لاحق. يحتوي على وقت التسليم و معرف الرسالة المرجعي الذي يحدد الرسالة. يوضح المستند أدناه محتويات وحدة بيانات البروتوكول (PDU) لتقرير تسليم SMPP ويعطيك مثالًا على تقرير التسليم.

ما هو تنسيق تقرير تسليم SMPP

يتم استلام تقرير تسليم SMPP كرسالة نصية قياسية. يحتوي نص الرسالة على تنسيق خاص، يتضمن حقولًا مختلفة حول الرسالة الأصلية المرسلة. يمكن استخدام هذه الحقول لتحديد حالة تسليم الرسالة.

مثال على تقرير التسليم

تم استلام تقرير التسليم. +44251234567->+0000000 'تم التسليم; إلى: +44251234567; في: 2022-10-03 12:07:00; 
المرجع: 636445148; المعرف:636445148 sub:000 dlvrd:001 تاريخ الإرسال:2210031207 تاريخ الانتهاء:2210031207 
الحالة:DELIVRD الخطأ: النص:'

تم الإبلاغ عن التسليم الناجح إلى admin@localhost. معرف المهمة: cdfd66e1-880e-4ead-a559-7ca46d9ec669. 
تم التسليم; إلى: +44251234567; في: 2022-10-03 12:07:00; المرجع: 636445148; المعرف:636445148 sub:000 dlvrd:001 
تاريخ الإرسال:2210031207 تاريخ الانتهاء:2210031207 الحالة:DELIVRD الخطأ: النص:

كيفية استلام تقرير تسليم SMPP

لاستلام تقرير تسليم SMPP

1. قم بتوصيل عميل SMPP
2. قم بالربط كمرسل ومستقبل
3. أرسل الرسالة النصية باستخدام وحدة submit_sm
4. سجل معرف الرسالة من استجابة submit_sm_resp
5. انتظر وصول الرسالة إلى الهاتف المحمول
6. استلم وحدة تقرير تسليم الرسالة
7. قم بمطابقة معرف الرسالة مع الرسالة المرسلة
8. سجل الطابع الزمني لتسليم الرسالة

معلمات تقرير تسليم SMPP

يدعم SMPP إيصالات / تقارير التسليم (DLRs) للرسائل النصية القصيرة حتى يتمكن تطبيقك من تحديد نتائج التسليم.

يعتمد إرجاع إيصال / تقرير تسليم الرسالة (DLR) على القيمة المحددة في حقل registered_delivery في الرسالة المرسلة أصلاً من ESME إلى MC في عملية submit_sm. يمكن تكوين هذا لسيناريوهات عدم التسليم والتسليم فقط، مما قد يؤدي إلى ظروف لن يتم فيها إرجاع الإيصال. يتم إرجاع إيصالات تسليم الرسائل في عمليات deliver_sm و data_sm.

الحقول التالية ذات صلة في عمليات deliver_sm و data_sm عند استخدامها لنقل إيصالات التسليم.

• عنوان المصدر (أي source_addr_ton، source_addr_npi، source_addr) - سيتم أخذ عنوان المصدر من عنوان الوجهة للرسالة القصيرة الأصلية، التي أنشأت إيصال التسليم. يظهر الإيصال كما لو أنه صادر من مستلم الرسالة الأصلية المسجلة.
• عنوان الوجهة (أي dest_addr_ton، dest_addr_npi، destination_addr) - سيتم أخذ عنوان الوجهة من عنوان المصدر للرسالة القصيرة الأصلية، التي أنشأت إيصال التسليم. يتم توجيه الإيصال إلى SME الذي أرسل الرسالة المسجلة أصلاً.
• esm_class - يتم تعيين البت 2 من esm_class إلى 1 للإشارة إلى أن الرسالة هي إيصال تسليم MC. إذا تم تعيين البت 5، فإن الرسالة هي إشعار وسيط.
• message_state TLV - يشير إلى الحالة النهائية للرسالة الأصلية. انظر حالات الرسالة أدناه.
• network_error_code TLV - انظر رموز الخطأ أدناه.
• receipted_message_id TLV - معرف الرسالة الذي تم إرجاعه إلى ESME بواسطة MC في وحدة submit_sm_resp.

إيصال تسليم MC

يستخدم هذا النوع من الرسائل لحمل إيصال تسليم MC. عند اكتشاف الحالة النهائية لرسالة مسجلة، يقوم MC عادةً بإنشاء رسالة إيصال جديدة موجهة إلى مرسل الرسالة الأولى. ثم يتم تسليم إيصال تسليم MC إلى ESME في عملية deliver_sm أو data_sm.

الإشعار الوسيط

الإشعار الوسيط هو شكل خاص من الرسائل التي قد يرسلها MC إلى ESME لتسليم رسالة موجهة إلى الهاتف المحمول. يوفر حالة وسيطة لمحاولة تسليم الرسالة.

من الاستخدامات النموذجية الإبلاغ عن نتيجة محاولات التسليم التي تمت خلال فترة إعادة المحاولة للرسالة داخل MC. يمكن استخدام هذا لتتبع الأسباب المختلفة لعدم تسليم الرسالة إلى وجهتها واستخدام هذا لتحليل توفر المشترك.

دعم وظيفة الإشعار الوسيط خاص بتنفيذ MC وموفر خدمة MC وهو خارج نطاق هذا المواصفات.

إيصال في حقل الرسالة القصيرة

من المحتمل أن تحتوي العديد من واجهات برمجة التطبيقات قبل الإصدار 3.4 ومراكز الرسائل التي تدعم الإصدار 3.3 على وسيلة لنقل معلومات الإيصال داخل حقل الرسالة القصيرة. ينطبق هذا على إيصالات تسليم مركز الرسائل والإشعارات الوسيطة. تفاصيل تنسيق هذه المعلومات تعتمد على بوابة الرسائل القصيرة ومنصة مركز خدمة الرسائل القصيرة وهي خارج نطاق المواصفات. ومع ذلك، يوضح ما يلي النهج المتبع عادةً:

id:123A456B sub:1 dlvrd:1 submit date:1702281424 done date:1702281424 stat:DELIVRD err:0 text:

يتم تحديد الحقول على النحو التالي:

تحسينات Ozeki SMPP

بعد تنفيذ عدد كبير جدًا من اتصالات SMPP، وجدنا المشكلات التالية في التطبيقات المختلفة:

قيمة حقل ID في تقرير التسليم (الذي نسميه Submit Reference في Ozeki) غالبًا ما تكون مختلفة عن المعرف الذي نتلقاه من مزود خدمة الرسائل القصيرة. الفرق الأكثر شيوعًا هو أن المعرف الأصلي يتم إرجاعه كرقم صحيح قياسي بينما يتم إرجاع المعرف في تقرير التسليم كرقم سداسي عشري. يمكن أن يحدث هذا أيضًا بالعكس. الشيء الجيد هو أنه في هذه الحالة، عند التحويل مرة أخرى، يتطابق الرقمان، لذا يمكن أن تتطابق تقارير التسليم. تطبيقات Ozeki للرسائل القصيرة تقوم بإجراء فحوصات مختلفة ويمكنها التعامل مع الحالة الموصوفة بشكل صحيح.

قيمة حقول التاريخ غالبًا ما تأتي بتنسيق غير قياسي. Ozekي يقوم حاليًا بتحليل حقول التاريخ باستخدام الأنماط التالية. يمكنك أيضًا تحديد نمط مخصص لحقل التاريخ في نموذج تكوين البرنامج.

• "yyMMddHHmm",
• "yyMMddHHmmss",
• "dd-MMM-yyHH:mm",
• "dd-MMM-yyHH:mm:ss",
• "dd-MMM-yy HH:mm",
• "dd-MMM-yy HH:mm:ss",
• "yyyyMMddHHmmss",
• "yyyyMMddHHmm",
• مخصص

حالات الرسالة

فيما يلي قائمة بالحالات المسموح بها للرسالة القصيرة. يقوم MC بإرجاع قيمة message_state إلى ESME كجزء من استجابة query_sm_resp أو query_broadcast_sm_resp أو PDU لإيصال إيصال deliver_sm.

الحالات المتوسطة هي حالات يمكن أن تتغير. أما الحالات النهائية فهي حالات تمثل نهاية دورة حياة الرسالة.

على سبيل المثال، قد تعيد رسالة في حالة إعادة المحاولة حالة ENROUTE. في وقت ما في المستقبل، ستنتهي صلاحية هذه الرسالة أو يتم تسليمها. عندها ستتقدم الحالة إلى EXPIRED أو DELIVERED. وبالتالي، يُقال إن الرسالة في حالة ENROUTE في حالة متوسطة.

لا يمكن للرسالة في حالة DELIVERED أو EXPIRED أن تتقدم إلى حالة أخرى. لذلك، تعتبر هذه الحالات حالات نهائية.

عند إرسال رسالة نصية قصيرة (SMS)، يكون تأكيد وصولها إلى هاتف المستلم أمرًا بالغ الأهمية. تستخدم الرسائل القصيرة نظام تأكيد من خطوتين لضمان ذلك.

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

بعد القبول، يتم تخزين الرسالة في مركز الخدمة حتى يصبح التسليم ممكنًا. قد يتأخر ذلك إذا كان هاتف المستلم مغلقًا، مما قد يطيل فترة الانتظار إلى أيام. عندما يصبح هاتف المستلم متاحًا، يتم تسليم الرسالة. عند التسليم الناجح، يتم إرسال "تقرير التسليم" مرة أخرى إلى المرسل كرسالة SMS منفصلة.

تتضمن رسالة التأكيد هذه:

• رقم هاتف المستلم: يؤكد أن المستلم المقصود قد تلقى الرسالة.
• مرجع الرسالة (معرف الاستدعاء): يتطابق مع المعرف من تقرير الإرسال الأصلي، مما يوفر رابطًا واضحًا بين المرحلتين.
• طابع زمني للتسليم: يوفر الوقت الدقيق الذي وصلت فيه الرسالة إلى هاتف المستلم.

هل يمكنني ضبط المدة التي يتم فيها تخزين الرسالة في مركز الخدمة؟

بينما توفر الرسائل القصيرة وسيلة ملائمة للتواصل، فإن ضمان وصول الرسالة إلى مستلمها بسرعة أمر بالغ الأهمية. هنا يأتي دور مفهوم "فترة الصلاحية".

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

فوائد استخدام فترة الصلاحية:

• الرسائل الحساسة للوقت: تخيل إرسال نص حول حدث حساس للوقت، مثل برنامج تلفزيوني مباشر. يضمن تعيين فترة صلاحية مناسبة عدم تسليم الرسالة بعد انتهاء الحدث، مما يجعلها غير ذات صلة.
• كفاءة الشبكة: من خلال منع محاولات التسليم غير الضرورية إلى الهواتف غير المتاحة، تحسن فترة الصلاحية استخدام موارد الشبكة.