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 34ing 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 34ing 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 34ing 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 34ing mà nhiều nguồn phát chọn cùng một định danh là rất hiếm, nhng 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 34ing vào do bộ Mixer. Tại phía ngời nhận, nó đợc 34ing để 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 34ing để 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 34ing 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). Nhng 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ỉ 35ing 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. Nhng 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 36ing 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 36ing 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 trng cho 36ing ứng dụng. Các trờng này đợc đặt trong phần tiêu đề cố định, trong khi đó để 36ing đợ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 36ing 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 36ing 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 36ing đối với các hàm không đợc cài đặt cơ chế mở rộng. (adsbygoogle = window.adsbygoogle || []).push({});
Chú ý rằng, phần mở rộng này chỉ dành cho một số ngời ngời 37ing, khi mà đa phần ngời sử dụng đều 37ing đến thành phần này thì nó sẽ đợc đa vào phần tiêu đề cố định.
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ố.