Meet Media API की गड़बड़ियों को हल करना

इस गाइड में, Google Meet Media API से जुड़ी सामान्य गड़बड़ियों को ठीक करने का तरीका बताया गया है.

गड़बड़ी कोड से जुड़ी समस्या हल करना

connectActiveConference एंडपॉइंट से मिले गड़बड़ी कोड की समस्या हल करने के लिए, यहां सलाह दी गई है:

यूनिफ़ाइड प्लान

अगर डेटा चैनल कभी नहीं खुलते और आपको कभी ऑडियो या वीडियो नहीं मिलता, तो देखें कि लोकल पीयर कनेक्शन को कॉन्फ़िगर करते समय, सिर्फ़ यूनिफ़ाइड प्लान का इस्तेमाल किया गया है या नहीं.

मीडिया के ब्यौरे के क्रम से जुड़ी गड़बड़ी

सेशन डिस्क्रिप्शन प्रोटोकॉल (एसडीपी) ऑफ़र की मदद से, पीयर-टू-पीयर कनेक्शन बनाते समय, आपको गड़बड़ी का यह मैसेज दिख सकता है:

Failed to execute 'setRemoteDescription' on 'RTCPeerConnection':
Failed to set remote answer sdp:
The order of m-lines in answer doesn't match order in offer. Rejecting answer.

इसका मतलब है कि एसडीपी के जवाब में मीडिया के ब्यौरे वाली लाइनें, एसडीपी के ऑफ़र में मीडिया के ब्यौरे से मेल नहीं खाती हैं:

इस गड़बड़ी को ठीक करने के लिए, पक्का करें कि मिलते-जुलते मीडिया टाइप सही तरीके से कॉन्फ़िगर किए गए हों और पीयर कनेक्शन ऑब्जेक्ट सेट करते समय, उन्हें एक साथ ग्रुप किया गया हो. इंटरलीव किए गए मीडिया के ब्यौरे का इस्तेमाल नहीं किया जा सकता.

यहां दिए गए कोड सैंपल में, मीडिया की जानकारी को सही तरीके से मैच करने का तरीका बताया गया है:

rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;

// Signal the entire video at once.
for (uint32_t i = 0; i < configurations.receiving_video_stream_count; ++i) {
    webrtc::RtpTransceiverInit video_init;
    video_init.direction = webrtc::RtpTransceiverDirection::kRecvOnly;
    video_init.stream_ids = {absl::StrCat("video_stream_", i)};

    webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::RtpTransceiverInterface>>
        video_result = peer_connection->AddTransceiver(
            cricket::MediaType::MEDIA_TYPE_VIDEO, video_init);
  // . . .
}

pc = new RTCPeerConnection();

// Signal the entire video at once.
pc.addTransceiver(video, {'direction':'recvonly'});
pc.addTransceiver(video, {'direction':'recvonly'});
pc.addTransceiver(video, {'direction':'recvonly'});

डीटीएलएस भूमिका एट्रिब्यूट से जुड़ी गड़बड़ी

DTLS भूमिका एट्रिब्यूट सेट करते समय, आपको गड़बड़ी दिख सकती है:

All DTLS roles must be one of [ACTIVE, ACTPASS].

यह गड़बड़ी तब होती है, जब SDP ऑफ़र में सभी मीडिया डिस्क्रिप्शन के लिए a=setup:< > एट्रिब्यूट की वैल्यू सही तरीके से सेट न की गई हो.

इस गड़बड़ी को ठीक करने के लिए, पक्का करें कि एसडीपी ऑफ़र में मौजूद हर मीडिया के ब्यौरे में, इनमें से कोई एक ज़रूरी एट्रिब्यूट मौजूद हो:

• a=setup:actpass
• a=setup:active

v=0
o=- 4743178474630771513 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS
. . .
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101
. . .
a=setup:actpass
. . .
m=audio 39807 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=setup:actpass
. . .

ऑडियो से जुड़ी समस्याएं हल करना

नीचे दिए गए सेक्शन से, आपके ऐप्लिकेशन में ऑडियो से जुड़ी समस्याओं को हल करने में मदद मिल सकती है.

लॉग देखना

अगर Chrome ब्राउज़र में वेब क्लाइंट का इस्तेमाल किया जा रहा है, तो:

1. नया टैब खोलें और पता बार में यह डालें: chrome://webrtc-internals.
2. Stats graph for inbound-rtp लेबल वाले सेक्शन पर जाएं.
3. हर ऑडियो ग्राफ़ की जांच करके देखें कि पैकेट मिल रहे हैं या नहीं.

अगर C++ रेफ़रंस क्लाइंट का इस्तेमाल किया जा रहा है, तो देखें कि OnAudioFrame को कभी कॉल किया गया है या नहीं.

OAuth के दायरों की पुष्टि करना

ऑडियो सिर्फ़ तब ट्रांसमिट किया जाता है, जब शुरुआती कनेक्शन अनुरोध के साथ सही दायरा दिया गया हो. गड़बड़ी को ठीक करने के लिए, पक्का करें कि आपने सही OAuth 2.0 स्कोप दिए हों. ज़्यादा जानकारी के लिए, Meet Media API के दायरे देखें.

पुष्टि करें कि कॉन्फ़्रेंस सही तरीके से सेट अप किया गया है

• जब क्लाइंट, Google Meet के सर्वर से कनेक्ट होता है, तो वह कॉन्फ़्रेंस में अपने-आप शामिल नहीं होता. पक्का करें कि आपको सेशन कंट्रोल डेटा चैनल पर, सेशन कंट्रोल रिसॉर्स का अपडेट मिला हो. साथ ही, उसकी स्थिति STATE_JOINED हो.

  {"sessionStatus":{"connectionState":"STATE_JOINED"}}
  

• पक्का करें कि मीटिंग में शामिल ऐसे अन्य लोग हों जिनकी ऑडियो स्ट्रीम म्यूट न की गई हों.

ऑडियो के लिए सिग्नल की पुष्टि करना

Meet सिर्फ़ तब ऑडियो उपलब्ध कराता है, जब एसडीपी ऑफ़र में इसकी जानकारी दी गई हो. ऑफ़र में सिर्फ़ पाने के लिए, तीन ऑडियो मीडिया ब्यौरे होने चाहिए.

m=audio 39807 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=mid:0
. . .
a=recvonly
. . .
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=mid:1
. . .
a=recvonly
. . .
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=mid:2
. . .
a=recvonly
. . .
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
. . .

अगर Meet सर्वर को कोई मान्य ऑफ़र मिलता है, तो वे एसडीपी के जवाब के साथ जवाब देते हैं. इसमें, सिर्फ़ भेजने के लिए उपलब्ध तीन ऑडियो मीडिया की जानकारी होती है.

m=audio 19306 UDP/TLS/RTP/SAVPF 111
. . .
a=mid:0
. . .
a=sendonly
a=msid:virtual-6666 virtual-6666
. . .
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111
. . .
a=mid:1
. . .
a=sendonly
a=msid:virtual-6667 virtual-6667
. . .
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111
. . .
a=mid:2
. . .
a=sendonly
a=msid:virtual-6668 virtual-6668
. . .
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
. . .

आपने ऑब्ज़र्वर को लागू किया है या नहीं, इसकी जांच करना

अगर डेटा प्रोसेसिंग को किसी दूसरी थ्रेड पर ले जाया जाता है, तो ऑडियो डेटा की कॉपी बनाना न भूलें. AudioFrame.pcm16 असल में, डेटा के रेफ़रंस के तौर पर काम करता है. इसलिए, OnAudioFrame के बाद इसे ऐक्सेस करने की कोशिश करने पर, सेगमेंटेशन फ़ॉल्ट जैसा कोई गड़बड़ी का मैसेज दिख सकता है.

वीडियो से जुड़ी समस्याएं हल करना

यहां दिए गए सेक्शन से, आपके ऐप्लिकेशन में वीडियो से जुड़ी समस्याओं को हल करने में मदद मिल सकती है.

लॉग देखना

अगर Chrome ब्राउज़र में वेब क्लाइंट का इस्तेमाल किया जा रहा है, तो:

1. नया टैब खोलें और पता बार में यह डालें: chrome://webrtc-internals.
2. Stats graph for inbound-rtp लेबल वाले सेक्शन पर जाएं.
3. हर वीडियो के ग्राफ़ की जांच करके देखें कि पैकेट मिल रहे हैं या नहीं.

अगर C++ रेफ़रंस क्लाइंट का इस्तेमाल किया जा रहा है, तो देखें कि OnVideoFrame को कभी कॉल किया गया है या नहीं.

OAuth के दायरों की पुष्टि करना

वीडियो सिर्फ़ तब ट्रांसमिट किया जाता है, जब शुरुआती कनेक्शन अनुरोध के साथ सही दायरा दिया गया हो. गड़बड़ी को ठीक करने के लिए, पक्का करें कि आपने सही OAuth 2.0 स्कोप दिए हों. ज़्यादा जानकारी के लिए, Meet Media API के दायरे देखें.

पुष्टि करें कि कॉन्फ़्रेंस सही तरीके से सेट अप किया गया है

• जब क्लाइंट, Meet के सर्वर से कनेक्ट होता है, तो वह कॉन्फ़्रेंस में अपने-आप शामिल नहीं होता. पक्का करें कि आपको सेशन कंट्रोल डेटा चैनल पर, सेशन कंट्रोल रिसॉर्स का अपडेट मिला हो. साथ ही, उसकी स्थिति STATE_JOINED हो.

  {"sessionStatus":{"connectionState":"STATE_JOINED"}}
  

• पुष्टि करें कि कॉन्फ़्रेंस में शामिल ऐसे लोग भी हों जिनकी वीडियो स्ट्रीम म्यूट न की गई हों.

वीडियो के लिए सिग्नल की पुष्टि करना

Meet सिर्फ़ तब वीडियो दिखाता है, जब SDP ऑफ़र में इसका सिग्नल दिया गया हो. ऑफ़र में, सिर्फ़ पाने के लिए उपलब्ध, वीडियो मीडिया के ब्यौरे ज़्यादा से ज़्यादा तीन होने चाहिए.

v=0
o=- 4743178474630771513 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS
. . .
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 35 36 37 38 102 103 104 105 106 107 108 109 127 125 39 40 41 42 43 44 45 46 47 48 112 113 114 115 116 117 118 49
. . .
a=setup:actpass
a=mid:1
. . .
a=recvonly
. . .
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
. . .

अगर Meet को कोई मान्य ऑफ़र मिलता है, तो वह SDP के जवाब के साथ रिस्पॉन्स देता है. इसमें n सिर्फ़ भेजे जाने वाले वीडियो मीडिया के ब्यौरे होते हैं. n, SDP ऑफ़र में वीडियो मीडिया के ब्यौरे की संख्या होती है.

v=0
o=- 0 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS virtual-video-7777/7777
a=ice-lite
. . .
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99
. . .
a=setup:passive
a=mid:1
. . .
a=msid:virtual-video-7777/7777 virtual-video-7777/7777
a=rtcp-mux
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
. . .

वीडियो न दिखने की समस्या हल करना

• देखें कि Meet सर्वर को भेजे गए एसडीपी ऑफ़र में m=video … मौजूद है या नहीं.
• देखें कि a=recvonly हर m=video लाइन में मौजूद एट्रिब्यूट है.
• देखें कि एसडीपी के जवाब में, m=video लाइनों की संख्या बराबर हो.
• देखें कि एसडीपी के जवाब में, हर m=video पंक्ति के नीचे a=sendonly या a=sendrecv एट्रिब्यूट हों.
• देखें कि Meet के सर्वर पर VideoAssignmentRequest को सही तरीके से भेजा गया था और उसे सर्वर ने सही तरीके से पाया था. अनुरोध पूरा होने या न होने की जानकारी, क्लाइंट को उसी डेटा चैनल से दी जानी चाहिए.

उम्मीद से कम वीडियो स्ट्रीम होने की समस्या हल करना

• देखें कि एसडीपी ऑफ़र में m=video … लाइनों की सही संख्या है या नहीं.
• पक्का करें कि एसडीपी के जवाब में मौजूद सभी m=video ब्यौरे में, a=sendonly या a=sendrecv एट्रिब्यूट शामिल हो. जवाब में a=recvonly के तौर पर मार्क की गई हर लाइन, क्लाइंट को भेजी जाने वाली स्ट्रीम की संख्या को उतना ही कम कर देती है.

आपने ऑब्ज़र्वर को लागू किया है या नहीं, इसकी जांच करना

अगर डेटा प्रोसेसिंग को किसी दूसरी थ्रेड पर ले जाया जाता है, तो वीडियो डेटा की कॉपी बनाना न भूलें. VideoFrame.frame असल में, डेटा का रेफ़रंस होता है. इसलिए, OnVideoFrame के बाद इसे ऐक्सेस करने की कोशिश करने पर, सेगमेंटेशन फ़ॉल्ट जैसा कोई गड़बड़ी का मैसेज दिख सकता है.

मिलते-जुलते विषय

• Meet Media API के कॉन्सेप्ट