Media API के कॉन्सेप्ट के मुताबिक होना चाहिए
संग्रह की मदद से व्यवस्थित रहें
अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
Google Meet Media API की मदद से, आपका ऐप्लिकेशन Google Meet कॉन्फ़्रेंस में शामिल हो सकता है. साथ ही, रीयल-टाइम मीडिया स्ट्रीम का इस्तेमाल कर सकता है.
क्लाइंट, Meet सर्वर से कम्यूनिकेट करने के लिए WebRTC का इस्तेमाल करते हैं. दिए गए रेफ़रंस क्लाइंट (C++, TypeScript) में, सुझाई गई सबसे सही तरीके दिखाए गए हैं. हमारा सुझाव है कि आप सीधे तौर पर इनका इस्तेमाल करें.
हालांकि, आपके पास पूरी तरह से कस्टम WebRTC क्लाइंट बनाने का विकल्प भी होता है. ये क्लाइंट, Meet Media API की तकनीकी ज़रूरी शर्तों के मुताबिक होने चाहिए.
इस पेज पर, Meet Media API सेशन को सही तरीके से इस्तेमाल करने के लिए ज़रूरी WebRTC के मुख्य कॉन्सेप्ट के बारे में बताया गया है.
ऑफ़र-आंसर सिग्नलिंग
WebRTC एक पीयर-टू-पीयर (P2P) फ़्रेमवर्क है. इसमें पीयर, एक-दूसरे को सिग्नल भेजकर कम्यूनिकेट करते हैं. सेशन शुरू करने के लिए, सेशन शुरू करने वाला पीयर, रिमोट पीयर को SDP
ऑफ़र भेजता है. इस ऑफ़र में यह अहम जानकारी शामिल है:
ऑडियो और वीडियो के लिए मीडिया के ब्यौरे
मीडिया के ब्यौरे से पता चलता है कि पी2पी सेशन के दौरान क्या कम्यूनिकेट किया जाता है. जानकारी तीन तरह की होती है: ऑडियो, वीडियो, और डेटा.
ऑफ़र देने वाला व्यक्ति, ऑफ़र में n ऑडियो मीडिया की जानकारी शामिल करता है, ताकि n ऑडियो स्ट्रीम के बारे में बताया जा सके. वीडियो के लिए भी यही नियम लागू होता है. हालांकि, ज़्यादा से ज़्यादा एक डेटा मीडिया ब्यौरा होगा.
दिशा
हर ऑडियो या वीडियो की जानकारी में, सिक्योर रीयल-टाइम ट्रांसपोर्ट प्रोटोकॉल (एसआरटीपी) की अलग-अलग स्ट्रीम के बारे में बताया जाता है. इन स्ट्रीम को RFC
3711 कंट्रोल करता है. ये दोनों तरफ़ से काम करते हैं. इसलिए, दो पीयर एक ही कनेक्शन पर मीडिया भेज और पा सकते हैं.
इस वजह से, ऑफ़र और जवाब, दोनों में मौजूद हर मीडिया ब्यौरे में तीन एट्रिब्यूट में से कोई एक एट्रिब्यूट शामिल होता है. इससे यह पता चलता है कि स्ट्रीम का इस्तेमाल कैसे किया जाना चाहिए:
sendonly: सिर्फ़ ऑफ़र करने वाले पीयर से मीडिया भेजता है. रिमोट पीयर, इस स्ट्रीम पर मीडिया नहीं भेजेगा.
recvonly: यह सिर्फ़ रिमोट पीयर से मीडिया हासिल करता है. ऑफ़र करने वाला व्यक्ति इस स्ट्रीम पर मीडिया नहीं भेजेगा.
sendrecv: दोनों पीयर इस स्ट्रीम पर डेटा भेज और पा सकते हैं.
कोडेक
हर मीडिया ब्यौरे में, उन कोडेक के बारे में भी बताया जाता है जिन्हें पीयर इस्तेमाल कर सकता है. Meet Media API के मामले में, क्लाइंट के ऑफ़र तब तक अस्वीकार कर दिए जाते हैं, जब तक वे तकनीकी ज़रूरी शर्तों में बताए गए कोडेक के साथ काम नहीं करते.
डीटीएलएस हैंडशेक
एसआरटीपी स्ट्रीम को सुरक्षित करने के लिए, पीयर के बीच शुरुआती डेटाग्राम ट्रांसपोर्ट लेयर सिक्योरिटी ("डीटीएलएस", RFC
9147) हैंडशेक किया जाता है.
आम तौर पर, DTLS एक क्लाइंट-टू-सर्वर प्रोटोकॉल होता है. सिग्नलिंग प्रोसेस के दौरान, एक पीयर सर्वर के तौर पर काम करने के लिए सहमत होता है, जबकि दूसरा पीयर के तौर पर काम करता है.
हर एसआरटीपी स्ट्रीम का अपना डीटीएलएस कनेक्शन हो सकता है. इसलिए, हर मीडिया ब्यौरे में तीन एट्रिब्यूट में से किसी एक को शामिल किया जाता है. इससे डीटीएलएस हैंडशेक में पीयर की भूमिका के बारे में पता चलता है:
a=setup:actpass: ऑफ़र करने वाला सहकर्मी, रिमोट सहकर्मी की पसंद को प्राथमिकता देता है.
a=setup:active: यह पीयर, क्लाइंट के तौर पर काम करता है.
a=setup:passive: यह पीयर, सर्वर के तौर पर काम करता है.
ऐप्लिकेशन के मीडिया का ब्यौरा
डेटा चैनल (RFC 8831), स्ट्रीम कंट्रोल ट्रांसमिशन प्रोटोकॉल ("SCTP", RFC
9260) का एक ऐब्स्ट्रैक्शन है.
शुरुआती सिग्नलिंग फ़ेज़ के दौरान डेटा चैनल खोलने के लिए, ऑफ़र में ऐप्लिकेशन मीडिया की जानकारी शामिल होनी चाहिए. ऑडियो और वीडियो के ब्यौरे के उलट, ऐप्लिकेशन के ब्यौरे में दिशा या कोडेक के बारे में नहीं बताया जाता.
ICE के उम्मीदवार
किसी पीयर के इंटरैक्टिव कनेक्टिविटी इस्टैब्लिशमेंट ("ICE", RFC
8445) कैंडिडेट, उन रास्तों की सूची होते हैं जिनका इस्तेमाल कोई रिमोट पीयर, कनेक्शन बनाने के लिए कर सकता है.
दो पियर की सूचियों के कार्टेशियन प्रॉडक्ट को कैंडिडेट पेयर कहा जाता है. यह दो पियर के बीच संभावित रास्तों को दिखाता है. इन पेयर की जांच की जाती है, ताकि सबसे सही रास्ता तय किया जा सके.
ऑडियो मीडिया के ब्यौरे वाला ऑफ़र यहां दिया गया है:
पहली इमेज. ऑडियो मीडिया की जानकारी देने वाले ऑफ़र का उदाहरण.
रिमोट पीयर, एसडीपी जवाब के साथ जवाब देता है. इसमें मीडिया की जानकारी देने वाली लाइनों की संख्या उतनी ही होती है. हर लाइन से पता चलता है कि रिमोट पीयर, SRTP स्ट्रीम में ऑफ़र करने वाले क्लाइंट को कौनसी मीडिया स्ट्रीम भेजता है. दूर मौजूद पीयर, ऑफ़र करने वाले व्यक्ति की कुछ स्ट्रीम को भी अस्वीकार कर सकता है. इसके लिए, उसे मीडिया के ब्यौरे वाली एंट्री को recvonly पर सेट करना होगा.
Meet Media API के लिए, क्लाइंट हमेशा कनेक्शन शुरू करने के लिए एसडीपी ऑफ़र भेजते हैं. Meet कभी भी मीटिंग शुरू नहीं करता है.
इस व्यवहार को रेफ़रंस क्लाइंट (C++, TypeScript) मैनेज करते हैं. हालांकि, कस्टम क्लाइंट के डेवलपर, ऑफ़र जनरेट करने के लिए WebRTC के PeerConnectionInterface का इस्तेमाल कर सकते हैं.
Meet Meet से कनेक्ट करने के लिए, ऑफ़र को कुछ ज़रूरी शर्तों का पालन करना होगा:
DTLS हैंडशेक में क्लाइंट को हमेशा क्लाइंट के तौर पर काम करना चाहिए. इसलिए, ऑफ़र में मौजूद हर मीडिया ब्यौरे में, a=setup:actpass या a=setup:active में से किसी एक को तय करना होगा.
मीडिया के ब्यौरे की हर लाइन में, उस मीडिया टाइप के लिए ज़रूरी
कोडेक होने चाहिए:
ऑडियो:Opus
वीडियो:VP8, VP9, AV1
ऑडियो पाने के लिए, ऑफ़र में सिर्फ़ तीन ऑडियो मीडिया
डिटेल शामिल होनी चाहिए. इसके लिए, पीयर कनेक्शन ऑब्जेक्ट पर ट्रांससीवर सेट करें.
वीडियो पाने के लिए, ऑफ़र में सिर्फ़ वीडियो पाने के लिए इस्तेमाल होने वाले मीडिया के 1 से 3 ब्यौरे शामिल होने चाहिए. इसके लिए, पीयर कनेक्शन ऑब्जेक्ट पर ट्रांससीवर सेट करें.
यहां मान्य एसडीपी ऑफ़र और उससे मेल खाने वाले एसडीपी जवाब का पूरा उदाहरण दिया गया है. इस ऑफ़र में, ऑडियो और एक वीडियो स्ट्रीम के साथ Meet Media API सेशन के लिए बातचीत की जाती है.
देखें कि यहां ऑडियो मीडिया के तीन ब्यौरे, वीडियो मीडिया का एक ब्यौरा, और ऐप्लिकेशन मीडिया का ज़रूरी ब्यौरा मौजूद है.
[[["समझने में आसान है","easyToUnderstand","thumb-up"],["मेरी समस्या हल हो गई","solvedMyProblem","thumb-up"],["अन्य","otherUp","thumb-up"]],[["वह जानकारी मौजूद नहीं है जो मुझे चाहिए","missingTheInformationINeed","thumb-down"],["बहुत मुश्किल है / बहुत सारे चरण हैं","tooComplicatedTooManySteps","thumb-down"],["पुराना","outOfDate","thumb-down"],["अनुवाद से जुड़ी समस्या","translationIssue","thumb-down"],["सैंपल / कोड से जुड़ी समस्या","samplesCodeIssue","thumb-down"],["अन्य","otherDown","thumb-down"]],["आखिरी बार 2026-10-01 (UTC) को अपडेट किया गया."],[],[]]