Truyền dữ liệu thời gian thực trên Giao thức truyền tải thời gian thực (RTP)

MỤC LỤC

Điều khiển luồng dữ liệu

Trong việc điều khiển luồng dữ liệu phương pháp hay sử dụng là dùng phương pháp cửa sổ trượt. Phương pháp cửa sổ trượt cho phép nới gửi (Sender) có thể gửi đi nhiều gói tin rồi sau đó mới đợi tín hiệu báo nhận ACK (Acknowledgement) của nơi nhận (Receiver).Với phương pháp cửa sổ trượt khi cần truyền các gói tin, giao thức sẽ đặt một cửa sổ có kích cố định lên các gói tin.

Thiết lập và huỷ bỏ liên kết

Với phương thức chủ động thì người sử dụng yêu cầu TCP thử thiết lập một liên kết với một Socket nào đó với một mức ưu tiên và độ an toàn nhất định. Nếu liên kết được thiết lập thành công thì thì hàm Open success primitive được dùng để thông báo cho người sử dụng biết (cũng được sử dụng trong trường hợp Passive Open) còn nếu thất bại thì hàm Open failure primitive được dùng để thông báo.

Truyền và nhận dữ liệu

Nếu trạm ở xa kia đáp lại bằng một hàm Passive open tương hợp hoặc đã gửi một active open tương hợp thì liên kết sẽ được thiết lập. Liên kết có thể bị huỷ bỏ một cách bất thường vì một lý do nào đó(do người sử dụng hoặc do TCP đóng liên kết do không thể duy trì được liên kết).

GIAO THỨC UDP: (USER DATAGRAM PROTOCOL)

Lớp UDP được đặt trên lớp IP, tức là UDP Datagram khi chuyển xuống tầng dưới sẽ được đặt vào IP Datagram để truyền trên liên mạng. Tại trạm đích các PDU được gửi từ dưới lên trên, qua mỗi tầng phần Header của PDU được gỡ bỏ và cuối cùng chỉ còn lại phần dữ liệu như ban đầu được chuyển cho người sử dụng.

ĐỊNH TUYẾN MULTICAST

Các gói multicast được tái tạo lại bên trong các Router mà đã kích hoạt khả năng PIM (Protocol Independent Multicast) và các giao thức hỗ trợ multicast khác đưa đến kết quả là nó tạo ra khả năng phát chuyển dữ liệu tới nhiều thành viên một cách hiệu quả nhất. Cụ thể, vùng group không được phân chia thành các bit để xác định nguồn gốc hay đơn vị sở hữu của nhóm, nó cũng không chứa thông tin quản trị như là các thành viên của nhóm có ở trên một mạng vật lý không.

GIAO THỨC NÀO Cể THỂ ĐÁP ỨNG ĐƯỢC YấU CẦU THỜI GIAN THỰC?

- Cần kết hợp với một thông số về thời gian (nhãn thời gian) kèm theo gói dữ liệu: Với các tín hiệu thời gian thực, đặc biệt là tín hiệu video, việc khôi phục đồng bộ tại phía thu là rất quan trọng, do đó đòi hỏi nhãn thời gian kèm theo để phục vụ cho việc tái tạo lại dữ liệu tại nơi nhận. Ngoài ra với tính chất vốn có của mình, TCP là giao thức được sử dụng để truyền dữ liệu theo kiểu điểm tới điểm, hay nói cách khác TCP chỉ được dùng cho truyền unicast, không thể sử dụng cho truyền multicast.

Hình 1.6:Sử dụng Multicast trong truyền dữ liệu đa phương tiện.

GIAO THỨC TRUYỀN TẢI THỜI GIAN THỰC (RTP: REAL TIME TRANSPORT PROTOCOL)

CSRC

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 điểm multicast ) hoặc riêng biệt cho từng thành viên(trong trường hợp truyền điểm điểm unicast). Một nguồn RTP có thể thay đổi định dạng tải trong một phiên truyền, tuy nhiên ta không nên _ing 1 phiên RTP để truyền đồng thời các luồng media có định dạng khác nhau, theo khuyến cáo của RFC1890.

GIAO THỨC ĐIỀU KHIỂN RTP (RTCP: RTP CONTROL PROTOCOL)

CHỨC NĂNG VÀ HOẠT ĐỘNG CỦA RTCP

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. Việc đồng bộ nội cho từng luồng tín hiệu (video hoặc audio) được thực hiện dựa trên các thông tin về số thứ tự, nhãn thời gian gắn trên các gói RTP và RTCP của bên gởi.

CÁC LOẠI GểI TIN RTCP

Đ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 và rời bỏ mà không điều khiển quan hệ tới các thành viên khác. Nếu gói ghép này có kích thước vượt quá giá trị của một đơn vị truyền tải (maximum transmission unit), khi đó nó sẽ được phân thành các gói ghép nhỏ hơn để có thể tryền được trong những gói của giao thức lớp dưới.

KHOẢNG THỜI GIAN TRUYỀN CÁC GểI RTCP : (RTCP TRANSMISSION INTERVAL)

Việc tính toán chu kỳ phát các gói tin ghép RTCP cũng nên đặt ra giới hạn tránh trường hợp quá nhiều gói tin vượt quá mức băng thông cho phép, khi số lượng thành viên tham gia ít và không còn theo qui luật số lớn nữa. Sau đó các thành viên khác gởi các bản tin thông báo gởi lại sẽ điều chỉnh lại khoảng thời gian phát của các bản tin RTCP ngắn hơn cho phù hợp, có thể sẽ bằng 1/2 giá trị ban đầu.

CẬP NHẬT SỐ THÀNH VIÊN THAM GIA PHIÊN TRUYỀN

Khoản thời gian thực tế giữa các gói RTCP được biến đổi ngẫu nhiên trong khoảng [0.5,1.5] lần giá trị tính toán, để tránh sự đồng bộ không lường trước được của các thành viên. Gói RTCP đầu tiên được gởi sau khi thành viên tham gia phiên truyền cũng bị làm trễ đi một khoảng thời gian ngẫu nhiên trong khoảng 1/2 khoảng thời gian RTCP tối thiểu.

QUI ĐỊNH ĐỐI VỚI VIỆC GỞI VÀ NHẬN CÁC GểI RTCP

Theo cách tính này, khoảng thời gian T sẽ lấy giá trị ngẫu nhiên tại một thời điểm, tuy nhiên nếu tính lâu dài thì giá trị trung bình sẽ ≥25% RTCP sẽ được giành cho những người gởi dữ liệu, phần còn lại dành cho người nhận dữ liệu. Nếu một thành viên trong danh sách người gởi mà không được nhận một gói RTP nào trong khoảng thời gian 2T.(khoảng thời gian giữa 2 gói RTCP cuối cùng được nhận), khi đó thành viên sẽ bị loại khỏi danh sách người gởi, số người gởi senders được cập nhật lại.

CÁC BẢN TIN THÔNG BÁO CỦA NGƯỜI GỞI VÀ NGƯỜI NHẬN Trong giao thức RTP, các thành viên có thể trao đổi thông tin điều khiển thông

Các số đếm tích luỹ được sử dụng trong cả thông tin người gởi và các khối thông báo của người nhận, do đó sự khác biệt được tính giữa 2 bản tin bất kỳ phục vụ cho phép đo trong thời gian ngắn hoặc dài, được dùng để khôi phục lại các bản tin bị thất lạc. Nhãn thời gian sẽ được gắn giống nhau cho mọi gói tin chứa cùng 1 khung hình, tuy nhiên các gói dữ liệu này lại không được truyền đi đồng thời mà được gởi đi lần lượt, điều này sẽ làm giảm độ chính xác của việc tính toán jitter với mục đích phân tích hoạt động của mạng.

GểI TIN Mễ TẢ CÁC THễNG TIN CỦA NGUỒN

- Một định danh SSRC được phân phối một cách ngẫu nhiên và có thể thay đổi trong một phiên RTP, khi phát hiện sự xung đột, hoặc khi chương trình khởi tạo lại. Tuy nhiên, nếu không nhận được thông tin NOTE trong một thời gian nào đó, bên nhận cũng sẽ tự mặc định rằng nó đã được ngừng kích hoạt (thời gian này khoảng 20-30 lần chu kỳ gởi RTCP).

Gói BYE

Trường “prefix string” định nghĩa loại của PRI, dùng chỉ dẫn cho phía nhận.Trường “value string” sẽ chứa những phần thông tin mở rộng khác (extended items). Tuy điều này có thể không làm hài lòng một số ứng dụng, tuy nhiên với kích thước như vậy là đúng mức để băng thông dành cho RTCP không bị quá tải.

GểI APP: APPLICATION-DEFINED RTCP PACKET Cấu trúc gói RTCP-APP

Mặc dù sự có mặt của 2 thiết bị này làm cho hệ thống trở lên phức tạp hơn nhiều, nhưng đây là các chức năng thật sự cần thiết cho hệ thống RTP. Nó đóng vai trò rất quan trọng trong các hệ thống truyền multicast, trong các hệ thống có một phần được bảo vệ bởi fire wall, trong hệ thống có một phần băng thông hạn hẹp.

KHÁI NIỆM CHUNG

- Các “cloud” được nối với nhau qua các bộ “mixer” và “translator”, để tham dự vào một phiên RTP, phải khác nhau ít nhất một trong những tham số sau: Protocol, address, port, hoặc phải hoàn toàn tách biệt với nhau ở lớp mạng. Phía nhận sẽ hoàn toàn không hề phát hiện ra được sự có mặt của “translator” trừ khi sử dụng một số phương tiện đặc biệt, bởi vì kiểu định dạng tải, địa chỉ giao vận của các gói tin không hề bị thay đổi gì so với nguồn gốc.

Hình 5.1 : Mô hình mạng với các bộ traslator và mixer

HOẠT ĐỘNG CỦA BỘ TRANSLATORS

Chú ý: thường thì “translator” không kết hợp các gói SR và RR từ các nguồn khác vào một gói chung, bởi vì như vậy sẽ làm giảm độ chính xác của việc đo thời gian trễ lan truyền dựa trên các trường LSR và DLSR.  Nếu trước đây “translator” kết hợp nhiều gói RTP đầu vào thành một gói RTP ghép tại đầu ra và đã thực hiện việc thay đổi số thứ tự của gói, thì nó phải thực hiện chuyển đổi ngược tương ứng với các trường “packet loss” và "extended last sequence number”.

HOẠT ĐỘNG CỦA MIXERS

Trong gói BYE này sẽ chứa danh sách tất cả các SSRC mà nó đã từng chuyển tiếp đến “cloud” đó, bao gồm cả SSRC của chính nó (nếu như nó cũng đã gởi đi các bản thông báo của riêng mình). Khi các bộ “mixer” không chuyển tiếp thẳng các gói SR, RR, chúng sẽ phân tích các gói SDES từ một gói ghép RTCP, tối thiểu hoá phần tiêu đề, sau đó có thể ghép các đoạn trong một gói SDES đơn.

Hình 5.4: khả năng phát hiện vòng lặp hoặc xung đột của mixer.

CÁC “MIXER” MẮC PHÂN TẦNG

Đối với một bộ “mixer” sử dụng cơ chế chuyển thẳng các gói SDES mà nó nhận được cũng có tốc độ phát các gói RTCP lớn hơn so với một nguồn đơn. Gói Byte này sẽ chứa định danh SSRC của tất cả các nguồn đã từng được chuyển qua, kể cả định danh SSRC của bản thân bộ “mixer”.

MỘT SỐ THUẬT TOÁN CẦN CHÚ Ý

PHÂN PHỐI CÁC ĐỊNH DANH SSRC
VẤN ĐỀ BẢO MẬT TRONG RTP

Trong các ứng dụng như điện thoại, có một số nguồn như các thực thể di động có thể thay đổi địa chỉ trong suốt một phiên RTP, nên giao thức RTP phải cung cấp thuật toán phát hiện xung đột để chấp nhận các gói đến từ địa chỉ nguồn mới. Tuy nhiên, trong trường hợp xấu nhất khi ”mixer” và ”translator” không làm việc chính xác, tức là không loại bỏ được vòng lặp thì điều cần thiết là cần phải cho các hệ thống cuối ngừng hoàn toàn việc truyền phát các gói dữ liệu và điều khiển.

ỨNG DỤNG LÝ THUYẾT VÀO THỰC TẾ

Kiểm soát và cân bằng lưu lượng
DềNG DỮ LIỆU THỜI GIAN THỰC 0.1. Khái niệm truyền dòng

Ta phải chỉ định phương thức framing được sử dụng, ngay cả khi gói RTP được mang theo giao thức cung cấp cơ chế framing để có thể mang nhiều gói RTP trong một đơn vị dữ liệu của giao thức lớp dưới (ví dụ như gói UDP). Em hy vọng rằng, sau này em sẽ có điều kiện để tiếp tục tìm hiểu sâu hơn nữa về giao thức RTP, và có thể hoàn thiện chương trình của mình tốt hơn, đáp ứng được như cầu của một dịch vụ VoD hoàn hảo.