Omówienie interfejsu Meet Media API

Interfejs Google Meet Media API umożliwia dostęp do multimediów w czasie rzeczywistym z konferencji w Google Meet. Umożliwia to różne przypadki użycia, np. aplikacje, które dokumentują działania, oferują informacje w czasie rzeczywistym o bieżącym spotkaniu lub przesyłają strumieniowo dźwięk i obraz do nowego urządzenia.

Przypadki użycia

Aplikacje zarejestrowane w konsoli Google Cloud mogą używać interfejsu Meet Media API do łączenia się z konferencjami w Meet, co umożliwia im:

  • korzystanie ze strumieni wideo;
  • korzystanie ze strumieni audio;
  • korzystanie z metadanych uczestników.

Cykl życia interfejsu Meet Media API

Na tych ilustracjach przedstawiono cykl życia interfejsu Meet Media API:

  • Bot interfejsu Meet Media API próbuje dołączyć do spotkania w witrynie innej firmy.
    Rysunek 1. Bot interfejsu Meet Media API próbuje dołączyć do witryny innej firmy. Połączenie jest odrzucane, gdy są obecne konta osób niepełnoletnich.
  • zaszyfrowane spotkania i spotkania ze znakiem wodnym.
    Rysunek 2. Spotkania można oznaczyć jako zaszyfrowane i dodać do nich znak wodny. Nie można połączyć się z interfejsem Meet Media API, gdy spotkanie jest zaszyfrowane lub ma znak wodny.
  • Sprawdź, czy ustawienie administratora jest prawidłowe.
    Rysunek 3. Sprawdź, czy ustawienie administratora jest prawidłowe.
  • Skonfiguruj spotkanie w Kalendarzu.
    Rysunek 4. Skonfiguruj spotkanie w Kalendarzu. Gospodarz musi przyznać uprawnienia aplikacji innej firmy w ustawieniach Kalendarza. W przeciwnym razie połączenie zostanie odrzucone.
  • Zmiana ustawień w trakcie połączenia.
    Rysunek 5. Zmiana ustawienia podczas rozmowy. Jeśli gospodarz zdecyduje się wyłączyć ustawienie interfejsu Meet Media API podczas rozmowy, połączenie zostanie przerwane.
  • Podczas spotkań z klientami osoba inicjująca musi być obecna.
    Rysunek 6. Jeśli właściciel spotkania ma konto konsumenckie (konto z końcówką @gmail.com), inicjator musi być obecny na spotkaniu, aby wyrazić zgodę. W przeciwnym razie połączenie zostanie odrzucone.
  • Połączenie zostało nawiązane.
    Rysunek 7. Po nawiązaniu połączenia gospodarz, współgospodarz lub dowolny uczestnik z tej samej organizacji co gospodarz zobaczy okno inicjowania.
  • Każda osoba może zatrzymać interfejs Meet Media API podczas połączenia.
    Rysunek 8. Każdy może zatrzymać interfejs Meet Media API podczas rozmowy.

Wymagania dotyczące osoby wyrażającej zgodę

Aplikacje interfejsu Meet Media API mogą dołączyć do spotkania tylko wtedy, gdy w rozmowie jest osoba, która może wyrazić zgodę w imieniu spotkania.

W przypadku spotkań w Google Workspace

Aby wyrazić zgodę na spotkaniach w Google Workspace, musisz należeć do organizacji, która jest właścicielem spotkania. W większości przypadków właściciel spotkania jest taki sam jak organizator. Jeśli gospodarz lub inicjator jest na spotkaniu i należy do organizacji, która jest właścicielem spotkania, wyświetli się okno rozpoczęcia preferencyjnie.

W przypadku spotkań konsumenckich

W przypadku spotkań organizowanych przez konta Gmail inicjator musi być obecny na spotkaniu, aby wyrazić zgodę.

Często spotykane terminy

Numer projektu w chmurze
Niezmienny, wygenerowany identyfikator int64 projektu Google Cloud. Te wartości są generowane przez konsolę Google Cloud dla każdej zarejestrowanej aplikacji.
Konferencja
Wygenerowana przez serwer instancja połączenia w miejscu spotkań. Użytkownicy zwykle uważają ten scenariusz za jedno spotkanie.
Kanał danych zasobów konferencji

Zamiast wysyłać żądania zasobów przez HTTP, jak w przypadku interfejsu Google Meet REST API, klienci interfejsu Meet Media API wysyłają żądania zasobów do serwera przez kanały danych.

Dla każdego typu zasobu można otworzyć osobny kanał danych. Po otwarciu klient może wysyłać żądania przez kanał. Aktualizacje zasobów będą przesyłane przez ten sam kanał.

Źródło współtworzenia (CSRC)

W przypadku wirtualnych strumieni multimediów nie można zakładać, że strumień multimediów zawsze wskazuje tego samego uczestnika. Wartość CSRC w nagłówku każdego pakietu RTP identyfikuje prawdziwe źródło pakietu.

Gdy uczestnik dołącza do konferencji , Meet przypisuje mu unikalną wartość CSRC. Ta wartość pozostaje stała do momentu opuszczenia spotkania.

Kanały danych

Kanały danych WebRTC umożliwiają wymianę dowolnych danych (tekstu, plików itp.) niezależnie od strumieni audio i wideo. Kanały danych korzystają z tego samego połączenia co strumienie multimediów, co zapewnia skuteczny sposób dodawania wymiany danych do aplikacji WebRTC.

Interactive Connectivity Establishment (ICE)

Protokół służący do nawiązywania połączenia, znajdowania wszystkich możliwych tras, którymi 2 komputery mogą się ze sobą komunikować za pomocą sieci peer-to-peer (P2P), a następnie zapewniający utrzymanie połączenia.

Strumień multimediów

Strumień multimediów WebRTC reprezentuje przepływ danych multimedialnych, zwykle audio lub wideo, przechwytywanych z urządzenia, takiego jak kamera lub mikrofon. Składa się z co najmniej 1 ścieżki strumienia multimediów, z których każda reprezentuje pojedyncze źródło multimediów, np. ścieżkę wideo lub ścieżkę audio.

Ścieżka strumienia multimediów

Składa się z pojedynczego, jednokierunkowego przepływu pakietów RTP. Ścieżka strumienia multimediów może być ścieżką audio lub wideo, ale nie może być jednocześnie ścieżką audio i wideo. Dwukierunkowe połączenie Secure Real-time Transport Protocol (SRTP) zwykle składa się z 2 ścieżek strumienia multimediów: wyjścia z lokalnego do zdalnego elementu równorzędnego i wejścia ze zdalnego do lokalnego elementu równorzędnego.

Miejsce spotkań

Wirtualne miejsce lub trwały obiekt (np. sala konferencyjna), w którym odbywa się a konferencja. W danym miejscu może się odbywać tylko 1 aktywna konferencja. Miejsce spotkań pomaga też użytkownikom spotykać się i znajdować udostępnione zasoby.

Uczestnik

Osoba, która dołączyła do konferencji lub korzysta z trybu towarzyszącego, ogląda jako widz lub urządzenie w sali połączone z rozmową. Gdy uczestnik dołącza do konferencji, przypisywany jest mu unikalny identyfikator.

Odpowiednie strumienie

Istnieje limit liczby wirtualnych strumieni audio i wirtualnych strumieni wideo , które klient może otworzyć.

Liczba uczestników w konferencji może przekroczyć ten limit. W takich sytuacjach serwery Meet przesyłają strumienie audio i wideo uczestników uznanych za „najbardziej odpowiednich”. Odpowiedniość jest określana na podstawie różnych cech, takich jak udostępnianie ekranu i to, jak niedawno uczestnik mówił.

Selective Forwarding Unit (SFU)

Selective Forwarding Unit (SFU) to komponent po stronie serwera w konferencjach WebRTC, który zarządza dystrybucją strumieni multimediów. Uczestnicy łączą się tylko z SFU, który selektywnie przekazuje odpowiednie strumienie do innych uczestników. Zmniejsza to obciążenie przetwarzania po stronie klienta i zapotrzebowanie na przepustowość, co umożliwia skalowanie konferencji.

Session Description Protocol (SDP)

Mechanizm sygnalizacji używany przez WebRTC do negocjowania połączenia P2P. RFC 8866 reguluje to.

Odpowiedź SDP

Odpowiedź na ofertę SDP. Odpowiedź odrzuca lub akceptuje wszystkie otrzymane strumienie ze zdalnego elementu równorzędnego. Negocjuje też, które strumienie planuje przesłać z powrotem do elementu równorzędnego. Pamiętaj, że odpowiedź SDP nie może dodawać sygnalizowanych strumieni z początkowej oferty. Jeśli element równorzędny sygnalizuje, że akceptuje maksymalnie 3 strumienie audio ze zdalnego elementu równorzędnego, ten zdalny element równorzędny nie może sygnalizować 4 strumieni audio do transmisji.

Oferta SDP

Początkowy SDP w procesie negocjacji peer-to-peer. Oferta jest tworzona przez inicjujący element równorzędny i określa warunki sesji peer-to-peer. Oferta jest zawsze tworzona przez klienta interfejsu Meet Media API i przesyłana do serwerów Meet.

Oferta może na przykład wskazywać liczbę strumieni audio lub wideo, które oferujący wysyła (lub może odbierać), oraz czy mają zostać otwarte kanały danych.

Synchronization Source (SSRC)

SSRC to 32-bitowy identyfikator, który jednoznacznie identyfikuje pojedyncze źródło strumienia multimediów w sesji RTP (Real-time Transport Protocol). W WebRTC identyfikatory SSRC służą do rozróżniania różnych strumieni multimediów pochodzących od różnych uczestników lub nawet różnych ścieżek od tego samego uczestnika (np. z różnych kamer).

RtpTransceiver

Zgodnie z RFC 8829 transceiver to abstrakcja strumieni RTP w sesji peer-to-peer.

Pojedynczy transceiver jest mapowany na pojedynczy opis multimediów w SDP i opisany przez niego. Transceiver składa się z RtpSender i RtpReceiver.

Ponieważ RTP jest dwukierunkowy, każdy element równorzędny ma własną instancję transceivera dla tego samego połączenia RTP. RtpSender danego transceivera dla lokalnego elementu równorzędnego jest mapowany na RtpReceiver konkretnego transceivera w zdalnym elemencie równorzędnym. Działa to też w drugą stronę. RtpSender tego samego transceivera zdalnego elementu równorzędnego jest mapowany na RtpReceiver lokalnego elementu równorzędnego.

Każdy opis multimediów ma własny transceiver. Dlatego sesja peer-to-peer z wieloma strumieniami RTP ma wiele transceiverów z wieloma RtpSenders i RtpReceiver dla każdego elementu równorzędnego.

Wirtualne strumienie multimediów

Wirtualne strumienie multimediów to zagregowane strumienie multimediów generowane przez Selective Forwarding Unit (SFU) w konferencjach WebRTC. Zamiast wysyłać poszczególne strumienie do wszystkich innych uczestników, SFU multipleksuje wybrane strumienie uczestników na mniejszą liczbę wychodzących strumieni wirtualnych. Upraszcza to topologię połączenia i zmniejsza obciążenie uczestników, co umożliwia skalowanie konferencji. Każdy strumień wirtualny może zawierać multimedia od wielu uczestników, którymi dynamicznie zarządza SFU.