Ở phần trước mình có giới thiệu về WebRTC và hướng tiếp cận media server. Ở phần này mình sẽ đi sâu vào chi tiết cách thực hiện một ứng dụng sử dụng media server cụ thể hơn là KMS (kurento media server).

I. Các thành phần tham gia vào thực hiện ứng dụng video call

Với các ứng dụng WebRTC thông thường, việc thực hiện các ứng dụng media sử dụng API WebRTC cung cấp thông thường hầu như khá phức tạp, rất khó để cho lập trình viên. Như đã đề cập đến ở chương 2, kurento cung cấp một số API nhằm mục đích đơn giản hóa việc xây dựng các ứng dụng đa phương tiện, một phần trong các API này dựa vào WebRTC API có sẵn. Một điều nữa là mặc dù các ứng dụng WebRTC chưa hẳn là peer-to-peer, nó vẫn cần một server đứng giữa để thực hiện việc trao đổi các thông tin cần thiết giữa các peer, có thể cần một media server cho việc nâng cao hiệu suất của ứng dụng WebRTC. Dưới đây là một số thành phần tham gia vào khi thực hiện cuộc gọi.

Tóm lượt lại hình trên ta có thể thấy có 4 thành phần chính tham gia vào quá trình thực hiện. Dưới đây là mô tả tóm gọn các thành phần:

• Peer : Chính là đối tượng kết nối ( ở đây có thể là trình duyệt web,mobile…).
• Signaling Server: Như đã giới thiệu ở các phần trên, ở đây nó đứng giữa thực hiện trao đổi với các peer và KMS.
• ICE (Interactive Connectivity Establishment): Quá trình hỗ trợ vượt NAT, nó sẽ nhận đăng kí từ các peer và trả về candidate (là các cách để kết nối với peer đó).ICE ở đây có thể là tập hợp bao gồm STUN, TURN server được đặt ở các đối tượng là peer và KMS. Phần này đã được giới thiệu ở phần trước

Các đối tượng này sẽ tham gia vào trong quá trình thực hiện cuộc gọi video.Về cơ bản ta có thể chia quá trình này thành 3 quá trình con là đăng kí,thực hiện cuộc gọi,kết thúc cuộc goi.Chi tiết về quá trình thực hiện sẽ được mô tả bên dưới.

II. Quá trình thực hiện ứng dụng video call

1. Đăng kí người dùng

Bước này thực hiện khá đơn giản với việc có 3 tác nhân là người dùng A, người dùng B và signaling server.Server này sẽ là trung gian xử lý các yêu cầu đăng kí của hai bên (ví dụ có thể lưu vào database).Nó cũng đưa ra các quyết định liệu có thể cho người dùng đăng kí hay không.Có hai trạng thái mà nó gửi về cho người dùng ở bước này là đăng kí thành công và đăng kí thất bại. Hình dưới mô tả pha đăng kí người dùng.

2.Thực hiện cuộc gọi

Bước chủ yếu được giới thiệu ở đây là thực hiện cuộc gọi.Ở bước này các peer sẽ phải thực hiện một số trao đổi nhất định để có thể đạt được kết nối với KMS. Các trao đổi này được trung gian qua Signaling Server và lấy được candidate thông qua các ICE đứng bên cạnh các đối tượng.Dưới đây là mô tả chi tiết các quy trình để thực hiện một cuộc gọi video.

Quy trình lấy được SDP

Khi thực hiện việc đăng kí thành công,để bắt đầu thiết lập cuộc gọi, mỗi bên cần biết một thông số nhất định.Đầu tiên, bắt đầu khởi tạo một đối tượng là WebRtcPeer ( đã nhắc qua ở chương 2).Sau đó ta bắt đầu thiết lập một callback để lắng nghe SDP offer được gửi về. Khi nhận được SDP thành công, Peer A bắt đầu gửi yêu cầu cấp quyền truy cập một số tài nguyên thiết bị tới người dùng.Nếu người dùng đồng ý, chúng ta bắt đầu thực hiện quá trình tiếp theo là gửi các thông tin ban đầu từ Peer A ( như là SDP, đến từ đâu, muốn kết nối tới đâu…) đến signaling.Signaling có nhiệm vụ lưu lại các thông tin này và bắt đầu thông báo tới trình duyệt B là có ai đó muốn kết nối.Khi Peer B nhận được thông báo bên A muốn kết nối, nó sẽ thiết lập tương tự như Peer A khi lấy SDP offer và truy cập thiết bị. Khi đó Signaling sẽ có thông tin của hai Peer và bắt đầu vào quá trình thiết lập cuộc gọi với KMS.

Trao đổi ứng viên (candidate)

Quá trình này song song với quá trình đạt được SDP, mục đích của quá trình này nhằm mở ra các cách khác nhau mà cách peer khác có thể kết nối với A.Đầu tiên ta cần làm là đăng kí lắng nghe candidate tới ICE peer A bằng cách ta sẽ thiết lập một callback là OnIceCandidate ( đây là một option khi tạo đối tượng WebRtcPeer).Khi đó,ICE cho trình duyệt A sẽ thực hiện chức năng của nó là tìm các cách để có thể kết nối với A. Khi tìm được, nó sẽ gửi lại cho trình duyệt A thông qua hàm callback OnIceCandidate.Bước tiếp theo trình duyệt A gửi lại cho signaling server, server này đơn giản là ủy quyền lại cho Kurento Media Sever (KMS) bằng cách gọi addCandidate để yêu cầu thêm vào các cách để kết nối với A (candidate).Vì vậy KMS sẽ biết cách để kết nối với peer A.Việc này tương tự với Peer B.

Quá trình này được thực hiện khi mà WebRtcEndpoint đã được tạo ra bên trong KMS. Khi đó ta cần biết cách để biết làm sao để kết nối với WebRtcEndpoint tương ứng. Bằng cách thêm vào một máy chủ ICE bên cạnh KMS ( có thể là STUN hoặc TURN). Nó sẽ nói cho KMS biết làm cách nào để kết nối với WebRtcEndpoint trong đó.Từ đó KMS sẽ gửi các cách kết nối với WebRtcEndpoint này (candidate) trở lại chỗ mà nó đã đăng kí mỗi khi mà máy chủ ICE gửi trả về một candidate tương ứng.Các candidate này được gửi trở lại các peer qua Signaling làm trung gian.Các peer sẽ thực hiện công việc cuối cùng là thêm cái candidate đó vào (bằng cách thực hiện addCandidate ở đối tượng WebRtcPeer) và quá trình này có thể sẽ phải lặp lại nhiều lần. Nếu quá trình trao đổi thành công, Peer sẽ biết cách để kết nối với WebRtcEndpoint trong KMS vừa tạo.Kết quả từ hai quá trình kể trên là các Peer và KMS đã hiểu cách kết nối với nhau.

Bắt đầu thiết lập cuộc gọi

Ngay sau khi B chấp nhận kết nối, chúng ta bắt đầu thiết lập các bước cần thiết để có thể đạt được cuộc gọi giữa hai.Trọng phần này các bước sẽ được thực hiện ở Signaling, dưới đây là mô tả các bước Signaling cần thực hiện để thiết lập cuộc gọi.

Ở bước này đầu tiên ta cần phải tạo một kurentoClient bằng cách gọi hàm kurento ( được kurento cung cấp ) nhằm kết nối tới KMS.Sau khi đã kết nối được với KMS,chúng ta cần gửi yêu cầu đến tạo một pipeline, chúng ta sử dụng đối tượng kurentoClient đã tạo trước đó gọi hàm create (được thiết kế để tương tác với KMS như đề cập ở chương trước) với tham số là MediaPipeline.Tiếp đó, ngay sau khi có được pipeline, chúng ta cần hai WebRTCEndpoint cho hai trình duyệt tương ứng A và B. Mục đích của việc này là để các luồng media hoạt động trên KMS có thể trao đổi với nhau.

Mặc dù đã tạo hai WebRTCEndPoint nhưng chúng ta cần phải làm một điều là kết nói chúng lại với nhau,việc kết nối này được thực hiện trên cả hai WebRTCEndPoint. Thực hiện điều này bằng cách sử dụng đối tượng hai đối tượng WebRTCEndPoint ở trên và thực hiện gọi invoke với tham số là ‘connect’. Việc này được thực hiện lần lượt với cả hai WebRTCEndPoint.

Bước cuối cùng trong việc thực hiện thiết lập cuọc gọi là việc trao đổi SDP với KMS.Bên phía signaling đã có hai SDP offer được gửi cho nó từ lần trước.Cái signaling làm là gọi sử dụng đối tượng WebRTCEndPoint mà KMS đã trả về từ trước, gọi hàm processOffer với tham số là SDP offer tương ứng với mỗi peer và một callback.Khi thực hiện điều này, bên phía KMS sẽ đáp lại SDP answer và gửi trả về tương ứng với mỗi peer.Sau khi nhận được SDP answer, mỗi peer sẽ gọi processAnswer để xử lý SDP answer được trả về. Từ đây mỗi peer có thể tương tác với nhau, gửi/nhận dữ liệu media qua KMS.

Kết thúc cuộc gọi

Pha cuối cùng trong quy trình là ngừng cuộc gọi. Khi có yêu cầu ngừng từ một peer, peer này sẽ kết thúc phiên tương tác bằng cách ngắt kết nối camera và gửi yêu cầu tới signaling, signaling sẽ tiếp tục gửi lại yêu cầu này tới peer đang tương tác và thực hiện tương tự. Tiếp theo signaling sẽ gửi tới KMS yêu cầu ngắt kết nối với hai peer và giải phóng tài nguyên, kết thúc phiên làm việc. Hình dưới mô tả phiên làm việc kết thúc tương tác.

III.Kết luận

Trên đây là chi tiết toàn bộ process để thực hiện một ứng dụng video call, đây là các bước tổng quát bạn chị cần nắm được các bước này là có thể thực hiện tương các ứng dụng khác như livestream, video conference, group chat.... Ở bài sau mình sẽ chỉ ra chương trình thực hiện ứng dụng video call một cách cụ thể hơn