Đồ án Nghiên cứu và ứng dụng giao thức RTP

uá trình mã hoá tín hiệu video. Nhãn thời gian sẽ được gắn giống nhau cho mọi gói tin chứa cùng 1 khung hình, tuy nhiên các gói dữ liệu này lại không được truyền đi đồng thời mà được gởi đi lần lượt, điều này sẽ làm giảm độ chính xác của việc tính toán jitter với mục đích phân tích hoạt động của mạng. Nhưng nó sẽ hợp lý nếu ta giả thiết rằng quá trình xảy ra hoàn toàn tương tự tại bộ đệm của người nhận. Khi đó hằng số thời gian trễ do việc chờ đến lượt truyền sẽ bị loại trừ. Vì vậy chúng ta có thể kiểm soát được jitter xảy ra trong quá trình lan truyền trên mạng. 4.7 Gói tin mô tả các thông tin của nguồn: (SDES: Source Description RTCP Packet) Cấu trúc bản tin 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 Header V=2 P RC PT=SDES=202 length SSRC of packet sender Chunk1 SSRC/CSRC_1 SDES items .......... Chunk2 SSRC/CSRC_2 SDES items .......... Hình 4.6: Cấu trúc gói tin SDES-RTCP Gói SDES bao gồm phần tiêu đề, kèm theo là các đoạn chứa các thông tin về các nguồn SSRC/CSRC _i (ở đây ta gọi tắt là các đoạn SSRC/CSRC). Trong một gói SDES có thể có không hoặc nhiều đoạn thông tin này. Các thông tin trong từng đoạn riêng lẻ là hoàn toàn độc lập. version (V), padding (P), length: hoàn toàn tương tự như trong các gói RTCP khác. packet type (PT): 8 bits. Có giá trị bằng 202, dùng xác định đây là một gói SDES RTCP. source count (SC): 5 bits. Xác định số các đoạn SSRC/CSRC được chứa trong gói SDES này. Trường này có thể nhận giá trị nhỏ nhất bằng 0 khi không có thông tin về một nguồn nào được mô tả, tuy nhiên điều này thường không xảy ra. Mỗi đoạn SSRC/CSRC bao gồm 1 phần định danh nguồn SSRC/CSRC, tiếp theo là một loạt các thông tin về nguồn SSRC/CSRC đó. Mỗi đoạn sẽ bắt đầu bằng 1phần 32-bit. Mỗi phần thông tin (SDES item) sẽ có trường định kiểu 8-bit, 8-bit dùng xác định chiều dài của phần thông tin (không chứa 2-byte đầu tiên này). Tiếp theo là phần thông tin cụ thể (text). Chú ý rằng phần text không thể vượt quá 255-byte, nhưng điều này hoàn toàn phù hợp với giới hạn của băng thông RTCP. Phần text được mã hoá theo tiêu chuẩn mã hoá UTF-8 được đưa ra trong bản RFC-2279. Chuẩn này hoàn toàn đáp ứng được cá yêu cầu của chuẩn ASCII của Mỹ. 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… Type field length text Hình 4.7: Cấu trúc SDES item. Mỗi hệ thống đầu cuối sẽ phát đi gói SDES mang thông tin định danh nguồn của mình (tương tự như giá trị SSRC trong phần tiêu đề của gói RTP). Sau đó bộ trộn (mixer) sẽ gộp các thông tin này lại từ các nguồn phân tán, phân chúng thành từng đoạn trong một gói SDES chung và gởi đi. Nếu có nhiều hơn 31 nguồn thì các thông tin sẽ được chứa trong nhiều gói SDES chung. Chung ta sẽ nói cụ thể hơn trong phần Mixer. Bây giờ ta sẽ định nghĩa từng loại thông tin mang trong gói SDES. Trong đó chỉ có CNAME là bắt buộc. 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ể. Các loại được thông tin nêu ra ở đây đều phổ biến, đã được đăng ký với IANA [] 15. CNAME: Canonical End-Point Identifier: Đây là một trường thông tin bắt buộc trong gói SDES, dùng để nhận dạng một đầu cuối. 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… CNAME=1 length user and domain name Hình 4.8: Cấu trúc CNAME-SDES . CNAME có các thuộc tính sau: Một định danh SSRC được phân phối một cách ngẫu nhiên và có thể thay đổi trong một phiên RTP, khi phát hiện sự xung đột, hoặc khi chương trình khởi tạo lại. Do vậy, CNAME được sử dụng để liên kết một định danh SSRC với một định danh không đổi dành cho một nguồn xác định. Cũng giống như SSRC, giá trị của CNAME của mỗi thành viên phải là duy nhất trong một phiên RTP. Giá trị của CNAME được dùng cố định cho một thành viên nào đó. Đ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. Ví dụ, khi mà một thành viên gởi đồng thời tín hiệu video và tín hiệu audio với qua 2 cặp cổng UDP khác nhau. Để thuận tiện cho nhà quản trị mạng trong việc định vị nguồn, CNAME nên tương ứng với với sự xác định một cá nhân nào đó Vì vậy, CNAME sẽ được nhận theo một thuật toán nào đó, không được nhập vào một cách tuỳ ý bởi người dùng. Để thoả mãn các yêu cầu trên, ta sẽ đưa ra một định dạng của CNAME. Tuy nhiên định dạng này không hề có tính bắt buộc, nó có thể được định nghĩa khác, tuỳ vào từng trường hợp cụ thể. CNAME xác định dựa trên "user@host" (Ví dụ: doe@sleepy.example.com , hoặc “host” trong trường hợp “user name” không được xác định trên hệ thống đơn người dùng. Việc xác định “host“ là hoàn toàn đơn trị. Tuy nhiên trong trường hợp, một “host” có thể đồng thời tạo ra nhiều nguồn, cú pháp này không giúp ta phân biệt được từng nguồn cụ thể trong số đó. Việc này sẽ được giải quyết ở lớp ứng dụng, ta sẽ không đề cập đến ở đây. NAME: User Name Cấu trúc khung: 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… NAME=2 length common name of source Hình 4.9: Cấu trúc NAME-SDES . Phần này chứa là tên thật, được dùng để mô tả nguồn, ví dụ: “Nguyễn Văn A”. Nó có thể được đặt tuỳ ý do người dùng. Trong một ứng dụng cụ thể, ví dụ như hội thảo trên mạng, tên này sẽ là nick mà 1người dùng để hiển thị trên danh sách thành viên. Chính vì vậy mà nó có thể được gởi đi thường xuyên (đứng thứ 2 sau CNAME). Chú ý: Giá trị của NAME sẽ được duy trì không đổi trong ít nhất một chu kỳ. Nó sẽ không bắt buộc là duy nhất trong một các thành viên tham gia. EMAIL: Electronic Mail Address Cấu trúc dữ liệu: 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… EMAIL=3 length email address of source Hình 4.10: Cấu trúc EMAIL-SDES . Địa chỉ Email được định dạng theo chuẩn RFC 2822. Ví dụ: "John.Doe@example.com". PHONE: Phone Number SDES Item 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… PHONE=4 length phone number of source Hình 4.11: Cấu trúc PHONE-SDES . Số điện thoại được định dạng với dấu “+” thay cho mã truy nhập quốc tế. Ví dụ: "+1 908 555 1212" được dùng cho một số của nước Mỹ. LOC: Geographic User Location SDES Item 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… LOC=5 length geographic location of site Hình 4.12: Cấu trúc LOC-SDES. Giá trị này có mức độ chi tiết khác nhau phụ thuộc vào từng ứng dụng. Định dạng của nó phụ thuộc vào sự cài đặt cụ thể. TOOL: Application or Tool Name SDES Item 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… TOOL=6 length name/version of source application Hình 4.13: Cấu trúc TOOL-SDES. Chuỗi ký tự có thể cho biết tên và đôi khi cho biết cả verion của ứng dụng được dùng để tạo ra luồng dữ liệu RTP. Ví dụ: "videotool 1.2" Thông tin này đôi khi sẽ rất hữu ích cho mục đích “gỡ rối” (debugging). NOTE: Notice/Status SDES Item 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… NOTE=7 length note about the source Hình 4.14: Cấu trúc NOTE-SDES. Trường chú thích này được dùng với mục đích gởi các bản tin ngắn, mô tả trạng thái hiện tại của một nguồn. Ví dụ: “busy”. Trong một cuộc thảo luận chuyên đề, trường này có thể dùng để truyền tải tiêu đề của cuộc thảo luận. Trường này nên được sử dụng để mang những thông tin đặc biệt, không nên được phát thường xuyên bởi tất cả các thành viên. Bởi vì điều đó làm giảm tốc độ nhận các bản tin hồi đáp và các gói chứa CNAME. Nếu NOTE trở lên quan trọng, cần được hiển thị liên tục, khi đó ta có thể giảm tốc độ của các phần thông tin khác (không được giảm tốc độ của CNAME). Do vậy NOTE có thể sử dụng một phần cố định của băng thông RTCP. Khi muốn ngừng kích hoạt, NOTE chứa chuỗi rỗng sẽ được gởi đi vài lần để báo hiệu cho phía nhận. Tuy nhiên, nếu không nhận được thông tin NOTE trong một thời gian nào đó, bên nhận cũng sẽ tự mặc định rằng nó đã được ngừng kích hoạt (thời gian này khoảng 20-30 lần chu kỳ gởi RTCP). PRIV: Private Extensions SDES Item 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… PRIV=8 length prefix length prefix string... value string ... Hình 4.15: Cấu trúc PRIV-SDES. Phần này được dùng cho các SDES mở rộng. Nó chứa thông tin về chiều dài của 2 chuỗi trong 2 trường kích thước: length, prefix length, mỗi trường có độ dài 8-bit. Trường “prefix string” định nghĩa loại của PRI, dùng chỉ dẫn cho phía nhận.Trường “value string” sẽ chứa những phần thông tin mở rộng khác (extended items). Chú ý: Do trường prefix có độ dài 8-bit, nên tổng cộng chiều dài của phần thông tin thêm (“prefix string” +“value string”) phải nhỏ hơn 256 octets. Tuy điều này có thể không làm hài lòng một số ứng dụng, tuy nhiên với kích thước như vậy là đúng mức để băng thông dành cho RTCP không bị quá tải. Phần tiền tố của PRIV – SDES không cần phải khai báo định dạng với IANA. Khi một định dạng nào của PRIV được phổ dụng thì nó sẽ được đưa lên phần dùng chung (như NAME, LOC……). Lúc đó nó sẽ cần đăng ký với IANA. Cơ chế đơn giản hoá này giúp ta tăng hiệu quả truyền tải. 4.8. Gói BYE: Gói RTCP này chỉ ra 1 hay nhiều nguồn SSRC sẽ rời khỏi trạng thái kích hoạt. Bây giờ chúng ta sẽ tìm hiểu cấu trúc của gói BYE. 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 V=2 P RC PT=BYE=203 Length SSRC/CSRC . . . . . . . opt length reason for leaving Hình 4.16: Cấu trúc gói RTCP BYTE. Các trường version (V), padding (P), length: hoàn toàn giống như các trường tương ứng trong gói SR. packet type (PT): 8 bits Trường này có giá trị bằng 203, để chỉ định đây là gói BYE. source count (SC): 5 bits Dùng thông báo, số định danh SSRC/CSRC được chứa trong gói BYE. Trường hợp nhỏ nhất SC có thể bằng 0, tuy nhiên đây là trường hợp không xảy ra. Việc gởi gói BYE được thực hiện như đã trình bầy ở phần trước. Khi mộ gói BYE được nhận bởi bộ trộn (mixer), bộ trộn sẽ chuyển tiếp gói BYE đến trực tiếp, không làm thay đổi trường SSRC/CSRC có sẵn. Khi một bộ trộn muốn tắt, nó sẽ gởi đi một gói BYE trong đó liệt kê toàn bộ các nguồn mà nó quản lý, cùng địa chỉ SSRC của chính nó. Ngoài ra, gói BYE còn có 1 trường 8-bit, theo sau phần danh sách SSRC. Trường này chứa số octets được chứa trong phần chú thích. Phần chú thích chứa một chuỗi ký tự dạng text được mã hoá theo chuẩn UTF-8 []. Nó dùng để giải thích lý do rời bỏ của nguồn, như: “camera malfunction”, “RTP loop detected”…. Nếu chuỗi này điển đầy hàng 32-bit tiếp theo, nó không cần kết thúc với xâu rỗng. Nếu không, gói BYE sẽ phải thêm các byte rỗng cho đủ số nguyên lần 32-bit. Việc thêm này sẽ được báo hiệu bởi bit P trong phần tiêu đề RTCP. 4.9. Gói APP: Application-Defined RTCP Packet Cấu trúc gói RTCP-APP: 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 V=2 P subtype PT=APP=204 Length SSRC/CSRC name (ASCII) application-dependent data Hình 4.17: Cấu trúc gói RTCP-APP.. Gói APP được dùng cho những ứng dụng mới, đang thử nghiệm hoặc những chức năng mới đang được phát triển. Bởi nó hỗ trợ phần định kiểu tự do, không cần đăng ký giá trị với IANA. Một gói APP khi không xác định được tên sẽ được mặc định bỏ qua. Nếu sau thời gian thử nghiệm, loại gói này được dùng rộng rãi, nó sẽ được đăng ký với IANA, loại bỏ 2 trường “subtype” và “name”, trở thành một gói RTCP loại mới. Các trường version (V), padding (P), length: giống như các trường tương ứng trong gói SR. subtype: 5 bits 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. packet type (PT): 8 bits Trường này mang giá trị 204, để chỉ định đây là gói APP-RTCP. name: 4 octets Tên này được dùng để phân chia các tập gói APP thành từng nhóm khác nhau để ứng dụng có thể nhận biết được. Tên này có thể lấy giá trị tuỳ ý do người lập trình đặt ra, tuy nhiên theo khuyến nghị, nó nên đặt dựa trên thực thể mà nó miêu tả. Tên này sẽ được biểu diễn dưới 4 ký tự mã ASCII, có phân biệt chữ hoa, chữ thường. Application-dependent data: trường này có độ dài biến đổi, có giá trị là số nguyên lần 32-bit. Đây là 1 trường không bắt buộc trong gói APP. Nó được mô tả phụ thuộc từng ứng dụng. Chương V: các bộ RTP Translators và RTP Mixers Trong các thiết bị đầu cuối RTP, chúng ta có khái niệm "translators" và "mixers". Đây là một trong những thành phần rất quan trọng trong hệ thống RTP. Chúng được coi như là các hệ thống trung gian ở hoạt động ở lớp tương đương với RTP. Mặc dù sự có mặt của 2 thiết bị này làm cho hệ thống trở lên phức tạp hơn nhiều, nhưng đây là các chức năng thật sự cần thiết cho hệ thống RTP. Nó đóng vai trò rất quan trọng trong các hệ thống truyền multicast, trong các hệ thống có một phần được bảo vệ bởi fire wall, trong hệ thống có một phần băng thông hạn hẹp. Các bộ "translators" và "mixers" sẽ giúp cho các hệ thống này giữ nguyên khi áp dụng giao thức RTP. 5.1. Khái niệm chung: Một bộ translator/mixer được nối với một hay nhiều “clouds” ở tầng giao vận. Thông thường, mỗi “cloud” được định nghĩa bởi một mạng chung và một giao thức giao vận (ví dụ IP/UDP) cộng với địa chỉ multicast và một cổng đích ở tầng giao vận, hoặc một cặp các địa chỉ unicast và các cổng tương ứng. Một hệ thống có thể được dùng như một bộ “translator” hoặc “mixer” cho một tập các phiên RTP, tuy nhiên chúng nên được phân thành từng thực thể riêng. Để tránh việc xảy ra các vòng lặp khi ta cài đặt các bộ “mixer” hoặc “translator”, các qui tắc sau cần được đảm bảo: Các “cloud” được nối với nhau qua các bộ “mixer” và “translator”, để tham dự vào một phiên RTP, phải khác nhau ít nhất một trong những tham số sau: Protocol, address, port, hoặc phải hoàn toàn tách biệt với nhau ở lớp mạng. Xuất phát từ yêu cầu của điều một, để tránh sự lặp vòng thì không được sử dụng nhiều bộ “translator” hoặc “mixer” mắc song song, trừ khi các ngồn được chuyển tiếp tại đầu ra được phân thành từng nhóm. Tương tự, mọi hệ thống cuối RTP đều có thể trao đổi thông tin với một hoặc nhiều bộ “translator” hoặc “mixer” chia sẽ cùng một miền SSRC, do vậy các định danh SSRC của mọi đầu cuối phải là đơn nhất trên toàn hệ thống. Phần sau ta sẽ đề cập cụ thể hơn về cơ chế đảm bảo điều này. Thực tế có rất nhiều loại “translator” và “mixer” được thiết kế cho những mục đích, những ứng dụng khác nhau. Ví dụ như để thêm hay loại bỏ mã bảo mật, thay đổi mã hoá dữ liệu, Chuyền đổi giữa địa chỉ Mutilcast và nhóm các địa chỉ Unicast. Sự khác nhau cơ bản giữa “translator” và “mixer” là “translator” thì chuyển tiếp các luồng dữ liệu từ các nguồn khác nhau một cách riêng rẽ, còn “mixer” thì kết hợp chúng lại trong một luống mới. Translator: Chuyển tiếp các gói RTP mà không thay đổi định danh SSRC của chúng. Điều này giúp cho phía nhận có thể xác định được từng nguồn gởi riêng biệt, cho dù chúng được chuyển qua cùng một “translator”. 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 ngắn kèm của gói RTP. Nếu nhiều loại dữ liệu (hình ảnh và âm thanh) được ghép lại hoặc trường hợp ngược lại, thì bộ “translator” sẽ phải tạo một số thứ tự mới cho các gói đầu ra. 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. Phía nhận sẽ hoàn toàn không hề phát hiện ra được sự có mặt của “translator” trừ khi sử dụng một số phương tiện đặc biệt, bởi vì kiểu định dạng tải, địa chỉ giao vận của các gói tin không hề bị thay đổi gì so với nguồn gốc. Mixer: Thiết bị này sẽ nhận luồng các gói dữ liệu RTP từ một hoặc nhiều nguồn, có thể thay đổi định dạng tải, kết hợp chúng theo một cách nào đó, sau đó truyền chúng đi trong một luồng kết hợp. Do nhãn thời gian gắn trên các nguồn tới khác nhau là không đồng bộ, “Mixer” sẽ điều chỉnh lại nhãn thời gian của các nguồn và tạo ra một nhãn thời gian riêng cho luồng ra kết hợp. Vì vậy một “Mixer” có vai trò như mọt nguồn đồng bộ SC. Tất cả các gói dữ liệu được chuyển tiếp bởi bộ “Mixer” đều được đánh dấu với định danh SSRC của bộ “Mixer”. Để 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. Nếu không chèn thêm danh sách này thì cũng được trong một số ứng dụng cụ thể. Tuy nhiên việc này là hoàn toàn không nên bởi việc không phát hiện được nguồn gởi gốc có thể gây ra việc các gói tin giống nhau không được phân biệt. Một bộ “Mixer” cũng có vai trò của một nguồn đồng bộ nên trong một số gói tin ta cũng nên chèn thêm giá trị SSRC của “Mixer” vào danh sách CSRC. Trong một số trường hợp bộ “Mixer” có ưu thế hơn hẳn so với bộ “translator”. Ví dụ, trong những ứng dụng audio, dải thông đầu ra bị giới hạn chỉ phục vụ cho một nguồn, mà trong khi đó lại có rất nhiều nguồn đầu vào. Hay trong trường hợp đầu ra có băng thông hẹp, không thể tải hết các thông tin tại đầu vào. Tuy nhiên “Mixer” cũng có một số hạn chế. Đó là việc bên nhận ở phía sau bộ “Mixer” sẽ không thể điều khiển các nguồn phát phía trước “Mixer”, trừ khi bộ “Mixer” được cài đặt thêm một số cơ chế điều khiển từ xa. Việc tái tạo lại các thông tin đồng bộ của bộ “Mixer” làm cho bên nhận không thể thực hiện đồng bộ nội giữa các thành phần tín hiệu (âm thanh/hình ảnh) của cùng một nguồn phát. Việc này phải đo các bộ “multi-media Mixer” thực hiện. Hình 5.1 : Mô hình mạng với các bộ traslator và mixer Hình này minh hoạ tác động của “mixer” và “translator” tới giá trị của SSRC và CSRC. Chú ý rằng ký hiệu "M1: 48(1,17)" dùng để chỉ, gói tin được phát từ “mixer” M1có giá trị SSRC là 48 (đây là giá trị ngẫu nhiên), kèm theo 2 định danh trong danh sách SCRC là 1, 17 (2 giá trị này được lấy từ phần định danh SSRC của 2 gói tin từ E1, E2. 5.2. Hoạt động của bộ 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 co xử lý đối với các gói RTCP. Trong nhiều trường hợp, chúng tách các gói ghép RTCP được nhận từ các hệ thống đầu cuối, tập hợp các thông tin SDES và sửa đổi các gói SR và RR. Sự truyền lại các thông tin này có thể gây ra “trigger” do khoảng thời điểm đến của các gói tin hoặc do bản thân bộ “mixer” và “translator” gây ra. Hình 5.2: Hoạt động của Translator. Nếu bộ “translator” chỉ thực hiện chuyển đổi giữa địa chỉ multicast và địa chỉ Unicast, không sửa đổi gì các gói dữ liệu thì đối với các gói RTCP nó cũng không phải sửa đổi. Khi một bộ “translator” thay đổi dạng của phần tải RTP theo một cách nào đó thì nó cũng phải thay đổi các thông tin trong gói SR và RR một cách tương ứng. Để có thể đảm bảo các gói này vẫn phản ánh được các thuộc tính của gói RTP được gởi đi (đối với gói SR), chất lượng nhận các gói RTP (đối với gói RR). Các gói RTCP không chỉ được chuyển tiếp một cách đơn thuần. Chú ý: thường thì “translator” không kết hợp các gói SR và RR từ các nguồn khác vào một gói chung, bởi vì như vậy sẽ làm giảm độ chính xác của việc đo thời gian trễ lan truyền dựa trên các trường LSR và DLSR. Bây giờ ta sẽ tìm hiểu cụ thể tác động của “translator” tới các loại gói tin RTCP: SR (thông tin người gởi): Một bộ “translator” sẽ không tạo ra gói SR của riêng mình, nó chỉ nhận SR từ một “cloud” rồi chuyển tiếp đến các “cloud” khác. Trong đó trường SSRC được giữ nguyên, nhưng các trường mô tả thông tin người gởi có thể bị thay đổi nếu cầ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!