رقم ENUM-only سقط نحو مسار PSTN لم يكن موجوداً

الخلاصة

• يوثّق RFC 5346 تجربة ما قبل تجارية لـ Infrastructure ENUM أجرتها NIDA وشركتا VoIP في كوريا عام 2006. كانت السياسة تفرّق بين NOERROR مع URI قابلة للاستخدام، وNOERROR بلا URI قابلة للاستخدام لرقم ENUM-only، وأخطاء DNS التي تسمح بالرجوع إلى طريقة المورّد وPSTN.
• لم تكن NAPTR صالحة طريقاً مكتملاً. كان نطاق URI يحتاج بعد ذلك إلى جدول ثابت خاص أو إلى DNS تكراري وقواعد تحديد موقع SIP. وقد عكس الجدول الخاص اتفاق ربط ثنائياً بقدر ما عكس معلومة تقنية.
• الدليل التشغيلي الكافي هو سلسلة قرارات لا نتيجة أخيرة: الرقم، وفئة الإجابة، والسجلات المقبولة والمرفوضة، وسياسة النطاق، ومصدر تعيين البوابة، وسبب fallback، وسلطة الربط، والمسار المنفذ، ثم نتيجة المكالمة.

كان نطاق ENUM-only وعداً بعدم وجود طريق قديم

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

هذا التصميم يجعل إجابة DNS الناجحة تركيبياً غير كافية. قد تعود NAPTR query بقيمة RCODE=0، ومع ذلك لا يجد الـ softswitch خدمة يستطيع استخدامها. عندئذ طلب RFC 5346 الفشل الفوري، لا الرجوع إلى PSTN. السبب ليس تشدداً شكلياً، بل غياب الوجهة التقليدية التي يفترضها fallback.

لو تعامل نظام التشغيل مع كل غياب URI على أنه إذن للمسار القديم، فسيرسل رقماً ENUM-only إلى شبكة لا تملك نقطة ربط له. وقد تعيد الشبكة المحاولة أو تعيد الرقم إلى مسار آخر، فتتحول سياسة استمرارية إلى مخاطرة حلقة. لذلك يجب أن يحمل الرقم معه تصنيف النطاق، لا أن يعتمد القرار على RCODE وحده.

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

الفارق دقيق وحاسم: عدم وجود اسم في ENUM قد يعني أن الرقم ما زال يعيش في النظام القديم؛ وجود الاسم بلا خدمة قابلة للاستخدام في النطاق الحصري يعني أن الاتصال يجب أن يتوقف. السياسة هي التي أعطت الحالتين معناهما.

اكتمال المكالمة لم يحدد من اختار الطريق

يمكن لمكالمة أن تنجح بعد أن حوّل الـ softswitch رقم E.164 إلى اسم تحت e164.arpa، وقرأ NAPTR ملائمة، واختار URI، ثم حوّل نطاقها إلى بوابة IP. في هذا التاريخ تكون بنية ENUM جزءاً من قرار الطريق.

ويمكن للمكالمة نفسها أن تنجح بعد timeout أو NXDOMAIN. عندها يترك النظام دليل ENUM، ويستخدم جدول الأرقام الخاص بالمورّد، ويرسل الرقم إلى PSTN. النتيجة المرئية متطابقة تقريباً: رنين، ثم SIP 200 OK، وربما محادثة ناجحة. لكن سلطة التوجيه ليست متطابقة.

إذا سجلت لوحة المتابعة “answered” فقط، فهي تمحو الحد الذي انتقلت عنده السيطرة. وإذا سجلت “ENUM attempted”، فهي لا تزال تخلط المحاولة بالاختيار. نجاح المسار الاحتياطي يمكن أن يحجب نقص تغطية الدليل أو خلل المزوّد أو عطل المحلل.

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

حتى URI الصالحة لم تكن بوابة

بعد اختيار NAPTR صالحة، بقي سؤال مستقل: كيف يتحول domainpart في URI إلى نقطة ربط؟ عرض RFC 5346 طريقتين. الأولى DNS تكراري يتبعه تحديد موقع SIP. والثانية جدول ثابت داخل الـ softswitch يربط النطاق ببوابة متفق عليها.

إذا لم يجد الجدول نطاق URI، أمكن الرجوع إلى PSTN. وإذا فشلت عملية DNS أو لم تنتج سجلات قابلة للاستخدام، أمكن الرجوع كذلك. هذا يعني أن NAPTR سليمة لا تثبت أن المكالمة اتبعت ENUM حتى النهاية. إنها تعليمة أولية اجتازت سلطة أولى، ثم بقي عليها اجتياز سلطة نطاق وربط.

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

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

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

انتهاء المهلة كان تغييراً في نظام القرار

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

لم تخفض التجربة مهلة DNS بصورة غير متوافقة كي تخفي المشكلة. كانت مكتبة الحل في الـ softswitch تستخدم لأغراض أخرى، وتغييرها من دون فهم الأثر كان قد يبدل سلوك كل مستهلك DNS في الجهاز. هذا يبيّن أن إعداداً يبدو محلياً لمسار ENUM قد يكون اعتماداً مشتركاً.

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

هناك erratum معلّق لتحديث المستند يصحح أربع إشارات في القسم 4.1.1 من “rule 2” إلى “rule 3”، وerratum آخر يصحح كلمة “non-complaint” إلى “non-compliant”. لا يبدلان الاستنتاج، لكنهما يثبتان أن سجل التشغيل يجب أن يربط قواعده بنسخة النص والـ errata التي فُسرت منها.

متوسط التأخير لم يكن سجلاً للمسار

قارن التقرير المتوسط من SIP INVITE إلى 200 OK. كانت الفروق في الأزواج الستة أقل من ثانية: 2.33 مقابل 2.28 ثانية لاتصال A بنفسها، و2.23 مقابل 2.25 من A إلى B، و4.11 مقابل 3.79 من A إلى وجهة PSTN أخرى؛ ثم 2.18 مقابل 2.05، و2.19 مقابل 2.19، و3.95 مقابل 3.41 في الاتجاهات التي بدأت من B.

هذه القيم تدعم ملاحظة محدودة: لم يظهر للمستخدم فرق متوسط كبير في مجموعات التجربة المقاسة. لكنها لا تقدم عدد العينات، أو percentiles، أو ذيل التأخير، أو نسبة الفشل، أو حالة cache، أو المسار المنفذ لكل مكالمة.

ويتوقف القياس عند 200 OK. لا يثبت جودة الصوت، أو اكتمال المحادثة، أو صحة الفوترة، أو ملكية الرقم، أو صلاحية الربط. مكالمة PSTN أنقذها fallback ومكالمة IP قادها ENUM تستطيعان إنتاج المتوسط نفسه.

لذلك يجب ألا يتحول “المتصل لم يلاحظ” إلى “الدليل الجديد كان صاحب القرار”. الأول قياس خبرة ضيق؛ الثاني ادعاء عن السلطة يحتاج آثاراً مختلفة.

الخطأ المشترك لم يكن له مالك إصلاح واضح

أشار RFC 5346 إلى أن بيانات ENUM الخاطئة تسبب المشكلة في شبكة الشركة التي تبدأ المكالمة. لكن تلك الشركة قد لا تعرف من يخدم الرقم حالياً أو من يستطيع تعديل السجل. قابلية نقل الرقم تجعل العلاقة بين البادئة والمالك أقل وضوحاً.

قد يعيد المحلل السجل المنشور بأمانة. وقد يطبق الـ softswitch قاعدته بأمانة. وقد تفشل المكالمة لدى الجهة البادئة. لا تحدد هذه السلسلة من المسؤول عن إصلاح المصدر.

إن مشاركة معلومات الطريق تجعل الاكتشاف أكثر اتساقاً، لكنها توسع أيضاً نصف قطر الخطأ. إذا لم تنتقل معها هوية المزوّد، وإصدار السجل، وسياق porting، وقناة provision، وجهة الاتصال المخولة، فسينتشر الأثر أسرع من المسؤولية.

هذه ليست مشكلة DNS فقط. إنها مشكلة إسناد مؤسسي. ينبغي لبلاغ الحادث أن يجيب: من نشر؟ من يخدم الرقم؟ أي view رأى المستعلم؟ أي سياسة اختارت المسار؟ من يملك حق التصحيح؟ من دون ذلك يتحول “البيانات خاطئة” إلى حالة لا صاحب لها.

الانفتاح العام حسّن الاكتشاف ووسّع سطح المراقبة

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

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

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

الوثيقة تقرير تاريخي وليست وعداً حالياً

RFC 5346 وثيقة Informational، وليست Internet Standard. وهي تصف تجربة قبل تجارية في 2006، ثم حل RFC 6116 لاحقاً محل RFC 3761 بوصفه مواصفة ENUM. لا يجوز إسقاط نتائجها مباشرة على شبكة حالية أو اعتبار قواعدها تكليفاً عاماً.

قيمتها أنها تعرض فروعاً تشغيلية ملموسة: رقم حصري، وحالة NOERROR غير قابلة للاتصال، وأخطاء تسمح بالرجوع، وجدول خاص، وDNS عام، وقياس تأخير، وفجوة مسؤولية. هذه البنية تتيح سؤالاً صالحاً اليوم: عندما يتعايش دليل جديد مع طريق قديم، هل تسجل المؤسسة من اتخذ القرار أم تسجل أن النتيجة كانت خضراء فحسب؟

إيصال الطريق يجب أن يحفظ الحدود

يبدأ الإيصال برقم E.164 بعد التطبيع وتصنيف نطاقه: هل PSTN مسموحة أم أن الرقم ENUM-only؟ ثم يحتفظ بالسؤال والـ RCODE والإجابات، وبكل NAPTR مقبولة أو مرفوضة وأسباب ذلك، وبالـ order والـ preference والـ enumservice والـ URI والـ TTL.

بعد ذلك يسجل كيف عُيّن domainpart: DNS تكراري أم جدول ثابت، وأي نسخة أو view، وأي بوابة، وأي اتفاق ربط. وإذا وقع fallback، يسجل السبب والوقت والمسار المسموح وآلية منع الحلقة. وفي النهاية يفصل الرد SIP عن الاتصال الإعلامي واكتمال المحادثة والفوترة.

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