Chơng V: các bộ RTP Translators và RTP Mixers
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:
a. 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, nhng 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ó.
c. 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ó.
d. 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).
e. 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.