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.
9. 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.
10. 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. (adsbygoogle = window.adsbygoogle || []).push({});
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ố.