Fehler bei der Meet Media API beheben

In diesem Leitfaden erfahren Sie, wie Sie häufige Fehler bei der Google Meet Media API beheben.

Fehlercodes beheben

Hier sind einige Tipps zur Fehlerbehebung bei Fehlercodes, die vom Endpunkt connectActiveConference zurückgegeben werden:

Fehlercodes
NO_ACTIVE_CONFERENCE Prüfen Sie, ob der Meet Media API-Client erst dann eine Verbindung herstellt, wenn sich der authentifizierte Nutzer bereits in einer Konferenz im Videokonferenzraum befindet.
INVALID_OFFER Lesen Sie die Angebotsanforderungen, um zu prüfen, ob alle erforderlichen Angaben vorhanden sind, z. B. die erforderlichen Kanäle für die Dateneröffnung. Sie können den Angebotsstring Ihrer App auch mit dem Beispielangebot vergleichen und mögliche Unterschiede untersuchen.
INCOMPATIBLE_DEVICE Mindestens ein Gerät in der Videokonferenz ist nicht mit Meet Media API-Clients kompatibel. Ihre App kann nicht teilnehmen. Sie sollten Ihre Endnutzer darüber informieren.
CONNECTIONS_EXHAUSTED Es kann jeweils nur ein Meet Media API-Client eine Verbindung zu einer Konferenz herstellen. Wenn Ihre App abstürzt, wird dieser Fehler möglicherweise angezeigt, wenn versucht wird, eine neue Verbindung herzustellen. Warten Sie in diesem Fall etwa 30 Sekunden, bis die vorherige Verbindung in Google Meet abgelaufen ist. Versuchen Sie es anschließend noch einmal.

Einheitlicher Plan

Wenn Datenkanäle nie geöffnet werden und du keine Audio- oder Videoinhalte erhältst, prüfe, ob bei der Konfiguration der lokalen Peer-Verbindung nur Unified Plan verwendet wird.

Fehler bei der Reihenfolge der Medienbeschreibungen

Beim Erstellen einer Peer-to-Peer-Verbindung mit einem Session Description Protocol-Angebot (SDP) kann der folgende Fehler auftreten:

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.

Das bedeutet, dass die Zeilen der Medienbeschreibung in der SDP-Antwort nicht mit den Medienbeschreibungen im SDP-Angebot übereinstimmen:

SDP-Angebot SDP-Antwort
m=audio 9 UDP/TLS/RTP/SAVPF 111 m=audio 9 UDP/TLS/RTP/SAVPF 111
❌ m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 ❌ m=audio 9 UDP/TLS/RTP/SAVPF 111
m=audio 9 UDP/TLS/RTP/SAVPF 111 m=audio 9 UDP/TLS/RTP/SAVPF 111
❌ m=audio 9 UDP/TLS/RTP/SAVPF 111 ❌ m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99

Um diesen Fehler zu beheben, müssen ähnliche Medientypen richtig konfiguriert und beim Festlegen des Peer-Verbindungsobjekts gruppiert werden. Interleaved-Medienbeschreibungen werden nicht unterstützt.

Das folgende Codebeispiel zeigt, wie die Medienbeschreibungen richtig abgeglichen werden:

C++

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);
  // . . .
}

JavaScript

pc = new RTCPeerConnection();

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

Fehler beim DTLS-Rollenattribut

Beim Festlegen des DTLS-Rollenattributs wird möglicherweise der Fehler angezeigt:

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

Dieser Fehler tritt auf, wenn das Attribut a=setup:< > nicht richtig für alle Medienbeschreibungen im SDP-Angebot festgelegt ist.

Um diesen Fehler zu beheben, muss jede Medienbeschreibung im SDP-Angebot eines der folgenden erforderlichen Attribute haben:

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

Probleme mit dem Ton beheben

In den folgenden Abschnitten erfahren Sie, wie Sie Audioprobleme in Ihrer App beheben können.

Log prüfen

Wenn Sie den Webclient in einem Chrome-Browser verwenden:

  1. Öffnen Sie einen neuen Tab und geben Sie in die Adressleiste Folgendes ein: chrome://webrtc-internals.
  2. Gehen Sie zum Abschnitt mit der Beschriftung Stats graph for inbound-rtp.
  3. Prüfen Sie in jeder Audiografik, ob Pakete empfangen werden.

Wenn Sie den C++-Referenzclient verwenden, prüfen Sie, ob OnAudioFrame aufgerufen wird.

OAuth-Bereiche prüfen

Audio wird nur übertragen, wenn in der ersten Verbindungsanfrage der richtige Umfang angegeben ist. Geben Sie die richtigen OAuth 2.0-Bereiche an, um den Fehler zu beheben. Weitere Informationen finden Sie unter Scopes der Meet Media API.

Prüfen, ob die Konferenz richtig eingerichtet ist

  • Wenn der Client eine Verbindung zu den Google Meet-Servern herstellt, wird er nicht automatisch zur Konferenz zugelassen. Prüfe, ob du über den Datenkanal für die Sitzungssteuerung eine Aktualisierung der Sitzungssteuerungsressource mit dem Status STATE_JOINED erhalten hast.

    {"sessionStatus":{"connectionState":"STATE_JOINED"}}
    
  • Prüfen Sie, ob andere Konferenzteilnehmer vorhanden sind, deren Audiostreams nicht stummgeschaltet sind.

Signal für Audio prüfen

Meet stellt nur Audio bereit, wenn du dies im SDP-Angebot signalisierst. Im Angebot müssen drei Audiomedienbeschreibungen zum Empfang vorhanden sein.

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

Wenn die Meet-Server ein gültiges Angebot erhalten, antworten sie mit einer SDP-Antwort mit drei Audiomedienbeschreibungen, die nur zum Senden bestimmt sind.

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

Implementierung des Beobachters überprüfen

Erstelle unbedingt Kopien der Audiodaten, wenn du die Datenverarbeitung in einen anderen Thread verschiebst. AudioFrame.pcm16 ist im Grunde eine Referenz auf die zugrunde liegenden Daten. Wenn Sie also nach OnAudioFrame auf sie zugreifen, führt dies zu einem undefinierten Verhalten, z. B. zu einem Segmentierungsfehler.

Probleme bei Videos beheben

In den folgenden Abschnitten erfahren Sie, wie Sie Videoprobleme in Ihrer App beheben können.

Log prüfen

Wenn Sie den Webclient in einem Chrome-Browser verwenden:

  1. Öffnen Sie einen neuen Tab und geben Sie in die Adressleiste Folgendes ein: chrome://webrtc-internals.
  2. Gehen Sie zum Abschnitt mit der Beschriftung Stats graph for inbound-rtp.
  3. Prüfen Sie in jeder Videografik, ob Pakete empfangen werden.

Wenn Sie den C++-Referenzclient verwenden, prüfen Sie, ob OnVideoFrame aufgerufen wird.

OAuth-Bereiche prüfen

Das Video wird nur übertragen, wenn bei der ersten Verbindungsanfrage der richtige Umfang angegeben wird. Geben Sie die richtigen OAuth 2.0-Bereiche an, um den Fehler zu beheben. Weitere Informationen finden Sie unter Scopes der Meet Media API.

Prüfen, ob die Konferenz richtig eingerichtet ist

  • Wenn der Client eine Verbindung zu den Meet-Servern herstellt, wird er nicht automatisch zur Konferenz zugelassen. Prüfe, ob du über den Datenkanal für die Sitzungssteuerung eine Aktualisierung der Sitzungssteuerungsressource mit dem Status STATE_JOINED erhalten hast.

    {"sessionStatus":{"connectionState":"STATE_JOINED"}}
    
  • Prüfen Sie, ob andere Konferenzteilnehmer vorhanden sind, deren Videostreams nicht stummgeschaltet sind.

Signal für Video prüfen

In Meet wird nur dann Video übertragen, wenn dies im SDP-Angebot signalisiert wird. Im Angebot müssen bis zu drei Videomedienbeschreibungen vorhanden sein, die nur zum Empfangen gedacht sind.

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

Wenn Meet ein gültiges Angebot empfängt, antwortet es mit einer SDP-Antwort mit n Videomedienbeschreibungen, die nur gesendet werden. n ist die Anzahl der Videomedienbeschreibungen im SDP-Angebot.

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

Fehlerbehebung bei fehlendem Video

  • Prüfen Sie, ob m=video … im SDP-Angebot vorhanden ist, das an die Meet-Server gesendet wurde.
  • Prüfen Sie, ob a=recvonly ein Attribut unter jeder m=video-Zeile ist.
  • Prüfen Sie, ob in der SDP-Antwort dieselbe Anzahl von m=video-Zeilen vorhanden ist.
  • Prüfe, ob a=sendonly oder a=sendrecv Attribute unter jeder m=video-Zeile in der SDP-Antwort sind.
  • Prüfen Sie, ob eine VideoAssignmentRequest an die Meet-Server gesendet und von diesen empfangen wurde. Erfolg oder Fehlschlag sollten über denselben Datenkanal an den Client zurückgesendet werden.

Problembehebung bei weniger Videostreams als erwartet

  • Prüfe, ob das SDP-Angebot die richtige Anzahl von m=video …-Zeilen enthält.
  • Achten Sie darauf, dass alle m=video-Beschreibungen in der SDP-Antwort entweder ein a=sendonly- oder ein a=sendrecv-Attribut enthalten. Bei Zeilen, die in der Antwort mit a=recvonly gekennzeichnet sind, wird die Anzahl der an den Client gesendeten Streams entsprechend reduziert.

Implementierung des Beobachters überprüfen

Erstellen Sie unbedingt Kopien der Videodaten, wenn Sie die Datenverarbeitung in einen anderen Thread verschieben. VideoFrame.frame ist im Grunde eine Referenz auf die zugrunde liegenden Daten. Wenn Sie also versuchen, nach OnVideoFrame darauf zuzugreifen, führt dies zu undefiniertem Verhalten, z. B. zu einem Segmentierungsfehler.