قال الهاتف إن الجرس يرن، لكن المتصل ظل ينتظر حزم الوسائط: RFC 3960

الخلاصة

• عنت 180 Ringing في RFC 3960 أن الطرف المطلوب يجري تنبيهه، ولم تثبت أن نغمة أو إعلاناً داخل المسار وصل إلى المتصل.
• أمكن للعميل توليد رنين محلي عند غياب الحزم، ثم إيقافه عند ظهور الوسائط، مع إبقاء التفاوض والتوثيق والعرض والنتيجة أحكاماً مختلفة.

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

نظمت RFC 3960 في ديسمبر 2004 مفهوم الوسائط المبكرة: الصوت أو الفيديو المتبادل بعد INVITE الأول وقبل الرد النهائي. قد تحمل نغمة أو رسالة انتظار أو إعلان فشل أو حواراً تفاعلياً. أهم ما فعلته الوثيقة أنها رفضت مساواة تقدم SIP بوجود الوسائط.

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

لم تكن الإشارات كافية. قد يرسل خادم بسيط وسائط من دون ردود مؤقتة موثوقة. وقد يضع خادم آخر جواب SDP في رد مؤقت موثوق لتنفيذ الشروط المسبقة من دون نية إرسال صوت فوراً. جعلت RFC 3262 الردود موثوقة عبر RSeq وRAck وPRACK، لكنها لم تجعل إيصال التحكم إثباتاً لحزم RTP. وربطت RFC 3312 التقدم بتوفر الموارد؛ غير أن قبول الموارد ليس سماعاً.

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

حتى وصول الحزم ليس النهاية. قد تحمل صمتاً أو ضوضاء راحة. قدمت RFC 3711 في SRTP التوثيق والسلامة والحماية من الإعادة والسرية الاختيارية. لكن قبول الحزمة تشفيرياً لا يثبت فك الترميز أو خروج الصوت من السماعة أو فهم الإنسان. يجب الفصل بين 180، ومعلمات الوسائط، وأول حزمة، وأول صوت مفيد موثق.

عرّفت RFC 3264 offer/answer، وعرّفت RFC 3261 رسائل SIP التي تحملها. يثبت الاتفاق توافق المعلمات، لا حركة البيانات. وكان على العميل الاستعداد لتشغيل حزم قبل 200 OK، لأن انتظار الرد النهائي قد يقطع الكلمات الأولى.

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

فصل نموذج خادم التطبيقات بين الوسائط المبكرة والعادية. عرّفت RFC 3959 نوع early-session ووسم الخيار. أمكن رفض offer مبكر أو كتمه من دون تعطيل الجلسة التي ستستمر بعد القبول. حسّن الفصل السيطرة، لكنه لم يختر وحده أي تدفق يعرض ولم يثبت التسليم.

لم يحدد Alert-Info التوقيت أيضاً. يستطيع اختيار النغمة البديلة إذا قرر العميل إنشاء رنين محلي، لكنه لا يقول متى يبدأ.

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

تركت RFC 3960 درساً واضحاً: التنبيه البعيد، والرنين المحلي، والتدفق الوارد، وما يسمعه الإنسان وقائع يمكن وصلها بسلاسة، لكنها لا تصبح دليلاً واحداً.

يثبت سجل RFC Editor وبحث التصويبات أصل الوثيقة. ويأتي السياق من RFC 3261، وRFC 3262، وRFC 3264، وRFC 3959، وRFC 3312، وRFC 3711.