Tham s này có ốvai trò nh tham s NS trong HDLC.. Ngoài ra, giao thậ ức UDP còn có th s d ng cho truy n multicast.. ộ- Theo dõi quá trình truy n t i: delivery monitoring.. ố đị ọCòn danh
M t s khái ni m liên quan ộ ố ệ đế n RTP
Payload RTP là phần dữ liệu được truyền trong các gói RTP, có thể chứa thông tin về các mã hóa video đã được nén Việc phân nhánh dữ liệu này (được xác định bởi phần payload type) giúp nhận diện và xử lý các thông tin cần thiết trong quá trình truyền tải.
Gói RTP (Real-time Transport Protocol) bao gồm các thành phần chính như tiêu đề RTP, danh sách các nguồn phân tán và phần tải trọng RTP Một số giao thức truyền tải có thể yêu cầu gói lại các gói RTP để đảm bảo tính hiệu quả trong việc truyền dữ liệu Thông thường, một gói RTP sẽ chứa một gói dữ liệu, nhưng cũng có thể xảy ra trường hợp nhiều gói RTP được gộp lại trong một gói duy nhất, tùy thuộc vào cách thức đóng gói của ứng dụng.
Gói RTCP là một phần quan trọng trong giao thức RTCP, có chức năng cung cấp thông tin về trạng thái và chất lượng của các gói RTP Cấu trúc của gói RTCP phụ thuộc vào loại gói và thường được truyền cùng với các gói RTP trong một phiên truyền Điều này cho phép RTCP cung cấp thông tin điều khiển hiệu quả và đảm bảo rằng các gói RTP được gửi đi một cách chính xác và đồng bộ.
Cổng (Port) là một khái niệm quan trọng trong giao thức UDP, được sử dụng để phân biệt các phiên truyền dữ liệu Trong giao thức TCP/IP, cổng là một số nguyên dương 16 bit Khái niệm cổng tương đương với TSEL (transport selectors) trong mô hình OSI RTP hoạt động dựa trên các cổng để phân phối dữ liệu, được cung cấp bởi giao thức RTP và RTCP, nhằm đảm bảo việc truyền tải các gói dữ liệu và thông tin điều khiển trong mỗi phiên truyền.
Địa chỉ vận chuyển là một thành phần quan trọng trong việc truyền dữ liệu, giúp xác định điểm đến cho các gói tin Nó là sự kết hợp giữa địa chỉ IP và cổng UDP, cho phép các gói tin được gửi đến đúng địa chỉ Các gói tin sẽ được truyền tải qua mạng một cách hiệu quả, đảm bảo thông tin được chuyển giao chính xác và nhanh chóng.
RTP media type là một loại giao thức truyền tải dữ liệu có các đặc điểm giống nhau được mang trong phiên truyền RTP Trong hệ thống truyền thông, có hai loại RTP media type chính là video-MPEG2 và audio-PCMA Các loại RTP này sẽ được trình bày chi tiết trong phần 3 của bài viết.
Phiên RTP là quá trình mà các thành viên tham gia có thể trao đổi thông tin một cách hiệu quả Mỗi thành viên được xác định dựa trên địa chỉ nguồn, có thể sử dụng giao thức truyền gói RTP hoặc RCTP Các phương thức truyền tải có thể là chung cho tất cả các thành viên trong trường hợp truyền multicast hoặc riêng biệt cho từng thành viên trong trường hợp truyền unicast Để đảm bảo phiên truyền multimedia diễn ra suôn sẻ, các tín hiệu thành phần như video và audio sẽ được truyền theo một kênh riêng biệt.
Hình 2.1: Mô hình phiên RTP
Nguồn đồng bộ (SSRC) là một mã định danh 32-bit trong phần header của gói RTP, cho phép xác định nguồn phát của các gói dữ liệu SSRC đảm bảo rằng các gói dữ liệu được phát từ một nguồn duy nhất và đồng bộ hóa thời gian, giúp duy trì tính toàn vẹn của thông tin Mã SSRC là duy nhất trên toàn mạng và được chọn ngẫu nhiên để tránh xung đột giữa các nguồn khác nhau.
Hình 2.2: Minh ho các ngu n ạ ồ đồng b SSRC ộ
Mixer (b tr n) là một hệ thống trung gian, có khả năng nhận các gói RTP từ một hoặc nhiều nguồn khác nhau Do đó, dữ liệu thu được có thể khác nhau Mixer sẽ kết hợp các gói có cùng định dạng rồi chuyển tiếp trong một gói RTP mới Khi đó, thời gian được gán theo các gói tin sẽ được đồ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ộ.
Khi dòng các gói RTP được tích hợp vào Mixer, nó sẽ chèn một danh sách CSRC chứa các mã danh SSRC của các nguồn khác nhau Việc này giúp cho bên nhận có thể dễ dàng phân tách và xác định SSRC tương ứng với từng nguồn gửi.
Hình 2.4: Minh ho vi c chèn danh sách CSRC khi i qua b Mixer ạ ệ đ ộ
Hệ thống cuối (End system) là thành phần tạo ra dữ liệu được lưu trữ để truyền tải trong các gói RTP Dữ liệu này được sử dụng để xử lý và nhận diện trong hệ thống cuối của RTP.
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 ị ủ
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 sử dụng giao thức NTP (Network Time Protocol) để tính toán thời gian từ 0h UTC ngày 1-1-1900, biểu diễn bằng 64 Bits Trong đó, 32 Bits đầu tiên đại diện cho phần nguyên và 32 Bits còn lại cho phần thập phân Tuy nhiên, trong một số trường hợp, người ta chỉ sử dụng 32 Bits giữa, với 16 Bits cao của phần nguyên và 16 Bits cao của phần thập phân Với cách tính thời gian theo NTP, giá trị sẽ quay trở lại 0 vào năm 2036 Đối với các ứng dụng thời gian thực, cần xem xét độ chênh lệch thời gian do chu kỳ này gây ra là hoàn toàn thỏa mãn.
C u trúc ph n tiêu ấ ầ đề gói RTP
C u trúc khung ph n tiêu ấ ầ đề gói RTP nh b ng: ư ả
B ng 2.1: 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, có chứa thông tin quan trọng cho mỗi gói RTP Danh sách CSRC sẽ được đưa vào khi chúng ta xử lý qua Mixer Bây giờ, chúng ta sẽ tiến hành phân tích chi tiết hơn.
_ing n ng c th c a _ing tră ụ ể ủ ường: a version (V): 2 bits
Trường này xác định phiên bản của RTP Hiện nay, trong truyền video và truyền âm thanh, RTP đang sử dụng phiên bản 2 Phiên bản 1 là phiên bản được sử dụng đầu tiên, trong khi phiên bản 0 chỉ là giao thức dùng để cài đặt thêm các thông tin cần thiết cho âm thanh Padding (P) là 1 bit.
Đệm này được đặc tả giá trị 1, báo rằng gói tin chứa một số byte điều kiện Byte cuối cùng trong các byte đệm sẽ chứa thông tin về các byte đệm đã được thêm vào, không phải byte chính Các byte đệm này có thể được sử dụng để mã hóa một gói tin, hoặc trong trường hợp đặc biệt, để gói nhiều gói RTP trong một gói duy nhất Phần mở rộng (X) được biểu thị bằng 1 bit.
Khi bit này được gán giá trị 1, nó sẽ xác định phần tiêu đề mở rộng Việc mở rộng thêm phần tiêu đề giúp cung cấp thêm thông tin cho gói RTP khi cần thiết CSRC count (CC) có độ dài 4 bits.
Phần này chứa số lượng các bệnh nhân dùng CSRC sẽ được thêm vào sau phần tiêu đề địa chỉ Dùng để xác định các phần tử 32 bit địa chỉ được chứa trong phần CSRC Marker (M): 1 bit.
Bit này được sử dụng để báo hiệu thông tin Nó có thể được thay đổi để làm cho tín hiệu báo hiệu khung trong trường hợp truyền các gói tin thành dòng Bit này có thể được sử dụng hoặc không, và nếu không sử dụng, ta có thể thay thế bằng cách điều chỉnh số lượng bit trong trường payload type Payload type (PT) chiếm 7 bits.
Trường này đang xác định các đặc điểm của phần tài địa ủ ầ ả để chọn lọc các ngữ dạng phù hợp Giá trị của phần nh d ng tại đây có thể ảnh hưởng trong một phiên RTP nếu ta thực hiện đúng các phương pháp mã hóa tính toán Nó sẽ có giá trị biến đổi nếu như trong phiên RTP đó ta sử dụng các chỉ dẫn đúng đắn cho địa chỉ động.
Mạng RTP có thể thay đổi địa chỉ trong một phiên truyền, tuy nhiên không nên sử dụng một phiên RTP để truyền đồng thời các luồng media có địa chỉ 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 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 ụ ụ h Sequence number: 16 bits
Số lượng các gói RTP được phát hiện sẽ ảnh hưởng đến việc ánh sáng được phân phối Nhận diện số lượng này sẽ giúp khôi phục lại trạng thái của các gói hoặc phát hiện nhữ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 đảm bảo tính bảo mật, bởi nó có thể ảnh hưởng đến việc kết hợp với khóa 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 chuẩn hóa, có độ chính xác cao, nhằm đảm bảo việc kiểm tra và xác định độ Jitter giữa các gói tin khi đến đích Điều này rất quan trọng, bởi nếu chúng ta truyền tín hiệu video, Jitter có thể gây ra hiện tượng giật hình ảnh.
Thời gian nhãn phụ thuộc vào tần số mẫu, với tần số 8 KHz, các gói tin sẽ được truyền theo tần số mỗi 20ms, tương ứng với 160 mẫu Do đó, mỗi nhãn thời gian liên tiếp cách nhau 160 mẫu, không cần quan tâm đến việc gói dữ liệu 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 ẫ k SSRC: 32 bits
Trường này được thiết lập nhằm cung cấp một môi trường học tập đa dạng và phong phú Giá trị của trường được xác định một cách ngẫu nhiên, với sự kiểm tra kỹ lưỡng để đảm bảo độ tin cậy Điều này nhằm tránh tình trạng trong một phiên RTP có nhiều nguồn tài nguyên đồng bậc sử dụng cùng một giá trị SSRC.
Here is a rewritten paragraph that contains the meaning of the original text, complying with SEO rules:"Mặc dù xác suất xảy ra nhiều nguy cơ phát sinh cùng một tên danh là rất cao, nhưng chúng ta vẫn phải cài đặt xác nhận và giải quyết xung đột này một cách đột phá để đảm bảo an toàn và hiệu quả."Let me know if you need any further assistance!
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 l 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 chứa từ 0 đến 15 phần tử, mỗi phần tử chiếm 32 bit Nó được sử dụng để xác định nguồn tin tạo ra nội dung trong phần tử Do danh sách chỉ chứa địa chỉ ồ ạ ộ ầ ả ỉ ứ, nên khi có nhiều hơn 16 nguồn tin, một số nguồn sẽ bị bỏ qua hoặc sử dụng cách gán vòng.
Ghép các phiên truy n RTP…………………………………………….30 ề 2.1.4 S thay ự đổ i ph n tiêu ầ đề trong m t s tr ộ ố ườ ng h p………………… 31 ợ 2.2: GIAO TH C I U KHI N RTCP……………………………………33 Ứ Đ ỀỂ 2.2.1 Ch c n ng và ho t ứ ă ạ độ ng c a RTCP…………………………………….33 ủ 2.2.2 Các lo i gói tin RTCP…………………………………………………….35 ạ 2.2.3 Kho ng th i gian truy n các gói RTCP……………………………… 37 ảờề 2.2.4 C p nh t s thành viên tham gia phiên truy n……………………….40 ậậ ốề 2.2.5 Qui nh đị đố ớ i v i vi c g i và nh n các gói RTCP…………………… 41 ệởậ 2.2.6 Các b n tin thông báo c a ngảủ ườ ở i g i và ng ườ i nh n……………… 47 ậ 2.2.7 Gói tin mô t các thông tin c a ngu n………………………………….57 ảủồ 2.2.8 Gói BYE
Trong giao thức RTP, việc ghép kênh dữ liệu đượ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à danh tính của các bên 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ẽ sử dụng đồng thời hai thành phần âm thanh và hình ảnh Khi đó, mỗi thành phần sẽ được mã hóa theo những định dạng khác nhau, được mang trên những phiên RTP với độ trễ thấp qua một giao thức riêng Quá trình phân kênh sẽ được thực hiện dựa trên địa chỉ SSRC Khi truyền các gói dữ liệu khác loại mà sử dụng cùng một địa chỉ SSRC, cần phải đảm bảo rằng các thành phần âm thanh và hình ảnh được xử lý đúng cách.
Here is a rewritten paragraph that contains the important sentences and complies with SEO rules:"Khi sử dụng hai luồng thoại cùng một phiên truy vấn, vấn đề phát sinh là giá trị SSRC giống nhau Một luồng được coi là thay đổi cách mã hóa dựa trên trường payload type Tuy nhiên, vấn đề này không thể xác định luồng nào là gốc và luồng nào có thay đổi cách mã hóa."
Here is the rewritten paragraph:"Một nguồn SSRC cung cấp một dãy nhãn thời gian và một chuỗi số thứ tự Trong khi việc truyền đi các loại tin khác nhau yêu cầu độ nhạy khác nhau, để xác nhận sự thứ tự của các gói tin định tuyến trong khi truyền đi, cần phải có một chuỗi số thứ tự riêng biệt."
Các thông báo RTCP từ phía nhận và phía gửi chứa thông tin về một dãy thời gian và một dãy số thứ tự, nhưng không có thông tin về vị trí hoặc đường phân loại.
Các b Mixer không thể xử lý một lượng lớn đầu vào bao gồm các thành phần khác nhau đồng thời Để khắc phục vấn đề này, chúng ta có thể chọn giải pháp sử dụng các bộ chuyển đổi SSRC để điều chỉnh các địa chỉ khác nhau cho mỗi luồng tín hiệu và truyền chung trong một phiên RTP Tuy nhiên, khi thực hiện, cần lưu ý rằng việc điều chỉnh này phải phù hợp với các yêu cầu kỹ thuật và tiêu chuẩn truyền tải.
Việc truyền dữ liệu đồng thời nhiều loại dữ liệu sử dụng chung một phiên RTP có thể gặp một số vấn đề Không thể thực hiện việc tìm kiếm đường truyền khác nhau đối với từng loại dữ liệu cho phù hợp với tài nguyên của mạng Không thể cho phép người dùng là chọn việc nhận dữ liệu (tiếng nói hình ảnh) Điều này khá cần thiết, khi một thành viên tham gia gặp vấn đề trong việc sử dụng đường truyền có độ trễ thấp, cần chọn giải pháp chất lượng cao để đảm bảo tín hiệu âm thanh.
2.1.4 S THAY Ự ĐỔI PH N TIÊU Ầ ĐỀ TRONG M T S TRỘ Ố ƯỜNG H P Ợ
Để đảm bảo các yêu cầu cơ bản trong các ngữ dụng RTP, chúng ta cần chú trọng đến việc đáp ứng những tiêu chí đã đề ra Tuy nhiên, với những yêu cầu nâng cao, cần bổ sung thêm một số trường trong phần tiêu đề để tối ưu hóa hiệu quả sử dụng.
Các trường M và PT chứa thông tin đặc trưng cho việc điều hướng dữ liệu Những trường này được xác định trong phần tiêu đề của định dạng, trong khi đó, chúng có thể được sử dụng cho nhiều ứng dụng khác nhau, yêu cầu độ dài tối đa là 32 Bit Do đó, các trường này cần phải được định nghĩa rõ ràng trong các chỉ thị ánh dương Tuy nhiên, khi thêm các byte ánh dương, cần thiết phải có một bit báo hiệu để phân biệt giữa trường hợp có ánh dương và không có ánh dương Bit này sẽ nằm trong phần tiêu đề của định dạng.
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ỗi lần lập trình động, các thông tin cần thiết được cài đặt thêm không phụ thuộc vào loại hình dữ liệu Khi đó, phần thông tin thêm vào nên là chính xác và được đặt ngay sau phần tiêu đề chính Điều này giúp cho người 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 Đồng thời, các vấn đề thực hiện đều đồng thời với việc phân bổ 12 byte cho tiêu đề dữ liệu chính.
Mở rộng ố được cung cấp cho phép cài đặt các hàm đơn lẻ hoạt động độc lập với logic dùng của người dùng Cách thiết kế này đảm bảo phần tiêu đề đề ở ố mở rộng là trong _ing đối với các hàm không được cài đặt ở ố.
Chú ý rằng phần mở rộng này chỉ dành cho một số người dùng nhất định, khi mà các địa chỉ IP sử dụng đều liên quan đến thành phần này thì nó sẽ được đưa vào phần tiêu đề chính.
Hình 2.2 : 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 ợ ệ ừ
Here is a rewritten paragraph that contains the main points of the article, complying with SEO rules:"Trong quá trình phát triển phần mềm, việc đảm bảo mức độ tin cậy của các hàm xử lý là vô cùng quan trọng Các tiêu chuẩn đề ra ở mỗi mức độ khác nhau không ảnh hưởng đến nhau, nhưng một hàm cài đặt mức độ có thể tương thích với nhiều loại tiêu chuẩn đề ra Để đáp ứng các yêu cầu trên, phần tiêu chuẩn đề ra được thiết kế với 16-bit đầu tiên được sử dụng cho việc nhận biết bit hoặc dùng để truy nhập tham số."
2.2.1 CH C N NG VÀ HO T Ứ Ă Ạ ĐỘNG C A RTCP Ủ
Giao thức này sử dụng UDP để điều khiển các gói mang tin trong phiên truyền của các thành viên, được phân phối theo cùng cách nhất quán Các giao thức lặp lạ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 hai cổng UDP khác nhau Thông thường, các gói mang thông tin điều khiển đi qua cổng lẻ, trong khi các gói dữ liệu đi qua cổng chẵn để đảm bảo tính ổn định và hiệu quả trong việc truyền tải.
Giao th c RTCP ứ đượ ử ục s d ng v i m t s ch c n ng sau: ớ ộ ố ứ ă
Gói APP
B ng 2.16: C u trúc gói RTCP-APPả ấ 0
SSRC/CSRC name (ASCII) application-dependent data
Gói APP được sử dụng cho những người dùng mới, đang thử nghiệm hoặc những ứng dụng đang được phát triển Bởi vì nó hỗ trợ phong cách tự do, không cần phải đăng ký giá trị với IANA Một gói APP khi không xác định rõ ràng sẽ được đánh dấu là không hợp lệ Nếu sau thời gian thử nghiệm, loại gói này trở nên phổ biến, nó sẽ được đăng ký với IANA, với hai trường “subtype” và “name”, trở thành một gói RTCP trong 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
- 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 ấ ặ ấ ỳ ạ ữ ệ ụ ộ ứ ụ
- Trường này mang giá tr 204, ị để ch nh ây là gói APP-RTCP ỉ đị đ
Tên này được sử dụng để phân chia các nhóm gói ứng dụng thành các nhóm khác nhau nhằm mục đích nhận diện dễ dàng hơn Giá trị của tên này có thể thay đổi tùy theo lập trình viên đặt ra, nhưng theo khuyến nghị, nó nên được đặt dựa trên nội dung mà nó mô tả Tên này sẽ được biểu diễn dưới dạng 4 ký tự mã ASCII, có phân biệt chữ hoa và chữ thường.
Dữ liệu phụ thuộc vào ứng dụng là trường có độ dài biến đổi, với giá trị là số nguyên 32-bit Đây là một trường không bắt buộc trong gói APP, và nó được mô tả bằng một phương thức cụ thể trong ngôn ngữ lập trình.
CÁC B RTP TRANSLATORS VÀ RTP MIXERS…………………65 Ộ 2.3.1 Khái ni m chung………………………………………………………… 65 ệ 2.3.2 Ho t ạ độ ng c a b Translators………………………………………… 67 ủộ 2.3.3 Ho t ạ độ ng c a Mixers……………………………………………………70 ủ 2.3.4 Các “mixer” m c phân t ng…………………………………………… 72 ắầ 2.4: M T S THU T TOÁN C N CHÚ Ý……………………………… 72 ỘỐẬẦ 2.4.1 Phân ph i các nh danh SSRC………………………………………….72 ố đị 2.4.1.1 Xác su t xung ấ độ t
Phát hi n vòng l p và gi i quy t xung ệ ặ ả ế độ t………………74 2.4.2 V n ấ đề ả b o m t trong RTP……………………………………………… 76 ậ
Mặc dù xác suất xảy ra xung đột giữa các nhãn danh SSRC là rất thấp, nhưng người dùng vẫn cần thiết lập các cơ chế để phát hiện xung đột và chọn ra các cách giải quyết phù 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, nó sẽ gửi gói RTCP-BYE với nhãn danh SSRC của mình, sau đó 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 có hai nguồn đang xung đột, nó sẽ gây ảnh hưởng đến việc gửi và nhận các gói tin từ nguồn này và loại bỏ các gói tin từ nguồn kia Việc phân biệt hai nguồn xung đột này được thực hiện dựa trên giá trị của bản ghi CNAME Hai nguồn xung đột sẽ được cài đặt với cơ chế giải quyết xung đột, do đó 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” trong mạng multicast có chức năng chuyển tiếp một gói dữ liệu tới một nhóm multicast mà các nguồn dữ liệu đã nhận được gói dữ liệu này Trong trường hợp này, cùng một gói dữ liệu xuất hiện nhiều lần tại nhiều bên nhận, giúp phát tán thông tin một cách hiệu quả tới các nguồn khác nhau.
Hình 2.14: Minh ho l p vòng ạ ặ ắ đượ đặ đ
Khi hai bộ "translator" hoạt động song song, chúng có thể tạo ra một nhóm multicast Do đó, khi một gói tin được gửi đi, nó sẽ đồng thời được chuyển tiếp đến cùng một địa chỉ multicast Các bộ "translator" đơn hướng sẽ tạo ra hai bản sao, trong khi các bộ "translator" hai chiều có thể hạn chế vòng lặp.
Khi một nguồn dữ liệu gửi ra gói tin, có thể xảy ra tình trạng lặp vòng hoặc gói tin từ một nguồn khác gây ra lặp vòng Sự lặp vòng và xung đột này thường do việc chọn các giá trị SSRC một cách ngẫu nhiên, dẫn đến việc các gói dữ liệu bị nhầm lẫn với nhau Để tránh tình trạng này, khi một nguồn thay đổi địa chỉ giao tiếp của mình, cần chọn một giá trị SSRC mới để ngăn ngừa lặp vòng Điều này không phải là bắt buộc, nhưng trong một số ứng dụng RTP, một nguồn có thể thay đổi địa chỉ chỉ trong suốt phiên truyền.
Khi máy chủ "translator" khởi động lại, địa chỉ giao vận của nó có thể thay đổi do địa chỉ của nguồn thay đổi Nếu không được điều chỉnh, các gói dữ liệu sẽ bị coi là lặp vòng khi đến bên nhận Điều này xảy ra vì giá trị SSRC trên các gói này khác với giá trị SSRC của nguồn sau khi khởi động lại Vấn đề này có thể được tránh bằng cách giữ nguyên địa chỉ giao vận trong quá trình khởi động lại.
Khi xảy ra xung đột giữa các gói tin trong vòng lặp, việc phát hiện gặp khó khăn nếu khoảng cách giữa "mixer" và "translator" quá xa Để nhận diện và giải quyết các xung đột này, RTP cần được cài đặt thêm một thuật toán đặc biệt Thuật toán này giúp xác định xung đột bằng cách phân tích các gói tin từ nguồn phát, nhằm điều chỉnh giá trị SSRC của các thành viên trong vòng lặp Khi xung đột xảy ra, thuật toán sẽ chọn một danh tính duy nhất và sau đó điều chỉnh các gói tin để tránh tình trạng tràn ngập gói BYTE Việc này rất quan trọng để đảm bảo hệ thống hoạt động ổn định và hiệu quả.
Theo thuật toán này, cần phải tạo một bảng ánh xạ các giá trị SSRC, đảm bảo rằng 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ãn mời được nhận Bảng sẽ được cập nhật các trạng thái 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 liên quan đến chất lượng khi cần.
Nội dung của bài viết đề cập đến việc xử lý và quản lý dữ liệu thông qua một "mixer" để nhận diện và kiểm tra các nguồn dữ liệu Trong các ứng dụng hiện nay, có nhiều nguồn khác nhau có thể thay đổi địa chỉ trong suốt một phiên RTP, do đó, giao thức RTP cần phải có khả năng phát hiện và xử lý các gói dữ liệu để đảm bảo tính ổn định của nguồn dữ liệu Khi có một danh danh SSRC mới được chọn do xung đột, danh danh này cần phải được kiểm tra trong bảng danh sách nguồn để xác định xem nó đã được sử dụng bởi nguồn nào hay chưa Nếu danh danh này đã được sử dụng, một danh danh khác sẽ được tạo ra và quá trình kiểm tra sẽ tiếp tục.
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
Các "mixer" và "translator" cần 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 hoạt động chính xác, việc cần thiết là phải đảm bảo rằng các hệ thống cuối cùng hoàn toàn có khả năng truyền phát các gói dữ liệu và điều khiển Việc này có thể được thực hiện để đảm bảo tính liên tục trong một khoảng thời gian dài, mặc dù có thể gặp khó khăn trong việc duy trì độ ổn định sau một thời gian nhất định.
Thu t toán s ậ ẽ được nêu ph n ph l c ở ầ ụ ụ
Các giao thức RTP cung cấp các dịch vụ bảo mật cho một kết nối truyền thông, bao gồm xác thực, tính toàn vẹn và khả năng che giấu dữ liệu Những dịch vụ này đã được chỉnh lệnh IP Khi khởi tạo một dòng audio hoặc video sử dụng RTP, cần che giấu dữ liệu trước khi đưa xuống lớp IP bằng cách sử dụng chế độ bảo mật của các gói RTP/RTCP.
Che dữ liệu là cách bảo vệ thông tin mà người nhận mong đợi sẽ nhận được, nhằm đảm bảo rằng chỉ có những người được phép mới có thể truy cập vào nội dung gói tin Điều này rất quan trọng vì nếu dữ liệu không được bảo vệ, thông tin hữu ích có thể bị rò rỉ hoặc bị truy cập bởi những người không có quyền Để che dữ liệu của nội dung gói tin, ta sử dụng mã hóa.
Việc mã hóa các gói RTP và RTCP yêu cầu tất cả các octets được đóng gói để truyền trong một gói duy nhất và được mã hóa thành một tập hợp 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 thêm vào trước khi mã hóa Trong khi đó, đối với các gói RTP, không có dữ liệu nào được thêm vào, nhưng các trường số thật và nhãn thời gian sẽ được sử dụng trong các khung ngẫu nhiên.
Gói RTCP có thể được chia thành hai gói ghép, trong đó một gói sẽ được mã hóa và gói còn lại sẽ được truyền trực tiếp Ví dụ, thông tin SDES có thể được mã hóa, trong khi các thông điệp báo nhận sẽ được truyền 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 khóa mã Để kiểm tra tính bảo mật của gói tin, việc xác minh khóa giải mã 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 tiêu đề và phần thân gói tin.
Thuật toán mã hóa được sử dụng trong bài viết này là DES (Data Encryption Standard algorithm) theo quy định trong RFC 1423 Do giới hạn của đề tài, chúng tôi chỉ đề cập đến vấn đề này tại đây.
2.4.2.2 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