- Tuy nhiên, RTP có thể được sử dụng với mạng khác ở tầng dưới, hoặc các giao thức vận chuyển (xem phần 10). - Nếu muốn bảo mật, các gói tin dữ liệu và điều khiển có thể được mã hóa theo quy định tại mục 9.1, trong trường hợp đó một khoá mã hóa cũng phải được tạo ra và truyền kèm theo. - Ngoài việc bổ sung tên người dùng, các thông tin nhận biết khác có thể cũng được sử dụng để điều khiển giới hạn băng thông. - Mặc dù phân tách, sự phát lại đồng bộ của nguồn âm thanh và video có thể đạt được bằng cách sử dụng thông tin thời gian thực trong các gói tin RTCP cho cả hai phiên. - Tuy nhiên, điều này có thể không phải lúc nào cũng thích hợp. - Những gói tin này có thể được truyền đơn hướng cho một người nhận hoặc đa hướng tới nhiều người nhận. - RTP-level còn có thể sử dụng để thay đổi độ phân giải của tín hiệu Video cho phù hợp với từng thành viên tham gia. - Thiết bị trộn và truyền có thể được thiết kế cho nhiều mục đích. - Gói RTP: Một gói dữ liệu bao gồm các tiêu đề RTP cố định, một danh sách có thể rỗng của các nguồn đóng góp và phần dữ liệu payload. - Một số giao thức lớp dưới có thể yêu cầu phải đóng gói lại các gói RTP. - RTP session: Một phiên RTP có thể có sự tham gia của một tập các thành viên cùng trao đổi thông tin. - 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 tin đồng bộ có thể thay đổi định dạng dữ liệu của nó, ví dụ như mã hóa âm thanh, qua thời gian. - Cách thức không RTP: Giao thức và kỹ thuật có thể cần thiết trong việc thêm vào RTP để cung cấp một dịch vụ có thể sử dụng. - Đối với các ứng dụng đơn giản như thư điện tử hoặc một cơ sở dữ liệu hội nghị cũng có thể được sử dụng. - Thời gian Wallclock (thời gian tuyệt đối) được biểu diễn bằng cách sử dụng cấu trúc nhãn thời gian (timestamp) của giao thức Network Time Protocol (NTP) tức là trong vài giây tương đối so với 0h UTC ngày 01 tháng 1 năm 1900 [5]. - Ta có thể dùng nó để làm sự kiện báo hiệu khung trong trường hợp ta truyền các gói tin thành dòng. - Bit này có thể được sử dụng hoặc không. - Nếu không sử dụng ta có thể thay đổi số lượng bit trong trường payload type. - Giá trị của phần định dạng tải này có thể cố định trong một phiên RTP nếu ta sử dụng phương pháp mã hoá tĩnh. - Phía nhận có thể hiểu đây là hai luồng thoại sử dụng cùng một phiên truyền, với cùng giá trị SSRC. - Tiêu đề các gói tin dữ liệu RTP hiện được coi là hoàn chỉnh cho tập hợp các chức năng cần thiết trong ứng dụng phổ biến trên tất cả các lớp RTP có thể hỗ trợ. - Do vậy, những trường này có thể phải được định nghĩa lại trong các trường đánh dấu mở rộng. - Điều này giúp cho các ứng dụng có thể nhanh chóng và trực tiếp xử lý các thông tin trong trường được thêm. - Chỉ một phần mở rộng duy nhất có thể được nối vào các tiêu đề dữ liệu RTP. - 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). - 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. - Việc truyền tải RTCP có thể được điều khiển khác nhau giữa người nhận và người gửi, trong trường hợp sử dụng đường truyền đơn hướng. - Nhiều gói RTCP có thể được kết nối với nhau thành gói ghép (compound packet. - Mỗi gói RTCP trong gói ghép có thể được xử lý một cách độc lập, không cần dựa vào thứ tự hoặc sự kết hợp giữa các gói. - Điều này giúp cho việc định danh nguồn gửi, từ đó có thể thực hiện đồng bộ giữa các thành 27phần (video/audio). - Số các kiểu gói có thể chứa trong phần đầu tiên của gói ghép. - BYE or APP: Một số gói RTCP loại khác có thể được đặt ở các vị trí bất kỳ. - 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. - Băng thông có thể được cung cấp và bị giới hạn bởi nhà cung cấp dịch vụ. - Điều này sẽ giới hạn số phiên truyền tối đa có thể chấp nhận. - Giá trị này có thể được hiểu như là session bandwidth. - 31 Thuật toán này có thể được sử dụng cho các phiên trong đó tất cả người tham gia được được phép gửi. - Để tránh trường hợp một gói tin nào đó đến sau gói BYTE có thể tạo ra địa chỉ mới. - Ví dụ, một ứng dụng có thể được thiết kế để chỉ gửi 3 tham số: CNAME, NAME và EMAIL. - Báo gửi và báo 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 qua các bản tin RTCP. - Cả bản tin SR và RR đều có thể không mang thông tin (rỗng) hoặc mang thêm một vài khối báo nhận là một khối cho mỗi nguồn đồng bộ (synchronization sources) mà người nhận đã nhận các gói dữ liệu RTP từ khi có báo cáo cuối cùng. - Khi đó, trong mỗi khoảng thời gian nhất định, ta chỉ có thể truyền đi một phần trong số các gói RR này. - Gói thông báo của bên gửi dữ liệu chứa 3 phần cố định, có thể được gắn thêm tới 4 phần mở rộng (profile-specific extension) nếu nó được định nghĩa. - Các bits đệm có thể được sử dụng trong một số thuật toán mã hóa với kích thước block cố định. - Nó có thể được bên nhận dùng để xác định tổng thời gian truyền từ điểm gửi đến điểm nhận. - Có thể dùng thời gian lấy mẫu để tính thời gian thực tế trôi qua. - Một người gửi không biết thời gian thực tế hoặc thời gian trôi qua có thể đặt tem thời gian NTP bằng 0. - Trường này cũng có thể được sử dụng để ước tính tốc độ tải trung bình của một người gửi. - Việc truyền đi trạng thái của người nhận trong khi người nhận đó đang thay đổi định danh SSRC có thể gây ra xung đột. - SSRC_n có thể tính toán tổng thời gian trễ lan truyền đến SSRC_r bằng cách ghi lại thời gian A khi bản tin báo nhận được nhận. - Giá trị này có thể được dùng để tính gần đúng khoảng cách tới các người nhận, cho dù thời gian trễ trên các đường truyền là khác nhau. - Người gửi có thể điều chỉnh quá trình truyền tin của mình thông qua các thông tin phản hồi. - Nhà quản trị mạng có thể chỉ nhận các gói RTCP (không cần quan tâm đến các gói RTP) để đánh giá hiệu suất của mạng trong quá trình truyền multicast. - Sự khác nhau giữa 2 bản tin cuối cùng nhận được có thể được dùng để ước tính chất lượng hiện thời của đường truyền. - Việc gắn nhãn thời gian NTP giúp ta có thể tính được tốc độ truyền tải dựa vào khoảng thời gian chênh lệch của 2 gói RTCP. - Ta cũng có thể tính tỷ lệ thất lạc gói tin trong 1s bằng cách chia tỷ số này cho khoảng thời gian chênh lệch giữa 2 nhãn thời gian NTP (đơn vị tính bằng s). - Mỗi gói SDES có thể có không hoặc nhiều đoạn thông tin này. - các thông tin còn lại có thể có hay không tuỳ thuộc vào từng ứng dụng cụ thể. - Điều này giúp ta có thể kết nối giữa các luồng dữ liệu khác nhau được gửi đi từ cùng một thành viên nhưng sử dụng 2 phiên RTP riêng. - Nó có thể được đặt tuỳ ý do người dùng. - Chính vì vậy mà nó có thể được gửi đi thường xuyên (đứng thứ 2 sau CNAME). - Do vậy NOTE có thể sử dụng một phần cố định của băng thông RTCP. - Ta có thể sử kiểu phụ để định nghĩa một tập các gói APP dưới một cái tên duy nhất, hoặc cho bất kỳ loại dữ liệu phụ thuộc ứng dụng. - Một số loại “translator” sẽ chuyển tiếp dữ liệu một cách nguyên vẹn, nhưng một số loại khác có thể thay đổi dạng mã hoá dữ liệu của phần tải và nhãn thời gian gắn kèm của gói RTP. - Ngoài ra sự thất lạc các gói gói tin đầu vào cũng có thể tạo lên sự không liên tục của các số thứ tại đầu ra. - Để có thể duy trì định danh SSRC của từng nguồn phân tán trong một gói tổng hợp, bộ “Mixer” phải chèn các giá trị SSRC của chúng vào danh sách CSRC ngay sau phần tiêu đề RTP của gói dữ liệu. - Quá trình xử lý RTCP trong Translators Khi gói dữ liệu RTP được chuyển tiếp qua các bộ “mixer” và “translator”, nó có thể bị sửa đổi, khi đó ta phải có xử lý đối với các gói RTCP. - Sự truyền lại các thông tin này có thể được kích hoạt bởi các gói tin đến hoặc do chính bộ phận timer của “mixer” hoặc “translator” gây ra. - Điều này có thể là phức tạp. - Vì thế mà tốc độ gói RTCP có thể khác nhau tại hai phía của một bộ “mixer”. - Cascaded Mixers – Các Mixer mắc phân tầng: Một phiên RTP có thể bao gồm nhiều bộ “translator” và “mixer” như hình vẽ Hình 2.23. - Xác suất xung đột còn có thể được giảm hơn nữa khi mà một nguồn mới được nhận các gói tin từ các nguồn khác trước khi nó gửi đi gói tin đầu tiên của mình (là gói RTP hoặc RTCP). - Bởi vì giá trị của SSRC được giữ đảm bảo là duy nhất trong toàn bộ phiên RTP, do vậy nó có thể được sử dụng để phát hiện vòng lặp gây ra bởi các bộ “translator” và “mixer”. - Một bộ “translator” có thể chuyển tiếp không chính xác một gói dữ liệu tới một nhóm multicast mà các nguồn tại đấy đã nhận được gói dữ liệu rồi. - Lúc này nguồn có thể xuất hiện một SSRC trên gói dữ liệu và một CSRC trong một gói dữ liệu đã trộn. - Điều này không hề bắt buộc, bởi trong một số ứng dụng RTP, một nguồn có thể thay đổi địa chỉ trong suốt phiên truyền. - Một phần tử có thể được loại bỏ khỏi danh sách khi không xảy ra xung đột trong thời gian 10 báo cáo RTCP (xem 6.2). - Giải thuật có thể được cấu trúc lại cho lần đầu tiên thực hiện việc so sánh với định danh nguồn của thành viên. - Điều này có thể xảy ra nếu nguồn ban đầu tìm ra xung đột và chuyển tới một định danh nguồn mới. - Một vòng lặp các gói dữ liệu tới một đích multicast có thể gây ra hiện tượng tràn. - Việc truyền lại có thể được thử lại định kỳ sau một khoảng thời gian dài ngẫu nhiên (đơn vị phút). - Ngoài ra đối với gói RTCP, có thể chia 1 gói ghép RTCP thành 2 gói RTCP ghép. - Cả hai thành viên có thể sử dụng cùng một cặp cổng. - RTP có thể được sử dụng cho nhiều ứng dụng với các yêu cầu gần giống nhau. - Một profile cho ứng dụng audio và video có thể được tìm thấy trong dự thảo internet. - Một số các định dạng payload có thể được xác định bởi tham chiếu đến các đặc tả định dạng payload riêng biệt. - Người qua sát ở ngoài có thể dùng thông tin này để thực hiện quản lý chất lượng dịch vụ. - Nhưng có thể lợi dụng bất kỳ một giao thức nào của tầng thấp hơn trên cơ sở gói tin. - Các ứng dụng client có thể hiển thị về tên và email trong các giao diện người sử dụng. - Cuối cùng các phần tử ứng dụng (APP) có thể dùng để đưa thêm các thông tin cụ thể vào các gói tin RTCP. - Các bản tin người nhận và người gửi và các gói SDES có chứa các thông tin, các thông tin này có thể thay đổi thường xuyên do đó phải gửi các gói này một cách định kỳ. - Do đó có thể dẫn đén sự tràn các bản tin RTCP. - Các ứng dụng có thể lựa chọn nhiều mức chất lượng dịch vụ khác nhau cho luồng lưu lượng của mình. - Các host có thể tham gia vào các nhóm multicast ở bất kỳ thời điểm nào. - Các gói này có thể gửi tới địa chỉ all-hosts hoặc tới từng nhóm cụ thể. - Luồng dữ liệu được điều khiển bởi giao thức RTSP có thể sử dụng RTP, tuy nhiên hoạt động của giao thức RTSP không phụ thuộc vào cơ chế vận chuyển của các giao thức mình sử dụng. - và các đối tượng này vẫn có thể được sử dụng như là các đối tượng Otcl thông qua các liên kết. - Luận văn cũng tiến hành tìm hiểu, cài đặt NS và dùng NS để mô phỏng giao thức RTP cho thấy RTP đảm bảo băng thông cố định có thể phục vụ truyền các ứng dụng thời gian thực. - Ngoài ra, việc kiểm tra có thể khắt khe hơn với yêu cầu nhiều hơn 2 gói tin liên tiếp
Xem thử không khả dụng, vui lòng xem tại trang nguồn hoặc xem
Tóm tắt