تتيح Google Meet Media API لتطبيقك الانضمام إلى مؤتمر على Google Meet واستخدام بث الوسائط في الوقت الفعلي.
يستخدم العملاء WebRTC للتواصل مع خوادم Meet. يوضّح ملفَا العميل المرجعيَين (C++ وTypeScript) الممارسات المقترَحة، ويُنصح بالاستناد إليهما مباشرةً.
ومع ذلك، يمكنك أيضًا إنشاء عملاء WebRTC مخصّصين بالكامل يلتزمون
بالمتطلبات الفنية لواجهة برمجة التطبيقات Meet Media API.
توضّح هذه الصفحة مفاهيم WebRTC الرئيسية المطلوبة لجلسة ناجحة
Meet Media API.
إشارة العرض والإجابة
WebRTC هو إطار عمل للتواصل بين الأجهزة (نظير إلى نظير)، حيث يتواصل الأجهزة مع بعضها البعض من خلال إرسال إشارات
إلى بعضها. لبدء جلسة، يُرسِل المُشغِّل المُبادِر عرضًا لبروتوكول وصف الجلسة (SDP) إلى مُشغِّل عن بُعد. يتضمّن هذا العرض
التفاصيل المهمة التالية:
أوصاف الوسائط للصوت والفيديو
تشير أوصاف الوسائط إلى ما يتم تبادله خلال جلسات الاتصال المباشر بين الأجهزة. هناك ثلاثة
أنواع من الأوصاف: الصوت والفيديو والبيانات.
للإشارة إلى n بثّ صوتي، يُدرج مقدّم العرض n وصفًا لوسائط الصوت
في العرض. وينطبق ذلك أيضًا على الفيديو. ومع ذلك، لن يكون هناك سوى وصف واحد لبيانات
الوسائط كحد أقصى.
اتجاهات الطريق
يصف كل وصف صوت أو فيديو أحداث بث فردية بروتوكول النقل الآمن في الوقت الفعلي (SRTP) تخضع RFC
3711. وهذه القنوات ثنائية الاتجاه،
وتسمح لجهازَين متصلَين بإرسال الوسائط واستلامها عبر الاتصال نفسه.
ولهذا السبب، يحتوي كل وصف وسائط (في كلّ من العرض والجواب) على
إحدى السمات الثلاث التي تصف كيفية استخدام البث:
sendonly: لا يتم إرسال الوسائط إلا من نظير العرض. لن يُرسِل جهاز الكمبيوتر البعيد
الوسائط في هذا البث.
recvonly: لا يتلقّى الوسائط إلا من المثيل البعيد. لن يرسل المحتوى المعروض
وسائط في هذا البث.
sendrecv: يمكن لكلا الطرفَين الإرسال والاستلام في هذا البث.
برامج الترميز
يحدّد كل وصف وسائط أيضًا برامج الترميز التي يتوافق معها جهاز نظير. في ما يتعلّق بواجهة برمجة التطبيقات
Meet Media API، يتم رفض عروض العملاء ما لم تكن متوافقة مع ملفّات الترميز المحدّدة في المتطلبات
التقنية (على الأقل).
تأكيد الاتصال عبر بروتوكول أمان طبقة النقل لمخطّطات البيانات (DTLS)
يتم تأمين أحداث SRTP من خلال عملية أمان طبقة النقل لمخطّطات البيانات ("DTLS"، RFC
9147) الأولية بين الأجهزة المشارِكة.
يُعدّ بروتوكول DTLS تقليديًا بروتوكولًا بين العميل والخادم. وخلال عملية الإرسال، يوافق أحد الأجهزة المشابهة على العمل كخادم بينما يعمل الآخر كجهاز مشابه.
بما أنّ كل بث SRTP قد يتضمّن اتصال DTLS مخصّصًا، يحدّد كل وصف
للوسائط إحدى السمات الثلاث للإشارة إلى دور العميل
في عملية تأكيد الاتصال باستخدام بروتوكول DTLS:
a=setup:actpass: يعتمد تطبيق العرض على اختيار
التطبيق البعيد.
a=setup:active: يلعب هذا الجهاز دور العميل.
a=setup:passive: يعمل هذا الجهاز كمثيل للخادم.
أوصاف وسائط التطبيق
قنوات البيانات (RFC 8831) هي
طريقة تجريدية لبروتوكول التحكّم في نقل البث ("SCTP"، RFC
9260).
لفتح قنوات البيانات أثناء مرحلة الإرسال الأولي، يجب أن يحتوي العرض على
وصف وسائط التطبيق. على عكس أوصاف الصوت والفيديو،
لا تحدّد أوصاف التطبيقات الاتجاه أو برامج الترميز.
المرشحون لبرنامج ICE
مرشحو Interactive Connectivity Establishment (ICE، RFC
8445) للندّ هي قائمة ب
المسارات التي قد يستخدمها ندّ بعيد لإنشاء اتصال.
يمثّل المنتج الديكارتي لقائمتَي الخوادم المتكافئة، المعروف باسم الأزواج المرشحة،
المسارات المحتملة بين الخادمَين المتكافئَين. ويتم اختبار هذه الأزواج لتحديد المسار الأمثل.
يردّ الشريك البعيد من خلال إجابة SDP تحتوي على العدد نفسه
من أسطر وصف الوسائط. يشير كل سطر إلى الوسائط، إن توفّرت، التي يرسلها العميل البعيد
إلى العميل الموفّر عبر أحداث SRTP. قد يرفض العميل العميق
المتّصل عن بُعد أيضًا أحداث بث معيّنة من مقدّم المحتوى من خلال ضبط إدخال وصف
الوسائط على recvonly.
بالنسبة إلى Meet Media API، يرسل العملاء دائمًا عرض SDP لبدء
الاتصال. لا يكون Meet هو المُشغِّل أبدًا.
تتم إدارة هذا السلوك داخليًا من خلال عملاء المرجع
(C++ وTypeScript)،
ولكن يمكن لمطوّري العملاء المخصّصين استخدام PeerConnectionInterface في WebRTC لمحاولة
إنشاء عرض.
للربط بتطبيق Meet، يجب أن يلتزم العرض بأحد
المتطلبات التالية:
يجب أن يتصرّف العميل دائمًا بصفته العميل في عملية مصافحة DTLS، لذا يجب أن يحدّد كل وصف
للوسائط في العرض إما a=setup:actpass أو
a=setup:active.
لتلقّي المحتوى الصوتي، يجب أن يتضمّن العرض 3 أوصاف بالضبط لوسائط الوسائط الصوتية التي تتيح الاستلام فقط. ويمكنك إجراء ذلك من خلال ضبط أجهزة الإرسال والاستقبال في ملف تعريف
اتصال الأقران.
لتلقّي الفيديو، يجب أن يتضمّن العرض وصفًا واحدًا أو ثلاثة أوصافًا لوسائط فيديو
مخصّصة للاستقبال فقط. ويمكنك إجراء ذلك من خلال ضبط أجهزة الإرسال والاستقبال في ملف تعريف
اتصال الأقران.
يجب أن يتضمّن العرض دائمًا قنوات البيانات. يجب أن تكون قناتا
session-control وmedia-stats مفتوحتَين دائمًا على الأقل. يجب أن تكون جميع قنوات
البيانات ordered.
تاريخ التعديل الأخير: 2025-03-06 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-03-06 (حسب التوقيت العالمي المتفَّق عليه)"],[[["The Google Meet Media API enables applications to join Google Meet conferences and receive real-time media streams, relying on WebRTC for peer-to-peer communication."],["Offer-answer signaling, facilitated by the Meet REST API, is crucial for establishing WebRTC sessions, with the initiating peer sending an SDP offer and receiving an SDP answer from the remote peer."],["Clients connecting to Google Meet must support specific codecs (Opus for audio, VP8, VP9, AV1 for video), act as the DTLS client, include at least three `recvonly` audio descriptions, and always include data channels."],["Media descriptions specify the type of media (audio, video, data), with directionality (sendonly, recvonly, sendrecv) determining stream usage and direction, governed by SRTP."],["SDP media descriptions include the type of media (audio, video, or application/data), which IP and port it uses, the ICE credential, the DTLS fingerprint and the header extensions it supports, like the time offset, the content type, the mid and the rtp-stream-id, among others."]]],[]]