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

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)

Bảng 2.: Một số loại payload type audio được RTP hỗ trợ

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