تطبيقات الوسائط المتعددة في الشبكات الحاسوبية

تحتاج تطبيقات الوسائط المتعددة مثل الاتصالات الهاتفية وعقد المؤتمرات عبر الفيديو إلى بروتوكولاتها الخاصة، تمامًا مثل التطبيقات التقليدية الموضحة سابقًا، وقد جاءت الخبرة الأولية في تصميم بروتوكولات تطبيقات الوسائط المتعددة من أدوات شبكة MBone، مثل تطبيقات vat وvic التي طُوِّرت للاستخدام على شبكة MBone؛ وهي شبكة تراكب overlay network تدعم البث المتعدد multicast عبر بروتوكول الإنترنت للتمكّن من عقد المؤتمرات متعددة الأطراف.

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

لقد رأينا عددًا من البروتوكولات التي تستخدمها تطبيقات الوسائط المتعددة مثل بروتوكول النقل في الوقت الحقيقي Real-Time Transport Protocol أو اختصارًا RTP الذي يوفّر العديد من الوظائف الشائعة لتطبيقات الوسائط المتعددة مثل نقل معلومات التوقيت وتحديد أنظمة التشفير وأنواع وسائط التطبيق.

يمكن استخدام بروتوكول حجز الموارد Resource Reservation Protocol أو اختصارًا RSVP لطلب تخصيص الموارد في الشبكة، بحيث يمكن توفير جودة الخدمة المطلوبة QoS لأحد التطبيقات. سنرى كيف يتفاعل تخصيص الموارد مع الجوانب الأخرى لتطبيقات الوسائط المتعددة لاحقًا في هذا القسم.

تحتاج العديد من تطبيقات الوسائط المتعددة بالإضافة إلى هذه البروتوكولات الخاصة بنقل الوسائط المتعددة وتخصيص الموارد إلى بروتوكول إصدار إشارات signalling أو بروتوكول التحكم في الجلسة. افترض مثلًا أننا أردنا أن نكون قادرين على إجراء مكالماتٍ هاتفية عبر الإنترنت Voice over IP لنقل الصوت عبر بروتوكول IP أو اختصارًا VoIP، هنا سنحتاج إلى آليةٍ ما لإعلام المستلم المقصود بمثل هذه المكالمة مثل إرسال رسالةٍ إلى بعض أجهزة الوسائط المتعددة التي من شأنها أن تصدر صوت رنين. نود أيضًا أن نكون قادرين على دعم ميزات مثل تمرير المكالمات، والاتصال ثلاثي الاتجاهات وغير ذلك. يُعَد بروتوكول بدء الجلسة Session Initiation Protocol أو اختصارًا SIP وبروتوكول H.323 أمثلةً على البروتوكولات التي تتناول قضايا التحكم في الجلسة.

التحكم في الجلسة والتحكم في المكالمات باستخدام البروتوكولات SDP وSIP وH.323

ضع في بالك المشكلة التالية لفهم بعض مشكلات التحكم في الجلسة. لنفترض مثلًا أنك تريد عقد مؤتمر فيديو في وقتٍ معين وتريد إتاحته لعددٍ كبيرٍ من المشاركين. لربما قررت تشفير تدفق الفيديو باستخدام معيار MPEG-2، واستخدام عنوان IP متعدد البث 224.1.1.1 لنقل البيانات، وإرسال تدفق الفيديو باستخدام بروتوكول RTP عبر منفذ UDP رقم 4000. تتمثل إحدى الطرق لإتاحة كل هذه المعلومات للمشاركين المقصودين في وضعها ضمن رسالة بريدٍ إلكتروني وإرسالها، ولكن يجب من الناحية المثالية أن يكون هناك صيغةً وبروتوكولًا قياسيًا لنشر هذا النوع من المعلومات.

لقد حددت منظمة IETF بروتوكولات لهذا الغرض فقط، حيث تشمل البروتوكولات التالية:

بروتوكول وصف الجلسة Session Description Protocol أو اختصارًا SDP.
بروتوكول إعلان الجلسة Session Announcement Protocol أو اختصارًا SAP.
بروتوكول بدء الجلسة Session Initiation Protocol أو اختصارًا SIP.
بروتوكول التحكم في المؤتمر البسيط Simple Conference Control Protocol أو اختصارًا SCCP.

قد تعتقد أن هذا عددٌ كبير من البروتوكولات من أجل مهمةٍ بسيطة، ولكن هناك العديد من المشاكل والمواقف المختلفة الواجب معالجتها، فمثلًا هناك فرقٌ بين الإعلان عن حقيقة توفير جلسة مؤتمرٍ معينة على شبكة MBone؛ الذي سيُحقق باستخدام بروتوكولَي SDP وSAP وبين محاولة إجراء مكالمةٍ هاتفية عبر الإنترنت مع مستخدمٍ في وقتٍ معين؛ والذي يمكن تحقيقه باستخدام بروتوكولَي SDP وSIP.

يمكنك التفكير في أن مهمتك في الحالة الأولى قد أُنجزت بمجرد إرسال جميع معلومات الجلسة بصيغةٍ قياسية إلى عنوانٍ متعدد البث معروف، أما في الحالة الثانية فستحتاج إلى تحديد موقع مستخدمٍ أو أكثر، وإرسال رسالةٍ إليهم تعلن فيها عن رغبتك في التحدث مثل رنين هواتفهم، وربما التفاوض على تشفيرٍ صوتيٍ مناسب لجميع الأطراف. سنشرح أولًا بروتوكول SDP الشائع في العديد من التطبيقات، ثم سنشرح بروتوكول SIP المُستخدم على نطاقٍ واسع لعددٍ من التطبيقات التفاعلية مثل الاتصال الهاتفي عبر الإنترنت Internet telephony.

بروتوكول وصف الجلسة Session Description Protocol أو اختصارا SDP

بروتوكول SDP هو بروتوكولٌ عام إلى حدٍ ما ويمكن استخدامه ضمن مجموعةٍ متنوعة من المواقف ويستخدم عادةً بالاقتران مع بروتوكولٍ أو أكثر من البروتوكولات الأخرى مثل بروتوكول SIP، وينقل المعلومات التالية:

اسم الجلسة والغرض منها.
أوقات بدء وانتهاء للجلسة.
أنواع الوسائط مثل الصوت والفيديو التي تتألف منها الجلسة.
المعلومات التفصيلية المطلوبة لتلّقي الجلسة، مثل العنوان متعدد البث multicast address الذي ستُرسَل البيانات إليه وبروتوكول النقل المُستخدَم وأرقام المنافذ ونظام التشفير.

يوفّر بروتوكول SDP هذه المعلومات بتنسيق ASCII باستخدام سلسلةٍ من السطور النصية، ويوضّح المثال التالي نموذج رسالة SDP:

v=0
o=Ali 2890844526 2890842807 IN IP4 128.112.136.10
s=Networking 101
i=A class on computer networking
u=http://www.cs.princeton.edu/
e=Ali@cs.princeton.edu
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb

لاحظ أن بروتوكول SDP مثل بروتوكول HTML، فهو يسهّل على الإنسان القراءة إلى حدٍ ما، لكن لديه قواعد تنسيقٍ صارمة تمكّن الأجهزة من تفسير البيانات بصورةٍ لا لبس فيها؛ حيث تحدّد مواصفات بروتوكول SDP جميع أنواع المعلومات الممكنة والمسموح لها بالظهور، والترتيب الذي يجب أن تظهر به، والتنسيق والكلمات المحجوزة لكل نوعٍ محدَّد.

يُحدَّد كل نوعٍ من أنواع المعلومات بحرفٍ واحد، حيث يخبرنا السطر الأول أن قيمة الإصدار version تساوي صفر؛ أي أن هذه الرسالة منسَّقةً وفقًا للإصدار صفر من بروتوكول SDP. ويوفّر السطر التالي "أصل origin" الجلسة التي تحتوي على معلوماتٍ كافية لتعريف الجلسة بصورةٍ فريدة. يشير الاسم Ali إلى اسم مستخدم مُنشئ الجلسة مع عنوان IP لحاسوبه؛ أما الرقم الذي يلي Ali فهو معرّف جلسةٍ اختير ليكون فريدًا لهذا الجهاز. يتبع ذلك رقم الإصدار version إعلان SDP؛ فإذا جرى تحديث معلومات الجلسة برسالةٍ لاحقة، فسيُزاد رقم الإصدار.

توفّر الأسطر الثلاثة التالية i وs وu اسم الجلسة ووصف الجلسة ومعرّف الموارد الموحد للجلسة Uniform Resource Identifier أو اختصارًا URI، وهي معلوماتٌ من شأنها أن تكون مفيدةً للمستخدم في تقرير المشاركة في هذه الجلسة.

يمكن عرض هذه المعلومات في واجهة المستخدم الخاصة بأداة دليل الجلسة التي تعرض الأحداث الحالية والقادمة التي أُعلِن عنها باستخدام بروتوكول SDP. يحتوي السطر التالي e على عنوان البريد الإلكتروني لشخصٍ ما للاتصال به بخصوص الجلسة، ويظهر الشكل الآتي لقطة شاشة لأداة دليل جلسة (والتي أصبحت قديمةً الآن)، حيث تُسمى sdr جنبًا إلى جنب مع أوصاف عدة جلساتٍ أُعلِن عنها في وقت التقاط هذه الصورة.

نصل بعد ذلك إلى التفاصيل التقنية التي من شأنها تمكين برنامج التطبيق من المشاركة في الجلسة، حيث يوفّر السطر c عنوان IP متعدد البث الذي ستُرسَل بيانات هذه الجلسة إليه، لأن المستخدم بحاجةٍ إلى الانضمام إلى مجموعة البث المتعدد هذه لاستقبال الجلسة. نرى بعد ذلك أوقات بدء وانتهاء الجلسة المشفّرة بصورة أعدادٍ صحيحة وفقًا لبروتوكول وقت الشبكة Network Time Protocol. وأخيرًا، نصل إلى معلومات وسائط هذه الجلسة، حيث تحتوي هذه الجلسة على ثلاثة أنواع وسائط متوفرة هي الصوت والفيديو وتطبيق لوح المعلومات المشترك المعروف باسم wb. ويوجد سطرٌ من المعلومات لكل نوع وسائط له التنسيقٍ التالي:

m=<media> <port> <transport> <format>

أرقام المنافذ في كل حالةٍ هي منافذ UDP، فعندما ننظر إلى حقل النقل transport، يمكننا أن نرى أن تطبيق wb يعمل مباشرةً عبر بروتوكول UDP، بينما يُنقَل الصوت والفيديو باستخدام بروتوكول RTP / AVP، وهذا يعني أن الصوت والفيديو يعملان عبر بروتوكول RTP، ويستخدمان ملف تعريف التطبيق application profile المعروف باسم AVP.

يحدد ملف تعريف التطبيق هذا عددًا من مخططات التشفير المختلفة للصوت والفيديو؛ حيث يمكننا أن نرى في هذه الحالة أن الصوت يستخدم الترميز 0، وهو ترميزُ يستخدم معدل أخذ عينات قيمته 8 كيلوهرتز وكل عينةٍ حجمها 8 بتات، ويستخدم الفيديو ترميز 31 الذي يمثل مخطط ترميز H.261. هذه الأرقام السحرية لأنظمة التشفير محددةٌ في وثائق RFC التي تحدد ملف تعريف AVP، ويمكن أيضًا وصف مخططات التشفير غير القياسية في بروتوكول SDP.

أخيرًا، نرى وصفًا لنوع الوسائط wb، حيث أن جميع معلومات الترميز لهذه البيانات خاصةٌ بتطبيق wb، ولذلك يكفي فقط توفير اسم التطبيق في حقل الصيغة format، وهذا مشابهٌ لوضع النوع application/wb في رسالة MIME.

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

يلعب بروتوكول SDP أيضًا دورًا مهمًا بالاقتران مع بروتوكول بدء الجلسة SIP، حيث أصبح بروتوكول SIP الآن أحد الأعضاء المهمين في مجموعة بروتوكولات الإنترنت مع التبني الواسع لبروتوكول Voice over IP أي دعم التطبيقات الشبيهة بالهاتف عبر شبكات IP ومؤتمرات الفيديو القائمة على IP.

بروتوكول SIP

بروتوكول SIP هو بروتوكول طبقة تطبيق يشبه بروتوكول HTTP من خلال استناده إلى نموذج طلب / استجابة request/response model مشابه، لكنه صُمِّم مع وضع أنواعٍ مختلفة من التطبيقات في الحسبان، وبالتالي فإنه يوفر إمكاناتٍ مختلفةً تمامًا عن بروتوكول HTTP. يمكن تجميع القدرات التي يوفرها بروتوكول SIP في خمس فئات هي:

موقع المستخدم User location: لتحديد الجهاز الصحيح الذي يجري الاتصال به للوصول إلى مستخدمٍ معين.
توافرية المستخدم User availability: لتحديد ما إذا كان المستخدم مستعدًا أو قادرًا على المشاركة في جلسة اتصالٍ معينة.
قدرات المستخدم User capabilities: لتحديد عناصر مثل اختيار الوسائط ونظام الترميز المُراد استخدامه.
إعداد الجلسة Session setup: لإنشاء معامِلات الجلسة مثل أرقام المنافذ التي يستخدمها الأطراف المتصلون.
إدارة الجلسة Session management: وهي مجموعةٌ من الوظائف تتضمن نقل الجلسات لتطبيق "تمرير المكالمات" مثلًا وتعديل معاملات الجلسة.

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

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

يقدّم بروتوكول SIP مفهوم الوسيط proxy لتمكين المستخدم من ممارسة المستوى المناسب من التحكم في مكالماته، ويمكن عد وكيل بروتوكول SIP مثل نقطة اتصال لمستخدمٍ تُرسَل إليه الطلبات الأولية للتواصل معه، كما يؤدي الوكلاء أيضًا وظائفًا نيابةً عن المتصلين. ويمكننا أن نرى كيف يعمل الوكلاء بصورةٍ أفضل من خلال المثال الآتي:

ضع في بالك المستخدمين الاثنين الموجودين في الشكل السابق. لاحظ أن لكل مُستخدمٍ اسمًا وفق الصيغة user @ domain الذي يشبه إلى حدٍ كبير عنوان البريد الإلكتروني، فإذا أراد المستخدم أحمد ahmad مثلًا بدء جلسةٍ مع سارة sara، فإنه سيرسل رسالة SIP الأولية الخاصة به إلى الوكيل المحلي لنطاقه الذي هو cisco.com، وتحتوي هذه الرسالة الأولية على معرّف SIP URI الذي هو أحد نماذج معرّف المورد الموحد، والذي يكون على النحو التالي:

SIP:sara@princeton.edu

يوفر معرّف SIP URI تعريفًا كاملًا للمستخدم بدون موقعه على عكس محدّد URL، لأنه يتغير مع مرور الوقت، وسنرى لاحقًا كيفية تحديد موقع المستخدم.

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

يُطلَق على إرسال الرسالة إلى أكثر من جهاز بالاشتقاق forking، ويمكن إجراؤه إما بالتوازي أو على التسلسل، مثل إرسال الرسالة إلى هاتف سارة المحمول إذا لم ترد على الهاتف في مكتبها.

يمكن أن تكون الرسالة الأولية من أحمد إلى سارة رسالة invite دعوة SIP، والتي تكون على النحو التالي:

INVITE sip:sara@princeton.edu SIP/2.0
Via: SIP/2.0/UDP bsd-pc.cisco.com;branch=z9hG4bK433yte4
To: Larry <sip:sara@princeton.edu>
From: Bruce <sip:ahmad@cisco.com>;tag=55123
Call-ID: xy745jj210re3@bsd-pc.cisco.com
CSeq: 271828 INVITE
Contact: <sip:ahmad@bsd-pc.cisco.com>
Content-Type: application/sdp
Content-Length: 142

يحدد السطر الأول نوع الوظيفة المراد تطبيقها invite، والمصدر الذي ستُطبّق الوظيفة عليه، والطرف المُستدعَى sip: sara@princeton.edu، وإصدار البروتوكول 2.0. يمكن أن تكون سطور الترويسة اللاحقة مألوفةً إلى حدٍ ما بسبب تشابهها مع سطور الترويسة ضمن رسالة بريدٍ إلكتروني.

يحدّد بروتوكول SIP عددًا كبيرًا من حقول الترويسة والتي سنشرح بعضها هنا، حيث تحدّد الترويسة Via: في هذا المثال الجهاز الذي نشأت منه هذه الرسالة، وتصِف الترويستان Content-Type: وContent-Length: محتويات الرسالة التي تلي الترويسة، تمامًا كما هو الحال في رسالة البريد الإلكتروني المشفرة باستخدام تقنية MIME؛ حيث يكون المحتوى في هذه الحالة رسالة SDP. تصف هذه الرسالة أمورًا مثل نوع الوسائط (الصوت والفيديو وغير ذلك) التي يرغب أحمد في تبادلها مع سارة، وخصائصًا أخرى للجلسة، مثل أنواع برامج الترميز التي يدعمها، ويوفّر الحقل في بروتوكول SIP القدرة على استخدام أي بروتوكولٍ لهذا الغرض، على الرغم من أن بروتوكول SDP هو الأكثر شيوعًا.

لا يُمرر الوكيل فقط رسالة الدعوة invite إلى princeton.edu عندما تصل هذه الرسالة إلى الوكيل، ولكنه يستجيب أيضًا لمرسل رسالة invite، حيث تحتوي جميع الاستجابات على رمز استجابة تمامًا كما هو الحال في بروتوكول HTTP، وتنظيم الرموز مشابهٌ لتنظيم بروتوكول HTTP. يمكننا أن نرى في الشكل التالي سلسلةً من رسائل واستجابات SIP.

أول رسالة استجابةٍ في هذا الشكل هي الاستجابة المؤقتة 100 trying، التي تُشير إلى استلام وكيل المتصل الرسالة دون خطأ، حيث ينبّه الهاتف "سارة" بمجرد تسليم رسالة invite إليها ويستجيب برسالة 180 ringing. يُعد وصول هذه الرسالة إلى حاسوب أحمد علامةً على أنه يمكن أن يولد "نغمة رنين".

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

لاحظ أن الوسائط تأخذ مسارًا مختلفًا عبر الشبكة عن مسار رسائل إصدار الإشارات الأصلية، حيث يمكن أن تستمر المكالمة بصورةٍ طبيعية حتى إذا تعطل أحد الوكلاء أو كليهما في هذه المرحلة. أخيرًا، يرسل أحد الأطراف رسالة BYE عندما يرغب في إنهاء الجلسة، وتؤدي هذه الرسالة إلى استجابة 200 OK في الظروف العادية.

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

المشكلة الكبيرة الأخرى التي تجاهلناها هي تحديد موقع جهاز سارة الصحيح، حيث كان على حاسوب أحمد أولًا إرسال دعوته invite إلى الوكيل cisco.com، والذي قد يكون جزءًا من المعلومات المضبوطة في الحاسوب أو المُتعلَّمة بواسطة بروتوكول DHCP، ثم يجب على وكيل cisco.com العثور على الوكيل princeton.edu، ويمكن فعل ذلك باستخدام نوعٍ خاص من بحث DNS الذي سيعيد عنوان IP لوكيل SIP للنطاق.

أخيرًا، يجب على وكيل princeton.edu العثور على جهازٍ يمكن الاتصال بسارة من خلاله. يكون للخادم الوكيل حق الوصول إلى قاعدة بيانات الموقع المُمكن ملؤها بعدّة طرق، ويُعد الضبط اليدوي Manual configuration أحد الخيارات، ولكن الخيار الأكثر مرونةً هو استخدام إمكانات التسجيل الخاصة ببروتوكول SIP.

يمكن للمستخدم التسجيل في خدمة الموقع عن طريق إرسال رسالة register تسجيل SIP إلى مسجّل registrar نطاقه. تنشئ هذه الرسالة ارتباطًا بين "عنوان السجل" و"عنوان جهة الاتصال". يُحتمَل أن يكون "عنوان السجل" معرّف SIP URI، وهو العنوان المعروف للمستخدم مثل sip: sara@princeton.edu، وسيكون عنوان جهة الاتصال هو العنوان الذي يمكن العثور على المستخدم عليه حاليًا مثل sip: sara@llp-ph.cs.princeton.edu، وهذا هو بالضبط الارتباط الذي طلبه الوكيل princeton.edu في مثالنا.

لاحظ أنه يجوز للمستخدم التسجيل في عدّة مواقع ويجوز لعدّة مستخدمين التسجيل على جهازٍ واحد. يمكنك أن تتخيل مثلًا مجموعةً من الأشخاص يدخلون غرفة اجتماعات مجهزةً بهاتف IP وجميعهم يسجّلون فيه ليتمكنوا من تلّقي المكالمات على هذا الهاتف.

بروتوكول SIP هو بروتوكولٌ غنيٌ جدًا ومرن، إذ يمكنه دعم مجموعةٍ واسعةٍ من سيناريوهات الاتصال المعقدة بالإضافة إلى التطبيقات التي تستطيع التعامل مع الاتصالات الهاتفية قليلًا، أو التي ليس لها علاقة بالاتصالات الهاتفية، حيث يدعم بروتوكول SIP مثلًا العمليات التي تتيح توجيه المكالمة إلى خادم الموسيقى قيد الانتظار music-on-hold، أو خادم البريد الصوتي. يمكن أيضًا معرفة كيفية استخدام بروتوكول SIP مع تطبيقاتٍ مثل المراسلة الفورية، كما أن توحيد إضافات بروتوكول SIP لهذه الأغراض مستمر.

بروتوكول H.323

كان الاتحاد الدولي للاتصالات International Telecommunication Union أو اختصارًا ITU نشطًا جدًا أيضًا في مجال التحكم في المكالمات، وهو أمرٌ لا يثير الدهشة، نظرًا لارتباطه بالهاتف، وهو المجال التقليدي لتلك الهيئة. كان هناك تنسيقٌ كبيرٌ بين منظمة IETF والاتحاد الدولي للاتصالات في هذه الحالة، بحيث تكون البروتوكولات المختلفة قابلةً للتشغيل البيني إلى حدٍ ما.

تُعرَف التوصية الرئيسية الصادرة عن الاتحاد الدولي للاتصالات ITU من أجل الاتصالات متعددة الوسائط عبر شبكات الرزم باسم H.323، وهي تربط بين العديد من التوصيات الأخرى بما في ذلك H.225 للتحكم في المكالمات. تصل مجموعةٌ كاملة من التوصيات التي يغطيها بروتوكول H.323 إلى عدة مئاتٍ من الصفحات، وبما أن البروتوكولات معروفةٌ بتعقيدها، فسنقدّم فقط لمحةً موجزةً عنه هنا.

يُعَد بروتوكول H.323 شائعًا في مجال الاتصالات الهاتفية عبر الإنترنت، بما في ذلك مكالمات الفيديو، حيث يُعرف الجهاز الذي يصدر أو ينهي المكالمات باسم طرفية H.323؛ فقد تشغّل محطة عمل تطبيقًا للاتصالات الهاتفية عبر الإنترنت، أو قد تكون جهازًا مصممًا بصورةٍ خاصة مثل جهاز يشبه الهاتف مع برمجياتٍ شبكية ومنفذ ايثرنت على سبيل المثال. يمكن لطرفيات H.323 التحدث مع بعضها البعض مباشرةً، ولكن غالبًا يتوسّط جهازٌ في المكالمات يُعرَف باسم حارس البوابة gatekeeper. يطبّق حارس البوابة عددًا من الوظائف مثل الترجمة بين صيغ العناوين المختلفة المستخدمة للمكالمات الهاتفية والتحكم في عدد المكالمات الممكن إجراؤها في وقتٍ معين للحد من حيز النطاق التراسلي bandwidth المُستخدم من قِبل تطبيقات H.323.

يتضمن بروتوكول H.323 أيضًا مفهوم البوابة gateway التي تربط شبكة H.323 بأنواعٍ أخرى من الشبكات، ويُعَد الاستخدام الأكثر شيوعًا للبوابة هو توصيل شبكة H.323 بشبكة تبديل الهاتف العامة public switched telephone network أو اختصارًا PSTN كما هو موضحُ في الشكل الآتي، وهذا يمكّن المستخدم الذي يشغل تطبيق H.323 على حاسوبٍ من التحدث إلى شخصٍ يستخدم هاتفًا تقليديًا على شبكة الهاتف العامة.

تتمثل إحدى الوظائف المفيدة التي يؤديها حارس البوابة في مساعدة الطرفيات في العثور على بوابة، وربما الاختيار من بين عدة خياراتٍ للعثور على بوابةٍ قريبة نسبيًا من وجهة المكالمة النهائية، ومن الواضح أن هذا مفيدٌ في عالمٍ يفوق فيه عددُ الهواتف التقليدية عددَ الهواتف القائمة على الحاسوب. تصبح البوابة هي نقطة النهاية الفعالة لمكالمة H.323 عندما تجري طرفية H.323 مكالمةً إلى نقطة نهاية، والتي هي هاتفٌ تقليدي، وتكون مسؤولةً عن إجراء الترجمة المناسبة لكلًّ من معلومات إصدار الإشارات وتدفق الوسائط الذي يجب أن تُنقَل عبر شبكة الهاتف.

بروتوكول H.245 هو جزءٌ مهم من بروتوكول H.323، ويُستخدَم للتفاوض على خصائص المكالمة بصورةٍ مشابهة إلى حدٍ ما لاستخدام بروتوكول SDP الموصوف أعلاه. قد تعطي رسائل H.245 قائمةً بعددٍ من معايير ترميز الصوت المختلفة التي يمكن أن تدعمها؛ حيث ستعطي نقطة نهاية المكالمة البعيدة قائمةً ببرامج الترميز المدعومة الخاصة بها، ويمكن للطرفين اختيار معيار ترميزٍ يمكن لكليهما التأقلم معه، كما يمكن أيضًا استخدام بروتوكول H.245 للإشارة إلى أرقام منافذ UDP التي سيستخدمها بروتوكول RTP وبروتوكول التحكم في الوقت الحقيقي Real-Time Control Protocol أو اختصارًا RTCP، لتدفق الوسائط (أو التدفقات، فقد تتضمن المكالمة كلًا من الصوت والفيديو على سبيل المثال) لهذه المكالمة. ويمكن أن تستمر المكالمة بمجرد الانتهاء من ذلك، مع استخدام بروتوكول RTP لنقل تدفقات الوسائط ويحمل بروتوكول RTCP معلومات التحكم ذات الصلة.

تخصيص الموارد لتطبيقات الوسائط المتعددة

يمكن استخدام بروتوكولات التحكم في الجلسة مثل بروتوكولَي SIP وH.323 لبدء الاتصال والتحكم فيه في تطبيقات الوسائط المتعددة، بينما يوفر بروتوكول RTP وظائفًا على مستوى النقل لتدفقات بيانات التطبيقات. يجب التأكد أيضًا من تخصيص الموارد المناسبة داخل الشبكة لضمان تلبية احتياجات جودة خدمة التطبيق، وقد قدّمنا عددًا من الأساليب لتخصيص الموارد في مقال سابق.

لقد كان الدافع وراء تطوير هذه التقنيات إلى حدٍ كبير هو دعم تطبيقات الوسائط المتعددة. إذًا، كيف تستفيد التطبيقات من إمكانات تخصيص موارد الشبكة الأساسية؟ تجدر الإشارة إلى أن العديد من تطبيقات الوسائط المتعددة تعمل بنجاح ضمن شبكات أفضل جهد best-effort، مثل الإنترنت العام، وتُعَد المجموعة الواسعة من خدمات VoIP التجارية مثل Skype برهانًا على حقيقة أنه لا داعي للقلق إلا بشأن تخصيص الموارد عندما لا تكون الموارد وفيرة.

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

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

يمكن استخدام الخدمات المميزة Differentiated Services أو اختصارًا DiffServ لتوفير تخصيصٍ أساسي إلى حدٍ ما وقابلٍ للتطوير لموارد التطبيقات، كما يمكن لتطبيق الوسائط المتعددة ضبط نقطة رمز الخدمات المتميزة differentiated services code point أو اختصارًا DSCP في ترويسة IP للرزم التي يولّدها في محاولةٍ لضمان حصول كل من رزم الوسائط ورزم التحكم على جودة الخدمة المناسبة.

يمكن وضع علامةٍ على رزم الوسائط الصوتية على أنها EF للدلالة على تمرير سريع expedited forwarding على سبيل المثال، لكي تُوضَع في رتلٍ ذو زمن انتقالٍ منخفض أو ذو أولويةٍ منخفضة في الموجهات على طول المسار، بينما تُوضَع علامةٌ على رزم إصدار إشارات الاتصال مثل رزم SIP مثلًا على أنها من النوع AF للدلالة على تمريرٍ مضمون assured forwarding، لتمكينها من البقاء في الرتل بصورةٍ منفصلة عن حركة مرور الأفضل جهدًا، وبالتالي تقليل مخاطر الخسارة.

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

خدمات DiffServ جذابةٌ لبساطتها، لكنها لا تستطيع تلبية احتياجات التطبيقات في جميع الظروف. افترض مثلًا أن حيز نطاق المنبع التراسلي في الشكل السابق هو 100 كيلو بت في الثانية فقط، ويحاول العميل إجراء مكالمتَي VoIP؛ كلٌ منهما باستخدام برنامج ترميز 64 كيلو بت في الثانية، وبالتالي فإن الرابط الصاعد مُحمَّلٌ الآن بنسبة تزيد عن 100%، مما سيؤدي إلى تأخيرٍ كبير في الرتل وفقدانٍ للرزم، ولا يمكن لأي قدرٍ من الانتظار الذكي في رتل موجّه العميل إصلاح ذلك.

خصائص العديد من تطبيقات الوسائط المتعددة هي من نفس القبيل، فبدلًا من محاولة ضغط الكثير من المكالمات في أنبوبٍ ضيقٍ للغاية، سيكون من الأفضل حظر مكالمةٍ واحدة، مع السماح لمكالمةٍ أخرى بالمتابعة؛ أي يُفضَّل أن يكون هناك شخصٌ ما يجري محادثةً بنجاح بينما يسمع شخصٌ آخر إشارة مشغول بدلًا من جعل كلا المتصلين يختبران جودة صوت غير مقبولةٍ في نفس الوقت. نشير في بعض الأحيان إلى مثل هذه التطبيقات على أنها ذات منحنى استخداميةٍ حاد steep utility curve، مما يعني انخفاض استخدامية أو فائدة التطبيق بسرعةٍ، مع تدهور جودة الخدمة التي تقدمها الشبكة. تحتوي تطبيقات الوسائط المتعددة على هذه الخاصية، في حين لا تمتلكها العديد من التطبيقات التقليدية، ويستمر البريد الإلكتروني مثلًا في العمل جيدًا حتى لو وصلت التأخيرات إلى ساعات.

تكون التطبيقات ذات منحنيات الاستخدامية شديدة الانحدار مناسبةً تمامًا لبعض أشكال التحكم في القبول؛ فإذا لم تكن متأكدًا من توفر الموارد الكافية دائمًا لدعم الحِمل المقدَّم للتطبيقات، فإن التحكم في القبول يوفر طريقةً لقول "لا" لبعض التطبيقات مع السماح للآخرين بالحصول على الموارد التي تحتاجها.

رأينا طريقةً للتحكم في القبول باستخدام بروتوكول RSVP في مقال سابق، وسنعود إلى ذلك قريبًا، ولكن توفّر تطبيقات الوسائط المتعددة التي تستخدم بروتوكولات التحكم في الجلسة بعضَ خيارات التحكم في القبول الأخرى؛ أما النقطة الأساسية الواجب ملاحظتها هنا، فهي أن بروتوكولات التحكم في الجلسة مثل بروتوكولي SIP أو H.323، أي أنها تتضمن غالبًا نوعًا من تبادل الرسائل بين نقطة نهاية وكيانٍ آخر مثل وكيل SIP أو حارس بوابة H.323 في بداية مكالمةٍ أو جلسة، ويمكن أن يوفر هذا وسيلةً سهلةً لقول "لا" لمكالمةٍ جديدة لا تتوفر لها مواردٌ كافية.

ضع في حساباتك الشبكة في الشكل الآتي على سبيل المثال، وافترض أن الرابط الواسع من المكتب الفرعي إلى المكتب الرئيسي لديه حيز نطاقٍ تراسلي كافٍ لاستيعاب ثلاثة مكالمات VoIP في وقتٍ واحد باستخدام برامج ترميز 64 كيلوبت في الثانية. يحتاج كل هاتفٍ إلى الاتصال بوكيل SIP المحلي أو حارس بوابة H.323 عندما يبدأ في إجراء مكالمة، لذلك من السهل على الوكيل / حارس البوابة إرسال رسالةٍ تخبر هاتف IP بتشغيل إشارة مشغول إذا حمِّل هذا الرابط بالكامل، ويمكن كذلك للوكيل أو حارس البوابة التعامل مع احتمال إجراء هاتف IP معين مكالماتٍ متعددة في نفس الوقت واستخدام سرعاتٍ مختلفة لبرنامج الترميز، ولكن لن يعمل هذا المخطط إلا إذا لم يتمكن أي جهازٍ آخر من زيادة التحميل على الرابط دون التحدث أولًا إلى حارس البوابة أو الوكيل.

يمكن استخدام رتل خدمة DiffServ للتأكد من عدم تداخل الحاسوب المشارك في نقل الملفات مع مكالمات VoIP على سبيل المثال، ولنفترض أن بعض تطبيقات VoIP التي لا تتحدث أولًا إلى حارس البوابة أو الوكيل مفعَّلةٌ في المكتب البعيد؛ فإذا استطاع مثل هذا التطبيق وضع علامةٍ على رزمه بصورةٍ مناسبة وفي نفس رتل حركة مرور VoIP الحالية، فيمكن أن يقود الرابط إلى نقطة التحميل دون أي استجابةٍ من الوكيل أو حارس البوابة.

يشير اعتماد النهج الموصوف للتو، على أن حارس البوابة أو الوكيل لديه معرفةٌ بالمسار الذي سيستخدمه كل تطبيق مشكلةً، لكنها ليست كبيرةً في مخطط الشبكة البسيط الموضح في الشكل السابق، بينما يمكن أن تصبح متسارعةً وغير قابلةٍ للإدارة في الشبكات الأكثر تعقيدًا. نحتاج فقط إلى تخيُّل الحالة التي يكون فيها للمكتب البعيد اتصالين مختلفين بالعالم الخارجي لنرى أننا نطلب من الوكيل أو حارس البوابة فهم التوجيه وفشل الروابط وظروف الشبكة الحالية، إضافةً لفهم بروتوكول SIP أو H.323، ويمكن أن يصبح هذا أيضًا غير قابل للإدارة بسرعة.

نشير إلى نوع التحكم في القبول الموصوف للتو على أنه بعيدٌ عن المسار off-path؛ بمعنى أن الجهاز الذي يتخذ قرارات التحكم في القبول غير موجودٍ على مسار البيانات، حيث يلزم تخصيص الموارد. البديل الواضح هو التحكم في القبول على المسار، والمثال القياسي للبروتوكول الذي يتحكم في القبول على المسار في شبكات IP هو بروتوكول حجز الموارد RSVP.

لقد رأينا في مقال سابق كيفية استخدام بروتوكول RSVP لضمان تخصيص مواردٍ كافية على طول المسار، ويُعَد استخدام بروتوكول RSVP في تطبيقات مثل التطبيقات الموضحة في هذا القسم أمرًا سهلًا.

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

لا يمكنك إجراء جميع عناصر التحكم في الجلسة أولًا، لأنك لا تريد أن يرن الهاتف قبل اتخاذ قرار التحكم في القبول الذي من الممكن أن يفشل. ويوضح الشكل السابق هذا الموقف، حيث يُستخدَم بروتوكول SIP للتحكم في الجلسة ويُستخدَم بروتوكول RSVP لاتخاذ قرار التحكم في القبول بنجاحٍ في هذه الحالة.

تمثل الخطوط المتصلة في الشكل السابق رسائل SIP، بينما تمثل الخطوط المتقطعة رسائل RSVP. لاحظ أن رسائل SIP تنتقل بالاتجاه من هاتفٍ إلى آخر في هذا المثال (لم نُظهِر وكلاء SIP)، بينما تُعالَج رسائل RSVP أيضًا بواسطة الموجّهات للتحقق من وجود الموارد الكافية لقبول المكالمة، حيث نبدأ بتبادلٍ أوَّلي لمعلومات الترميز في أول رسالتين من SIP مع التذكير بأن بروتوكول SDP يُستخدم لإعطاء قائمةٍ ببرامج الترميز المتاحة.

الإشعار PRACK هو إشعارٌ مؤقت provisional acknowledgment، ويمكن إرسال رسائل RSVPPATH، التي تحتوي على وصفٍ لمقدار الموارد المطلوبة في الخطوة الأولى في حجز الموارد في كلا اتجاهي المكالمة، ويمكن بعد ذلك إرسال رسائل RESV مرةً أخرى لحجز الموارد. يستطيع هاتف البدء بمجرد استلامه لرسالة RESV إرسال رسالة SDP محدثة تبلّغ عن حقيقة أن الموارد قد حُجزِت في اتجاهٍ واحد. إذا استقبل الهاتف المُتَّصل به هذه الرسالة واستقبل رسالة RESV من الهاتف الآخر، فيمكنه البدء في الرنين وإخبار الهاتف الآخر بأن الموارد محجوزةً الآن في كلا الاتجاهين مع رسالة SDP، وإعلام الهاتف المتصل أيضًا بأنه يرن، ويستمر إصدار إشارات SIP العادية وتدفق الوسائط من الآن فصاعدًا.

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

ترجمة -وبتصرّف- للقسم Multimedia Applications من فصل Applications من كتاب Computer Networks: A Systems Approach.