الخلاصة

  • طلب RFC 3351 أن تكون النصوص والصوت والفيديو وخدمات الترحيل وتفضيلات المستخدم أجزاءً من جلسة SIP يمكن تغييرها من دون إعادة بدء المكالمة.
  • لكنه مستند متطلبات معلوماتي، لا امتداد SIP موحّداً ولا دليل على أن الأجهزة ومقدمي الخدمة نفذوا السيناريوهات الواردة فيه.

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

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

لكن لا يجوز إغفال تصنيف RFC 3351. فهو مستند معلوماتي يصرّح بأنه لا يحدد أي معيار للإنترنت. وكلمات MUST وSHOULD الواردة فيه تعبّر عن المتطلبات التي يطلبها المؤلفون؛ ولا تحوّله إلى امتداد SIP موحّد. كما أنه لا يصادق على تنفيذ بعينه ولا يحصي عدد الخدمات المتاحة. السيناريوهات الواردة أمثلة تصميمية، وليست مسحاً لواقع النشر.

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

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

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

يكشف تسلسل RFC اللاحق تطور المواصفات، لا نجاحاً شاملاً. عرّف RFC 4103 تنسيق RTP للنص الآني T.140 وأوصى بالتكرار للمساعدة في استعادة بعض الأحرف المفقودة. ثم وضع RFC 5194 إطاراً أكثر تفصيلاً للنص والتحويل والعرض والتشغيل البيني عبر SIP/IP، وأحال إلى RFC 3351 بشأن استدعاء خدمة الترحيل. وأوصى RFC 4504 بأن تدعم أجهزة الهاتف المعتمدة على SIP متطلبات الإتاحة في RFC 3351. وفي وقت لاحق، حدد RFC 8865 نقل نص T.140 عبر قنوات بيانات WebRTC الموثوقة والمرتبة، بينما عالج RFC 9071 مزج النص الآني في مؤتمرات RTP وحدّث RFC 4103. تجعل كل وثيقة جزءاً من المسار أدق، لكن أياً منها لا يثبت توافره على كل جهاز أو لدى كل مزود أو خدمة طوارئ.

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

المصادر: RFC 3351 · سجل RFC 3351 · سجل RFC 3351 في Datatracker · RFC 2119 · RFC 8174 · بروتوكول SIP، RFC 3261 · نموذج العرض والجواب في SDP، RFC 3264 · حمولة النص الحواري عبر RTP، RFC 4103 · إطار النص الآني عبر SIP، RFC 5194 · متطلبات أجهزة الهاتف SIP، RFC 4504 · نص T.140 عبر قنوات بيانات WebRTC، RFC 8865 · تنسيق المزج لنص RTP متعدد الأطراف، RFC 9071 · حد أدنى للمواصفات الأولية وقرار مستقبلي محلي واعتماد طوعي · أولوية الشيفرة العاملة