פתרון בעיות הקשורות לשגיאות ב-Meet Media API ותיקון שלהן

במדריך הזה מוסבר איך לפתור שגיאות נפוצות ב-Google Meet Media API.

פתרון בעיות בקודי שגיאה

ריכזנו כאן טיפים לפתרון בעיות שקשורות לקודי שגיאה שמוחזרים מנקודת הקצה connectActiveConference:

תוכנית מאוחדת

אם ערוצי הנתונים אף פעם לא נפתחים ואף פעם לא מתקבל אודיו או וידאו, צריך לוודא שמשתמשים רק ב-Unified Plan כשמגדירים את חיבור ה-peer המקומי.

שגיאה בסדר של תיאור המדיה

כשיוצרים חיבור ישיר (P2P) עם הצעת 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.

המשמעות היא ששורות תיאור המדיה בתשובת ה-SDP לא תואמות לתיאורי המדיה בהצעת ה-SDP:

כדי לתקן את השגיאה הזו, צריך לוודא שסוגי מדיה דומים מוגדרים בצורה נכונה ומקובצים יחד כשמגדירים את אובייקט חיבור העמיתים. אין תמיכה בתיאורי מדיה שמשולבים בתוכן.

בדוגמת הקוד הבאה אפשר לראות איך להתאים את תיאורי המדיה בצורה נכונה:

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

כשמגדירים את מאפיין התפקיד DTLS, יכול להיות שתופיע השגיאה:

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

השגיאה הזו מתרחשת כשמאפיין a=setup:< > לא מוגדר בצורה תקינה לכל תיאורי המדיה בהצעת ה-SDP.

כדי לפתור את השגיאה הזו, צריך לוודא שלכל תיאור מדיה בהצעת ה-SDP יש אחד מהמאפיינים הנדרשים הבאים:

• 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 אפשר לקבל אודיו בלבד אם מציינים זאת בהצעת ה-SDP. במבצע צריכים להיות שלושה תיאורי מדיה של אודיו בלבד, שניתן רק לקבל אותם.

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 מקבלים הצעה תקפה, הם מגיבים עם תשובת SDP עם שלושה תיאורי מדיה של אודיו, שמוגדרים לשליחה בלבד.

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

בדיקת ההטמעה של רכיב ה-Observer

אם מעבירים את עיבוד הנתונים לשרשור אחר, חשוב ליצור עותקים של נתוני האודיו. ‫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
. . .

פתרון בעיות כשאין וידאו

• בודקים ש-m=video … קיים בהצעת ה-SDP שנשלחה לשרתי Meet.
• בודקים ש-a=recvonly הוא מאפיין בכל שורה של m=video.
• בודקים שיש מספר שווה של שורות m=video בתשובת ה-SDP.
• בודקים שהמאפיינים a=sendonly או a=sendrecv מופיעים מתחת לכל שורה m=video בתשובה של SDP.
• בודקים ש-VideoAssignmentRequest נשלח לשרתי Meet ושהתקבל בהם. הצלחה או כישלון צריכים להיות מועברים חזרה ללקוח באותו ערוץ נתונים.

פתרון בעיות שקשורות למספר נמוך מהצפוי של סטרימינג של וידאו

• בודקים שהצעת ה-SDP מכילה את המספר הנכון של שורות m=video ….
• מוודאים שכל התיאורים של m=video בתשובת ה-SDP מכילים את המאפיין a=sendonly או a=sendrecv. כל שורה שמסומנת ב-a=recvonly בתשובה מפחיתה את מספר הזרמים שנשלחים ללקוח באותו מספר.

בדיקת ההטמעה של רכיב ה-Observer

אם מעבירים את עיבוד הנתונים לשרשור אחר, חשוב ליצור עותקים של נתוני הסרטון. ‫VideoFrame.frame הוא למעשה הפניה לנתונים הבסיסיים, ולכן ניסיון לגשת אליו אחרי OnVideoFrame יוביל להתנהגות לא מוגדרת, כמו שגיאת פילוח.

נושאים קשורים

• הסברים על מושגים ב-Meet Media API