Google Meet Media API की मदद से, आपका ऐप्लिकेशन Google Meet कॉन्फ़्रेंस में शामिल हो सकता है और रीयल-टाइम में मीडिया स्ट्रीम का इस्तेमाल कर सकता है.
क्लाइंट, Meet सर्वर से बातचीत करने के लिए WebRTC का इस्तेमाल करते हैं. दिए गए रेफ़रंस क्लाइंट (C++,
TypeScript), सुझाए गए तरीकों को दिखाते हैं. इसलिए, हमारा सुझाव है कि आप सीधे इन पर आधारित क्लाइंट बनाएं.
हालांकि, Meet Media API की तकनीकी ज़रूरी शर्तों को पूरा करने वाले, पूरी तरह से कस्टम WebRTC क्लाइंट भी बनाए जा सकते हैं.
इस पेज पर, Meet Media API सेशन को सही तरीके से चलाने के लिए ज़रूरी WebRTC के मुख्य कॉन्सेप्ट के बारे में बताया गया है.
ऑफ़र-जवाब सिग्नलिंग
WebRTC एक पीयर-टू-पीयर (पी2पी) फ़्रेमवर्क है, जहां पीयर एक-दूसरे को सिग्नल भेजकर कम्यूनिकेट करते हैं. सेशन शुरू करने के लिए, शुरू करने वाला पीयर, रिमोट पीयर को एसडीपी ऑफ़र भेजता है. इस ऑफ़र में ये ज़रूरी जानकारी शामिल है:
ऑडियो और वीडियो के लिए मीडिया की जानकारी
मीडिया की जानकारी से पता चलता है कि पी2पी सेशन के दौरान क्या जानकारी शेयर की गई है. जानकारी तीन तरह की होती है: ऑडियो, वीडियो, और डेटा.
n ऑडियो स्ट्रीम की जानकारी देने के लिए, ऑफ़र देने वाला व्यक्ति या कंपनी, ऑफ़र में n ऑडियो मीडिया की जानकारी शामिल करता है. वीडियो के लिए भी यही बात लागू होती है. हालांकि, ज़्यादा से ज़्यादा एक डेटा मीडिया ब्यौरा होगा.
दिशा
हर ऑडियो या वीडियो की जानकारी में, RFC
3711 से कंट्रोल की जाने वाली अलग-अलग सिक्योर रीयल-टाइम ट्रांसपोर्ट प्रोटोकॉल (एसआरटीपी) स्ट्रीम के बारे में बताया जाता है. ये दोतरफ़ा होते हैं. इनकी मदद से, दो पीयर एक ही कनेक्शन पर मीडिया भेज और पा सकते हैं.
इस वजह से, ऑफ़र और जवाब, दोनों में मौजूद हर मीडिया ब्यौरे में, स्ट्रीम का इस्तेमाल करने के तरीके के बारे में बताने वाला तीन में से एक एट्रिब्यूट होता है:
sendonly: सिर्फ़ ऑफ़र करने वाले पीयर से मीडिया भेजता है. रिमोट पीयर, इस स्ट्रीम पर मीडिया नहीं भेजेगा.
recvonly: सिर्फ़ रिमोट पीयर से मीडिया पाता है. ऑफ़र करने वाला पीयर, इस स्ट्रीम पर मीडिया नहीं भेजेगा.
sendrecv: इस स्ट्रीम पर, दोनों पीयर डेटा भेज और पा सकते हैं.
कोडेक
हर मीडिया के ब्यौरे में, यह भी बताया जाता है कि पीयर किन कोडेक के साथ काम करता है. Meet Media API के मामले में, क्लाइंट के ऑफ़र तब तक अस्वीकार कर दिए जाते हैं, जब तक वे तकनीकी ज़रूरी शर्तों में बताए गए कोडेक के साथ काम नहीं करते.
डीटीएलएस हैंडशेक
SRTP स्ट्रीम को सुरक्षित करने के लिए, पीयर के बीच डेटाग्राम ट्रांसपोर्ट लेयर सिक्योरिटी ("DTLS", RFC
9147) हैंडशेक का इस्तेमाल किया जाता है.
DTLS आम तौर पर क्लाइंट-टू-सर्वर प्रोटोकॉल होता है. सिग्नल भेजने की प्रोसेस के दौरान, एक पीयर सर्वर के तौर पर काम करता है, जबकि दूसरा पीयर के तौर पर काम करता है.
हर SRTP स्ट्रीम का अपना खास डीटीएलएस कनेक्शन हो सकता है. इसलिए, हर मीडिया ब्यौरे में तीन में से किसी एक एट्रिब्यूट की जानकारी दी जाती है, ताकि डीटीएलएस हैंडशेक में पीयर की भूमिका के बारे में पता चल सके:
a=setup:actpass: ऑफ़र देने वाला पीयर, रिमोट पीयर की पसंद के हिसाब से काम करता है.
a=setup:active: यह पीयर क्लाइंट के तौर पर काम करता है.
a=setup:passive: यह पीयर, सर्वर के तौर पर काम करता है.
ऐप्लिकेशन के मीडिया का ब्यौरा
डेटा चैनल (RFC 8831), स्ट्रीम कंट्रोल ट्रांसमिशन प्रोटोकॉल ("एससीटीपी", RFC
9260) का एक एब्स्ट्रैक्शन है.
शुरुआती सिग्नल भेजने के दौरान डेटा चैनल खोलने के लिए, ऑफ़र में ऐप्लिकेशन मीडिया की जानकारी होनी चाहिए. ऑडियो और वीडियो के ब्यौरे के उलट, ऐप्लिकेशन के ब्यौरे में डायरेक्शन या कोडेक की जानकारी नहीं दी जाती.
ICE के उम्मीदवार
किसी पीयर के इंटरैक्टिव कनेक्टिविटी एस्टैब्लिशमेंट ("आईसीई", RFC
8445) के उम्मीदवार, उन रास्तों की सूची होते हैं जिनका इस्तेमाल करके, कोई रिमोट पीयर कनेक्शन बना सकता है.
दो पीयर की सूचियों का कार्टेशियन प्रॉडक्ट, कैन्डिडेट पेयर के तौर पर जाना जाता है. यह दो पीयर के बीच के संभावित रास्तों को दिखाता है. सबसे सही रास्ता तय करने के लिए, इन पेयर की जांच की जाती है.
यहां एक ऐसा ऑफ़र दिया गया है जिसमें ऑडियो मीडिया की जानकारी दी गई है:
पहली इमेज. ऑडियो मीडिया की जानकारी वाले ऑफ़र का उदाहरण.
रिमोट पीयर, एसडीपी के जवाब के साथ जवाब देता है. इसमें मीडिया के ब्यौरे की उतनी ही लाइनें होती हैं जितनी लाइनें होस्ट ने भेजी हैं. हर लाइन से पता चलता है कि रिमोट पार्टनर, SRTP स्ट्रीम के ज़रिए ऑफ़र करने वाले क्लाइंट को कौनसा मीडिया भेजता है. रिमोट पार्टनर, मीडिया ब्यौरे की एंट्री को recvonly पर सेट करके, ऑफ़र करने वाले की कुछ स्ट्रीम को भी अस्वीकार कर सकता है.
Meet Media API के लिए, क्लाइंट हमेशा कनेक्शन शुरू करने के लिए एसडीपी ऑफ़र भेजते हैं. Meet कभी भी मीटिंग शुरू नहीं करता.
इस व्यवहार को रेफ़रंस क्लाइंट (C++, TypeScript) के ज़रिए मैनेज किया जाता है. हालांकि, कस्टम क्लाइंट के डेवलपर, ऑफ़र जनरेट करने के लिए WebRTC के PeerConnectionInterface का इस्तेमाल कर सकते हैं.
Meet से कनेक्ट करने के लिए, ऑफ़र को कुछ खास शर्तों को पूरा करना होगा:
DTLS हैंडशेक में क्लाइंट को हमेशा क्लाइंट के तौर पर काम करना चाहिए. इसलिए, ऑफ़र में मौजूद हर मीडिया के ब्यौरे में a=setup:actpass या
a=setup:active में से किसी एक को बताना ज़रूरी है.
मीडिया के ब्यौरे की हर लाइन में, उस मीडिया टाइप के लिए सभी ज़रूरी कोडेक काम करने चाहिए:
ऑडियो:Opus
वीडियो:VP8, VP9, AV1
ऑडियो पाने के लिए, ऑफ़र में सिर्फ़ पाने के लिए उपलब्ध तीन ऑडियो मीडिया के ब्यौरे होने चाहिए. ऐसा करने के लिए, पीयर कनेक्शन ऑब्जेक्ट पर ट्रांसीवर सेट करें.
यहां मान्य एसडीपी ऑफ़र और उससे मैच करने वाले एसडीपी जवाब का पूरा उदाहरण दिया गया है. इस ऑफ़र में, ऑडियो और एक वीडियो स्ट्रीम के साथ Meet Media API सेशन के लिए बातचीत की जाती है.
ध्यान दें कि यहां तीन ऑडियो मीडिया के ब्यौरे, एक वीडियो मीडिया के ब्यौरे, और ऐप्लिकेशन के मीडिया के ज़रूरी ब्यौरे हैं.
[null,null,["आखिरी बार 2025-03-06 (UTC) को अपडेट किया गया."],[[["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."]]],[]]