12 byte đầu tiên đƣợc đƣa ra trong mọi gói tin RTP. Danh sách các chỉ số CSRC chỉ đƣợc chèn vào tại bộ trộn. Ý nghĩa các trƣờng nhƣ sau:
V (Version): độ dài 2 bit. Trƣờng này xác định độ dài của RTP.
P (Padding): độ dài 1 bit. Nếu bit này là 1 thì gói tin sẽ có một hoặc nhiều hơn một octet bù đƣợc chèn vào cuối mỗi gói tin (vì một số thuật toán mã hóa sử dụng các kích thƣớc block cố định).
X (Extension): độ dài 1 bit. Nếu bit này là 1 thì sẽ có phần mào đầu mở rộng sau phần mào đầu cố định.
CC (CSRC Count): độ dài 4 bit. CC xác định số lƣợng các CSRC indentifier sau phần mào đầu cố định.
M (Marker): độ dài 1 bit. Trƣờng này đƣợc sử dụng để cho phép đánh dấu các sự kiện quan trọng nhƣ các giới hạn khung trong luồng gói tin.
PT (Payload Type): độ dài 7 bit. Trƣờng này định nghĩa cấu trúc của tải tin RTP để ứng dụng có thể biên dịch đƣợc tải tin.
Sequence Number: độ dài 16 bit. Khi một gói tin RTP đƣợc đi thì trƣờng này đƣợc tăng lên 1 đơn vị. Phía nhận sử dụng trƣờng này để phát hiện các gói tin bị mất và khôi phục lại trật tự gói tin.
Timestamp: độ dài 32 bit. Trƣờng này chứa thông tin về thời điểm lấy mẫu của octet đầu tiên trong gói dữ liệu RTP. Trƣờng này đƣợc sử dụng cho mục đích đồng bộ và tính toán độ biến thiên trễ (jitter).
SSRC: độ dài 32 bit. Trƣờng SSRC đƣợc sử dụng để xác định nguồn đồng bộ.
CSRC: có từ 0 đến 15 mục, mỗi mục có chiều dài 32 bit.
3.2.2 Các ứng dụng sử dụng RTP
3.2.2.1 Thoại hội nghị đơn giản
Nhóm nghiên cứu của IETF đang nghiên cứu giao thức sử dụng các dịch vụ thoại dùng IP multicast trên nên mạng Internet công cộng. Dịch vụ này dùng một địa chỉ nhóm multicast và một cặp cổng. Trong đó một cổng đƣợc sử dụng cho dữ liệu thoại, và cổng kia đƣợc sử dụng cho các bản tin điều khiển (RTCP). Thông tin địa chỉ và cổng đƣợc gửi cho các thành viên nhóm multicast. Nếu dịch vụ bảo mật đƣợc sử dụng thì các gói tin dữ liệu và gói tin điều khiển đều đƣợc
mã hóa. Trong trƣờng hợp đó phải tạo ra khóa mã và khóa mã đƣợc gửi cho các thành viên của nhóm multicast.
Phần mềm thoại hội nghị ở tại đầu cuối của mỗi thành viên của nhóm multicast gửi dữ liệu thoại theo từng đoạn ngắn (với khoảng thời gian thoại là 20 ms). Mỗi đoạn dữ liệu thoại sẽ đƣợc gắn thêm một RTP header, sau đó cả RTP header và dữ liệu thoại lại tiếp tục đƣợc đóng gói trong gói tin UDP. RTP header sẽ chỉ ra rằng kiểu mã hóa thoại (PCM, ADPCM hoặc LPC) nào đƣợc sử dụng trong mỗi gói tin, nhờ vậy phía gửi có thể thay đổi kiểu mã hóa trong suốt quá trình thoại hội nghị.
Mạng Internet cũng giống nhƣ các mạng gói khác thƣờng xẩy ra hiện tƣợng mất gói tin, trật tự gói tin đến bị thay đổi và thời gian trễ của mỗi gói tin khác nhau. Để khắc phục những vấn đề này, RTP header có chứa trƣờng thông tin định thời và trƣờng thứ tự của mỗi gói tin (Sequence Number). Những thông tin này cho phép phía nhận khôi phục lại thông tin định thời và do đó các đoạn thoại đƣợc phát ra liên tục với tần suất 20ms. Việc khôi phục thông tin định thời đƣợc thực hiện riêng biệt cho mỗi nguồn gói tin RTP trong nhóm thoại hội nghị. Phía nhận cũng có thể sử dụng trƣờng Sequence Number để ƣớc lƣợng xem có bao nhiêu gói tin bị mất.
Vì các thành viên của nhóm thoại hội nghị có thể tham gia và rời khỏi nhóm ở bất kỳ thời điểm nào trong suốt quá trình thoại hội nghị. Một điều quan trong là các thành viên của nhóm cần phải biết đƣợc những thành viên nào đang tham gia vào thoại hội nghị tại bất kỳ thời điểm nào và các thành viên nhận dữ liệu thoại có đảm bảo chất lƣợng không. Để giải quyết vấn đề này, mỗi ứng dụng thoại trong nhóm thoại hội nghị định kỳ phải gửi cho các thành viên khác báo cáo nhận (reception) bao gồm cả tên ngƣời dùng của nó trên cổng RTCP. Báo cáo nhận cho biết thành viên này nhận dữ liệu thoại có tốt không và thông tin trong báo cáo này có thể đƣợc sử dụng để điều khiển lựa chọn kiểu mã hóa thoại thích hợp. Ngoài ra các thông tin nhƣ tên ngƣời dùng và các thông tin xác nhận khác có thể đƣợc sử dụng để điều khiển các giới hạn băng thông. Khi mỗi thành viên của nhóm thoại hội nghị rời khỏi nhóm thì nó phát đi bản tin RTCP để báo cho các thành viên khác trong nhóm biết.
3.2.2.2 Thoại và truyền hình hội nghị
Khi cả phƣơng tiện thoại và video đƣợc sử dụng trong nhóm hội nghị, thì dữ liệu thoại và dữ liệu video đƣợc phát đi theo các phiên RTP riêng biệt. Các gói tin RTCP đƣợc phát đi cho mỗi phƣơng tiện sử dụng các cặp cổng UDP hoặc các địa chỉ multicast khác nhau. Khi một ngƣời dùng tham gia vào thoại và video thì ngƣời dùng đó phải sử dụng cùng một tên nhận dạng trong các gói tin RTCP cho cả hai phiên đó ngoài ra không có bất kỳ một sự kết hợp nào tại mức RTP giữa các phiên thoại và video.
Một trong những động cơ của việc chia tách này là để cho phép một số thành viên trong nhóm hội nghị chỉ nhận dữ liệu thoại hoặc video tùy theo họ lựa chọn. Mặc dù có sự tách biệt giữa các phiên thoại và video nhƣng sự đồng bộ giữa thoại và video có thể đạt đƣợc bằng cách sử dụng thông tin định thời chứa trong các gói tin RTCP cho cả hai phiên thoại và video.
3.2.2.3 Bộ trộn và bộ biên dịch
Xem xét trong trƣờng hợp một số thành viên của nhóm hội nghị ở một vùng nào đó kết nối tới nhóm thoại hội nghị thông qua các kênh tốc độ thấp trong khi phần lớn các thành viên khác lại kết nối qua các kênh tốc độ cao. Thay vì bắt tất cả các thành viên trong nhóm hội nghị sử dụng tốc độ thấp, ngƣời ta sử dụng một bộ chuyển tiếp ở mức RTP hay còn đƣợc gọi là bộ trộn đặt tại phía các thành viên có tốc độ thấp. Các bộ trộn đồng bộ lại các gói tin thoại đầu vào để tái tạo lại khoảng thời gian không đổi 20ms giữa các đoạn thoại đƣợc tạo ra ở phía gửi, ghép các luồng thoại này thành một luồng, chuyển kiểu mã hóa thoại sang kiểu mã hóa thoại tốc độ thấp và chuyển luồng gói này lênh kênh tốc độ thấp. Các gói tin này có thể đƣợc phát unicast tới một ngƣời nhận hoặc đƣợc phát multicast trên một địa chỉ khác tới nhiều ngƣời nhận.
Một số thành viên của nhóm thoại hội nghị có thể kết nối thông qua kênh tốc độ cao nhƣng gói tin vẫn không thể đi đến đƣợc thông qua IP multicast. Ví dụ các thành viên này nằm sau một firewall ở mức ứng dụng, firewall này không cho phép bất kỳ một gói tin IP nào đi qua. Trong trƣờng hợp này ngƣời ta sử dụng một bộ chuyển tiếp ở mức RTP khác đƣợc gọi là bộ biên dịch (translator).
Trong trƣờng hợp nhƣ ví dụ trên sử dụng hai bộ biên dịch đƣợc lắp đặt ở hai phía của firewall. Bộ biên dịch ở phía ngoài sẽ nhận tất cả các gói tin multicast và chuyển cho bộ biên dịch ở phía trong firewall. Bộ biên dịch này sau đó sẽ gửi các gói tin multicast cho nhóm multicast bị giới hạn trong vùng mạng nội bộ.
3.3 Đồng bộ luồng hình ảnh và âm thanh
Việc truyền tải hình ảnh và âm thanh qua mạng bằng các ứng dụng riêng biệt sẽ dẫn đến việc ngƣời sử dụng cảm thấy khoảng thời gian trễ giữa phần tiếng và phần hình. Một số ứng dụng có yêu cầu chất lƣợng cao, đòi hỏi thời gian trễ giữa hình và tiếng phải đủ nhỏ để đạt đƣợc hiệu quả mong muốn. Việc đồng bộ hóa hình và tiếng có thể đƣợc thực hiện bằng cách làm chậm lại việc phát tín hiệu hình hoặc tiếng để hai tín hiệu này đồng bộ với nhau về mặt thời gian.
Mạng MBone là mạng multicast bên trong mạng Internet. Các phần mềm audio cho MBone, ví dụ nhƣ Rat, Nevot và các công cụ video nhƣ Vic, Ivs không hỗ trợ đồng bộ đƣờng hình và tiếng. Bộ phần mềm gồm công cụ audio Rat (robust audio tool) và công cụ video Vic (video conference) do UCL phát triển là bộ phần mềm đầu tiên hỗ trợ đồng bộ hình tiếng. Công cụ rat và vic đều sử dụng giao thức thời gian thực RTP của IETF để hỗ trợ các tính năng cần thiết cho giao tiếp video và audio sử dụng multicast. Cơ chế đồng bộ của rat sử dụng nhãn thời gian trong gói tin RTP để xác định thời gian làm trễ gói tin.
Việc gửi tín hiệu âm thanh qua mạng chuyển mạch gói đòi hỏi khả năng bảo vệ mất gói tin và trễ end-to-end thấp. Yêu cầu trễ thấp đồng nghĩa với việc kích thƣớc gói tin phải nhỏ và tần suất gửi gói tin cao. Kích thƣớc gói tin âm thanh trong mạng Internet tƣơng đƣơng với khoảng 20 đến 80 ms.
Trong khi đó thì công cụ video thƣờng có tốc độ quét ảnh thấp, chỉ từ 2 đến 10 hình/giây, chứ không cao nhƣ trong truyền hình (tốc độ 24 hình/giây). Lý do tốc độ quyết thấp là để tiết kiêm băng thông mạng, nhất là khi có nhiều nguồn video cùng đƣợc phát một lúc. Ngoài ra, thời gian xử lý video tại thiết bị đầu cuối cũng khá lớn khiến cho thời gian trễ giữa thời điểm bắt và hiển thị hình thƣờng khá lớn. Mỗi khung hình video thƣờng đƣợc chia nhỏ trƣớc khi gửi qua mạng.
Mạng MBone là mạng chuyển mạch gói chia sẻ có hỗ trợ multicast. Các thiết bị định tuyến vẫn hoạt động trên nguyên tắc đến trƣớc phục vụ trƣớc (FIFO) và vẫn trộn lẫn lƣu lƣợng từ nhiều nguồn khác nhau thành một luồng lƣu lƣợng. Điều này gây ra trễ jitter giữa các gói tin của một luồng gói tin thời gian thực. Khi luồng tin chứa thông tin âm thanh, trễ jitter phải đƣợc loại bỏ vì nếu không thì âm thanh phát ra tại thiết bị đầu cuối sẽ trở nên khó hiểu. Kỹ thuật thƣờng đƣợc dùng để loại bỏ jitter là sử dụng một bộ đệm tái tạo âm thanh. Bộ đệm này cho phép lƣu gói tin và làm trễ thời điểm phát tiếng, do vậy có thể giảm trễ jitter giữa các gói tin ở đầu ra. Cơ chế bộ đệm này phải có khả năng thích ứng do trễ jitter trên mạng MBone có thể thay đổi tùy từng thời điểm.
Việc tính toán thời gian làm trễ gói tin phải dựa trên thời gian truyền gói tin qua mạng. Vì thời gian làm trễ gói tin và tỷ lệ gói tin đến kịp thời có liên quan đến nhau, ngƣời ta thƣờng chọn thời gian làm trễ sao cho tỷ lệ gói tin đến nơi kịp thời là 99,9%.
Trễ jitter cũng ảnh hƣởng đến các ứng dụng video (hình ảnh sẽ bị giật). Tuy nhiên, đứng trên phƣơng diện của ngƣời sử dụng, việc này không ảnh hƣởng nhiều đến chất lƣợng của ứng dụng. Các công cụ video hiện thời nhƣ vic hay ivs đều hiển thị khung hình ngay khi nhận và giải mã gói tin.
Sự khác biệt giữa trễ tiếng và hình thƣờng thay đổi khá lớn do thời gian xử lý tín hiệu audio và video khác nhau. Vì vậy để có thể đồng bộ đƣờng hình và tiếng cần phải làm trễ một trong hai đƣờng hình tiếng tại đầu nhận. Các thử nghiệm với ngƣời sử dụng cho thấy, hai luồng tín hiệu hình tiếng không nhất thiết phải đồng bộ hoàn toàn và có thể lệch nhau 80 – 100 ms mà ngƣời sử dụng vẫn cảm thấy thoải mái.
Việc làm trễ đƣờng tiếng vẫn đƣợc thực hiện với một bộ đệm. Trong khi đó, các phần mềm video thƣờng không dùng bộ đệm ở đầu ra, nhƣng với yêu cầu đồng bộ hệ thống video cũng phải sử dụng bộ đệm.
Trễ đƣờng hình thƣờng lớn hơn trễ đƣờng tiếng. Trễ đƣờng tiếng không đƣợc quá lớn để đảm bảo độ tƣơng tác của hệ thống. Vì vậy phải có sự thống nhất giữa hệ thống hình và tiếng, tức là ta phải có phƣơng thức báo hiệu giữa hai hệ thống hình và tiếng để hai đƣờng có thể đồng bộ với nhau.
Báo hiệu giữa tiến trình video và audio đƣợc thực hiện thông qua một bus báo hiệu nội bộ, ví dụ nhƣ giao thức CCC (Conference Control Channel Protocol) hay bus báo hiệu LBL. Cả hai kiến trúc này đều trao đổi thông tin thông qua kênh loopback của multicast.
3.4 Sử dụng Access Grid xây dựng một hội nghị truyền hình
Access Grid theo cách hiểu đơn giản là một môi trƣờng tích hợp hỗ trợ cho ứng dụng hội nghị truyền hình, Access Grid sử dụng các công cụ audio và video để cho phép ngƣời dùng từ các nơi khác nhau trên thế giới có thể giao tiếp thông qua một phòng họp ảo (virtual venue). Trong các phòng họp ảo, các thành viên tham dự hội nghị có thể thấy và nói chuyện với các thành viên khác trong thời gian thực, sử dụng các công cụ trò chuyện hay chia sẻ các tài liệu một cách đồng thời.
3.4.1 Các thành phần của Access Grid