الخلاصة

  • يحدد RFC 5370 نموذج جسر المؤتمرات لاستدعاء خدمات تحويل الوسائط في SIP. يعمل T بوصفه B2BUA لا وكيلاً، فينهي معاملة A–T وينشئ معاملة مستقلة نحو B.
  • يجب على T أن يصادق المستخدمين ويفوضهم، وأن يبني From الصادر من القيمة الواردة مع مراعاة الخصوصية، من دون نسخ وسم tag. هذه أدلة مترابطة لكنها لا تثبت أن A أنشأ الطلب الصادر.
  • عندما يعيد T رمز الحالة الذي تلقاه من B، يبقى الرد الصاعد جديداً. وإذا ضاع 183 Session Progress فلا يكفي 603 وحده لمعرفة من رفض؛ ويصبح History-Info دليلاً ضرورياً للإسناد.

المصادقة أجابت سؤال الدخول

يصل A إلى T طالباً خدمة تحويل بينه وبين B. قبل أن يتصرف T، يلزمه أن يعرف من يستخدم الخدمة وأن يقرر ما إذا كان هذا المستخدم مخولاً.

المصادقة تربط الطلب بهوية ضمن سياسة اعتماد. والتفويض يقرر إن كانت تلك الهوية تستطيع طلب هذا النوع من الخدمة والوصول إلى هذا الهدف.

لكن نجاح الخطوتين لا يحول T إلى قناة شفافة. بعد قبول الطلب، T هو الذي ينشئ INVITE نحو B. لذا فعبارة “المتصل مصادق عليه” لا تعني “المتصل أرسل الرسالة التي استلمها B”.

يجب أن يحتفظ السجل بالهوية الموثّقة، وطريقة الإثبات، وقرار التفويض، والسياسة التي أنتجته. دمجها في حقل واحد اسمه “caller” يمحو الفرق بين من طلب الفعل ومن نفذه.

From قدّم هوية ولم ينقل المعاملة

ينص RFC 5370 على أن ينشئ T حقل From الصادر باستخدام قيمة From الواردة، مع الخضوع لمتطلبات الخصوصية في الطلب الأول. ولا تنطبق القاعدة على معامل tag.

يستطيع B بذلك أن يرى هوية تمثل A، بينما يستقبل رسالة أنشأها T ضمن معاملة جديدة. استمرارية العرض لا تعني استمرارية الحوار.

استثناء الوسم مهم لأنه جزء من تثبيت هوية الحوار. لو كان كل شيء نسخة واحدة لما احتاج T إلى مرساة جديدة على الجانب الثاني.

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

الخصوصية جعلت الهوية المعروضة قراراً

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

قد يعرف T هوية اعتماد داخلية لا ينبغي إرسالها. وقد يعرض عنواناً محدوداً أو مجهولاً وفق الطلب والسياسة. لذلك لا يثبت From الصادر وحده ما الذي عرفه T أو ما الذي تحقّق منه.

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

كان RFC 5370 يحيل إلى آلية الهوية في RFC 4474، ثم حل RFC 8224 محله لاحقاً. هذا التسلسل يوثق التاريخ ولا يثبت ما تستعمله منظومة حالية.

B2BUA كان صاحب الفعل الثاني

يحمل INVITE الوارد إلى T وصف SDP وقائمة recipient-list فيها URI واحد لـ B. بعد تفسيرهما، ينشئ T INVITE جديداً.

تؤكد الوثيقة أن T يعمل B2BUA لا proxy. الطلب الصادر ينتمي إلى معاملة أخرى، وT يبني SDP وفق خدمة التحويل التي يقدمها.

يمكن للمنصة إضافة معرف ارتباط يجمع الساقين في البحث. لكنه يعبّر عن قرار ربط اتخذه T، ولا يلغي معرفات المعاملات الأصلية.

هذه الحدود هي التي تسمح بتحديد أين حدث رفض أو تفاوض خاطئ. سجل واحد بعنوان “مكالمة A إلى B” سهل القراءة لكنه ضعيف في إسناد السلطة.

الرمز ذاته لم يكن الرد ذاته

حين يستلم T رداً نهائياً من B، ينشئ رداً نهائياً جديداً نحو A. وتوصي المواصفة بأن يحمل الرمز نفسه الذي استلمه.

إذا أرسل B 603 Decline يولّد T 603 في الساق الأخرى. التطابق يحافظ على تصنيف النتيجة، لا على هوية الحدث.

في المثال الفاشل، يرسل T أولاً 183 Session Progress. فإذا ضاعت هذه الرسالة المؤقتة ورأى A فقط 603، لا يعرف هل رفض T الطلب الأول أم رفض B الطلب الثاني.

التحقيق الذي يجمع الردين بسبب الرقم وحده ينسب قرار طرف إلى طرف آخر. وهذا يغير العلاج والمسؤولية ورسالة المستخدم.

History-Info أعاد سلسلة النسب

يذكر RFC 5370 استخدام History-Info بين T وA لحل الغموض. لا يغير السجل معنى 603، بل يبيّن الطريق الذي أنتج النتيجة.

تكشف المسألة قيمة الأحداث المؤقتة. وجود 183 دليل على أن T تقدم في المعالجة. فقدانه يحذف فارقاً بين رفض الخدمة ورفض الهدف.

أحال النص إلى RFC 4244، وجاء RFC 7044 لاحقاً ليحدث سياق History-Info. لا يكفي وجود المواصفة الأحدث للقول إن جلسة بعينها حملت التاريخ.

غياب الحقل يجب أن يبقى “مصدر غير محسوم” ما لم توجد قرينة أخرى. ملء الفراغ بأكثر الأسباب شيوعاً يخلق يقيناً غير صادر عن السجل.

البديل فصل القبول عن نتيجة الهدف

ناقشت الوثيقة مساراً آخر: يقبل T جلسة A برسالة 200 OK، ثم يرسل دعوة مستقلة إلى B، ويشترك A في حالة المؤتمر لمعرفة النتيجة.

كان هذا المسار يجعل قرارين ظاهرين: قبول T للمستخدم، ثم قبول B أو رفضه للدعوة. لكنه يزيد الرسائل والتعقيد وزمن الإعداد.

لم يُعتمد لهذا السبب. اشترى التصميم المختار بساطة وزمناً أقل، واعتمد في المقابل على History-Info لتفسير الفشل.

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

قائمة واحدة حدّت من التفويض

تحتوي recipient-list على URI واحد. وإذا وجد T أكثر من URI ينبغي أن يعيد 488 موضحاً أن الحد الأقصى واحد.

هذا القيد يضمن أن طلب A لا يتحول داخل الخدمة إلى انتشار متعدد. وهو خاص بنموذج التحويل ثنائي الطرف، لا إنكاراً لإمكان المؤتمرات متعددة الأطراف في RFC 5366.

يحكم SDP قدرات الوسائط على الساق الأولى، بينما تحكم القائمة الجهة التي يستطيع T دعوتها. وجودهما في multipart واحد لا يجعل سلطتهما واحدة.

حماية SDP من دون القائمة تحمي الترميز وتترك الهدف قابلاً للتغيير. يجب ربط سلامة القائمة بالطلب الوارد والـ URI المستخدم في الطلب الصادر.

عدم اشتراط opt-in كان استثناءً مشروطاً

تعالج خدمات القوائم خطر التضخيم والطلبات غير المرغوبة. ومع ذلك لا يطلب RFC 5370 قوائم opt-in لهذا النموذج.

يتأسس الاستنتاج على ثلاثة أمور: يولد T INVITE واحداً فقط؛ يكتب A بنفسه URI معروفاً لـ B؛ تظهر هوية المتصل في الطلب الصادر.

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

يجب تخزين الشروط نفسها لا النتيجة وحدها. علامة دائمة تقول “لا يلزم opt-in” يمكن أن تبقى بعد أن يتغير المنتج الذي بررها.

سلامة القائمة لم تثبت رضا B

تشدد الوثيقة على سلامة القائمة وتذكر S/MIME أو TLS، وتطلب من T المصادقة والتفويض.

سلامة القائمة تثبت، ضمن حدود الآلية، أن تعليمات الهدف لم تتغير. لا تثبت أن B وافق، أو أن T اختار SDP صحيحاً، أو أن التحويل كان دقيقاً.

كذلك لا ينتقل سياق الحماية من A–T تلقائياً إلى T–B. لكل ساق تفاوضها ونقاط نهايتها.

الإحالات إلى RFC 5246 وغيرها تنتمي إلى سياق 2008 ولا تصبح توصيات ضبط حالية. الدليل الحالي يجب أن يسمي الإصدار والسياسة والنتيجة الفعلية.

302 فوّض محاولة ولم ينفذها

يمكن لـ B، إذا لم يقبل SDP، أن يعيد 302 Moved Temporarily ويضع URI لـ T في Contact مع ?body= يحمل قائمة فيها عنوان B.

لا تستدعي هذه الرسالة T بذاتها. على A إغلاق المحاولة الأولى، وفك ترميز الجسم، والتحقق من الوجهة، ثم إنشاء INVITE جديد.

تصف RFC الترميز داخل URI بأنه معقد، وتقول إن 3pcc أبسط عند استدعاء الخدمة من جانب المتلقي.

لذلك يجب فصل اقتراح B، وقرار A باتباعه، وقبول T، وإنشاء الطلب الثاني. 302 دليل على توجيه مقترح، لا على أن الوسائط تحولت.

نجاح الإشارة لم يثبت إمكان الوصول

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

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

تثبت أكواد SIP حالة التحكم في الجلسة. أما النتيجة البشرية فتحتاج دليلاً على مستوى الاستخدام.

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

المصادقة لا تختصر سلسلة السلطة

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

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

تستخدم Minimum Initial Specification لدى Lu Heng هنا كعدسة معلنة. السجل الأدنى المفيد يحفظ هوية المستدعي، وقرار التفويض، والهدف الواحد المحمي، والخصوصية، ومعاملتين، وردود الساقين، والتاريخ السببي، وهوية T.

وتفصل Reality Layers بين الاعتماد، والاسم المعروض، والمعاملة، والحالة، والوسائط، والفهم. حقيقة طبقة لا تملأ طبقة أخرى.

الجسر أعاد كتابة السلطة بصورة قابلة للفحص

لا تكرر هذه القراءة إطار RFC 5369 الذي يسأل متى يلزم التحويل وأي طوبولوجيا تختار. بعد اختيار الجسر، يشرح RFC 5370 من ينشئ ماذا.

T يمثل A نحو B، لكنه لا يصبح A. يحمل نتيجة B نحو A، لكنها لا تصبح الرد الأصلي نفسه. يعرف هوية المستخدم، لكنه يبقى منشئ المعاملة الخارجية.

القوة التشغيلية مركزة في T: قبول الخدمة، كشف الهوية، تحديد SDP، إنشاء الدعوة، إعادة بناء الرد، والوصول إلى الوسائط.

لهذا يحتاج كل قرار إلى إيصال مستقل. المصادقة بداية سلسلة الإثبات، لا نهايتها.