.TÌM HIỂU VÀ ỨNG DỤNG WEBRTC ĐỂ TẠO ỨNG DỤNG VIDEO CALL. TS.NGUYỄN HÀ HUY CƯỜNG.

ĐẠI HỌC ĐÀ NẴNG

KHOA CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

ĐỒ ÁN CƠ SỞ 4

ĐỀ TÀI:

Tìm hiểu và ứng dụng Webrtc để
tạo ứng dụng Video Call

Sinh viên thực hiện : Võ Như Tài
Giảng viên hướng dẫn : TS. Nguyễn Hà Huy Cường
Lớp
: 17IT2

1


Đà nẵng, tháng 1 năm 2020

2


ĐẠI HỌC ĐÀ NẴNG

KHOA CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

ĐỒ ÁN CƠ SỞ 4

Tìm hiểu và ứng dụng Webrtc để tạo

ứng dụng Video Call

Đà Nẵng, tháng 1 năm 2020
1


MỞ ĐẦU

Ngày nay, trong một thế giới thông minh thì sẽ có nhiều nhu cầu đươc
đặt ra hơn, và trong đó chắc chắn sẽ có nhiều nhu cầu có thể giúp cho xã hội con
người vươn tầm lên tầm cao mới.
Là một bước đi mới khác với các đồ án kỳ trước. Lần này nôi dụng của
đồ án sẽ là Video Call – một trong những lĩnh vực được xem như là xu thế phát
triển và nâng cấp trong thời kì hiện đại… Đồ án kỳ này cũng là cũng là một cơ
hội mới để nâng cao kiến thức về lập trinh ứng dụng và tìm hiểu về các API có
trên thế giới
Việc sử dụng phương pháp Web Real-Time Communications tạo ra sự
thuận tiện việc thực hiện mục tiêu của đồ án lần này. Kết hợp với OpenTok để
tạo ra một server cho phép các người dùng có thể trao đổi video với nhau.
Và việc hoàn thành được đồ án 4 học kỳ này cũng không thể thiếu đến sự
giúp đỡ chỉ dẫn tận tình của thầy Nguyễn Hà Huy Cường - giáo viên hướng dẫn.
Người đã tạo điều kiện tốt nhất cho sự hoàn thành đề án này
Thật sự cảm ơn thầy trong thời gian qua đã hướng dẫn, định hướng hướng
phát triển cho chúng em. Chúng em xin cảm ơn!

2


NHẬN XÉT

......................................................................................................................
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
………………………………………………………

3


MỤC LỤC
Trang

Contents
Chương 1 Giới thiệu...........................................................................................9
1.1 Tổng quan................................................................................................9
1.2 Phương pháp, kết quả...............................................................................9
1.2.1 Phương pháp......................................................................................9
1.2.2 Kết quả..............................................................................................9
1.3 Cấu trúc đồ án........................................................................................10
Chương 2 Nghiên cứu tổng quan......................................................................11
2.1 Các phương pháp....................................................................................11
2.1.1 Web Real-Time Communications....................................................11
2.1.2 EasyRTC OpenSource.....................................................................12
2.2 Hạn chế, tồn tại của các phương pháp....................................................13
2.2.1 Web Real-Time Communications....................................................13
2.2.2 EasyRTC OpenSource.....................................................................13
2.3 Kết luận..................................................................................................14
Chương 3 Phân tích thiết kế hệ thống...............................................................15

3.1 Mô hình tổng quan của WebRTC...........................................................15
3.1.1 Các giao thức được sử dụng trong WebRTC....................................17
3.1.2 Các API của WebRTC......................................................................20
3.1.3 Bảo mật của WebRTC......................................................................21
3.2 Thiết kế chi tiết.......................................................................................21
Chương 4 Kết luận và Hướng phát triển...........................................................25
4.1 Kết luận..................................................................................................25
4.2 Định hướng phát triển.............................................................................25

4


DANH MỤC CÁC BẢNG
Trang
Bảng 2.1 – Bảng so sánh các phương pháp.....................................................13/14

5


DANH MỤC HÌNH

Trang
Hinh1 1: Hoạt động của WebRTC........................................................................11
Hinh1 2 : Kiến trúc tổng thể của WebRTC..........................................................15
Hinh1 3: Kiến trúc bên trong của WebRTC.........................................................16
Hinh1 4: Chồng giao thức WebRTC....................................................................17

6

DANH MỤC CỤM TỪ VIẾT TẮT
STT
1
2
3
4
5
6
7
8
9
10
11
12
13
14

Cụm từ
Web Real-Time Communication
HyperText Transfer Protocol
Voice over internet protoco
Real-time Transport Protocol
Secure RTP
Application Programming Interface
Session Description Protoco
Session Traversal Utilities for NAT
Traversal Using Relays around NAT
Interactive Communication
Establishment
User Datagram Protocol

Transport Layer Security
Stream Control Transport Protocol
Internet Protocol

7

Viết tắt
WebRTC
HTTP
VoIP
RTP
SRTP
API
SDP
STUN
TURN
ICE
UDP
TLS
SCTP
IP


Chương 1

Giới thiệu

1.1 Tổng quan
Trong bối cảnh xã hội ngày càng phát triển, đời sống mỗi con người đều
phát triển mạnh mẽ, các nhu cầu về dịch vụ cũng được nâng cao qua thời gian.

Trong đó, nhu cầu về việc liên lạc - tương tác với nhau ngày được chú ý và
phát triển mạnh mẽ. Theo lịch sử trước năm 1878, con người chủ yếu liên lạc ở
khoảng cách xa với nhau chủ yếu dựa vào bồ câu, và vận chuyển thư bằng người
tuy nhiên phương pháp này rất tốn thời gian và không đảm bảo. Sau năm 1878,
chiếc điên thoại đầu tiên ra đời cho phép truyền âm thanh ở khoảng cách xa với
tốc độ và độ chính xác cao hơn, và đặt nền móng cho việc liên lạc sau này.
Hiện này, theo dòng thời gian ta đã có thể thực hiện một cuộc gọi cách nữa
vòng Trát Đất rất dễ dàng. Tuy nhiên nhu cầu lại đc nâng lên một tầm cao mới,
mọi người đều muốn quan sát theo dõi cuộc sống hằng ngày của người mà họ yêu
thương qua những video trực tiếp , để có thế thấu hiểu hơn về đối phương.
Từ đó, việc phát triển các ứng dụng cho phép thực hiện các cuộc gọi video
luôn là vấn đề được quan tâm. Và để đáp ứng đươc nhu cầu của người người hay
còn có thể gọi là thị trường, cũng như để phục vụ cho quá trình học tập cụ thể là
Đồ án Cơ sở 4, cho nên chúng tôi đã quyết định nghiên cứu và phát triển một ứng
dụng – mô hình để cho mọi người có thể thoải mái liên lạc với nhau , cùng nhau
mang lại niềm vui hạnh phúc.
Ở đây, chúng tôi đang nghiên cứu về WebRTC, là một web API được phát triển
bởi World Wide Web Consortium, khả năng hỗ trợ trình duyệt giao tiếp với nhau
thông qua VideoCall để tạo nên một ứng dụng cho phép thực hiện các cuộc gọi
video

1.2 Phương pháp, kết quả
1.2.1 Phương pháp
Tìm hiểu WEBRTC là gì? Cách thức nó hoạt động như thế nào. Liên kết ra
sao với ngôn ngữ lập trình di động.
Chuẩn bị môi trường làm làm việc bao gồm các thiết bị cần thiết để phục
vụ cho việc lập trình đi động. Lên kế hoạch làm việc cho từng giai đoạn làm việc
để đảm bảo tiến độ dự án.
1.2.2 Kết quả
Đối với một ứng dụng trên thiết bị di dộng thì giao diện là môt phần quan

trọng không thua kém chức năng cho nên kết quả của đề tài lần này sẽ bào gồm:

8


-

Giao diện thân thiện,thuận tiện, sẵn sàng tương tác hỗ trợ người dùng
khi ứng dụng – hệ thống gặp vấn đề.
Đảm bào khả năng VideoCall luôn sẵn sàng hoạt động

1.3 Cấu trúc đồ án
-

-

Tìm hiểu và so sanh giữa hai phương pháp WebRTC và EasyRTC
Hạn chế và lợi ích của từng phương pháp
Tìm hiểu về OpenTok SDK Android
Phân tích thiết kệ hệ thống và triển khai:
o Nói rõ đến cách thức hoạt động của phương pháp được chọn
o Xây dựng mô hình hoạt động của ứng dụng.
o Tiến hành lập trình ứng dụng
Kết luận và hướng phát triển:
o Tổng kết những gì đã đạt được qua quá trình xây dựng ứng dụng
o Nêu ra những hạn chế tồn tại chưa được giải quyết
o Định ra hướng phát triển, khắc phục những hạn chế tồn tại nêu ra
trước đó

-

9


Chương 2

Nghiên cứu tổng quan

2.1 Các phương pháp
2.1.1 Web Real-Time Communications
Sơ lượt về lịch sử của WebRTC
Ý tưởng phát triển WebRTC được nhóm kỹ sư chịu trách nhiệm cho
Google Hangouts đưa ra từ tận năm 2009. Vào thời gian đó, để truyền tải video,
hình ảnh trên web thì người ta thường phải xài đến Flash. Nhóm kỹ sơ Hangouts
lại không muốn sử dụng công nghệ này, và họ bắt đầu tự làm một chuẩn riêng
cho mình. Đến năm 2010, Google thâu tóm hai công ty On2 và Global IP
Solutions (GIPS) để lấy công nghệ truyền dữ liệu thời gian thực làm nền tảng cho
WebRTC về sau.
Vào tháng 5/2011, Google ra mắt một dự án nguồn mở dành cho việc giao tiếp
thời gian thực giữa trình duyệt với nhau, và từ lúc này dự án mang tên WebRTC.
Song song đó, Hiệp hội World Wide Web (W3C) và Hiệp hội Kĩ sư quốc tế
(IETF) cũng đang phát triển một số giao thức để dùng cho việc việc kết nối thời
gian thực, thế nên họ bắt tay nhau tiếp tục hoàn thiện để rồi quyết định kết hợp
chung vào WebRTC.
Đến 27/10/2011, W3C ra mắt bản nháp đầu tiên của WebRTC. Tháng 11/2011,
Chrome 23 ra mắt, trở thành trình duyệt đầu tiên có tích hợp WebRTC ngay từ
bên trong. Và tính đến thời mà mình viết bài này thì WebRTC vẫn còn đang tiếp
tục được phát triển chứ chưa hoàn thiện một cách chính thức.
WebRTC là gì?

10


Hinh1 1: Hoạt động của WebRTC

WebRTC là viết tắt của cụm từ Web Real-Time Communication. Là một
web API được phát triển bởi World Wide Web Consortium (W3C), khả năng hỗ
trợ trình duyệt (browser) giao tiếp với nhau thông qua VideoCall, VoiceCall hay
transfer data Peer-to-Peer (P2P) mà không cần browser phải cài thêm plugins hay
phần mềm hỗ trợ nào từ bên ngoài.
WebRTC được ra đời từ năm 2011, ngay sau khi ra đời nó đã đạt được khả
năng tương tác giữa các trình duyệt Chrome và FireFox vào năm 2013 để triển
khai hỗ trợ cho điện thoại di động như Android, WebRTC đã ngày càng thu hút sự
chú ý hứa hẹn thị trường ngày càng phát triển
Ngoài ra theo dự đoán Apple và Microsoft sẽ kết hợp WebRTC trong trình
duyệt của họ và có thể có 7 tỷ thiết bị hỗ trợ WebRTC trong năm 2020. Với tốc
độ tăng trưởng mạnh mẽ việc kiểm tra để có một chiến lược cho các ứng dụng
WebRTC được hiệu quả là cần thiết.
Các thành phần chính của WebRTC và chức năng của WebRTC API ?
Các phần chính của WebRTC bao gồm:
- getUserMedia, cho phép trình duyệt web truy cập vào camera
và/hoặc microphone để lấy dữ liệu hình ảnh âm thanh cho việc
truyền tải.
-

RTCPeerConnection dùng để cài đặt videocall/voicecall dùng cho
việc truyền tải.

-

RTCDataChannel cho phép trình duyệt chia sẻ dữ liệu peer-to-peer.

WebRTC API bao gồm chức năng:
getStats cho phép ứng dụng web lấy tập hợp các số liệu thống kê
về các session WebRTC.
11


2.1.2 EasyRTC OpenSource
EasyRTC là một khung được xây dựng dựa trên WebRTC, một tiêu chuẩn
W3C / IETF mới nổi để giao tiếp thời gian thực của âm thanh, video và dữ liệu
giữa các trình duyệt web. WebRTC hỗ trợ chuyển âm thanh, video và dữ liệu trên
cơ sở ngang hàng đặt rất ít tải lên các máy chủ hỗ trợ.
Khung EasyRTC bao gồm thư viện JavaScript phía máy khách hoặc trình
duyệt và máy chủ JavaScript phụ trợ được xây dựng trên đỉnh của node.js. Bởi vì
các thư viện WebRTC được tích hợp vào mỗi trình duyệt, không cần trình cắm
trình duyệt.
Trình duyệt Chrome của Google có hỗ trợ rộng nhất cho API
WebRTC. Opera hiện đang sử dụng cùng một công cụ với Chrome và do đó bắt
chước hành vi của nó. Firefox cung cấp hỗ trợ tuyệt vời cho truyền thông dữ liệu
nhưng chỉ hỗ trợ cơ bản cho các cuộc trò chuyện video (nó thiếu khả năng đặt độ
phân giải camera, lập trình cho phép chia sẻ màn hình hoặc thu thập số liệu thống
kê).
WebRTC có tiềm năng một khi nó được chuẩn hóa hoàn toàn để hỗ trợ trò
chuyện và hội thảo bằng âm thanh và video, trò chơi nhiều người chơi và nhiều
ứng dụng dựa trên âm thanh, video và dữ liệu khác.
Như thường thấy với phần mềm, với sức mạnh đi kèm phức tạp. WebRTC
có một lộ trình học tập có khả năng cản trở việc sử dụng của các nhà phát triển
web. Để che giấu sự phức tạp đó, Priologic đã xây dựng khung EasyRTC.
Một ứng dụng WebRTC thường cần thực hiện hầu hết các bước sau.

-

Truy cập vào camera và micrô cục bộ dưới dạng "luồng phương
tiện".

-

Thiết lập kết nối đến một máy chủ báo hiệu.

-

Bắt đầu một cuộc gọi đến một người trên một trình duyệt khác.

-

Kết nối các luồng phương tiện với các thẻ video.

Sử dụng khung EasyRTC, một số bước trong số này có thể được thu gọn
thành một cuộc gọi, đơn giản hóa rất nhiều công việc của nhà phát triển, đặc biệt
nếu nhà phát triển web đang cố gắng hỗ trợ nhiều nền tảng.
Thành phần của EasyRTC OpenSource :
-

Một thư viện trình duyệt máy khách được viết bằng JavaScript. Ứng
dụng khách này xử lý tín hiệu và ở một mức độ lớn sẽ cách ly các ứng
dụng khỏi những thay đổi đang diễn ra trong api WebRTC.

12

-

Một máy chủ báo hiệu dựa trên Node.js. Node.js chạy trên các nền tảng
nhỏ như một Raspberry Pi lõi đơn (phiên bản đầu tiên) cho các máy
chủ trong đám mây.
Cùng với nhau, hai thành phần này sẽ cho phép bạn viết một ứng dụng hội
nghị video đơn giản hoặc một ứng dụng chia sẻ tệp, v.v ... chỉ trong một vài dòng
mã đơn giản.

2.2 Hạn chế, tồn tại của các phương pháp
2.2.1 Web Real-Time Communications
Như thường thấy với phần mềm, với sức mạnh đi kèm phức tạp. WebRTC
có một lộ trình học tập có khả năng cản trở việc sử dụng của các nhà phát triển
web. Để che giấu sự phức tạp đó, Priologic đã xây dựng khung EasyRTC.
Một ứng dụng WebRTC thường cần thực hiện hầu hết các bước sau.
-

Truy cập vào camera và micrô cục bộ dưới dạng "luồng phương
tiện".

-

Thiết lập kết nối đến một máy chủ báo hiệu.

-

Bắt đầu một cuộc gọi đến một người trên một trình duyệt khác.

-

Kết nối các luồng phương tiện với các thẻ video.

2.2.2 EasyRTC OpenSource
Hiện tại, máy chủ EasyRTC chạy trên một cá thể Node.js. Điều đó có nghĩa
là nó bị giới hạn bởi số lượng bộ nhớ và số lượng cổng mà đối tượng node.js có
quyền truy cập. Nó cũng chỉ có thể gửi và nhận tin nhắn rất nhanh. Số lượng
khách hàng mà nó có thể hỗ trợ có thể dao động từ hàng trăm đến hàng nghìn, tùy
thuộc vào nhu cầu ứng dụng của bạn đặt trên máy chủ. Điều này cũng có nghĩa là
máy chủ EasyRTC không mạnh như bạn muốn cho một hệ thống sản xuất. Nếu
máy chủ đang chạy quá trình máy chủ ngừng hoạt động, dịch vụ sẽ thất bại.

2.3 Kết luận
Web Real-Time Communications
Là một tập hợp các hàm lập trình

EasyRTC OpenSource

Một khung được xây dựng dựa trên
WebRTC
Không cần đăng kí tài khoản
Một máy chủ báo hiệu dựa trên Node.js
Còn được dùng để phát triển game chơi Một thư viện trình duyệt máy khách
13


trực tiếp trong trình duyệt
Thực thi hầu hết các tác vụ theo thời
gian thực
Không chỉ được dùng cho việc gọi
video giữa hai trình duyệt

Một lộ trình học tập có khả năng cản
trở việc sử dụng của các nhà phát triển
web.

được viết bằng JavaScript
Cho phép bạn viết một ứng dụng hội
nghị video đơn giản chỉ trong một vài
dòng mã đơn giản.
Bị giới hạn bởi số lượng bộ nhớ và số
lượng cổng mà đối tượng node.js có
quyền truy cập
Chỉ có thể gửi và nhận tin nhắn rất
nhanh

Bảng 1: So sanh 2 phương pháp WebRTC và EasyRTC

Mặc dù EasyRTC là một bộ khung thu gọn dựa trên WebRTC, phù hợp với
việc phát triển các hệ thống với số lượng bộ nhớ không quá lớn, hỗ trợ cho nhà
phát triển rất tốt… Nhưng để hoàn thành quá trình học tập và củng cố kiến thức
một cách chắc chắn nhất thì lựa chọn tốt nhất là bắt đầu với việc tìm hiểu và phát
triển ứng dụng trong đồ án lần này là theo phương pháp WebRTC .
Ở đồ án này chúng ta sẽ sữ dụng thêm môi trường là OpenTok.
OpenTok là nền tảng WebRTC hàng đầu cho video tương tác, cho phép
thoại, video và nhắn tin cho thiết bị di động và web với API Video trực tiếp. Bộ
giải pháp di động toàn diện nhất cho WebRTC. Tải ứng dụng di động của bạn lên
và chạy nhanh với các tính năng nâng cao, kiểm soát và hỗ trợ thiết bị rộng. Với
OpenTok, bạn có toàn quyền kiểm soát trang web hoặc ứng dụng bạn muốn.

14

Chương 3

Phân tích thiết kế hệ thống

3.1 Mô hình tổng quan của WebRTC
Cho phép truyền thông thời gian thực trong trình duyệt là một cam kết đầy
tham vọng, và có lẽ là một trong những bổ sung quan trọng nhất cho nền tảng
web từ khi được hình thành cho đến nay. Với kết quả là kiến trúc WebRTC bao
gồm rất nhiều tiêu chuẩn, giao thức và API mới để cho nó hoạt động:
 Tổ chức W3C chịu trách nhiệm định nghĩa các APIs mới của
WebRTC cho trình duyệt.
 Tổ chức IETF chịu trách nhiệm định nghĩa các giao thức, định dạng
dữ liệu, bảo mật và các khía cạnh cần thiết khác để cho phép truyền
thông peer-topeer trong trình duyệt.
Hình đưới đây mô tả kiến trúc tổng thể của WebRTC.Khối màu nhạt hơn
gọi là "chức năng truyền thông thời gian thực của trình duyệt". Chức năng này
tương tác với các ứng dụng web sử dụng các API tiêu chuẩn của WebRTC và nó
giao tiếp với hệ điều hành thông qua trình duyệt.

Hinh1 2 : Kiến trúc tổng thể của WebRTC

15


Một khía cạnh mới của WebRTC là sự tương tác xảy ra giữa trình duyệt
với trình duyệt, được biết đến nhờ một kết nối peer-to-peer, nơi mà chức năng
RTC trong một trình duyệt giao tiếp sử dụng các giao thức tiêu chuẩn trên dây
(không phải HTTP) với chức năng RTC trong một trình duyệt khác. Trong khi
truyền thôngtrên web sử dụng 12 giao thức TCP, các giao thức tiêu chuẩn trên

dây được RTC sử dụng giữa các trình duyệt có thể sử dụng giao thức truyền
UDP- User Datagram Protocol
Một cái mới nữa là máy chủ báo hiệu (signaling server) cung cấp các kênh
báo hiệu giữa các trình duyệt trong kết nối peer-to-peer.
Hình dưới đây thể hiện kiến trúc bên trong của WebRTC. Chúng ta thấy có
hai tầng riêng biệt trong WebRTC [8]: 1. Các nhà phát triển trình duyệt web (nhờ
Google Chrome hoặc Mozilla Firefox) sẽ quan tâm đến các WebRTC C ++ API
cho kết nối peer-to-peervà các API cho audio, video và vào/ra mạng theo ý của
họ. Các nhà phát triển ứng dụng web sẽ quan tâm đến các web API.

Hinh1 3: Kiến trúc bên trong của WebRTC

Ứng dụng web: là ứng dụng viết trên nền web sử dụng các JavaScript API
của WebRTCcho chức năng truyền thông thời gian thực như chia sẻ video, audio
chat, chia sẻ file.
WebRTC JavaScript API: là các API được xây dựng bởi các nhà phát triển
trình duyệt web theo tiêu chuẩn được quy định bởi tổ chức W3C. Các API này
được các nhà 13 phát triển ứng dụng web sử dụng để viết ra các ứng dụng web có
sử dụng chức năng truyền thông thời gian thực.
16


WebRTC C++ API: là một lớp API bên trong của WebRTC được các nhà
phát triển trình duyệt web sử dụng để dễ dàng thực hiện các WebRTC JavaScript
API. Khối giao vận: đảm nhiệm việc thiết lập kết nối qua các mô hình mạng khác
nhau sử dụng STUN, TURN và ICE, đồng thời thực hiện việc dồn kênh và thực
hiện chức năng truyền thông thời gian thực. VideoEngine: là một framework xử
lý chuỗi khung hình video, từ máy ảnh vào mạng, và từ mạng tới màn hình hiển
thị.VideoEngine trong WebRTC sử dụng VP8 video codec, đây là một định dạng
video mở, chất lượng cao và miễn phí cho nền tảng web được phát triển từ dự án

WebM - VideoEngine cũng sử dụng bộ đệm jitter
động cho video, nó giúp che giấu những ảnh hưởng của hiện tượng jitter và mất
gói tin đến chất lượng hình ảnh tổng thể. Ngoài ra Video Engine còn có bộ tăng
cường ảnh, giúp loại bỏ nhiễu cho các hình ảnh thu được từ webcam.
Voice Engine: là một framework xử lý chuỗi âm thanh từ card âm thanh vào
mạng. Nó sử dụng iSAC, iLBC và Opus audio codec và sử dụng bộ đệm jitter động để
che giấu những tác động của hiện tượng jitter và việc mất gói tin, trong khi giữ độ trễ
thấp nhất có thể và duy trì chất lượng âm thanh cao nhất. Voice Engine cũng sử dụng bộ
khử tiếng vọng và bộ giảm tiếng ồn để nâng cao chất lượng đàm thoại.

3.1.1 Các giao thức được sử dụng trong WebRTC

Hinh1 4: Chồng giao thức WebRTC

Giao thức HTTP (Hyper-Text Transport Protocol):
WebRTC sử dụng giao thức HTTP - Hyper-Text Transport Protocol giống
như bất kỳ ứng dụng web nào, vì vậy không cần một kiến thức đặc biệt nào về
HTTP. Phiên bản hiện tại của HTTP là 1.1. IETF đang làm việc để định nghĩa
phiên bản tiếp theo của HTTP, được gọi là 2.0. Giao thức này sẽ có khả năng tăng
tốc độ và hiệu quả tải web và các ứng dụng. WebRTC sẽ có thể sử dụng giao thức
này và bất kỳ phiên bản khác trong tương lai của HTTP.
Giao thức WebSocket:

17


WebSocket là một giao thức cung cấp các kênh truyền thông song công
hoàn toàn thông qua một kết nối TCP duy nhất .WebSocket làm cho giao tiếp thời
gian thực hiệu quả hơn vì nó giảm thiểu độ trễ để gửi/nhận thông báo giữa hai
phía của kết nối .WebRTC sử dụng WebSocket để trao đổi thông báo giữa các

trình duyệt với nhau và giữa các trình duyệt với máy chủ web để thiết lập, duy trì
và ngắt kết nối
RTP và SRTP
Giao thức quan trọng nhất được sử dụng bởi WebRTC là RTP - Real-time
Transport Protocol. WebRTC chỉ sử dụng phiên bản an toàn của RTP gọi là SRTP
- Secure RTP. SRTP là giao thức được sử dụng để vận chuyển và mang các gói tin
audio và video media giữa các WebRTC client. Các gói tin media chứa các audio
hoặc các khung hình video được số hóa được tạo ra bởi một microphone hoặc
máy ảnh hoặc ứng dụng, và được dựng lại bởi loa hoặc màn hình hiển thị. Một
thiết lập thành công một kết nối peer, cùng với việc hoàn thành trao đổi một cặp
offer/answer sẽ dẫn đến một kết nối SRTP được thiết lập giữa các trình duyệt
hoặc một trình duyệt và một máy chủ, và trao đổi thông tin media. SRTP cung
cấp thông tin cần thiết để vận chuyển thành công và dựng hình thông tin media:
các codec (coder/decoder được sử dụng để lấy mẫu và nén audio hoặc video),
nguồn của các media (nguồn đồng bộ hóa hoặc SSRC), một dấu thời gian, số thứ
tự (để phát hiện mất các gói dữ liệu), và các thông tin khác cần thiết để phát lại.
Đối với dữ liệu không phải là audio hoặc video, SRTP không được sử dụng. Thay
vào đó, một cuộc gọi đến API RTCDataChannel sẽ dẫn đến một kênh dữ liệu
được mở ra giữa các trình duyệt cho phép bất kỳ định dạng dữ liệu được trao đổi.
SDP:
Mô tả phiên WebRTC được mô tả bằng cách sử dụng SDP - Session
Description Protocol. Một mô tả phiên SDP (mã hóa nhờ là một đối tượng
RTCSessionDescription) được sử dụng để mô tả các đặc điểm media của kết nối
peer . Có một danh sách dài và phức tạp của thông tin cần phải được trao đổi giữa
hai đầu của phiên SRTP để chúng có thể giao tiếp. Lời gọi API đến
RTCPeerConnection sẽ cho kết quả là một mô tả phiên SDP, một tập định dạng
dữ liệu theo cách đặc biệt, được tạo ra bởi các trình duyệt và truy cập bằng cách
sử dụng JavaScript bởi các ứng dụng web. Một ứng dụng muốn có kiểm soát
media chặt chẽ hơn có thể thay đổi các mô tả phiên trước khi chia sẻ nó với trình
duyệt khác. Khi các thay đổi được thực hiện cho một kết nối peer, điều này sẽ dẫn

đến thay đổi mô tả phiên mà hai bên sẽ trao đổi. Điều này được gọi là một trao
đổi offer/answer. Bất kỳ nhà phát triển nào có nhu cầu kiểm soát các phiên media
chi tiết hơn cần phải hiểu về SDP. Cả SRTP và SDP là hai giao thức được chuẩn
hóa bởi IETF và được sử dụng rộng rãi bởi các thiết bị và dịch vụ truyền thông
trên Internet, chẳng hạn nhờ điện thoại VoIP, các gateways, hội nghị truyền hình
và các thiết bị hợp tác khác. Kết quả là, thông tin liên lạc giữa một trong những
thiết bị và một WebRTC client là có thể được. Tuy nhiên, rất ít các thiết bị VoIP
hoặc video hiện nay hỗ trợ đầy đủ các khả năng và các giao thức của WebRTC.
Các thiết bị này sẽ cần phải được nâng cấp để hỗ trợ các giao thức mới, hoặc một
chức năng gateway được sử dụng giữa WebRTC client và VoIP hoặc video client
để làm việc chuyển đổi.
18


STUN:
STUN - Session Traversal Utilities for NAT - là một giao thức đƣợc sử
dụng để giúp đi qua NAT. Trong WebRTC, một STUN client đƣợc xây dựng sẵn
trong user agent của trình duyệt, và các máy chủ web sẽ chạy một máy chủ
STUN. Gói tin kiểm tra STUN được gửi trước khi thiết lập phiên để cho phép
trình duyệt biết nếu nó đang ở đằng sau một NAT và để khám phá các địa chỉ ánh
xạ và cổng của nó. Thông tin này sau đó được sử dụng để xây dựng các địa chỉ
ứng cử viên trong kỹ thuật ICE "hole punching". STUN có thể đƣợc vận chuyển
qua UDP, TCP, hoặc TLS
TURN:
TURN - Traversal Using Relays around NAT - là một mở rộng của giao
thức STUN, nó cung cấp một chuyển tiếp media cho các trường hợp mà ICE
"hole punching" thất bại. Trong WebRTC, các user agent trong trình duyệt sẽ bao
gồm một TURN client, và một máy chủ web sẽ cung cấp một máy chủ TURN.
Trình duyệt yêu cầu một địa chỉ IP công cộng và số cổng nhờ một địa chỉ chuyển
tiếp vận chuyển từ máy chủ TURN. Địa chỉ này sau đó được bao gồm nhƣ là một

địa chỉ ứng cử viên trong ICE "hole punching". TURN cũng có thể đƣợc sử dụng
để đi qua tường lửa. TURN có thể được sử dụng để thiết lập địa chỉ vận chuyển
chuyển tiếp sử dụng UDP, TCP, hoặc TLS. Tuy nhiên, thông tin liên lạc giữa các
máy chủ TURN và TURN client (thông qua NAT) luôn luôn là UDP.
ICE:
ICE - Interactive Communication Establishment - là một giao thức được
tiêu chuẩn hóa bởi IETF (RFC- 5245) [17]. Giao thức ICE đƣợc dùng để thiết lập
phiên media dựa trên UDP đi qua NAT. ICE cố gắng tìm ra con đƣờng tốt nhất để
kết nối giữa các peer, nó thử tất cả các khả năng có thể kết nối một cách song
song và lựa chọn một con đƣờngkết nối hiệu quả nhất. ICE đầu tiên cố gắng để
tạo ra một kết nối bằng cách sử dụng địa chỉ thu đƣợc từ hệ điều hành và card
mạng của thiết bị; nếu thất bại (có thể do thiết bị ở đằng sau một NAT), ICE lấy
địa chỉ bên ngoài của thiết bị bằng cách sử dụng một máy chủ STUN, và nếu
không thành công, lưu lượng mạng được chuyển qua một máy chủ chuyển tiếp
TURN. ICE được chạy vào lúc bắt đầu của một phiên trước khi thiết lập phiên
SRTP giữa các trình duyệt. Nó cũng được sử dụng để thiết lập các kênh dữ liệu
không media
TLS:
TLS - Transport Layer Security (các phiên bản cũ đƣợc gọi là SSL Secure Sockets Layer), là một lớp chèngiữa TCP và các ứng dụng cung cấp các
dịch vụ bảo mật và xác thực. Bảo mật được cung cấp bằng cách mã hóa các gói
tin "trên dây". Xác thực được cung cấp bằng cách sử dụng giấy chứng nhận kỹ
thuật số. Duyệt web an toàn ngày nay (HTTPS) chỉ sử dụng vận chuyển TLS.
WebRTC có thể tận dụng lợi thế của TLS cho báo hiệu và bảo mật giao diện
19


người dùng. Ngoài ra còn có một phiên bản của TLS chạy trên UDP, đƣợc gọi là
DTLS - Datagram TLS, và một phiên bản có thể được sử dụng để tạo ra các khóa
cho SRTP được gọi là DTLS-SRTP
TCP:

Giao thức TCP - Transmission Control Protocol - là một giao thức lớp vận
chuyển trong chồng giao thức IP, nó cung cấp vận chuyển đáng tin cậy với kiểm
soát tắc nghẽn và kiểm soát luồng. TCP được sử dụng để vận chuyển trên web
(HTTP), nhƣng không phù hợp để thực hiện truyền thông thời gian thực nhờ
trong RTP, tại vì việc truyền tải lại được sử dụng để đảm bảo độ tin cậy tạo ra sự
chậm trễ quá lâu. Giống nhƣ trong UDP, TCP sử dụng một khái niệm về cổng,
một số nguyên 16-bit, để tách riêng các luồng và các giao thức. TCP được cung
cấp bởi hệ điều hành ở bên dưới trình duyệt
DTLS:
DTLS- là một phiên bản của TLS chạy UDP, nó cung cấp tính bảo mật và
xác thực tương tự như trong TLS. UDP đi qua NAT dễ dàng hơn và có thể
phù hợp hơn cho các ứng dụng peer-to-peer.
UDP:
UDP - User Datagram Protocol - là một giao thức lớp vận chuyển trong
chồng giao thức IP cung cấp dịch vụ gói tin không đáng tin cậy cho các lớp phía
trên. UDP thường đƣợc sử dụng để vận chuyển trao đổi gói tin nhỏ và ngắn (ví
dụ các gói tin DNS) hoặc để vận chuyển media thời gian thực nhƣ là RTP. UDP
được cung cấp để trao đổi thông tinrất nhanh và hiệu quả; tuy nhiên, người sử
dụng UDP phải đối phó với khả năng mất gói tin. Ngoài ra, UDP không có kiểm
soát tắc nghẽn, vì vậy người sử dụng phải nhạy cảm với việc mất gói tin và tắc
nghẽn để tránh làm quá tải các kết nối Internet. Giống như TCP, UDP sử dụng
khái niệm về cổng, một số nguyên 16-bit, để phân tách các luồng và các giao thức
SCTP:
SCTP - Stream Control Transport Protocol –là một tiêu chuẩn của IETF
(RFC 4960) nằm ở tầng chuyên vận, nó cung cấp vận chuyển đáng tin cậy hoặc
không đáng tin cậy trên IP cùng với việc kiểm soát tắc nghẽn và nhiều dòng trong
một phiên. Kiểm soát tắc nghẽn là khả năng của một giao thức để cảm nhận được
khi mất gói tin Internet và sự chậm trễ, và tự động điều chỉnh tốc độ gửi của mình
để giảm thiểu những tác động. Nhiều dòng trong một phiên cho phép một phiên
duy nhất được phân chia thành một số dòng, mỗi dòng trong số đó có thể chia sẻ

băng thông sẵn có trong phiên một cách công bằng.
SCTP không được hỗ trợ phổ biến trong các hệ điều hành, do đó các trình
duyệt sẽ có riêng chồng giao thức SCTP của chúng đƣợc xây dựng sẵn cho kênh
dữ liệu
IP:
20


IP - Internet Protocol - là giao thức lớp mạng làm nền tảng cho Internet. IP
phiên bản 4, IPv4, phiên bản hiện tại, đang bị hết địa chỉ định danh duy nhất,
được gọi là địa chỉ IP. IP phiên bản 6, IPv6 đã được định nghĩa để mở rộng đáng
kể không gian địa chỉ để cho phép Internet tiếp tục đà tăng trưởng phi thường của
nó trong thế kỷ 21. Thật không may, hỗ trợ và triển khai IPv6 vẫn tiếp tục được
tiến hành chậm chạp mặc dù mạng xương sống Internet và nhiều dịch vụ và các
Website hiện đang hỗ trợ nó. Ngày nay, không phải tất cả các nhà cung cấp dịch
vụ Internet (ISP) hỗ trợ IPv6. Đàm phán media và dữ liệu truyền tải trên các
phiên bản khác nhau của IP có thể đƣợc thực hiện bằng cách sử dụng ICE
3.1.2 Các API của WebRTC
Các ứng dụng sử dụng WebRTC thƣờng cần làm những việc sau:
 Lấy các dòng audio, video hoặc dữ liệu khác.
 Lấy thông tin về mạng nhờ địa chỉ IP và cổng, và trao đổi với khách
hàng WebRTC khác (peer) để cho phép kết nối, thậm chí kết nối qua
NAT và tường lửa.
 Phối hợp tín hiệu thông tin liên lạc để báo lỗi và bắt đầu hoặc kết
thúc phiên.
 Trao đổi thông tin về media và khả năng của khách hàng, chẳng hạn
như độ phân giải và codec.
 Giao tiếp thời gian thực với audio, video và dữ liệu.
Để lấy được và truyền các dòng dữ liệu, WebRTC thực hiện các API sau đây:
-

MediaStream: tiếp cận với dòng dữ liệu, chẳng hạn nhƣ từ máy ảnh
và microphonecủa ngƣời dùng

-

RTCPeerConnection: thực hiện các cuộc gọi audio hoặc video, với
hỗ trợ cho việc mã hóa và quản lý băng thông.

-

RTCDataChannel: truyền dữ liệu bất kỳ thông qua giao tiếp peerto-peer (gửi tin nhắn văn bản, gửi file, trò chơi trực tuyến…)

3.1.3 Bảo mật của WebRTC
Có một số nguyên nhân chính dẫn đến một ứng dụng thông tin liên lạc thời
gian thực có thể bị lỗi bảo mật:
21


-

Media hoặc dữ liệu không được mã hóa có thể bị can thiệp
trên đƣờng truyền giữa các trình duyệt.

-

Một ứng dụng có thể ghi lại và phân phối video hoặc audio
mà ngƣời sử dụng không biết.

WebRTC có một số tính năng để tránh những vấn đề bảo mật này:

-

WebRTC đƣợc triển khai sử dụng giao thức an toàn nhƣ
DTLS và SRTP
Mã hóa là bắt buộc đối với tất cả các thành phần WebRTC,
bao gồm cả cơ chế truyền báo hiệu.
WebRTC không phải là một plugin: các thành phần của nó
chạy bên trong trình duyệt và không phải trong một tiến
trình riêng biệt. Các thành phần WebRTC không yêu cầu cài
đặt riêng biệt và đƣợc cập nhật bất cứ khi nào trình duyệt
được cập nhật.

3.2 Thiết kế chi tiết
Ở ứng dụng lần này em sử dụng OpenTok Android SDK .

Opentok sẽ dựa vào nền tảng webRTC để gửi các gói tin đa phương tiện
qua javascript giúp tạo một streaming để chat. TODO: Có thể tìm hiểu qua
opentok sdk cho mobile app video.
Ứng dụng gồm có 2 phần chính:
- Phía client-side , sử dụng OpenTok SDK Cient và
chạy trong trình duyệt hoặc ứng dụng di động của
người dùng

-

Phía server-side , sử dụng OpenTok SDK Server và
chạy trên máy chủ của bạn để truyền thông tin xác
thực cho máy client.

SDK Client để xây dựng ứng dụng Android là SDK Android

OpenTok, cung cấp hầu hết các chức năng cốt lõi cho ứng
dụng của bạn, bao gồm:
-

Kết nối tới OpenTok session

-

Xuất bản đến một session

-

Đăng ký luồng trong một session
22


Client SDKs cũng có sẵn cho iOS và web. Tất cả các SDK khách OpenTok có thể
tương tác với nhau.
Các bước thực hiện:
1. Để kết nối với OpenTok session, khách hàng sẽ cần quyền truy cập
vào một số thông tin xác thực: API key, session ID, và token .

2. Yêu cầu quyền truy cập âm thanh và video
Vì ứng dụng của chúng tôi sử dụng âm thanh và video từ thiết
bị của người dùng, chúng tôi sẽ cần thêm một số mã để yêu cầu quyền
âm thanh và video. Chúng tôi sẽ sử dụng thư viện EasyPermissions để
làm điều này.

3. Kết nối đến Session
Tiếp theo, chúng tôi sẽ kết nối với OpenTok Sesion . Bạn

phải làm điều này trước khi bạn có thể xuất bản luồng video âm
thanh của mình lên phiên hoặc xem các luồng người tham gia khác.

Sesion class được định nghĩa trong SDK Android
OpenTok. Nó đại diện cho một OpenTok session và bao gồm các
phương thức để tương tác với phiên.

23