SIP والصوت لفرق المراسلة

بروتوكول بدء الجلسة (SIP، RFC 3261) هو بروتوكول إشارة على مستوى التطبيق يُستخدم لإنشاء جلسات الوسائط في الوقت الفعلي عبر IP، وتعديلها، وإنهائها، وغالبًا ما تكون هذه الجلسات صوتية أو مرئية. والجدير بالذكر أن SIP لا ينقل الوسائط نفسها، بل يتفاوض على الجلسة ويتحكم بها، ثم يتدفق الصوت أو الفيديو بشكل منفصل عبر RTP .

صُمم النظام عمدًا ليُحاكي بروتوكول HTTP، حيث يوفر رسائل نصية سهلة القراءة، وطرق طلب، ورموز استجابة مكونة من ثلاثة أرقام، وعناوين URI (مثل sip:alice@example.com)، مما يجعله سهل الاستخدام للفرق المُلمّة ببروتوكولات الويب. لهذا السبب، يتكامل الصوت بسلاسة مع المراسلة في منصة الاتصالات السحابية (CPaaS): فهو قناة أخرى تعتمد على واجهة برمجة API مع بنية طلب/استجابة مألوفة.

الجهات الفاعلة الرئيسية هي وكلاء المستخدم (وكيل مستخدم يرسل الطلبات ووكيل مستخدم يجيب عليها)، بالإضافة إلى البنية التحتية: يسجل المسجلون أماكن إمكانية الوصول إلى المستخدم، وتوجه الخوادم الوسيطة الطلبات إليه. بالنسبة لفريق المراسلة، غالبًا ما يكون الصوت هو قناة الرجوع الاحتياطية لرموز OTP وقناة التنبيهات العاجلة - لذا فإن فهم SIP يعني فهم كيفية اتصال هذه القناة فعليًا.

يُعرّف SIP مجموعة صغيرة من طرق الطلب. تبدأ INVITE جلسة أو تُعدّلها، وتؤكد ACK الاستجابة النهائية لطلب INVITE، وتُنهي BYE مكالمة قائمة. تُخبر REGISTER المُسجّل بمكان إمكانية الوصول إلى المستخدم، وتُنهي CANCEL طلبًا مُعلقًا، وتستعلم OPTIONS عن الإمكانيات. أضافت وثائق RFC اللاحقة طرقًا مثل INFO وMESSAGE وSUBSCRIBE/NOTIFY وUPDATE.

تُحاكي الاستجابات نظام HTTP المكون من ثلاثة أرقام في ست فئات. 1xx هي استجابات مؤقتة (100 محاولة، 180 رنين)؛ 2xx استجابات ناجحة (200 موافق)؛ 3xx استجابات إعادة توجيه؛ 4xx هي أخطاء من جانب العميل (404 غير موجود، 486 مشغول هنا، 407 مطلوب مصادقة الوكيل)؛ 5xx هي أخطاء من جانب الخادم؛ و6xx هي حالات فشل عامة (603 رفض). قراءة الفئة أولاً، ثم الكود، هي الطريقة الأمثل لتحديد سبب فشل المكالمة بسرعة.

من أبرز خصائص بروتوكولات الاتصالات التي يجب استيعابها هي عملية المصافحة الثلاثية لإعداد المكالمات: INVITE، ثم استجابة 200 OK، ثم استجابة ACK منفصلة - على عكس معظم بروتوكولات الطلب/الاستجابة، تُعتبر استجابة ACK لطلب INVITE معاملة مستقلة. ويُعدّ سوء التعامل مع هذه الاستجابة أحد أكثر الأسباب شيوعًا للمكالمات التي لا تُجرى دون اتصال.

بما أن SIP لا يستخدم سوى الإشارات، فإن معلمات الوسائط الفعلية تُوصف بواسطة بروتوكول وصف الجلسة (SDP، RFC 4566)، المُضمنة في محتوى رسائل SIP . في بروتوكول SDP، يُعلن كل طرف عن برامج الترميز التي يدعمها، وعنوان IP والمنفذ الذي سيستقبل الوسائط عليه، بالإضافة إلى سمات الوسائط الأخرى.

يستخدم SIP نموذج العرض/الاستجابة (RFC 3264): يحمل INVITE من المُرسِل عرض SDP يُفصّل إمكانياته، بينما يحمل رد المُستقبِل إجابة SDP تُحدّد المجموعة الفرعية المشتركة. هذه المفاوضة هي ما يسمح لنقطتي النهاية بالاتفاق على برنامج الترميز ومسار الوسائط قبل بدء تدفق الصوت.

تنتقل الوسائط المتفق عليها عبر بروتوكول النقل في الوقت الحقيقي (RTP)، الذي يحمل حزم الصوت والفيديو مع أرقام التسلسل والطوابع الزمنية، بالإضافة إلى بروتوكول التحكم في الوقت الحقيقي (RTCP) لضمان جودة الاتصال. وعندما تكون الوسائط سرية، يقوم SRTP في الوقت الحقيقي (RTP) بتشفير هذه الحزم والتحقق من صحتها. والنموذج الذهني الذي يجب تذكره هو: بروتوكول بدء الجلسة (SIP) وبروتوكول وصف الجلسة (SDP) يُنشئان المكالمة، بينما ينقلها RTP و SRTP - مساران منفصلان قد يسلكان مسارات مختلفة عبر الشبكة.

تتبع مكالمة بسيطة. يرسل نظام التحكم في حساب المستخدم (UAC) الخاص بالمتصل INVITE (مع عرض SDP) إلى المتلقي، ربما عبر خادم وسيط واحد أو أكثر. يرد المتلقي برسالة 100 "جاري المحاولة"، ثم 180 "جاري الرنين" أثناء تنبيه الهاتف، وأخيرًا 200 "موافق" حاملاً رد SDP بمجرد قبول المتلقي.

يرد المتصل برسالة تأكيد (ACK)، وفي تلك اللحظة يتم إنشاء الجلسة: تتدفق وسائط RTP مباشرةً بين نقاط النهاية وفقًا لبروتوكول وصف الجلسة SDP المتفق عليه، بغض النظر عن الخوادم الوسيطة التي أنشأت المكالمة. أما التغييرات التي تحدث أثناء المكالمة - مثل تعليق المكالمة، أو إضافة فيديو، أو تغيير برامج الترميز - فتستخدم طلب إعادة الدعوة (re-INVITE) أو تحديث (UPDATE) يحمل بروتوكول وصف جلسة SDP جديدًا.

يُنهي أيٌّ من الطرفين المكالمة بإرسال رسالة BYE، ويُجاب عليها برمز 200 OK، مما يُنهي الجلسة ويوقف نقل الوسائط. أما حالات الفشل فتؤدي إلى تعطيل سير المكالمة: فمثلاً، يُشير ظهور رمز 486 Busy Here أو 408 Request Timeout بدلاً من 200 OK إلى أن المكالمة لا تصل إلى مرحلة تأكيد الاتصال (ACK). إن رؤية هذا التسلسل الكامل هو ما يجعل سجلات SIP قابلة للقراءة عند حدوث خلل في المكالمة.

خط SIP هو اتصال قائم على SIP بين نظام هاتف خاص (PBX) أو تطبيق ومزود خدمة، يحل محل الخطوط المادية التقليدية وينقل المكالمات من وإلى الشبكة العامة عبر IP . وهو الوسيلة التي تصل بها المكالمات الصوتية المبرمجة إلى شبكة الهاتف العامة PSTN على نطاق واسع.

يقع مُتحكّم حدود الجلسة (SBC) على حدود الشبكة، وهو العنصر المسؤول عن تأمين SIP والتحكم فيه على حافة الشبكة. يقوم هذا المُتحكّم بإخفاء بنية الشبكة، واجتياز ترجمة عناوين الشبكة (NAT)، والتوافق بين البروتوكولات، وتوحيدها بين لهجات SIP المختلفة، والتحكم في الوصول وتحديد معدل نقل الرسائل، وغالبًا ما يقوم بتثبيت الوسائط وتحويل ترميزها. يُشبه دور مُتحكّم حدود الجلسة SBC في SIP دور جدار حماية الإشارات في بروتوكول SS7 / Diameter : فهو بمثابة نقطة تفتيش مُتحكّم بها على حدود الثقة.

VoLTE (الصوت عبر LTE) هي خدمة صوتية تُنقل عبر شبكة بيانات LTE باستخدام IMS، وتتم إدارة مكالماتها بواسطة SIP المشغّل داخل IMS - وهو نفس البروتوكول الذي تعلمته للتو، ولكن من خلال واجهات Cx / HSS وسياسات الشبكة الأساسية للهاتف المحمول. لذا، فإن SIP الذي يستخدمه فريق المراسلة للمكالمات الصوتية القابلة للبرمجة، وبروتوكول SIP الذي يتحكم في مكالمة VoLTE هما نفس البروتوكول، ويختلفان في الشبكة المحيطة، وليس في الإشارات نفسها.