Nghiên cứu & ứng dụng giao thức RTP

protocol). Những khái niệm ban đầu. 22 3.2 ứng dụng của RTP trong hội thảo đa phương tiện. 24 Chương III: Giao thức truyền tải thời gian thực (real time transport protocol). 3.1. Một số khái niệm liên quan đến RTP. 28 3.2. Cấu trúc phần tiêu đề gói RTP. 32 3.3 Ghép các phiên truyền RTP. 36 3.4. Sự thay đổi phần tiêu đề trong một số trường hợp. 37 Chương IV: Giao thức điều khiển RTP (RTCP: RTP control protocol). 4.1 Chức năng và hoạt động của RTCP. 39 4.2. Các loại gói tin RTCP. 41 4.3 Khoảng thời gian truyền các gói RTCP. 44 4.4 Cập nhật số thành viên tham gia phiên truyền. 47 4.5 Qui định đối với việc gởi và nhận các gói RTCP. 48 4.6. Các bản tin thông báo của người gởi và người nhận. 54 4.7 Gói tin mô tả các thông tin của nguồn. 64 4.8. Gói BYE. 70 4.9. Gói APP. 71 Chương V: các bộ RTP Translators và RTP Mixers . 5.1. Khái niệm chung. 73 5.2. Hoạt động của bộ Translators. 76 5.3. Hoạt động của Mixers. 78 5.4. Các “mixer” mắc phân tầng. 80 Phần VI: Một số thuật toán cần chú ý. 6.1. Phân phối các định danh SSRC. 82 6.2 Vấn đề bảo mật trong RTP. 86 6.3. Điều khiển tắc nghẽn. 87 6.4. RTP với các giao thức lớp mạng và lớp giao vận. 88 Chương VII: ứng dụng lý thuyết vào thực tế. 7.1 Phân tích yêu cầu đặt ra. 90 7.2. thực hiện. 92 7.3. Kết quả. 93 Phụ lục. 96 Kết luận. 99 Tài liệu tham khảo. 100 Lời nói đầu Hiện nay, mạng máy tính không còn là khái niệm xa lạ gì. sau hơn 40 năm phát triển, mạng máy tính, giờ đây mạng máy tính đã trải rộng trên toàn cầu, với chất lượng đường truyền có chất lượng cao. Ngoài ra tính bảo mật, độ tin cậy trên mạng cũng ngày càng được củng cố. Những ứng dụng trên mạng đang ngày càng phong phú. Chính những sự phát triển này làm nảy sinh một vấn đề, đó là truyền thông đa phương tiện trên mạng. Yếu tố rất quan trọng, có mặt trong rất nhiều lĩnh vực. Trong các buổi hội thảo trực tuyến, trong đào tạo từ xa trên mạng, trong dịch vụ video/audio theo yêu cầu….Tuy nhiên sự phát triển của truyền thông đa phương tiện đòi hỏi tính thời gian thực rất cao, chùm giao thức TCP/IP hiện đang được sử dụng rất phổ biến không thể đáp ứng được yêu cầu này. Do vậy, đòi hỏi các chuyên gia mạng phải tìm ra một giải pháp mới, một giao thức mới có thể đáp ứng được việc truyền tải dữ liệu thời gian thực trên mạng. Hiện nay, giao thức RTP đã và đang chứng tỏ những ưu điểm của mình trong việc đáp ứng các ứng dụng thời gian thực. Tại Việt Nam, các ứng dụng thời gian thực còn chưa phát triển, nhưng với như cầu cấp thiết của thực tế, trong thời gian tới chắc chắn các ứng dụng thời gian thực sẽ phát triển mạnh mẽ. Đây cũng là một trong những lý do chính để em chọn lựa đề tài này. Chương 0: truyền dòng dữ liệu thời gian thực (real time streaming) Có rất nhiều ứng dụng hiện nay đòi hỏi tính thời gian thực (real time). Trong các dịch vụ truyền hình qua mạng, hội thảo trực tuyến, chat hình, chat tiếng…mỗi ứng dụng có những đặc điểm riêng của nó, tuy nhiên có một số điều chung nhất mà các dịch vụ này đều yêu cầu đó là việc truyền dữ liệu theo dòng (streaming). Do vậy chúng ta sẽ bắt đầu với việc tìm hiểu về khái niệm truyền dòng. Khái niệm truyền dòng: Khái niệm truyền dòng có thể hiểu là khi nội dung của audio hay video được truyền tới nơi nhận, nơi nhận có thể thể hiện được ngay trong quá trình truyền mà không cần phải đợi đến khi toàn bộ nội dung video được truyền xong. Cơ chế này hoàn toàn khác với cơ chế download file của các giao thức HTTP hay FTP. Truyền dòng cho phép chúng ta thể hiện các dòng video thời gian thực mà không phụ thuộc vào độ dài của video. Điều này rất có ý nghĩa khi truyền các file video có kích thước lớn hay các dòng video có độ dài không xác định. Khi đó, các giao thức khác như FTP hay HTTP sẽ không thể sử dụng được. Chúng ta có thể bắt gặp rất nhiều trường hợp sử dụng cơ chế truyền dòng như các chương trình truyền hình trực tiếp, hội thảo qua mạng. Với khả năng truyền tải nội dung video, audio thông qua mạng, chúng ta có một phương pháp giao tiếp và truy nhập thông tin mới. Với góc nhìn bao quát, truyền dòng là một phương pháp truyền thông tin liên tục, trong đó nội dung video được truyền đi theo thời gian thể hiện của nội dung video đó. Bên nhận khi nhận dòng thông tin nội dung video sẽ có thể thể hiện ngay nội dung của video theo thời gian. Khả năng này rất có ý nghĩa đối với các loại dữ liệu phụ thuộc thời gian như video, audio, bởi vì để đảm bảo chất lượng cảm thụ video thì phải đảm bảo được mối quan hệ về mặt thời gian giữa các khung hình. Để có thể hình dung một cách đơn giản về cơ chế truyền dòng thời gian thực, chúng ta lấy một ví dụ như sau. Giả thiết có hai máy được kết nối với nhau, trong đó một máy đóng vai trò là máy truyền và một máy đóng vai trò là máy nhận. Bên truyền được trang bị camera để thu hình giảng viên giảng bài và dữ liệu video thu được được truyền tới máy nhận. Bên nhận có nhiệm vụ nhận dòng dữ liệu từ bên truyền gửi tới và thể hiện lên thiết bị ra như TV hay màn hình máy tính. Khi đó với việc sử dụng cơ chế truyền dòng thời gian thực, các hình ảnh của giảng viên mà bên nhận thể hiện sẽ phản ánh một cách tức thời (về mặt lí thuyết) những gì đang xảy ra đối với giảng viên ở bên truyền. Còn với các bài giảng được lưu trữ trước, truyền dòng thời gian thực sẽ đảm bảo việc thể hiện của video tương đương như khi nó được thể hiện trên máy truyền. Khi đó, môi trường mạng là trong suốt đối với người sử dụng, người sử dụng có cảm giác việc thể hiện đoạn video như là được thực hiện ngay trên máy cục bộ. Quá trình truyền dòng: Truyền dòng đối với video hay audio phải trải qua nhiều công đoạn với từng nhiệm vụ riêng để đi đến kết quả cuối cùng là đạt được khả năng thể hiện ngay ở bên nhận. Giải nộn video/audio RTP Packets Lấy mẫu Khụi phục dữ liệu và đồng bộ Network Dũng video/audio Hình 0.1: Quá trình truyền dòng video/audio Để có thể tìm hiểu sâu được cơ chế truyền dòng, chúng ta cần đi sâu vào quá trình mà thông tin được truyền đi thông qua môi trường mạng. Bất cứ một nội dung video hay audio nào được truyền đi dưới dạng truyền dòng đều phải trải qua các bước sau: Bước 1 - Mã hoá: Việc mã hoá video, mà cụ thể là nén video là một công đoạn không bắt buộc nhưng rất cần thiết. Với các loại dữ liệu video thô như dữ liệu thu từ camera, thì việc lưu trữ hay truyền video không nén sẽ phải trả giá cao, đôi khi là điều không thể. Ta lấy ví dụ với một định dạng tiêu biểu thường được sử dụng trong các ứng dụng hội nghị từ xa bằng video là định dạng CIF (Common Intermediate Format). CIF sử dụng độ phân giải 352 pixel mỗi dòng và 288 dòng tất cả. Một ảnh không nén cho một frame hình (chế độ 352x288x16bpp) chiếm 202752 byte. Việc ghi video không nén với tốc độ 15 hình một giây sẽ cần xấp xỉ 3 MB một giây và nếu truyền qua mạng thì băng thông cần thiết cho một dòng video không nén là 24 Mbps. Từ ví dụ trên đây, ta thấy việc nén video gần như là không thể thiếu được nếu các dòng video được truyền trên môi trường mạng tốc độ thấp. Bảng sau cho biết độ nén cần thiết đối với từng môi trường mạng khác nhau: Dạng kết nối Bit Rate Tỉ lệ nộn OC3 155 Mbps 1:1 T3 42 Mbps 4:1 Ethernet 10 Mbps 17:1 T1 1.5 Mbps 110:1 ISDN 128 Kbps 1300:1 Modem 56 Kbps 3000:1 Bảng 0-2: Băng thông mạng và tỉ lệ nén yêu cầu Có thể sử dụng nhiều chuẩn nén khác nhau cho việc nén video. Tuỳ theo yêu cầu chất lượng và băng thông, mà ta có thể lựa chọn được phương pháp nén thích hợp. Với việc áp dụng một chuẩn nén cho dữ liệu video, không gian lưu trữ cần thiết cũng như băng thông mạng yêu cầu cho dòng video giảm đột ngột. Ví như đối với dòng video ở trên, nếu sử dụng chuẩn nén H.263 thì băng thông yêu cầu cho việc truyền dòng video này chỉ vào khoảng 140 Kbps và không gian lưu trữ cần thiết cho một ngày với 24 giờ vào khoảng 1.4 MB. Hiện phổ biến hai họ chuẩn nén, là họ CCITT với các chuẩn dạng H.26x, H.36x và họ ISO MPEG với các chuẩn MPEG-1, MPEG-2, MPEG-4, MPEG-7. Sự phát triển của các chuẩn nén có thể tham khảo trong sơ đồ dưới đây: H.261 - Một kĩ thuật với tốc độ dũng bit nhỏ, được đưa ra vào năm 1984 bởi ITU sử dụng cho cỏc dịch vụ audio-visual. MPEG-1 - Chuẩn ISO, ứng dụng trong ngành cụng nghiệp quảng bỏ. MPEG-1 được tạo ra như là một sự sửa đổi của H.261 cho việc chuyển video vào đĩa CD với tốc độ dũng bit thấp. MPEG-2 - Được phỏt triển cho việc quảng bỏ video chất lượng cao bằng cỏch sử dụng tỉ lệ nộn thấp. H.263 - Một sửa đổi phỏng theo MPEG-2 với mục đớch thu được độ nộn cao trong khi vẫn đảm bảo chất lượng hỡnh ảnh cao. H.263+ và H.263++ là cỏc phiờn bản mở rộng của H.263. MPEG-4 - Được phỏt triển song song với H.263 như là một phương phỏp thay thế cho MPEG-1 với tốc độ dũng bit thấp. H.323 - Một hệ thống hoàn hảo cho việc truyền thụng multimedia, trong đú thành phần video được thực hiện trờn cơ sở H.261/263. JPEG-2000 - Chuẩn JPEG mới nhất, dựa trờn cơ sở DWT (Discrete Wavelet Transform), ban đầu được phỏt triển cho việc nộn ảnh tĩnh, hiện nay được ỏp dụng cho cả video. H.264 - Mở rộng H.263, hiện chưa được phỏt triển Hình 0.3: sự phát triển của các chuẩn nén. Bước 2 - Lấy mẫu: Việc lấy mẫu thực chất là việc chia nhỏ nội dung của video hay audio ra thành các khối nhỏ thích hợp để có thể truyền đi trong môi trường mạng. Đối với các dữ liệu audio, việc lấy mẫu được thực hiện theo thời gian. Tương ứng sau một khoảng thời gian bằng chu kì lấy mẫu phần dữ liệu audio tương ứng trong khoảng thời gian đó sẽ được sử dụng để truyền đi.Với các dữ liệu video, ngoài việc lấy mẫu theo thời gian còn có việc lấy mẫu theo không gian. Việc lấy mẫu theo thời gian tương ứng với thời gian thể hiện của các khung hình và việc lấy mẫu theo không gian sẽ được thực hiện bằng cách chia nhỏ các khung hình thành các phần với kích thước thích hợp đối với việc truyền đi. Khi lấy mẫu, các mẫu phải chứa đựng đầy đủ các thông tin dùng cho việc khôi phục lại dữ liệu video hay audio về cả mặt không gian cũng như thời gian khi bên nhận nhận được các mẫu này. Với việc sử dụng một giao thức như giao thức truyền thông thời gian thực như RTP, quá trình lấy mẫu sẽ được tiến hành tự động. Bước 3 - Truyền các mẫu qua mạng: Việc truyền các mẫu dữ liệu video có thể được thực hiện một cách trực tiếp thông qua các giao diện của môi trường mạng như Socket hay được thực hiện thông qua một giao thức cấp cao ở tầng ứng dụng như RTP. Thông thường người ta sẽ chọn giải pháp thứ hai, tức là sử dụng một giao thức truyền dòng thời gian thực cho việc truyền các mẫu nếu như giao thức đó được hỗ trợ trên nền phần cứng cũng như phần mềm. Việc sử dụng một giao thức truyền dòng thời gian thực có nhiều ưu điểm. Ưu điểm thứ nhất là tính hiệu quả, bởi vì các giao thức truyền thông thời gian thực được thiết kế cho việc truyền các loại dữ liệu động, như dữ liệu video chẳng hạn, khi đó tính thời gian thực sẽ được chú trọng hơn là tính chính xác về mặt dữ liệu. Ví dụ như đối với giao thức RTP, giao thức truyền thông lớp dưới thường được sử dụng là UDP (User Datagram Protocol) là giao thức với độ tin cậy thấp nhưng có tốc độ truyền dữ liệu cao hơn các giao thức với độ tin cậy cao như TCP. Ưu điểm thứ hai là các giao thức thời gian thực hỗ trợ mạnh việc đồng bộ các dòng dữ liệu từ các nguồn khác nhau nhưng có quan hệ với nhau về mặt thời gian thực. Ví dụ như đối với việc truyền âm thanh và hình ảnh của cùng một sự vật, khi đó bên nhận khi thể hiện phải đảm bảo yêu cầu là âm thanh phải phù hợp với hình ảnh. Ngoài ra, các giao thức điều khiển còn cung cấp các dịch vụ cho phép quản lí các thành viên tham gia và điều khiển chất lượng của việc phân phối dữ liệu. Với việc sử dụng một giao thức truyền thông thời gian thực cho việc truyền, khi đó các mẫu sẽ được đóng gói thành các gói tin. Các gói tin sẽ mang đầy đủ các thông tin như nhãn thời gian, số thứ tự của gói tin và các thông tin khác đủ dùng cho việc khôi phục dữ liệu và đồng bộ các dòng khi bên nhận tiến hành nhận và thể hiện nội dung của video hay audio. Thông qua các giao thức lớp dưới, các gói tin sẽ được truyền đi trong môi trường mạng. Bước 4 - Nhận và khôi phục dữ liệu và đồng bộ các dòng: Đây là quá trình ngược với bước thứ ba, được thực hiện ở bên nhận khi dữ liệu dưới dạng các gói tin được truyền đến. Các gói tin được truyền đến có thể là của nhiều dòng tương ứng với nhiều nguồn dữ liệu khác nhau và cũng có thể thứ tự các gói tin nhận được không giống như khi chúng được gửi đi. Khi đó bên nhận phải căn cứ vào các thông tin được ghi trong từng gói tin để có thể xác định được vị trí về mặt không gian và thời gian của các mẫu dữ liệu mà gói tin mang theo. Việc xác định được vị trí của các mẫu dữ liệu trong gói tin giúp cho việc khôi phục lại nội dung của video hay audio một cách chính xác nhất. Với việc truyền các dòng đơn lẻ không có quan hệ với nhau về măth thời gian, thì nội dung của audio hay video vừa được khôi phục có thể đuợc sử dụng để trình diễn. Còn trong trường hợp có nhiều dòng khác nhau có có quan hệ với nhau về mặt thời gian thực thì cần phải đồng bộ các dòng về mặt thời gian. Việc đồng bộ các dòng chỉ cần thiết khi các dòng có quan hệ với nhau về mặt thời gian, chẳng hạn như việc đồng bộ hình với tiếng khi truyền video, khi đó thời gian thể hiện của các dòng phải được tính toán sao cho phù hợp với nhau. Việc đồng bộ là một công việc phức tạp, thường được thực hiện tự động bởi các giao thức truyền thông thời gian thực như RTP. Khi đó, mặc dù thứ tự các gói tin nhận được có thể không giống như thứ tự khi được gửi, thậm chí có một số gói tin bị mất nhưng giao thức vẫn phải đảm bảo tính đồng bộ cho các dòng khi được thể hiện ở nơi nhận Bước 5 - Giải nén: Bước này sẽ tiến hành giải nén dòng video/audio với chuẩn nén được sử dụng khi nén. Dữ liệu sau khi giải nén có thể được thể hiện ra các thiết bị ra hay được ghi ra file. Chương I: Lựa chọn các giao thức phù hợp với các ứng dụng thời gian thực Trong chương trước chúng ta đã tìm hiểu qua khái niệm truyền dòng và phần nào đã hiểu một số yêu cầu cơ bản của truyền dòng. Chúng ta cũng đã đề cập đến việc sử dụng giao thức RTP cho việc truyền dòng dữ liệu thời gian thực. Vậy tại sao ta lại có sự lựa chọn đấy? Trong phần này chúng ta sẽ đi lý giải sâu hơn việc chọn lựa này, thông qua việc tìm hiểu sơ bộ về các giao thức lớp truyền tải: TCP, UDP cùng với khái niệm truyền đa điểm multicast. Giao thức TCP: ( Transmision Control Protocol) TCP là một giao thức kiểu có liên kết (Connection – Oriented), tức là phải có giai đoạn thiết lập liên kết giữa một cặp thực thể TCP trước khi truyền dữ liệu. Là một giao thức ở tầng giao vận TCP nhận thông tin từ các lớp trên chia nó thành nhiều đoạn nếu cần thiết. Mỗi gói dữ liệu được chuyển tới giao thức lớp mạng (thường là IP) để truyền và định tuyến. Bộ xử TCP của nó nhận thông báo đã nhận từng gói, nếu nó nhận thành công, các gói dữ liệu không có thông báo sẽ được truyền lại. TCP của nơi nhận lắp ráp lại thông tin và chuyển nó tới tầng cao hơn khi nó nhận được toàn bộ. Trước khi các gói dữ liệu được gửi tới máy đích nơi gửi và nơi nhận phải thương lượng để thiết lập một kết nối logic tạm thời. Kết nối này về đặc trưng sẽ ở trạng thái mở trong suốt phiên truyền. Đặc điểm giao thức TCP: Trong bộ giao thức TCP/IP TCP là giao thức được phát triển như là cách để kết nối các mạng máy tính khác nhau về các phương pháp truyền dẫn và hệ điều hành. TCP thiết lập kết nối hai đường giữa hai hệ thống cần trao đổi thông tin với nhau, thông tin trao đổi giữa hai hệ thống được chia thành các gói. TCP có những đặc điểm sau: Sự bắt tay: Hai hệ thống cần kết nối với nhau cần phải thực hiện một loạt các sự bắt tay để trao đổi những thông tin về việc chúng muốn kết nối. Quá trình bắt tay đảm bảo ngăn trặn sự tràn và mất mát dữ liệu khi truyền. Xác nhận: Trong phiên truyền thông tin, hệ thống nhận dữ liệu cần phải gửi các xác nhận cho hệ thống phát để xác nhận rằng nó đã nhận được dữ liệu. Trật tự: Các gói tin có thể đến đích không theo thứ tự sắp xếp của dòng dữ liệu liên tục bởi các gói tin đi từ cùng một nguồn tin theo những đường dẫn khác nhau để đi tới cùng một đích. Vì vậy thứ tự đúng của các gói tin phải được đảm bảo sắp xếp lại tại hệ thống nhận. Phát lại: Khi phát hiện gói tin bị lỗi thì nơi gửi chỉ phát lại những gói tin bị lỗi nhằm để tránh loại bỏ toàn bộ dòng dữ liệu. Hình 1.1 :Hoạt động của giao thức TCP trong việc cung cấp kết nối. Cấu trúc đơn vị truyền tải TCP: Đơn vị dữ liệu sử dụng trong giao thức TCP được gọi là Segment. Khuôn dạng của Segment được mô tả như hình sau: Bit 0 15 16 31 Sourse Port Destination Port Sequence Number Acknowledgment Number Data Offset (4 bits) Reserved (6 bits) URG ACK PSH RST SYN FIN Window (16 bits) Checksum Urgent poier Option Padding TCPdata Hình 1.2: Khuôn dạng TCP Segment. Các tham số của khuôn dạng trên có ý nghĩa như sau: Source Port (16 bits): Số hiệu của cổn bởi gia động bởi giao thức [5]g nguồn. Destination Port (16 bits): Số hiệu cổng của trạm đích. Số hiệu này là địa chỉ thâm nhập dịch vụ lớp giao vận (CCISAP Addess) cho biết dịch vụ mà TCP cung cấp là dịch vụ gì. TCP có số lượng cổng trong khoảng 0á216-1 tuy nhiên các cổng nằm trong khoảng từ 0á1023 là được biết nhiều nhất vì nó được sử dụng cho việc truy cập các dịch vụ tiêu chuẩn, ví dụ 23 là dịch vụ Telnet, 25 là dịch vụ mail . . . . Sequence Number (32 bits): Số hiệu của Byte đầu tiên của Segment trừ khi bit SYN được thiết lập. Nếu bit SYN được thiết lập thì Sequence Number là số hiệu tuần tự khởi đầu (ISN) và Byte dữ liệu đầu tiên là ISN+1. Tham số này có vai trò như tham số N(S) trong HDLC. Acknowledgment Number (32 bits): Số hiệu của Segment tiếp theo mà trạm nguồn dang chờ để nhận. Ngầm ý báo đã nhận tốt các Segment mà trạm trạm đích đã gửi cho trạm nguồn. Tham số này có vai trò như tham số N(R) trong HDLC. Data offset (4bits): Số lượng từ 32 bit trong TCP header (Tham số này chỉ ra vùng bắt đầu của vùng dữ liệu ). Reserved (6 bits): Dành để dùng trong tương lai. Control bits: Các bits điều khiển. Nếu tính từ trái sang phải: URG : Vùng con trỏ khẩn có hiệu lực. ACK : Vùng báo nhận (ACK number) có hiệu lực . PSH: Chức năng PUSH. RST: Khởi động lại (reset) liên kết. SYN : Đồng bộ các số liệu tuần tự (sequence number). FIN : Không còn dữ liệu từ trạm nguồn . Window (16bits): Cấp phát credit để kiểm soát luồng dữ liệu (cơ chế cửa sổ). Đây chính là số lượng các Byte dữ liệu bắt đầu từ Byte được chỉ ra trong vùng ACK number, mà trạm nguồn đã sẵn sàng để nhận. Checksum (16bits): Mã kiểm soát lỗi (theo phương pháp CRC) cho toàn bộ Segment. Urgent Pointer (16 bits) : Con trỏ này trỏ tới số liệu tuần tự của Byte đi theo sau dữ liệu khẩn, cho phép bên nhận biết được độ dài của dữ liệu khẩn. Vùng này chỉ có hiệu lực khi bit URG được thiết lập. Option (độ dài thay đổi): Khai báo các option của TCP, trong đó có độ dài tối đa của vùng TCP data trong một Segment . Padding (độ dài thay đổi): Phần chèn thêm vào Header để bảo đảm phần Header luôn kết thúc ở một mốc 32 bits. Phần thêm này gồm toàn số 0. Việc kết hợp địa chỉ IP của một máy trạm và số cổng được sử dụng tạo thành một Socket. Các máy gửi và nhận đều có Socket riêng. Số Socket là duy nhất trên mạng. Đ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 này giúp cho việc nhận luồng dữ liệu hiệu quả hơn. 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. Những gói tin nào nằm trong vùng cửa sổ ở một thời điểm nhất định sẽ được truyền đi. Thiết lập và huỷ bỏ liên kết: Như ta đã biết TCP là một giao thức kiểu có liên kết, tức là cần phải có giai đoạn thiết lập một liên kết giữa một cặp thực TCP trước khi truyền dữ liệu và huỷ bỏ liên kết khi không còn nhu cầu trao đổi dữ liệu nữa. Thiết lập liên kết TCP: Một liên kết có thể được thiết lập theo một trong hai cách chủ động (active) và bị động (passive). Nếu liên kết được thiết lập theo cách bị động thì đầu tiên TCP tại trạm muốn thiết lập liên kết sẽ nghe và chờ yêu cầu liên kết từ một trạm khác. Tuỳ trường hợp của lời gọi hàm mà người sử dụng phải chỉ ra cổng yêu cầu kết nối hoặc có thể kết nối với một cổng bất kỳ. 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 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. 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. Huỷ bỏ một liên kết: Khi không còn nhu cầu trao đổi dữ liệu nữa thì liên kết TCP có thể được huỷ bỏ. Liên kết có thể được huỷ bỏ theo hai cách: Huỷ bỏ một cách bất thường. Huỷ bỏ một cách bình thường. Liên kết được huỷ bỏ một cách bình thường khi toàn bộ dữ liệu đã được truyền hết. Tức là hai bên không còn nhu cầu trao đổi dữ liệu nữa. 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). Toàn bộ dữ liệu đang truyền có thể bị mất. Truyền và nhận dữ liệu: Sau khi liên kết được thiết lập giữa một cặp thực thể TCP thì có thể tiến hành việc truyền dữ liệu. Với liên kết TCP dữ liệu có thể được truyền theo cả hai hướng. Khi nhận được một khối dữ liệu cần chuyển đi từ người sử dụng, TCP sẽ lưu giữ nó tại bộ đệm gửi. Nếu cờ PUST được dựng thì toàn bộ dữ liệu trong bộ đệm sẽ được gửi đi hết dưới dạng các TCP Sgment. Còn nếu cờ PUST không được dựng thì toàn bộ dữ liệu vẫn được lưu giữ trong bộ đệm để chờ gửi đi khi có cơ hội thích hợp. Tại bên nhận, dữ liệu gửi đến sẽ được lưu giữ trong bộ đệm nhận. Nếu dữ liệu đệm được đánh dấu bởi cờ PUST thì toàn bộ dữ liệu trong bộ đệm nhận sẽ được gửi lên cho người sử dụng. Còn nếu dữ liệu không được đánh dấu với cờ PUST thì chúng vẫn được lưu trong bộ đệm. Nếu dữ liệu khẩn cần phải chuyển gấp thì cờ URGENT được dùng và đánh dấu dữ liệu bằng bit URG để báo rằng dữ liệu khẩn cần được chuyển gấp. Giao thức UDP: (User Datagram Protocol) UDP (User Datagram Protocol) là một giao thức kiểu không kết nối, được sử dụng trong một số yêu cầu ứng dụng thay thế cho TCP. Tương tự như giao thức IP, UDP không thực hiện các giai đoạn thiết lập và huỷ bỏ liên kết, không có các cơ chế báo nhận (Acknowledgement) như trong TCP. UDP cung cấp các dịch vụ giao vận không đáng tin cậy. Dữ liệu có thể bị mất, bị lỗi hay bị truyền luẩn quẩn trên mạng mà không hề có thông báo lỗi đến nơi gửi hoặc nơi nhận. Do thực hiện ít chức năng hơn TCP nên UDP chạy nhanh hơn, nó thường được sử dụng trong các dịch vụ không đòi hỏi độ tin vậy cao. Đơn vị dữ liệu dùng trong giao thúc UDP là UDP Datagram. Khuôn dạng của một UDP Datagrram gồm hai phần : Phần tiêu đề (Header) chứa các thông tin điều khiển và phần Data chứa dữ liệu Khuôn dạng của UDP Datagram cụ thể như hình 2.5. UDP Source Port UDP Destination Port UDP Message Length UDP Checksum Data ... ... Hình 1.3: Khuôn dạng UDP Datagram Trong đó ý nghĩa của các trườnglà: UDP Source Port (16 bits) : Cho biết địa chỉ cổng của trạm nguồn. Nếu nó không được chỉ ra thì trường này được thiết lập là 0. UDP Destination Port (16 bits) : Cho biết địa chỉ cổng của trạm đích. UDP Message Length (16 bits): Cho biết kích thước của một UDP Datagram (kể cả phần Header). Kích thước tối thiểu của một UDP Datagram là 8 Bytes (chỉ có phần Header, không có phần dữ liệu). UDP Checksum (16 bits): Là mã kiểm soát lỗi theo phương pháp CRC . 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. IP Datagram này được ghép vào một khung tin rồi được gửi tới liên mạng đến trạm đích. 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: IP Multicast là một kỹ thuật duy trì dải thông bằng cách làm giảm lưu lượng thông qua việc phân phát đồng thời một luồng dữ liệu tới hang ngàn người bên nhận. Các ứng dụng sử dụng ưu điểm của Multicast như là hội nghị video, truyền thông theo nhóm, lớp học từ xa, hoặc là để phân phối các phần mềm, các chỉ số chứng khoán và tin tức. Hình 1.4: Truyền Multicast IP Multicast thực hiện phân phối nguồn thông tin tới rất nhiều các bên nhận mà không cần them bất thông tin gì vào trong nguồn hay các bên nhận trong khi chỉ sử dụng một mức dải thông tối thiểu. 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. Tất cả mọi con đường đều yêu cầu nguồn phải gửi nhiều hơn một bản copy của dữ liệu. Một vài cách thì yêu cầu nguồn gửi cho mỗi một bên nhận một bản copy độc lập. Nếu như có hang ngàn bên nhận, việc sử dụng IP Multicast là rất có lợi. Với các ứng dụng yêu cầu băng thông cao như là MPEG video, thì nó có thể yêu cầu một phần lớn dải thông đường truyền cho một luồng đơn. Trong những ứng dụng này, cách duy nhất để gửi dữ liệu tới hang ngàn đích một cách đồng thời là sử dụng IP Multicast. Hình dưới đây sẽ cho chúng ta biết làm thế nào mà một nguồn gửi dữ liệu tới nhiều đích sử dụng IP Multicast. Khái niệm nhóm Multicast: Multicast dựa trên khái niệm của nhóm. Một nhóm tuỳ ý của các bên nhận biểu diễn một sự quan tâm đến việc nhận một luồng dữ liệu. Nhóm này không có bất cứ một ranh giới rõ rang về mặt vật lý hay địa lý. Các thành viên (hosts) của nhóm này có thể nằm ở bất cứ nơi nào trên Internet. Các thành viên này có cùng sở thích là nhận một luồng dữ liệu phát tới một nhóm đơn mà để nhận được luồng thông tin này thì buộc phải tham gia vào nhóm sử dụng giao thức IGMP. Các máy này phải là thành viên của nhóm thì mới nhận được luồng dữ liệu mà họ quan tâm. Địa chỉ Multicast: Địa chỉ Multicast chỉ rõ một nhóm tuỳ ý các máy trạm theo IP mà các máy đó tham gia vào nhóm này để nhận dữ liệu gửi tới nhóm. Trong IP multicast thì địa chỉ multicast là địa chỉ nhóm D, có cấu trúc: Hình1.5: địa chỉ multicast. Bốn bít đầu tiên chứa 1110 và xác định đây là địa chỉ multicast. Phần còn lại, 28 bit, xác định nhóm multicast cụ thể. Không còn cấu trúc nào nữa trong nhóm các bit. 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. 1.4 Giao thức nào có thể đáp ứng được yêu cầu thời gian thực? Trong những ứng dụng truyền thông đa phương tiện, yêu cầu đảm bảo khắt khe về thời gian thực (không cho phép có thời gian trễ lớn, jitter). Việc các gói tin đến không liên tục, đều đặn làm cho chất lượng hình ảnh, hoặc âm thanh thu được thấp. Rất có thể gây ra vấp hình, méo tiếng. Để đáp ứng được những yêu cầu này, một giao thức thời gian thực cần có các yếu tố: Hộ trợ việc định tuyến muticast: Với các ứng dụng tryền thông đa phương tiện đòi hỏi thời gian thực, có sự phân phối giống dữ liệu từ một nguồn tới nhiều đầu cuối nhận dữ liệu thì việc hỗ trợ multicast là rất cần thiết. Đây là một yêu cầu rất quan trọng. Khi đó, sẽ tồn tại 1 nguồn phát và rất nhiều nguồn thu, một máy chủ xuất luồng dữ liệu thời gian thực đến rất nhiều máy khách. Nếu ta sử dụng truyền unicast, tải trọng tác động lên máy chủ rất lớn. Trong khi đó, nếu mạng có hỗ trợ truyền multicast, ta chỉ việc xuất một luồng duy nhất từ máy chủ tới một địa chỉ multicast. Sau đó tại các nút mạng, luồng dữ liệu sẽ được nhân lên và chuyển tiếp tới những địa chỉ đích. Hình 1.6:Sử dụng Multicast trong truyền dữ liệu đa phương tiện. Chấp nhận một số gói tin bị lỗi: Không thể đợi để truyền lại các gói, đoạn, gam dữ liệu bị thất lạc. Việc truyền lại các dữ liệu bị thất lạc hoặc bị lỗi sẽ chiếm khá nhiều thời gian. Nó sẽ làm tăng lượng tải trên đường truyền đồng thời kéo dài thời gian trễ của các gói tin. 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. Đặc biệt, khi tín hiệu video được mã hoá theo từng khung hình, mỗi khung hình được vận chuyển trong nhiều gói RTP. Khi đó nhãn thời gian sẽ giúp ta phân định từng nhóm gói tin tương ứng với một hình một cách dễ dàng. Trong những giao thức ở lớp vận chuyển thì giao thức nào có thể đáp ứng được yêu cầu trên: TCP: Đây là một giao thức kiểu có liên kết (Connection – Oriented), tức là phải có giai đoạn thiết lập liên kết giữa một cặp thực thể TCP trước khi truyền dữ liệu. Trong khi truyền dữ liệu giao thức TCP phải đảm bảo các cơ chế xác nhận việc gởi dữ liệu, đảm bảo xắp xếp đúng thứ tự các gói tin tại bên nhận, phát lại các gói tin bị lỗi hoặc thất lạc. Do việc phải đảm bảo những cơ chế này gây lên thời gian trễ lớn, nên giao thức TCP không thể dùng được trong những ứng dụng thời gian thực. 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. Với những đặc điểm trên, TCP không nên được sử dụng trong việc truyền dữ liệu mang tính thời gian thực. UDP: Đây là một giao thức kiểu không kết nối, được sử dụng trong một số yêu cầu ứng dụng thay thế cho TCP. Tương tự như giao thức IP, UDP không thực hiện các giai đoạn thiết lập và huỷ bỏ liên kết, không có các cơ chế báo nhận như trong TCP. UDP cung cấp các dịch vụ giao vận không đáng tin c._.ậy. Dữ liệu có thể bị mất, bị lỗi hay bị truyền luẩn quẩn trên mạng mà không hề có thông báo lỗi đến nơi gửi hoặc nơi nhận. Do thực hiện ít chức năng hơn TCP nên UDP chạy nhanh hơn, nó thường được sử dụng trong các dịch vụ không đòi hỏi độ tin cậy cao. Ngoài ra, giao thức UDP còn có thể sử dụng cho truyền multicast. Do vậy UDP có thể được sử dụng để truyền các dữ liệu thời gian thực. Tuy nhiên để đảm bảo đáp ứng được các yêu cầu của các ứng dụng thời gian thực, giao thức UDP phải được kết hợp với một giao thức lớp trên, đó là giao thức RTP. Chương II: Tổng quan Giao thức thời gian thực RTP (real time protocol) Qua những nhận xét ở chương II, chúng ta đã thấy được, việc truyền thông đa phương tiện, thời gian thực đòi hỏi sự có mặt của một giao thức mới, dựa trên cơ sở giao thức UDP. Đó chính là giao thức RTP. Trong phần này ta sẽ tìm hiểu những điều tổng quan nhất về giao thức này. Những khái niệm ban đầu: RTP là một giao thức chuẩn dùng cho việc truyền các dữ liệu thời gian thực như video, audio. Nó có thể được sử dụng trong media-on-demand cũng như trong các dịch vụ tương tác khác như điện thoại internet…giao thức RTP bao gồm hai phần, dữ liệu và điều khiển (RTCP). Hình 2.1: Mô hình tổng quát về giao thức RTP. Giao thức RTP (Real-time transport protocol), cung cấp các hàm phục vụ việc truyền tải dữ liệu “end to end” cho các ứng dụng thời gian thực, qua các mạng multicast hay qua mạng unicast. Các dịch vụ này bao gồm: Sự phân loại tải: payload type identification. Đánh số thứ tự: sequence numbering. Đánh dấu thời gian phát, đồng bộ hoá: Hình 2.2:Nhãn thời gian và sự đ ồng bộ. Theo dõi quá trình truyền tải: delivery monitoring. Hình 2.3: Kiểm soát quá trình phân phối dữ liệu. Để hỗ trợ cho RTP là giao thức điều khiển RTCP. Giao thức này nhằm đảm bảo cho việc truyền dữ liệu, cho phép theo dõi được quá trình truyền tải trên một mạng multicast. Ngoài ra nó còn cung cấp các dịch vụ cac chức năng điều khiển và nhận dạng. Cả RTP và RTCP đều được thiết kế để có thể cài đặt một cách độc lập với các giao thức lớp mạng và lớp giao vận. Các ứng dụng RTP hoạt động phía trên của chồng giao thức UDP, với vai trò điều chế và cung cấp các dịch vụ kiểm soát lỗi. Tuy nhiên RTP cũng có thể sử dụng kết hợp với các chồng giao thức dưới lớp mạng hay dưới lớp giao vận. RTP hộ trợ truyền tải dữ liệu tới đa điểm theo cơ chế Mutilcast. RTP bản thân nó không hề cung cấp một cơ chế nào nhằm đảm bảo về mặt thời gian, cũng như sự đảm bảo về chất lượng dịch vụ(QoS) của các ứng dụng thời gian thực. Nhưng điều này vẫn được đảm bảo dựa trên các dịch vụ lớp dưới. Cũng như vậy RTP không đảm bảo độ tin cậy hay thứ tự của các gói tin. Nhưng các cơ chế đảm bảo độ tin cậy và việc đảm bảo thứ tự các gói tin nhận được sẽ được đảm bảo dưới các cơ chế của lớp mạng. Số thứ tự được đánh trong khung RTP cho phép bên nhận có thể khôi phục lại thứ tự gói phía gởi, nhưng có thể nó cũng được dùng để định vị gói tin như trong quá trình giải mã tín hiệu Video. Khi đó thì việc giải mã tín hiệu Video theo thứ tự là không nhất thiết. Tuy mục đích đầu tiên của giao thức RTP là nhằm đảm bảo cho các ứng dụng multimedia conference. Tuy nhiên các ứng dụng truyền dòng, các chương trình mô phỏng phân tán, các ứng dụng trong điều khiển, đo lường cũng nhanh chóng tìm thấy sự ứng của RTP. Khi đề cập đến giao thức RTP là chúng ta đề cập đến hai vấn đề: Giao thức truyền tải thời gian thực (real-time transport protocol): Với chức năng truyền tải các dữ liệu có thuộc tính thời gian thực. Giao thức điều khiển RCTP: Với chức năng giám sát chất lượng dịch vụ và truyền các thông tin về những phiên truyền. RTCP giúp cho việc điều khiển các phiên. 2.2 ứng dụng của RTP trong hội thảo đa phương tiện: Để tìm hiểu các ứng dụng của RTP ta xét trong trường hợp cụ thể, hội thảo đa phương tiện. Đây là trường hợp rất điển hình, có thể đại diện cho các ứng dụng truyền dòng thời gian thực. Hình 2.4: Vị trí RTP trong các ứng dụng multimedia 2.2.1 Hội thảo thoại sử dụng multicast đơn giản (Simple Multicast Audio Conference): Nhóm làm việc của 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 Mutilcast 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 tín hiệu điều khiển RCTP. Trong trường hợp cần yêu cầu bảo mật thì dữ liệu trước khi truyền qua hai cổng này sẽ được mã hoá theo chuẩn, các khoá mã cũng sẽ được sinh ra và truyền kèm theo. Mỗi thành viên tham gia hội thoại sẽ gởi dữ liệu thoại theo từng đoạn. Những đoạn dữ liệu sẽ được gắn thêm phần RTP header. Sau đó cả phần RTP header và phần dữ liệu sẽ được đóng vào gói UDP. Phần RTP header sẽ xác định loại mã hoá tín hiệu thoại (PCM, ADPCM…..) được mang trong phần dữ liệu, vì vậy kiểu mã hoá 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 với những thành viên sử dụng đường truyền tốc độ thấp hoặc hay trong trường hợp mạng bị nghẽn. Việc truyền các gói tin trên mạng rất có thể bị 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 đó phía nhận 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 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 hội thoại. Số thứ tự của các gói tin có thể dùng để nhận biết số lượng các gói tin bị thất lạc của mỗi nguồn, kể từ khi họ tham gia hội thoại. Việc này giúp chúng ta có thể đánh giá chất lượng mạng của từng thành viện. Trong quá trình hội thoại, 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 điều sử dụng RTCP. Những thông báo này sẽ xác định các gói tin do mỗi thành viên gởi đi được nhận có tốt không. Dựa vào đó ta có thể điều chỉnh bộ mã hoá động. Ngoài ra việc định danh thành viên cũng như 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 từng 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. 2.2.2 Hội thảo sử dụng thoại và video (Audio and Video Conference): 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, ta sẽ sử dụng đồng thời hai cặp RTP/RTCP. 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 1 định danh cho cả hai tiến trình này thì phía nhận vẫn hoàn toàn có thể ghép 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 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. Trên đây chúng ta đã giả định tất cả các thành viên đều cùng nhận 1 dạng format cho các dữ liệu Media. Đ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 có tốc độ cao. Khi đó ta không thể bắt tất cả các thành viên cùng sử dụng truyền ở tốc độ thấp, chất lượng tín hiệu thấp. Khi đó ta có thể sử dụng bộ trộn RTP-level 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 Unicast cho một người nhận đơn, hoặc Multicast cho một nhóm người nhận. Phần RTP header sẽ đảm nhiệm việc định danh lại người gởi phía 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. Ngoài ra chúng ta còn kể đến trường hợp, một thành viên sử dụng đường truyền tốc độ cao, nhưng họ lại không thể nhận trực tiếp các gói IP multicast. Khi đó ta sẽ phải cài đặt 2 bộ RTP-level mixer. Một được đặt phía trước firewall, một phía sau firewall. Chương III: Giao thức truyền tải thời gian thực (RTP: real time transport protocol) Qua các chương trước chúng ta đã nắm được khái niệm cơ bản thế nào là giao thức RTP, sự cần thiết của nó trong những ứng dụng thời gian thực. Chúng ta đã biết nói về giao thức RTP là đề cập đến 2 khái niệm giao thức truyền tải thời gian thực RTP và giao thức điều khiển RTCP. Trong phần này chúng ta sẽ đi vào tìm hiểu cụ thể giao thức truyền tải thời gian thực. 3.1. Một số khái niệm 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: Đây là phần dữ liệu được truyền trong các gói RTP. Đây có thể là các mẫu tín hiệu thoại hoặc dữ liệu Video đã được nén. Việc phân định dạng dữ liệu (được chỉ định bởi phần payload type) sẽ được để cập đến ở phần sau. RTP packet: Là 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 RTP 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 1 gói lớp dưới chứa 1 gói RTP. Tuy nhiên cũng có trường hợp nhiều gói RTP được đóng vào một gói, điều này hoàn toàn phụ thuộc cách đóng gói của lớp dưới. RTCP packet: Đây là gói tin điều khiển RTCP, có phần tiêu đề cố định gần giống gói RTP. Tiếp theo đến phần có cấu trúc, dạng của cấu trúc sẽ tuỳ 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. Điều này có thể thực hiện được do các gói RCTP 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 nó là số nguyên dương 16Bit. Khái niệm Port tương đương với khái niệm TSEL (transport selectors) trong mô hình OSI. RTP dựa trên các 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: Địa chỉ này phục vụ cho việc vận chuyển dữ liệu. Nó là sự kết hợp giữa địa chỉ mạng và các cổng được định nghĩa ở tầng giao vận. Ví dụ như sự kết hợp giữa địa chỉ IP với một cổng UDP nhất định. Các gói tin sẽ được truyền từ địa chỉ Transport address nguồn tới địa chỉ Transport address đích. RTP media type: Đây là một tập các loại tải có cùng một số tính chất được mang trong phiên truyền RTP. Trong hội thảo đa phương tiện ta có thể có hai loại RTP media type là video-MPEG2 và audio-PCMA. Cụ thể hơn về các loại RTP được trình bày trong phụ lục 3. 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. 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 RCTP). 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). Trong một phiên truyền Mutilmedia, các tín hiệu thành phần (video/audio) được truyền theo một cặp cổng riêng. Hình 3.1: Mô hình phiên RTP. Synchronization source (SSRC): nguồn phát dòng các gói RTP, được định danh bởi 32-bit SSRC trong phần header của 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 nhận 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 (xem chương 7). Hình 3.2: Minh hoạ các nguồn đồng bộ SSRC. 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 1 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 mixer sẽ thay đổi lại các nhãn thời gian cho thích hợp cho mỗi luồng ra. Mixer khi hoạt động có vai trò như một nguồn đồng bộ. Hình 3.3: hoạt động của Mixer. Contributing source (CSRC): Khi dòng các gói RTP được tổng hợp nhờ bộ Mixer. Bộ Mixer sẽ chèn một danh sách CSRC chứa các định danh SSRC của các nguồn đã được tổng hợp. 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. Hình 3.4: Minh hoạ việc chèn danh sách CSRC khi đi qua bộ Mixer. End system: Mỗi ứng dụng mà sinh ra dữ liệu để truyền đi trong những gói RTP, hoặc nhận những dữ liệu này để xử lý được gọi là hệ thống cuối RTP (End system). Một hệ thống cuối này có thể tương đương với một hay nhiều nguồn đồng bộ trong một RTP session, tuỳ thuộc vào số định danh SSRC mà nó sử dụng. Translator: Đâ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. Hình 3.5: Ttranslator. 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. TimeStamp: Được sử dụng theo qui định giao thức thời gian mạng (Network Time Protocol), thời gian tính bằng số giây kể từ 0h UTC ngày 1-1-1900. Giá trị này được biểu diễn bằng 64 Bits. 32 Bits đầu biểu diễn phần nguyên, 32 Bits sau biểu diễn phần thập phân. Tuy nhiên trong một số trường hợp, người ta chỉ dùng 32 Bits giữa, khi đó sẽ cần có sự phân biệt giữa 16Bits cao của phần nguyên và 16Bits cao của phần thập phân. Với cách đánh thời gian theo NTP, đến năm 2036 nó sẽ quay trở lại giá trị zero. Tuy nhiên với các ứng dụng thời gian thực, chúng ta chỉ cần xét khoảng thời gian chênh lệch do đó với chu kỳ như vậy là hoàn toàn thoả mãn. 3.2. Cấu trúc phần tiêu đề gói RTP: Cấu trúc khung phần tiêu đề gói RTP như hình vẽ: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Ver P X CC M PT Sequence Number Timestamp SSRC CSRC [0..15] ::: Hình 3.6: Cấu trúc phần header gói RTP. Trong phần tiêu đề của gói RTP 12 Octets đầu tiên là cố định cho mọi gói RTP. Còn danh sách CSRC chỉ ing vào khi ta cho qua bộ Mixer. Bây giờ ta sẽ phân tích ing năng cụ thể của ing trường: version (V): 2 bits Trường này ing để xác định Verson của RTP. Hiện nay trong truyền Video và Audio RTP đang sử dụng Verson 2. Verson 1 là Verson được sử dụng đầu tiên. Còn Verson 0 chỉ là giao thức ing cài đặt thêm các ing năng cho Audio. padding (P): 1 bit Nừu bit đệm này được đặt giá trị 1, báo rằng gói tin có chứa 1 số byte điều kiện phụ ở phần cuối (cuối phần payload). Byte cuối cùng trong các byte đệm sẽ chứa số các byte đệm đã được thêm, kể cả chính byte đó. Các byte đệm này có thể được ing để mã hoá mật gói tin, hoặc ing trong trường hợp đóng gói nhiều gói RTP trong 1 gói của lớp dưới. extension (X): 1 bit Khi bit này được gán giá trị 1 tức là sau phần tiêu đề cố định sẽ là phần tiêu đề mở rộng. Việc mở rộng thêm phần tiêu đề nhằm tăng thêm lượng thông tin cho gói RTP khi cần thiết. CSRC count (CC): 4 bits Phần này chứa số lượng các bộ nhận dạng CSRC sẽ được thêm vào sau phần tiêu đề cố định. Dùng để xác định số các phần tử 32 bit được chứa trong phần CSRC. Marker (M): 1 bit Bit này được ing với mục đích báo hiệu. Ta có thể ing 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. Payload type (PT): 7 bits Trường này ing để xác định dạng ingt của phần tải để chọn lựa các ứng dụng phù hợp. 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. Nó sẽ có giá trị biến đổi nếu như trong phiên RTP đó ta sử dụng cơ chế định dạng động. 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. Về phía nhận, nếu nhận được gói RTP có định dạng tải mà nó không hiểu, gói này sẽ phải được bỏ qua. Có một số loại tải như: Audio: PCM A-law PCM m-law GSM Video: CelB JPEG H.261 MPEG Cụ thể hơn về định dạng và các hằng số tương ứng của PT được trình bày trong phụ lục 3. Sequence number: 16 bits Số thứ tự được đánh tăng dần theo số lượng các gói RTP được phát đi. Phía nhận sẽ sử dụng số thứ tự này để khôi phục lại trật tự các gói, hoặc ing để phát hiện số lượng gói đã bị mất. Việc khởi tạo các giá trị này nên được thực hiện theo cơ chế ngẫu nhiên, nhằm tăng tính bảo mật, bởi nó có thể được kết hợp với khoá mã. Chúng ta sẽ đề cập rõ hơn ở phần sau. Timestamp: 32 bits Nhãn thời gian được tính theo thời điểm lấy mẫu của byte đầu tiên trong gói RTP. Thời gian được sử dụng theo chuẩn thời gian NTP. Nhãn thời gian phải được lấy từ đồng hồ nhịp chuẩn, có độ chính xác cao, nhằm đảm bảo cho việc kiểm tra đồng bộ và xác định độ Jitter giữa các gói tin khi đến đích. Điều này rất quan trọng, nếu ta truyền tín hiệu Video thì Jitter có thể gây ra hiện tượng vấp hình. Tần số nhịp của nhãn thời gian phụ thuộc vào ing trường hợp cụ thể, thường do loại định dạng tải quyết định. Với ứng dụng thoại, ta lấy mẫu với tần số 8 KHz. Các gói tin sẽ được truyền đi theo ing khối sau mỗi khoảng thời gian 20ms, tương ứng với 160 mẫu, . Do vậy mỗi nhãn thời gian liên tiếp sẽ có giá trị cách nhau 160 đơn vị, không cần quan tâm gói dữ liệu trước có được nhận hay không. Tương tự như số thứ tự, giá trị khởi tạo của nhãn thời gian cho mỗi phiên truyền là ngẫu nhiên. SSRC: 32 bits Trường này ing cho việc định danh một nguồn đồng bộ. Giá trị của trường này được chọn một cách ngẫu nhiên (có kiểm tra xung đột) để tránh trường hợp trong một phiên RTP có nhiều hơn một nguồn đồng bộ sử dụng cùng một giá trị SSRC. Tuy xác ing mà nhiều nguồn phát chọn cùng một định danh là rất hiếm, nhưng chúng ta vẫn phải cài đặt cơ chế xác định và giải quyết sự xung đột này (xem phần 6.1.2). Khi một nguồn thay đổi địa chỉ truyền tải nguồn (source transport address), thì nó cũng phải chọn một giá trị SSRC mới để tránh trường hợp xung đột. CSRC: Danh sách này được ing vào do bộ Mixer. Tại phía người nhận, nó được ing để xác định rõ xem thông tin nào của nguồn nào gởi. Danh sách này sẽ có từ 0 đến 15 phần tử. Mỗi phần tử chiếm 32 bit. Nó được ing để xác định số nguồn tin tạo ra nội dung trong phần tải. Do danh sách chỉ chứa được tối đa 16 phần tử, nên khi có nhiều hơn 16 nguồn tới thì một số nguồn sẽ bị loại bỏ, hoặc sử dụng cơ chế gán vòng. Ta có thể diễn giải cụ thể hơn qua ví dụ: Trong một cuộc hội đàm, có nhiều thành viên cùng gởi tin tức đi. Xét tại bộ Mixer ở gần một thành viên nào đó. Bộ Mixer sẽ tổng hợp các nguồn tin này vào một gói. Đồng thời ing thêm danh sách CRSC , chứa thông tin định danh các nguồn gởi được tổng hợp trong gói tin. Về phía nhận, sau khi gói tin được nhận, dựa vào danh sách này sẽ xác định xem phần thông tin nào trong gói là của thành viên nào gởi. 3.3 Ghép các phiên truyền RTP: Trong giao thức RTP, việc ghép kênh được dựa trên các địa chỉ giao vận (transport address), đây là địa chỉ kết hợp giữa địa chỉ mạng và định danh cổng tham gia phiên truyền. Mỗi địa chỉ này sẽ xác định một phiên RTP. Trong trường hợp một cuộc hội thảo qua mạng, chúng ta sử dụng đồng thời 2 thành phần âm thanh và hình ảnh. Khi đó mỗi thành phần sẽ được mã hoá theo những định dạng khác nhau, được mang trên những phiên RTP độc lập với địa chỉ giao vận riêng. Quá trình phân kênh sẽ được thực hiện dựa trên địa chỉ SSRC. Khi ta truyền các gói dữ liệu khác loại mà sử dụng cùng một địa chỉ SSRC sẽ gặp phải một số vấn đề: 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. Một luồng sẽ được coi là thay đổi cách mã hoá (dựa trên trường payload type). Nhưng nó không thể biết được luồng nào là gốc và luồng nào có thay đổi cách mã hoá. Một nguồn SSRC chỉ ing một dãy nhãn thời gian và một chuỗi số thứ tự. Trong khi đó việc truyền đồng thời nhiều loại tải, tốc độ nhịp khác nhau sẽ yêu cầu phải có một chuỗi số thứ tự riêng để xác định sự thất lạc của các gói tin trong khi truyền. Các bảng thông báo RTCP của phía nhận và phía gởi chỉ có thông tin về 1 dãy nhãn thời gian và một dãy số thứ tự, không hề có thông tin về trường phân loại định dạng tải. Các bộ Mixer không thể hiểu 1 luồng đầu vào bao gồm các thành phần khác định dạng xen lẫn nhau. Để khắc phục vấn đề này, chúng ta có thể chọn giải pháp sử dụng các địa chỉ SSRC khác nhau cho mỗi luồng tín hiệu và truyền chung trong 1 phiên RTP. Nhưng khi đó ta lại gặp phải vấn đề: Việc truyền đồng thời nhiều loại dữ liệu sử dụng chung 1 phiên RTP sẽ có một số vấn đề. Không thể thực hiện việc tìm đường khác nhau đối với ing loại dữ liệu cho phù hợp với tài nguyên của mạng. Không thể cho người ing lựa chọn việc chỉ nhận một loại dữ liệu (tiếng hặc hình). Mà điều này khá cần thiết, khi một thành viên tham gia hội thảo mà đang sử dụng đường truyền tốc độ thấp, họ cần chọn giải pháp chỉ chấp nhận tín hiệu âm thanh. 3.4. sự Thay đổi phần tiêu đề trong một số trường hợp: Với phần tiêu đề như trên, chúng ta có thể đảm bảo được những yêu cầu của tập các hàm cơ bản trong các ứng dụng RTP. Tuy nhiên với một số yêu cầu nâng cao, ta cần thêm vào một số trường trong phần tiêu đề: Các trường M, PT mang các thông tin đặc trưng cho ing ứng dụng. Các trường này được đặt trong phần tiêu đề cố định, trong khi đó để ing được cho rất nhiều ứng dụng khác nhau, đòi hỏi chúng phải có độ dài tới 32 Bit. 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. Tất nhiên, khi ta thêm các byte đánh dấu này thì nên để 1 bit báo hiệu để có thể phân biệt giữa trường hợp có mở rộng và không mở rộng. Bit này sẽ nằm trong phần tiêu đề cố định. Một số thông tin thêm được xác định phụ thuộc vào ing loại định dạng của dữ liệu. Ví dụ, trong trường hợp mã hoá tín hiệu Video, phần thông tin thêm vào nên được đặt trong phần tải. Nó có thể được đặt ở phần đầu tiên của tải hoặc cũng có thể đặt ở một vị trí nào đó trong phần tải mà đã được mặc định trước. Một số lớp ứng dụng, các ing năng cài đặt thêm không phụ thuộc vào loại định dạng tải. Khi đó phần thông tin thêm vào nên là cố định và đặt ngay sau phần tiêu đề cố định. Đ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. Trong khi đó các vẫn thực hiện đồng thời việc phân tích 12 byte tiêu đề cố định. 3.4.1 Phần tiêu đề mở rộng: Một cơ chế mở rộng được cung cấp cho phép việc cài đặt các hàm đơn lẻ hoạt động độc lập với loại định dạng của tải. Cơ chế được thiết kế sao cho phần tiêu đề mở rộng là trong ing đối với các hàm không được cài đặt cơ chế mở rộng. Chú ý rằng, phần mở rộng này chỉ dành cho một số người người ing, khi mà đa phần người sử dụng đều ing đến thành phần này thì nó sẽ được đưa vào phần tiêu đề cố định. 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Defined by profile length Header extension Hình 3.7: cấu trúc phần tiêu đề mở rộng. Nếu bit X ở phần tiêu đề cố định có giá trị 1, phần tiêu đề mở rộng sẽ được nối thêm vào phần tiêu đề cố định, sau phần danh sách CSRC (nếu có). Trong phần mở rộng, 16-bit đầu tiên sẽ chứa số đếm số từ 32-bit được thêm trong phần mở rộng, trừ 32—bit đầu tiên dùng định dạng. Do vậy trường length sẽ lấy giá trị hợp lệ tính từ 0. 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 được thiết kế với 16-bit đầu tiên được dùng với cho việc nhận biết hoặc dùng để truyền tham số. Chương IV: Giao thức điều khiển RTP (RTCP: RTP control protocol) Như ta đã biết, giao thức RTP bản thân nó không có cơ chế bảo đảm gói tin có thể đến đích theo đúng thứ tự, đúng thời gian. Do vậy để có thể điều khiển việc vận chuyển các gói RTP trên mạng cần có thêm một giao thức hỗ trợ. Đó chính là giao thức điều khiển RTP, hay còn được gọi tắt là RTCP. Đây là một phần rất quan trọng trong chùm giao thức RTP. Vậy tại sao RTCP có thể đảm nhận được chức năng này, chúng ta sẽ đi vào tìm hiểu cụ thể các chức năng, cấu trúc và hoạt động của RTCP 4.1 Chức năng và hoạt động của RTCP: Giao thức này dùng để đ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ế như 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 đi qua cổng lẻ, các gói dữ liệu đi qua cổng chẵn. Hình 4.1: Hoạt động của RTCP 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ợp truyền IP multicasrt, thì các thông tin hồi tiếp từ phía người nhận là tối quan trọng cho việc chuẩn đoán các sự cố xảy ra trong quá 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. RTCP mang một thông tin định danh ở lớp vận chuyể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. Ngoà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ày giúp cho việc đồng bộ tín hiệu audio với tín hiệu video. 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. Hai chức năng trên đò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 toán tốc độ truyền. Việc tính toán tốc độ được nêu cụ thể tại phần 4.3 Chức năng tuỳ chọn. Cho phép tuỳ 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 và 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ả cá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 chức năng đầu nên được cài đặt trong mọi môi trường hoạt động, đặc biệt là trong môi trường IP multicast. Những nhà thiết kế ứng dụng RTP nên tránh các cơ chế mà chỉ sử dụng được trong môi trường unicast, không tương thích với số người dùng lớn. 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. 4.2. Các loại gói tin RTCP: Chúng ta sẽ đề cập đến nhiều loại gói tin RTCP tương ứng với những loại thông tin điều khiển khác nhau: SR (Sender report): Bản tin phía gởi, dùng để thông tin về trạng thái truyền và nhận của phía gởi tin. RR (Receiver report): Bản tin người nhận, dùng để thông tin về trạng thái nhận của phía nhận tin. SDES (Source description items): Thông tin mô các về nguồn gởi, bao gồm cả CNAME. BYE: Dùng khi thành viên nào đó thoát khỏi hội thảo. APP (Application specific functions): Xác định các chức năng phụ thuộc vào từng ứng dụng cụ thể. Mỗi gói tin RTCP được bắt đầu với phần tiêu đề cố định tương tự như của gói tin RTP, tiếp theo là các thành phần cấu trúc, chúng có thể có chiều dài biến đổi tuỳ thuộc vào loại của gói tin, nhưng phải giới hạn trong 32-bit. Sự chuẩn hoá và các trường có chiều dài cố định trong mỗi gói RTCP làm cho chúng có thể được lưu trong ngăn xếp. Nhiều gói RTCP có thể được kết nối với nhau thành gói ghép (compound packet ), mà không cần sử dụng dấu phân cách giữa các gói RTCP, khi đưa chúng xuống đóng gói ở các lớp dưới. Ví dụ như đóng trong các gói UDP. 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. Tuy nhiên để thực hiện được điều này thì ta phải thiết lập một số ràng buộc: Các thông báo trạng thái (trong RS hoặc RR) phải được gởi đi định một cách thường xuyên nhất có thể, điều này cho phép để cập nhật các thông tin trạng thái. Trong mỗi gói ghép RTCP, phải có 1 gói mang bản tin (RS hoặc RR). Một người nhận mới cần nhận được giá trị CNAME càng sớm càng tốt. Điều này giúp cho việc định danh nguồ._.ần thiết. khi bộ “translator” thay đổi cách mã hoá dữ liệu thì nó phải thay đổi giá trị của trường đếm số byte của người gởi ( sender's byte count). Nếu bộ “translator” thực hiện việc ghép nhiều gói dữ liệu đầu vào thành một gói dữ liệu đầu ra, nó sẽ phải thay đổi trường đếm số gói mà người gởi đã phát đi (sender's packet count). Nếu “translator” thay đổi nhãn thời gian trong gói RTP thì nó cũng phải thay đổi trường "RTP timestamp" trong gói SR. Các khối thông báo SR/RR: Một bộ “translator” nhận một bản tin báo nhận từ một “cloud” chuyển tiếp đến các “cloud” khác, với trường SSRC không đổi. Chú ý rằng, luồng các bản tin báo nhận có chiều ngược với chiều của luồng dữ liệu RTP. 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”. Điều này có thể là phức tạp. Trong một số trường hợp, không có cách nào hiệu quả để chuyển đổi các bản tin báo nhận, “translator”sẽ tổng hợp các bản tin báo nhận của từng đầu cuối rồi tạo ra một bản báo nhận mới để chuyển đi. Một “translator” không bắt buộc có một định danh SSRC riêng, tuy nhiên cũng nên có một giá trị SSRC dùng với mục đích gởi đi các thông báo nó đã nhận được những gì. Các bản tin này sẽ được gởi tới tất cả các “cloud” kết nối với “translator” đó. Mỗi “cloud” sẽ nhận các bản tin này rồi truyền multicast các thành viên của nó. SDES: Thường thì “translator” sẽ chuyển tiếp các gói tin SDES từ một “cloud” đến các “cloud” khác mà không hề thay đổi gì. Trong trường hợp băng thông hạn chế “translator” sẽ chặn các gói SDES. Các gói CNAME phải luôn được chuyển tiếp vì nó được dùng để xác định xung đột SSRC trên mạng. Khi một bộ “translator” có tạo ra các gói RR của riêng mình thì phải gởi đi các thông tin về SDES, CNAME của nó. BYE: “translator” chuyển tiếp gói BYE, không hề thay đổi gì. khi một bộ “translator” dừng việc chuyển tiếp các gói tin (RTP/RCTP) thì nó sẽ gởi gói BYE đến tất cả các “cloud” mà nó kết nối. 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). APP: Gói này được chuyển tiếp hoàn toàn không thay đổi gì. 5.3. Hoạt động của Mixers: Do “mixer” luôn tạo ra các luồng dữ liệu mới của riêng mình, nó sẽ không chuyển thẳng các gói SR hay RR mà nó sẽ tái tạo lại các thông tin rồi mới chuyển đi. Hình 5.3: Hoạt động của Mixer. Bây giờ ta sẽ đi tìm hiểu, cách xử lý của mixer với từng loại gói tin RTCP. SR (sender information): Bộ “mixer” không chuyển thẳng các bản tin SR bởi vì một số đặc tính của nguồn đều bị thay đổi khi qua bộ “mixer”. Bộ “mixer” sẽ đóng vai trò như một nguồn đồng bộ, nó sẽ tạo ra gói SR riêng với thông tin thông báo cho luồng dữ liệu đã được trộn tại đầu ra. SR/RR (reception report blocks): Tương tự như trên, bộ “mixer” cũng sẽ tạo ra bản tin báo nhận mới tương ứng với các nguồn gởi. Trong bản tin báo nhận mà bộ “mixer” gởi đi nguồn nhận sẽ không được xác định dựa trên trường SSRC mà sẽ được xác định dựa trên danh sách CSRC. Do vậy các bản tin báo nhận cho một nguồn ở trong một “cloud” nào thì chỉ được gởi đến “cloud” đó, không được gởi đến các “cloud” khác. Cũng không được chuyển tiếp một bản tin báo nhận từ một “cloud” đến một “cloud” khác. SDES: Bộ “mixer” thường nhận các gói SDES từ một “cloud” chuyển tiếp đến các “cloud” khác mà không thay đổi gì. Tuy nhiên trong trường hợp mạng có băng thông hạn chế, “mixer” cũng giống như “translator” sẽ hạn chế việc truyền đi các gói SDES không mang CNAME. Các gói SDES-CNAME được truyền đi để sử dụng cho việc phát hiện xung đột SSRC trên mạng. Hình 5.4: khả năng phát hiện vòng lặp hoặc xung đột của mixer. Chú ý: một định danh SSRC trong danh sách CSRC được tạo bởi “mixer” có thể xung đột với một giá rị SSRC được phát bởi một hệ thống cuối. Ngoài ra bộ “mixer” phải gởi các gói SDES-CNAME của nó tới các “cloud” mà nó gởi tới các gói SR, RR. 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. Các gói SDES này sẽ được xếp vào trong các bản tin SR hoặc RR được phát đi bởi “mixer”. Vì thế mà tốc độ gói RTCP có thể khác nhau tại hai phía của một bộ “mixer”. Một bộ “mixer” tổng hợp các gói SDES sẽ sử dụng băng thông RTCP nhiều hơn một nguồn đơn bởi cac gói SDES ghép có kích thước lớn hơn. Điều này là hoàn toàn hợp lý bởi một bộ “mixer” đại diện cho nhiều nguồn đơn. Đố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. BYTE: Một bộ “mixer” phải chuyển thẳng các gói BYTE. Khi bộ “mixer” muốn rời khỏi phiên làm việc, nó sẽ gởi một gói BYTE đến tất cả các “cloud” có kết nối đế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”. APP: Việc xử lý các gói AAP tại “mixer” sẽ phụ thuộc vào từng ứng dụng cụ thể. 5.4. 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ư trên hình vẽ Hình5.5 :Mô hình phân tầng các Mixer. Nếu 2 “mixer” được phân tầng như M2 và M3 trong hình, các gói được nhận bởi một “mixer” đã được tổng hợp và đã được chèn thêm danh sách CSRC. Bộ “mixer” sau đó sẽ tạo danh sách CSRC ở đầu ra dựa vào danh sách CSRC từ “mixer” trước và các định danh SSRC của các gói chưa được trộn. Trên hình vẽ đầu ra của M3 sẽ có danh sách CSRC là (64,45). Giá trị này được tổng hợp từ danh sách CSRC chuyển tới từ M2 (64) với giá trị SSRC của đầu cuối E5:45. Cũng giống như trong trường hợp không phân tầng, nếu danh sách CSRC có nhiều hơn 15 định danh thì những giá trị từ 16 trở đi sẽ không được thêm. Trường hợp này để không xảy ra mất các nguồn từ 16 trở đi, ta sử dụng một cơ chế vòng lặp, chèn luân phiên. Phần VI: Một số thuật toán cần chú ý 6.1. Phân phối các định danh SSRC: Định danh SSRC được mang trong phần tiêu đề RTP cũng như trong nhiều trường khác của gói RTCP là một số ngẫu nhiên 32-bit. Giá trị của nó phải hoàn toàn là duy nhất trong một phiên RTP. Điều cốt yếu là làm thế nào để chọn ra được các giá trị định danh SSRC để cho các thành viên trong cùng mạng hay cùng bắt đầu vào một thời điểm là không giống nhau. Sẽ không thoả mãn nếu như ta sử dụng địa chỉ của mạng cục bộ để định danh bởi vì địa chỉ này có thể là không duy nhất. Ngoài ra khi các bộ “translators” và “mixers” xử lý trong các liên mạng. Nếu các liên mạng này phân chia địa chỉ theo một qui tắc nào đó thì khả năng xảy ra xung đột sẽ cao hơn so với việc phân chia một cách ngẫu nhiên. Việc nhiều nguồn cùng chạy trên một máy chủ cũng có thể gây ra xung đột. Tuy nhiên, việc xác định SSRC cũng không chỉ đơn giản là cứ chọn một giá trị ngẫu nhiên mà không quan tâm đến trạng thái khi khởi tạo. Ví dụ về cách tạo một giá trị SSRC được nêu ở phụ lục 6A[]. Bây giờ chúng ta sẽ thử tính xác suất xảy ra xung đột. 6.1.1Xác suất xung đột: Khi các giá trị SSRC được chọn một cách ngẫu nhiên, sẽ có thể xảy ra khả năng nhiều hơn một nguồn chọn cùng một giá trị, dẫn đến xung đột. Xác suất xảy ra xung đột sẽ cao hơn nếu tại một thời điểm có nhiều người bắt đầu đồng thời. Nếu ta giả sử, có N nguồn tham gia, mỗi nguồn sử dụng định danh có độ dài L-bit (ở đây L=32), khi đó xác suất 2 nguồn độc lập chọn cùng một giá trị sẽ được tính gần đúng khi N rất lớn theo công thức sau: PCollision=1 - exp(-N2 / 2L+1). Nếu ta lấy N=1000, L=32 thì PCollision=10-4. Ta thấy giá trị này khá nhỏ. Nhưng trên thực tế thì giá trị này còn nhỏ hơn. Bởi vì khi một nguồn tham gia vào một phiên RTP mà trong đó đã tồn tại sẵn một số nguồn khác với các giá trị định danh hợp lệ rồi, xác suất xảy ra xung đột chỉ sẽ được tính trên khoảng giá trị còn trống. Khi đó, nếu N là số nguồn, L chiều dài của phần định danh thì xác suất xung đột sẽ là: PCollision=N/2L. Nếu N=1000 thì PCollisioncũng chỉ xấp xỉ 2.10-7, một giá trị nhỏ hơn rất nhiều. 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). Nguồn mới kiểm tra các giá trị SSRC của những nguồn khác, trước khi phát đi gói số liệu đầu tiên, nó kiểm tra xem SSRC của mình có xung đột với một nguồn nào có sẵn không. Nếu có, nó sẽ chọn lại giá trị mới một cách ngẫu nhiên. Phát hiện vòng lặp và giải quyết xung đột: Mặc dù xác suất xảy ra xung đột các định danh SSRC là nhỏ, nhưng mọi ứng dụng RTP đều phải có sự cài đặt các cơ chế để phát hiện xung đột và chọn ra các cơ chế giải quyết thích hợp. Bất cứ khi nào một nguồn nhận ra rằng có một nguồn khác đang sử dụng SSRC trùng với mình thì nó sẽ gởi gói RTCP-BYTE với định danh SSRC cũ, sau đó nó sẽ chọn lại một giá trị SSRC ngẫu nhiên khác. Khi một người nhận phát hiện ra rằng có hai nguồn đang xung đột, nó sẽ chọn giữ lại các gói tin của một nguồn và loại bỏ các gói tin của nguồn kia. Việc phân biệt hai nguồn này được thực hiện dựa trên giá trị của địa chỉ truyền tải của nguồn hoặc dựa trên trường CNAME. Cả hai nguồn xung đột đều được cài đặt cơ chế giải quyết xung đột, do vậy tình trạng này sẽ không kéo dài. 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”. Vòng lặp là hiện tượng nhân đôi các gói dữ liệu hoặc thông tin điều khiển và truyền chúng tới cùng đích. Vòng lặp xuất hiện do một số nguyên nhân gây sau: Một bộ “translator” có thể chuyển tiếp 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. Trong trường hợp này, cùng một gói dữ liệu sẽ xuất hiện nhiều lần tại bên nhận, xuất phát từ các nguồn khác nhau. Hình 6.1: Minh hoạ lặp vòng. Khi hai “translator” mắc song song, được cài đặt không đúng cách, chúng có cùng một nhóm địa chỉ multicast, do vậy khi một gói tin được chuyển tới, nó sẽ đồng thời được chuyển tiếp tới cùng 1 địa chỉ đích. Các bộ “translator” đơn hướng sẽ tạo ra 2 bản copy, còn các bộ “translator” hai chiều sẽ có thể hạn chế được vòng lặp. Khi một nguồn nhận ra rằng gói tin của nó đang bị lặp vòng, hoặc gói tin của một nguồn khác bị lặp vòng. Cả sự lặp vòng và xung đột do việc chọn các giá trị SSRC một cách ngẫu nhiên đều gây ra việc các gói dữ liệu đến co cùng định danh SSRC nhưng lại có địa chỉ giao vận khác nhau. Bởi vậy khi một nguồn thay đổi địa chỉ giao vận của mình thì phải chọn một giá trị SSRC mới để tránh gây ra lặp vòng. Đ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. Khi một bộ “translator” restart, địa chỉ giao vận của nó cũng thay đổi (do địa chỉ cổng UDP của nguồn thay đổi), nếu trước đó nó đã gởi đi các gói số liệu thì các gói này sẽ bị coi là lặp vòng đối với bên nhận. Do giá trị SSRC trên các gói đó là giá trị cũ khác với giá trị SSRC của nguồn sau khi khởi động lại. vấn đề này có thể tránh được bằng cách giữ nguyên địa chỉ giao vận trong quá trình khởi động lại. Khi xung đột hoặc lặp vòng xảy ra cách xa “mixer” hoặc “translator” sẽ không thể phát hiện được dựa trên địa chỉ giao vận, nếu tất cả các bản sao của gói đều được chuyển qua 1 bộ “translator” hoặc “mixer”. Khi đó xung đột phải được phát hiện dựa trên trường CNAME. Nếu xung đột SSRC xảy ra, sẽ dẫn đến hiện tượng 2 gói tin có cùng SSRC nhưng lại cho CNAME khác nhau. Để có thể phát hiện và giải quyết những xung đột, RTP cần phải được cài đặt thêm một thuật toán như được nêu ở phần sau. Theo thuật toán này, các gói tin của một nguồn mới tham gia hoặc sự lặp vòng gây lên xung đột với một nguồn có săn sẽ bị bỏ qua. Nó giải quyết xung đột giá trị SSRC của các thành viên bằng cách gởi đi gói RTCP-BYTE, mang giá trị SSRC cũ (bị xung đột), chọn lại một giá trị SSRC mới. Tuy nhiên khi xung đột gây ra bởi sự lặp vòng các gói tin của chính mình, thuật toán sẽ chọn một định danh mới duy nhất một lần và sau đó bỏ qua tất các các gói từ địa chỉ nguồn bị lặp vòng. Việc này là nhằm tránh trường hợp các gói BYTE khi gởi đi cũng bị lặp dẫn đến việc tràn ngập gói BYTE. Theo thuật toán này, cần phải tạo một bảng, đánh số bằng các giá trị SSRC, địa chỉ giao vận của các nguồn. Các giá trị này được ghi vào bảng khi gói RTP và gói RTCP đầu tiên mang định danh mới được nhận. Bảng sẽ được cập nhật các trạng thái của của các nguồn. Mỗi giá trị SSRC hay CSRC nhận được từ các gói RTP hoặc RTCP sẽ được so sánh với các giá trị trong bảng để cập nhật các thông tin về dữ liệu hoặc thông tin điều khiển. Nếu địa chỉ nguồn ban đầu được nhận thông qua một ”mixer” và sau đó nó nhận được từ nguồn đó một cách trực tiếp, thì bên nhận được khuyến cáo nên chọn địa chỉ mới hơn. 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. Khi có một định danh SSRC mới được chọn do hiện tượng xung đột, thì định danh SSRC được chọn phải được kiểm tra trong bảng định danh nguồn để xem nó đã được dùng bởi nguồn nào hay chưa. Nếu định danh đó đã được dùng rồi thì định danh khác được tạo ra và tiếp tục quá trình kiểm tra đó. Một vòng lặp các gói dữ liệu có thể gây ra hiện tượng tràn khi nó được multicast. Tất cả các ”mixer” và ”translator” phải thực hiện thuật toán phát hiện vòng lặp để phá vỡ chúng. 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. 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). Thuật toán sẽ được nêu ở phần phụ lục. 6.2 Vấn đề bảo mật trong RTP: Các giao thức lớp dưới có thể cung cấp tất cả các dịch vụ bảo mật cần thiết cho một ứng dụng RTP, bao gồm chức năng xác thực, tính toàn vẹn và khả năng che dấu dữ liệu. Những dịch vụ này đã được chỉ định ở lớp IP. Khi khởi tạo một ứng dụng audio và video sử dụng RTP cần che dấu dữ liệu trước khi đưa xuống lớp IP ta sử dụng che dấu dữ liệu của các gói RTP/RTCP. Khả năng che dấu dữ liệu: Che dấu dữ liệu có nghĩa là chỉ những người nhận mong đợi mới có thể giải mã được gói tin nhận được, đối với những người nhận khác gói tin không cung cấp một thông tin hữu ích nào. Để che dấu dữ liệu của nội dung gói tin ta sử dụng mã mật. Với cách mã hoá các gói RTP và RTCP được đề ra ở đây, tất cả các octets sẽ được đóng gói để truyền trong một gói đơn ở giao thức lớp dưới và được mật hoá thành một khối dữ liệu hoàn chỉnh. Đối với các gói RTCP, một số 32-bit ngẫu nhiên, sẽ được gắn thêm trước khi được mã hoá. Đối với các gói RTP, ta không gắn thêm gì nhưng sẽ khởi tạo các trường số thứ tự và nhãn thời gian trong những khoảng ngẫu nhiên. Ngoài ra đối với gói RTCP, có thể chia những gói RTCP đơn lẻ trong 1 gói ghép RTCP thành 2 gói RTCP ghép. Sau đó một gói sẽ được mã hoá còn một gói sẽ được truyền đi trực tiếp. Ví dụ các thông tin SDES có thể được mã hoá trong khi đó các bản tin báo nhận thì được truyền đi trực tiếp, để các thành viên thứ ba (nhà quản trị) có thể theo dõi mà không cần khoá mã. Để kiểm tra gói tin có được mã mật không và để kiểm tra xem khoá giải mã có đúng không sẽ được thực hiện tại bên nhận thông qua việc kiểm tra sự hợp lệ của phần tiêu đề và phần tải. Thuật toán được sử dụng cho việc mã hoá mật được dùng là DES (Data Encryption Standard algorithm ) được nêu trong RFC 1423. Do khuôn khổ của đồ án, ta chỉ dừng vấn đề ở đây. Nhận thực và bảo toàn dữ liệu (Integrity and authenticity): Dịch vụ nhận thực và bảo toàn dữ liệu không được thực hiện ở lớp RTP nó sẽ được thực hiện ở các tầng giao thức dưới. 6.3. Điều khiển tắc nghẽn: Mọi giao thức truyền tải được sử dụng trên internet phải cung cấp khả năng điều khiển tắc nghẽn bằng một vài cách nào đó. Giao thức RTP cũng không là một ngoại lệ, tuy nhiên dữ liệu truyền tải bằng giao thức RTP thường có tốc độ khó thay đổi (nó thường có tốc độ cố định hoặc được ấn định trước một giá trị nào đó). Các phương tiện dùng để điều khiển tắc nghẽn của RTP có thể hơi khác biệt so với các giao thức truyền tải khác như TCP. Theo một cách nào đó, việc không thể thay đổi tốc độ của RTP làm giảm nguy cơ gây tắc nghẽn, bởi vì luồng RTP sẽ không trải hết khoảng băng thông cho phép như giao thức TCP. Việc không thay đổi tốc độ truyền của luồng RTP có nghĩa là không thể giảm tải trên mạng khi xảy ra tắc nghẽn. Do RTP có thể sử dụng trong nhiều ứng dụng khác nhau, trong những ngữ cảnh khác nhau, nên không thể có một cơ chế điều khiển tắc nghẽn nào có thể sử dụng cho tất cả. Vì thế, việc điều khiển tắc nghẽn sẽ được định nghĩa trong từng ứng dụng RTP cụ thể cho phù hợp. Một số loại ứng dụng có thể cài đặt một số câu lệnh hạn chế người sử dụng để tránh xảy việc tắc nghẽn. Một số loại ứng dụng khác có thể sử dụng những cơ chế thay đổi tốc độ dữ liệu dựa trên những thông tin hồi đáp từ RTCP. 6.4. RTP với các giao thức lớp mạng và lớp giao vận: Giao thức RTP nhờ vào các giao thức lớp dưới để phân thành các luồng dữ liệu RTP và luồng điều khiển RTCP. Đối với UDP và những giao thức tương tự, RTP nên sử dụng những cổng chẵn và luồng RTCP nên sử dụng cổng lẻ liền sau. Trong những ứng dụng mà các cổng đich RTP và RTCP được chỉ định rõ ràng, tách biệt các tham số (có thể sử dụng giao thức báo hiệu hoặc các phương tiện khác), khi đó ứng dụng sẽ không cần quan tâm đến điều kiện cặp cổng chẵn/lẻ. Tuy nhiên việc phân định các cổng RTP/RTCP theo dạng chẵn/lẻ vẫn luôn được khuyến khích. Ta phải phân định các cổng khác nhau cho RTP và RTCP vì giao thức RTP dựa trên số hiệu cổng để tách các luồng dữ liệu RTP và luồng điều khiển RTCP. Trong những phiên truyền unicast cả hai thành viên đều cần xác định một cặp cổng để nhận các gói RTP và RTCP. Cả hai thành viên có thể sử dụng cùng một cặp cổng. Khi các gói RTP được gởi theo cả hai hướng, các gói RTCP-SR của mỗi thành viên phải được gởi tới cổng mà thành viên kia dùng để nhận RTCP. Các gói RTCP-SR kết hợp cả thông tin về dữ liệu được gởi lẫn bản tin báo nhận. Nếu bên nào không ở trạng thái truyền dữ liệu thì nó sẽ gởi đi gói RTCP-RR. Khi địa chỉ multicast được sử dụng, địa chỉ cũng phải được tách biệt rõ ràng, bởi vì việc chọn đường dựa trên địa chỉ multicast và quan hệ nhóm thành viên được được quản lý dựa trên địa chỉ riêng rẽ. Chú ý, việc phân định các địa chỉ multicast liên tiếp không được thực hiện, bởi vì một số nhóm có yêu cầu những phạm vi khác nhau, nên phải được phân cho những khoảng địa chỉ khác nhau. Các gói dữ liệu RTP không chứa trường độ dài hay thông tin mô tả khác, do đó RTP phải dựa vào các giao thức bên dưới để cung cấp một số thông tin về độ dài. Độ dài lớn nhất của các gói RTP chỉ bị giới hạn bởi các giao thức lớp dưới. Nếu các gói RTP được vận chuyển bởi giao thức lớp dưới mà giao thức này cung cấp sự hỗ trợ luồng, sự đóng gói các gói RTP phải được hỗ trợ các cơ chế framing. Việc tạo khung cũng cần thiết nếu giao thức lớp dưới có chứa phần đệm làm cho phần mở rộng tải của RTP không được xác định rõ. Do phạm vi của đề tài, chúng ta sẽ không đi tìm hiểu cơ chế framing. 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). Việc mang nhiều gói RTP trong một gói đơn ở lớp giao vận hoặc lớp mạng giúp cho việc giảm thiểu kích thước tổng cộng phần tiêu đề và có thể làm cho việc đồng bộ giữa các luồng đơn giản hơn. Chương VII: ứng dụng lý thuyết vào thực tế Với phương châm, học đi đôi với hành, sau những gì đã tìm hiểu về giao thức RTP và RTCP, em đã cùng một số bạn đã thử áp dụng một mô hình RTP vào thực tế. Chúng em đã chọn mô hình truyền hình theo yêu cầu (video on demand). Công việc của chúng em là thiết kế một website quản lý VoD. Tuy có những hạn chế về hiểu biết, kinh nghiệm cũng như điều kiện vật chất, kỹ thuật nhưng chúng em cũng đã thu được một số kết quả nhất định. 7.1 Phân tích yêu cầu đặt ra: Thông lượng đường truyền: Tuỳ thuộc vào băng thông cho phép của mạng, ta có thể quyết định sử dụng chuẩn nén thích hợp. Với các mạng cục bộ, các chuẩn nén có thể được sử dụng bao gồm MPEG, H.263 và JPEG. Việc sử dụng các chuẩn nén này cho phép đạt được băng thông các dòng video trong khoảng từ 200 kbps tới 2 Mbps. Độ trễ: Độ trễ làm ảnh hưởng đến chất lượng video. Điều mong muốn là đạt được độ trễ nhỏ nhưng bị giới hạn bởi kênh truyền. Độ trễ chấp nhận được đối với các cuộc hội thoại video nằm trong khoảng từ 150 ms tới 200 ms. Với các dòng video có độ trễ lớn hơn 200 ms, tính thời gian thực sẽ không đảm bảo và đối với tai người có thể phát hiện ra độ trễ và làm cuộc hội thoại trở nên khó khăn. Jitter: Thông thường nếu giá trị của jitter nằm trong khoảng từ 10 ms tới 30 ms coi như chấp nhận được trong việc truyền hình. Kiểm soát và cân bằng lưu lượng: Kiểm soát lưu lượng: Với một băng thông cho trước, hạn chế về dung lượng, chúng ta phải phân phối băng thông một cách hợp lý để ứng dụng có thể chạy hiệu quả nhất, đảm bảo được nhiều client có thể xem đồng thời. Băng thông cho dòng video: Với một băng thông khoảng 740kbps dùng chuẩn nén MPEG là có thể cho ta chất lượng hình ảnh tương đối tốt. Băng thông cho dòng audio: Thông thường, băng thông mà một dòng audio cần là khoảng từ 56 đến 128kbps. Với mạng LAN, có điều kiện băng thông khá rồi dào (10Mbps) ta có thể chọn tốc băng thông dành cho dòng thoại 128M. Băng thông dùng điều khiển: Đây là băng thông giành cho những thông tin điều khiển trong giao thức RTP nằm trong các gói RTP, RTCP. Nó sẽ được tính bằng tốc độ của phần tiêu đề gói RTP+tốc độ của cả gói RTCP. Để kiểm soát lưu lượng, ta có thể sử dụng cơ chế tĩnh hoặc cơ chế động. Cơ chế tĩnh: Băng thông được cố định sẵn cho mỗi phiên truyền RTP, nó được duy trì trong suốt phiên và được giải phóng khi kết thúc phiên. Cơ chế động: Băng thông được cấp phát cho mỗi phiên truyền RTP được thay đổi phụ thuộc vào khả năng cung cấp của đường truyền, hay phụ thuộc số phiên RTP tham gia trên toàn mạng. b. Cân bằng lưu lượng: Cơ chế này được sử dụng để làm giảm độ chênh lệch quá lớn giữa các dòng video. Để thực hiện việc này ta phải thực hiện theo trình tự. Kiểm tra lưu lượng của dòng video lớn nhất xem có chất lượng có vượt hơn chất lượng tối thiểu không? Nếu chất lượng vượt qua chất lượng tối thiểu ở một khoảng nào đấy thì giảm lưu lượng dòng video xuống. Lặp lại quá trình trên cho đến khi các dòng đạt được tổng lưu lượng cho phép. Các phương pháp điều khiển lưu lượng dòng video: Thay đổi độ phân giải. Thay đổi tốc độ khung hình. Thay đổi chất lượng hình ảnh (số mầu của ảnh). 7.2. thực hiện: Mô hình triển khai là : Server: Sử dụng hệ điều hành Linux 9.0: Hệ điều hành mã nguồn mở, tính đa nhiệm cao, ổn định, rẻ tiền. Cơ sở dữ liệu Posgresql 7.43: Một hệ cơ sở dữ liệu mạng rất mạnh, có khả năng hộ trợ Java tốt, tốc độ cao, hộ trợ các chức năng giao tác, miễn phí, mã nguồn mở. Chùm ngôn ngữ lập trình Java (jsp, servlet, javaScript, EJB, JMF, java): Đây là những ngôn ngữ thuộc họ Java, chạy trên môi trường máy ảo, có rất nhiều hàm thư viện sẵn có. Đặc biệt java là ngôn ngữ hướng đối tượng, khả chuyển, linh động, hiệu quả cao. Máy chủ Tomcat: khả năng quản lý tốt, hộ trợ jsp và servlet, dễ sử dụng. Phương thức truyền: File video được nén theo chuẩn MPEG được lưu trên máy chủ. Khi có yêu cầu từ máy khách, máy chủ sẽ đọc file, xử lý, xuất thành luồng tới máy khách. Hình 7.1: Mô hình hoạt động. Phương thức báo hiệu: Việc truyền các luồng video được điều khiển và báo hiệu bằng giao thức RTCP. Client: Sử dụng microsoft windows media phiên bản từ 7.x, có khả năng hỗ trợ luồng (streaming suport). Khi chơi một streaming media, ta có thể quan sát được những thông tin về chất lượng kết nối, tốc độ bit hiện thời, tốc độ hình ảnh… 7.3. Kết quả: Sau một thời gian thực hiện, chúng em đã hoàn thành một website quản lý VoD trên hệ điều hành Linux với đầy đủ các chức năng của nhà quản trị VoD, đáp ứng được nhu cầu xem phim trực tuyến. Kết quả thu được như sau: Hình 7.2: Màn hình trang chủ Hình 7.4: Các chức năng phục vụ đối với Client. Hình 7.3: Chức năng quản lý của VoD admin. Phụ lục Kiểm tra phần tiêu đề RTP : RTP Data Header Validity Checks Bên nhận trong giao thức RTP phải kiểm tra tính hợp lệ của phần tiêu đề RTP của các gói tới, trong trường hợp chúng được mã mật hay là một gói tin bị nhầm địa chỉ từ một ứng dụng khác. Tương tự, nếu khi mã hoá mật theo phương thức được mô tả ở phần 9, thì phải thực hiện kiểm tra phần tiêu đề để khẳng định quá trình giải mã mật là chính xác. Việc kiểm tra tính hợp lệ của phần tiêu đề RTP được thực hiện theo một số qui tắc sau: Giá trị trường RTP version phải bằng 2. Kiểu tải (payload type) phải được xác định, phải khác kiểu SR và RR. Nếu bit P được thiết lập bằng 1, khi đó byte cuối cùng của gói phải chứa số byte hợp lệ (nhỏ hơn tổng kích thước gói trừ đi kích thước phần tiêu đề). Bit X phải bằng 0 nếu kiểu ứng dụng chưa được xác đinh, khi đó phần tiêu đề mở rộng được sử dụng. Ngược lại, trường kích thước mở rộng (extension length field) phải nhỏ hơn tổng kích thước gói trừ đi kích thước phần tiêu đề cố định và phần thêm (padding). Kích thước của gói phải nhất quán với CC và payload type. (nếu phần tải có kích thước đã biết). Trong những qui định trên, 3 qui tắc cuối cùng là khá phức tạp và có thể bỏ qua. Nếu phần định danh SSRC trong gói là một giá trị đã được nhận trước đây, khi đó gói có thể hợp lệ nếu số thứ tự nằm trong khoảng giá trị cho phép. Nếu định danh SSRC lần đầu tiên được nhận, khi đó gói tin mang định danh này sẽ bị coi là không hợp lệ cho đến khi nhận được một số các gói tin có số thứ tự liên tiếp. hững gói được coi là không hợp lệ sẽ bị loại bỏ hoặc có thể được lưu lại và được đem ra sử dụng khi bắt đầu có gói tin hợp lệ trong thời gian trễ cho phép. 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. Kiểm tra phần tiêu đề RTCP: Việc kiểm tra phần tiêu đề gói RTCP cũng được thực hiện tương tự với các qui tắc sau: RTP version bằng 2. Trường payload type của gói RTCP đầu tiên trong gói ghép phải bằng SR hoặc RR. Bit đệm (P) phải bằng 0 đối với gói đầu tiên trong gói ghep RTCP. Bởi vì phần đệm chỉ được thêm, nếu cần thiết, vào cuối gói. Những trường kích thước của từng gói RTCP riêng cộng lại phải bằng tổng kích thước của gói RTCP ghép nhận được. Việc kiểm tra này nhằm chuẩn hoá. Nếu trường hợp một gói RTCP có kiểu chưa xác định thì phải được nhận ra và bỏ qua. 3. Các hằng số dùng cho Payload Type: PT Name Type Clock rate (Hz) Audio channels References 0 PCMU Audio 8000 1 RFC 3551 1 1016 Audio 8000 1 RFC 3551 2 G721 Audio 8000 1 RFC 3551 3 GSM Audio 8000 1 RFC 3551 4 G723 Audio 8000 1 5 DVI4 Audio 8000 1 RFC 3551 6 DVI4 Audio 16000 1 RFC 3551 7 LPC Audio 8000 1 RFC 3551 8 PCMA Audio 8000 1 RFC 3551 9 G722 Audio 8000 1 RFC 3551 10 L16 Audio 44100 2 RFC 3551 11 L16 Audio 44100 1 RFC 3551 12 QCELP Audio 8000 1 13 CN Audio 8000 1 RFC 3389 14 MPA Audio 90000 RFC 2250, RFC 3551 15 G728 Audio 8000 1 RFC 3551 16 DVI4 Audio 11025 1 17 DVI4 Audio 22050 1 18 G729 Audio 8000 1 19 reserved Audio 20-24 25 CellB Video 90000 RFC 2029 26 JPEG Video 90000 RFC 2435 27 28 nv Video 90000 RFC 3551 29 30 31 H261 Video 90000 RFC 2032 32 MPV Video 90000 RFC 2250 33 MP2T Audio/Video 90000 RFC 2250 34 H263 Video 90000 35-71 72-76 Reserved 77-95 96-127 dynamic dynamic GSM-HR Audio 8000 1 dynamic GSM-EFR Audio 8000 1 dynamic L8 Audio variable variable dynamic RED Audio dynamic VDVI Audio variable 1 dynamic BT656 Video 90000 dynamic H263-1998 Video 90000 dynamic MP1S Video 90000 dynamic MP2P Video 90000 dynamic BMPEG Video 90000 Tài liệu tham khảo Nguyễn Quốc Cường (2001) – Internetworking với TCP/IP. Andrew S.Tanenbaum (2002) - Mạng mỏy tớnh. Biờn soạn và lược dịch Hồ Anh Phong. RFC 3550 – RTP: A Transport Protocol for Real-time Applications Kevin Jeffay, Department of Computer Science, University of North Carolina at Chapel Hill (1999) – The Multimedia Transport Protocol RTP. Kevin Jeffay (1999), Department of Computer Science, University of North Carolina at Chapel Hill – The Multimedia Control Protocol RTCP. Nguyễn Thỳc Hải (1999) - Mạng mỏy tớnh và cỏc hệ thống mở. Cisco press - Internetworking Technologles Handbook. Henning Schulzrinne (2003), Dept. of Computer Science, Columbia University – Multicast. David Meyer, Cisco System – Introduction to IP Multicast. Kết luận Hiện nay tại Việt Nam, tuy các ứng dụng RTP chưa phát triển, nhưng trong một thời gian ngắn nữa chắc chắn nó sẽ là một lĩnh vực nghiên cứu sôi động. Nếu có một nghiên cứu hoàn chỉnh, đầy đủ về RTP là một điều rất có ý nghĩa thực tế. Tuy nhiên do thời gian có hạn, những gì em làm được ở đây mới chỉ là nghiên cứu phần kiến thức cơ bản về RTP. Chương trình quản lý website VoD là sự thực hành giúp chúng em hiểu rõ hơn nắm chắc hơn những khái niệm và những thuật toán trong giao thức RTP. Tuy ứng dụng hoạt động còn nhiều hạn chế, nhưng dẫu sao nó cũng khẳng định rằng sự đầu tư tìm hiểu của chúng em là có hiệu quả. 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. Một lần nữa, em xin chân thành cảm ơn thầy Nguyễn Tài Hưng đã tận tình hướng dẫn, khích lệ và tạo mọi điều kiện thuận lợi giúp đỡ em trong quá trình hoàn thành đồ án này! Em xin chân thành cảm ơn các thầy cô đã tận tình dìu dắt em trong những năm học vừa qua! ._.