Tìm hiểu các khái niệm về Media API

Google Meet Media API cho phép ứng dụng của bạn tham gia một hội nghị trên Google Meet và sử dụng các luồng nội dung nghe nhìn theo thời gian thực.

Ứng dụng sử dụng WebRTC để giao tiếp với máy chủ Meet. Các ứng dụng tham chiếu được cung cấp (C++, TypeScript) minh hoạ các phương pháp đề xuất và bạn nên xây dựng trực tiếp dựa trên các ứng dụng đó.

Tuy nhiên, bạn cũng có thể tạo ứng dụng WebRTC tuỳ chỉnh hoàn toàn tuân thủ các yêu cầu kỹ thuật của Meet Media API.

Trang này trình bày các khái niệm chính về WebRTC cần thiết để có một phiên Meet Media API thành công.

Tín hiệu trả lời ưu đãi

WebRTC là một khung ngang hàng (P2P), trong đó các máy ngang hàng giao tiếp bằng cách báo hiệu cho nhau. Để bắt đầu một phiên, máy chủ bắt đầu gửi một lời mời SDP đến một máy chủ từ xa. Ưu đãi này bao gồm các thông tin quan trọng sau:

Nội dung mô tả nội dung nghe nhìn cho âm thanh và video

Nội dung mô tả nội dung nghe nhìn cho biết nội dung được truyền tải trong các phiên P2P. Có 3 loại nội dung mô tả: âm thanh, video và dữ liệu.

Để cho biết luồng âm thanh n, bên cung cấp sẽ đưa thông tin mô tả nội dung nghe nhìn n vào ưu đãi. Điều này cũng đúng với video. Tuy nhiên, tối đa sẽ chỉ có một nội dung mô tả nội dung nghe nhìn dữ liệu.

Hướng đi

Mỗi phần mô tả âm thanh hoặc video mô tả từng luồng Giao thức truyền tải bảo mật theo thời gian thực (SRTP) do RFC 3711 quản lý. Các kết nối này là hai chiều, cho phép hai máy ngang hàng gửi và nhận nội dung nghe nhìn qua cùng một kết nối.

Do đó, mỗi nội dung mô tả nội dung nghe nhìn (trong cả câu trả lời và câu hỏi) đều chứa một trong ba thuộc tính mô tả cách sử dụng luồng:

• sendonly: Chỉ gửi nội dung nghe nhìn từ máy ngang hàng cung cấp. Máy tính từ xa sẽ không gửi nội dung nghe nhìn trên luồng này.

• recvonly: Chỉ nhận nội dung nghe nhìn từ máy tính từ xa. Máy chủ đồng cấp cung cấp sẽ không gửi nội dung nghe nhìn trên luồng này.

• sendrecv: Cả hai máy ngang hàng đều có thể gửi và nhận trên luồng này.

Bộ mã hoá và giải mã

Mỗi nội dung mô tả nội dung nghe nhìn cũng chỉ định bộ mã hoá và giải mã mà máy chủ ngang hàng hỗ trợ. Trong trường hợp API Meet Media, các ưu đãi của ứng dụng khách sẽ bị từ chối trừ phi các ưu đãi đó hỗ trợ (ít nhất) các bộ mã hoá và giải mã được chỉ định trong các yêu cầu kỹ thuật.

bắt tay DTLS

Luồng SRTP được bảo mật bằng một giao thức bắt tay Bảo mật tầng truyền tải Datagram ("DTLS", RFC 9147) ban đầu giữa các máy ngang hàng. DTLS thường là giao thức từ máy khách đến máy chủ; trong quá trình truyền tín hiệu, một máy ngang hàng đồng ý đóng vai trò là máy chủ trong khi máy ngang hàng còn lại đóng vai trò là máy ngang hàng.

Vì mỗi luồng SRTP có thể có kết nối DTLS chuyên dụng riêng, nên mỗi nội dung mô tả nội dung đa phương tiện sẽ chỉ định một trong ba thuộc tính để cho biết vai trò của máy ngang hàng trong quy trình bắt tay DTLS:

• a=setup:actpass: Máy khách cung cấp sẽ trì hoãn lựa chọn của máy khách từ xa.

• a=setup:active: Máy khách này đóng vai trò là ứng dụng khách.

• a=setup:passive: Thiết bị đồng cấp này đóng vai trò là máy chủ.

Nội dung mô tả nội dung nghe nhìn của ứng dụng

Kênh dữ liệu (RFC 8831) là một bản tóm tắt của Giao thức truyền tải điều khiển luồng ("SCTP", RFC 9260).

Để mở kênh dữ liệu trong giai đoạn truyền tín hiệu ban đầu, ưu đãi phải chứa nội dung mô tả nội dung nghe nhìn của ứng dụng. Không giống như nội dung mô tả âm thanh và video, nội dung mô tả ứng dụng không chỉ định hướng hoặc bộ mã hoá và giải mã.

Ứng viên ICE

Các đề xuất Thiết lập kết nối tương tác ("ICE", RFC 8445) của máy ngang hàng là danh sách các tuyến mà máy ngang hàng từ xa có thể sử dụng để thiết lập kết nối.

Sản phẩm Descartes của hai danh sách ngang hàng, được gọi là cặp đề xuất, đại diện cho các tuyến đường tiềm năng giữa hai ngang hàng. Các cặp này được kiểm thử để xác định tuyến đường tối ưu.

Tín hiệu thông qua API Meet REST

Sử dụng Meet REST API để thực hiện tín hiệu offer-answer này. Ứng dụng của bạn cung cấp một ưu đãi SDP cho phương thức connectActiveConference() và nhận lại một câu trả lời SDP.

Ví dụ về quy trình kết nối

Dưới đây là một ưu đãi có nội dung mô tả nội dung nghe nhìn:

Máy khách từ xa phản hồi bằng một câu trả lời SDP chứa cùng số lượng dòng mô tả nội dung đa phương tiện. Mỗi dòng cho biết nội dung đa phương tiện (nếu có) mà máy khách từ xa gửi lại cho ứng dụng cung cấp qua luồng SRTP. Máy chủ đồng cấp từ xa cũng có thể từ chối các luồng cụ thể từ bên cung cấp bằng cách đặt mục nhập mô tả nội dung nghe nhìn đó thành recvonly.

Đối với Meet Media API, ứng dụng khách luôn gửi ưu đãi SDP để bắt đầu kết nối. Meet không bao giờ là ứng dụng tạo cuộc họp.

Hành vi này do các ứng dụng tham chiếu (C++, TypeScript) quản lý nội bộ, nhưng nhà phát triển của ứng dụng tuỳ chỉnh có thể sử dụng PeerConnectionInterface của WebRTC để tạo ưu đãi.

Để kết nối với Meet, ưu đãi phải tuân thủ các yêu cầu cụ thể:

1. Ứng dụng phải luôn đóng vai trò là ứng dụng trong quy trình bắt tay DTLS, vì vậy, mọi nội dung mô tả nội dung nghe nhìn trong ưu đãi phải chỉ định a=setup:actpass hoặc a=setup:active.

2. Mỗi dòng mô tả nội dung nghe nhìn phải hỗ trợ tất cả các bộ mã hoá và giải mã bắt buộc cho loại nội dung nghe nhìn đó:

   • Âm thanh: Opus
   • Video: VP8, VP9, AV1

3. Để nhận âm thanh, ưu đãi phải bao gồm đúng 3 nội dung mô tả nội dung nghe nhìn chỉ nhận. Bạn có thể thực hiện việc này bằng cách đặt bộ thu phát trên đối tượng kết nối ngang hàng.

   C++

   // ...
   rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;
   
   for (int i = 0; i < 3; ++i) {
     webrtc::RtpTransceiverInit audio_init;
     audio_init.direction = webrtc::RtpTransceiverDirection::kRecvOnly;
     audio_init.stream_ids = {absl::StrCat("audio_stream_", i)};
   
     webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::RtpTransceiverInterface>>
       audio_result = peer_connection->AddTransceiver(
         cricket::MediaType::MEDIA_TYPE_AUDIO, audio_init);
   
     if (!audio_result.ok()) {
       return absl::InternalError(absl::StrCat("Failed to add audio transceiver: ",
                                               audio_result.error().message()));
     }
   }
   

   JavaScript

   pc = new RTCPeerConnection();
   
   // Configure client to receive audio from Meet servers.
   pc.addTransceiver('audio', {'direction':'recvonly'});
   pc.addTransceiver('audio', {'direction':'recvonly'});
   pc.addTransceiver('audio', {'direction':'recvonly'});
   

4. Để nhận video, mặt hàng phải có 1 đến 3 nội dung mô tả nội dung nghe nhìn dạng video chỉ nhận. Bạn có thể thực hiện việc này bằng cách đặt bộ thu phát trên đối tượng kết nối ngang hàng.

   C++

   // ...
   rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;
   
   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);
   
     if (!video_result.ok()) {
       return absl::InternalError(absl::StrCat("Failed to add video transceiver: ",
                                               video_result.error().message()));
     }
   }
   

   JavaScript

   pc = new RTCPeerConnection();
   
   // Configure client to receive video from Meet servers.
   pc.addTransceiver('video', {'direction':'recvonly'});
   pc.addTransceiver('video', {'direction':'recvonly'});
   pc.addTransceiver('video', {'direction':'recvonly'});
   

5. Ưu đãi phải luôn bao gồm các kênh dữ liệu. Ít nhất, các kênh session-control và media-stats phải luôn mở. Tất cả kênh dữ liệu phải là ordered.

   C++

   // ...
   // All data channels must be ordered.
   constexpr webrtc::DataChannelInit kDataChannelConfig = {.ordered = true};
   
   rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;
   
   // Signal session-control data channel.
   webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::DataChannelInterface>>
     session_create_result = peer_connection->CreateDataChannelOrError(
       "session-control", &kDataChannelConfig);
   
   if (!session_create_result.ok()) {
     return absl::InternalError(absl::StrCat("Failed to create data channel ",
                                             data_channel_label, ": ",
                                             session_create_result.error().message()));
   }
   
   // Signal media-stats data channel.
   webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::DataChannelInterface>>
     stats_create_result = peer_connection->CreateDataChannelOrError(
       "media-stats", &kDataChannelConfig);
   
   if (!stats_create_result.ok()) {
     return absl::InternalError(absl::StrCat("Failed to create data channel ",
                                             data_channel_label, ": ",
                                             stats_create_result.error().message()));
   }
   

   JavaScript

   // ...
   pc = new RTCPeerConnection();
   
   // All data channels must be ordered.
   const dataChannelConfig = {
     ordered: true,
   };
   
   // Signal session-control data channel.
   sessionControlChannel = pc.createDataChannel('session-control', dataChannelConfig);
   sessionControlChannel.onopen = () => console.log("data channel is now open");
   sessionControlChannel.onclose = () => console.log("data channel is now closed");
   sessionControlChannel.onmessage = async (e) => {
     console.log("data channel message", e.data);
   };
   
   // Signal media-stats data channel.
   mediaStatsChannel = pc.createDataChannel('media-stats', dataChannelConfig);
   mediaStatsChannel.onopen = () => console.log("data channel is now open");
   mediaStatsChannel.onclose = () => console.log("data channel is now closed");
   mediaStatsChannel.onmessage = async (e) => {
     console.log("data channel message", e.data);
   };
   

Ví dụ về câu trả lời và ưu đãi SDP

Sau đây là ví dụ đầy đủ về một ưu đãi SDP hợp lệ và câu trả lời SDP phù hợp. Ưu đãi này đàm phán một phiên Meet Media API có âm thanh và một luồng video.

Hãy quan sát có 3 nội dung mô tả nội dung nghe nhìn, 1 nội dung mô tả nội dung nghe nhìn dạng video và nội dung mô tả nội dung nghe nhìn bắt buộc cho ứng dụng.

Chủ đề có liên quan

• Bắt đầu