المقدمة
يوضح هذا المستند كيفية تكوين enableDelayQuickReinvite لمنع خادم التطبيق (AS) من إرسال إعادة توجيه الدعوة بسرعة كبيرة بعد ACK.
المتطلبات الأساسية
- معرفة بروتوكول بدء جلسة عمل أساسية (SIP)
- أساسي كمعرفة
- معرفة أساسية بمواصفات BW BWCLI
المتطلبات
- يمكن إستخدام AS BWCLI ومستخدم مسؤول
- إمكانية مراجعة AS XSLogs
تشغيل a نتلقى أمر للتحقق من القيم الحالية لكلا المعلمتين.
بشكل افتراضي enableDelayQuickReInvite معطل (خطأ) والقيمة الافتراضية ل delayQuickReInviteMillisseconds هو 1000 (1000 مللي ثانية أو ثانية واحدة).
يتم حذف جزء من إخراج الأمر get لزيادة إمكانية القراءة.
AS_CLI/Interface/SIP> get
...
enableDelayQuickReInvite = false
delayQuickReInviteMilliseconds = 1000
...
قم بتكوين المعلمة delayQuickReInviteMillisseconds.
اقبل القيمة الافتراضية أو أستخدم القيمة الأكثر ملاءمة لبيئتك.
أستخدم أقل قيمة ممكنة. ابدأ بقيمة 100 مللي ثانية، وزودها بشكل كافي للسماح بحل المشكلة.
AS_CLI/Interface/SIP> set delayQuickReInviteMilliseconds 100
...Done
بعد تكوين قيمة delayQuickReInviteMillisseconds، قم بتمكين enableDelayQuickReInvite.
AS_CLI/Interface/SIP> set enableDelayQuickReInvite true
...Done
التحقق من الصحة
عند الانتهاء من التكوين، قم بتشغيل سيناريو الاتصال مرة أخرى للتأكد من أن AS يضيف التأخير بين ACK و re-INVITE.
على سبيل المثال، إذا تم تكوين AS لإضافة 100 مللي ثانية، فتوقع أن يكون التأخير 100 مللي ثانية على الأقل أو أعلى نوعا ما.
تكون 100 مللي ثانية كافية عادة لمنع إستلام ACK و Re-INVITE بشكل غير مرتب.
قد تكون القيمة أعلى، استنادا إلى بيئة الشبكة ووحدات SIP المعنية في مسار الإشارة.
استكشاف الأخطاء وإصلاحها
إذا كان الجهاز لا يزال يستجيب مع رمز خطأ يبلغ 500، وتم تسليم ACK و Re-Invite بالترتيب الصحيح، يلزم إجراء مزيد من التحقيق في الجهاز.
أستخدم XSLogs على AS للتحقق من أن AS أضاف التأخير كما تم تكوينه.
أستخدم التقاط حزمة أو سجلات الجهاز للتأكد من أن التأخير كان كافيا لتسليم الرسائل بالترتيب الصحيح.
لاحظ أن هذا يعمل فقط عندما يرسل AS إعادة دعوة مباشرة بعد أن يرسل ACK.
ولا يعمل في حالة تلقي ACK مما يتسبب في قيام AS بإرسال إعادة دعوة.
التعليقات