tìm hiểu về giao thức truyền tải thời gian thực rtp

Tiểu luận Internet và Giao thức
Đề tài: Tìm hiểu về giao thức truyền tải thời gian thực RTP
(Real-time Transport Protocol)
Mục lục
Lời nói đầu
Danh mục hình vẽ
Danh mục bảng biểu
Thuật ngữ viết tắt
Chương 1 Giới thiệu tổng quan về RTP
1.1. Sự phát triển của các ứng dụng tương tác thời gian thực
Việc truyền tải âm nhạc, lời nói, các audio cũng như video có tính tương tác cao
đang ngày càng trở nên phổ biến và thay thế dần cho việc truyền tải các luồng
video, text có nội dung tĩnh trên mạng internet. Những thay đổi này đòi hỏi việc
đặt ra các ứng dụng mới, điều này đặt ra các thách thức mới cho các nhà thiết kế
ứng dụng.
Một thách thức đặt ra trong việc thiết kế các ứng dụng là phải đảm bảo được sự
phân phối đáng tin cậy của audio và video trên một mạng IP khi đối mặt với các
vấn đề của mạng. Vì vậy, các tổ chức tiêu chuẩn như IETF (Internet Engineering
Task Force) và ITU (International Telecommunications Union- Liên minh Viễn
thông Quốc tế) đã xây dựng các tiêu chuẩn cho lớp ứng dụng này mà dựa vào đó,
các công ty độc lập sẽ có khả năng xây dựng các sản phẩm mới, dễ dàng hoạt động
tương hợp với nhau.
Hình 1.: Chồng giao thức IETF và ITU cho việc truyền audio/video trên Internet
1.2. Giới thiệu giao thức truyền tải thời gian thực RTP
Một trong các giao thức được xây dựng cho các ứng dụng tương tác là giao thức
truyền tải thời gian thực RTP. RTP được phát triển bởi IETF trong giai đoạn 1992-
1996, được định nghĩa cũng như trình bày rõ ràng trong RFC 1889 xuất bản năm
1996, và được thay thế bởi RFC 3550 vào năm 2003.
Trong RFC 3550, RTP được mô tả là một giao thức cung cấp các chức năng truyền
tải mạng đầu cuối tới đầu cuối phù hợp cho các ứng dụng truyền dữ liệu thời gian
thực, chẳng hạn như audio, video hoặc dữ liệu mô phỏng qua các dịch vụ mạng đa

hướng (multicast) hay đơn hướng (unicast). RTP không đề cập đến việc dự phòng
tài nguyên và cũng không cung cấp các đảm bảo chất lượng QoS cho các dịch vụ
thời gian thực. Việc truyền dữ liệu được bổ sung bằng một giao thức điều khiển
RTCP để cho phép giám sát việc phân phối dữ liệu để có thể mở rộng các mạng đa
hướng (multicast) lớn và để cung cấp chức năng kiểm soát và nhận dạng tối thiểu.
RTP và RTCP được thiết kế để được độc lập bên dưới lớp truyền tải và lớp mạng.
Hỗ trợ việc sử dụng giao thức RTP là các bộ dịch và bộ trộn RTP.
RTP cung cấp các dịch vụ phân phối end-to-end cho dữ liệu có các đặc trưng của
thời gian thực, như là audio/video có tính tương tác. Các dịch vụ này bao gồm
nhận dạng loại tải trọng, gắn số thứ tự, nhãn thời gian và kiểm tra việc phân phối
đối với các khúc audio/video trước khi đưa chúng tới tầng truyền tải.
Các ứng dụng cơ bản sẽ chạy giao thức RTP trên UDP để thực hiện sử dụng các
dịch vụ kết hợp và kiểm tra; cả hai giao thức đóng góp một phần vào chức năng
của giao thức truyền tải. Tuy nhiên, RTP có thể được sử dụng với các giao thức
phù hợp khác nằm bên dưới lớp mạng hoặc lớp truyền tải. RTP hỗ trợ truyền tải dữ
liệu tới nhiều đích đến bằng cách sử dụng việc phân bổ đa hướng (multicast) nếu
chúng được hỗ trợ ở bên dưới lớp mạng.
Cần nhấn mạnh rằng RTP bản thân nó không cung cấp bất kì cơ chế nào để đảm
bảo việc chuyển phát dữ liệu đúng thời hạn hay cung cấp đảm bảo các đảm bảo
chất lượng QoS, độ tin cậy sẽ dựa vào các dịch vụ lớp dưới. Thậm chí nó cũng
không đảm bảo chuyển gói tin đến đích hay ngăn ngừa chuyển gói tin đến sai thứ
tự. Các trường số thứ tự (sequence number) trong RTP cho phép bên nhận được
xây dựng lại chuỗi gói tin của bên gửi, cũng có thể được sử dụng để xác định chính
xác vị trí của gói tin, ví dụ trong việc giải mã video mà không có các gói tin mã
hóa cần thiết trong chuỗi.
RTP được thiết kế để đáp ứng nhu cầu của các hội nghị đa phương tiện đa thành
viên nhưng lại không được giới hạn các ứng dụng cần thiết. Sự tích lũy của dữ liệu
liên tục, mô phỏng phân bố các tác động qua lại, dấu hiệu hoạt động và các ứng
dụng điều khiển, đo lường có thể cũng tìm kiếm RTP thích hợp.
Chương 2 Giao thức truyền tải thời gian thực RTP

2.1. Khái niệm cơ bản liên quan đến RTP
Trước khi đi vào tìm hiểu cụ thể về giao thức RTP, chúng ta cần phải nắm được
một số khái niệm cơ bản sau đây:
- RTP payload: phần dữ liệu được truyền tải trong một gói tin RTP, ví dụ các
mẫu audio hoặc dữ liệu video đã được nén. Việc phân định dạng dữ liệu
(được chỉ định bởi trường Payload type) sẽ được đề cập đến trong phần sau.
- RTP packet: một gói dữ liệu RTP, bao gồm phần cố định RTP header, phần
danh sách các nguồn phân tán (có thể rỗng), phần dữ liệu payload. Một số
giao thức tầng dưới có thể yêu cầu phải đóng gói lại các gói RTP. Thông
thường một gói của giao thức lớp dưới chứa một gói RTP. Tuy nhiên cũng có
trường hợp nhiều gói RTP được đóng gói vào một gói, điều này hoàn toàn
phụ thuộc vào cách đóng gói của lớp dưới.
- RTCP packet: gói tin điều khiển RTCP bao gồm phần tiêu đề cố định gần
giống gói RTP, phần có cấu trúc mà dạng của cấu trúc tùy thuộc vào loại gói
RTCP. Thông thường một số gói RTCP sẽ được ghép chung trong một gói
của lớp dưới. Việc này có thể được thực hiện do các gói RTCP có phần tiêu
đề cố định.
- Port: cổng địa chỉ UDP được sử dụng. đây là khái niệm trừu tượng mà các
giao thức truyền tải sử dụng để phân biệt các phiên truyền. Với giao thức
TCP/IP, port là số nguyên dương 16 bit được chèn vào phần đầu của mỗi gói
tin. Khái niệm port tương đương với khái niệm TSEL (transport selectors-
bộ chọn lọc truyền tải) trong mô hình OSI. RTP dựa trên cac cơ chế tương tự
sự phân cổng được cung cấp bởi giao thức lớp dưới để gửi đồng thời các gói
dữ liệu RTP và gói tin điều khiển RTCP trong mỗi phiên truyền.
- Transport address: là tổ hợp một địa chỉ mạng và cổng được định nghĩa ở
tầng giao vận, ví dụ như một địa chỉ IP và một cổng UDP nhất định. Các gói
tin được truyền từ transport address của nguồn tới transport address của
đích.
- RTP media type: một tập hợp các loại tải có cùng tính chất được mang
trong phiên truyền RTP. Trong hội thảo đa phương tiện, có thể có hai loại

RTP media type là video-MPEG2 và audio-PCMA.
- Multimedia session: một tập hợp các phiên RTP đồng trời trong một nhóm
chung của người tham gia. Ví dụ, một hội nghị truyền hình (mà là một
multimedia session) có thể chứa một phiên RTP audio và một phiên RTP
video.
- RTP session: một liên kết giữa tập hợp các thành viên cùng tham gia giao
tiếp với RTP. Một người tham gia có thể tham gia nhiều phiên RTP cùng một
lúc. Trong một phiên họp đa phương tiện, mỗi phương tiện được thực hiện
trong một phiên RTP riêng biệt với các gói RTCP riêng của mình. Mỗi
thành viên được xác định dựa trên cặp địa chỉ nguồn (một dùng truyền gói
RTP, một dùng truyền gói RTCP). Cặp địa chỉ đích có thể là chung cho tất cả
các thành viên còn lại (trong trường hợp truyền đa hướng multicast) hoặc
riêng biệt cho từng thành viên (trong trường hợp truyền đơn hướng unicast).
Trong một phiên truyền multimedia, các tín hiệu thành phần (video/audio)
được truyền theo một cặp cổng riêng.
- Synchronization source (SSRC) (nguồn đồng bộ): nguồn phát dòng các
gói tin RTP, được định danh bởi 32 bits SSRC trong phần tiêu đề gói RTP.
Nó có giá trị hoàn toàn độc lập với địa chỉ mạng. Các gói dữ liệu được phát
từ một nguồn được gắn thời gian và số thứ tự một cách thống nhất. Do đó
phía thu sẽ dựa trên SSRC để khôi phục lại tín hiệu. Giá trị của định danh
SSRC của mỗi nguồn RTP là đơn trị trên toàn mạng, nó được khởi tạo một
cách ngẫu nhiên.
- Contributing source (CSRC) (nguồn truyền báo): nguồn của một dòng
của các gói tin RTP được tổng hợp nhờ bộ RTP mixer (bộ trộn RTP). Bộ
mixer chèn một danh sách các định danh SSRC của nguồn để tạo ra một gói
tin đặc biệt bằng cách gán vào phần tiêu đề của gói tin đó. Danh sách này
được gọi là danh sách CSRC. Việc này giúp cho bên nhận có thể dễ dàng
phân tách địa chỉ SSRC tương ứng với từng nguồn gói.
- End system: một ứng dụng tạo ra các nội dung được gửi trong các gói tin
RTP và/hoặc xử lý nội dung của gói tin RTP nhận được. Một end system có

thể hoạt động như một hoặc nhiều nguồn đồng bộ trong một phiên RTP cụ
thể, tùy thuộc vào số định danh SSRC mà nó sử dụng.
- Mixer (bộ trộn): đây là một hệ thống trung gian, có thể nhận các gói RTP từ
một hoặc nhiều nguồn đồng bộ khác nhau. Do đó dạng của dữ liệu thu được
có thể khác nhau. Mixer sẽ kết hợp các gói có cùng dạng rồi chuyển tiếp
trong một gói RTP mới. Khi đó thời gian được gắn theo các gói tin sẽ bị mất
đồng bộ nên bộ mixer sẽ thay đổi lại các nhãn thời gian cho thích hợp với
mỗi luồng ra. Bộ mixer khi hoạt động sẽ đóng vai trò như một nguồn đồng
bộ.
- Translator (bộ dịch): đây là một hệ thống trung gian có nhiệm vụ chuyển
tiếp các gói RTP mà không làm thay đổi giá trị của SSRC
- Monitor (bộ giám sát): một ứng dụng nhận gói tin RTCP được gửi bởi
người tham gia trong một phiên RTP, đặc biệt là báo cáo cụ thể sự tiếp nhận,
ước lượng chất lượng dịch vụ hiện thời để giám sát sự phân phối, chẩn đoán
lỗi và thống kê dài hạn. Chức năng của monitor có thể được xây dựng bởi
các ứng dụng có thể tham gia trong phiên hoặc không và không nhận hoặc
gửi đi các gói dữ liệu RTP. Đây được gọi là các bộ monitor tham gia thứ ba.
Bộ monitor thứ ba có thể nhận gói dữ liệu RTP nhưng không được gửi đi gói
RTCP hoặc được tính trong phiên.
- Non-RTP means: dùng để chỉ các giao thức hay các cơ chế được sử dụng để
kết hợp với RTP để tạo ra những dịch vụ cụ thể, khả dụng.
2.2. Các trường tiêu đề RTP
Tiêu đề RTP được định dạng theo khuôn mẫu dưới đây:
Hình 2.: Cấu trúc RTP header
Hình 2.1 biểu diễn các trường có mặt trong RTP header, trong đó thì 12 octets
(byte) đầu tiên là cố định cho mọi gói tin RTP trừ trường CSRC identifier chỉ xuất
hiện khi được thêm vào bởi một bộ mixer. Các trường có ý nghĩa như sau:
- version (V): 2 bits
Đây là trường định nghĩa phiên bản của RTP. Trường version được xác định là (2).
Giá trị (1) được sử dụng để mô tả phiên bản nháp đầu tiên của RTP và giá trị (0)

được sử dụng để biểu diễn cho các giao thức được bổ sung ban đầu trong công cụ
“vat” audio.
- padding (P): (trường đệm)
Nếu bit padding được lập, gói dữ liệu sẽ có một vài octets thêm vào cuối gói dữ
liệu. Octet cuối cùng của phần thêm vào này sẽ chỉ kích thước của phần thêm vào
(tính theo byte). Những octets này không phải là thông tin. Chúng được thêm vào
để đáp ứng các yêu cầu sau: phục vụ cho một vài thuật toán mã hóa thông tin cần
kích thước dữ liệu xác định để có thể thực hiện, hoặc dùng để 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 tầng dưới.
- extension (X): 1 bit
Nếu như bit extension được lập, theo sau phần tiêu đề cố định sẽ là một tiêu đề mở
rộng.
- CSRC count (CC): 4 bits
Trường này xác định số lượng các định danh CSRC có trong danh sách được lưu
trữ sau phần tiêu đề cố định.
- marker (M): 1 bit.
Tùy từng trường hợp cụ thể mà bit này mang những ý nghĩa khác nhau ý nghĩa của
nó được chỉ ra trong một profile đi kèm. Nó bao gồm các thông tin về các sự kiện
quan trọng như việc đánh dấu các biên của frame trong luồng packet. Profile có thể
định nghĩa thêm các bit đánh dấu (marker) hoặc xác định rằng không có bit đánh
dấu nào bằng cách thay đổi số lượng bit trong trường payload type.
- payload type (PT): 7 bits.
Trường này cho biết định dạng của RTP payload và xác định loại mã hóa mà ứng
dụng sử dụng. Các mã sử dụng trong trường này ứng với các loại tải trọng được
quy định trong một profile đi kèm. Nếu bên gửi quyết định thay đổi mã hóa trong
phiên, bên gửi có thể thông báo với bên nhận về thay đổi này thông qua trường
payload type. Bên gửi có thể muốn thay đổi mã hóa để tăng chất lượng audio/video
hay giảm tốc độ bit luồng RTP. Bảng 2.1 và 2.2 dưới đây sẽ liệt kê một số loại tải
trọng hiện đang được RTP hỗ trợ.

Số của payload type Khuôn dạng
audio
Tốc độ lấy mẫu
(kHz)
Tốc độ
(kbps)
0 PCM µ 8 64
1 1016 8 4.8
3 GSM 8 13
7 LPC 8 2.4
9 G.722 16 48-64
14 MPEG Audio 90 -
15 G.728 8 16
Bảng 2.: Một số loại payload type audio được RTP hỗ trợ
Số của payload type Khuôn dạng video
26 JPEG hình ảnh động
31 H.261
32 Video MPEG1
33 Video MPEG2
Bảng 2.: Một số loại payload type video được RTP hỗ trợ
- sequence number: 16 bits.
Mang số thứ tự của gói RTP. Số thứ tự này được tăng lên một sau mỗi gói RTP
được gửi đi. Trường này có thể được sử dụng để bên thu phát hiện được sự mất gói
và khôi phục lại trình tự đúng của các gói như khi truyền. Giá trị khởi đầu của
trường này là ngẫu nhiên, không thể dự đoán trước làm cho sự tấn công vào dữ liệu
mã hóa trong quá trình mã hóa gặp khó khăn hơn bởi vì một gói tin có thể được
truyền qua translator để thực hiện mã hóa mặc dù bản thân bên nguồn không thực
hiện mã hóa. Có rất nhiều kỹ thuật tạo ra một số ngẫu nhiên không thể dự đoán
trước được.
- timestamp (nhãn thời gian): 32 bits.

Trường timestamp phản ánh thời điểm lấy mẫu của byte đầu tiên trong gói tin dữ
liệu RTP. Thời điểm lấy mẫu này phải được lấy từ một đồng hồ tăng đều đặn và
tuyến tính theo thời gian để cho phép việc đồng bộ và tính toán độ jitter. Bước tăng
của đồng hồ này phải đủ nhỏ để đạt được độ chính xác đồng bộ mong muốn khi
phát lại và độ chính xác của việc tính toán jitter. Tần số đồng hồ này là không cố
định, tùy thuộc vào loại khuôn dạng của tải trọng. Giá trị khởi đầu của nhãn thời
gian cũng được chọn một cách ngẫu nhiên. Một vài gói RTP có thể mang cùng một
giá trị nhãn thời gian 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 nhau (tín hiệu đã mã hóa thoại tốc
độ cố định, fixed-rate audio) thì nhãn thời gian được tăng một cách đều đặn. Trong
trường hợp khác giá trị nhãn thời gian sẽ tăng không đều.
- SSRC Identifiers: 32 bits.
Trường SSRC chỉ ra nguồn đồng bộ của gói RTP. Định danh này được chọn một
cách ngẫu nhiên nhằm mục đích để bất cứ hai nguồn đồng bộ nào trong cùng một
phiên RTP không có cùng một định danh. Tuy nhiên, các cài đặt của RTP phải
chuẩn bị cho việc phát hiện và xử lý đụng độ. Trong một phiên RTP có thể có
nhiều hơn một nguồn đồng bộ. Mỗi một nguồn phát ra một dòng các gói RTP. Bên
thu nhóm các gói của cùng một nguồn đồng bộ lại với nhau để phát lại tín hiệu thời
gian thực. Nguồn đồng bộ có thể là nguồn phát các gói RTP phát ra từ một micro,
camera hay một RTP mixer.
- CSRC list: Có từ 0 đến 15 mục mỗi mục 32 bits
Danh sách CSRC xác định các số nhận dạng nguồn đóng góp trong phần tiêu đề,
chỉ ra những nguồn đóng góp thông tin và phần tải trọng của gói. Các số nhận dạng
này được Mixer chèn vào tiêu đề của gói và nó chỉ mang nhiều ý nghĩa trong
trường hợp dòng các gói thông tin là dòng tổng hợp tạo thành từ việc trộn nhiều
dòng thông tin tới mixer. Trường này giúp cho bên thu nhận biết được gói thông tin
này mang thông tin của những người nào trong một cuộc hội nghị. Số lượng các số
nhận dạng nguồn đóng góp được xác định trong trường CC của phần tiêu đề. Số
lượng tối đa của các số nhận dạng này là 15. Nếu có nhiều hơn 15 nguồn đóng góp

thông tin vào trong gói thì chỉ có 15 số nhận dạng được liệt kê vào danh sách.
Mixer chèn các số nhận dạng này vào gói nhờ số nhận dạng SSRC của các nguồn
đóng góp.
2.3. Cấu trúc phần tiêu đề mở rộng (RTP Header Extension)
Một cơ chế mở rộng được cung cấp để cho phép thử nghiệm thức thi những chức
năng định dạng độc lập payload mới yêu cầu các thông tin bổ sung cần được mang
theo trong tiêu đề RTP. Cơ chế này được thiết kế để phần tiêu đề mở rộng có thể
được bỏ qua bởi các thực thi khác không hỗ trợ.
Chú ý rằng phần tiêu đề mở rộng này chỉ được giới hạn sử dụng. Hầu hết các khả
năng sử dụng của cơ chế này sẽ được thực hiện tốt hơn bất kì cách nào khác.
Thông tin thêm vào đòi hỏi cho mỗi định dạng payload không nên sử dụng cho
phần tiêu đề mở rộng nhưng nên được thực hiện trong phần payload của gói dữ
liệu.
Hình 2.: Cấu trúc phần tiêu đề mở rộng
Nếu như bit X trong phần tiêu đề cố định được đặt bằng 1 thì theo sau phần tiêu đề
cố định là phần tiêu đề mở rộng có chiều dài thay đổi được nối thêm vào ngay sau
phần danh sách CSRC nếu danh sách này có trong phần tiêu đề. Phần tiêu đề mở
rộng có một trường dài 16 bit cho biết chiều dài của nó tính theo word (32 bit) trừ
phần tiêu đề phụ dài 4 byte. Chỉ có thể thêm được một phần tiêu đề mở rộng vào
RTP header. Tuy nhiên 16 bit đầu tiên trong phần tiêu đề mở rộng đượ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. Tiếp theo là trường length có
độ dài 16 bits. Mang giá trị chiều dài của phần tiêu đề mở rộng tính theo đơn vị là
word (32 bit).
Phần tiêu đề mở rộng phải đảm bảo một số điều kiện : trong suốt đối với các hàm
xử lý gốc; các tiêu đề mở rộng khác loại không ảnh hưởng đến nhau; một hàm cài
đặt mở rộng có thể tương thích với nhiều hơn 1 loại tiêu đề mở rộng.
Để thực hiện những yêu cầu trên, phần tiêu đề mở rộng phải được thiết kế với 16
bit đầu tiên được dùng cho việc nhận ra định danh hoặc tham số.
2.4. Ghép kênh các phiên RTP

Để xử lý một cách hiệu quả thì số lượng các phiên RTP được đem ghép kênh phải
càng nhỏ càng tối. Trong RTP, sự ghép kênh được thực hiện nhờ vào địa chỉ truyền
đích (địa chỉ mạng và số cổng) xác định nên một phiên RTP. Ví dụ: trong một cuộc
hội thảo từ xa bằng âm thanh và hình ảnh mà các dữ liệu này được mã hóa bởi hai
bộ phận riêng biệt thì các dữ liệu này nên được truyền trên hai phiên RTP khác
nhau với địa chỉ truyền đích riêng. Nếu truyền chung trong một phiên RTP, việc
xen kẽ các gói với các kiểu payload khác nhau nhưng cùng một định danh SSRC sẽ
dẫn đến một số vấn đề sau:
1. Nếu hai luồng âm thanh được chia sẻ trong cùng một phiên RTP với cùng
một giá trị SSRC và một trong hai luồng được mã hóa khác đi dẫn đến loại
payload khác nhau. Khi đó sẽ không có cách nào xác định loại payload của
luồng đã thay đổi cách mã hóa.
2. SSRC được định nghĩa để xác định một cách tính thời gian và không gian số
thứ tự riêng. Do đó, việc truyền xen kẽ nhiều loại payload sẽ cần nhiều cách
tính thời gian khác nhau và cũng sẽ cần nhiều không gian số thứ tự hơn để
biết các gói tin của loại payload nào bị mất.
3. Thông báo của bên gửi và bên nhận RTCP có thể chỉ mô tả một cách tính
thời gian và một không gian số thứ tự riêng cho mỗi một SSRC và không
kèm theo trường payload type.
4. Bộ RTP mixer không thể kết hợp các luồng dữ liệu xen kẽ không tương thích
nhau thành một luồng.
5. Truyền nhiều loại dữ liệu trong cùng một phiên RTP sẽ không có được các
khả năng: sử dụng sự phân phối các đường mạng và tài nguyên mạng khác
nhau nếu có thể; chỉ nhận được một số loại dữ liệu trong số nhiều loại yêu
cầu ví dụ như chỉ nhận được âm thanh nếu tín hiệu hình ảnh vượt quá băng
thông; bên nhận cài đặt các xử lý riêng cho mỗi loại dữ liệu; việc dùng nhiều
phiên RTP cho phép các cài đặt đơn hoặc đa xử lý.
Sử dụng định danh SSRC khác nhau cho mỗi loại dữ liệu nhưng gửi trong cùng
một phiên RTP giống nhau sẽ tránh được ba vấn đề đầu tiên nhưng không tránh
được hai vấn đề cuối.

Một cách khác, ghép kênh các nguồn đa phương tiện của cùng một loại dữ liệu
trong một phiên RTP sử dụng các giá trị SSRC khác là quy tắc cho các phiên đa
hướng (multicast). Các vấn đề liệt kê bên trên không áp dụng cho: một bộ RTP
mixer có thể kết hợp các nguồn âm thanh mà sử dụng cùng một cách xử lý cho tất
cả. Điều này cũng có thể thích hợp để ghép các luồng của cùng một loại dữ liệu sử
dụng giá trị SSRC khác nhau trong các kịch bản khác nhau (hai vấn đề cuối không
áp dụng).
2.5. Những thay đổi trong đặc tả profile của RTP header
Cấu trúc hiện tại của phần tiêu đề RTP được coi là đầy đủ để đáp ứng tất cả các
chức năng cho mọi lớp ứng dụng mà RTP có thể hỗ trợ. Tuy nhiên, với nguyên lý
thiết kế ALF, tiêu đề RTP có thể được cải tiến bằng cách chỉnh sửa hoặc thêm vào
các định nghĩa mới đặc tả profile của nó trong khi vẫn cho phép các công cụ quản
lí và ghi nhận hoạt động độc lập với profile.
- Bit marker và trường payload type mang thông tin đặc trưng của profile,
nhưng chúng được định vị trong phần tiêu đề cố định vì có rất nhiều ứng
dụng cần đến chúng, và nếu không thì có thể đã phải tăng thêm một word
(32 bits) chỉ để lưu trữ nó. Các octet chứa những trường này có thể được
định nghĩa bởi profile để phù hợp với các yêu cầu khác nhau như thêm hoặc
bớt các bit marker. Nếu có nhiều bit marker, thì một bit sẽ được đặt ở vị trí
quan trọng nhất của octet vì các bộ monitor độc lập với profile có thể sử
dụng bit marker để quan sát sự tương quan giữa việc mất mát gói tin và bit
marker.
- Các thông tin yêu cầu thêm vào cho một định dạng payload cụ thể, như là
mã hóa video, nên được lưu trong phần payload của gói tin. Các thông tin
thêm vào header đều nằm ở phần bắt đầu của payload hiện tại hoặc là được
chỉ định bởi một giá trị dành riêng trong phần dữ liệu.
- Nếu một lớp cụ thể của ứng dụng cần thêm vào các chức năng độc lập với
định dạng của payload thì profile bên dưới của các ứng dụng này sẽ định
nghĩa thêm các trường cố định ngay sau trường SSRC trong phần tiêu đề
chuẩn. Những ứng dụng này sẽ có thể truy xuất nhanh chóng và trực tiếp đến

các trường thêm vào này trong khi các bộ điều khiển và ghi nhận độc lập với
profile vẫn có thể xử lý các gói tin RTP chỉ với 12 octet đầu tiên.
Nếu đến lúc nào đó các chức năng phụ được nhận thấy là cần thiết cho tất cả các
profile thì một phiên bản mới hơn của RTP sẽ được xây dựng để cố định các thay
đổi trong phần tiêu đề.
Chương 3 Các kịch bản sử dụng giao thức RTP
Nội dung chương này sẽ mô tả một số khía cạnh của việc sử dụng RTP. Các ví dụ
đã được lựa chọn để minh họa cho các hoạt động cơ bản của các ứng dụng sử dụng
RTP. Trong các ví dụ này, RTP được thực hiện trên nền IP và UDP, và theo các quy
ước trong RFC 3551.
3.1. Hội thảo audio sử dụng multicast đơn giản.
Nhóm IETF đưa ra ý kiến việc sử dụng dịch vụ IP multicast cho việc truyền tín
hiệu thoại trên mạng Internet. Quan điểm chính là kết hợp việc truyền Multicast và
sử dụng đồng thời hai cổng truyền dữ liệu. Trong đó một cổng sẽ dùng để truyền
các dữ liệu thoại cụ thể, cổng còn lại sẽ sử dụng để truyền các gói tin điều khiển
RTCP. Địa chỉ và cổng thông tin được phân chia cho những người tham gia. Trong
trường hợp cần yêu cầu bảo mật thì dữ liệu và các gói tin điều khiển trước khi
truyền qua hai cổng này sẽ được mã hóa theo chuẩn, các khóa mã cũng sẽ được
sinh ra và truyền kèm theo.
Mỗi thành viên tham gia thoại sẽ gửi dữ liệu thoại theo từng đoạn 20ms của tiếng
nói. Những đoạn dữ liệu này sẽ được gắn thêm phần RTP header; RTP header và
dữ liệu được chứa trong một gói tin UDP. Tiêu đề RTP sẽ xác định loại mã hóa tín
hiệu thoại (PCM, ADPCM…) được mang trong phần dữ liệu, vì vậy kiểu mã hóa
tín hiệu thoại của những thành viên tham gia có thể thay đổi trong quá trình hội
đàm. Điều này rất có ý nghĩa, đặc biệt đối với những thành viên sử dụng đường
truyền tốc độ thấp hay trong trường hợp nghẽn mạng.
Việc truyền các gói tin trên Internet, giống như các mạng chuyển mạch gói khác,
rất có thể xảy ra thất lạc, mất thứ tự các gói tin hay xảy ra Jitter. Để giải quyết vấn
đề này, phần RTP header có chứa thông tin về thời gian và số thứ tự của các gói tin.
Do đó bên thu có thể dựa vào đó để khôi phục lại về mặt thời gian. Trong trường

hợp này, mỗi thành viên sẽ liên tục truyền đi các gói tin với chu kỳ 20ms. Việc
khôi phục thời gian này được biểu diễn riêng cho mỗi nguồn của các gói tin RTP
trong cuộc hội thoại, do đó sẽ giúp cho bên nhận có thể phân được các nguồn tin
khác nhau trong quá trình thoại. Số thứ tự được gán trong phần tiêu đề cũng giúp
cho bên nhận tính toán được bao nhiêu gói tin đã bị mất mát trong quá trình truyền
của mỗi nguồn. Việc này giúp chúng ta đánh giá chất lượng mạng mỗi thành viên.
Trong quá trình hội thoại sẽ có thành viên tham gia hoặc rời đi, vì vậy, sẽ hữu ích
nếu biết được có những ai đang tham gia tại bất kì thời điểm nào và chất lượng dữ
liệu thoại họ thu được có tốt hay không. Để làm được điều đó, những bản tin thông
báo có kèm theo định danh của từng thành viên sẽ được chuyển qua cổng sử dụng
RTCP. Những thông báo này sẽ xác định gói tin do mỗi thành viên gửi đi nhận có
tốt không. Dựa vào đó ta có thể điều chỉnh bộ mã hóa động. Ngoài việc định danh
thành viên, các thông tin xác định khác có thể được sử dụng để điều khiển giới hạn
băng thông của mỗi thành viên. Khi một thành viên rời khỏi hội thoại, họ sẽ gửi
một gói tin RTCP BYE để thông báo.
3.2. Hội thảo sử dụng audio và video.
Hình 2.5 RTP trong hội thảo sử dụng cả video/audio.
Trong trường hợp ta sử dụng đồng thời cả âm thanh và hình ảnh trong hội thảo, dữ
liệu âm thanh và hình ảnh sẽ được truyền trong các phiên RTP riêng biệt. Thật vậy,
các gói tin RTP và RTCP được truyền riêng biệt cho mỗi luồng dữ liệu sử dụng hai
cặp cổng UDP khác nhau và/hoặc các địa chỉ đa hướng. Việc truyền tín hiệu tiếng
và tín hiệu hình là hoàn toàn độc lập. Không hề có sự kết nối trực tiếp nào giữa hai
quá trình này. Tuy nhiên nếu mỗi thành viên tham gia, sử dụng một định danh cho
cả hai tiến trình này thì phía nhận vẫn hoàn toàn có thể liên kết lại được từng cặp
audio/video.
Với việc truyền tách biệt này, cho phép một thành viên tham gia hội thảo thiết lập
cơ chế chỉ nhận một luồng audio hoặc video. Việc mất đồng bộ của tín hiệu hình và
tiếng nói sẽ được giải quyết dựa vào thông tin định thời trong các gói tin RTCP của
hai luồng.
3.3. Các bộ mixer và translators

Trên đây chúng ta đã giả định tất cả các thành viên đều cùng nhận một định dạng
cho các kiểu dữ liệu. Điều này không thể được trong trường hợp có thành viên sử
dụng đường truyền tốc độ thấp, các thành viên khác lại sử dụng đường truyền ở tốc
độ cao. Khi đó ta không thể bắt tất cả các thành viên khác cùng sử dụng truyền ở
tốc độ thấp, chất lượng thấp.
Hình 3.: Minh họa việc sử dụng bộ mixer
Khi đó, ta có thể sử dụng bộ RTP chuyển tiếp cân bằng gọi là bộ mixer, đặt gần nơi
có băng thông hẹp. Bộ này sẽ tái đồng bộ các gói tin thoại, khôi phục lại chu kỳ
20ms của phía gửi, sau đó truyền lại dòng audio với tốc độ bit phù hợp với đường
truyền. Việc truyền lại này có thể sử dụng truyền đơn hướng cho một người nhận
đơn, hoặc đa hướng cho nhiều người nhận. Phần RTP header sẽ đảm nhận việc
định danh lại người gửi phía nhận.
Một số những người tham gia trong hội thảo có thể được kết nối với các liên kết
băng thông cao nhưng có thể không thể truy cập trực tiếp qua IP multicast. Ví dụ,
họ có thể ở phía sau một tường lửa cấp ứng dụng không để bất cứ gói tin IP nào đi
qua. Trong trường hợp này, bộ mixer có thể không cần thiết, một loại chuyển tiếp
cân bằng RTP khác có thể được sử dụng gọi là bộ translator.
Hai bộ translator sẽ được cài đặt, một trong hai bên của tường lửa, với một bên
ngoài nơi tất cả gói tin đa hướng được nhận thông qua một liên kết an toàn tới bộ
translator bên trong tường lửa. Bộ translator bên trong tường lửa sẽ gửi chúng lại
giống như các gói tin đa hướng cho một nhóm đa hướng hạn chế tới mạng nội bộ.
Các bộ mixer và bộ translator có thể được thiết kế cho nhiều mục đích. Một ví dụ
là một bộ mixer sẽ trộn các hình ảnh của từng người theo luồng video riêng biệt và
ghép chúng thành một luồng video để mô phỏng nhóm. Một ví dụ khác về bộ
translator là việc kết nối của một nhóm các máy chủ sử dụng IP/UDP với một
nhóm các máy chủ chỉ có thể hiểu ST-II, hoặc mã hóa dịch gói-by-gói của các
luồng video từ các nguồn cá nhân mà k cần đồng bộ hóa lại hay pha trộn chúng.
Chương 4 Phát triển ứng dụng phần mềm với RTP
Có hai giải pháp để phát triển ứng dụng kết nối mạng dựa trên RTP:
1. Phát triển ứng dụng kết hợp RTP thủ công tức là người phát triển ứng dụng

thực sự viết mã thực hiện đóng gói gói tin RTP tại bên gửi và tháo gỡ RTP
tại bên nhận.
2. Phát triển ứng dụng sử dụng các thư viện RTP (đối với người lập trình C) và
các lớp Java (đối với người lập trình Java) sẵn có để thực hiện đóng gói và
tháo gỡ cho ứng dụng.
Tổng kết và kết luận
Tài liệu tham khảo
1. H. Schulzrinne, S.C., R. Frederick and V. Jacobson, RTP: A Transport
Protocol for Real-Time Applications. July 2003.
2. Perkins, C., RTP: Audio and Video for the Internet. June 12, 2003.
[1, 2]