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 do wykonania, 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ą używać interfejsu Meet Media API do łączenia się z konferencjami w Meet, co umożliwia im:

  • oglądać strumienie wideo,
  • odtwarzać strumienie audio;
  • korzystać z metadanych uczestników,

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 internetowej innej firmy. Połączenie jest odrzucane, gdy występują konta osób niepełnoletnich.
  • zaszyfrowane spotkania i spotkania ze znakiem wodnym.
    Rysunek 2. Spotkania mogą być oznaczone jako zaszyfrowane i zawierać znak wodny. Nie można połączyć interfejsu Meet Media API, gdy spotkanie jest szyfrowane 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 ustawień w trakcie połączenia; Jeśli gospodarz zdecyduje się wyłączyć ustawienie Meet Media API podczas połączenia, połączenie zostanie przerwane.
  • Podczas spotkań z klientami 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 korzystające z interfejsu 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 spotkań 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 mu się okno rozpoczęcia.

W przypadku spotkań z klientami

W przypadku spotkań organizowanych przy użyciu kont Gmail inicjator musi uczestniczyć w spotkaniu, 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 traktują ten scenariusz jako 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.

Contributing Source (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.

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 (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, 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 jednej lub kilku ścieżek strumienia multimediów, z których każda reprezentuje jedno ź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 może być jednocześnie audio i wideo. 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 spotkań), w którym odbywa się konferencja. W danej przestrzeni może się odbywać tylko 1 aktywna rozmowa wideo naraz. Przestrzeń do spotkań pomaga też użytkownikom spotykać się i znajdować wspólne zasoby.

Uczestnik

Osoba dołączona do konferencji lub korzystająca z trybu towarzyszącego, oglądająca jako widz lub urządzenie w sali połączone z rozmową. Gdy uczestnik dołącza do konferencji, przypisywany jest mu unikalny identyfikator.

Trafne strumienie

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

Liczba uczestników konferencji może przekroczyć 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 mówił.

Selective Forwarding Unit (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 oferującego. Pamiętaj, że odpowiedź SDP nie może dodawać strumieni sygnalizowanych z początkowej oferty. Nieoficjalnie: jeśli peer oferujący sygnalizuje, że akceptuje maksymalnie 3 strumienie audio od swojego 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 Meet Media API 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 mają zostać otwarte 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 nadajnik-odbiornik 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.

Protokół 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 równorzędnego jest mapowany na RtpReceiver konkretnego nadajnika-odbiornika na zdalnym urządzeniu równorzędnym. Działa to też w drugą stronę. RtpSender tego samego nadajnika-odbiornika 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ć indywidualne strumienie do wszystkich pozostałych uczestników, SFU multipleksuje wybrane strumienie uczestników na mniejszą liczbę wychodzących strumieni wirtualnych. Upraszcza to topologię połączeń i zmniejsza obciążenie uczestników, umożliwiając skalowalne konferencje. Każdy strumień wirtualny może zawierać multimedia od wielu uczestników, którymi dynamicznie zarządza SFU.