نظرة عامة على Meet Media API

تتيح لك Google Meet Media API الوصول إلى الوسائط في الوقت الفعلي من مؤتمرات Google Meet. يتيح ذلك مجموعة متنوعة من حالات الاستخدام، مثل التطبيقات التي توثّق بنود العمل أو تقدّم إحصاءات فورية حول الاجتماع الحالي أو تبث الصوت والفيديو إلى سطح جديد.

حالات الاستخدام

يمكن للتطبيقات المسجّلة في Google Cloud Console استخدام Meet Media API للاتصال بمؤتمرات Meet، ما يتيح لها إجراء ما يلي:

  • استهلاك مجموعات بث الفيديو
  • استهلاك بث صوتي
  • استهلاك البيانات الوصفية للمشاركين

دورة حياة Meet Media API

تعرض الصور التالية دورة حياة واجهة برمجة التطبيقات Meet Media API:

  • يحاول برنامج Meet Media API الآلي الانضمام إلى الموقع الإلكتروني الخارجي.
    الشكل 1. يحاول برنامج الروبوت الخاص بـ Meet Media API الانضمام إلى الاجتماع من الموقع الإلكتروني التابع لجهة خارجية. يتم رفض الربط في حال توفّر حسابات قاصرين.
  • الاجتماعات المُشفَّرة والاجتماعات التي تتضمّن علامة مائية
    الشكل 2. يمكن وضع علامة على الاجتماعات بأنّها مشفّرة، كما يمكن إضافة علامة مائية إليها. لا يمكن ربط واجهة برمجة التطبيقات Meet Media API عندما يكون الاجتماع مشفَّرًا أو يتضمّن علامة مائية.
  • تأكَّد من صحة إعدادات المشرف.
    الشكل 3. تأكَّد من صحة إعدادات المشرف.
  • إعداد الاجتماع في "تقويم Google"
    الشكل 4. إعداد الاجتماع في "تقويم Google" على المضيف منح الإذن للتطبيق الخارجي في إعدادات التقويم، وإلا سيتم رفض عملية الربط.
  • تغيير الإعدادات أثناء المكالمة
    الشكل 5. تغيير أحد الإعدادات أثناء المكالمة إذا قرر المضيف إيقاف خيار Meet Media API أثناء مكالمة، سيتوقف الاتصال.
  • يجب أن يكون الشخص الذي بدأ الاجتماع حاضرًا أثناء اجتماعات المستهلكين.
    الشكل 6. إذا كان مالك الاجتماع لديه حساب مستهلك (حساب ينتهي بالنطاق ‎ @gmail.com)، يجب أن يكون المنشئ حاضرًا في الاجتماع لمنح الموافقة، وإلا سيتم رفض الاتصال.
  • تم إنشاء الاتصال.
    الشكل 7. بعد إنشاء الاتصال، يظهر مربّع حوار بدء البث للمضيف أو المضيف المشارك أو أي مشاركين في المؤسسة نفسها التي ينتمي إليها المضيف.
  • يمكن لأي مستخدم إيقاف Meet Media API أثناء المكالمة.
    الشكل 8. يمكن لأي مستخدم إيقاف Meet Media API أثناء المكالمة.

متطلبات مقدّم الموافقة

لا يُسمح لتطبيقات Meet Media API بالانضمام إلى اجتماع إلا إذا كان هناك مشارك في المكالمة لديه الإذن بتقديم الموافقة نيابةً عن الاجتماع.

لاجتماعات Google Workspace

لتقديم موافقتك في اجتماعات Google Workspace، يجب أن تكون ضمن المؤسسة التي تملك الاجتماع. في معظم الحالات، يكون مالك الاجتماع هو نفسه المنظِّم. إذا كان المضيف أو الشخص الذي بدأ الاجتماع حاضرًا في الاجتماع وكان من المؤسسة التي تملك الاجتماع، سيظهر له مربّع الحوار الخاص بالبدء بشكل تفضيلي.

للاجتماعات المخصّصة للمستهلكين

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

عبارات عامة

رقم مشروع على السحابة الإلكترونية
معرّف int64 غير قابل للتغيير تم إنشاؤه لمشروع على Google Cloud. يتم إنشاء هذه القيم من خلال Google Cloud Console لكل تطبيق مسجَّل.
المؤتمر
هي نسخة من مكالمة تم إنشاؤها على الخادم ضمن مساحة اجتماع. ويعتبر المستخدمون عادةً هذا السيناريو اجتماعًا واحدًا.
قناة بيانات مراجع المؤتمرات

بدلاً من طلب الموارد عبر HTTP، كما هو الحال مع Google Meet REST API، يطلب عملاء Meet Media API الموارد من الخادم عبر قنوات البيانات.

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

المصدر المساهم (CSRC)

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

يُعيّن Meet لكل مشارك في مؤتمر قيمة CSRC فريدة عند انضمامه. وتظل هذه القيمة ثابتة إلى أن يغادر المستخدم.

قنوات البيانات

تتيح قنوات بيانات WebRTC تبادل بيانات عشوائية (نصوص وملفات وما إلى ذلك) بشكل مستقل عن بث الصوت والفيديو. تستخدم قنوات البيانات الاتصال نفسه الذي تستخدمه وسائط البث، ما يوفّر طريقة فعّالة لإضافة تبادل البيانات إلى تطبيقات WebRTC.

تأسيس الاتصال التفاعلي (ICE)

بروتوكول لإنشاء اتصال والعثور على جميع المسارات الممكنة لتواصل جهازَي كمبيوتر مع بعضهما البعض من خلال شبكة الند للند (P2P)، ثم التأكّد من استمرار الاتصال.

بث الوسائط

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

مسار بث الوسائط

تتألف من تدفق واحد أحادي الاتجاه لحِزم RTP. يمكن أن يكون مسار بث الوسائط صوتًا أو فيديو، ولكن ليس كليهما. يتألف اتصال بروتوكول النقل الآمن في الوقت الفعلي (SRTP) الثنائي الاتجاه عادةً من مسارَين لتدفق الوسائط، أحدهما للخروج من الجهاز المحلي إلى الجهاز البعيد، والآخر للدخول من الجهاز البعيد إلى الجهاز المحلي.

مساحة الاجتماع

تمثّل هذه السمة مكانًا افتراضيًا أو عنصرًا ثابتًا (مثل غرفة اجتماعات) يتم فيه عقد مؤتمر. يمكن عقد اجتماع فيديو نشط واحد فقط في مساحة واحدة في أي وقت. تساعد مساحة الاجتماعات أيضًا المستخدمين في الاجتماع والعثور على الموارد المشتركة.

المشارك

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

أحداث البث المباشر ذات الصلة

هناك حدّ أقصى لعدد مصادر البث الصوتي الافتراضية ومصادر البث المرئي الافتراضية التي يمكن للعميل فتحها.

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

وحدة إعادة التوجيه الانتقائي (SFU)

وحدة إعادة التوجيه الانتقائي (SFU) هي أحد مكونات WebRTC من جهة الخادم، وتعمل على إدارة توزيع بث الوسائط في مؤتمرات WebRTC. يتصل المشاركون فقط بوحدة SFU التي تعيد توجيه التدفقات ذات الصلة بشكل انتقائي إلى المشاركين الآخرين. يقلّل ذلك من احتياجات المعالجة ومعدل نقل البيانات لدى العميل، ما يتيح عقد مؤتمرات قابلة للتوسيع.

بروتوكول وصف الجلسة (SDP)

آلية إرسال الإشارات التي تستخدمها WebRTC للتفاوض بشأن اتصال "شبكة الند للند" وتخضع هذه البيانات لسياسة RFC 8866.

إجابة SDP

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

عرض SDP

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

على سبيل المثال، قد يشير العرض إلى عدد عمليات بث الصوت أو الفيديو التي يرسلها (أو يمكنه تلقّيها) مقدّم العرض وما إذا كان سيتم فتح قنوات البيانات.

مصدر المزامنة (SSRC)

معرّف SSRC هو معرّف يبلغ 32 بت ويحدّد بشكل فريد مصدرًا واحدًا لتدفق وسائط ضمن جلسة RTP (بروتوكول النقل في الوقت الفعلي). في WebRTC، يتم استخدام أرقام تعريف مصدر الحزمة المتزامنة (SSRC) للتمييز بين تدفقات الوسائط المختلفة الواردة من مشاركين مختلفين أو حتى مسارات مختلفة من المشارك نفسه (مثل الكاميرات المختلفة).

RtpTransceiver

كما هو موضّح بالتفصيل في RFC 8829، جهاز الإرسال والاستقبال هو تجريد لتدفقات RTP في جلسة من نظير إلى نظير.

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

بما أنّ بروتوكول النقل في الوقت الفعلي (RTP) ثنائي الاتجاه، يكون لكل جهاز نظير مثيل جهاز إرسال واستقبال خاص به لاتصال بروتوكول النقل في الوقت الفعلي نفسه. يتم ربط RtpSender لجهاز إرسال واستقبال معيّن بالنظير المحلي RtpReceiver لجهاز إرسال واستقبال محدّد في النظير البعيد. والعكس صحيح أيضًا. يتم ربط RtpSender لجهاز الإرسال والاستقبال نفسه الخاص بالجهاز البعيد بنظيره RtpReceiver الخاص بالجهاز المحلي.

يحتوي كل وصف وسائط على جهاز إرسال واستقبال مخصّص. وبالتالي، تتضمّن جلسة من الند للند مع مجموعات بث RTP متعددة أجهزة إرسال واستقبال متعددة مع RtpSenders وRtpReceiver متعددة لكل نظير.

Virtual Media Streams

"تدفّقات الوسائط الافتراضية" هي تدفّقات وسائط مجمّعة تنشئها وحدة إعادة توجيه انتقائية (SFU) في مؤتمرات WebRTC. بدلاً من أن يرسل كل مشارك تدفقات فردية إلى جميع المشاركين الآخرين، يدمج SFU تدفقات المشاركين المحدّدة في عدد أقل من التدفقات الافتراضية الصادرة. يؤدي ذلك إلى تبسيط بنية الاتصال وتقليل الحمل على المشاركين، ما يتيح إمكانية توسيع نطاق المؤتمرات. يمكن أن يحتوي كل بث افتراضي على وسائط من عدة مشاركين، ويديرها SFU بشكل ديناميكي.

  • للتعرّف على كيفية بدء تطوير برنامج Meet Media API، اتّبِع الخطوات الواردة في البدء.

  • للتعرّف على كيفية إعداد وتشغيل عميل مرجعي نموذجي لواجهة Meet Media API، يُرجى الاطّلاع على دليل البدء السريع الخاص بالعميل المرجعي C++‎.

  • للحصول على نظرة عامة مفاهيمية، يُرجى الاطّلاع على مفاهيم Meet Media API.

  • لمزيد من المعلومات حول WebRTC، يمكنك الاطّلاع على WebRTC For The Curious.

  • للتعرّف على كيفية التطوير باستخدام واجهات برمجة التطبيقات في Google Workspace، بما في ذلك التعامل مع المصادقة والتفويض، يُرجى الرجوع إلى التطوير على Google Workspace.