Dépanner et corriger les erreurs de l'API Meet Media

Ce guide explique comment résoudre les erreurs courantes de l'API Google Meet Media.

Résoudre les problèmes liés aux codes d'erreur

Voici quelques conseils pour résoudre les problèmes liés aux codes d'erreur renvoyés par le point de terminaison connectActiveConference :

Forfait unifié

Si les canaux de données ne s'ouvrent jamais et que vous ne recevez jamais d'audio ni de vidéo, vérifiez que seul Unified Plan est utilisé lors de la configuration de la connexion appairée locale.

Erreur d'ordre de description des contenus multimédias

Lorsque vous créez une connexion peer-to-peer avec une offre Session Description Protocol (SDP), l'erreur suivante peut s'afficher :

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.

Cela signifie que les lignes de description du contenu multimédia dans la réponse SDP ne correspondent pas aux descriptions du contenu multimédia dans l'offre SDP :

Pour corriger cette erreur, assurez-vous que les types de contenus multimédias similaires sont correctement configurés et regroupés lors de la définition de l'objet de connexion pair à pair. Les descriptions de contenu multimédia entrelacées ne sont pas acceptées.

L'exemple de code suivant montre comment faire correspondre correctement les descriptions des contenus multimédias :

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'});

Erreur d'attribut de rôle DTLS

Lorsque vous définissez l'attribut de rôle DTLS, l'erreur suivante peut s'afficher :

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

Cette erreur se produit lorsque l'attribut a=setup:< > n'est pas correctement défini pour toutes les descriptions de contenu multimédia dans l'offre SDP.

Pour résoudre cette erreur, assurez-vous que chaque description de contenu multimédia dans l'offre SDP comporte l'un des attributs obligatoires suivants :

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

Résoudre les problèmes audio

Les sections suivantes peuvent vous aider à résoudre les problèmes audio dans votre application.

Vérifier les journaux

Si vous utilisez le client Web dans un navigateur Chrome :

1. Ouvrez un nouvel onglet et saisissez chrome://webrtc-internals dans la barre d'adresse.
2. Accédez à la section Stats graph for inbound-rtp.
3. Inspectez chaque graphique audio pour voir si des paquets sont reçus.

Si vous utilisez le client de référence C++, vérifiez si OnAudioFrame est appelé.

Vérifier les niveaux d'accès OAuth

L'audio n'est transmis que si le bon champ d'application est fourni avec la demande de connexion initiale. Pour résoudre l'erreur, assurez-vous de fournir les bons niveaux d'accès OAuth 2.0. Pour en savoir plus, consultez Scopes de l'API Meet Media.

Vérifier que la conférence est correctement configurée

• Lorsque le client se connecte aux serveurs Google Meet, il n'est pas automatiquement admis à la visioconférence. Assurez-vous d'avoir reçu une mise à jour de la ressource de contrôle de session sur le canal de données de contrôle de session avec un état STATE_JOINED.

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

• Vérifiez qu'il y a d'autres participants à la conférence dont les flux audio ne sont pas coupés.

Vérifier le signal audio

Meet ne fournit l'audio que si vous l'indiquez dans l'offre SDP. L'offre doit contenir trois descriptions de support audio en mode réception uniquement.

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

Si les serveurs Meet reçoivent une offre valide, ils répondent avec une réponse SDP comportant trois descriptions de contenu audio en mode envoi uniquement.

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

Vérifier l'implémentation de votre observateur

Veillez à faire des copies des données audio si vous déplacez le traitement des données vers un autre thread. AudioFrame.pcm16 étant une référence aux données sous-jacentes, toute tentative d'accès après OnAudioFrame entraîne un comportement indéfini, tel qu'une erreur de segmentation.

Résoudre les problèmes liés aux vidéos

Les sections suivantes peuvent vous aider à résoudre les problèmes vidéo dans votre application.

Vérifier les journaux

Si vous utilisez le client Web dans un navigateur Chrome :

1. Ouvrez un nouvel onglet et saisissez chrome://webrtc-internals dans la barre d'adresse.
2. Accédez à la section Stats graph for inbound-rtp.
3. Inspectez le graphique de chaque vidéo pour voir si des paquets sont reçus.

Si vous utilisez le client de référence C++, vérifiez si OnVideoFrame est appelé.

Vérifier les niveaux d'accès OAuth

La vidéo n'est transmise que si le bon champ d'application est fourni avec la demande de connexion initiale. Pour résoudre l'erreur, assurez-vous de fournir les bons niveaux d'accès OAuth 2.0. Pour en savoir plus, consultez Scopes de l'API Meet Media.

Vérifier que la conférence est correctement configurée

• Lorsque le client se connecte aux serveurs Meet, il n'est pas automatiquement admis à la visioconférence. Assurez-vous d'avoir reçu une mise à jour de la ressource de contrôle de session sur le canal de données de contrôle de session avec un état STATE_JOINED.

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

• Vérifiez que d'autres participants à la visioconférence n'ont pas coupé le son de leur flux vidéo.

Valider votre signal pour la vidéo

Meet ne fournit la vidéo que si elle est signalée dans l'offre SDP. L'offre doit contenir jusqu'à trois descriptions de contenu vidéo en mode réception uniquement.

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

Si Meet reçoit une offre valide, il répond avec une réponse SDP contenant des descriptions de contenu vidéo n en mode "envoi uniquement", où n correspond au nombre de descriptions de contenu vidéo dans l'offre 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
. . .

Résoudre les problèmes d'absence de vidéo

• Vérifiez que m=video … existe dans l'offre SDP envoyée aux serveurs Meet.
• Vérifiez que a=recvonly est un attribut sous chaque ligne m=video.
• Vérifiez qu'il existe un nombre égal de lignes m=video dans la réponse SDP.
• Vérifiez que a=sendonly ou a=sendrecv sont des attributs sous chaque ligne m=video dans la réponse SDP.
• Vérifiez qu'un VideoAssignmentRequest a bien été envoyé aux serveurs Meet et reçu par eux. La réussite ou l'échec doivent être communiqués au client sur le même canal de données.

Résoudre les problèmes liés à un nombre de flux vidéo inférieur à celui attendu

• Vérifiez que l'offre SDP contient le bon nombre de lignes m=video ….
• Assurez-vous que toutes les descriptions m=video de la réponse SDP contiennent un attribut a=sendonly ou a=sendrecv. Toute ligne marquée a=recvonly dans la réponse réduit d'autant le nombre de flux envoyés au client.

Vérifier l'implémentation de votre observateur

Veillez à faire des copies des données vidéo si vous déplacez le traitement des données vers un autre thread. VideoFrame.frame est en fait une référence aux données sous-jacentes. Par conséquent, toute tentative d'accès après OnVideoFrame entraînera un comportement indéfini, tel qu'une erreur de segmentation.

Articles associés

• Découvrir les concepts de l'API Meet