رابط برنامهنویسی کاربردی رسانه گوگل میت (Google Meet Media API) به شما امکان میدهد به رسانههای کنفرانسهای گوگل میت به صورت آنی دسترسی داشته باشید. این قابلیت، کاربردهای متنوعی را امکانپذیر میکند، مانند برنامههایی که موارد عملیاتی را مستند میکنند، بینشهای آنی در مورد جلسه فعلی ارائه میدهند یا صدا و تصویر را به یک سطح جدید پخش میکنند.
موارد استفاده
برنامههای ثبتشده در کنسول Google Cloud میتوانند از رابط برنامهنویسی کاربردی Meet Media برای اتصال به کنفرانسهای Meet استفاده کنند و این امکان را برای آنها فراهم میکند:
- از استریمهای ویدیویی استفاده کنید . برای مثال:
- پخشهای ویدیویی تولید شده در کنفرانسهای Meet را به مدلهای هوش مصنوعی خود وارد کنید.
- فیلتر کردن جریانها برای ضبطهای سفارشی.
- از جریانهای صوتی استفاده کنید . برای مثال:
- صدا را مستقیماً به Gemini ارسال کنید و چتبات هوش مصنوعی مخصوص جلسه خود را بسازید.
- پخش جریانهای صوتی تولید شده در کنفرانسهای Meet را به سرویس رونویسی خودتان ارسال کنید
- ایجاد زیرنویس به زبانهای مختلف.
- فیدهای زبان اشاره تولید شده توسط مدل را از صدای ضبط شده ایجاد کنید.
- مدلهای نویزگیر خودتان را بسازید تا پسزمینه و نویزهای اضافی را از کنفرانس حذف کنید.
- مصرف فرادادههای شرکتکنندگان . برای مثال:
- تشخیص اینکه کدام شرکتکنندگان در کنفرانس حضور دارند، که امکان هوش و تحلیل بهتر را فراهم میکند.
با چرخه عمر API رسانه آشنا شوید
تصاویر زیر چرخه حیات Meet Media API را نشان میدهند:
شکل ۱. ربات Meet Media API سعی میکند به وبسایت شخص ثالث متصل شود. در صورت وجود حسابهای کاربری زیر سن قانونی، اتصال رد میشود. 
شکل ۲. جلسات میتوانند به صورت رمزگذاری شده علامتگذاری شوند و دارای واترمارک باشند. وقتی جلسهای دارای رمزگذاری یا واترمارک باشد، نمیتوان به Meet Media API متصل شد. 
شکل ۳. مطمئن شوید که تنظیمات مدیر صحیح است. 
شکل ۴. تنظیم جلسه در تقویم. میزبان باید در تنظیمات تقویم به برنامه شخص ثالث اجازه دسترسی بدهد، در غیر این صورت اتصال رد میشود. 
شکل ۵. تغییر تنظیمات در حین تماس. اگر میزبان تصمیم بگیرد تنظیمات Meet Media API را در حین تماس غیرفعال کند، اتصال متوقف میشود. 
شکل ۶. اگر صاحب جلسه یک حساب کاربری مصرفکننده (حسابی که به @gmail.com ختم میشود) داشته باشد، آنگاه آغازگر جلسه باید برای اعلام رضایت حضور داشته باشد، در غیر این صورت اتصال رد میشود. 
شکل ۷. پس از برقراری اتصال، میزبان، میزبان مشترک یا هر شرکتکنندهای که در همان سازمان میزبان قرار دارد، پنجرهی شروع اتصال را مشاهده میکند. 
شکل ۸. هر کسی میتواند رابط برنامهنویسی کاربردی Meet Media را در طول تماس متوقف کند.
الزامات موافقت کننده
برنامههای رابط برنامهنویسی کاربردی Meet Media فقط در صورتی مجاز به ورود به جلسه هستند که شخصی در تماس وجود داشته باشد که مجاز به ارائه رضایت از طرف جلسه باشد.
برای جلسات Google Workspace
برای ارائه رضایت در جلسات Google Workspace، باید در سازمانی باشید که مالک جلسه است. در بیشتر موارد، مالک جلسه همان سازماندهنده است. اگر میزبان یا آغازگر در جلسه باشد و در سازمانی باشد که مالک جلسه است، ترجیحاً کادر گفتگوی شروع به او نشان داده میشود.
برای جلسات مصرفکنندگان
برای جلساتی که توسط حسابهای Gmail سازماندهی میشوند، آغازگر جلسه باید در جلسه حضور داشته باشد تا رضایت خود را ارائه دهد.
اصطلاحات رایج
- شماره پروژه ابری
- یک شناسه
int64تغییرناپذیر تولید شده برای یک پروژه Google Cloud. این مقادیر توسط کنسول Google Cloud برای هر برنامه ثبت شده تولید میشوند. - کنفرانس
- نمونهای از یک تماس تولید شده توسط سرور در فضای جلسه . کاربران معمولاً این سناریو را یک جلسه واحد در نظر میگیرند.
- کانال دادههای منابع کنفرانس
به جای درخواست منابع از طریق HTTP، مانند Google Meet REST API ، کلاینتهای Meet Media API منابع را از طریق کانالهای داده از سرور درخواست میکنند.
میتوان برای هر نوع منبع، یک کانال داده اختصاصی باز کرد. پس از باز شدن، کلاینت میتواند درخواستها را از طریق کانال ارسال کند. بهروزرسانیهای منابع از طریق همان کانال ارسال میشوند.
- منبع مشارکتکننده (CSRC)
در جریانهای رسانهای مجازی ، نمیتوانید فرض کنید که یک جریان رسانهای همیشه به یک شرکتکننده اشاره میکند. مقدار CSRC در هدر هر بسته RTP، منبع واقعی بسته را مشخص میکند.
Meet به هر شرکتکننده در کنفرانس، هنگام پیوستن، یک مقدار CSRC منحصر به فرد اختصاص میدهد. این مقدار تا زمان خروج آنها ثابت میماند.
- کانالهای داده
کانالهای داده WebRTC امکان تبادل دادههای دلخواه (متن، فایل و غیره) را مستقل از جریانهای صوتی و تصویری فراهم میکنند. کانالهای داده از همان اتصال جریانهای رسانهای استفاده میکنند و روشی کارآمد برای افزودن تبادل داده به برنامههای WebRTC ارائه میدهند.
- استقرار اتصال تعاملی (ICE)
پروتکلی برای برقراری اتصال، یافتن تمام مسیرهای ممکن برای ارتباط دو کامپیوتر با یکدیگر از طریق شبکه نظیر به نظیر (P2P) و سپس اطمینان از اتصال دائمی شما.
- جریان رسانهای
یک جریان رسانهای WebRTC نشاندهنده جریانی از دادههای رسانهای، معمولاً صوتی یا تصویری، است که از دستگاهی مانند دوربین یا میکروفون ضبط میشود. این جریان شامل یک یا چند تراک جریان رسانهای است که هر کدام نشاندهنده یک منبع واحد رسانهای مانند یک تراک ویدیویی یا یک تراک صوتی هستند.
- مسیر جریان رسانهای
شامل یک جریان واحد و یکطرفه از بستههای RTP است. یک مسیر جریان رسانه میتواند صوتی یا تصویری باشد، اما نه هر دو. یک اتصال دوطرفه پروتکل انتقال امن بلادرنگ (SRTP) معمولاً شامل دو مسیر جریان رسانه است، خروجی از همتای محلی به همتای راه دور و ورودی از همتای راه دور به همتای محلی.
- فضای جلسات
یک مکان مجازی یا یک شیء پایدار (مانند اتاق جلسه) که در آن کنفرانس برگزار میشود. فقط یک کنفرانس فعال میتواند در هر زمان در یک فضا برگزار شود. یک فضای جلسه همچنین به کاربران کمک میکند تا با یکدیگر ملاقات کرده و منابع مشترک را پیدا کنند.
- شرکتکننده
شخصی که به یک کنفرانس پیوسته یا از حالت همراهی استفاده میکند، به عنوان بیننده تماشا میکند، یا دستگاهی در اتاق که به یک تماس متصل است. وقتی یک شرکتکننده به کنفرانس میپیوندد، یک شناسه منحصر به فرد به او اختصاص داده میشود.
- جریانهای مرتبط
محدودیتی برای تعداد جریانهای صوتی مجازی و جریانهای ویدیویی مجازی که یک کلاینت میتواند باز کند، وجود دارد.
کاملاً ممکن است که تعداد شرکتکنندگان در یک کنفرانس از این تعداد بیشتر شود. در این شرایط، سرورهای Meet جریانهای صوتی و تصویری شرکتکنندگانی را که "مرتبطترین" تشخیص داده میشوند، ارسال میکنند. مرتبط بودن از ویژگیهای مختلفی مانند اشتراکگذاری صفحه نمایش و اینکه یک شرکتکننده اخیراً چه زمانی صحبت کرده است، تعیین میشود.
- واحد حمل و نقل انتخابی (SFU)
واحد ارسال انتخابی (SFU) یک جزء سمت سرور در کنفرانس WebRTC است که توزیع جریان رسانه را مدیریت میکند. شرکتکنندگان فقط به SFU متصل میشوند، که به صورت انتخابی جریانهای مرتبط را به سایر شرکتکنندگان ارسال میکند. این امر نیاز به پردازش و پهنای باند کلاینت را کاهش میدهد و امکان کنفرانسهای مقیاسپذیر را فراهم میکند.
- پروتکل توصیف جلسه (SDP)
مکانیزم سیگنالدهی که WebRTC برای مذاکره در یک اتصال P2P استفاده میکند.
RFC 8866آن را مدیریت میکند.- پاسخ SDP
پاسخ به پیشنهاد SDP . این پاسخ، هرگونه جریان دریافتی از همتای راه دور را رد یا قبول میکند. همچنین در مورد اینکه کدام جریانها را قصد دارد به همتای ارائهدهنده ارسال کند، مذاکره میکند. توجه به این نکته مهم است که پاسخ SDP نمیتواند جریانهای سیگنالشده از پیشنهاد اولیه را اضافه کند. به طور خلاصه، اگر یک همتای ارائهدهنده اعلام کند که حداکثر سه جریان صوتی را از همتای راه دور خود میپذیرد، این همتای راه دور نمیتواند چهار جریان صوتی را برای انتقال سیگنال دهد.
- پیشنهاد SDP
SDP اولیه در جریان مذاکره همتا به همتا برای پیشنهاد-پاسخ. این پیشنهاد توسط همتای آغازگر ایجاد میشود و شرایط جلسه همتا به همتا را تعیین میکند. این پیشنهاد همیشه توسط کلاینت Meet Media API ایجاد و به سرورهای Meet ارسال میشود.
برای مثال، یک پیشنهاد ممکن است تعداد جریانهای صوتی یا تصویری که ارائهدهنده ارسال میکند (یا قادر به دریافت آنهاست) و اینکه آیا کانالهای داده باید باز شوند یا خیر را نشان دهد.
- منبع همگامسازی (SSRC)
SSRC یک شناسه ۳۲ بیتی است که به طور منحصر به فرد یک منبع واحد از جریان رسانه را در یک جلسه RTP (پروتکل انتقال در زمان واقعی) مشخص میکند. در WebRTC، از SSRC ها برای تمایز بین جریانهای رسانهای مختلف که از شرکتکنندگان مختلف یا حتی مسیرهای مختلف از یک شرکتکننده (مانند دوربینهای مختلف) سرچشمه میگیرند، استفاده میشود.
- فرستنده/گیرنده Rtp
همانطور که در
RFC 8829به تفصیل آمده است، فرستنده-گیرنده انتزاعی پیرامون جریانهای RTP در یک جلسه نظیر به نظیر است.یک فرستنده-گیرنده واحد به یک توصیف رسانه واحد در SDP نگاشت شده و توسط آن توصیف میشود. یک فرستنده-گیرنده شامل یک
RtpSenderو یکRtpReceiverاست.از آنجا که RTP دو طرفه است، هر همتا نمونه فرستنده-گیرنده مخصوص به خود را برای اتصال RTP یکسان دارد.
RtpSenderیک فرستنده-گیرنده معین برای همتای محلی بهRtpReceiverیک فرستنده-گیرنده خاص در همتای راه دور نگاشت میشود. عکس این قضیه نیز صادق است.RtpSenderهمان فرستنده-گیرنده همتای راه دور بهRtpReceiverهمتای محلی نگاشت میشود.هر توصیف رسانه، فرستنده/گیرنده اختصاصی خود را دارد. از این رو، یک جلسه نظیر به نظیر با چندین جریان RTP، چندین فرستنده/گیرنده با چندین
RtpSendersوRtpReceiverبرای هر نظیر دارد.- جریانهای رسانهای مجازی
جریانهای رسانهای مجازی، جریانهای رسانهای تجمیعی هستند که توسط یک واحد ارسال انتخابی (SFU) در کنفرانسهای WebRTC تولید میشوند. به جای اینکه هر شرکتکننده جریانهای جداگانهای را برای دیگران ارسال کند، SFU جریانهای شرکتکننده منتخب را به جریانهای مجازی خروجی کمتری تقسیم میکند. این امر توپولوژی اتصال را ساده کرده و بار روی شرکتکنندگان را کاهش میدهد و امکان کنفرانسهای مقیاسپذیر را فراهم میکند. هر جریان مجازی میتواند شامل رسانه از چندین شرکتکننده باشد که به صورت پویا توسط SFU مدیریت میشوند.
مباحث مرتبط
برای آشنایی با نحوه شروع توسعه کلاینت Meet Media API، مراحل موجود در بخش «شروع به کار» را دنبال کنید.
برای یادگیری نحوه راهاندازی و اجرای یک کلاینت مرجع نمونه Meet Media API، راهنمای سریع کلاینت مرجع C++ را مطالعه کنید.
برای دریافت یک مرور کلی مفهومی، به مفاهیم Meet Media API مراجعه کنید.
برای کسب اطلاعات بیشتر در مورد WebRTC، به WebRTC For The Curious مراجعه کنید.
برای کسب اطلاعات بیشتر در مورد توسعه با APIهای Google Workspace، از جمله مدیریت احراز هویت و مجوز، به «توسعه در Google Workspace» مراجعه کنید.
رابط برنامهنویسی کاربردی رسانه گوگل میت (Google Meet Media API) به شما امکان میدهد به رسانههای کنفرانسهای گوگل میت به صورت آنی دسترسی داشته باشید. این قابلیت، کاربردهای متنوعی را امکانپذیر میکند، مانند برنامههایی که موارد عملیاتی را مستند میکنند، بینشهای آنی در مورد جلسه فعلی ارائه میدهند یا صدا و تصویر را به یک سطح جدید پخش میکنند.
موارد استفاده
برنامههای ثبتشده در کنسول Google Cloud میتوانند از رابط برنامهنویسی کاربردی Meet Media برای اتصال به کنفرانسهای Meet استفاده کنند و این امکان را برای آنها فراهم میکند:
- از استریمهای ویدیویی استفاده کنید . برای مثال:
- پخشهای ویدیویی تولید شده در کنفرانسهای Meet را به مدلهای هوش مصنوعی خود وارد کنید.
- فیلتر کردن جریانها برای ضبطهای سفارشی.
- از جریانهای صوتی استفاده کنید . برای مثال:
- صدا را مستقیماً به Gemini ارسال کنید و چتبات هوش مصنوعی مخصوص جلسه خود را بسازید.
- پخش جریانهای صوتی تولید شده در کنفرانسهای Meet را به سرویس رونویسی خودتان ارسال کنید
- ایجاد زیرنویس به زبانهای مختلف.
- فیدهای زبان اشاره تولید شده توسط مدل را از صدای ضبط شده ایجاد کنید.
- مدلهای نویزگیر خودتان را بسازید تا پسزمینه و نویزهای اضافی را از کنفرانس حذف کنید.
- مصرف فرادادههای شرکتکنندگان . برای مثال:
- تشخیص اینکه کدام شرکتکنندگان در کنفرانس حضور دارند، که امکان هوش و تحلیل بهتر را فراهم میکند.
با چرخه عمر API رسانه آشنا شوید
تصاویر زیر چرخه حیات Meet Media API را نشان میدهند:
شکل ۱. ربات Meet Media API سعی میکند به وبسایت شخص ثالث متصل شود. در صورت وجود حسابهای کاربری زیر سن قانونی، اتصال رد میشود. شکل ۲. جلسات میتوانند به صورت رمزگذاری شده علامتگذاری شوند و دارای واترمارک باشند. وقتی جلسهای دارای رمزگذاری یا واترمارک باشد، نمیتوان به Meet Media API متصل شد. شکل ۳. مطمئن شوید که تنظیمات مدیر صحیح است. شکل ۴. تنظیم جلسه در تقویم. میزبان باید در تنظیمات تقویم به برنامه شخص ثالث اجازه دسترسی بدهد، در غیر این صورت اتصال رد میشود. شکل ۵. تغییر تنظیمات در حین تماس. اگر میزبان تصمیم بگیرد تنظیمات Meet Media API را در حین تماس غیرفعال کند، اتصال متوقف میشود. شکل ۶. اگر صاحب جلسه یک حساب کاربری مصرفکننده (حسابی که به @gmail.com ختم میشود) داشته باشد، آنگاه آغازگر جلسه باید برای اعلام رضایت حضور داشته باشد، در غیر این صورت اتصال رد میشود. شکل ۷. پس از برقراری اتصال، میزبان، میزبان مشترک یا هر شرکتکنندهای که در همان سازمان میزبان قرار دارد، پنجرهی شروع اتصال را مشاهده میکند. شکل ۸. هر کسی میتواند رابط برنامهنویسی کاربردی Meet Media را در طول تماس متوقف کند.
الزامات موافقت کننده
برنامههای رابط برنامهنویسی کاربردی Meet Media فقط در صورتی مجاز به ورود به جلسه هستند که شخصی در تماس وجود داشته باشد که مجاز به ارائه رضایت از طرف جلسه باشد.
برای جلسات Google Workspace
برای ارائه رضایت در جلسات Google Workspace، باید در سازمانی باشید که مالک جلسه است. در بیشتر موارد، مالک جلسه همان سازماندهنده است. اگر میزبان یا آغازگر در جلسه باشد و در سازمانی باشد که مالک جلسه است، ترجیحاً کادر گفتگوی شروع به او نشان داده میشود.
برای جلسات مصرفکنندگان
برای جلساتی که توسط حسابهای Gmail سازماندهی میشوند، آغازگر جلسه باید در جلسه حضور داشته باشد تا رضایت خود را ارائه دهد.
اصطلاحات رایج
- شماره پروژه ابری
- یک شناسه
int64تغییرناپذیر تولید شده برای یک پروژه Google Cloud. این مقادیر توسط کنسول Google Cloud برای هر برنامه ثبت شده تولید میشوند. - کنفرانس
- نمونهای از یک تماس تولید شده توسط سرور در فضای جلسه . کاربران معمولاً این سناریو را یک جلسه واحد در نظر میگیرند.
- کانال دادههای منابع کنفرانس
به جای درخواست منابع از طریق HTTP، مانند Google Meet REST API ، کلاینتهای Meet Media API منابع را از طریق کانالهای داده از سرور درخواست میکنند.
A dedicated data channel may be opened for each resource type. Once opened, the client can send requests over the channel. Resource updates will be transmitted over the same channel.
- منبع مشارکتکننده (CSRC)
در جریانهای رسانهای مجازی ، نمیتوانید فرض کنید که یک جریان رسانهای همیشه به یک شرکتکننده اشاره میکند. مقدار CSRC در هدر هر بسته RTP، منبع واقعی بسته را مشخص میکند.
Meet به هر شرکتکننده در کنفرانس، هنگام پیوستن، یک مقدار CSRC منحصر به فرد اختصاص میدهد. این مقدار تا زمان خروج آنها ثابت میماند.
- کانالهای داده
کانالهای داده WebRTC امکان تبادل دادههای دلخواه (متن، فایل و غیره) را مستقل از جریانهای صوتی و تصویری فراهم میکنند. کانالهای داده از همان اتصال جریانهای رسانهای استفاده میکنند و روشی کارآمد برای افزودن تبادل داده به برنامههای WebRTC ارائه میدهند.
- استقرار اتصال تعاملی (ICE)
پروتکلی برای برقراری اتصال، یافتن تمام مسیرهای ممکن برای ارتباط دو کامپیوتر با یکدیگر از طریق شبکه نظیر به نظیر (P2P) و سپس اطمینان از اتصال دائمی شما.
- جریان رسانهای
یک جریان رسانهای WebRTC نشاندهنده جریانی از دادههای رسانهای، معمولاً صوتی یا تصویری، است که از دستگاهی مانند دوربین یا میکروفون ضبط میشود. این جریان شامل یک یا چند تراک جریان رسانهای است که هر کدام نشاندهنده یک منبع واحد رسانهای مانند یک تراک ویدیویی یا یک تراک صوتی هستند.
- مسیر جریان رسانهای
شامل یک جریان واحد و یکطرفه از بستههای RTP است. یک مسیر جریان رسانه میتواند صوتی یا تصویری باشد، اما نه هر دو. یک اتصال دوطرفه پروتکل انتقال امن بلادرنگ (SRTP) معمولاً شامل دو مسیر جریان رسانه است، خروجی از همتای محلی به همتای راه دور و ورودی از همتای راه دور به همتای محلی.
- فضای جلسات
یک مکان مجازی یا یک شیء پایدار (مانند اتاق جلسه) که در آن کنفرانس برگزار میشود. فقط یک کنفرانس فعال میتواند در هر زمان در یک فضا برگزار شود. یک فضای جلسه همچنین به کاربران کمک میکند تا با یکدیگر ملاقات کرده و منابع مشترک را پیدا کنند.
- شرکتکننده
شخصی که به یک کنفرانس پیوسته یا از حالت همراهی استفاده میکند، به عنوان بیننده تماشا میکند، یا دستگاهی در اتاق که به یک تماس متصل است. وقتی یک شرکتکننده به کنفرانس میپیوندد، یک شناسه منحصر به فرد به او اختصاص داده میشود.
- جریانهای مرتبط
محدودیتی برای تعداد جریانهای صوتی مجازی و جریانهای ویدیویی مجازی که یک کلاینت میتواند باز کند، وجود دارد.
کاملاً ممکن است که تعداد شرکتکنندگان در یک کنفرانس از این تعداد بیشتر شود. در این شرایط، سرورهای Meet جریانهای صوتی و تصویری شرکتکنندگانی را که "مرتبطترین" تشخیص داده میشوند، ارسال میکنند. مرتبط بودن از ویژگیهای مختلفی مانند اشتراکگذاری صفحه نمایش و اینکه یک شرکتکننده اخیراً چه زمانی صحبت کرده است، تعیین میشود.
- واحد حمل و نقل انتخابی (SFU)
واحد ارسال انتخابی (SFU) یک جزء سمت سرور در کنفرانس WebRTC است که توزیع جریان رسانه را مدیریت میکند. شرکتکنندگان فقط به SFU متصل میشوند، که به صورت انتخابی جریانهای مرتبط را به سایر شرکتکنندگان ارسال میکند. این امر نیاز به پردازش و پهنای باند کلاینت را کاهش میدهد و امکان کنفرانسهای مقیاسپذیر را فراهم میکند.
- پروتکل توصیف جلسه (SDP)
مکانیزم سیگنالدهی که WebRTC برای مذاکره در یک اتصال P2P استفاده میکند.
RFC 8866آن را مدیریت میکند.- پاسخ SDP
پاسخ به پیشنهاد SDP . این پاسخ، هرگونه جریان دریافتی از همتای راه دور را رد یا قبول میکند. همچنین در مورد اینکه کدام جریانها را قصد دارد به همتای ارائهدهنده ارسال کند، مذاکره میکند. توجه به این نکته مهم است که پاسخ SDP نمیتواند جریانهای سیگنالشده از پیشنهاد اولیه را اضافه کند. به طور خلاصه، اگر یک همتای ارائهدهنده اعلام کند که حداکثر سه جریان صوتی را از همتای راه دور خود میپذیرد، این همتای راه دور نمیتواند چهار جریان صوتی را برای انتقال سیگنال دهد.
- پیشنهاد SDP
SDP اولیه در جریان مذاکره همتا به همتا برای پیشنهاد-پاسخ. این پیشنهاد توسط همتای آغازگر ایجاد میشود و شرایط جلسه همتا به همتا را تعیین میکند. این پیشنهاد همیشه توسط کلاینت Meet Media API ایجاد و به سرورهای Meet ارسال میشود.
برای مثال، یک پیشنهاد ممکن است تعداد جریانهای صوتی یا تصویری که ارائهدهنده ارسال میکند (یا قادر به دریافت آنهاست) و اینکه آیا کانالهای داده باید باز شوند یا خیر را نشان دهد.
- منبع همگامسازی (SSRC)
SSRC یک شناسه ۳۲ بیتی است که به طور منحصر به فرد یک منبع واحد از جریان رسانه را در یک جلسه RTP (پروتکل انتقال در زمان واقعی) مشخص میکند. در WebRTC، از SSRC ها برای تمایز بین جریانهای رسانهای مختلف که از شرکتکنندگان مختلف یا حتی مسیرهای مختلف از یک شرکتکننده (مانند دوربینهای مختلف) سرچشمه میگیرند، استفاده میشود.
- فرستنده/گیرنده Rtp
همانطور که در
RFC 8829به تفصیل آمده است، فرستنده-گیرنده انتزاعی پیرامون جریانهای RTP در یک جلسه نظیر به نظیر است.یک فرستنده-گیرنده واحد به یک توصیف رسانه واحد در SDP نگاشت شده و توسط آن توصیف میشود. یک فرستنده-گیرنده شامل یک
RtpSenderو یکRtpReceiverاست.از آنجا که RTP دو طرفه است، هر همتا نمونه فرستنده-گیرنده مخصوص به خود را برای اتصال RTP یکسان دارد.
RtpSenderیک فرستنده-گیرنده معین برای همتای محلی بهRtpReceiverیک فرستنده-گیرنده خاص در همتای راه دور نگاشت میشود. عکس این قضیه نیز صادق است.RtpSenderهمان فرستنده-گیرنده همتای راه دور بهRtpReceiverهمتای محلی نگاشت میشود.هر توصیف رسانه، فرستنده/گیرنده اختصاصی خود را دارد. از این رو، یک جلسه نظیر به نظیر با چندین جریان RTP، چندین فرستنده/گیرنده با چندین
RtpSendersوRtpReceiverبرای هر نظیر دارد.- جریانهای رسانهای مجازی
جریانهای رسانهای مجازی، جریانهای رسانهای تجمیعی هستند که توسط یک واحد ارسال انتخابی (SFU) در کنفرانسهای WebRTC تولید میشوند. به جای اینکه هر شرکتکننده جریانهای جداگانهای را برای دیگران ارسال کند، SFU جریانهای شرکتکننده منتخب را به جریانهای مجازی خروجی کمتری تقسیم میکند. این امر توپولوژی اتصال را ساده کرده و بار روی شرکتکنندگان را کاهش میدهد و امکان کنفرانسهای مقیاسپذیر را فراهم میکند. هر جریان مجازی میتواند شامل رسانه از چندین شرکتکننده باشد که به صورت پویا توسط SFU مدیریت میشوند.
مباحث مرتبط
برای آشنایی با نحوه شروع توسعه کلاینت Meet Media API، مراحل موجود در بخش «شروع به کار» را دنبال کنید.
برای یادگیری نحوه راهاندازی و اجرای یک کلاینت مرجع نمونه Meet Media API، راهنمای سریع کلاینت مرجع C++ را مطالعه کنید.
برای دریافت یک مرور کلی مفهومی، به مفاهیم Meet Media API مراجعه کنید.
برای کسب اطلاعات بیشتر در مورد WebRTC، به WebRTC For The Curious مراجعه کنید.
برای کسب اطلاعات بیشتر در مورد توسعه با APIهای Google Workspace، از جمله مدیریت احراز هویت و مجوز، به «توسعه در Google Workspace» مراجعه کنید.