نظرة عامة على 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 بالانضمام إلى اجتماع إلا إذا كان هناك شخص في المكالمة مسموح له بمنح الموافقة نيابةً عن الاجتماع.

بالنسبة إلى اجتماعات Google Workspace

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

بالنسبة إلى اجتماعات المستهلكين

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

عبارات عامة

رقم مشروع Cloud

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

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

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

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

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

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

بروتوكول وصف الجلسة الأوّلي في مسار التفاوض "نظير إلى نظير" بين العرض والإجابة ينشئ النظير الذي يبدأ التفاوض العرض ويحدد بنود جلسة "نظير إلى نظير". ينشئ عميل Meet Media API العرض دائمًا ويُرسله إلى خوادم Meet.

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

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

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

RtpTransceiver

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

يتم ربط جهاز إرسال واستقبال واحد بوصف وسائط واحد في بروتوكول وصف الجلسة ويتم وصفه من خلاله. يتكوّن جهاز الإرسال والاستقبال من RtpSender وRtpReceiver.

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

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

بثوث الوسائط الافتراضية

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

مواضيع ذات صلة

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

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

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

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

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