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

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

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

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

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

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

मीडिया के ब्यौरे के क्रम में गड़बड़ी

Session Description Protocol (SDP) ऑफ़र के साथ पीयर-टू-पीयर कनेक्शन बनाते समय, आपको यह गड़बड़ी दिख सकती है:

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].

यह गड़बड़ी तब होती है, जब एसडीपी ऑफ़र में मौजूद सभी मीडिया के ब्यौरों के लिए, 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 सिर्फ़ तब वीडियो उपलब्ध कराता है, जब एसडीपी ऑफ़र में इसकी जानकारी दी गई हो. ऑफ़र में ज़्यादा से ज़्यादा तीन, सिर्फ़ वीडियो मीडिया के ब्यौरे होने चाहिए.

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 को कोई मान्य ऑफ़र मिलता है, तो वह n send-only वीडियो मीडिया के ब्यौरे के साथ एसडीपी जवाब देता है. यहां n, एसडीपी ऑफ़र में वीडियो मीडिया के ब्यौरों की संख्या है.

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 के बाद इसे ऐक्सेस करने की कोशिश करने पर, अनडिफ़ाइंड व्यवहार होगा. जैसे, सेगमेंटेशन फ़ॉल्ट.

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

• Media API के कॉन्सेप्ट के बारे में जानकारी