Устранение и исправление ошибок Meet Media API

В этом руководстве представлены инструкции по устранению распространенных ошибок Google Meet Media API.

Устранение кодов ошибок

Ниже приведены советы по устранению кодов ошибок, возвращаемых конечной точкой connectActiveConference :

Единый план

Если каналы передачи данных никогда не открываются и вы никогда не получаете аудио или видео, убедитесь, что при настройке локального однорангового соединения используется только единый план .

Ошибка порядка описания мультимедиа

При создании однорангового соединения с предложением протокола описания сеанса (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. Дополнительную информацию см. в разделе Области действия API Meet Media .

Убедитесь, что конференция настроена правильно.

• Когда клиент подключается к серверам 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
. . .

Проверьте реализацию вашего наблюдателя

Обязательно сделайте копии аудиоданных, если вы переносите обработку данных в другой поток. AudioFrame.pcm16 фактически является ссылкой на базовые данные, поэтому попытка доступа к нему после OnAudioFrame приводит к неопределенному поведению, например к ошибке сегментации.

Устранение неполадок с видео

Следующие разделы помогут решить проблемы с видео в вашем приложении.

Проверьте журналы

Если вы используете веб-клиент в браузере Chrome:

1. Откройте новую вкладку и введите в адресную строку: chrome://webrtc-internals .
2. Перейдите в раздел с надписью Stats graph for inbound-rtp .
3. Проверьте каждый видеографик, чтобы увидеть, принимаются ли пакеты.

Если вы используете эталонный клиент C++, проверьте, вызывается ли когда-либо OnVideoFrame .

Проверьте области действия OAuth

Видео передается только в том случае, если в первоначальном запросе на соединение указан соответствующий объем. Чтобы устранить эту ошибку, обязательно укажите правильные области действия OAuth 2.0. Дополнительную информацию см. в разделе Области действия API Meet Media .

Убедитесь, что конференция настроена правильно.

• Когда клиент подключается к серверам 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 .
• Убедитесь, что в ответе SDP присутствует равное количество строк m=video .
• Убедитесь, что a=sendonly или a=sendrecv являются атрибутами каждой строки m=video в ответе SDP.
• Убедитесь, что успешный VideoAssignmentRequest был отправлен и получен серверами Meet. Успех или неудача должны быть переданы обратно клиенту по тому же каналу данных.

Устранение неполадок с меньшим количеством видеопотоков, чем ожидалось

• Убедитесь, что предложение SDP содержит правильное количество строк m=video … .
• Убедитесь, что все описания m=video в ответе SDP содержат атрибут a=sendonly или a=sendrecv . Любые строки, отмеченные a=recvonly в ответе, значительно уменьшают количество потоков, отправляемых клиенту.

Проверьте реализацию вашего наблюдателя

Обязательно сделайте копии видеоданных, если переносите обработку данных в другой поток. VideoFrame.frame фактически является ссылкой на базовые данные, поэтому попытка доступа к нему после OnVideoFrame приведет к неопределенному поведению, например к ошибке сегментации.

Связанные темы

• Познакомьтесь с концепциями Media API

В этом руководстве представлены инструкции по устранению распространенных ошибок Google Meet Media API.

Устранение кодов ошибок

Ниже приведены советы по устранению кодов ошибок, возвращаемых конечной точкой connectActiveConference :

Единый план

Если каналы передачи данных никогда не открываются и вы никогда не получаете аудио или видео, убедитесь, что при настройке локального однорангового соединения используется только единый план .

Ошибка порядка описания мультимедиа

При создании однорангового соединения с предложением протокола описания сеанса (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. Дополнительную информацию см. в разделе Области действия API Meet Media .

Убедитесь, что конференция настроена правильно.

• Когда клиент подключается к серверам 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
. . .

Проверьте реализацию вашего наблюдателя

Обязательно сделайте копии аудиоданных, если вы переносите обработку данных в другой поток. AudioFrame.pcm16 фактически является ссылкой на базовые данные, поэтому попытка доступа к нему после OnAudioFrame приводит к неопределенному поведению, например к ошибке сегментации.

Устранение неполадок с видео

Следующие разделы помогут решить проблемы с видео в вашем приложении.

Проверьте журналы

Если вы используете веб-клиент в браузере Chrome:

1. Откройте новую вкладку и введите в адресную строку: chrome://webrtc-internals .
2. Перейдите в раздел « Stats graph for inbound-rtp .
3. Проверьте каждый видеографик, чтобы увидеть, принимаются ли пакеты.

Если вы используете эталонный клиент C++, проверьте, вызывается ли когда-либо OnVideoFrame .

Проверьте области действия OAuth

Видео передается только в том случае, если в первоначальном запросе на соединение указан соответствующий объем. Чтобы устранить эту ошибку, обязательно укажите правильные области действия OAuth 2.0. Дополнительную информацию см. в разделе Области действия API Meet Media .

Убедитесь, что конференция настроена правильно.

• Когда клиент подключается к серверам 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 .
• Убедитесь, что в ответе SDP присутствует равное количество строк m=video .
• Убедитесь, что a=sendonly или a=sendrecv являются атрибутами каждой строки m=video в ответе SDP.
• Убедитесь, что успешный VideoAssignmentRequest был отправлен и получен серверами Meet. Успех или неудача должны быть переданы обратно клиенту по тому же каналу данных.

Устранение неполадок с меньшим количеством видеопотоков, чем ожидалось

• Убедитесь, что предложение SDP содержит правильное количество строк m=video … .
• Убедитесь, что все описания m=video в ответе SDP содержат атрибут a=sendonly или a=sendrecv . Любые строки, отмеченные a=recvonly в ответе, значительно уменьшают количество потоков, отправляемых клиенту.

Проверьте реализацию вашего наблюдателя

Обязательно сделайте копии видеоданных, если переносите обработку данных в другой поток. VideoFrame.frame фактически является ссылкой на базовые данные, поэтому попытка доступа к нему после OnVideoFrame приведет к неопределенному поведению, например к ошибке сегментации.

Связанные темы

• Познакомьтесь с концепциями Media API