HỌC VIỆN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG
KHOA VIỄN THƠNG 1

BÁO CÁO BÀI TẬP LỚN
INTERNET VÀ GIAO THỨC

CHỦ ĐỀ: TÌM HIỂU VỀ RTP/ RTCP

1


LỜI MỞ ĐẦU
Ngày nay, cùng với sự phát triển của xã hội thì ngành cơng nghệ thơng tin đang
đạt được những tiến bộ đáng kể. Các hãng sản xuất phần cứng cũng như phần mềm
luôn luôn cố gắng tạo ra những sản phẩm tốt nhất và tối ưu nhất với mức giá hấp dẫn
nhất có thể, đưa ra thị trường nhằm phục vụ cho lợi ích của người tiêu dùng cũng như
làm tăng thị phần của mình trong mơi trường cạnh tranh khốc liệt.
Cùng với sự phát triển của ngành công nghệ thông tin trên thế giới, công nghệ
thông tin Việt Nam với phương châm đi tắt đón đầu cũng đã có những bước phát triển
vượt bậc. Những năm trước đây, người sử dụng mạng Internet ở nước ta chỉ có thể
truy cập bằng các Modem quay số (Dial-up) với tốc độ khá chậm và cước phí cịn khá
cao so với thu nhập bình thường của người lao động. Vài ba năm trở lại đây, người sử
dụng mạng Internet đã được tiếp cận nhiều hơn bởi sự phát triển rộng rãi của công
nghệ DSL (Digital Subsriber Line - đường dây th bao số). Với cơng nghệ này thì
Internet đã trở nên phổ biến trong cộng đồng và Internet dần trở thành một nhu cầu tất
yếu của xã hội hiện đại. Đời sống xã hội ngày càng được cải thiện, môi trường sống và
làm việc tốt hơn cùng với thu nhập của người lao động cũng khá hơn trước nên yêu
cầu về các tiện ích trong cuộc sống cũng tăng lên đáng kể. Giờ đây, người sử dụng
không chỉ dừng lại ở những ứng dụng thông thường mà Internet mang đến, những loại
hình giải trí như nghe nhạc, xem phim chưa đủ làm thỏa mãn nhu cầu mà họ cần có
những ứng dụng cao hơn, hiện đại hơn như giám sát và điều khiển những thiết bị từ xa,

bởi nó vừa có tính an tồn cao và đồng thời cũng mang rất nhiều tiện ích trong một xã
hội cơng nghiệp đang phát triển.
Trong bài tiểu luận này nhóm em sẽ tìm hiểu về giao thức RTP và RTCP
Trong quá trình làm bài cịn tồn đọng những thiếu sót, nhóm em rất mong nhận
được những góp ý phản hồi từ thầy giáo và các bạn để bài tiểu luận của nhóm em có
thể hồn thiện và đầy đầy đủ hơn.


MỤC LỤC


CHƯƠNG 1: TẠI SAO CẦN GIAO THỨC RTP VÀ RTCP
Các ứng dụng phương tiện (Multimedia/Media Application) ở tầng ứng
dụng (trong mơ hình OSI hay mơ hình TCP/IP) cần phải đảm bảo những tính
chất khắt khe về thời gian thực, khơng cho phép độ trễ quá lớn gây ảnh hưởng
tương tác người dùng với chúng. Để thực hiện được điều này thì những ứng
dụng đó u cầu những tầng dưới hỗ trợ, và các giao thức truyền dữ liệu thời
gian thực ở các tầng dưới cần đảm bảo 1 số điều như sau:
- Có khả năng thử lỗi: có thể chấp nhận mất 1 số gói tin bị lỗi, mất mát. Lí
do của yêu cầu này là lượng dữ liệu đa phương tiện thường rất lớn, hơn nữa
môi
trường truyền tải của mạng máy tính (mạng IP) khơng thể bảo đảm hồn tồn
khơng có lỗi, nên hiện tượng mất gói hay lỗi gói có tỷ lệ xảy ra cao. Số lượng
và
mật độ các gói tin đa phương tiện gặp sự cố cần phải ở trong giới hạn để đảm
bảo cảm nhận của người dùng (ở mức độ nào đó).
- Cần phải kết hợp các thơng số về thời gian: điều này có lí do khá ró ràng
do các dữ liệu đa phương tiện luôn liên quan tới miền thời gian và nhu cầu
đảm
bảo tương tác thời gian thực của người dùng. Không có các thơng số về miền

thời gian được gửi kèm, các ứng dụng sẽ gặp khó khăn trong việc sắp xếp hay
trình diễn các nội dung nó nhận được.
- Hỗ trợ định tuyến đa điểm (multicast): điều này khơng có ý nghĩa nhiều
khi tương tác chỉ dừng lại ở mức độ điểm-điểm (unicast), nhưng nhu cầu của
con người không chỉ dừng lại ở đó. Các hội nghị, các phiên họp hay chỉ là
những cuộc trị chuyện theo nhóm là những ví dụ điển hình cho tương tác đa
điểm, trong đó mơ hình truyền tải có rất nhiều nguồn gửi và đích nhận liên tục
gửi audio hay video cho nhau cùng lúc.
Sử dụng giao thức TCP hay UDP để truyền tải dữ liệu đa phương tiện rất
không thuận lợi
-

TCP là giao thức tin cậy, vì vậy có tính thử lỗi rất tốt. Tuy nhiên TCP là
giao thức hướng kết nối, và cơ chế hộ trợ tin cậy khiến nó chậm chạp (điển
hình
là các cơ chế chờ đợi xác nhận gửi-nhận, đảm bảo sắp xếp thứ tự gói tin, phát
lại
gói tin trong trường hợp thất lạc...)


-

UDP thì gần như ngược lại TCP khi khơng phải là giao thức không hướng
kết nối, gửi dữ liệu theo phương pháp best-effort, vì vậy nó có thể truyền dữ
liệu
với tốc độ rất nhanh. UDP có thể dùng để truyền dữ liệu thời gian thực nhưng
vì
khơng có cơ chế đảm bảo tin cậy nên nó khơng thể dùng trực tiếp



- Tốc độ truyền dữ liệu của TCP quá chậm so với nhu cầu, hơn nữa khơng

có hỗ trợ multicast nên người ta đã lựa chọn phương án sử dụng UDP kết hợp
với 1 giao thức tầng trên để khắc phục được các nhược điểm của UDP trong
truyền dữ liệu thời gian thực nhưng vẫn lợi dụng được tốc độ truyền dữ liệu cao
của nó cụ thể là RTP và RTCP
CHƯƠNG 2: GIAO THỨC RTP
2.1KHÁI NIỆM
Real-time Transport Protocol (RTP) là giao thức thực hiện vận chuyển các
ứng dụng dữ liệu thời gian thực như thoại và hội nghị truyền hình. Các ứng dụng
này thường mang các định dạng của âm thanh (PCM, GSM và MP3 và các định
dạng độc quyền khác) và định dạng của video (MPEG, H.263 và các định dạng
video độc quyền khác). RTP được định nghĩa trong RFC 1889, RFC 3550.
2.2CHỨC NĂNG
Giao thức RTP chạy trên nền UDP để sử dụng các chức năng ghép kênh và
checksum. Cả hai giao thức RTP và UDP tạo nên một phần chức năng của lớp
giao vận. Tuy nhiên RTP cũng có thể được sử dụng với những giao thức khác
của lớp mạng và lớp giao vận bên dưới miễn là các giao thức này cung cấp được
các dịch vụ mà RTP đòi hỏi. Một điều cần lưu ý là bản thân giao thức RTP
không cung cấp một cơ chế nào đảm bảo việc phân phát kịp thời dữ liệu tới các
trạm, mà nó dựa trên các dịch vụ của lớp thấp hơn để thực hiện điều này. RTP
cũng không đảm bảo việc truyền các gói theo đúng thứ tự. Tuy nhiên số thứ tự
trong header cho phép bên thu điều chỉnh lại thứ tự dịng gói tin của bên phát
gữi đến.
RTP không chỉ hỗ trợ các dịch vụ phổ biến của hầu hết các ứng dụng
truyền thông hội nghị đa phương tiện mà cịn có khả năng mở rộng cho phù hợp
với dịch vụ mới. Khả năng mở rộng, các mã tương ứng trong trường PT của
header ứng với các loại payload trong gói RTP được mơ tả trong profile đi kèm.
2.3CẤU TRÚC



Cấu trúc gói tin RTP
-

-

Version: 2 bit. Trường vesion để chỉ phiên bản của giao thức. Có 3 phiên
bản 0,1,2. Phiên bản hiện tại được sử dụng là 2.
P (Padding): 1 bit. Nếu trường P được thiết lập thì gói tin sẽ có một hoặc
nhều octets P (những octets này khơng phải một phần của payload) được thêm
vào cuối gói tin. Octet P cuối cùng chỉ kích thước của tổng octect được thêm
vào. Mục đích của việc thêm octect P là để dùng cho thuật tốn mã hóa cần
kích
thước gói cố định hoặc được dùng cho việc cách ly các gói RTP trong trường
hợp nhiều gói thơng tin được mang trong cùng một đơn vị dữ liệu của giao
thức
lớp dưới.
X (Extension): 1 bit. Nếu trường X được thiết lập thì phần header cố
định phải được liên kết với phần header mở rộng.
CC (CSRC count): 4 bits. Chứa các giá trị của trường CSRC ID trong
header cố định.
M (Marker): 1 bit. Được sử dụng ở lớp ứng dụng để xác định một
profile.
PT (Payload type): 7 bits. Xác định và nêu ý nghĩa các dạng payload
của RTP. RTP có thể hỗ trợ đến 27 = 128 loại payload khác nhau. Với một
luồng âm thanh hay video trường PT được sử dụng để kí hiệu các mã âm thanh
hay video. Ví dụ: mã PT của một số định dạng âm thanh và video: PCM
(0),GSM(3), LPC (7), G.722 (9), MPEG Audio(14), G.728(15), JPEG(26),
H.261(31), MPEG1(32), MPEG2(33) . Nếu máy phát quyết định thay đổi mã ở
phần giữa của một phiên làm việc, thì máy phátcó thể thông báo cho máy

thuvề
sự thay đổi trường PT. Máy phát có thể thay đổi mã để tăng chất lượng âm
thanh
hay video hoặc giảm tốc độ luồng RTP.


Sequence Number: 16 bits. Trường mang số thứ tự của các gói tin RTP.
Số thứ tự này được tăng lên 1 sau mỗi lần gói tin RTP được máy phát gửi đi và
còn được dùng để máy thu phát hiện mất gói và khơi phục lại trình tự chuỗi gói
tin. Giá trí khởi đầu của trường này là một giá trị ngẫu nhiên. Vd: máy phát
nhận
được luồng gói tin RTP có khoảng trống giữa 2 hai số thứ tự 86, 89 thì máy
phát
sẽ biết rằng gói tin có số thự tự 87, 88 đã bị mất.
- Timestamp: 32 bits. Trường xác định thời điểm lấy mẫu của octets đầu
tiên trong gói tin RTP. Thời điểm lấy mẫu phải được đo bằng một đồng hồ tăng
đều đặn và tuyến tính về mặt thời gian để cho phép việc đồng bộ và tính tốn
độ
jitter. Tần số đồng hồ này là khơng cố định mà phụ thuộc vào loại định dạng
của
payload. Giá trị khởi đầu trường timestamp cũng được chọn một cách ngẫu
nhiên. Một vài gói tin RTP có thể mang cùng một giá trị của trường này nếu
như
chúng được phát đi cùng một lúc về mặt logic (ví dụ như các gói của cùng một
khung hình video). Trong trường hợp các gói dữ liệu được phát ra sau những
khoảng thời gian bằng thì giá trị timestamp được tăng một cách đều đặn.
Ngược
lại, trong trường hợp khác giá trị timestamp sẽ tăng không đều đặn.
- SSRC (Synchronization Source Identiíier): 32 bits. Giá trị của trường
SSRC chỉ ra nguồn đồng bộ (nguồn phát gói tin RTP từ micro, camera hay

RTP
mixer) của gói tin RTP, giá trị này được chọn ngẫu nhiên. Trong một phiên kết
nối RTP thì có nhiều nguồn đồng độ phát ra nhiều dịng gói tin RTP. Máy thu
sẽ
nhóm các dịng gói tin RTP cùng nguồn để phát lại tín hiệu thời gian thực
(realtime).
- CSRC (Contributing Source List): từ 0 đến 15 items, 32 bits. Trường
CSRC xác định các nguồn đóng góp payload cho gói tin (CSRC cho phép xác
định tối đa 15 nguồn đóng góp tương ứng vớ 15 items). Giá trị của CSRC được
cho bởi trường CC và giá trị này được chèn vào mỗi items bằng các bộ trộn
(mixer).
-


-

Phần header mở rộng: Cơ chế mở rộng của RTP cho phép những ứng
dụng riêng lẻ của giao thức RTP thực hiện được với những chức năng mới đòi
hỏi những thơng tin thêm vào phần header của gói tin. Cơ chế này được thiết
kế
để một vài ứng dụng có thể bỏ qua một số ứng dụng khác lại có thể sử dụng
được phần nào đó. Nếu như trường X (bit X) trong phần header cố định được
đặt
bằng 1 thì theo sau phần header cố định là phần header mở rộng có chiều dài
thay đổi. 16 bit đầu tiên của trong phần tiêu đề được sử dụng với mục đích
riêng
cho từng ứng dụng được định nghĩa bởi profile (thường nó được sử dụng để
phân biệt các loại tiêu để mở rộng). 16 bits kế tiếp mang giá trị chiều dài
củaphần header mở rộng tính theo đơn vị là 32 bits (Giá trị này không bao gồm
32

bit đầu tiên của phần header mở rộng)

CHƯƠNG 3: GIAO THỨC RTCP
3.1ĐỊNH NGHĨA
Giao thức RTCP (Realtime Transport Control Protocol) là giao thức điều
khiển được thiết kế để hoạt động kết hợp với RTP, dựa trên việc truyền đều đặn
các gói điều khiển tới tất cả các người tham gia vào phiên truyền RTCP cung
cấp thông tin về các gói tin nhận được, cung cấp thơng tin phản hồi để theo dõi
về chất lượng dịch vụ hội nghị và thông tin về các thành viên tham gia hội nghị
để giúp kiểm soát phiên làm việc.
Trong một phiên RTP, thường chỉ có một địa chỉ multicast duy nhất và tất
cả các gói tin RTP và RTCP đều phụ thuộc vào phiên làm việc IP multicast. Gói
tin RTP và RTCP được phân biệt với nhau bằng việc sử dụng cổng riêng,
thường thì số cổng của RTCP được tạo từ cổng RTP cộng thêm một.
3.2CHỨC NĂNG VÀ HOẠT ĐỘNG CỦA RTCP
Giao thức này dung để điều khiển các gói mang tin trong phiên truyền của
mỗi thành viên, được phân phối theo cùng cơ chế với các gói mang tin. Các giao
thức lớp dưới phải đảm bảo các gói mang dữ liệu RTP và các gói mang thơng tin
điều khiển RTCP được truyền trên 2 cổng UDP khác nhau. Thường thì các gói
mang thơng tin điều khiển sẽ là cổng lẻ, các gói mang dữ liệu sẽ là cồng chẵn.


Giao thức RTCP được sử dụng với một số chức năng sau:
-

Cung cấp các thông tin phản hồi về chất lượng của đường truyền dữ
liệu: Đây là một phần không thể thiếu được với vai trò là một giao thức giao
vận, nó liên quan đến các hàm điều khiển luồng (flow control) và kiểm soát sự
tắc nghẽn (congestion control). Chức năng này được thực hiện dựa trên các
bản

tin thông báo từ phía người gửi và phía người nhận. Thơng tin hồi đáp có thể
được sử dụng trực tiếp cho việc điều khiến việc thay đổi phương pháp mã hoá
(adaptive encoding). Trong trường hơn truyền IP multicast thì các thơng tin hồi
tiến từ nhía người nhận là tối quan trọng cho việc chuẩn đốn các sự cố xảy ra
trong q trình truyền, Ngoài ra, việc các bản tin phản hồi từ phía người nhận
đến tất cả các thành viên khác giúp cho mỗi thành viên có thể quan sát lỗi và
đánh giá xem lỗi xảy ra với mình là lỗi cục bộ hay là lỗi trên toàn mạng. Với
cơ
chế truyền IP multicast, có thể cần đến một thực thể đóng vai trị của nhà cung
cấp dịch vụ, nhận các thơng tin phản hồi. Thực thế này đóng vai trị bên thứ 3,
quan sát và phân tích các vấn đề xảy ra.


Xác định nguồn: RTCP mang một thông tin định danh ở lớp giao vận gọi
là CNAME (canonical name). Thông tin này giúp ta định danh một nguồn phát
RTP(tương ứng với 1 thành viên tham gia hội thảo). Trong 1 phiên truyền RTP,
khi giá trị của SSRC của phía phát thay đổi có thể gây ra xung đột sẽ địi hỏi
thiết lập lại kết nối. Do đó phía nhận cần sử dụng CNAME để duy trì kết nối
tới
từng thành viên. Ngồi ra, việc CNAME có thể xác định được từng thành viên,
giúp cho bên nhận có thể phân chia những luồng tin nhận được thành từng tập
tương ứng với từng người gửi. Ví dụ, xác định một cặp tín hiệu video/audieo
của
cùng một người gởi (vì 2 luồng này có định danh SSRC khác nhau). Điều
nàygiúp cho việc đồng bộ tín hiệu audio với tín hiệu video, RTCP cịn cung
cấp
thơng tin nhận dạng nguồn cụ thể hơn ở dạng văn bản. Nó Có thể bao gồm tên
người sử dụng, số điện thoại, địa chỉ e-mail và các thông tin khác.
- Đồng bộ thời gian: Các thông báo của bộ phát RTCP chứa thông tin để
xác định thời gian NTP và nhãn thời gian RTP tương ứng. Chúng có thể được

sử
dụng để đồng bộ giữa âm thanh với hình ảnh,
- Điều chỉnh tốc độ truyền các gói RTCP: Hai chức năng đầu địi hỏi tất
cả các thành viên đều phải gửi đi các gói RTCP. Do vậy, trong trường hợp có
một số lượng lớn người cùng tham gia hội thảo, đòi hỏi phải có sự điều chỉnh
tốc độ cho phù hợp để dành tài nguyên cho các gói RTP. Dựa vào việc mỗi
thành viên gửi gói tin điều khiển của mình tới tất cả các thành viên khác, mỗi
thành viên có thể độc lập quan sát số lượng người tham gia. Con số này sẽ
được
dùng để tính tốn tốc độ truyền thơng điệp.
-

-Chức năng tùy chọn: Cho phép tùy chọn các chức năng, giúp giảm tối đa
các việc truyền các thông tin điều khiển. Điều này rất hữu ích trong các phiên
truyền “loosely controlled”, các thành viên có thể tham gia hoặc rời bỏ mà
không điều khiển quan hệ tới các thành viên khác. Ví dụ, một thành viên chỉ cần
nghe các thơng tin chuyển tới, như một RTCP Server. Nó có thể sử dụng một
kênh thích hợp kết nối với tất cả thành viên, nhưng nó khơng cần sử dụng tất cả
các chức năng của một ứng dụng.

3.3CÁC LOẠI GÓI TIN RTCP:
-

RR (Receiver Report): Thông điệp RR được tạo ra để báo cáo về việc
thu nhận của máy thu trong một phiên làm việc RTP và nó sẽ được đưa vào


một
gói tin RTCP. Gói tin này sau đó sẽ được gửi vào cây multicast để kết nối với
tất

cả phiên làm việc khác. Thông điệp RR chứa thông tin: SSRC của luồng RTP,
số lượng gói tin RTP bị mất, các số sq number cuối nhận được trong luồng
RTP,
độ jitter trong truyền gói.
- SR (Sender Report): Máy phát tạo ra thơng điệp SR để truyền đi vào các
luồng RTP, thông điệp này chứa các thông tin: SSRC của luồng RTP,
timestamp
và thời gian wall clock của gói tin RTP được tao ra gần đây nhất, số lượng gói
tin được gửi đi trong luồng, số lượng byte được gửi đi trong luồng. Ngồi ra,
SR
cịn có thể đồng bộ các luồng dữ liệu đa phương tiện khác nhau trong một
phiên
làm việc RTP.
- SDES (Source Description Items): Các thông điệp SDES được máy phát
tạo ra và truyền trên luồng RTP chứa các thông tin: điểm bắt đầu (như địa chỉ
mail của người gửi, tên người gửi), giá trị SSRC của luồng RTP kết hợp.


BYE (End of participation): Nguồn phát sẽ gửi thông điệp BYE đến
điểm cuối (end-point) nhằm mục đích tắt luồng truyền RTP.
- APP (Application-specific message): Thông điệp APP chứa các chức
năng cụ thể của các ứng dụng.
-

3.4Khoảng thời gian giữa hai lần phát hợp gói RTCP
Các hợp gói của RTCP được phát đi một cách đều đặn sau những khoảng
thời gian bằng nhau để thường xuyên thông báo về trạng thái các điểm cuối
tham gia. Vấn đề là tốc độ phát các hợp gói này phải đảm bảo khơng chiếm hết
lưu lượng thông tin dành cho các thông tin khác.
Trong một phiên truyền, lưu lượng tổng cộng cực đại của tất cả các loại

thông tin truyền trên mạng được gọi là băng thông của phiên (session
bandwidth). Lưu lượng này được chia cho các bên tham gia vào cuộc hội nghị.
Lưu lượng này được mạng dành sẵn và không cho phép vượt quá để không ảnh
hưởng đến các dịch vụ khác của mạng. Trong mỗi phần băng thông của phiên
được chia cho các bên tham gia phần lưu lượng dành cho các gói RTCP chỉ
được phép chiếm một phần nhỏ và đã biết là 5% để khơng ảnh hưởng đến chức
năng chính của giao thức là truyền các dòng dữ liệu media.

3.5Phân tích cụ thể từng loại thơng điệp
3.5.1 Khn dạng gói RR
Gói RR (Receiver Report) có khn dạng giống như gói SR ngoại trừ
trường hợp PT mang giá trị bằng 201 và không mang phần thông tin về nguồn
gửi. Khuôn dạng gói RR được miêu tả trong.


023

8

16

v=2 p RC

31

PT=201

length

SSRC của nguồn gửi gỏi RR

SSRC^l (SSRC của nguồn đồng bõ thứ nhất)
fraction lost

cumulaŨMe HUíTtber of packets last

extended htghest seạuence numtoer received
interarrivaỉ "itter
last SR (LSR)
de lay since last £R (ĐLSR)
SSRC_2 (SSRC của nguồn dóng bỏ thứ hai}

«-■ V

prohle-speciíĩc extension
Khn íiạng gói RR

3.5.2

Khn dạng gói SDES

Gói SDES (System Description).
Gói SDES có khn dạng như trong hình 3.10 bao gồm một phần tiêu đề
và các đoạn thông tin mô tả nguồn.
3.5.2.1 Phần tiêu đề
Các trường V (version), P (padding), length, PT (packet type) mang ý
nghĩa giống như của gói SR, PT bằng 202.
- SC (Source count): 5 bits.
-

Số lượng của các đoạn thông tin mô tả nguồn.



Khuôn dạng gỏi SDES

3.5.2.2

Phần miêu tả nguồn

Mỗi đoạn thông tin miêu tả nguồn bao gồm một cặp số nhận dạng nguồn
SSRC/CSRC theo sau đó là các mục miêu tả (SDES Items). Các mục miêu tả có
cấu trúc chung như hình.
0

8
hem

Mục miêu

length

16

31
Thông tin mờ tả nguồn

tả

Item (8 bits): chỉ thị loại mục mô tả. Giá trị của trường này tương ứng với
các loại mục miêu tả sau:
-


CNAME (Canonical Name) (item =1): Phần thông tin mô tả mang số
nhận dạng tầng giao vận cố định đối với một nguồn RTP.
NAME (item = 2): phần thông tin mô tả mang tên mô tả nguồn.
EMAIL (item = 3): Thông tin mô tả là địa chỉ Email của nguồn.
PHONE (item = 4): Thông tin mô tả là số điện thoại của nguồn.
LOC (item = 5): Thông tin mô tả là địa chỉ của nguồn.
TOOL (item = 6): Thông tin mô tả là tên của ứng dụng tạo ra dịng thơng
tin media.
NOTE (item = 7): Các chú thích về nguồn.
PRIV (item = 8): Dành cho các thơng tin khác.

3.5.3 Khn dạng gói BYE
Gói BYE được sử dụng để thông báo một hay một vài nguồn sẽ rời
khỏi phiên truyền. Trường thông tin về lý do rời khỏi phiên là tùy chọn
(có thể có hoặc khơng).


3.5.4 Khn dạng gói APP
Khn dạng gói APP được miêu tả trong hình dưới. Gói này được sử
dụng để dành cho các chức năng cụ thể của từng ứng dụng.