الخلاصة

  • فصلت RFC 3372 بين حفظ رسالة ISUP داخل جسم MIME وبين ترجمة بعض حقولها إلى SIP كي تقرأها الوكلاء وتختار المسار.
  • لا يثبت الجسم السليم صحة المسار أو تنفيذ الخاصية، كما لا يثبت وصول طلب SIP إلى الوجهة أن ISUP أعيد بناؤه بأمانة أو أن الوسائط والخدمة نجحتا.

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

نشرت RFC 3372 في سبتمبر 2002 بوصفها BCP 63، وأطلقت على الإطار اسم SIP-T. شددت الوثيقة على أنه ليس بروتوكولاً جديداً، بل مجموعة آليات للتشغيل البيني. وكان قرارها الأساسي أن تحمل المكالمة سجلين مترابطين لا يقوم أحدهما مقام الآخر.

السجل الأول هو رسالة ISUP المغلفة. تحدد بوابة الدخول النسخة التي تلقتها، وتضع الرسالة في جسم SIP باستخدام أنواع MIME في RFC 3204. تحتفظ هذه القناة بمعلمات قد لا يكون لها مقابل مباشر في SIP، ويمكن لبوابة الخروج استخدامها قالباً عند إعادة الإشارة إلى PSTN.

السجل الثاني هو طلب SIP الظاهر. لا يفترض بالوكيل أن يفسر ISUP، ولذلك تترجم بوابة الدخول معلومات مختارة، مثل الرقم المطلوب، إلى URI وترويسات يستطيع الوسيط استعمالها. سمت RFC الهدف الأول شفافية الخصائص، والثاني قابلية التوجيه. وهما نتيجتان مستقلتان.

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

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

كما أن المنشئ لا يعرف دائماً نوع النهاية. قد تنتهي مكالمة بدأت في PSTN عند هاتف SIP لا يستخدم ISUP. ومع ذلك ينبغي للهاتف التعامل بهدوء مع multipart والأنواع غير المعروفة بالاستناد إلى RFC 2046 وإطار SIP في RFC 3261. وإذا بدأ الاتصال من هاتف SIP، فلا معنى لإجباره على توليد ISUP تحسباً لنهاية هاتفية لم تحدد بعد.

كشفت إشارات منتصف المكالمة حدوداً أخرى. بعض رسائل ISUP لا تغير حالة جلسة SIP ولا معلماتها. لذلك أشارت RFC 3372 إلى طريقة INFO في RFC 2976 لنقلها. وصول INFO يثبت النقل، ولا يثبت فهم التطبيق أو ظهور الخاصية للمشترك.

قدم TRIP في RFC 3219 وENUM في RFC 2916 أدوات مجاورة للعثور على المسار والخدمة المرتبطة بالرقم، لكنهما لم يحلا محل سياق ISUP. وأوجبت SIP-T دعم توقيعات S/MIME وأوصت بالتشفير استناداً إلى RFC 2633. يستطيع التوقيع حماية المحتوى، لكنه لا يثبت صحة الترجمة أو شرعية السياسة أو نجاح المسار الصوتي.

فصلت RFC 3398 لاحقاً تحويلات SIP وISUP. وأتاحت RFC 3326 حمل سبب من فضاء بروتوكولي محدد، لكن تفسير الفعل ليس الفعل نفسه. أما RFC 3331 وRFC 3332 فناقشتا تكييف وظائف SS7 فوق SCTP. تلك الوثائق تحدد موضع حالة قديمة؛ أما SIP-T فيحدد لماذا تحتاج المكالمة إلى معنى محفوظ وسطح توجيه جديد في آن واحد.

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

تساعد مقالتا Lu Heng في ضبط الاستنتاج. تدعو “Minimum Initial Specification” إلى طبقة مشتركة صغيرة مع إبقاء القرارات المحلية مرئية. وتمنع “On Reality Layers” جمع SS7 المستلم والجسم المغلف والترويسة المترجمة والمسار وإعادة البناء والوسائط وتجربة المستخدم في حقيقة واحدة. جعلت RFC 3372 عبور الحد ممكناً لأنها لم تدّع أن حمل المعنى واتخاذ القرار به إثبات واحد.

المصادر