الخلاصة

  • عرّف RFC 3261 حوار SIP بواسطة Call-ID ووسم محلي ووسم بعيد. تنعكس الزاوية عند الطرف المقابل، فالوسم المحلي لطرف هو الوسم البعيد للآخر.
  • يمكن لطلب INVITE متفرع أن ينشئ حوارات مبكرة أو مؤكدة عدة. تشترك في Call-ID ووسم المنشئ، ويضيف كل مجيب To-tag مختلفاً.
  • يحمل الحوار حالة الترتيب والمسار والهدف إلى معاملات لاحقة. يربط معرّفه السياق، لكنه لا يصادق على شخص ولا يثبت وصول الوسائط.

كان العنوان واحداً، أما العلاقات فلم تكن كذلك

توحي كلمة «مكالمة» بحدث مفرد: يختار شخص عنواناً، يجيب طرف واحد، ويبدأ الحديث. سمح توجيه SIP بصورة أقل بساطة. كان الوكيل يستطيع إرسال INVITE نفسه إلى هاتف مكتبي وعميل برمجي وبوابة في الوقت ذاته. وقد ترن أجهزة عدة ويجيب أكثر من واحد.

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

احتاج SIP لذلك إلى اسم لذاكرة العلاقة، لا إلى اسم لتبادل رسالة واحدة فحسب.

في مارس 1999 سمّى RFC 2543 تلك العلاقة المستمرة call leg، وحددها بمزيج Call-ID وTo وFrom. وقد عرف مشكلة التفرع بالفعل: إذا أمكن للطلب أن يصل إلى خوادم مستخدمين عدة، أضاف كل رد To-tag حتى يميز المنشئ بين المجيبين. وكانت الردود المختلفة على INVITE الواحد تمثل فروع مكالمة مستقلة.

ظل النموذج مع ذلك متعلقاً بحقول العناوين كلها؛ كان From-tag اختيارياً، ولم تكن قواعد Route وRecord-Route مكتملة بما يكفي. حافظ SIP 2.0 على حقيقة التفرع، لكنه رسم حدود الحالة الطويلة بصورة أدق.

لم يكن المنشئ يملك سوى نصف الاسم

استبدل RFC 3261، الصادر في يونيو 2002، مفهوم call leg بمفهوم dialog: علاقة SIP نظير إلى نظير بين وكيلي مستخدم تستمر مدة من الزمن. يمنح الحوار الرسائل سياق تفسير، ويرتب الطلبات في الاتجاهين، ويحتفظ بما يلزم لتوجيه الطلبات اللاحقة.

يتكون dialog ID لدى كل وكيل من Call-ID ووسم محلي ووسم بعيد. وصفتا «محلي» و«بعيد» نسبيتان. وسم Alice المحلي هو وسم Bob البعيد؛ ووسم Bob المحلي هو وسم Alice البعيد. يتفق الطرفان على قيمتين مبهمتين، لا على اتجاه عالمي واحد لهما.

يحمل الطلب الأول Call-ID وFrom-tag، أي نصف معرّف الحوار بتعبير RFC 3261. ويضيف الرد القادر على إنشاء الحوار To-tag. لدى المنشئ يصبح From-tag محلياً وTo-tag المستلم بعيداً؛ ولدى المجيب تنعكس النظرة.

حل هذا التقاسم مشكلة التفرع. ترث الفروع كلها Call-ID ووسم المنشئ، ويضيف كل جهاز مستجيب To-tag خاصاً به. يستطيع المتصل جمع الإشارات المرتبطة من دون دمج حالات الأطراف المختلفة.

لذلك لم يكن Call-ID وحده معرّفاً كاملاً. ولم تكن الوسوم أسماء مستخدمين أو بيانات اعتماد. ألزم RFC 3261 أن يكون الوسم المولّد فريداً عالمياً وعشوائياً تشفيرياً بما لا يقل عن 32 بت من العشوائية. يقلل ذلك التباس السياق؛ لكنه لا يثبت هوية Alice ولا يمنح Bob إذناً ولا يتحقق من الاسم المعروض.

قد يولد الحوار قبل الإجابة النهائية

في حالة INVITE، ينشئ رد مؤقت من 101 إلى 199 يحمل To-tag ما يسمى early dialog. يستطيع المنشئ حينها حفظ حالة تخص ذلك المجيب قبل حسم النتيجة. يؤكد رد 2xx الحوار المقابل، أما الفشل أو غياب نجاح ذلك الفرع فينهي الحالة المبكرة وفق القواعد الأساسية.

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

يجيب PRACK عن سؤال قريب لكنه مختلف. يجعل RSeq وRAck بعض الردود المؤقتة موثوقة ومرتبة؛ بينما تحدد الوسوم سياق النظير الذي تنتمي إليه. تعمل الموثوقية داخل early dialog له اسم سابقاً ولا تصنع اسمه.

ويقع Via branch في طبقة أخرى أيضاً. فهو يربط المعاملة وإعادات إرسالها. تبقى ثلاثية الحوار بعد انتهاء تلك المعاملة وتظهر في معاملات جديدة. الخلط بينهما إما أن يمحو العلاقة باكراً أو يدمج طلبات مستقلة في تبادل واحد.

حفظ الاسم آلة حالة كاملة

لم يخزن الحوار ثلاث قيم header فقط. شملت حالة RFC 3261 رقمي تسلسل محلياً وبعيداً، وعناوين URI للطرفين، وremote target، وعلامة أمان، وroute set مرتبة.

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

تسجل route set الوكلاء الذين طلبوا البقاء في مسار الإشارة. يأخذها UAS من Record-Route في الطلب، ويبنيها UAC من الرد بترتيب معكوس. تبين تدفقات RFC 3665 بقاء Call-ID والوسمين في ACK وBYE والردود، بينما تبقي حقول Route الوكلاء المختارين في الطريق.

يجيب remote target عن سؤال مختلف: إلى أي Contact حالي يجب إرسال الطلب التالي؟ ينشأ مع الحوار، ويمكن لطلب target refresh ناجح تغييره. وفي حوار أنشأه INVITE، عرّف RFC 3261 طريقة re-INVITE الأساسية للتحديث.

لا يغير Contact جديد Call-ID أو الوسمين، ولا يعيد كتابة route set. تقول الثلاثية «أي سياق»، وتقول route set «عبر أي وسطاء»، ويقول الهدف «إلى أي عنوان حالي». فصل هذه السلطات منع حقلاً واحداً من التحكم في الارتباط والمسار والحركة معاً.

لم يكن سياق الإشارة هو الصوت

بعد إنشاء الحوار، يستطيع أي نظير بدء معاملة جديدة. يصبح المرسل UAC والمتلقي UAS لتلك المعاملة مهما كانت أدوارهما في INVITE الأصلي. فالعلاقة المستمرة أكثر تناظراً من تبادل عميل وخادم واحد.

وضع RFC 3264 تفاوض الوسائط في نموذج SDP offer/answer. تصف العروض والإجابات التدفقات والترميزات والعناوين والمنافذ، بينما يربط سياق أعلى مثل SIP التبادلات المتعاقبة. ويمكن لعروض لاحقة إضافة وسائط أو حذفها أو تعديلها داخل الحوار نفسه.

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

أضاف RFC 4028 مؤقتات جلسة متفاوضاً عليها وتحديثاً بواسطة re-INVITE أو UPDATE. يمكن للحوارات الناتجة من INVITE واحد أن تحمل فترات مختلفة أو ألا تحمل مؤقتاً. كل تحديث معاملة جديدة داخل السياق؛ النجاح يمدد الجلسة، وغيابه قد يقود إلى BYE. ليست الثلاثية حقاً دائماً في بقاء الحالة.

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

كشفت الامتدادات أيضاً قصور عبارة «حوار واحد، مكالمة واحدة». ينشئ INVITE ما يسمى invite usage، ويمكن لـ SUBSCRIBE أو REFER داخل الحوار إنشاء استخدامات إضافية. يوضح RFC 5057 أنها تشترك في Call-ID والوسوم وCSeq وroute set وعناوين Contact وremote target وعلامة الأمان، مع احتفاظ كل استخدام بحالته مثل مدة الاشتراك.

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

يجعل RFC 6665 الحد ملموساً في إشعارات الأحداث. يستخدم SUBSCRIBE وNOTIFY حالة الحوار، لكن حقل Event يشارك في مطابقة الاشتراك المحدد. وقد ينشئ SUBSCRIBE متفرع حوارات مستقلة يحدث كل منها على حدة. تجد الثلاثية السياق المشترك، لكنها ليست المفتاح الكامل لكل استخدام.

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