تم توثيق المحوّل. لكنه ظل قادراً على قراءة الوسائط

الخلاصة

• RFC 5369 وثيقة Informational تصف اكتشاف الحاجة إلى تحويل الوسائط في SIP واستدعاء الخدمة عبر التحكم بطرف ثالث أو جسر مؤتمر.
• لا ينبغي إدخال T قبل إثبات أن الطرف المجيب الفعلي يفتقر إلى القدرة المطلوبة؛ فالتفرع قد يختار جهازاً غير المتوقع، وقد يضيف الطرفان محوّلين إلى جلسة لم تحتج أياً منهما.
• يحتاج T إلى الوصول إلى الوسائط وتعديلها. يمكن توثيقه وحماية وصلتي A–T وT–B، لكن التشفير والسلامة العاديين من طرف إلى طرف لا يبقيان متصلين عبر وظيفة التحويل.

التوثيق ضيّق سؤال الهوية

توصي RFC 5369 بتوثيق المحوّل لتقليل خطر خدمة خبيثة تحصل على الوسائط. هذه خطوة ضرورية لكنها محددة.

تثبت عملية التوثيق أن الجهة قدمت اعتماداً مقبولاً تحت سياسة محددة. لا تثبت أنها استلمت أقل قدر من الوسائط أو أجرت التحويل الصحيح.

ولا تثبت الحذف أو العزل أو عدم استخدام البيانات لغرض آخر. تلك قرارات تحتاج سياسة وأحداث تشغيلية منفصلة.

ينبغي أن يسجل النظام هوية T، والمصدر الذي وثّقها، ونطاق الاعتماد، ووقت القرار، والجلسة والوسائط المصرح بها.

وظيفة T تتطلب إنهاء الحماية

التحويل يعني تفسير تمثيل ثم إنتاج آخر. إذا لم يستطع T قراءة الوسائط المشفرة فلن يستطيع تحويلها؛ وإذا منعته السلامة من التعديل فلن يستطيع إخراج الصيغة الجديدة.

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

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

عبارة «مكالمة مشفرة» من دون ذكر نقطة الإنهاء قد تكون صحيحة تقنياً ومضللة للقرار في الوقت نفسه.

الحاجة نفسها احتاجت دليلاً

قبل اختيار T، يحتاج offerer إلى معرفة قدرة answerer. يمكن لـpresence أو SDP أن يوفر معلومات.

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

تربط RFC 5369 ذلك بـHERFP وتترك الحل العام خارج نطاقها. لا تحوّل عدم الحل إلى إذن للتخمين.

احفظ ناشر القدرة، Contact، النسخة، الحداثة، الفروع، المجيب النهائي وoffer/answer. قرار T يتبع الطرف الذي اختير.

الانتظار منع وسيطين غير ضروريين

يوصي الإطار بعدم استدعاء التحويل قبل التأكد من أن answerer لا يدعم المطلوب.

إذا تصرف الطرفان على توقعات، فقد يضيف كل منهما T. قد يتحول GSM إلى PCM ثم يعود إلى GSM رغم وجود codec مشترك.

كل وسيط إضافي يزيد زمن الاستجابة وفقد الجودة والكلفة ومساحة الوصول إلى الوسائط.

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

اكتشاف الخدمة لم يكن ضمن الإطار

تفترض RFC 5369 أن الوكيل يعرف URI لخادم التحويل ولا تعرف طريقة اكتشافه.

إثبات الحاجة لا يثبت أن الخادم المختار يدعم اللغة والاتجاه والصيغ والسياسة والسعة المطلوبة.

الاختيار والتوثيق والتفويض والصحة والموقع والاحتفاظ أسئلة أخرى. اسم «تحويل كلام إلى نص» ليس عقد أداء.

يجب أن تتتابع الإيصالات: عدم توافق، اختيار T، تفاوض الوصلتين، استلام، إخراج، جودة، انتهاء وحذف.

عدم توافق المستخدم لم يكن codec فقط

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

يستعمل RFC 5369 آليات SIP نفسها لحالتي الجهاز والمستخدم. المعنى والنتيجة لا يصبحان متطابقين.

يحتاج الغرض الإنساني إلى لغة واتجاه وتفضيل وطريقة عرض. يمكن أن يكون التحويل متماثلاً أو في اتجاه واحد.

وصول الحزم إلى T لا يثبت دقة النص، وظهور النص لا يثبت أنه وصل في الوقت المناسب أو فُهم.

3pcc فصل الإشارات عن T

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

يستطيع endpoint متقدم إرسال التدفقات التي تحتاج التحويل فقط عبر T وترك المتوافقة مباشرة.

كما يستطيع استخدام محوّل للاتجاه المرسل وآخر للمستقبل. تتوزع السلطة بحسب التدفق والاتجاه.

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

الجسر جمع الإشارات والوسائط

في نموذج جسر المؤتمر، يعمل T بصفة B2BUA ويتفاوض على A–T وT–B.

يقل عدد تبادلات الإشارة للوكيل المستدعي، وهو مفيد لأجهزة بسيطة أو وصول بطيء.

لكن لا يمكن اختيار T مختلف لكل تدفق أو اتجاه. تتسع السلطة التي تتركز في الجسر.

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

التغيير في منتصف الجلسة كشف الاعتماد

قد تبدأ الجلسة بصوت متوافق ثم تضيف فيديو غير متوافق.

يسمح 3pcc بإدخال T بسهولة نسبية. يتطلب الجسر دعماً لـReplaces في الطرف البعيد لإدخال المحوّل أو تغييره.

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

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

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

يمكن لـ3pcc استخدام T1 في اتجاه وT2 في الآخر، فلا يرى محوّل واحد كل الوسائط.

هذا يقلل تركيزاً واحداً لكنه ينشئ هويتين وسياستين وسجلين ومساحتي احتفاظ. قد يجمع مشغل مشترك أو الارتباط الزمني السياق.

العبارة الدقيقة هي أن عقدة واحدة لا تعالج الاتجاهين. لا يصح تحويلها إلى وعد بأن النظام كله لا يستطيع إعادة البناء.

سجل لكل اتجاه الخدمة والوسيط ومفتاح الوصلة والتحويل والإخراج والحذف.

الدليل التاريخي لا يحدد إعداد اليوم

نشر RFC 5369 في أكتوبر 2008 بوصفه Informational، ويقول إنه لا يحدد معيار إنترنت.

أشار إلى وثائق TLS وS/MIME المتاحة آنذاك. أبطل RFC 8446 الوثيقة RFC 5246، وتنتمي RFC 3850 إلى سلسلة أقدم. لا يقدم هذا المقال إعداداً تشفيرياً حالياً.

أبطل RFC 6665 الوثيقة RFC 3265 الخاصة بالإشعارات. التطور لا يغير حاجة ربط القدرة بصاحبها.

RFC 3351 يقدم سياق الوصول، وRFC 4117 وRFC 5370 يصفان النموذجين. وجودها لا يثبت نجاح جلسة بعينها.

التشفير والنتيجة كانا طبقتين مختلفتين

يجب أن يحتفظ التقرير بالقدرة، والمجيب، وعدم التوافق، وT، والوصلتين، والوسائط، والإخراج، ونتيجة المستخدم.

حماية الوصلة لا تثبت جودة التحويل. النص الصحيح لا يثبت التسليم أو الفهم.

تُستخدم Minimum Initial Specification لـLu Heng كعدسة معلنة لإبقاء العقد المشترك في حده الأدنى وترك القرار المحلي لصاحب المعلومات. وتفصل Reality Layers بين presence وSDP والاستجابة والمسار والفهم. تستند الوقائع إلى RFCs.