Hình 4: Cấu trúc header của RTP
Các trường trong tiêu đề RTP : Version( V ) : 2 bít. Trường này xác định phiên bản của RTP: Padding( P ) : 1 bít
Nếu trường padding được thiếp lập lên 1, thì gói dữ liệu chứa thêm một hay nhiều bộ 8 bít dữ liệu mở rộng. Nó không phải là một phần của gói dữ liệu. 8 bít cuối của phần dữ liệu bổ sung chứa tổng số octets nên bỏ qua, bao gồm chính nó. Dữ liệu bổ sung thường không được sử dụng, nhưng nó lại cần thiết trong những thuật toán mã hóa với kích thước của gói dữ liệu là cố định hoặc cần thiết cho việc mang đi nhiều gói RTP trong một đơn vị dữ liệu giao thức lớp dưới.
a) Extension( X ) : 1 bít
RTP cho phép một phần header mở rộng được báo hiệu bằng bít X trong header RTP. Khi bít X được đặt là 1, sau phần header cố định của RTP và trước phần dữ liệu của gói sẽ có một header mở rộng với định dạng riêng, chiều dài của header này không cố định nhưng đều bắt đầu bằng 16 bít chỉ kiểu và 16 bít chỉ chiều dài (không bao gồm 32 bít này), cho phép các ứng dụng có thể loại bỏ nếu không đọc được thông tin trong header này.
Header mở rộng này được cung cấp khi ứng dụng cần nhiều thông tin hơn những gì có trong header cố định của RTP. Chúng rất ít khi được sử dụng. Thông
thường thay vì sử dụng header mở rộng, chúng ta sẽ lưu các thông tin bổ sung bên trong phần dữ liệu của gói như là một header của phần dữ liệu.
b) CSRC count( CC ) : 4 bít
Trường CSRC count chứa số lượng CSRC theo sau header.
c) Marker( M ) : 1 bít
Bít đánh dấu Marker trong header của RTP được sử dụng để đánh dấu các sự kiện trong một luồng media, giá trị của nó quyết định bởi đặc tả RTP và định dạng media được sử dụng.
Đối với các luồng dữ liệu audio sử dụng đặc tả RTP cho dữ liệu audio và video với cấu hình tối thiểu, bít Marker được đặt là 1 khi gói đầu tiên được gửi sau một khoảng lặng, còn lại được đặt là 0. Bít Marker được đặt là 1 là dấu hiệu cho các ứng dụng biểt được lúc nào nên điều chỉnh thời lượng chơi bởi một chút thay đổi trong độ dài khoảng lặng thường người nghe khó nhận ra.
Đối với các luồng dữ liệu video sử dụng đặc tả RTP cho dữ liệu audio và video với cấu hình tối thiểu, bít Marker được đặt là 1 khi đó là gói cuối cùng chứa dữ liệu của một frame video, các gói khác được đặt bằng 0. Bít Marker được đặt là 1 là dấu hiệu cho các ứng dụng biết thời điểm nào bắt đầu giải mã frame đó thay vì chờ đợi một gói có timestamp khác (cũng là một cách nhận biết) để xác định dữ liệu đầy đủ cho một frame.
Trong mọi trường hợp, bít Marker chỉ là dấu hiệu cho các ứng dụng. Với luồng audio, thông thường có thể nhận biết điểm kết thúc của một khoảng lặng nhờ mối quan hệ giữa sequence number và timestamp thay đổi. Điểm bắt đầu của một frame video có thể được phát hiện bởi sự thay đổi timestamp. Một ứng dụng có thể sử dụng các nhận biết này để hoạt động tốt nhưng làm giảm khả năng thi hành nếu gói chứa bít Marker bị mất.
d) Payload type (PT) : 7 bít
Chỉ định loại media nào được truyền đi trong các gói RTP. Các ứng dụng bên nhận kiểm tra trường này để quyết định cách thức xử lý dữ liệu.
Tất cả các định dạng dữ liệu đều được đăng ký theo chuẩn MIME (MIME type registration). Các định dạng mới hơn được định nghĩa trong đặc tả của chúng; Một nhóm đăng ký cho các định dạng cũ hơn đang được phát triển.
Hình 5: Khởi tạo phiên
Dù kiểu dữ liệu được chỉ định là tĩnh hay động, điều cần thiết là phải mô tả được phiên hiện thời tới ứng dụng sao cho ứng dụng đó hiểu được những loại dữ liệu nào đang được sử dụng. Một trong các giao thức dùng để mô tả phiên đó là SDP (Session Description Protocol). Một ví dụ về một bản ghi SDP như hình 5.
Ví dụ trên mô tả 2 phiên RTP, audio được gửi loopback 127.0.0.1 qua cổng 1230, Time-To-Live là 127, video được gửi tới cùng nhóm multicast nói trên qua cổng 1232. Cả audio và video đều sử dụng giao thức RTP/AVP làm giao thức chuyển vận. Audio được mã hóa dạng MPEGA, còn video được mã hóa theo chuẩn H.264
e) Sequence number : 16 bít
Là số không dấu 16 bít dùng để phân biệt các gói,và được dùng để sắp xếp gói theo đúng trật tự ở phía thu và phát hiện mất gói. Tuy nhiên nó không được dùng để đặt lịch playout của các gói tin
Giá trị của số thứ tự được khởi đầu ngẫu nhiên để tăng tính bảo mật của dòng dữ liệu (khó cho các cuộc tấn công khi không biết phiên bắt đầu từ gói nào).
Giá trị của số thứ tự tăng lên 1 sau mỗi gói và khi giá trị của số thứ tự tăng tới giá trị tối đa (65535) thì trở về 0. Và giá trị của số thứ tự tăng đều liên tục không nhảy lại phía sau trừ trường hợp quay vòng (wrap-around).
Tùy theo ứng dụng người ta có thể dùng thêm số thứ tự mở rộng theo công thức sau: extended_sequence_number = sequence_number + (65535 * wrap_around_count).
f) Timestamp : 32 bít
Nhãn thời gian chỉ khoảng thời gian lấy mẫu của octet đầu tiên của dữ liệu media ở trong 1 gói, được dùng để đặt lịch của dữ liệu media.
Nhãn thời gian là số nguyên 32 bít không dấu tăng tuỳ theo tốc độ của media, và trở về không khi giá trị đạt cực đại. Giá trị bắt đầu là ngẫu nhiên làm cho các cuộc tấn công vào dòng dữ liệu khó khăn hơn
Nhãn thời gian không phải là duy nhất trong 1 phiên, 2 gói dữ liệu khi có cùng nhãn thời gian có nghĩa là chúng có cùng thời gian lấy mẫu. Cụ thể hơn, trong trường hợp truyền 1 khung video có kích thước lớn, khung sẽ chia thành các mảnh nhỏ hơn và được đóng trong các gói có số thứ tự khác nhau nhưng có cùng nhãn thời gian
Hình 6 : Phân mảnh dữ liệu
RTP
header Payload header Payload
data
Timestamp Nén frame đa phương tiện
Frame nguyên bản với timestamp
Mảnh khung phù hợp với mạng MTU. Mỗi mảnh có nhãn thời gian
Tạo ra các gói RTP. Nhãn thời gian tạo thành một phần tiêu đề và thêm payload header mô tả mảnh
g) SSRC
ợc ánh xạ tới một định danh phiên (long-lived canonical name) CNAME thông qua giao thức điều khiển RTCP.
SSRC là một số nguyên 32 bít có giá trị ngẫu nhiên được chọn bởi các bên tham gia khi tham gia vào phiên. Bởi SSRC được chọn ngẫu nhiên từ phía host nên sẽ có thể xảy ra trường hợp 2 bên tham gia có cùng giá trị
ố SSRC của nó, phương pháp phát hiện xung đột này đảm bảo SSRC là duy nhất cho mỗi bên tham gia trong một phiên.
Tất cả các gói có cùng SSRC tạo, bên nhận cần phải nhóm các gói theo SSRC để thực hiện quá trình playback. Nếu một bên tham gia nào đó tạo ra nhiều luồng media trong một phiên RTP thì với mỗi luồng sẽ phải có một số SSRC khác nhau để các bên nhận có thể phân biệt gói nào thuộc luồng nào.
h) CSRC
Trong các trường hợp thông thường, các gói RTP được tạo ra chỉ bởi một nguồn duy nhất, nhưng khi có nhiều luồng RTP đi qua một bộ mixer hoặc translator, các dữ liệu từ nhiều nguồn này có thể được góp vào một gói RTP. Trong danh sách CSRC chứa thông tin của các bên tham gia có dữ liệu nằm trong gói RTP nhưng không chứa các thông tin liên quan đến thời gian và đồng bộ. Mỗi mã nhận dạng nguồn là một số nguyên 32 bít mang thông tin chính là SSRC của bên tham gia có dữ liệu nằm trong gói. Chiều dài của danh sách CSRC được chỉ định trong trường CC của RTP Header.
Các gói chứa danh sách CSRC được tạo ra bởi bộ RTP Mixer, khi nhận được một gói chứa danh sách CSRC, các số SSRC sẽ được sử dụng để nhóm các gói và xử lý một cách bình thường và mỗi CSRC được thêm vào danh sách các bên tham gia đã biết. Mỗi bên tham gia xác định bởi một CSRC sẽ có một luồng giao thức điều khiển gói RTP tương ứng mang đầy đủ thông tin về bên tham gia.