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

ĐẠ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ệu tham
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ôi xin 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
STT
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

Từ viết tắt
WebRTC
KMS
HTTP
CSS
NAT
STUN
TURN

P2P
HTML
UDP
API
JSON
JSON-RPC
GCP
REST
SIP

Cụm từ tiếng anh
Web Real-Time Communication

Kurento Media Server
Hypertext Transfer Protocol
Cascading Resource Locator
Network Address Translation
Session Traversal Utilities for NAT
Traversal Using Relays around NAT
Peer-to-Peer
Hyper-Text Markup Language
User Datagram Protocol
Application Programming Interface
Javasript Object Notation
Javasript Object Notation – Remote Procedure Call
Google Cloud Platform
Representational State Transfer
Session Initiation Protocol

7

DANH MỤC HÌNH VẼ

DANH MỤC BẢNG

8


9


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ụng cá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ày nà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ũng cầ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ơn nhằ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ộng nghệ thực tế ảo
tăng cường ( AR ), Computer Vision … Một số ứng dụng nổi tiếng thực hiệ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ện
phả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ằm giú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ểm riê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ảng mạ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ện các ứng dụng
multimedia.

Kurento với phần lõi là Kurento Media Server, đây là một media server được xây dự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ực tiế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àm cho 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 ứng dụng
multimedia khi sử dụng với kurento thường được được đi kèm với một Kurento Media 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ăng củ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ều chỉ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ảo giữ 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 demo khi thực

10


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.

11


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ải thờ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ông chỉ 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ệt khá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 web thự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ời gian
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 IP Solutions

( GIPS), đây là một công ty phần mềm về VoIP và video hội họp (công ty này cũ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ết tớ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ể đến như [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ùng Flash,
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.

12


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ông thờ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ình duyệ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áy tí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ệu
media.Đ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 WebRTC thì 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ều nà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ăng thông hiệu quả
hơn.Các APIs WebRTC và signaling có thể thỏa thuận kích thứ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ệt phả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ụng trong
WebRTC được thể hiện ở hình dưới:

Hình 2.1 Protocol stack trong WebRTC [3]

13


SRTP
SRTP (Secure Real Time Protocol) [4] được sử dụng để mã hóa và chuyển các gói tin
media giữa các WebRTC client.Sau khi thiết lập thành công PeerConnection,kết nối SRTP 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.
SCTP
WebRTC sử dụng SCTP (Stream Control Tranmission Protocol) [5] để truyền dữ liệu
non-media giữa các peer. Giao thức SCTP là giao thức vận chuyển tương tự như TCP và
UDP,có thể chạy trực tiếp trên giao thức IP. SCTP được lựa chọn do có những tính năng tốt
của TCP và UDP như message-oriented transmission, khả năng cấu hình tùy biến tính tin cậy
và thứ tự gói tin, có cơ chế quản lý lưu lượng và chống nghẽn.
DTLS
Datagram Transport Layer Security- DTLS [6] giao thức này cung cấp tính năng bả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ụng DTLS.
STUN
NAT [7] cung cấp một địa chỉ IP để sử dụng trong mạng nội bộ. Nhưng địa chỉ này
không được sử dụng bên ngoài mạng. Không biết địa chỉ công khai sẽ không có cách nào để
hai Peer có thể tương tác. Để giải quyết vấn đề đó WebRTC sử dụng STUN (Session 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ác peer 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ách làm việc của STUN server:

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

14


TURN
Traversal Using Relays around NAT (TURN) [9]. Được xây dựng nhằm vượt qua
symmetric 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 tin thông
qua server này (dữ liệu audio/video/data streaming giữa các peer, không phải signaling
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ối

như 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ểu nhau
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ập kế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ăn khi 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ết nố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ọn hiệ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 STUN server.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ữa
browser và web server chúng ta sử dụng HTTP chạy trên giao thức TCP hoặc có thể nâng cao

15


hơn là trên Websocket. Thông tin được đặt trong các đoạn mã Hyper-Text Markup Language,
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ặc WebSocket .

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ình
duyệ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ới nhau.
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 gian thự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úc của đơn giản
WebRTC

16


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ết nố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 được kế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ạo
peer 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ó 2
luồ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ểm tra 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ần 5mbps. 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 đến tậ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ải nghiệm của người dùng khi

17


thực hiện các kết nối là điều cần thiết (ví dụ như là ứng dụng Computer Vision hay AR trong
việc stream video…).Với giới hạn về thiết bị hiện nay thật khó để 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ều nà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ới nhau.Server này được gọi là media server, hình dưới
minh hóa kiến trúc của hệ thống WebRTC 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ỗi peer
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ột server 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ụ video nâ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.

18


MCU
Multipoint Controller Unit là một kiểu chiến lược cho phép tối ưu việc nhiều peer kế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 peer khá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 MCU
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
Streams/ngườ
Tổng cộng
Người dùng
i dùng

n
2
2n
Với một media server ở giữa ta có thể nhận thấy sự giảm phụ thuộc vào các peer kết nối
với nhau.Về cơ bản MCU nhận tất cả stream từ tất cả các peer, giải mã các stream này và sau
đó tạo một layout trộn lẫn tất cả các stream này. Cuối cùng nó giải mã và gửi đến tất cả các
peer khác. Ưu điểm của MCU là đơn giản và tránh được vấn đề về hiệu suất khi có nhiều peer
kết nối.Nhưng một điều ta có thể nhận thấy ở đây là MCU trộn lẫn các luồng stream với nhau,
điều này dẫn đến việc chúng ta khó có thể có được những luồng stream nguyên dạng ban đầu
( có thể chất lượng video kém hơn) hoặc có một vài độ trễ khi sử dụng. Một điều không tránh
khỏi là thêm một server đứng giữa rất tốn kém. Bên cạnh đó media server phải mã hóa và giải
mã lên tốn khá nhiều tài nguyên hệ thống như băng thông,CPU.
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ều công

19


đ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 peer khá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ông phả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 SFU
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
Người
dùng
n

Streams/ngư
ời dùng
n

Tổng cộng
n2

2.2. Một số media server có sẵn
Như đã đề cập đến ở trên một media server là rất cần cho việc quản lý các luồng stream
một cách hiệu quả.Nhưng vấn đề đặt ra ở đây là xây dựng một media server rất phức tạp và
đòi hỏi tốc độ cao xử lý.Vì thế cần phải sử dụng một số ngôn ngữ bậc thấp và rất khó để cho
lập trình viên có thể xây dựng.Từ nhu cầu đó chúng ta có được một số open source giúp cho
việc xây dựng một hệ thống WebRTC trở lên hiểu quả và dễ dàng. Một trong sốc các media
server có thể thấy ở bẳng dưới đây bao gồm Intel Collaboration Suite for WebRTC (Intel CS
for WebRTC), Janus WebRTC gateway, Jitsi VideoBridge, Lincode, MediaSoup, Kurento
Media Server…

20


Bảng 2.3. Danh sách các media server có sẵn
Tên
Mô tả
Intel CS for WebRTC Được hình thành dưới sự hợp tác giữa Intel và South Korean
[12]
telecommunication (SK telecom ). Họ hỗ trợ bao gồm client
SDKs (JS/ Android/ IOS / Windows), server SDKs (SFU/
MCU/ SIP Gateway). Cũng đồng nghĩa với việc có mọi thức
cần cho một ứng dụng media và được đóng goi sẵn. Media
Server này cũng được xây dựng dựa trên Licode (giới thiệu ở

dưới ).Một số đặc tính nó như:
• 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 Janus là một WebRTC server và được phát triển bởi Meetecho.
[17]
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, sau
nà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ên

21


nhiề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ế theo
SFU, 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 đặc
tí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ới

nhiều user tham gia.
• Hỗ trợ TCP và UDP trên các giao thức ICE /DTLS/ RTP/
RTCP
Kurento Media Server Tương tự những cái đã giới thiệu trước đây là một WebRTC
[21]
media server. KMS được thực thi bằng C++ sử dụng thư viện
Gstreamer vì thế KMS xử lý được rất nhiều tác vụ video nâng
cao nhưng xử lý luồng một cách linh hoạt, hỗ trợ thực tế ảo
tăng cường (AR), phân tích và nhận diện trên video…Kurento
cũ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 cloud
như 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 trong
Kurento Media Server. Tất cả các ứng dụng có thể được
thực hiện bởi bất cứ công nghệ hoặc framework nào lập
trình viên muốn, từ client tới server.Từ browsers tới cloud
services
• Tự động chuyển mã các luồng media được hỗ trợ bởi
Gstreamer 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
Intel CS for WebRTC
Junus WebRTC gateway

Jitsi VideoBridge
Licode
MediaSoup
Kurento Media Server

SF
U







MC
U









Audi
o












Video

22

OpenSourc
e






License
free
GPL v3
Apache 2
MIT
ISC
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 media cầ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

2.3.2 Media Element
Là tập hợp các thành phần có một chức năng cụ thể nào đó được kurento cung cấp.
Lợi ích khi sử dụng nó là lập trình viên sẽ không cần biết nó được xử lý cụ thể như nào.Nhìn
chung một các media element đều có khẳ năng nhận/gửi dữ liệu media từ các media element
khác.Kurento phân loại thành bốn nhóm thành phần chính như là Endpoint, Filters, Hubs,
Output Endpoints … các thành phần cụ thể được miêu tả ở bảng dưới.
Bảng 2. 5 Danh sách các media element trên KMS [22]
Tên thành phần
Endpoints

Mô tả
Nhìn chung thành phần này có khả năng nhận dữ liệu
/đưa dữ liệu media theo nhiều tài nguyên khác nhau như
là file, từ mạng và có trực tiếp từ ảnh chụp từ camera
hoặc các thiết bị phần cứng khác.Một số Endpoint có
thể kể đến là:
• 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ông

nghệ WebRTC nhằm mục đích tương tác với trình
duyệ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ới
cá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 media
giữ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ào
trong media pipeline.
• RecordEndpoint: Cung cấp các chức năng phục vụ

23


Filters

Hubs

việc chưa đựng nội dung.
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ư Computer
Vision , 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 chịu trách nghiệm quản lý nhiều luồng media
trong một đường ống (pipeline).Một Hub có thể có một
vài hub ports.Đây là tập hợp các Media Elements được
kế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ông
qua đườ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ác luồ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ác element
luồng đầu vào khác (sink).Dưới đây là ví dụ minh họa một Media Pipeline gồm hai thành
phần là WebRtcEndpoint, WebRtcEndpoint thứ hai nhận dữ liệu từ cái thứ nhất qua 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

24

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ụng thư
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": "2.0",
"id": 1,
"method": "create",
"params": {
"type": "PlayerEndpoint",
"constructorParams": {
"pipeline": "6829986",
"uri": "http://host/app/video.mp4"
},
"sessionId": "c93e5bf0-4fd0-4888-9411-765ff5d89b93"
}
}
• “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ì.

25