الخلاصة

  • يؤكد PRACK استجابة مؤقتة موثوقة بعينها؛ أما 2xx الذي يجيب عن PRACK فلا يعني قبول طلب INVITE الأصلي.
  • يربط RSeq وRAck الإقرار بالحوار وCSeq والطريقة والترتيب، لكنهما لا يثبتان وصول الوسائط أو سماعها، حتى إذا اكتمل تفاوض العرض والجواب مبكراً.

لماذا احتاجت الحالة المؤقتة إلى إيصال موثوق

يسمح RFC 3261 بإرسال استجابة مؤقتة واحدة أو أكثر قبل النتيجة النهائية لطلب INVITE. وقد تشير الاستجابات من 101 إلى 199 إلى تقدم الاتصال وتنشئ حواراً مبكراً. القبول النهائي يأتي في 2xx الخاص بـINVITE، بينما تحمل الفئات النهائية الأخرى إعادة التوجيه أو الرفض. لكن المواصفة الأساسية لا ترسل تلك الاستجابات المؤقتة بصورة موثوقة.

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

عرّف RFC 3262 وسم الخيار 100rel وطريقة PRACK. إذا أعلن INVITE دعمه لـ100rel جاز للخادم إرسال استجابة مؤقتة غير 100 بصورة موثوقة. وإذا طلبها عبر Require: 100rel وجب على الخادم تنفيذها أو رفض متطلب الامتداد. لا يشمل ذلك 100 Trying لأنها استجابة بين كل قفزتين، بينما يعمل هذا التأكيد من طرف إلى طرف.

عنوان دقيق للاستجابة المراد تأكيدها

تحمل الاستجابة المؤقتة الموثوقة Require: 100rel ورقم RSeq. يختار الرقم الأول من المجال المحدد، وتخص مساحة الأرقام معاملة واحدة؛ لذلك لا يصلح RSeq وحده معرفاً عالمياً للمكالمة.

يعاد إرسال الاستجابة بتراجع أسي يبدأ من T1 إلى أن يصل PRACK مطابق. يحتوي RAck على رقم RSeq ورقم CSeq وطريقة الطلب المرتبطة بالاستجابة، ويجب أن يقع PRACK في الحوار نفسه. الإقرار لا يقول إن «شيئاً ما» وصل، بل يحدد أي حالة مؤقتة في أي معاملة.

عند التطابق يجيب UAS عن PRACK بـ2xx ويوقف إعادة إرسال الاستجابة المؤقتة. وإذا لم يطابق PRACK أي استجابة معلقة، يجيب بـ481. وهنا يجب إبقاء المعاملتين منفصلتين: نجاح 2xx يخص PRACK، ولا يجيب عن INVITE ولا يقرر قبول الدعوة.

يشبه دور PRACK دور ACK، لكنه ليس نوعاً فرعياً منه. إنه طلب SIP عادي داخل الحوار، له موثوقية معاملة مستقلة بين القفزات وله استجابة خاصة. هذه الاستقلالية هي ما يتيح إثبات الاستلام من دون استعارة سلطة النتيجة النهائية.

ترتيب لا يسمح بالقفز فوق الفجوات

إقرارات PRACK غير تراكمية. توصي المواصفة، للحد من الازدحام، بألا تبقى سوى استجابة مؤقتة موثوقة واحدة بلا تأكيد، وتمنع إرسال الثانية قبل تأكيد الأولى. وبعد ذلك يزداد RSeq بمقدار واحد بالضبط ولا يلتف إلى البداية.

يتعرف الطرف المستقبل إلى إعادة الإرسال من معرّف الحوار وCSeq وRSeq، فيسقط النسخة المكررة. وإذا وصلت استجابة لاحقة قبل الرقم المنتظر، فلا يعالجها ولا يرسل لها PRACK؛ ويمكنه حفظها انتظاراً للحلقة المفقودة. الموثوقية هنا تشمل الوصول بالترتيب الصحيح، لا مجرد الظهور في سجل الحزم.

إذا استمر غياب PRACK المطابق مدة 64*T1، ينبغي للخادم رفض الطلب الأصلي باستجابة 5xx. وبذلك تضيف الموثوقية سطح فشل جديداً أيضاً: المؤقتات وذاكرة التسلسل ومسار الحوار والمصادقة يجب أن تبقى متسقة. لا تخبرنا المواصفة بنسبة الالتزام بهذه القواعد في الشبكات العاملة.

يمكن أن يكتمل التفاوض قبل أن تُقبل الدعوة

يستطيع PRACK حمل محتوى. فإذا تضمن INVITE عرضاً، أمكن للاستجابة المؤقتة الموثوقة حمل الجواب. وإذا خلا INVITE من العرض، أمكن للاستجابة المؤقتة أن تقدمه، وعندئذ يجب أن يحمل PRACK الجواب. كما يستطيع PRACK تقديم عرض جديد يكون جوابه في 2xx الخاص به.

قد تستقر معلمات الجلسة بهذه الطريقة قبل النتيجة النهائية لطلب INVITE. لكن اكتمال العرض والجواب لا يعني قبول الدعوة. إذا حملت استجابة مؤقتة موثوقة وصف جلسة وبقيت بلا PRACK، فلا يجوز لـUAS إرسال 2xx النهائي لقبول INVITE حتى يصل التأكيد. القيد يحمي سلامة التفاوض ولا يمنح PRACK صلاحية الإجابة النهائية.

يوضح RFC 6337 أن دعم الطرفين لـ100rel لا يجعل كل الاستجابات المؤقتة موثوقة بالضرورة. وعندما يحمل INVITE عرضاً، يكون أول SDP في استجابة موثوقة غير فاشلة هو الجواب الحقيقي؛ أما SDP السابق في استجابة غير موثوقة فليس إلا معاينة.

ويتيح UPDATE في RFC 3311 تغيير المعلمات داخل الحوار المبكر أو المؤكد. لكنه لا يدمج UPDATE وPRACK وINVITE في معاملة واحدة؛ لكل طريقة طلبها وتسلسلها واستجابتها.

للصوت المبكر مسار إثبات آخر

يناقش RFC 3960 نغمة الرنين والإعلانات والتفاعل المبكر قبل الإجابة النهائية. مسار إشارات SIP ومسار الوسائط مترابطان بصورة رخوة، وقد يسلكان طريقين مختلفين أو يصلا بترتيب مختلف.

لذلك لا يثبت PRACK وصول حزم RTP أو سماع الإنسان للإعلان أو رد الطرف الآخر. كما أن سماع الصوت لا يثبت مطابقة RAck مع RSeq الصحيح. يمكن جمع الخطين الزمنيين في التحليل، لكن لا يجوز استخدام أحدهما بديلاً عن الآخر.

يسجل سجل IANA لمعاملات SIP PRACK وRAck وRSeq و100rel مع الإحالة إلى RFC 3262. يثبت ذلك التخصيص الرسمي، لا الانتشار أو التوافق الفعلي أو جودة التنفيذ.

ولا يثبت تطابق الأرقام هوية المرسل. يحذر RFC 3262 من أن مهاجماً قد يحقن PRACK فيوقف إعادة إرسال معلومات مؤقتة مهمة. لذلك ينبغي توثيق PRACK مثل سائر الطلبات. مطابقة الحالة والثقة بالطرف اختباران مختلفان.

المصادر