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 zastosowania, np. aplikacje, które dokumentują elementy działania, oferują statystyki w czasie rzeczywistym dotyczące bieżącego spotkania lub przesyłają strumieniowo dźwięk i obraz na nowe urządzenie.

Przypadki użycia

Aplikacje zarejestrowane w konsoli Google Cloud mogą korzystać z interfejsu Meet Media API, aby łączyć się z konferencjami w Meet. Dzięki temu mogą:

  • oglądać strumienie wideo,
  • odtwarzać strumienie audio;
  • korzystać z metadanych uczestnika,

Cykl życia interfejsu Meet Media API

Poniższe obrazy przedstawiają 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 spotkania na stronie innej firmy. Połączenie jest odrzucane, gdy występują konta osób niepełnoletnich.
  • szyfrowane spotkania i spotkania ze znakiem wodnym.
    Rysunek 2. Spotkania mogą być oznaczane jako zaszyfrowane i zawierać znak wodny. Nie można połączyć interfejsu Meet Media API, gdy spotkanie jest szyfrowane lub zawiera 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ń podczas połączenia.
    Rysunek 5. zmiana ustawień podczas połączenia; Jeśli gospodarz zdecyduje się wyłączyć ustawienie interfejsu Meet Media API podczas połączenia, połączenie zostanie przerwane.
  • Podczas spotkań z konsumentami osoba inicjująca musi być obecna.
    Rysunek 6. Jeśli właściciel spotkania ma konto indywidualne (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 uczestnicy z tej samej organizacji co gospodarz zobaczą okno inicjowania.
  • Każda osoba może zatrzymać interfejs Meet Media API podczas połączenia.
    Rysunek 8. Każda osoba może zatrzymać interfejs Meet Media API podczas połączenia.

Wymagania dotyczące osoby udzielającej zgody

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

W przypadku spotkań w Google Workspace

Aby wyrazić zgodę na nagrywanie spotkania w Google Workspace, musisz należeć do organizacji, która jest właścicielem spotkania. W większości przypadków właścicielem spotkania jest 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.

Spotkania z klientami

W przypadku spotkań organizowanych przez użytkowników kont Gmail osoba rozpoczynająca spotkanie musi być na nim obecna, aby wyrazić zgodę.

Często spotykane terminy

Numer projektu w chmurze
Niezmienny wygenerowany int64 identyfikator projektu Google Cloud. Te wartości są generowane przez konsolę Google Cloud dla każdej zarejestrowanej aplikacji.
Konferencja
Instancja połączenia wygenerowana przez serwer w przestrzeni spotkania. Użytkownicy zwykle uważają ten scenariusz za jedno spotkanie.
Kanał danych o zasobach konferencji

W przeciwieństwie do interfejsu Google Meet REST API, w którym żądania zasobów są wysyłane przez HTTP, klienci interfejsu Meet Media API wysyłają żądania zasobów z 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 tym samym kanałem.

Źródło danych (CSRC)

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

Meet przypisuje każdemu uczestnikowi konferencji unikalną wartość CSRC, gdy dołącza on do spotkania. Ta wartość pozostaje stała, dopóki użytkownik nie opuści strony.

Kanały danych

Kanały danych WebRTC umożliwiają wymianę dowolnych danych (tekstów, 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ół do nawiązywania połączeń, wyszukiwania wszystkich możliwych tras, którymi dwa komputery mogą się ze sobą komunikować w sieci peer-to-peer (P2P), a następnie zapewnia 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 jednej ś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ć audio lub wideo, ale nie oba naraz. Dwukierunkowe połączenie Secure Real-time Transport Protocol (SRTP) zwykle składa się z 2 ścieżek strumienia multimediów: wychodzącej od lokalnego do zdalnego urządzenia równorzędnego i przychodzącej od zdalnego do lokalnego urządzenia równorzędnego.

Miejsce spotkań

Wirtualne miejsce lub trwały obiekt (np. sala konferencyjna), w którym odbywa się konferencja. W danym momencie w jednej przestrzeni może się odbywać tylko 1 aktywna rozmowa wideo. Przestrzeń do spotkań pomaga też użytkownikom spotykać się i znajdować wspólne zasoby.

Uczestnik

Osoba dołączyła do konferencji lub korzysta z trybu towarzyszącego, ogląda spotkanie jako widz lub korzysta z urządzenia w sali konferencyjnej połączonego 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 konferencji może przekraczać tę liczbę. W takich sytuacjach serwery Meet przesyłają strumienie audio i wideo uczestników uznanych za „najbardziej istotnych”. Trafność jest określana na podstawie różnych cech, takich jak udostępnianie ekranu i to, jak niedawno uczestnik zabrał głos.

Jednostka selektywnego przekazywania (SFU)

Jednostka selektywnego przekazywania (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 klienta i zapotrzebowanie na przepustowość, umożliwiając skalowanie konferencji.

Session Description Protocol (SDP)

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

Odpowiedź SDP

Odpowiedź na ofertę SDP. Odpowiedź odrzuca lub akceptuje wszystkie strumienie otrzymane od zdalnego klienta. Negocjuje też strumienie, które planuje przesłać z powrotem do urządzenia oferującego. Warto pamiętać, że odpowiedź SDP nie może dodawać strumieni sygnalizowanych z początkowej oferty. Nieoficjalnie: jeśli oferujący peer sygnalizuje, że akceptuje maksymalnie 3 strumienie audio od zdalnego peera, ten zdalny peer nie może sygnalizować 4 strumieni audio do transmisji.

Oferta SDP

Początkowy SDP w procesie negocjacji peer-to-peer typu oferta-odpowiedź. Oferta jest tworzona przez inicjującego użytkownika i określa warunki sesji peer-to-peer. Oferta jest zawsze tworzona przez klienta API Meet Media i przesyłana na serwery Meet.

Na przykład oferta może wskazywać liczbę strumieni audio lub wideo, które oferujący wysyła (lub może odbierać), oraz czy należy otworzyć kanały danych.

Źródło synchronizacji (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 opisem w RFC 8829, transceiver to abstrakcja strumieni RTP w sesji peer-to-peer.

Pojedynczy nadajnik-odbiornik jest mapowany na pojedynczy opis multimediów w SDP i przez niego opisywany. Nadajnik-odbiornik składa się z RtpSender i RtpReceiver.

RTP jest dwukierunkowy, więc każdy węzeł ma własną instancję nadajnika-odbiornika dla tego samego połączenia RTP. RtpSender danego nadajnika-odbiornika dla lokalnego urządzenia jest mapowany na RtpReceiver konkretnego nadajnika-odbiornika na urządzeniu zdalnym. Działa to też w drugą stronę. RtpSender tego samego transceivera zdalnego węzła jest mapowany na RtpReceiver lokalnego węzła.

Każdy opis multimediów ma własny dedykowany nadajnik-odbiornik. Dlatego sesja peer-to-peer z wieloma strumieniami RTP ma wiele nadajników-odbiorników z wieloma RtpSenders i RtpReceiver dla każdego uczestnika.

Virtual Media Streams

Wirtualne strumienie multimediów to zagregowane strumienie multimediów generowane przez jednostkę selektywnego przekazywania (SFU) podczas konferencji WebRTC. Zamiast wysyłać strumienie do wszystkich uczestników, SFU multipleksuje wybrane strumienie uczestników do mniejszej liczby wychodzących strumieni wirtualnych. Upraszcza to topologię połączeń i zmniejsza obciążenie uczestników, umożliwiając skalowanie konferencji. Każda wirtualna transmisja może zawierać multimedia od wielu uczestników, którymi dynamicznie zarządza SFU.