الخلاصة

  • كان branch في RFC 2543 يميّز أساساً النسخ التي يصنعها وكيل متشعّب؛ أما RFC 3261 فألزمه بوعد أوسع: التفرد عبر المكان والزمان مع استثناءات محددة.
  • البادئة z9hG4bK علامة توافق وليست وسيلة توثيق. وجودها يجيز قاعدة المطابقة الحديثة المختصرة، وغيابها يعيد المستقبل إلى مقارنة الحقول القديمة.
  • تعيد إعادة الإرسال استخدام الفرع نفسه، بينما تحصل محاولة توجيه جديدة على فرع جديد. ويشارك CANCEL وACK لرد غير ناجح الفرع عمداً للوصول إلى الحالة الصحيحة.

حين كان الفرع اسماً لنسخة لا للمعاملة كلها

قد تعبر دعوة SIP سلسلة من الوكلاء قبل أن تبلغ وكيل المستخدم. يضيف كل وكيل قيمة Via إلى أعلى المسار، وإذا كان يحتفظ بالحالة فإنه ينشئ معاملة عميل لكل وجهة يحاولها. تعود الردود عبر طبقات Via بالترتيب العكسي.

عرّف RFC 2543 معامل branch منذ النسخة المبكرة من المعيار، لكن ضمانه كان ضيقاً. كان على الوكيل الذي يشق الطلب إلى نسخ متوازية أن يمنح كل نسخة رمزاً يميّزها عن نظيراتها المتماثلة. أما الوكيل الذي لا يتشعّب فلم يكن ملزماً بإضافته.

لذلك لم يكن الفرع دليلاً كافياً على هوية معاملة واحدة. اعتمدت المطابقة كذلك على To وFrom وCall-ID وCSeq وأعلى Via. كانت الآلية قابلة للعمل، لكنها لم تسمح لخادم يرى رمزاً منفرداً بأن يفترض له قاعدة تفرد موحّدة.

هذه نقطة التوافق الحاسمة. عندما يتغير معنى حقل موجود، يعرف المرسل كيف أنشأه، لكن المستقبل يتحمل تكلفة الاختيار الخاطئ. من دون علامة داخل الرسالة سيضطر إلى تخمين جيل النظير من اسم الشركة أو موضع الشبكة أو سلوك سابق.

وضع RFC 3261 إعلان النسخة داخل القيمة

في عام 2002 نقل RFC 3261 الفرع إلى عقد جديد. صار على عميل وكيل المستخدم أن يضع Via أعلى كل طلب، وأن يحتوي هذا الـVia على branch. وباستثناء الحالات التي يحددها النص، يجب أن تكون القيمة فريدة في المكان والزمان بين جميع الطلبات الصادرة عن ذلك العميل.

كما ألزم المعيار أن تبدأ القيمة بـz9hG4bK. اختيرت الأحرف السبعة لأنها بعيدة الاحتمال في مخرجات تطبيقات RFC 2543. لا تشفّر البادئة تاريخاً أو مساراً أو مصنعاً أو هوية شخص. إنها تعلن فقط أن الجزء الباقي تكوّن وفق وعد RFC 3261.

مصطلح «magic cookie» قد يوحي بكلمة مرور أو cookie للمتصفح أو تحدٍّ عشوائي. الواقع أبسط: إنها شاهدة إصدار مضمّنة في الحقل الذي تغيّر تفسيره. يستطيع المستقبل فحصها محلياً ثم اختيار القانون المناسب، من دون سؤال سجل مركزي عمّا إذا كان الطرف «حديثاً».

قوة الوعد اختصرت عملية المطابقة

في الطلب الذي يحمل البادئة، تطابق معاملة الخادم الفرع الموجود في أعلى Via، وقيمة sent-by لذلك الـVia، والطريقة. لـACK استثناء محدد لأنه، عند الإقرار برد نهائي غير 2xx، ينتمي إلى معاملة INVITE المقصودة. وتظل sent-by لازمة لأن عميلين قد ينتجان القيمة نفسها، مصادفة أو عمداً.

إذا غابت البادئة، فلا يجوز للمستقبل أن ينسب إلى المرسل ضماناً لم يقدمه. ينتقل إلى إجراء التوافق مع RFC 2543، فيقارن Request-URI والوسوم وCall-ID وCSeq وأعلى Via بحسب الحالة. هكذا تعايشت مجموعتا توافق من غير إعادة تفسير صامتة للرسائل القديمة.

أما الرد فيُربط بواسطة branch في أعلى Via مع طريقة CSeq. وجود الطريقة جوهري لأن CANCEL معاملة مستقلة رغم أنها تستخدم فرع الطلب المستهدف. الرمز يضيّق مجال البحث، ولا يلغي معنى الحقول المحيطة به.

تُظهر أمثلة RFC 3665 حدود الاسم بوضوح: يضيف كل وكيل Via وفرعه عند الإرسال، ثم تُنزع الطبقة المقابلة عند عودة الرد. الفرع معرّف بين عميل وخادم متجاورين، لا اسم عالمي للمكالمة.

المحاولة ذاتها يجب أن تعيد إنتاج الدليل ذاته

يعطي الوكيل ذو الحالة فرعاً جديداً لكل محاولة صادرة. إذا فشلت وجهة وانتقل إلى عنوان آخر، فهذه معاملة عميل أخرى. وإذا عاد الطلب إلى الوكيل بعد تغير مدخلات المعالجة فقد تكون هناك دورة حلزونية مشروعة لا حلقة؛ ويمكن لتطبيق يكشف الحلقات أن يضمّن تلك المدخلات في جزء قابل للفصل من الفرع.

إعادة الإرسال هي النقيض. إنها نسخة أخرى من المحاولة نفسها، ولذلك يجب أن تحمل الفرع نفسه. بهذه الاستمرارية يعثر الخادم على الحالة القائمة ويعيد الرد المخزّن بدلاً من تنفيذ العملية مرة ثانية.

تظهر الصعوبة عند الوكيل عديم الحالة: لا يحتفظ بجدول يقرر أن الحزمة مكررة، لكن توليد عشوائية جديدة كل مرة سيحوّل معاملة واحدة إلى معاملات كثيرة. لذلك يطلب RFC 3261 اشتقاق الجزء الثابت من حقول الطلب وإعدادات لا تتغير بين الإعادات. لا تكفي الفرادة وحدها؛ يجب أن تقترن بقابلية إعادة الإنتاج.

CANCEL يستعير طريق الهوية ولا يرث النتيجة

يحتاج CANCEL إلى العثور على الطلب المعلّق نفسه وعلى المسار نفسه من قفزة إلى قفزة. ينسخ Request-URI وCall-ID والوسوم ورقم CSeq وأعلى Via والفرع، ثم يغيّر طريقة CSeq إلى CANCEL. وبذلك يستطيع حتى الوكيل عديم الحالة اتخاذ قرار التوجيه ذاته.

ومع هذا يبقى CANCEL معاملة مستقلة. قد يجيبه الخادم بـ200، ثم ينهي INVITE الأصلي برد 487 أو برد نهائي آخر؛ وربما كان رد نهائي قد سبق الإلغاء أصلاً. نجاح CANCEL يثبت قبول طلب الإلغاء للمعالجة، ولا يعيد كتابة مصير الطلب الأول.

فصل RFC 3261 المعاملتين بعدما كان RFC 2543 يمزج بعض سلوكهما. مشاركة branch هنا رابطة للعثور على الهدف، لا اندماجاً في دورة حياة واحدة.

صنف الرد النهائي يرسم الحد الفاصل بين نوعي ACK

إذا انتهى INVITE برد نهائي غير 2xx، يبقى ACK داخل معاملة INVITE. يكرر أعلى Via والفرع، ويبدل الطريقة إلى ACK، وتمتصه آلة حالة المعاملة. السلسلة التي نقلت الفشل هي التي توقف إعادة إرساله.

أما رد 2xx فينشئ وضعاً آخر. قد ينجح أكثر من فرع وتظهر حوارات مقبولة متعددة، ويجب أن تصل كل نتيجة إلى المتصل. يتولى نواة وكيل المستخدم ACK من الطرف إلى الطرف، متبعاً مسار الحوار وبـVia ذي فرع جديد. لا ينتمي هذا ACK إلى معاملة INVITE الأصلية على مستوى القفزات.

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

عالجت المواصفات اللاحقة عمر الحالة ولم تغيّر معنى الهوية

لم تحل هوية المعاملة كل أخطاء آلات الحالة. صحح RFC 4320 سلوك الردود والمهل في معاملات غير INVITE. ثم أضاف RFC 6026 حالة Accepted والمؤقت L، لكي يحتفظ الخادم بحالة INVITE تكفي لامتصاص الإعادات بعد إرسال 2xx.

ويحتفظ RFC 6026 أيضاً بمسار خاص لـACK قديم لا يحمل فرعه بادئة RFC 3261. استمرار الاستثناء يؤكد قيمة العلامة: يمكن إصلاح مدة بقاء الحالة، لكن لا بد للمستقبل أن يعرف أي افتراضات هوية قدمها المرسل فعلاً. يوثق RFC 5359 تدفقات خدمية أحدث تستخدم الاصطلاح؛ وهو دليل على القواعد الموصوفة، لا إحصاء لانتشار التنفيذ.

ما لا تستطيع البادئة إثباته

يمكن لأي طرف كتابة z9hG4bK. لا توثق السلسلة مستخدماً، ولا تجيز مكالمة، ولا تحمي سلامة الرسالة، ولا تثبت أن لاحقتها فريدة حقاً. قد يحمي TLS قفزة، وقد يثبت digest authentication دعوى اعتماد، وقد تقرر السياسة المحلية القبول. ليست أي من هذه السلطات من اختصاص branch.

والمعاملة ليست الحوار. يصف Call-ID والوسوم علاقة الحوار؛ وتوجّه route sets الطلبات اللاحقة؛ وللتفاوض الإعلامي وRTP حالاتهما. لا تثبت مطابقة branch الصحيحة أكثر من انتماء رسالة واردة إلى الحالة المحلية التي اختارتها قاعدة المطابقة.

القيمة التاريخية محدودة ودائمة في آن: غُيّر عقد الحقل من دون مطالبة المستقبل بالثقة في اسم المرسل. سبعة أحرف اختارت قاعدة قابلة للتنفيذ، وتوقفت صلاحيتها عند الحد الذي يمكن التحقق منه محلياً.

المصادر وحدود الاستدلال

تتكون حزمة الأدلة المغلقة من RFC 2543، وRFC 3261، وRFC 3665، وRFC 4320، وRFC 5359، وRFC 6026. تثبت هذه الوثائق تطور القواعد وأمثلة التشغيل والتصحيحات اللاحقة. ولا تثبت نسب الانتشار الحالية أو مطابقة منتج بعينه أو جودة المكالمات أو غياب تصادمات فعلية.