أخبار تكنلوجيا

تحتاج تطبيقات الوسائط المتعددة مثل الاتصالات الهاتفية وعقد المؤتمرات عبر الفيديو إلى بروتوكولاتها الخاصة، تمامًا مثل التطبيقات التقليدية الموضحة سابقًا، وقد جاءت الخبرة الأولية في تصميم بروتوكولات تطبيقات الوسائط المتعددة من أدوات شبكة 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 أمثلةً على البروتوكولات التي تتناول قضايا التحكم في الجلسة.

ضع في بالك المشكلة التالية لفهم بعض مشكلات التحكم في الجلسة. لنفترض مثلًا أنك تريد عقد مؤتمر فيديو في وقتٍ معين وتريد إتاحته لعددٍ كبيرٍ من المشاركين. لربما قررت تشفير تدفق الفيديو باستخدام معيار 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.

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

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

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

لاحظ أن بروتوكول 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. ويوجد سطرٌ من المعلومات لكل نوع وسائط له التنسيقٍ التالي:

أرقام المنافذ في كل حالةٍ هي منافذ 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 هو بروتوكول طبقة تطبيق يشبه بروتوكول 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 URI تعريفًا كاملًا للمستخدم بدون موقعه على عكس محدّد URL، لأنه يتغير مع مرور الوقت، وسنرى لاحقًا كيفية تحديد موقع المستخدم.

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

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

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

يحدد السطر الأول نوع الوظيفة المراد تطبيقها invite، والمصدر الذي ستُطبّق الوظيفة عليه، والطرف المُستدعَى sip: [email protected]، وإصدار البروتوكول 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: [email protected]، وسيكون عنوان جهة الاتصال هو العنوان الذي يمكن العثور على المستخدم عليه حاليًا مثل sip: [email protected]، وهذا هو بالضبط الارتباط الذي طلبه الوكيل princeton.edu في مثالنا.

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

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

كان الاتحاد الدولي للاتصالات 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.

• المقال السابق: تطبيقات الشبكات الحاسوبية: خدمات الويب
• الإصدار السادس من بروتوكول IP
• الشبكات الفرعية والعناوين والأخطاء في بروتوكول IP
• النقل الموثوق (Reliable Transmission) في الشبكات الحاسوبية

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

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

من جانبه، قال متحدث باسم التطبيق الشهير: "إننا نجعل من السهل التواصل تلقائيا مع مجموعاتك. انضم إلى المكالمات الجارية مع مجموعاتك في أي وقت، ومن دون مجهود وبشكل مباشر من عرض الدردشة بنقرة واحدة"، وفق ما نقلته صحيفة "ذي صن" البريطانية.

ويعني الزر الجديد أنه يمكنك الاتصال بمجموعة "واتس آب" (أو الانضمام إلى مكالمة) من الدردشة نفسها.

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

وستظهر المكالمة أيضا في قائمة الدردشة، بحيث يمكنك بسرعة وسهولة معرفة المجموعات التي لديها مكالمات جارية.

وتقول شركة "واتساب" أيضا إن الزر الجديد يقدم "نغمة رنين مميزة أخف".

يشار إلى أن التحديث الجديد أصبح متاحا الآن على نطاق واسع، وبمجرد التحديث، ستكون قادرا على رؤية التصميم الجديد.

يذكر أنه في وقت سابق من هذا العام، أعلنت شركة "واتساب" عن إضافة المكالمات الجماعية القابلة للانضمام، ما يعني أنه يمكن الانضمام إلى مكالمات "واتساب" الجماعية الجارية بعد بدئها، بدلا من تفويت المحادثة إذا لم تقبل دعوة الاتصال من البداية.

أعلنت منصة سناب شات أنها تطلق ستوديو إبداعيا عالميا جديدا للواقع المعزز Arcadia لمساعدة العلامات التجارية في إنشاء إعلانات وتجارب واقع معزز.

وأطلق الاستوديو أول مشاريعه في الواقع المعزز بالتعاون مع سلسلة الوجبات السريعة شيك شاك Shake Shack. ويمكن لزوار المطعم في نيويورك فتح تطبيق سناب شات ومسح الكود لتجربة منتجات Snap Shack وشراء العناصر.

يأتي ذلك كجزء من خطوة للترويج لاستخدام التكنولوجيا التي يمكن أن تراكب الصور التي تم إنشاؤها بواسطة الحاسب في العالم الحقيقي.

وقالت الشركة إن Arcadia يمثل أحدث عضو في نظام الواقع المعزز البيئي الخاص بها. الذي يتضمن أيضًا أكثر من 40 شريكًا. بالإضافة إلى أدوات مثل Lens Web Builder و Creator Marketplace، الذي تم تقديمه في شهر مايو.

كما استشهدت الشركة بدراسة حديثة بتكليف من Deloitte وجدت أن 94% من المشاركين توقعوا استخدام الواقع المعزز للتسوق بشكل أكبر في عام 2022 مقارنة بعام 2021.

وخلال برنامج الشركة التجريبي الأخير للواقع المعزز مع أكثر من 30 علامة تجارية عبر عدة قطاعات، جرب مستخدمو سناب شات المنتجات أكثر من 250 مليون مرة. وكان احتمال نقرهم للشراء 2.4 مرة أكثر من أولئك الذين لم يستخدموا هذه الميزة.

كذلك، أضافت الشركة إن هدف Arcadia هو تطوير تقنية جديدة وتقديم تجربة AR فعالة ومؤثرة ومبتكرة لشركاء الوكالة والعلامة التجارية.

وأصبح تطبيق الرسائل المصورة شائعًا لأول مرة بين المستخدمين الشباب لأشكاله المبكرة من الواقع المعزز، مثل فلاتر الصور.

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

من جانبه، قال جيف ميلر، الرئيس العالمي للاستراتيجية الإبداعية في شركة سناب: إن الاستوديو الجديد يساعد العلامات التجارية في بناء تجارب الواقع المعزز. وذلك من أجل سناب شات أو أي تطبيقات أو مواقع تواصل اجتماعي أخرى.

ويهدف الاستوديو الجديد إلى دفع حدود ما هو ممكن في الواقع المعزز. وقالت الشركة إن P&G Beauty وشركة الاتصالات فيريزون وشركة الترفيه WWE هم أول عملاء Arcadia المسجلين، مما يعني أن الاستوديو يتعامل مع جميع أعمال الواقع المعزز واستراتيجيات العلامات التجارية.

ويعمل Arcadia، الموجود كقسم من أقسام شركة سناب، أيضًا مع الشركات القائمة على المشاريع. أو يقدم المشورة للعلامات التجارية والوكالات الإعلانية من خلال ورش العمل.

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

وقالت شركة كراودسترايك، أمس الثلاثاء، إن المجموعة التي أطلق عليها اسم "لايت بازين"، تعمل منذ 2016 على الأقل لكنها رُصدت على نحو أكبر في الآونة الأخيرة، تستخدم أدوات كانت من بين تلك الأكثر تطورا التي تُكتشف، بحسب بما نقلت "رويترز".

في حين أوضح النائب الأول لرئيس الشركة، آدم مايرز أن شركته جمعت هذه المعلومات من خلال الاستجابة لحوادث في عدة دول رفض أن يُعلن عنها.

وقال إن البرامج يمكنها استرداد بيانات محددة دون انقطاع، مضيفاً: "لم أر أبدا مثل هذه الأدوات المصممة لهذا الغرض". رافضاً أن يكشف الدول التي رصد فيه هذه الهجمات السيبرانية.

كما أشار مايرز إلى أن هذه الهجمات كانت تجري بطريقة حاذقة وماهرة للغاية، حتى أنها لا تجذب أي انتباه، ولا تثير أي شكوك من حولها "لم يسبق لي أن رأيت أدوات أنشئت بهذه الدقة حتى تحقق الأهداف المرجوة منها".

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

وأورد المتحدث أن الشركة رصدت تقنيات سبق أن استخدمت في هجمات قيل إن الحكومة الصينية هي التي تقف وراءها.

في المقابل، أوردت رويترز أن شبكة القراصنة التي تتهم بهذا التسلل لها علاقة بالصين، على غرار هجمات إلكترونية كثيرة قيل إنها جرت بموافقة من دول مثل روسيا وإيران.

إلى ذلك، قامت الشركة الأميركية، بنشر تفاصيل التقنية الاثنين، بشأن الهجوم الواسع، في مسعى إلى تمكين شركات أخرى من إجراء عمليات تحقق مماثلة.

وكان الرئيس الأميركي جو بايدن قد وجه في وقت سابق، الاتهام للصين بحماية منفذي الهجمات السيبرانية، محذرا من مخاطر حماية القراصنة الإلكترونيين.

وعبر البيت الأبيض عن احتفاظ الولايات المتحدة بحقها في اتخاذ إجراءات إضافية على هجمات الصين السيبرانية. فيما تنفي بكين مسؤوليتها عن هذه الهجمات.

عندما كشفت شركة سامسونج عن هاتفها الذكي القابل للطي، Galaxy Z Flip 3 ، في شهر أغسطس الماضي، وفرته مع عدة تصميمات وألوان تتناسب مع معظم الأذواق، لكنها الآن قررت توفير المزيد من الخيارات للمستخدمين من خلال نسخة Z Flip 3 Bespoke Edition.

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

ستتيح سامسونج من خلال نسخة Galaxy Z Flip 3 Bespoke Edition اختيار ألوان تتناسب معهم أذواقهم لهيكل وغلاف الهاتف مع طرح ألوان جديدة، تساعدهم بالحصول على نحو 49 تصميمًا مختلفًا عند دمج الألوان معًا، وهذا يعني خيارات لونية تتناسب مع معظم المستخدمين إذا لم يكن جميعهم.

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

ستتوفر نسخة Galaxy ZFlip 3 Bespoke Edition بسعر يبدأ من 1,100 دولار أمريكي وضمان لمدة 12 شهرًا، وسيكون متاح في الولايات المتحدة، كندا، أستراليا، ألمانيا، المملكة المتحدة، وكوريا الجنوبية في البداية، وربما لاحقًا ستصل للبلدان العربية.

يُشار أن وصول الهاتف سيستغرق وقتًا أطول مقارنة بشراء النسخة العادية، حيث سيتم تركيبه ودمج ألوانه معًا وفقًا للاختيارات الشخصية، كما سيختلف موعد وصوله كذلك من شخص لآخر لنفس الأمر.

المصدر:

Samsung

التدوينة سامسونج تطلق نسخة Bespoke Edition من Galaxy Z Flip 3 لتتيح للمستخدمين اختيار تصميمهم المفضل ظهرت أولاً على عالم التقنية.

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

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

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

ووفقًا لديفيد ماركوس، مدير تطوير خدمات الدفع والعملات الرقمية في فيس بوك، ستعمل المرحلة الاختبارية من محفظة Novi مع عملة Pax Dollar (USDP)، وهي عملة مستقرة بحسب ما أشار إليه ومستمرة بالعمل بطريقة مشروعة دون أي مشاكل على مدار ثلاث سنوات ماضية، ما يعني تقليل المشاكل المتعلقة بتناقل الأموال. وستعمل الشركة مع منصة Coinbase لمعالجة المعاملات الخاصة بالعمل.

المصدر:

Facebook

التدوينة فيس بوك تختبر محفظتها الرقمية Novi بشكل محدود ومطالبات بإيقافها ظهرت أولاً على عالم التقنية.

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

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

لكن وفقًا للمصدر فإن الاسم أقرب لـ Horizon وهو اسم استخدمته الشركة كثيرًا في الفترة الأخيرة، كما كان جزءًا من عنوانها “Horizon Worlds” لمؤتمرها عام 2019 حول تقنيات وأجهزة الواقع وقتها.

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

ويعني هذا أن واتساب أو انستجرام على سبيل المثال لن تكون تابعة لفيس بوك كاسم فعلي، ولكنها ستكون تابعة للشركة الجديدة التي سيتم تأسيسها، وستكون فيس بوك شركة شقيقة تحت مظلة الاسم الجديد.

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

المصدر:

The Verge

التدوينة فيس بوك تخطط لتغيير اسمها في الفترة المقبلة ظهرت أولاً على عالم التقنية.

أعلنت جوجل في مؤتمرها للكشف عن هواتف بكسل 6 و6 برو الجديدة، عن اشتراك موحد يجمع خدماتها المختلفة في مكان واحد دون الحاجة لدفع اشتراكات منفردة، وسيكون الاشتراك تحت اسم Pixel Pass.

ستتاح الخدمة الجديدة في الولايات المتحدة حاليًا وستكون لمستخدمي هواتف بكسل دون غيرهم، فيما ستوفر عدة خدمات أبرزها 200 جيجابايت من السعة التخزينية على سحابة Google One، واشتراك يوتيوب بريميوم أو ميوزك بريميوم، بالإضافة إلى اشتراك خدمة الألعاب Play Pass، وخصومات على متجرها Google Store، بالإضافة إلى تأمين على العديد من المنتجات.

وبفضل الخدمات الكثيرة التي ستوفرها، حددت شركة جوجل قيمة اشتراك Pixel Pass مع هواتف بكسل 6 بقيمة 45 دولارًا في الشهر، ومع هواتف بكسل 6 برو بسعر 55 دولارًا في الشهر.

التدوينة جوجل تجمع خدماتها في مكان واحد مع اشتراك Pixel Pass بسعر يبدأ من 45$ شهريًا ظهرت أولاً على عالم التقنية.

استغلت شركة جوجل حدثها الخاص قبل قليل للكشف عن هواتفها الجديدة، جوجل بكسل 6 و6 برو “Pixel 6 – 6 Pro”، بطريقة مغايرة مع الإعلان عن السعر أولًا لجذب الانتباه. وستأتي الهواتف مع رقاقة معالجة Tensor التي طورتها الشركة بنفسها، وكاميرات تتفاخر الشركة بتطويرها لهذا الحد، بالإضافة إلى مستشعر بصمة أسفل الشاشة لأول مرة في هواتف بكسل.

قررت جوجل السير في طريق منفرد لتقديم أفضل تجربة على هواتفها من خلال تطوير رقاقة معالجة خاصة باسم Tensor بتقنية 5 نانومتر تعتمد على تقديم الذكاء الاصطناعي بأفضل شكل مع هواتفها، حيث تقول الشركة إنها تقدم سرعة أكبر بنحو 80% من المعالجات التي استخدمتها على بكسل 5 – كانت من كوالكوم.

تحوي رقاقة معالجة جوجل نواتي Cortex-X1 المبنية على معمارية ARM مع سرعة 2.8 جيجا هرتز، ونواتي Cortex A76 مع سرعة 2.25 جيجا هرتز، بالإضافة إلى 4 نوى Cortex A55 بسرعة 1.8 جيجا هرتز مهمتها رفع كفاءة المعالجة عند الحاجة.

يأتي بكسل 6 مع شاشة 6.4 بوصة من نوع OLED بدقة 1080×2400 بكسل بوضوح 411 بكسل لكل بوصة مع سرعة تحديث 90 هرتز، أما نسخة برو فتأتي مع شاشة من نوف النوع لكن بدقة 1440×3120 بكسل بوضوح 512 بكسل لكل بوصة وهي كذلك من نوع OLED لكن بسرعة تحديث تصل 120 هرتز. وستدعم شاشتا الهاتفين مستشعر بصمة أسفلها لأول مرة في تاريخ هواتف جوجل.

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

تقول جوجل إنها طورت بطاريات هواتفها لتعمل على مدار اليوم مع المستخدمين حتى عند استخدام الجيل الخامس، حيث وفرت بطارية 4,614 ملي أمبير/ ساعة مع بكسل 6، وبطارية 5,003 بكسل مع نسخة برو. وتعول الشركة على تقنيات الذكاء الاصطناعي وكفاءة الطاقة مع رقاقاتها الجديدة لجعل الهاتف أقل استهلاكًا للطاقة في الوقت الذي يوفر فيه أفضل أداء.

سيعمل كلا الهاتفين مع نظام تشغيل أندرويد 12 الجديد مع تصميم واجهة Material You من جوجل.

يوفر الهاتف بكسل 6 كاميرا مزدوجة بالخلف مع عدسات بدقة 50 ميجابكسل للكاميرا الأساسية مع حجم بكسلات كبير، وكاميرا عريضة جدًا بدقة 12 ميجابكسل، فيما تضيف نسخة برو كاميرا ثالثة بالخلف بدقة 48 ميجابكسل للتصوير القريب والتقاط الصور بتركيز أعلى. يتيح نظام الكاميرا لكلا الهاتفين التقاط مقاطع فيديو بدقة 1080 بكسل حتى 4K على سرعة 30 أو 60 إطارًا في الثانية.

سيوفر بكسل 6 كاميرا أمامية بدقة 8 ميجابكسل بفتحة غالق f/2.0، فيما سيوفر 6 برو كاميرا بدقة 11.1 ميجابكسل بفتحة غالق f/2.2.

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

• دعم الجيل الخامس.
• دعم 5 سنوات من التحديثات الأمنية.
• رقاقة الأمان والحماية Titan M2.
• مركز حماية وخصوصية جديد.
• معيار مقاومة الماء والغبار IP68.
• مقاومة الخدش مرتين أكثر من الجيل السابق.
• سماعات ستيريو.
• شحن سريع 30 واط.
• شحن لاسلكي سريع 21 واط.
• منفذ USB C.
• دعم WiFi 6.
• دعم بلوتوث 5.2.
• تقنية GPS مزدوج.
• تقنية NFC.

يأتي بكسل 6 في 28 أكتوبر بسعر يبدأ من 599 دولارًا أمريكيًا لنسخة 8 جيجابايت رام و128 جيجابايت سعة تخزينية.

فيما سيأتي بكسل 6 برو بسعر يبدأ من 899 دولارًا أمريكيًا لنسخة رام 8 جيجابايت رام و128 جيجابايت سعة تخزينية.

التدوينة جوجل تعلن عن بكسل 6 بسعر 599$ ونسخة برو بسعر 899$ مع رقاقة معالجة Tensor ظهرت أولاً على عالم التقنية.