Google Meet Media API به برنامه شما اجازه میدهد به کنفرانس Google Meet بپیوندد و جریانهای رسانهای را در زمان واقعی مصرف کند.
کلاینت ها از WebRTC برای ارتباط با سرورهای Meet استفاده می کنند. مشتریان مرجع ارائه شده ( C++ ، TypeScript ) شیوه های توصیه شده را نشان می دهند و شما تشویق می شوید که مستقیماً بر اساس آنها بسازید.
با این حال، میتوانید کلاینتهای WebRTC کاملاً سفارشی بسازید که به الزامات فنی Meet Media API پایبند باشند.
این صفحه مفاهیم کلیدی WebRTC مورد نیاز برای یک جلسه موفقیت آمیز Meet Media API را نشان می دهد.
سیگنالینگ پیشنهاد-پاسخ
WebRTC یک چارچوب همتا به همتا (P2P) است که در آن همتایان با سیگنال دادن به یکدیگر ارتباط برقرار می کنند. برای شروع یک جلسه، همتای شروع کننده یک پیشنهاد SDP را به یک همتای راه دور ارسال می کند. این پیشنهاد شامل جزئیات مهم زیر است:
توضیحات رسانه برای صدا و تصویر
توضیحات رسانه نشان می دهد که چه چیزی در طول جلسات P2P ارتباط برقرار می کند. سه نوع توصیف وجود دارد: صوتی، تصویری و داده.
برای نشان دادن n جریان صوتی، ارائه دهنده n توصیف رسانه صوتی را در پیشنهاد گنجانده است. در مورد ویدیو هم همینطور است. با این حال، حداکثر تنها یک توضیح رسانه داده وجود خواهد داشت.
جهت دار بودن
هر توضیحات صوتی یا تصویری، جریانهای پروتکل حمل و نقل بیدرنگ امن (SRTP) را توصیف میکند که توسط RFC 3711 اداره میشود. اینها دو جهته هستند و به دو همتا اجازه میدهند رسانهها را از طریق یک اتصال ارسال و دریافت کنند.
به همین دلیل، هر توصیف رسانه (هم در پیشنهاد و هم در پاسخ) حاوی یکی از سه ویژگی است که نحوه استفاده از جریان را توصیف می کند:
sendonly : فقط رسانه را از همتای ارائه دهنده ارسال می کند. همتای راه دور رسانه را در این جریان ارسال نمی کند.
recvonly : فقط رسانه را از همتای راه دور دریافت می کند. همتای پیشنهادی رسانه را در این جریان ارسال نمیکند.
sendrecv : هر دو همتا ممکن است در این جریان ارسال و دریافت کنند.
کدک ها
هر توضیح رسانه همچنین کدک هایی را که یک همتا پشتیبانی می کند مشخص می کند. در مورد Meet Media API، پیشنهادات مشتری رد میشوند مگر اینکه از کدکهای مشخصشده در الزامات فنی (حداقل) پشتیبانی کنند.
دست دادن DTLS
جریان های SRTP با یک دست دادن اولیه Datagram Layer Security ("DTLS"، RFC 9147 ) بین همتایان ایمن می شوند. DTLS به طور سنتی یک پروتکل مشتری به سرور است. در طول فرآیند سیگنالینگ، یک همتا موافقت می کند که به عنوان سرور عمل کند در حالی که دیگری به عنوان یک همتا عمل می کند.
از آنجا که هر جریان SRTP ممکن است اتصال DTLS اختصاصی خود را داشته باشد، هر توضیح رسانه یکی از سه ویژگی را برای نشان دادن نقش همتا در دست دادن DTLS مشخص می کند:
a=setup:actpass : همتای پیشنهادی به انتخاب همتای راه دور موکول می شود.
a=setup:active : این همتا به عنوان مشتری عمل می کند.
a=setup:passive : این همتا به عنوان سرور عمل می کند.
توضیحات رسانه های کاربردی
کانال های داده ( RFC 8831 ) انتزاعی از پروتکل انتقال کنترل جریان ("SCTP"، RFC 9260 ) هستند.
برای باز کردن کانال های داده در مرحله سیگنال دهی اولیه، پیشنهاد باید حاوی توضیحات رسانه برنامه باشد. برخلاف توضیحات صوتی و تصویری، توضیحات برنامه مسیر یا کدک ها را مشخص نمی کند.
نامزدهای ICE
نامزدهای برقراری اتصال تعاملی یک همتا ("ICE"، RFC 8445 ) لیستی از مسیرهایی هستند که یک همتای راه دور ممکن است برای ایجاد یک اتصال استفاده کند.
حاصل ضرب دکارتی لیست دو همتا، که به نام جفت نامزد شناخته می شود، نشان دهنده مسیرهای بالقوه بین دو همتا است. این جفت ها برای تعیین مسیر بهینه آزمایش می شوند.
در اینجا یک پیشنهاد با توضیح رسانه صوتی وجود دارد:
شکل 1. پیشنهاد نمونه با توضیحات رسانه صوتی.
همتای راه دور با یک پاسخ SDP حاوی همان تعداد خطوط توصیف رسانه پاسخ می دهد. هر خط نشان میدهد که در صورت وجود، همتای راه دور چه رسانهای را در جریانهای SRTP به مشتری پیشنهادی ارسال میکند. همتای راه دور ممکن است جریانهای خاصی را از ارائهدهنده با تنظیم آن ورودی توصیف رسانه روی recvonly رد کند.
برای Meet Media API، مشتریان همیشه پیشنهاد SDP را برای شروع یک اتصال ارسال میکنند. ملاقات هرگز آغازگر نیست.
این رفتار به صورت داخلی توسط مشتریان مرجع مدیریت می شود ( C++ ، TypeScript )، اما توسعه دهندگان مشتریان سفارشی می توانند از PeerConnectionInterface WebRTC برای ایجاد یک پیشنهاد استفاده کنند.
برای اتصال به Meet Meet، پیشنهاد باید از شرایط خاصی پیروی کند:
کلاینت باید همیشه به عنوان مشتری در دست دادن DTLS عمل کند، بنابراین هر توضیح رسانه در پیشنهاد باید a=setup:actpass یا a=setup:active مشخص کند.
هر خط توصیف رسانه باید از همه کدک های مورد نیاز برای آن نوع رسانه پشتیبانی کند:
صدا:Opus
ویدئو:VP8 ، VP9 ، AV1
برای دریافت صدا، پیشنهاد باید دقیقاً شامل 3 توصیف رسانه صوتی فقط دریافت باشد. شما می توانید این کار را با تنظیم فرستنده گیرنده بر روی شی اتصال همتا انجام دهید.
برای دریافت ویدیو، پیشنهاد باید شامل 1 تا 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."]]],[]]