الخلاصة

  • رسمت RFC 3136 معمارية SPIRITS لنقل حدث بدأ في شبكة الهاتف إلى مستخدم متصل بالإنترنت، ثم إعادة اختياره لمعالجة المكالمة إلى جهة التحكم الهاتفي.
  • لم يكن النقر تنفيذاً. كان على Gateway وSPIRITS Client حمل الاختيار، وعلى SCF تحويله إلى إجراء هاتفي، وعلى المقسم استئناف المعالجة قبل ظهور نتيجة يسمعها المتصل.

المكالمة في المقسم والاختيار على الشاشة

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

اقترحت خدمة Internet Call Waiting أن يظهر الحدث في نافذة: رقم المتصل أو اسمه إن توفر، ثم خيارات قبول المكالمة بعد إنهاء الإنترنت، أو تحويلها، أو إرسالها إلى البريد الصوتي، أو تشغيل رسالة، أو رفضها. يستطيع البرنامج إثبات أن المشترك ضغط خياراً بعينه.

غير أن المقسم لا يرى الفأرة. يملك هو حالة المكالمة والمهلة ونقطة التشغيل. ويملك حاسوب المستخدم النية. وبينهما سلسلة من جهات الملاحظة والقرار لا يجوز اختصارها بكلمة «نجاح» واحدة.

صدرت RFC 3136 في يونيو 2001 بوصفها Informational. لم تعرّف بروتوكولاً تنفيذياً كاملاً، بل وصفت مكونات وواجهات للخدمات التي تنشأ في PSTN وتحتاج إلى تفاعل مع الإنترنت. لذلك تثبت الخريطة ضرورة المسار، لا أن شبكة معينة طبّقته أو أن نتيجته تحققت.

الحدث بدأ من جهة الهاتف

تتعرف Service Switching Function، الموجودة عادة في المقسم، على triggers في Intelligent Network وتتفاعل مع Service Control Function. تنفذ SCF منطق الخدمة وتؤثر في الطريقة التي يكمل بها المقسم المكالمة.

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

وضعت RFC 3136 مكوّن SPIRITS Client في الجانب الهاتفي. يستقبل طلبات SCF ويرسل الردود. وقد يكون في الموقع نفسه مع SCF أو يتصل به عبر الواجهة D. الصناديق في الرسم وظائف، لا وعداً بأجهزة أو مؤسسات منفصلة.

يتوسط SPIRITS Gateway بين المجالين ويمكن أن يوجد مع مكونات PINT. أما SPIRITS Server فينهي طلبات PSTN ويتولى التفاعل مع المشترك، من عرض الإشعار إلى إعادة خيار المعالجة. تسمية Server لا تمنحه سلطة المقسم.

لكل واجهة معنى مختلف

تحمل الواجهة A طلبات PINT من مضيف المشترك إلى PINT Server. وكان دورها الرئيسي في SPIRITS تسجيل جلسة الخدمة وتنشيطها لمدة، وقد تستخدم للاشتراك. يثبت التسجيل علاقة نشطة، لا أن trigger لاحقاً سيعمل ولا أن المضيف سيظل قابلاً للوصول.

تصل B بين SPIRITS Server وGateway. تحمل في اتجاه إشعار المكالمة وبيانات المتصل المتاحة، وفي الاتجاه الآخر disposition اختاره المستخدم لحظياً. وصول الإشعار لا يثبت عودة الاختيار، ووصول الاختيار إلى Gateway لا يثبت تسليمه إلى التحكم الهاتفي.

تصل C بين Gateway وSPIRITS Client. وقد يتواصل Gateway مع Server أو يعمل خادماً افتراضياً ينهي الطلب. لذلك قد تعني كلمة «terminated» نهاية صحيحة للطلب داخل المعمارية، لا فشلاً ولا دليلاً على عبوره إلى عملية أخرى.

تربط D بين Client وSCF. تنتقل معلمات trigger من SCF، ويعود خيار المشترك إليها. وهنا تقول RFC 3136 إن SCF «تحوّل» disposition إلى إجراءات مناسبة، مثل تشغيل إعلان للمتصل، ثم تستأنف معالجة المكالمة المعلّقة في SSP.

أما E فترسل طلبات PINT إلى SCF للتنفيذ. يبدأ PINT بطلب من الإنترنت إلى الهاتف، بينما يبدأ SPIRITS بحدث هاتفي يريد خدمة من الإنترنت. اشتراكهما في مكونات لا يجعل التسجيل والإشعار والاختيار والتنفيذ سجلاً واحداً.

«رفض» على الشاشة ليس النغمة التي يسمعها المتصل

إذا اختار المشترك الرفض، يستطيع المضيف تسجيل هوية الجلسة والوقت والزر. يستطيع Server ترميز الرسالة، وGateway التحقق منها، وClient تسليمها إلى SCF. وحتى بعد نجاح ذلك كله، ربما لم يسمع المتصل إعلاناً ولم تُنهَ المكالمة.

تفسر SCF الاختيار حسب حالة المكالمة والاشتراك وسياسة المشغل. قد تحوله إلى أمر إعلان ثم تحرير. ويتعين على SSP أو SSF التنفيذ قبل انتهاء المهلة. إذا وصل الرد بعد أن تابع المقسم مساره، يبقى الرد صحيح التكوين لكنه فقد القدرة على تغيير تلك المكالمة.

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

لذلك يجب فصل تسجيل الجلسة، واكتشاف trigger، وإصدار الإشعار، ووصوله وعرضه، والاختيار اليدوي أو المسبق، واستلام Server/Gateway/Client، وتحويل SCF، وتنفيذ المقسم، ونتيجة الوجهة، والقراءة المستقلة. لا يكتسب إيصال مبكر معنى الإيصال اللاحق.

القاعدة المسبقة لم تُلغِ سلسلة التنفيذ

كان يمكن للمشترك إعداد معالجة عامة أو قواعد تختلف باختلاف رقم المتصل. عندئذ لا تظهر نافذة، ويطبّق النظام القاعدة ثم يعرض سجلاً فيه الوقت والرقم والاسم وdisposition.

هذا السجل شاهد محلي. قد تعني “forwarded” أن القاعدة اختيرت، أو أن الطلب خرج، أو أن النظام صنف رداً معيناً نجاحاً. من دون تحديد موضع المراقبة وشرط الاكتمال، لا تثبت أن الهاتف الآخر رن ولا أن شخصاً أجاب.

سبقت RFC 2995 هذه المعمارية بمسح أربعة تطبيقات pre-SPIRITS. دعمت كلها Internet Call Waiting، واستخدم معظمها SIP، واعتمدت كلها حلول Intelligent Network في الجانب الهاتفي. لكنها لم تكن جميعاً قابلة للتشغيل البيني، وحتى تطبيقات SIP لم تدعم بالضرورة الإصدار نفسه.

كما اختلف معنى “SPIRITS server” حسب التطبيق. أثبتت الأنظمة العاملة وجود تجارب حقيقية، لكنها لم تثبت مساراً عالمياً ولا نتيجة بشرية لكل قيمة success.

الإشعار لم يكن تفويضاً للتحكم

طلبت RFC 3298 لاحقاً أن يستطيع الحد الأدنى من بروتوكول SPIRITS تقديم إشعار أساسي من دون الاعتماد على PINT أو تفاعل دائم مع PSTN. يمكن إذاً للنظام أن يخبر مضيف الإنترنت بالحدث من دون أن يمنحه القدرة على تغيير المكالمة.

في سيناريو المعالجة، رسمت الوثيقة التسجيل ثم الإشعار ثم disposition ثم Service Control ثم SSP. وعدّت رد الفعل على الإشعار العنصر الباقي لتسليم الخدمة. شملت الرسائل قبولاً ورفضاً وإعادة توجيه، وبقي قبول VoIP خارج النطاق.

ينبغي للواجهة أن تقول: وصل الحدث؛ أرسل الاختيار؛ قبلت السياسة؛ نفذ المقسم؛ أجابت الوجهة. جمعها في علامة خضراء يمحو حدود السلطة.

في 2004 عرّفت RFC 3910 بروتوكول SPIRITS باستخدام SIP SUBSCRIBE/NOTIFY وXML. سمت جهة الإنترنت subscriber للأحداث، والجهة الهاتفية notifier. من يطلب المراقبة ومن يصدر الملاحظة أهم من لقب client أو server.

وفرّقت بين detection point من نوع Request، يوقف معالجة SSP حتى الرد، ونوع Notification يسمح للمعالجة بالاستمرار بعد الإبلاغ. استلام NOTIFY لا يثبت أن المقسم ينتظر قرار الإنترنت.

حتى قبول الاشتراك كان مراحل. يمكن أن تعني 202 أن الطلب قُبل ويجري العمل عليه، ثم يصل NOTIFY أول؛ وعند تهيئة نقاط الكشف يصل آخر. أما وقوع الحدث لاحقاً فله إشعار جديد. القبول والجاهزية والوقوع ليست حالة واحدة.

جسر التنفيذ بقي سياسة محلية

ركزت RFC 3910 على B وC، واعتبرت D مسألة سياسة محلية لمشغل PSTN. قد تكون واجهة وظيفية أو تبادل رسائل. توقف العقد المشترك قبل موضع تحويل نية الإنترنت إلى منطق SCF.

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

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

تحرك سطح الهجوم مع الاختيار

اعتبرت RFC 3136 الواجهة B، التي تعبر الإنترنت العام غالباً، الأكثر عرضة للسرقة ورفض الخدمة. وقد تكون C داخل شبكة المزود، لكن Gateway المتصل بالإنترنت يفتح حدوداً؛ وحذرت الوثيقة من أن firewall وحده قد لا يكفي.

يمكن لتسجيل مزور أن يحول caller ID إلى شخص آخر. ويمكن لتعديل disposition أن يستبدل البريد الصوتي بالتحويل. وقد يطبق replay متأخر خياراً قديماً على مكالمة جديدة. وحتى الهوية الصحيحة قد لا تعود مرتبطة بالخط.

المصادقة، والسلامة، والحداثة، وربط الخط، وسلطة الاختيار، وسياسة SCF، وتنفيذ المقسم، والنتيجة النهائية اختبارات مستقلة. يثبت النقر النية فقط.

انتهى زمن المودم وبقيت المسافة

تعرض لوحات اليوم أزرار تحويل حركة أو إلغاء اعتماد أو نقل حمل أو إيقاف عملية. ينشئ الزر نية؛ تتحقق البوابة؛ تقرر السياسة؛ يترجم المتحكم؛ ينفذ الجهاز؛ ويؤكد مراقب آخر النتيجة.

كانت صراحة RFC 3136 في أنها لم تسمِّ السلسلة كلها نقرة. اختار المشترك، لكن الشبكة كان عليها أن تجعل الاختيار حقيقة.