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. Ngồ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ẽ hồn tồ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à hồn tồ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:
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, 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ã hố 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.