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:

Plan 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 le plan unifié est utilisé lors de la configuration de la connexion peer locale.

Erreur d'ordre dans la description des contenus multimédias

Lorsque vous créez une connexion peer-to-peer avec une offre Session Description Protocol (SDP), le message d'erreur suivant 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 des médias dans la réponse SDP ne correspondent pas aux descriptions des médias dans l'offre SDP:

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

L'exemple de code suivant montre comment faire correspondre correctement les descriptions 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 multimédias de l'offre SDP.

Pour résoudre cette erreur, assurez-vous que chaque description multimédia de 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 champs d'application OAuth

L'audio n'est transmis que si la portée appropriée est fournie avec la requête de connexion initiale. Pour résoudre l'erreur, veillez à fournir les portées OAuth 2.0 appropriées. Pour en savoir plus, consultez la section Champs d'application 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 conférence. Assurez-vous d'avoir reçu une mise à jour de la ressource de contrôle de session via le canal de données de contrôle de session avec un état de STATE_JOINED.

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

• Vérifiez que d'autres participants à la conférence ont des flux audio non coupés.

Vérifier votre signal audio

Meet ne fournit de l'audio que si vous le signalez dans l'offre SDP. L'offre doit comporter trois descriptions de médias audio en réception seule.

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 par une réponse SDP avec trois descriptions multimédias audio à envoyer 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 à créer des copies des données audio si vous déplacez le traitement des données vers un autre thread. AudioFrame.pcm16 est en fait une référence aux données sous-jacentes. Par conséquent, 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 liés aux vidéos 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 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 champs d'application OAuth

La vidéo n'est transmise que si le champ d'application approprié est fourni avec la requête de connexion initiale. Pour résoudre l'erreur, veillez à fournir les portées OAuth 2.0 appropriées. Pour en savoir plus, consultez la section Champs d'application 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 conférence. Assurez-vous d'avoir reçu une mise à jour de la ressource de contrôle de session via le canal de données de contrôle de session avec un état de STATE_JOINED.

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

• Vérifiez que d'autres participants à la conférence ont leurs flux vidéo activés.

Valider votre signal pour la vidéo

Meet ne fournit de la vidéo que si elle est signalée dans l'offre SDP. L'offre doit comporter jusqu'à trois descriptions de médias 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 avec n descriptions multimédias vidéo d'envoi uniquement, où n est le nombre de descriptions multimédias 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 de vidéo manquante

• 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'un nombre égal de lignes m=video existe 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é et reçu par les serveurs Meet. La réussite ou l'échec doivent être communiqués au client via le même canal de données.

Résoudre les problèmes de diffusion de moins de flux vidéo que prévu

• 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 à créer 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. Toute tentative d'accès après OnVideoFrame entraînera un comportement indéfini, tel qu'une erreur de segmentation.

Articles associés

• Concepts de l'API Meet Media