ĐỒ ÁN CƠ SỞ 4 ĐỀ TÀI: Xây dựng ứng dụng hội nghị trựctuyến (trên nền tảng Web RTC). Giảng viên hướng dẫn : TS.TRẦN THẾ SƠN

ĐẠI HỌC ĐÀ NẴNG

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ
TRUYỀN THÔNG VIỆT - HÀN

ĐỒ ÁN CƠ SỞ 4
ĐỀ TÀI: Xây dựng ứng dụng hội nghị trực
tuyến (trên nền tảng Web RTC)

Sinh viên thực hiện :
Giảng viên hướng dẫn :

THÁI VĂN LÂM
HOÀNG ĐĂNG KHÁNH
TS. TRẦN THẾ SƠN

Lớp :

17IT3


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


ĐẠI HỌC ĐÀ NẴNG

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

ĐỒ ÁN CƠ SỞ 4
Xây dựng ứng dụng hội nghị trực tuyến (trên
nền tảng Web RTC)

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

1


MỞ ĐẦU

Ngày nay,tổ chức các buổi hội nghị trực tuyến là một nhu cầu cấp thiết
hiện nay đặc biệt trước diễn biến phức tạp của đại dịch toàn cầu covid-19
làm hạn chế việc gặp mặt trực tiếp hoặc tập trung đơng người.Thực tế, có
nhiều ứng dụng hiện nay cho phép tổ chức hội nghị trực tuyến như:
Google Meet, Zoom cloud Meeting……Ví dụ như ứng dụng Google
Meet và Zoom cloud Meeting hiện tại lần lượt đã có lên đến hơn
100.000.000 và 500.000.000 người dùng cài đặt sử dụng và hơn 950 000
và 1.480.000 người đánh giá trung bình 3,3 sao và 3,6 sao cho 2 ứng dụng
này trên Google Play.Dựa trên số liệu trên có thể thấy ứng dụng hội nghị
trực tuyến đang được rất nhiều người sử dụng hiện nay. Nhằm nghiên cứu
về hệ thống này và làm chủ công nghệ hội nghị trực tuyến, đề tài này tập
trung nghiên cứu và xây dựng ứng dụng web hội nghị trực tuyến dựa trên
công nghệ Web RTC.

2


LỜI CẢM ƠN
Kính gửi đến thầy hướng dẫn đồ án 4 là Tiến sĩ Trần Thế Sơn. Nhóm chúng em bao
gồm Hoàng Đăng Khánh và Thái Văn Lâm , sinh viên Khoa Công nghệ thông tin và
truyền thông – Đại học Đà Nẵng. Sau 1 kì học được sự hướng dẫn của thầy , chúng
em đã biết và tìm hiểu nhiều hơn về các giao thức và hoàn thiện một sản phẩm. Chúng

em đã có thể vận dụng được những kiến thức thầy đã hướng dẫn để áp dụng vào demo
sản phẩm cho mơn học đồ án này.Nhóm chúng em xin chân thành cảm ơn thầy.

3


NHẬN XÉT
(Của giảng viên hướng dẫn)

…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………

4


MỤC LỤC
Trang
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.3 Cấu trúc đồ án.............................................................................................10
Chương 2 GIỚI THIỆU VỀ WEBRTC.................................................................11
2.1 WebRTC là gì?............................................................................................11
2.2 Lợi ích của WebRTC...................................................................................11
2.3 WebRTC dùng để làm gì ?..........................................................................12
2.4 Giao tiếp Peer-To-Peer................................................................................12
2.5 Tường lửa và NAT Traversal.......................................................................13
2.6 Signaling, Sessions......................................................................................14
2.7 WebRTC’s protocols...................................................................................15
2.8 Media server...............................................................................................17
2.9 Các API của WebRTC.................................................................................18
Chương 3 CÁC BƯỚC TẠO RA WEBRTC.........................................................19
3.1 Bắt đầu với Media devices..........................................................................19
3.2 Nắm bắt phương tiện và các ràng buộc.......................................................21
3.3 Bắt đầu với Peer-connection.......................................................................22
3.4 Bắt đầu với Media Stream...........................................................................25
3.5 Kênh dữ liệu................................................................................................26
3.6 TURN máy chủ...........................................................................................28
Chương 4 Phân tích thiết kế hệ thống...................................................................29
4.1 Mơ hình tổng quan của WebRTC................................................................29
4.2 Kiến trúc WebRTC......................................................................................29
Chương 5 Demo sản phẩm....................................................................................32

Chương 6 KẾT LUẬN..........................................................................................34
6.1 Kết quả đạt được.........................................................................................34
6.2 Hạn chế.......................................................................................................34
6.3 Hướng phát triển.........................................................................................34

5


DANH MỤC CÁC BẢNG

6


DANH MỤC HÌNH
Trang
Hình 1 Sơ đồ về sự trao đổi giữa 2 peer qua các tín hiệu, phiên và giao thức......15
Hình 2.......................................................................................................................19
Hình 3....................................................................................................................... 20
Hình 4....................................................................................................................... 20
Hình 5 Kiến trúc tổng thể của WebRTC....................................................................29
Hình 6....................................................................................................................... 30
Hình 7....................................................................................................................... 31
Hình 8....................................................................................................................... 32
Hình 9....................................................................................................................... 32
Hình 10..................................................................................................................... 33
Hình 11..................................................................................................................... 33

7

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
15

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
Select Forwarding Unit

8

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


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ổ chức
các buổi hội nghị trực tuyến là một nhu cầu cấp thiết hiện nay đặc biệt trước diễn
biến phức tạp của đại dịch toàn cầu covid-19 làm hạn chế việc gặp mặt trực tiếp
hoặc tập trung đông người
Ở đây, chúng em đ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ả
 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 React.
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. 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.
 Kết quả

Đối với một ứng dụng web 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:
 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

9


1.3 Cấu trúc đồ án
 Tìm hiểu phương pháp WebRTC
 Hạn chế và lợi ích của phương pháp
 Phân tích thiết kệ hệ thống và triển khai:
 Nói rõ đến cách thức hoạt động của phương pháp được chọn
 Xây dựng mơ hình hoạt động của ứng dụng.
 Tiến hành lập trình ứng dụng
 Kết luận và hướng phát triển:
 Tổng kết những gì đã đạt được qua quá trình xây dựng ứng dụng
 Nêu ra những hạn chế tồn tại chưa được giải quyết
 Đị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 đó

10


Chương 2

GIỚI THIỆU VỀ WEBRTC

Những năm gần đây, nền tảng web đã trở nên khơng cịn xa lạ gì với cái tên

WebRTC. WebRTC là viết tắt của cụm từ Web Real-Time Communication rất
được các lập trình viên ưa chuộng. WebRTC cho phép các trình duyệt giao
tiếp với nhau theo thời gian thực. Ví dụ như: gọi điện, video, chơi game,…
Ngồi ra, WebRTC là một sản phẩm của World Wide Web Consortium
(W3C).

2.1 WebRTC là gì?
 Hiểu một cách đơn giản hơn về WebRTC thì nó khơng chỉ là một sản phẩm
hay một hàm API duy nhất. Nó là cả một tập hợp rất nhiều các hàm có thể
được lập trình viên sử dụng cho nhiều mục đích khác nhau. Có hàm chỉ để
làm những việc đơn giản như đòi quyền truy cập vào webcam và microphone
của máy tính, có hàm phức tạp hơn thì để thiết lập kết nối giữa hai người
dùng với nhau, có hàm cịn dùng để chia sẻ màn hình với người khác. Và rồi
có hàm để hai người gọi video cho nhau, cũng là chức năng "nổi tiếng" nhất
của WebRTC tính đến thời điểm hiện tại.
 Tuy nhiên, tất cả mọi hàm lập trình nằm trong bộ API có một điểm chung vơ
cùng quan trọng: chúng thực thi hầu hết các tác vụ theo thời gian thực. Đó là
lý do vì sao chữ Real-Time xuất hiện trong cái tên của bộ hàm này. Và nó
khơng chỉ được dùng cho việc gọi video giữa hai trình duyệt mà người ta cịn
có thể làm nhiều chuyện khác, miễn là chuyện đó có liên quan đến việc làm
cho hai hoặc nhiều người dùng liên lạc với nhau.

2.2 Lợi ích của WebRTC
 Giảm giá thành: chi phí triển khai và hỗ trợ IT thấp vì khơng cần cài đặt
phần mềm client đặc biệt nào phía client.
 Khơng Plugins: trước đây phải sử dụng Flash, Java Applets và các giải
pháp khác để xây dựng ứng dụng web tương tác đa phương tiện, phải
download và cài đặt các plugin của bên thứ ba để có thể sử dụng nội dung
đa phương tiện, ngồi ra còn phải lưu ý đến những giải pháp/plugin cho
các hệ điều hành và nền tảng (platform) khác nhau. Với WebRTC thì

khơng cần quan tâm đến vấn đề này nữa.
 Truyền thông P2P: trong đa phần các trường hợp, truyền thơng được thiết
lập trực tiếp giữa trình duyệt, khơng cần có những điểm trung gian.
 Dễ sử dụng: có thể dễ dàng tích hợp tính năng WebRTC trong dịch vụ
web/trang web bằng cách sử dụng JavaScript APIs, những framework đã
có sẵn.
 Một giải pháp cho mọi nền tảng: không cần phát triển những phiên bản
dịch vụ web cho những nền tảng khác nhau (Windows, Android, IOS…)
 Mã mở và miễn phí: WebRTC được Google đưa thành dự án mã nguồn mở,
và được hỗ trợ bởi những công ty quốc tế như Mozilla, Google và Opera,
11


thêm cộng đồng trên thế giới có thể phát hiện những lỗi mới và giải quyết
nhanh chóng hồn tồn miễn phí
 Built-in security: WebRTC quy định mọi dữ liệu truyền P2P đều được bảo
mật và mã hóa.

2.3 WebRTC dùng để làm gì ?
 WebRTC cung cấp khả năng đa phương tiện một cách mạnh mẽ cho Web,
bao gồm hỗ trợ âm thanh, video, trao đổi tệp... Kết nối giữa các peer có thể
được thực hiện mà khơng u cầu một trình điều khiển đặc biệt hoặc
plugin nào và nó có thể thực hiện mà không cần bất kỳ máy chủ trung gian
nào.
 Kết nối giữa 2 peer được tạo nên và đại diện bởi interface
RTCPeerConnection. Một khi kết nối được thiết lập và mở thì các luồng
truyền thơng (MediaStreams) hoặc kênh dữ liệu (RTCDataChannels) có
thể được thêm vào kết nối.
 Các luồng truyền thơng có thể bao gồm một số lượng bất kỳ các track của
thông tin đa phương tiện. Tracks được đại diện bởi đối tượng dựa vào

interface MediaStreamTrack có thể chứa một số loại dữ liệu truyền thơng
bao gồm âm thanh, video, văn bản. Hầu hết các luồng bao gồm ít nhất một
bản âm thanh và có thể cũng là video, cũng có thể được sử dụng để gửi và
nhận đa phương tiện truyền thông trực tiếp hoặc thông tin đa phương tiện
được lưu trữ.
 Một trong những trang web được biết đến khá nhiều trong giới lập trình
viên WebRTC đó là Appear.in ra mắt hồi năm 2012. Dịch vụ này hỗ trợ
người dùng tạo một phòng chat video cực kì nhanh chóng chỉ bằng cách
dùng Chrome hoặc Firefox gốc, khơng cần phải cài thêm bất kì một plugin
nào. Thậm chí người ta cịn khơng cần phải đăng nhập hay tạo tài khoản
như các app chat video hiện nay.
 Nói tóm lại, WebRTC có thể được sử dụng cho nhiều mục đích, từ việc
truyền tải video, âm thanh cho đến gửi dữ liệu theo thời gian thực giữa hai
hoặc nhiều thiết bị với nhau mà không nhất thiết phải đi qua server trung
gian. Điều này giúp giảm độ trễ trong việc truyền tải, giảm độ phức tạp khi
phát triển ứng dụng cũng như giảm chi phí vận hành (vì khơng phải trả tiền
th server, tiền điện, tiền bảo dưỡng...), kéo theo đó giá bán dịch vụ nếu
có thì cũng sẽ thấp hơn.

2.4 Giao tiếp Peer-To-Peer
 Để có thể giao tiếp lẫn nhau thơng qua trình duyệt web, mỗi trình duyệt của
user phải thực hiện những bước sau đây:
 Đồng ý để bắt đầu giao tiếp
 Biết cách xác định vị trí của đối tượng
 Vượt qua an ninh và tưởng lửa bảo vệ
 Chuyển giao tất cả các giao tiếp đa phương tiện theo real-time
 Một trong số những thách thức lớn nhất liên quan đến các giao tiếp P2P dựa
trên trình duyệt là làm sao để biết vị trí & thiết lập 1 kết nối socket mạng
12

(network socket connection) với 1 trình duyệt khác để vận chuyển dữ liệu 2
chiều. Ta sẽ xem xét những khó khăn liên quan đến việc thiết lập kết nối này.
 Khi web app của bạn cần dữ liệu hoặc tài nguyên, nó sẽ lấy về từ các server.
Tuy nhiên, nếu bạn muốn tạo ra 1 ứng dụng video chat chẳng hạn, bằng cách
kết nối trực tiếp đến trình duyệt của người khác - thì đây là vấn đề, vì bạn
khơng biết địa chỉ bởi vì trình duyệt của người kia khơng phải là 1 web
server. Vì vậy để có thể thiết lập 1 kết nối P2P ta cần rất nhiều thứ.

2.5

Tường lửa và NAT Traversal
 Thường thì máy tính của bạn khơng khơng có địa chỉ IP public tĩnh. Lý do là
máy tính của bạn phải núp đằng sau tường lửa và thiết bị NAT (Network
access translation - Bộ phiên dịch truy cập mạng).
 Thiết bị NAT sẽ dịch địa chỉ IP cá nhân từ bên trong tường lửa thành địa chỉ
IP công khai (public-facing IP). Ta cần các thiết bị NAT để bảo mật và giải
quyết sự giới hạn của IPv4 đối với những địa chỉ IP công khai sẵn có. Đó là
lý do tại sao webapp khơng nên giả định rằng thiết bị hiện tại có 1 địa chỉ IP
public tĩnh.
 Cùng tìm hiểu 1 chút về cách hoạt động của các thiết bị NAT. Nếu như bạn
đang ở trong môi trường công cộng và kết nối vào mạng WiFi, máy tính của
bạn sẽ được gán 1 địa chỉ IP mà nó chỉ tồn tại đằng sau NAT. Giả sử IP là
172.0.23.4, tuy nhiên, với thế giới bên ngồi, địa chỉ IP của bạn có thể mang
giá trị khác, ví dụ 164.53.27.98. Vì vậy, thế giới bên ngồi sẽ thấy các request
của bạn đến từ địa chỉ 164.53.27.98 nhưng thiết bị NAT sẽ đảm bảo các
response cho những request (được gửi từ máy của bạn) sẽ trả về đúng chỗ là
172.0.23.4. Ơn trời các bảng ánh xạ (mapping table). Lưu ý rằng ngồi địa chỉ
IP thì cổng (port) cũng là điều kiện cần thiết cho các giao tiếp mạng.
 Do có sự tham gia của các thiết bị NAT, trình duyệt của bạn cần tìm được địa

chỉ IP của máy tính có trình duyệt mà bạn muốn giao tiếp.
 Đến đây thì ta lại phải nhờ đến các server STUN (Session Traversal Utilities
for NAT - Tiện ích truyền tải theo phiên cho NAT) và TURN (Traversal Using
Relays around NAT - Truyền tải sử dụng điểm chuyển tiếp vòng quanh NAT).
Để các công nghệ WebRTC hoạt động được, đầu tiên thì 1 request hỏi địa chỉ
IP public của bạn sẽ được gửi đến server STUN. Bạn cứ nghĩ theo hướng kiểu
như máy tính đang tạo truy vấn đến 1 server từ xa để hỏi về địa chỉ IP mà
server đó nhận câu truy vấn là bao nhiêu. Server từ xa sẽ trả về địa chỉ IP mà
nó thấy. Nói ngắn gọn là máy tính của bạn “hỏi” 1 server từ xa địa chỉ IP của
chính máy bạn là bao nhiêu.
 Giả sử tiến trình này hoạt động bình thường và bạn nhận được địa chỉ IP
public của mình cũng như số port, bạn sẽ có thể nói với những peer ngang
hàng khác làm thế nào để kết nối trực tiếp đến bạn. Những peer này cũng có
thể làm cùng 1 việc là sử dụng STUN & server TURN và nói cho bạn biết
nên liên lạc đến địa chỉ nào.
13


2.6 Signaling, Sessions
 Q trình khám phá thơng tin mạng được mô tả ở trên chỉ là 1 phần của chủ
đề về Signaling to bự hơn nhiều, trong trường hợp của WebRTC thì phần
signaling này dựa trên 1 chuẩn JSEP (Javascript Session Establishment
Protocol - Giao thức thiết lập phiên của Javascript). Signaling bao gồm cả
khám phá mạng (network discovery) và NAT Traversal, tạo và quản lý phiên,
bảo mật giao tiếp, siêu dữ liệu (metadata) và phối hợp khả năng của media,
xử lý lỗi.
 Để kết nối có thể hoạt động, peer thu được những điều kiện về local media
cho metadata (ví dụ: những khả năng về kích thước và kiểu codec) và gom
góp các địa chỉ mạng có thể có cho host của ứng dụng. Cơ chế signaling dùng
để truyền tới/lui những thông tin quan trọng này không được định nghĩa trong

API của WebRTC.
 Signaling không được quy định bởi chuẩn WebRTC và nó khơng được triển
khai bằng API của nó để cho phép sử dụng một cách linh động các công nghệ
và giao thức cần thiết. Các WebRTC developer sẽ đối phó với signaling và
server xử lý signaling. Phần đàm phán và thiết lập khởi tạo phiên xảy ra khi
dùng 1 giao thức signaling/giao tiếp được đặc tả trong các giao tiếp đa
phương tiện. Giao thức này cũng chịu trách nhiệm cho việc điều hành các quy
định trong đó phiên được quản lý và hủy bỏ.
 Một trong số các giao thức như vậy có tên là Session Initiation Protocol (SIP
- Giao thức khởi tạo phiên). Lưu ý rằng do sự linh động của WebRTC
signaling, SIP không phải là giao thức signaling duy nhất có thể dùng. Giao
thức signaling được chọn phải hoạt động với 1 giao thức ở tầng ứng dụng gọi
là Session Description Protocol (SDP - Giao thức mô tả phiên), giao thức này
được sử dụng trong trường hợp của WebRTC. Tất cả các metadata đa phương
tiện cụ thể được truyền đi bằng giao thức SDP này.
 Bất kỳ peer nào (ví dụ: app tận dụng WebRTC) thử giao tiếp với 1 peer khác
đều sinh ra 1 tập các ứng viên giao thức Interactive Connectivity
Establishment (ICE - Thiết lập kết nối tương tác). Những ứng viên này biểu
diễn 1 bộ kết hợp của địa chỉ IP, port, giao thức giao vận được dùng. Lưu ý
rằng 1 máy tính có thể có nhiều giao diện mạng (khơng dây, có dây, vân vân),
vì thế có thể được gán nhiều địa chỉ IP cho mỗi giao diện.

14


Hình 1 Sơ đồ về sự trao đổi giữa 2 peer qua các tín hiệu, phiên và giao thức

2.7 WebRTC’s protocols
 SRTP
 Giao thức quan trọng nhất mà WebRTC sử dụng là Secure Real-time

Transport Protocol, hay SRTP [17]. SRTP đượ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 hoặ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 Transmission Protocol [15] để
truyền các 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. Tuy nhiên trong WebRTC, SCTP chạy trên DTLS trên
UDP. SCTP được lựa chọn do có những tính năng tốt nhấ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.
 SDP
 WebRTC sử dụng Session Description Protocol, SDP [18], được encode
trong đối tượng RTCSessionDescription, để mơ tả đặc tính media của hai
đầu trong kết nối P2P như loại media đề truyền/nhận (audio, video,
application data), network transports, loại codecs sử dụng và cấu hình,
thơng tin băng thơng, và các thơng tin metadata khác.Thông điệp SDP
được trao đổi qua máy chủ báo hiệu hay còn gọi là được trao đổi qua kênh
báo hiệu. Máy chủ báo hiệu có trách nhiệm gửi và nhận tất cả thông điệp
đến tất cả các peers mà mong muốn kết nối đến peer khác. Mặc dù SDP là
định dạng dữ liệu dùng để trao đổi, thống nhất thông số giữa kết nối Peerto-Peer, nhưng do WebRTC không ràng buộc cho các SDP “offer” và
“answer” giao tiếp như nào, nên nó khơng được thể hiện ở hình 2.7 ở trên.
15












Tuy nhiên, mơ hình offer/answer được thiết kế tn thủ theo RFC3264
[24].
DTLS
 Datagram Transport Layer Security- DTLS [16] dựa trên giao thức TLS,
cung cấp tính bảo mật và tồn vẹn dữ liệu truyền giữa các ứng dụng tương
tự TLS [19]. Tuy nhiên, WebRTC sử dụng DTLS do nó chạy trên giao
thức UDP thích hợp với việc vượt NAT cho các ứng dụng P2P. Tất cả các
dữ liệu truyền P2P đều được bảo mật sử dụng DTLS. Cụ thể hơn, DTLS
được sử dụng trong việc thống nhất khóa bảo mật cho việc mã hóa dữ liệu
media và trong việc bảo mật sự vận chuyển dữ liệu ứng dụng. Mặc dù
cung cấp tính mã hóa, tính tồn vẹn, nhưng phần xác thực trong WebRTC
được gán cho ứng dụng.
STUN
 Session Traversal Utilities for NAT, STUN [14]: là giao thức giúp cho
việc vượt NAT trong quá trình thiết lập kết nối. Trong WebRTC, một
STUN client sẽ được xây dựng trong User Agent của trình duyệt để kết
nối đến STUN server ngoài Internet.STUN server thực thi nhiệm vụ khá
đơn giản, kiểm tra thông tin địa chỉ IP, port của request đến từ ứng dụng
sau NAT, sau đó trả thơng tin đó về dưới dạng response, nói cách khác là
STUN giúp ứng dụng biết địa chỉ IP, cổng của nó sử dụng khi đi ra
Internet STUN có thể được vận chuyển trên UDP, TCP hoặc TLS
 Trong đa số các trường hợp thì chỉ cần sử dụng STUN trong việc thiết lập

kết nối P2P, trừ trường hợp một peer đứng sau symmetric NAT, một peer
đứng sau Symmetric NAT hoặc port-restricted NAT. Trường hợp này quá
trình hole punching [20] sẽ không thành công, cần phải sử dụng đến
TURN - Traversal Using Relays around NAT [21].
TURN
Traversal Using Relays around NAT, TURN, là một mở rộng (extension) của
giao thức STUN, cung cấp media relay cho tình huống thực hiện hole
punching khơng thành cơng. Trong WebRTC, User Agent của trình duyệt sẽ
bao gồm một TURN client. TURN server được cung cấp trên Internet qua các
nhà cung cấp dịch vụ, hoặc có thể cài đặt trong mạng doanh nghiệp. Giao
thức UDP được sử dụng để giao tiếp giữa TURN client và TURN server qua
NAT. Cổng UDP mặc định cho TURN là 3478. Trên thực tế TURN server
thường là STUN server có bổ sung tính năng relay. TURN server thì có chức
năng STUN, nhưng khơng phải mọi STUN server đều có chức năng TURN.
ICE
Interactive Communication Establishment, hay ICE [13] là giao thức rất quan
trọng trong WebRTC, có hai chức năng chính: cho phép WebRTC client trao
đổi media qua thiết bị có thực hiện NAT và cung cấp sự xác minh việc chấp
thuận giao tiếp giữa client, giúp gói tin media chỉ được gửi đến trình duyệt
mà đang đợi dữ liệu. Một ứng dụng web độc hại có thể lừa trình duyệt gửi dữ
liệu media đến một host trên Internet mà không phải là thành phần muốn giao
tiếp. Kiểu tấn công này là tấn công từ chối dịch vụ DOS (Denial of Service),
và ICE thành cơng trong việc ngăn ngừa điều này vì dữ liệu media không bao
giờ được gửi trừ khi quá trình trao đổi ICE kết thúc thành cơng.ICE sử dụng
kỹ thuật hole punching [20], kỹ thuật được tiên phong bởi các game thủ chơi
16


online, những người cần trao đổi gói tin trực tiếp giữa các PCs cho dù giữa
chúng có NAT. Hole punching là kỹ thuật cho phép “đục lỗ” qua thiết bị NAT

để thiết lập kết nối trực tiếp giữa ứng dụng ngay cả khi cả hai đầu ứng dụng
đều nằm sau NAT.Để hole punching thành công cần thỏa mãn một số các yêu
cầu:
- Hai trình duyệt muốn thiết lập kết nối trực tiếp phải gửi gói hole
punching cùng thời điểm. Nhờ vậy cả hai trình duyệt mới nhận ra
session cần thiết lập và biết các địa chỉ để gửi gói tin. Gói tin hole
punching là gói tin IP thơng thường được gửi để kiểm tra có đến được
địa chỉ đích (sau NATs) khơng.
- Hai trình duyệt phải biết càng nhiều địa chỉ IP mà có thể sử dụng để
kết nối đến peer càng tốt. Các địa chỉ này các địa chỉ nội bộ (trong
NAT), địa chỉ public (ngoài NAT) và địa chỉ relay.
- Cả hai trình duyệt phải kết nối đến được địa chỉ IP Public của media
relay.
- Dòng đối xứng phải được sử dụng. Lưu lượng UDP phải xuất hiện để
hoạt động tương tự cách của kết nối TCP.
 Yêu cầu đầu tiên thỏa mãn khi sử dụng máy chủ web để điều phối quá trình
hole punching, bởi máy chủ web biết có nhu cầu mong muốn thiết lập giữa
hai trình duyệt,do đó nó đảm bảo việc hai trình duyệt bắt đầu quá trình hole
punching cùng thời điểm ở mức tương đối. Yêu cầu thứ 2 được thỏa mãn
bằng cách dùng STUN Server. Yêu cầu thứ 3 được thỏa mãn khi dùng TURN
Server. Trình duyệt ưu tiên truy vấn đến STUN server trước để khởi động quá
trình hole punching, sau đó mới truy vấn đến TURN server để lấy địa chỉ
media relay. Địa chỉ media relay là địa chỉ public, giúp chuyển tiếp gói tin
đến và đi từ trình duyệt thiết lập địa chỉ relay. Địa chỉ này sau đó sẽ được
thêm vào danh sách địa chỉ ứng viên (Địa chỉ ứng viên gồm địa chỉ IP và
cổng UDP). Yêu cầu 4 được đáp ứng bởi trình duyệt gửi media từ cùng 1
cổng UDP mà trình duyệt sử dụng để lắng nghe media đến. Điều này làm cho
2 phiên một chiều RTP trên UDP xuất hiện với NAT như là một phiên RTP
hai chiều.
 Trong đa số các trường hợp thì hole puching thành cơng, kết nối peer-to-peer

được thiết lập, luồng media không relay qua máy chủ. Luồng media chỉ relay
qua máy chủ khi mọi đường media đều thiết lập khơng thành cơng.
 Quy trình hoạt động của ICE: Để thiết lập được đường định tuyến giữa các
peer, WebRTC, cụ thể là đối tượng PeerConnection có một ICE agent cho
nhiều nhiệm vụ như thu thập thông tin địa chỉ ứng viên, kiểm tra kết nối giữa
các peer, gửi các thông tin keepalives.

2.8 Media server
 WebRTC là một tập hợp các giao thức, cơ chế và API cung cấp trình duyệt và
ứng dụng di động với Real-Time Communications (RTC) thông qua kết nối
peer-to-peer. Nó đã được hình thành như một cơng nghệ cho phép trình duyệt
để giao tiếp trực tiếp mà không cần qua trung gian của bất kỳ loại cơ sở hạ
tầng nào. Tuy nhiên, mơ hình này chỉ đủ để tạo các ứng dụng web cơ bản; các
tính năng như liên lạc nhóm, ghi dịng phương tiện, phương tiện truyền thơng
phát sóng, hoặc chuyển mã phương tiện rất khó thực hiện. Vì lý do này, nhiều
ứng dụng yêu cầu một máy chủ phương tiện trung gian.
17


 Về mặt khái niệm, WebRTC media servers chỉ là một phần mềm trung gian
đa phương tiện, nơi lưu lượng phương tiện truyền thông đi qua khi di chuyển
từ nguồn đến đích.
 Media servers có khả năng xử lý các luồng phương tiện đến và cung cấp các
kết quả khác nhau, chẳng hạn như:
 Group Communications: Phân phối giữa một số người nhận luồng phương
tiện mà một người ngang hàng tạo ra, tức là hoạt động như một đơn vị nhiều
hội nghị (NGÀY MCU).
 Mixing: Chuyển đổi một số luồng đến thành một luồng tổng hợp duy nhất.
 Transcoding: Thích ứng nhanh chóng các codec và định dạng giữa các máy
khách khơng tương thích.

 Recording: Lưu trữ một cách liên tục các phương tiện truyền thông trao đổi
giữa các đồng nghiệp.

2.9 Các API của WebRTC
 Có 3 mục phân loại API chính trong WebRTC:
 Media Capture and Streams (luồng media và chụp media): cho phép bạn
truy xuất vào các thiết bị đầu vào, chẳng hạn như microphone hay web
camera. API cho phép bạn lấy 1 luồng media từ các thiết bị đó.
 RTCPeerConnection - dùng những API này, bạn có thể gửi theo thời gian
thực 1 luồng âm thanh & hình ảnh đã bắt được thơng qua internet đến 1
endpoint WebRTC khác. Bạn có thể tạo ra kết nối giữa máy local và peer
từ xa. Nó cũng cung cấp các phương thức để kết nối đến 1 peer từ xa, duy
trì và kiểm sốt kết nối & đóng kết nối 1 khi ta khơng cần đến nó nữa.
 RTCDataChannel - API này cho phép bạn truyền dữ liệu tùy ý. Mỗi kênh
dữ liệu được liên kết với 1 RTCPeerConnection.

18


Chương 3
3.1

CÁC BƯỚC TẠO RA WEBRTC

Bắt đầu với Media devices
 Khi phát triển cho web, tiêu chuẩn WebRTC cung cấp các API để truy cập
máy ảnh và micro được kết nối với máy tính hoặc điện thoại thơng minh. Các
thiết bị này thường được gọi là Thiết bị Phương tiện và có thể được truy cập
bằng JavaScript thơng qua đối tượng navigator.mediaDevices, đối tượng này
thực thi MediaDevices giao diện. Từ đối tượng này, chúng ta có thể liệt kê tất

cả các thiết bị được kết nối, lắng nghe các thay đổi của thiết bị (khi thiết bị
được kết nối hoặc ngắt kết nối) và mở một thiết bị để lấy Media Stream.
 Cách phổ biến nhất được sử dụng là thông qua hàm getUserMedia(), hàm này
trả về một lời hứa sẽ giải quyết thành một MediaStream cho các thiết bị
phương tiện phù hợp. Hàm này nhận một đối tượng MediaStreamConstraints
xác định các u cầu mà chúng ta có. Ví dụ, để chỉ cần mở micrô và máy ảnh
mặc định, chúng tơi sẽ làm như sau.

Hình 2

 Lệnh gọi tới getUserMedia()sẽ kích hoạt một yêu cầu quyền. Nếu người dùng
chấp nhận quyền, lời hứa sẽ được giải quyết bằng một MediaStream đoạn
video và một đoạn âm thanh. Nếu quyền bị từ chối, một
PermissionDeniedError sẽ được ném. Trong trường hợp khơng có thiết bị
phù hợp nào được kết nối, một NotFoundError sẽ được ném ra.
Truy vấn thiết bị phương tiện
 Trong một ứng dụng phức tạp hơn, rất có thể chúng tơi sẽ muốn kiểm tra tất
cả các máy ảnh và micrô được kết nối và cung cấp phản hồi thích hợp cho
người dùng. Điều này có thể được thực hiện bằng cách gọi hàm
enumerateDevices(). Điều này sẽ trả về một lời hứa phân giải thành một
mảng MediaDevicesInfo mô tả từng thiết bị phương tiện đã biết. Chúng tơi có
thể sử dụng điều này để trình bày giao diện người dùng cho người dùng để họ
chọn giao diện người dùng họ thích. Mỗi MediaDevicesInfochứa một thuộc
19


tính được đặt tên kindvới giá trị audioinput, audiooutputhoặc videoinput, nêu
rõ là loại thiết bị phương tiện truyền thơng.

Hình 3

Lắng nghe các thay đổi của thiết bị
 Hầu hết các máy tính đều hỗ trợ cắm nhiều thiết bị khác nhau trong thời gian
chạy. Đó có thể là một webcam được kết nối bằng USB, tai nghe Bluetooth
hoặc một bộ loa ngoài. Để hỗ trợ đúng cách này, ứng dụng web phải lắng
nghe những thay đổi của thiết bị phương tiện. Điều này có thể được thực hiện
bằng cách thêm một người nghe navigator.mediaDevices cho devicechange
sự kiện.

Hình 4

20


Ràng buộc về phương tiện
 Đối tượng ràng buộc, phải triển khai MediaStreamConstraints giao diện, mà
chúng ta chuyển vào dưới dạng tham số để getUserMedia() cho phép chúng ta
mở một thiết bị phương tiện phù hợp với một yêu cầu nhất định. Yêu cầu này
có thể được xác định rất lỏng lẻo (âm thanh và / hoặc video), hoặc rất cụ thể
(độ phân giải máy ảnh tối thiểu hoặc ID thiết bị chính xác). Các ứng dụng sử
dụng getUserMedia() API trước tiên nên kiểm tra các thiết bị hiện có và sau
đó chỉ định một ràng buộc phù hợp với thiết bị chính xác bằng cách sử dụng
deviceId ràng buộc. Các thiết bị cũng sẽ được cấu hình theo các ràng buộc
nếu có thể. Chúng tơi có thể bật tính năng khử tiếng vọng trên micrô hoặc đặt
chiều rộng và chiều cao cụ thể hoặc tối thiểu của video từ máy ảnh.
Phát lại cục bộ
 Sau khi thiết bị phương tiện đã được mở và chúng tơi có MediaStreamsẵn,
chúng tơi có thể gán thiết bị đó cho phần tử video hoặc âm thanh để phát trực
tuyến cục bộ.
 HTML cần thiết cho một phần tử video điển hình được sử dụng

getUserMedia() thường sẽ có các thuộc tính autoplayvà playsinline. Các
autoplay thuộc tính sẽ gây ra con suối mới giao cho nguyên tố này để chơi tự
động. Các playsinlinethuộc tính cho phép video để chơi inline, thay vì chỉ
trên tồn màn hình, trên các trình duyệt di động nào đó. Nó cũng được
khuyến nghị sử dụng controls="false"cho các luồng trực tiếp, trừ khi người
dùng có thể tạm dừng chúng.

3.2 Nắm bắt phương tiện và các ràng buộc
 Phần phương tiện của WebRTC bao gồm cách truy cập vào phần cứng có khả
năng thu video và âm thanh, chẳng hạn như máy ảnh và micrô, cũng như cách
hoạt động của các luồng phương tiện. Nó cũng bao gồm phương tiện hiển thị,
đó là cách một ứng dụng có thể thực hiện chụp màn hình.
Thiết bị phương tiện
 Tất cả các camera và micrơ được trình duyệt hỗ trợ đều được truy cập và
quản lý thơng qua navigator.mediaDevicesđối tượng. Các ứng dụng có thể
truy xuất danh sách thiết bị được kết nối hiện tại và cũng có thể lắng nghe các
thay đổi, vì nhiều máy ảnh và microhpones kết nối qua USB và có thể được
kết nối và ngắt kết nối trong vịng đời của ứng dụng. Vì trạng thái của thiết bị
media có thể thay đổi bất kỳ lúc nào, nên các ứng dụng nên đăng ký các thay
đổi của thiết bị để xử lý các thay đổi đúng cách.
Ràng buộc
 Khi truy cập vào các thiết bị media, bạn nên cung cấp các ràng buộc chi tiết
nhất có thể. Mặc dù có thể mở máy ảnh và micrơ mặc định với một hạn chế
21


đơn giản, nhưng nó có thể cung cấp một luồng phương tiện khác xa mức tối
ưu nhất cho ứng dụng.
 Các ràng buộc cụ thể được xác định trong một MediaTrackConstraintđối
tượng, một cho âm thanh và một cho video. Các thuộc tính trong đối tượng

này là các loại ConstraintLong, ConstraintBoolean, ConstraintDoublehoặc
ConstraintDOMString. Đây có thể là một giá trị cụ thể (ví dụ: một số,
boolean hoặc chuỗi), một phạm vi ( LongRangehoặc DoubleRangevới giá trị
nhỏ nhất và lớn nhất) hoặc một đối tượng với một idealhoặc một exactđịnh
nghĩa. Đối với một giá trị cụ thể, trình duyệt sẽ cố gắng chọn thứ gì đó càng
gần càng tốt. Đối với một phạm vi, giá trị tốt nhất trong phạm vi đó sẽ được
sử dụng. Khi exactđược chỉ định, chỉ các luồng phương tiện khớp chính xác
với ràng buộc đó mới được trả về.Để xác định cấu hình thực tế mà một bản
nhạc nhất định của luồng phương tiện có, chúng ta có thể gọi cấu hình
MediaStreamTrack.getSettings()trả về MediaTrackSettingshiện đang được áp
dụng.
 Cũng có thể cập nhật các ràng buộc của bản nhạc từ thiết bị đa phương tiện
mà chúng tôi đã mở, bằng cách gọi applyConstraints()trên bản nhạc. Điều này
cho phép ứng dụng định cấu hình lại thiết bị phương tiện mà trước tiên khơng
phải đóng luồng hiện có.
Hiển thị phương tiện
 Một ứng dụng muốn có thể thực hiện quay và chụp màn hình phải sử dụng
API phương tiện hiển thị. Hàm getDisplayMedia()(một phần của hàm
navigator.mediaDevicesnày tương tự getUserMedia()và được sử dụng cho
mục đích mở nội dung của màn hình (hoặc một phần của nó, chẳng hạn như
cửa sổ). Hàm trả về MediaStreamhoạt động giống như khi sử dụng
getUserMedia(). Các ràng buộc cho getDisplayMedia()khác với các ràng
buộc được sử dụng cho đầu vào video hoặc âm thanh thông thường.
Luồng và bản nhạc
 A MediaStream đại diện cho một luồng nội dung đa phương tiện, bao gồm
các bản nhạc ( MediaStreamTrack) âm thanh và video. Bạn có thể truy xuất
tất cả các bản nhạc từ đó MediaStreambằng cách gọi
MediaStream.getTracks(), thao tác này trả về một mảng MediaStreamTrack
đối tượng.
MediaStreamTrack

 A MediaStreamTrackcó một thuộc tính là audio hoặc video, cho biết loại
phương tiện mà nó đại diện. Mỗi bản nhạc có thể bị tắt tiếng bằng cách
chuyển đổi thuộc tính của nó enabled. Một bản nhạc có thuộc tính Boolean
remotecho biết nó có được lấy nguồn bởi a RTCPeerConnectionvà đến từ một
đồng đẳng từ xa hay không.

22


3.3 Bắt đầu với Peer-connection
 Kết nối ngang hàng là một phần của thông số kỹ thuật WebRTC đề cập đến
việc kết nối hai ứng dụng trên các máy tính khác nhau để giao tiếp bằng giao
thức ngang hàng. Giao tiếp giữa các đồng nghiệp có thể là video, âm thanh
hoặc dữ liệu nhị phân tùy ý (đối với các ứng dụng khách hỗ trợ
RTCDataChannelAPI). Để khám phá cách hai máy khách có thể kết nối, cả
hai máy khách cần cung cấp cấu hình Máy chủ ICE. Đây là máy chủ STUN
hoặc máy chủ TURN và vai trò của chúng là cung cấp các ứng viên ICE cho
mỗi máy khách, sau đó được chuyển đến máy ngang hàng từ xa. Việc chuyển
các ứng viên ICE này thường được gọi là báo hiệu.
Báo hiệu
 Đặc tả WebRTC bao gồm các API để giao tiếp với Máy chủ ICE (Thiết lập
Kết nối Internet), nhưng thành phần báo hiệu không phải là một phần của nó.
Báo hiệu là cần thiết để hai đồng nghiệp chia sẻ cách họ nên kết nối. Thông
thường điều này được giải quyết thông qua API Web dựa trên HTTP thông
thường (tức là dịch vụ REST hoặc cơ chế RPC khác) nơi các ứng dụng web
có thể chuyển tiếp thông tin cần thiết trước khi kết nối ngang hàng được bắt
đầu.
 Đoạn mã sau cho thấy cách dịch vụ báo hiệu hư cấu này có thể được sử dụng
để gửi và nhận tin nhắn không đồng bộ. Điều này sẽ được sử dụng trong các
ví dụ cịn lại trong hướng dẫn này khi cần thiết.

// Set up an asynchronous communication channel that will be
// used during the peer connection setup
const signalingChannel = new SignalingChannel(remoteClientId);
signalingChannel.addEventListener('message', message => {
// New message from remote client received
});
// Send an asynchronous message to the remote client
signalingChannel.send('Hello!');
 Báo hiệu có thể được thực hiện theo nhiều cách khác nhau và đặc tả WebRTC
khơng thích bất kỳ giải pháp cụ thể nào.
Khởi tạo kết nối ngang hàng
 Mỗi kết nối ngang hàng được xử lý bởi một RTCPeerConnectionđối tượng.
Hàm tạo cho lớp này nhận một RTCConfigurationđối tượng duy nhất làm
tham số của nó. Đối tượng này xác định cách kết nối ngang hàng được thiết
lập và phải chứa thông tin về các máy chủ ICE để sử dụng.
 Sau khi RTCPeerConnection được tạo, chúng tôi cần tạo một phiếu mua hàng
hoặc câu trả lời SDP, tùy thuộc vào việc chúng tôi là đồng nghiệp đang gọi
23