XÂY DỰNG GIẢI PHÁP PHÂN cụm CHO KURENTO MEDIA SERVER NHẰM TĂNG KHẢ NĂNG mở RỘNG của các hệ THỐNG WEBRTC

Kurento với phần lõi là Kurento Media Server, đây là một media server được xâydựng nhằm xử lý nhiều tác vụ video nâng cao như thực tế ảo tăng cường, phân tích vànhận dạng…Kurento cũng đư

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Đào Tuấn Anh

XÂY DỰNG GIẢI PHÁP PHÂN CỤM CHO KURENTO MEDIA SERVER NHẰM TĂNG KHẢ NĂNG MỞ RỘNG

CỦA CÁC HỆ THỐNG WEBRTC

ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Truyền thông và mạng máy tính

HÀ NỘI - 2018 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Đào Tuấn Anh

XÂY DỰNG GIẢI PHÁP PHÂN CỤM CHO KURENTO MEDIA SERVER NHẰM TĂNG KHẢ NĂNG MỞ RỘNG

CỦA CÁC HỆ THỐNG WEBRTC

ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Truyền thông và mạng máy tính

Cán bộ hướng dẫn: TS Nguyễn Đình Hóa

Cán bộ đồng hướng dẫn: TS Hoàng Xuân Tùng

HÀ NỘI - 2018

LỜI CAM ĐOAN

Tôi xin cam đoan những nội dung trong đồ án dưới đây là do chính tôi thực hiện dưới sựhướng dẫn trực tiếp của TS Hoàng Xuân Tùng và T.S Nguyễn Đình Hóa Tất cả tài liệutham khảo nghiên cứu liên quan đều được ghi nguồn trích dẫn rõ ràng Nếu có gì sai tôixin hoàn toàn chịu trách nhiệm

Hà Nội, ngày…tháng…năm 2018

Sinh viên

Đào Tuấn Anh

LỜI CẢM ƠN

Tôi xin gửi lời cảm ơn sâu sắc của mình tới thầy Hoàng Xuân Tùng và thầy Nguyễn

Đình Hóa thuộc bộ môn Truyền thông và Mạng máy tính, trường Đại Học Công Nghệ, Đại Học Quốc Gia Hà Nội, người đã trực tiếp hướng dẫn tôi trong quá trình thực

hiện đồ án này

Tôi cũng xin chân thành cảm ơn các Thầy Cô trong khoa Công Nghệ Thông Tin nói riêng

và các thầy cô trong trường Đại Học Công Nghệ - Đại Học Quốc Gia Hà Nội nói chung đãdạy dỗ và tận tình chỉ bảo tôi trong suốt quá trình học tập tại trường

Cuối cùng tôi xin gửi lời cảm ơn tới gia đình, bạn bè đã luôn động viên ủng hộ giúp đỡ tôi

để có thể hoàn thành khóa luận này

Tôi xin chân thành cảm ơn

Hà Nội, ngày tháng năm 2018

Sinh viên

Đào Tuấn Anh

MỤC LỤC

DANH MỤC CÁC TỪ VIẾT TẮT i

DANH MỤC HÌNH VẼ ii

DANH MỤC BẢNG iv

CHƯƠNG 1 MỞ ĐẦU 1

1.1 Đặt vấn đề 1

1.2 Phạm vi mục tiêu báo cáo 1

1.3 Phương pháp và bố cục nghiên cứu 2

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT 3

2.1 Giới thiệu về hệ thống WebRTC 3

2.1.1 Quá trình phát triển 3

2.1.2 Một số lợi ích của WebRTC 4

2.1.3 Các giao thức trong WebRTC 4

2.1.4 Một số kiến trúc của hệ thống WebRTC 7

2.2 Một số media server có sẵn 11

2.3 Các gói thư viện trong kurento 14

2.3.1 Kurento API 14

2.3.2 Media Element 14

2.3.3 Media Pipeline 16

2.3.4 Kurento Protocol 16

2.4 Các kiến trúc phân tải của ứng dụng web 18

2.4.1 Tất cả trong một 18

2.4.2 Tách biệt riêng database server 18

2.4.3 Load Balancer ( Reverse Proxy) 19

2.4.4 HTTP Accelerator (Caching Reverse Proxy) 20

2.4.5 Master-Slave nhân rộng database 21

CHƯƠNG 3 GIẢI PHÁP PHÂN CỤM CHO KURENTO MEDIA SERVER 23

3.1 Các quá trình thực hiện cuộc gọi video với kurento media server 23

3.1.1 Đăng kí người dùng 24

3.1.2 Thực hiện cuộc gọi 24

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

3.2 Một số tình huống phân tải trên kurento 29

3.2.1 Tình huống phân tải phổ biến 29

3.2.2 Tình huống phân tải cho kurento media server 30

3.2.3 Một số thuật toán phân tải phổ biến 31

3.3 Giải pháp phân cụm với API GATEWAY 35

3.3.1 Vai trò của API GATEWAY 35

3.3.2 Một số hướng tiếp cận API GATEWAY trong hệ thống WebRTC 44

CHƯƠNG 4 CÀI ĐẶT VÀ THỬC NGHIỆM CHƯƠNG TRÌNH 46

4.1 Các thư viện sử dụng 46

4.1.1 Các công cụ và thư viện sử dụng ở trình duyệt web 46

4.1.2 Các công cụ và thư viện được sử dụng trong phần Signaling 47

4.1.3 Công cụ và thư viện được sử dụng trên API GATEWAY 49

4.2 Cài đặt hệ thống 50

4.2.1 Cài đặt Kurento Media Server 50

4.2.2 Khai triển các server 51

4.3 Các cài đặt thực nghiệm 54

4.3.1 Thực nghiệm hệ thống với một cuộc gọi khi không có API GATEWAY 54

4.3.2 Thực nghiệm hệ thống với một cuộc gọi khi thêm vào API GATEWAY 56

4.3.3 Thực nghiệm hệ thống với nhiều cuộc gọi khi không có API GATEWAY 59

4.3.4 Thực nghiệm hệ thống với nhiều cuộc gọi khi có API GATEWAY 60

4.4 Kết quả 62

CHƯƠNG 5 KẾT LUẬN CHUNG 64

5.1 Những thành quả đã đạt được 64

5.2 Một số hướng phát triển tiếp theo 64

TÀI LIỆU THAM KHẢO 65

DANH MỤC CÁC TỪ VIẾT TẮT

1. WebRTC Web Real-Time Communication

2. KMS Kurento Media Server

3. HTTP Hypertext Transfer Protocol

4. CSS Cascading Resource Locator

5. NAT Network Address Translation

6. STUN Session Traversal Utilities for NAT

7. TURN Traversal Using Relays around NAT

8. P2P Peer-to-Peer

9. HTML Hyper-Text Markup Language

10. UDP User Datagram Protocol

11. API Application Programming Interface

12. JSON Javasript Object Notation

13. JSON-RPC Javasript Object Notation – Remote Procedure Call

14. GCP Google Cloud Platform

15. REST Representational State Transfer

16. SIP Session Initiation Protocol

DANH MỤC HÌN

Hình 2.1 Protocol stack trong WebRTC [3] 5

Hình 2.2 Mô tả cách thức hoạt động của STUN 6

Hình 2.3 Mô tả cách thức hoạt động của TURN 6

Hình 2.4 Kiến trúc của hệ thống web truyền thống 7

Hình 2.5 Kiến trúc phổ biến của hệ thống WebRTC 8

Hình 2.6 Minh họa hệ thống WebRTC khi có nhiều người dùng kết nối với nhau 8

Hình 2.7 Kiến trúc đơn giản của WebRTC khi thêm vào Media Server 9

Hình 2.8 Minh họa cách thức hoạt động của mô hình MCU 10

Hình 2.9 Mô tả cách thức hoạt động của mô hình SFU 11

Hình 2.10 Mô tả một Media Pipeline với hai thành phần là WebRtcEndpoint đượ nối với nhau .16

Hình 2.11 Mô tả kiến trúc phân tải tất cả trong một 18

Hình 2.12 Mô tả kiến trúc phân tải tách riêng database server 19

Hình 2.13 Mô tả kiến trúc phân tải load balancer 20

Hình 2.14 Mô tả kiến trúc phân tải Accelerator 21

Hình 2.15 Mô tả kiến trúc phân tải Master-Slave nhân rộng database 21

YHình 3.2 Mô tả kiến trúc các thành phần tham gia vào thực hiện cuộc gọi video 23

Hình 3.3 Mô tả quá trình đăng kí 24

Hình 3.4 Mô tả quá trình bắt đầu lấy SDP 25

Hình 3.5 Quá trình thu thập candidate từ trình duyệt và trao đổi với KMS 25

Hình 3.6 Quá trình KMS trao đổi candidate với các peer 26

Hình 3.7: Quá trình kết nối với KMS và tạo các thành phần cần thiết cho việc thực hiện cuộc gọi 27

Hình 3.8 Quá trình kết nối hai WebRtcEndpoint 28

Hình 3.9 Quá trình trao đổi SDP và bắt đầ thiết lập kết nối giữa các peer và KMS 28

Hình 3.10 Quá trình kêt thúc cuộc gọi 29

Hình 3.11 Tình huống phân tải phổ biến của ứng dụng web 30

Hình 3.12 Tình huống phân tải với ứng dụng media thực hiện bới kurento 31

Hình 3.13 Minh họa thuật toán phân tải Round Robin 32

Hình 3.14 Minh họa thuật toán phân tải Weighted Round Robin 33

Hình 3.15 Hình minh họa thuật toán Round Robin khi một số kết nối bị ngắt 33

Hình 3 16 Minh họa thuật toán phân tải Least Connections 34

Hình 3.17 Kiến trúc của hệ thống WebRTC khi thêm API GATEWAY trung gian 35

Hình 3.18 Mô tả tóm lượt sự tương tác giữa API GATEWAY và KMS 43

Hình 3.19 Mô tả trường hợp signaling gửi một yêu cầu duy nhất 44

Hình 3.20 Mô tả trường hợp signaling gửi lần lượt yêu cầu 44

YHình 4.1 Các thanh phần tham gia được thực trong chương trình 46

Hình 4.2 Mô tả các thông số để tạo server trên Google Cloud Platform 53

Hình 4.3 Mô tả kết quả khi tạo server thành công 53

Hình 4.4 Kết quả thực nghiệm thực hiện một cuộc gọi khi không có API GATEWAY 56

Hình 4.5 Mô tả chạy chương trình thực hiện qua chương trình test 56

Hình 4.6 Kết quả thu được với thực nghiệm 2 58

Hình 4.7 Mô tả thực hiện thực nghiệm 2 với chương trình test 59

Hình 4.8 Mô tả thực hiện thực nghiệm 3 với chương trình test 60

Hình 4.9 Kết quả của cuộc gọi thứ 11 60

Hình 4.10 Mô tả thực hiện thực nghiệm 4 với chương trình test 62

Hình 4.11 Kết quả thực hiện cuộc gọi thứ 11 với thực nghiệm 4 62

DANH MỤC BẢ

Bảng 2.1 Thống kê số peer và các luồng stream tham gia khi thực hiện theo mô hình MCU 10

Bảng 2.2 Bảng thống kê các peer và luồng stream tham gia khi hoạt động theo mô mình SFU .11

Bảng 2.3 Danh sách các media server có sẵn 12

Bảng 2.4 Tóm lượt các đặc tính được hỗ trọ của các media server trên 14

Bảng 2.5 Danh sách các media element trên KMS [22] 15

YHình 4.1 Các thanh phần tham gia được thực trong chương trình………46

Hình 4.2 Mô tả các thông số để tạo server trên Google Cloud Platform 53

Hình 4.3 Mô tả kết quả khi tạo server thành công 53

Hình 4.4 Kết quả thực nghiệm thực hiện một cuộc gọi khi không có API GATEWAY 56

Hình 4.5 Mô tả chạy chương trình thực hiện qua chương trình test 56

Hình 4.6 Kết quả thu được với thực nghiệm 2 58

Hình 4.7 Mô tả thực hiện thực nghiệm 2 với chương trình test 59

Hình 4.8 Mô tả thực hiện thực nghiệm 3 với chương trình test 60

Hình 4.9 Kết quả của cuộc gọi thứ 11 60

Hình 4.10 Mô tả thực hiện thực nghiệm 4 với chương trình test 62

Hình 4.11 Kết quả thực hiện cuộc gọi thứ 11 với thực nghiệm 4 62

CHƯƠNG 1 MỞ ĐẦU 1.1 Đặt vấn đề

Ngày nay với sử bùng nổ công nghệ, người dùng internet đòi hỏi yêu cầu sử dụngcác ứng dụng truyền thông đa phương tiện ngày càng lớn Các ứng dụng multimedia ngàynày không hẳn chỉ là thực hiện việc tương tác giữa các người dùng là đủ Chúng ta cũngcần phải quan tâm đến vấn đề tối ưu hóa hiệu năng hay xử lý các tính năng nâng cao hơnnhằm giúp tăng khả năng tương tác với mọi người sử dụng bằng cách sử dùng các cộngnghệ thực tế ảo tăng cường ( AR ), Computer Vision … Một số ứng dụng nổi tiếng thựchiện tốt việc này có thế kể tới như Facebook, Youtube, Skype, Viber, … Những ứng dụngđược sử dụng rộng rãi trên toàn thế thế giới

Tuy nhiên việc xử lý dữ liệu multimedia không hề đơn giản, đòi hỏi người thực hiệnphải có kiến thức nhất định Chính vì lý do này một số mã nguồn mở được đưa ra nhằmgiúp cho việc đơn gian hóa khi khai triển các ứng dụng multimedia Có rất nhiều dự án mãnguồn mở được đưa ra nhằm trợ giúp cho việc xây dựng các ứng dụng multimedia nhưJenus, Jitsi, Lincode, Kurento…Mỗi nền tảng được thiết kế đều có ưu và nhược điểmriêng của mình.Trong báo cáo này xin được trình bầy về Kurento Đây là một nền tảngmạnh mẽ và hoàn toàn miễn phí được đưa ra với mục đích nâng cao khả năng thực hiệncác ứng dụng multimedia

Kurento với phần lõi là Kurento Media Server, đây là một media server được xâydựng nhằm xử lý nhiều tác vụ video nâng cao như thực tế ảo tăng cường, phân tích vànhận dạng…Kurento cũng đưa ra các gói thư viện nhằm hỗ trợ cho việc điều khiển trựctiếp Kurento Media Server và đơn giản hóa quá trình thực hiện các API của WebRTC.Mặc dù đây là một hỗ trợ tốt cho người lập trình, tuy nhiên việc này vô hình chung làmcho ta phải phụ thuộc vào những ngôn ngữ lập trình mà Kurento đưa ra ,vấn đề này sẽđược đề cập trong báo cáo

Một vấn đề khác được đề cập đến ở đây là thông thường khi ta thực hiện các ứngdụng multimedia khi sử dụng với kurento thường được được đi kèm với một KurentoMedia Server duy nhất Khi số lượng người dùng tăng lên đồng nghĩa với việc hiệu năngcủa ứng dụng sẽ giảm đi, ta cần phải có giải pháp để thay đổi điều này Nhưng sự điềuchỉnh nào cũng đồng nghĩa với sự thay đổi trong ứng dụng hiện có Vì vậy trong báo cáo

này đưa ra giải pháp giúp cho tăng hiệu năng của hệ thống, nhưng cũng đồng thời đảm bảogiữ nguyên được những cái đã xây dựng trước đó của ứng dụng

1.2 Phạm vi mục tiêu báo cáo

Báo cáo tập trung tìm hiểu về kurento, các APIs và các giao thức mà họ sử dụng, sau

đó đưa ra cách thực hiện ứng dụng multimedia Từ đó đưa ra giải pháp nhằm cải thiện khảnăng của ứng dụng, cách mà giải pháp đó thực hiện Báo cáo cũng đưa ra ứng dụng demokhi thực hiện giải pháp, so sánh với ứng dụng khi không áp dụng giải pháp, từ đó đưa rađược các nhận xét đánh giá

1.3 Phương pháp và bố cục nghiên cứu

Báo cáo được chi thành năm chương với nội dung như sau:

Chương 1: Mở đầu.

Chương 2: Cơ sở lý thuyết Chương này giới thiệu về WebRTC, các giao thức của nó

Phân tích tại sao cần media server, đưa ra giải pháp là sử dụng kurento và giới thiệu nó Cuối cùng giới thiệu các tình huống phân tải phổ biến của ứng dụng web

Chương 3: Giải pháp phân cụm cho Kurento Media Server Chương này trình bầy cách

thực hiện cuộc gọi với kurento, sau đó đưa ra giải pháp xây dựng một server trung gian gọi là API GATEWAY nhằm tăng tính mở rộng của hệ thống WebRTC khi sử dụng kurento

Chương 4: Cài đặt và thực nghiệm đánh giá chương trình Chương này đưa ra nhưng thứ

cần thiết cho việc xây dựng chương trình Đưa ra nhưng thực nghiệm để kiểm thử và đánh giá giải pháp

Chương 5: Kết luận chung Kết quả đạt được và những hướng phát triển tiếp theo.

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT

Trong chương 2 bắt đầu đi vào tìm hiểu các thông tin tổng quát về WebRTC, những khó khăn gặp phải khi thực hiện ứng dụng với WebRTC Từ đó, bắt đầu giới thiệu về kurento như một giải pháp cho việc thực hiện ứng dụng với WebRTC

2.1 Giới thiệu về hệ thống WebRTC

WebRTC (Web Real-Time Communication) [1] là một tiêu chuẩn định nghĩa tập

hợp các giao thức truyền thông và các giao diện lập trình ứng dụng cho phép truyền tảithời gian thực trên các kết nối peer-to-peer Điều này cho phép các trình duyệt web khôngchỉ yêu cầu tài nguyên từ máy chủ mà còn truyền thông tin thời gian thực với trình duyệtkhác Về bản chất, WebRTC là tập hợp các chuẩn và giao thức cho phép trình duyệt webthực hiện trực tiếp các tính năng truyền thông đa phương tiện thời gian thực như gọi điện,truyền hình, truyền dữ liệu, gửi tin nhắn bằng các APIs Javascripts

2.1.1 Quá trình phát triển

WebRTC bắt đầu từ lúc Google muốn xây dựng một chuẩn nhằm thực hiện thờigian thực trên tất cả các trình duyệt.Vì vậy trong năm 2010 Google đa mua lại Global IPSolutions ( GIPS), đây là một công ty phần mềm về VoIP và video hội họp (công ty nàycũng phát triển nhiều thành phần được yêu cầu cho RTC (Real Time Communication)như codecs và các công nghệ echo cancellation ).Google đưa GIPS thành một mã nguồn

mở và bắt đầu tham gia vào IETF và W3C Tháng 5/2011 Google bắt đầu đưa ra một dự

án mã nguồn mở cho phép thực hiện cái ứng dụng thời gian thực cho trình duyệt được biếttới như WebRTC.Nhưng công ty hỗ trợ WebRTC tích cực nhất gồm có Google, Mozilla,Opera Sự phát triển của WebRTC qua các năm gần đây trên các trình duyệt có thể kể đếnnhư [1]:

 27/10/2011: WebRTC bắt đầu được công bố.

 11/2011: WebRTC bắt đầu hỗ phần trên Chrome 23.

 1/2013: WebRTC hỗ trợ trên firefox.

 7/2013: Phiên bản beta của Chrome 29 trên Android hỗ trợ WebRTC.

 8/2013: WebRTC hỗ trợ đầy đủ trên Chrome Android.

 10/2013: WebRTC bắt đầu hỗ trợ trên phiên bản Opera beta.

 3/2014: Bắt đầu hỗ trợ phiên bản Opera 20 trên Android.

 2/2015: WebRTC 1.0 working draft chính thức công bố, đến nay đã hỗ trợ bởi các

trình duyệt Chrome (phiên bản 23 trở lên), Firefox ( phiên bản 22 trở lên), Opera( phiên bản 18 trở lên) và hỗ trợ trình duyệt trên nền tảng Android (Chrome 29 trởlên, Firefox 24 trở lên, Opera Mobile 12 trở lên, Google Chrome OS)

2.1.2 Một số lợi ích của WebRTC

Trước kia muốn xây dựng một ứng dụng đa phương tiện người ta cần phải dùngFlash, Java Applet và tích hợp plugins từ các nhà cung cấp thứ ba để thực hiện.Vì thếWebRTC ra đời để giải quyết vấn đề này dưới đây là một số lợi ích và đặc tính màWebRTC cung cấp

Một số lợi ích của WebRTC :

 Miễn phí: WebRTC là một dự án mã nguồn mở được được Google giới thiệu

trong năm 2011 Mục đích của Google là cung cấp một công cụ truyền thôngthời gian thực dựa trên tiêu chuẩn là miễn phí và có sẵn trên tất cả các trìnhduyệt

 Hỗ trợ mọi nền tảng thiết bị: Bất kì trình trình duyệt nào với hệ điều hành bất

kì có thể tạo trực tiếp một real-time voice hoặc video kết nối tới thiết bịWebRTC khác.Lập trình viên có thể viết các đoạn mã HTML làm việc với máytính hoặc thiết bị di động

 An toàn trong voice và video [2]: WebRTC sử dụng giao thức SRTP (Secure

Real Time Communication) nhằm mục đích mã hóa và xác thực dữ liệumedia.Điều này tránh được việc nghe trộm khi người dùng thực hiện các tác vụmedia như là video hay voice

 Không Plugins : Như đề cập ở trên WebRTC cần phải cài các plugin của bên

thức ba để sử dụng các ứng dụng đa phương tiện.Việc làm làm cho ứng dụng

đa phương tiện còn phải phụ thuộc vào các nền tàng khác nhau.Với WebRTCthì không cần quan tâm đến vấn đề này

 Dễ sử dụng: Có thể tích hợp các tính năng của WebRTC trong các dịch vụ

web bằng cách sử dụng JavaScript APIs,những Framework có sẵn

 Thích ứng với các điều kiện mạng khác nhau [2]:WebRTC hỗ trợ việc

thương lượng với nhiều kiểu media và các thiết bị đầu cuối khác nhau Điềunày các ứng dụng tương tác video hoặc gọi thoại của chúng ta sử dụng băngthông hiệu quả hơn.Các APIs WebRTC và signaling có thể thỏa thuận kíchthức và định dạng cho môi thiết bị đầu cuối

2.1.3 Các giao thức trong WebRTC

Do các đặc điểm cần thời gian thực cao hơn tính tin cậy, giao thức UDP được sửdụng trong WebRTC là giao thức vận chuyển.Nhưng để thỏa mãn yêu cầu của trình duyệtphải hỗ trợ giao thức và dịch vụ ở lớp khác nữa.Về cơ bản các giao thức chính sử dụngtrong WebRTC được thể hiện ở hình dưới:

Hình 2.1 Protocol stack trong WebRTC [3]

SRTP

SRTP (Secure Real Time Protocol) [4] được sử dụng để mã hóa và chuyển các góitin media giữa các WebRTC client.Sau khi thiết lập thành công PeerConnection,kết nốiSRTP sẽ được thiết lập giữa các trình duyệt và máy chủ.Với dữ liệu non-audio hay video,SRTP không được sử dụng, thay vào đó là SCTP

DTLS

Datagram Transport Layer Security- DTLS [6] giao thức này cung cấp tính năngbảo mật và toàn vẹn dữ liệu Tất cả các dữ liệu truyền P2P đều được bảo mật sử dụngDTLS

Traversal Utilities for NAT) [8] STUN server tồn tại trên mạng internet và chỉ có nhiệm

vụ duy nhất là kiểm tra địa chỉ IP và cổng của yêu cầu vừa đến và gửi trở lại IP và cổngđó.Các ứng dụng sử dụng STUN server để cung cấp IP và cổng công khai từ internet Từ

đó một WebRTC peer có thể tự lấy được địa chỉ IP và cổng công khai và đưa nó cho cácpeer khác thông qua cơ chế signaling (tìm hiểu ở phần 2.1.4).Hình bên dưới mô tả về cáchlàm việc của STUN server:

Hình 2.2 Mô tả cách thức hoạt động của STUNTrong đa số trường hợp chỉ cần dùng STUN để thiết lập kết nối P2P , trừ trườnghợp Peer đứng sau symmetric NAT hoặc post-restricted NAT Trường hợp này sẽ khôngthành công, cần phải sử dụng đến TURN được giới thiệu tiếp theo

TURN

Traversal Using Relays around NAT (TURN) [9] Được xây dựng nhằm vượt quasymmetric NAT bằng cách mở một kết nối tới TURN server và đáp lại tất cả thông tinthông qua server này (dữ liệu audio/video/data streaming giữa các peer, không phảisignaling data).Turn server làm được điều này vì nó có một public địa chỉ, vì thế nó có thểliên lạc với các peer thậm chí peer có tường lửa hoặc proxy đứng sau Hình dưới mô tảhoạt động của TURN server

Hình 2.3 Mô tả cách thức hoạt động của TURN

SDP

Session Description Protocol [10] là một chuẩn mô tả các thông số của mỗi kết nốinhư là độ phân giải, định dạng, codecs, mã hóa… Điều này làm cho mỗi peer có thể hiểunhau khi dữ liệu được truyền Đây thực chất là meta-data miêu tả nội dung chứ không phải

là dữ liệu media

ICE

Interactive Connectivity Establishment [11] là một chuẩn được sử dụng để thiết lậpkết nối giữa các các peer trên internet.Mặc dù WebRTC là kết nối trực tiếp Peer-to-Peer,nhưng thực tế nó vẫn gặp phải vấn đề NAT (Network Address Translation) gây khó khănkhi kết nối.ICE sẽ cố gắng thiết lập kết nối bằng cách tìm đường đi tốt nhất cho kếtnối.Bằng cách thử hết các khả năng song song nhau, ICE có thể chọn ra được lựa chọnhiệu quả nhất cho kết nối Đầu tiên ICE cố gắng kết nối sử dụng địa chỉ host lấy được từ

hệ điều hành hoặc card mạng Nếu thất bại nó sẽ lấy địa chỉ IP public thông qua STUNserver.Nếu vẫn thất bại, lưu lượng được gửi thông qua TURN server Các cách để kết nối

này được gọi là “candidate”, cách thức trao đổi sẽ được mô tả ở các phần bên sau

2.1.4 Một số kiến trúc của hệ thống WebRTC

Kiến trúc của một ứng dụng web cơ bản khá đơn giản.Vận chuyển thông tin giữabrowser và web server chúng ta sử dụng HTTP chạy trên giao thức TCP hoặc có thể nângcao hơn là trên Websocket Thông tin được đặt trong các đoạn mã Hyper-Text MarkupLanguage, HTML Các đoạn mã này có thể bao gồm Javascript và Cascading Style Sheets(CSS) Trường hợp phổ biến là browser gửi một yêu cầu HTTP tới webserver, tiếp đóserver sẽ xử lý yêu cầu mà browser cung cấp và đáp lại yêu cầu đó tới browser Trong một

số trường hợp phức tạp khác là server gửi server gửi Javascript chạy trên browser.Server

sẽ tương tác với browser thông qua APIs còn lại người dùng sẽ tương tác với browser

thông qua các sự kiện Browser trao đổi thông tin với server thông qua HTTP mở hoặcWebSocket

Hình 2.4 Kiến trúc của hệ thống web truyền thống

WebRTC có sự khác biệt với mô hình truyền thống là sử dụng P2P giữa các trìnhduyệt Mặc dù sử dụng mô hình P2P xong cái ứng dụng WebRTC vẫn cần một serverđứng trung gian để có trao đổi các thông tin cần thiết để hai trình duyệt có thể kết nối vớinhau Server này được gọi là signaling server, nó cần phải là một với chức năng thời gianthực (Real Time Communication hay RTC).Ngoài ra WebRTC cũng cung cấp cấp một sốAPIs để tương tác cũng như tận dụng khả năng của các trình duyệt.Hình mô tả kiến trúccủa đơn giản WebRTC

Hình 2.5 Kiến trúc phổ biến của hệ thống WebRTC

WebRTC không giới hạn kết nối giữa hai người dùng Chúng ta có khả năng kếtnối từ một người dùng đến nhiều người dùng khác.Hình mô tả có nhiều hơn hai peer đượckết nối với nhau.

Hình 2.6 Minh họa hệ thống WebRTC khi có nhiều người dùng kết nối với nhau

Như ta thấy ở hình trên, bất cứ khi nào ta muốn kết nối tới một user khác ta cần tạopeer thêm peer để kết nối với hai bên Theo hình 2.6, như ta thấy ở trên mỗi peer sẽ có 2luồng kết nối.Chúng ta cho là khi ta có 10 peer kết nối với nhau với một, chúng ta kiểmtra là mỗi peer kết nối mất khoảng 500kbps, nếu vậy 10 kết nối sẽ tốn chi phí là gần5mbps Nếu ta sử dụng mạng ADSL với băng tần 3mbps, chúng ta không thể kết nối đếntận 10 peer Thêm vào đó với sự phát triển về công nghệ như hiện nay, việc tăng trảinghiệm của người dùng khi thực hiện các kết nối là điều cần thiết (ví dụ như là ứng dụngComputer Vision hay AR trong việc stream video…).Với giới hạn về thiết bị hiện nay thậtkhó để các kết nối có thể thực hiện những điều trên Với nhu cầu đó, người ta đưa ra một ýtưởng là có một server riêng, server này có trách nhiệm trung gian chuyển/nhận các luồng

dữ liệu tới các peer Với điều này các peer chỉ cần nhận/truyền stream từ server đó Điềunày làm giảm gánh nặng cho bên phía người dùng bên bị giới hạn bởi thiết bị của mình(như là thiết bị di động, trình duyệt web…), nhất là khi có rất nhiều peer kết nối vớinhau.Server này được gọi là media server, hình dưới minh hóa kiến trúc của hệ thốngWebRTC khi thêm media server

Hình 2.7 Kiến trúc đơn giản của WebRTC khi thêm vào Media Server

Với việc thêm vào Media Server ta thấy rõ sự giảm tải giữa các peer kết nối Mỗipeer bây giờ chỉ cần giữ kết nối tới một Media Server Điều này giải quyết được vấn đề đềcập đến trước đó với 10 peer kết nối.Và với thời đại công nghệ phát triển như hiện nay,việc tăng trải nghiệm cho người dùng là một rất cần thiết và quan trọng.Vì thế với mộtserver riêng biệt chúng ta có nhiều sức mạnh hơn trong việc thực hiện các tác vụ videonâng cao tăng tương tác với người dùng.Hiện tại thì có hai loại Media Server phổ biếnđược dùng là MCU và SFU

Multipoint Controller Unit là một kiểu chiến lược cho phép tối ưu việc nhiều peerkết nối với nhau.Với MCU thay vì các peer được thiết lập kết nối với tất cả các peerkhác,nó chỉ cần thiết lập kết nối với một media server trung gian Media server này cótrách nghiệm nhận/chuyển tới các peer khác.Dưới đây hình minh họa của MCU:

Hình 2.8 Minh họa cách thức hoạt động của mô hình MCUBảng 2.1 Thống kê số peer và các luồng stream tham gia khi thực hiện theo mô hình MCU

SFU

Một cách tiếp cận khác ở đây là Select Forwarding Unit (SFU) Tương tự như MCU

có một server trung gian ở giữa, nhưng SFU có phần cải tiến hơn Thay vì phải xử lý nhiềucông đoạn như giải mã, trôn, sau đó giải mã, SFU đơn giản chỉ giải mã và gửi tới các peerkhác khi người dùng gửi một luồng stream tới.Việc này làm làm cho các luồng stream cóthể chất lượng tốt hơn do không phải trộn như media server.Và độ trễ thấp hơn khi khôngphải trải qua nhiều giai đoạn như MCU Hình dưới mô tả SFU:

Hình 2.9 Mô tả cách thức hoạt động của mô hình SFUBảng 2.2 Bảng thống kê các peer và luồng stream tham gia khi hoạt động theo mô mình SFU

Bảng 2.3 Danh sách các media server có sẵn

 Hiệu năng cao, VP8 [13] , VP9 [14], H.264 [15] và HEVC[16] thời gian thực với Intel HD Graphics

 Phân tán, dễ dàng mở rộng, MCU server

 Trộn HD video stream hiệu quả để tích kiệm băng thông và pin cho thiết bị mobile

 Có cơ chế điều khiển QoS thông minh và thích ứng với các môi trường mạng khác nhau

Janus WebRTC gateway

[17]

Janus là một WebRTC server và được phát triển bởi Meetecho

Nó bao gồm tất cả các chức năng cần thiết mà một WebRTC Media Server cần như là tương tác và trao đổi JSON với browers, đáp lại RTP/RTCP và các tin nhắn giữa phía browers

và server Browsers có thể tương tác với Junus media server để

sử dụng các chức năng của nó ví dụ như hội nghị video, cuộc gọi video trực tuyến, SIP gateways… Nó cũng được xây dựng dựa trên libsrtp và libnice sử dụng Slack ( được xây dựng dựa trên C)

Jitsi VideoBridge [18] Jitsi Videobridge là một thành phần của XMPP server.Nó cho

phép thực hiện cuộc gọi video nhóm hiệu suất cao.Jitsi cũng là một SFU và được viết bằng Java Đây là một open source với nhiều đặc tính như:

 Tính linh hoạt : vì là open source, lập trình viên có thể mở rộng các đặc tính cho ứng dụng của mình

 Khả năng mở rộng: Không cần server cấu hình cao, thậm trí

cả một CPU thấp cũng có thể sử dụng được

 Dễ dàng điều khiển: Có thể được điều khiển thông qua một

số giao thức phổ biến như HTTPS hoặc REST…

 Chất lượng tốt: Với việc chỉ gửi trả lại các luồng video mà không cần trộn nó vào Jitsi có đưa ra các luồng stream với chất lượng

 Khả năng bảo mật: Được mã hóa với DTLS/SRTP

Licode [19] Licode là một WebRTC media server được xây dựng dựa trên

WebRTC.Khởi đâu lincode định hướng xây dựng là MCU, saunày mở rộng như là SFU Licode được thực thi dựa vào C++.Một số đặc tính nổi bật của lincode như:

 Tương tác thời gian thực với các ứng dụng đa phương tiện

 Không chỉ tích hợp trong các ứng dụng web mà còn trênnhiều thiết bị khác nhau

 Tương thích với cloud và tính mở rộng hiệu quả

MediaSoup [20] Được biết đến như là phiên bảo mới nhất của dự án tăng khẳ

năng của SFU Được xây dựng Được xây dựng bằng C (sửdụng libuv) bọc với các đoạn mã Javascipt.Nhờ thiết kế theoSFU, MediaSoup cho ra hiệu năng tốt hơn và ít độ trễhơn.Thêm vào đó mang theo khả năng mở rộng cao.Các đặctính của mediasoup gồm:

 Được bóc bởi javascipt (ECMAScript) một ngôn ngữ phổbiến nhất cho cho ứng dụng web.Lập trình viên có thể dễdàng điều khiển nó

 Có thể tạo ra nhiều cuộc gọi hội hội thảo trực tuyến vớinhiều user tham gia

 Hỗ trợ TCP và UDP trên các giao thức ICE /DTLS/ RTP/RTCP

Kurento Media Server

[21]

Tương tự những cái đã giới thiệu trước đây là một WebRTCmedia server KMS được thực thi bằng C++ sử dụng thư việnGstreamer vì thế KMS xử lý được rất nhiều tác vụ video nângcao nhưng xử lý luồng một cách linh hoạt, hỗ trợ thực tế ảotăng cường (AR), phân tích và nhận diện trên video…Kurentocũng đưa ra tập hợp các API (hỗ trợ Java/Javascript/Nodejs) vàgiao thức để lập trình viên có thể tương tác với KMS một cáchđơn giản nhất Một số đặc tính nổi bật của KMS:

 Có hỗ trợ các giao thức truyền trực tuyến như là HTTP,RTP và WebRTC

 Hỗ trợ cả hai MCU,SFU

 Xử lý các tác vụ nâng cao như Computer Vision, AR

 Thiết kế kurento phù hợp để tích hợp vào môi trường cloudnhư là PaaS (Platform as a Service )

 Lập trình viên không cần biết về độ phức tạp bên trongKurento Media Server Tất cả các ứng dụng có thể đượcthực hiện bởi bất cứ công nghệ hoặc framework nào lậptrình viên muốn, từ client tới server.Từ browsers tới cloudservices

 Tự động chuyển mã các luồng media được hỗ trợ bởiGstreamer như là VP8, H.263,H.264, G.711 …

Bảng 2.4 Tóm lượt các đặc tính được hỗ trọ của các media server trên

Tên SF

U

MCU

Video

Audio

OpenSourc

e LicenseIntel CS for WebRTC     free

Junus WebRTC gateway      GPL v3Jitsi VideoBridge     Apache 2

Kurento Media Server      Apache 2

2.3 Các gói thư viện trong kurento

Như đã được đề cập trước đó kurento mang đầy đủ các tính năng mà một ứng dụng mediacần.Về cơ bản kurento cung cấp đầy đủ các gói thư viện và các giao thức cho lập trình viên sửdụng (hỗ trợ hai ngôn ngữ phổ biến là java/javascript) như là Kurento API, Kurento Protocol,

Kurento API, Kurento Utils JS, Kurento Modules

2.3.1 Kurento API

Gói thư viện này được kurento xây dựng nhằm mục đích hỗ trợ việc điều khiển KMS cách dễ dàng nhất.Bằng cách đưa ra cách API, chúng ta có thể tương tác với KMS thông qua các ngôn ngữ bậc cao như javascript hay java.Kurento đưa ra một số API có thể

kể đến ở đây như như Media Elements, Media Pipeline, Endpoint, Filter, Hub

Bảng 2 5 Danh sách các media element trên KMS [22]

 WebRtcEndpoint: Endpoint này cung cấp luồng

media thông qua web.Nó có hai khả năng nhận vàxuất các luồng media.Được xây dựng dựa trên côngnghệ WebRTC nhằm mục đích tương tác với trìnhduyệt web

 RtcEndpoint: Cũng có khả năng nhận và xuất các

luồng media.Endpoint này cung cấp tương tác vớicác peer khác hai chiều thông qua giao thức RTP(Real Time Communications) Nó sử dụng SDP đểtrao đổi các thông số cần thiết để thực hiện mediagiữa các peer

 HttpPostEndpoint: có khả năng nhận các luồng

media bằng cách sử dụng yêu cầu HTTP POST (ví

dụ như upload file…)

 PlayerEndpoint: Nhận nội dung từ file hệ thống

như là HTTP URL hoặc RTSP URL và đưa nó vàotrong media pipeline

 RecordEndpoint: Cung cấp các chức năng phục vụ

việc chưa đựng nội dung

Filters Là một thành phần của Media Elements.Nó được xây

dựng nhằm mục đích xữ lý dữ liệu media như ComputerVision , AR (Augmented Reality)…Đây cũng là điểm khác biệt của kurento so với các ưng dụng truyền thông

đa phương tiện khác Một số Filter có thể kể tới như:

 ZbarFilter: đây là một bộ lọc với mục đích nhận

diện mã QR và bar trong video stream.Khi kết quả được tìm thấy, bộ lọ sẽ trả về một sự kiện.Client có thể nghe sự kiện đó và xử lý các hành động tiếp theo

 FaceOverlayFilter: bộ lọc này nhận diện khuông

mặt trong một video stream.Nó cũng có thể ghi đè khuông mặt với hình được client thiết lập

 GstreamerFilter: bộ lọc này cho phép chúng ta mở

rộng các tính năng của filters

Hubs

Hubs chịu trách nghiệm quản lý nhiều luồng mediatrong một đường ống (pipeline).Một Hub có thể có mộtvài hub ports.Đây là tập hợp các Media Elements đượckết nối với nhau Các loại hubs có thể tới như là:

 Composite:có chức năng trộn các luồng audio của

các endpoint dữ liệu đầu vào được kết nối

 DispatcherOneToMany: Gửi dữ liệu tới tất cả đầu

ra của các thành phần được kết nối với nhau thôngqua đường ống

 Dispatcher: Là một hub cho phép định tuyến đầu

vào/ra giữa các thành phần được kết nối

2.3.3 Media Pipeline

Một Media Pipeline là một chuỗi các media element nối tiếp nhau mà ở đó cácluồng đầu ra được tạo bởi một element (source) và đưa nó vào trong một hoặc nhiều cácelement luồng đầu vào khác (sink).Dưới đây là ví dụ minh họa một Media Pipeline gồmhai thành phần là WebRtcEndpoint, WebRtcEndpoint thứ hai nhận dữ liệu từ cái thứ nhấtqua sink, sau đó gửi trả lại theo source (src) [22]

Hình 2.10 Mô tả một Media Pipeline với hai thành phần là WebRtcEndpoint đượ nối với nhau

2.3.4 Kurento Protocol

Một điểm bất lợi khi điều khiển KMS là phải sử dụng Kurento API là phải sử dụngthư viện do Kurento cung cấp (Kurento hỗ trợ hai ngôn ngữ là java và javascript) Vì thếKurento cung cấp một giao thức gọi là Kurento protocol nhằm giúp lập trình viên có thể

sử dụng bất cứ ngôn ngữ nào mà mình muốn.Kurento protocol sử dụng JSON-RPC v2.0[23] để mã hóa các tin nhắn API của nó và sử dụng websocket để vận chuyển tin nhắn đó

tới KMS, websocket này có khả năng tương tác hai chiều giữa client và server Một sốRPC mà KMS đưa ra có thể liệt kê như sau [24]:

 Ping: Được xây dựng với mục đích kiểm tra kết nối từ client tới KMS có còn

không

 Create: Mục đích là tạo một media object mới, đây có thể là pipeline hoặc media

element

 Invoke: Được xây dựng nhằm gọi một phương thức cụ thể nào đó tồn tại trong

media object (pipeline hoặc media element)

 Subscribe: lắng nghe một sự kiện nào đó từ media element.

 Unsubscribe: hủy lắng nghe sự kiện.

 Release: xóa bỏ một media object và giải phóng nó.

 OnEvent: Khi sự kiện xuất hiện, request sẽ được gửi tới client theo dõi nó.

Các yêu cầu RPC gửi tới KMS có dạng JSON như ví dụ sau:

 “jsonrpc” : Là một kiểu string dùng để xác định phiên bản của giao thức JSON-RPC

Ở đây là “2.0” vì KMS sử dụng phiên bản này

 “id” : Một giá trị định danh duy nhất được được thiết lập bởi client KMS sẽ hồi đáp

lại id có cùng giá trị với yêu cầu từ client

 “method” : Là một string chứa tên của yêu cầu được gọi.

 “params” : Mang các giá trị điều kiện mà KMS cần để thực hiện một method bất kì.

Ngoài hai cái kể trên kurento còn cung cấp một thư viện gọi là Kurento Utils Đây là một đối tượng của RTCPeerConnection.Gói thư viện này nhằm đơn giản hóa việc phát triển các ứng dụng WebRTC

2.4 Các kiến trúc phân tải của ứng dụng web

Hình 2.11 Mô tả kiến trúc phân tải tất cả trong một

Ưu điểm: Đơn giản

Nhược điểm:

 Ứng dụng và database sử dụng tranh chấp tài nguyên server (CPU,RAM,I/O…).Do đó bên cạnh việc gây ra giảm hiệu năng của hệ thống, nó còn gây khókhăn trong việc xác định thành phần nào gây ra điều đó

 Không dễ dàng cho việc mở rộng ứng dụng

2.4.2 Tách biệt riêng database server

Cách thiết lập này [25] sẽ tách riêng hệ thống database với những phần còn lại để loại bỏ việc tranh chấp tài nguyên giữa các ứng dụng và database Đồng thời tăng tính bảo mật bằng cách giấu database khỏi internet công cộng

Trường hợp sử dụng: Tốt cho việc thiết lập một ứng dụng nhanh chóng, tuy nhiên có thể

loại bỏ được việc tranh chấp tài nguyên hệ thống giữa các ứng dụng với database

Hình 2.12 Mô tả kiến trúc phân tải tách riêng database server

Ưu điểm:

 Các tầng ứng dụng và cơ sở dữ liệu không còn trang tranh chấp nguyên hệ thốngnữa (CPU, bộ nhớ, I/O…)

 Có thể mở rộng bằng cách thêm tài nguyên cho server nào cần (CPU, bộ nhớ)

 Tùy thuộc vào thiết lập, có thể tăng tính bảo mật bằng cách che giấu cơ sở dữ liệu

Nhược điểm:

 Thiết lập phức tạp hơn chút so với cách sử dụng một server duy nhất

 Có thể phát sinh các vấn đề về hiệu năng nếu kết nối mạng giữa 2 server có độ trễcao ( do khoảng cách địa lý giữa các server) hoặc bằng thông quá thấp cho việctruyền tải dữ liệu

2.4.3 Load Balancer ( Reverse Proxy)

Load Balancer [25] được thêm vào hệ thống để tăng hiệu suất của hệ thống bằng cáchphân tải ra nhiều server Nếu một server bị lỗi, các server còn lại sẽ phân chia nhau chịutải cho đến khi server kia hoạt động trở lại Nó có thể được sử dụng để cung cấp nhiều ứngdụng thông qua cùng một tên miền và cổng.Có một số phần mềm cung cấp khả năng phântải như là HAProxy, Nginx và Varnish…

Trường hợp sử dụng: Kiến trúc này hữu dụng trong môi trường đòi hỏi khả năng mở

rộng bằng cách thêm nhiều server

Hình 2.13 Mô tả kiến trúc phân tải load balancer

Ưu điểm:

 Cho phép mở rộng hệ thống bằng cách thêm nhiều server

 Có thể bảo vệ chống lại những tấn công DDOS bằng cách giới hạn kết nối clientvới một số lượng và tần số hợp lý

Nhược điểm:

 Load balancer có thể gây ra tình trạng “nghẽn cổ chai” nếu server chạy loadbalancer không được cung cấp đủ tài nguyên hoặc không được cấu hình tốt

 Nếu load balancer sập, toàn bộ dịch vụ của ta sập theo

2.4.4 HTTP Accelerator (Caching Reverse Proxy)

Một HTTP Accelerator [25], hay caching HTTP reverse proxy, có thể được sửdụng để giảm thời phục vụ của hệ thống đối với người dùng sử dụng một vài kĩ thuật khácnhau Kĩ thuật chính của phương pháp này là cache lại hồi đáp từ một web server hoặcapplication server vào trong bộ nhớ và những yêu cầu trong tương lai cùng với nội dung sẽđược cung cấp một cách nhanh chóng mà không cần tương tác với web server hoặcapplication server

Môt số phần mềm cung cấp HTTP acceleration: Vernish, Squid, Nginx

Trường hợp sự dụng: Kiến trúc này hữu dụng trong nhưng hệ thống web động năng về

nội dung hoặc với nhiều tệp được truy cập thường xuyên

Hình 2.14 Mô tả kiến trúc phân tải Accelerator

Ưu điểm:

 Tăng hiệu suất bằng cách giảm CPU tải trên web server, thông qua caching

 Có thể đóng vai trò như reverse proxy load balancer

 Một vài phần mềm caching có thể bảo vệ chống lại các cuộc tấn công DDOS

Nhược điểm:

 Cần phải tinh chỉnh để có hiệu suất tốt nhất

 Nếu tốc độ truy cập vào cache chậm, nó sẽ làm giảm hiệu năng

2.4.5 Master-Slave nhân rộng database

Một cách để tăng hiệu suất của hệ thống database thực hiện nhiều thao tác đọc ghi,

ví dụ như các hệ thống CMS, đó là sử dụng các kiến trúc Master-Slave Replication [25].Master-Slave replication yêu cầu một master và nhiều slave Master đóng vai trò ghi dữliệu còn các Slave đóng vai trò đọc dữ liệu ra Khi có dữ liệu được ghi trên master, những

dữ liệu này sau đó sẽ được đồng bộ dần lên các Slave Kiến trúc này giúp chia tải (cácthao tác đọc dữ liệu) ra nhiều server

Trường hợp sử dụng: Hữu dụng cho các hệ thống mà cần tăng tốc độ đọc ghi.

Hình 2.15 Mô tả kiến trúc phân tải Master-Slave nhân rộng database

CHƯƠNG 3 GIẢI PHÁP PHÂN CỤM CHO KURENTO MEDIA SERVER

Ở chương này ta đi trình bầy giải pháp nhằm tăng tính mở rộng cho các ứng dụngWebRTC sử dụng kurento trước đó.Trước tiên, ta bắt đầu phân tích các quy trình thựchiện một ứng dụng multimedia với kurento, các thành phần tham gia vào trong ứng dụng

và quá trình trao đổi tương tác với nhau

3.1 Các quá trình thực hiện cuộc gọi video với kurento media server

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àoWebRTC 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

Hình 3.1 Mô tả kiến trúc các thành phần tham gia vào thực hiện cuộc gọi video

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ựchiệ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ệntrao đổ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 đốitượng là peer và KMS Phần này đã được giới thiệu ở phần 2.1.4

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ộcgoi.Chi tiết về quá trình thực hiện sẽ được mô tả bên dưới

3.1.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

Hình 3.2 Mô tả quá trình đăng kí

3.1.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 đổinày được trung gian qua Signaling Server và lấy được candidate thông qua các ICE đứngbê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ọivideo

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

Hình 3.3 Mô tả quá trình bắt đầu lấy SDPKhi 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ộtthô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àinguyê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ếtnố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 đầuthô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ọivới KMS

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

Hình 3.4 Quá trình thu thập candidate từ trình duyệt và trao đổi với KMS

Quá trình này song song với quá trình đạt được SDP, mục đích của quá trình nàynhằ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ầnlà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ìnhduyệ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ếptheo trình duyệt A gửi lại cho signaling server, server này đơn giản là ủy quyền lại choKurento 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àytương tự với Peer B

Hình 3.5 Quá trình KMS trao đổi candidate với các peerQuá trình này được thực hiện khi mà WebRtcEndpoint đã được tạo ra bên trongKMS 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ửitrở 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

Hình 3.6: Quá trình kết nối với KMS và tạo các thành phần cần thiết cho việc thực hiện cuộc