Tài liệu Nghiên cứu truyền tin bằng giao thức rtp và ứng dụng thực tiễn

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Nguyễn Công Minh NGHIÊN CỨU TRUYỀN TIN BẰNG GIAO THỨC RTP VÀ ỨNG DỤNG THỰC TIỄN LUẬN VĂN THẠC SĨ Hà Nội - 2007 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Nguyễn Công Minh NGHIÊN CỨU TRUYỀN TIN BẰNG GIAO THỨC RTP VÀ ỨNG DỤNG THỰC TIỄN LUẬN VĂN THẠC SĨ Hà Nội - 2007 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Nguyễn Công Minh NGHIÊN CỨU TRUYỀN TIN BẰNG GIAO THỨC RTP VÀ ỨNG DỤNG THỰC TIỄN Ngành : Công nghệ Điện tử - Viễn thông Chuyên ngành: Kỹ thuật vô tuyến điện tử và thông tin liên lạc Mã số: 2.07.00 LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC PGS-TS TRẦN QUANG VINH Hà Nội - 2007 i MỤC LỤC Trang phụ bìa………………………………………………………… i Lời cam đoan…….………………………………....………………… ii Mục lục ……..……………………………………....………………… iii Danh mục các bảng ……..…………………………..……………… vi Danh mục các hình vẽ…………………………....………………… vii Mở đầu ………………………………………....………..…………… 1 Chương 1: Giao thức RTP …………………….……………..……. 3 1. Giới thiệu.…………………………………………….…………... 3 2. Giao RTP……………………………………….…………… thức 4 2.1. Giao thức RTP………………………………….………….… 4 2.2. Cấu trúc gói tin RTP………………………….……..……… 5 2.3. Vấn đề đồng RTP…………………….…………...… của 6 2.4. Hoạt động của RTP………………………….……………… 7 3. Profile và các dạng của payload……………………….……… 9 3.1. Profile cho hội nghị âm thanh và hình ảnh………..…….. 9 3.2. Sự hoạt RTP………………………..…….. động bộ trên 10 gian 11 4. Các khái niệm liên quan khác…………….…………….……… 11 4.1. Nén Header…………………………………………….…..… 11 4.2 Quản lý thông tin các gói RTP……………………….…….. 12 5. Kết luận…………………………………………………………… 12 Chương 2: Truyền thông tin qua Internet………………………. 14 3.3. Dạng payload thực…………..…….. cho con H.261 trỏ thời iii 1. Tổng quan về hệ thống Web……………………………………. 1.1. thiệu……………………………………………………... 14 Giới 14 1.2. Mô hình hệ thống Web nói chung…………………………. 14 1.3. Nguyên tắc hoạt động………………………………………. 15 2. Ngôn ASP………………………………………………... ngữ 15 Markup 15 2.2.Ngôn ASP………………………………………………… ngữ 16 2.2.1. Cơ bản ASP…………………………………………… về 16 2.2.2. Mô hình hoạt động của ASP…………………………… 17 2.2.3. Tạo một trang ASP……………………………………… 18 2.1. Ngôn Language)……. ngữ HTML (Hyper Text 2.3. Lập trình ASP……………………………………………. với 19 2.3.1. Thêm các Script…………………………………………. 19 2.3.2. Khai báo ASP……………………………….. trong 19 ứng 20 2.3.4. Khai báo thủ tục, hàm và cách gọi…………………… 20 2.3.4.1. Đối với VBScript……………………………………. 20 2.3.4.2. Đối với JScript……………………………………… 21 2.3.5. Tạo liên kết giữa các file……………………………….. 21 2.3.6. Các đối tượng Component……………………………... 21 2.3.6.1. Khái niệm về Component………………………….. 21 2.3.3. Biến phiên dụng…………………………… 2.3.6.2. Sử Component……………………………. biến và dụng biến các 22 iv đối 22 đối 22 của 22 cổng 24 1. Giới thiệu…………………………………………………………. 24 2. Điều khiển cổng LPT……..………………………….…………. 24 3. Kiểm tra ………………….………………………………………. 32 Chương 4: Thực nghiệm: Điều khiển các thiết bị cho ngôi nhà thông minh của thế kỷ XXI ………………………………….. 33 1. Giới thiệu…………………………………………………………. 33 2. Mô hình…………………………………………………………… 33 2.3.6.3. Phương tượng………... thức và 2.3.6.4. Giải tượng……………………………….. thuộc phóng 2.3.7. Các đối ASP…………………………………. Chương 3: Điều LPT………………………………….. tính tượng khiển 3. Giải pháp hiện……………………………………………… của thực 34 4. Các bước tiến hành……………………………………………… 37 4.1. Cài đặt IIS……………………………………………………. 37 4.2. Lập trình điều khiển………………………………………… 40 5. Cấu hình WebServer…………………………………………….. 48 6. Cấu hình quan sát……………………………………………….. 53 Chương 5: Định hướng tiếp theo …………………………………. 63 1. Giới thiệu…………………………………………………………. 63 2. Điều khiển thiết bị qua SMS……………………………………. 63 2.1. Định hướng hiện……………………………………….. thực 63 2.2. Giải pháp mềm………………………………………… phần 66 v 3. Mở rộng…………………………………………………………... 69 Kết luận………………………………………………………………... 70 Tài liệu tham khảo…………………………………………………... 71 Phụ lục 1………………………………………………………………. 73 Phụ lục 2………………………………………………………………. 83 vi DANH MỤC CÁC BẢNG Cấu trúc gói tin RTP ……………………………………………… 5 Giá trị bit các chân của cổng LTP……………………………….. 31 vii DANH MỤC HÌNH VẼ Cấu trúc gói tin RTP………………………………………………. 5 Truyền trực tiếp một buổi hòa nhạc……………………………… 7 Mô hình hệ thống Web……………………………………………... 14 Mô hình hoạt động của ASP………………………………………. 18 Cấu tạo cổng LPT………………………………………………….. 24 Sơ đồ mạch thử cổng LPT…………………………………………. 32 Mô hình điều khiển thiết bị……………………………………….. 33 Sơ đồ lắp ráp Rơle trong mạch…………………………………… 34 Cấu trúc UNL2003, UNL2803…………………………………… 35 Sơ đồ nguyên lý bị……………………………….. điều khiển thiết 36 Sơ đồ nguyên lý chi tiết điều khiển thiết bị……………………… 36 Kiến trúc hệ thống quan sát………………………………………. 55 Sơ đồ kết nối Mobile và PC……………………………………….. 64 viii MỞ ĐẦU Ngày nay, cùng với sự phát triển của xã hội thì ngành công nghệ thông tin đang đạt được những tiến bộ đáng kể. Các hãng sản xuất phần cứng cũng như phần mềm luôn luôn cố gắng tạo ra những sản phẩm tốt nhất và tối ưu nhất với mức giá hấp dẫn nhất có thể, đưa ra thị trường nhằm phục vụ cho lợi ích của người tiêu dùng cũng như làm tăng thị phần của mình trong môi trường cạnh tranh khốc liệt. Cùng với sự phát triển của ngành công nghệ thông tin trên thế giới, công nghệ thông tin Việt Nam với phương châm đi tắt đón đầu cũng đã có những bước phát triển vượt bậc. Những năm trước đây, người sử dụng mạng Internet ở nước ta chỉ có thể truy cập bằng các Modem quay số (Dial-up) với tốc độ khá chậm và cước phí còn khá cao so với thu nhập bình thường của người lao động. Vài ba năm trở lại đây, người sử dụng mạng Internet đã được tiếp cận nhiều hơn bởi sự phát triển rộng rãi của công nghệ DSL (Digital Subsriber Line - đường dây thuê bao số). Với công nghệ này thì Internet đã trở nên phổ biến trong cộng đồng và Internet dần trở thành một nhu cầu tất yếu của xã hội hiện đại. Đời sống xã hội ngày càng được cải thiện, môi trường sống và làm việc tốt hơn cùng với thu nhập của người lao động cũng khá hơn trước nên yêu cầu về các tiện ích trong cuộc sống cũng tăng lên đáng kể. Giờ đây, người sử dụng không chỉ dừng lại ở những ứng dụng thông thường mà Internet mang đến, những loại hình giải trí như nghe nhạc, xem phim chưa đủ làm thỏa mãn nhu cầu mà họ cần có những ứng dụng cao hơn, hiện đại hơn như giám sát và điều khiển những thiết bị từ xa, bởi nó vừa có tính an toàn cao và đồng thời cũng mang rất nhiều tiện ích trong một xã hội công nghiệp đang phát triển. Xuất phát từ những nhu cầu cơ bản đó trong xã hội hiện đại nên tác giả đã nghiên cứu để ứng dụng sự phát triển của công nghệ thông tin vào sử dụng trong đời sống thường ngày, nhằm thiết kế một ngôi nhà thông minh, đáp ứng những yêu cầu thiết yếu của con người trong việc quan sát ngôi nhà thân yêu của mình và điều khiển các thiết bị điện trong nhà mỗi khi đi vắng, tạo tâm lý yên tâm hơn mỗi khi chúng ta không có mặt ở nhà để tập trung nâng cao năng suất lao động trong công việc đạt được những kết quả cao hơn. 1 Về cơ bản, nội dung của đề tài này được chia thành hai phần chính: Lý thuyết và Thực nghiệm. Phần Lý thuyết trình bày các vấn đề cơ bản về truyền tin trên mạng Internet sử dụng giao thức thời gian thực RTP (Real-Time Transport Protocol), xây dựng ý tưởng quan sát và điều khiển từ xa đối với ngôi nhà thông minh và các thiết bị được lắp đặt trong nó. Phần Thực nghiệm trình bày về các bước tiến hành để dự án có thể khả thi, các yêu cầu về thiết bị, phần cứng, phần mềm, lập trình ứng dụng nhằm giải quyết những vấn đề đã được đề cập đến trong phần Lý thuyết, thiết kế và thi công lắp ráp hoàn chỉnh các mạch điện thực hiện cho mục đích chính của đề tài. Trong quá trình thực hiện đề tài này, tác giả đã nhận được sự giúp đỡ rất nhiều của các thầy cô giáo trường Đại học Công nghệ - Đại học Quốc gia Hà nội, nhất là sự hướng dẫn nhiệt tình của thầy giáo PGS TS Trần Quang Vinh, nhân đây tác giả xin chân thành cảm ơn sự giúp đỡ của các thầy cô giáo và đặc biệt cảm ơn PGS TS Trần Quang Vinh đã giúp cho tác giả có điều kiện, kiến thức để thực hiện thành công đề tài. Mặc dù tác giả đã rất cố gắng, nhưng do điều kiện và trình độ còn có nhiều hạn chế nên không thể tránh được những thiếu sót trong đề tài, rất mong sự đóng góp ý kiến của các thầy giáo, cô giáo và các bạn đồng nghiệp cũng như các độc giả để đề tài này có thể phát triển tốt hơn, nhằm phục vụ các nhu cầu cơ bản của đời sống cộng đồng. Hà nội, tháng 11 năm 2007 Tác giả Nguyễn Công Minh 2 Chương 1: GIAO THỨC RTP 1. Giới thiệu: Hai thập niên trước, sự phát triển của Internet mới chỉ đơn thuần là cố gắng truyền tải các bản tin và các file dữ liệu. Giao thức truyền chủ yếu được sử dụng là TCP (Transmission Control Protocol), cung cấp một dịch vụ đáng tin cậy cho việc truyền dữ liệu không cấu trúc [13]. Từ đó, đã có rất nhiều nghiên cứu về thuật toán điều khiển tắc nghẽn của giao thức này, bởi vì công việc làm giảm tắc nghẽn một cách có hiệu quả là nhu cầu cần thiết của Internet khi mà số lượng các Host trong mạng liên tục tăng lên một cách nhanh chóng. Những năm gần đây đã xuất hiện xu hướng sử dụng giao thức IP (Internet Protocol) để truyền đi các loại dữ liệu khác nhau. Ngoài việc cung cấp các dịch vụ truyền thống như thư điện tử và các ứng dụng duyệt Web, các nhà cung cấp còn có tham vọng đưa đến cho chúng ta những dịch vụ mới hơn, đó là có thể xem những chương trình truyền hình yêu thích trên nền Internet bằng cách sử dụng các thiết bị IP, hoặc có thể thưởng thức các buổi hòa nhạc với thời gian thực (real-time) được truyền trên mạng IP từ bất kỳ nơi nào trên thế giới. Tuy nhiên, việc truyền các dữ liệu âm thanh hay hình ảnh (Audio/Video) lại không thể thực hiện được bằng giao thức TCP, bởi nó yêu cầu tất cả các bit dữ liệu cần phải sắp xếp theo đúng thứ tự. Có một lựa chọn khác để truyền các luồng dữ liệu theo thời gian thực trên Internet, đó là sử dụng trên giao thức UDP (User Datagram Protocol) [14], nhưng giao thức này lại không hỗ trợ cho việc nhận các thông tin phản hồi từ phía thu, không kiểm tra được luồng dữ liệu có đến đích hay không và cũng không có sự hổ trợ một số tính năng cần thiết cho truyền các dữ liệu theo thời gian thực. AVT (Audio/Video Transport – truyền dẫn các tín hiệu âm thanh và hình ảnh) là một nhóm của tổ chức IETF (Internet Engineering Task Force) đã xác định các giao thức cần thiết cho việc truyền các dữ liệu âm thanh và hình ảnh, trong đó phải kể đến giao thức RTP (Real-time Transport Protocol) dùng để truyền tải các dữ liệu thời gian thực trên Internet. Ngoài giao thức RTP, nhóm này còn xác định một số profile dùng cho RTP và dạng payload cho các loại dữ liệu thời gian thực khác nhau, mà chủ yếu là dạng âm thanh và hình ảnh [7]. 3 2. Giao thức RTP 2.1. Giao thức RTP RTP (Real-time Transport Protocol - giao thức truyền tải thời gian thực) được coi là một chuẩn của RFC được IETF giới thiệu vào năm 1996. Mục đích của giao thức là cung cấp dịch vụ truyền dữ liệu theo thời gian thực như các luồng âm thanh và hình ảnh [15]. RTP được sử dụng ở lớp trên của các giao thức truyền tải khác, mà điển hình là lớp UDP trên Internet. Theo như nguyên lý thiết kế của giao thức thì RTP là giao thức end-to end, mặc dù trên đường truyền dẫn có thể gồm có một số Host trung gian. RTP gồm hai giao thức liên quan là: RTP dùng cho truyền dữ liệu thời gian thực và cho điều khiển, giám sát nguồn dữ liệu được truyền đi, hay còn gọi là RTCP (RTP Control Protocol - giao thức điều khiển truyền dữ liệu thời gian thực). Đối với RTP thì dạng của các Header là cố định nhưng dạng của payload lại phụ thuộc vào dữ liệu được mã hóa. Bên cạnh các luồng dữ liệu âm thanh và hình ảnh thì RTP cũng được dùng để truyền các dạng dữ liệu thời gian thực bất kỳ. Và như vậy, các đặc tính truyền phụ thuộc rất nhiều vào dạng của payload [7]. Cũng giống như RTP, RTCP là giao thức truyền Datagram ở lớp trên cùng. Đặc điểm quan trọng nhất của RTCP là nơi gửi sẽ nhận được các phản hồi (feedback) về chất lượng truyền dẫn. Các header của giao thức RTP cũng khá đơn giản, thường thì chúng chỉ thị cho dạng của payload và các dạng của chúng được định nghĩa đầy đủ trong Profile Specification. Ngoài các thông tin về dạng payload, các header còn chứa thông tin nhận dạng về nguồn đồng bộ (Synchronization Source) và có thể gồm cả danh sách phân bố kèm theo của chúng (Contributing Source). Tuy nhiên, các header này có thể mở rộng theo yêu cầu của dạng payload. Giao thức RTP sử dụng khái niệm nguồn đồng bộ (SSRC Synchronization Source) trong các header của gói tin để nhận diện ra các gói dữ liệu đã được Share ở cùng thời điểm và được đánh số một cách lần lượt. Tại nơi nhận, thông tin về SSRC của các gói tin được chia ra từ các luồng khác nhau sẽ được sử dụng để sắp xếp luồng dữ liệu đầu ra. Dữ liệu gốc từ các nguồn vật lý khác nhau, ví dụ như từ các Camera, phải được phân biệt bởi các SSRC, ngay cả khi chúng đã được đồng bộ. 4 Và như vậy, các luồng âm thanh và hình ảnh từ các cuộc hội thảo được truyền một cách tách biệt với nhau cũng dùng các SSRC khác nhau, rồi sau đó chúng được kết hợp với nhau tại nơi nhận bởi các thông tin định thời trong các gói tin RTP [7]. 2.2. Cấu trúc của gói tin RTP Cấu trúc gói tin RTP và header cụ thể được biểu diễn như sau [29]: IP Header UDP Header +Bits RTP Header RTP Payload 0-1 2 3 4-7 8 9-15 16-31 Sequence Number 0 Ver P X CC M PT 32 Timestamp 64 SSRC indentifier 96 …SSRC indentifier… 96+(CCx32) Extension header (optional) 96+(CCx32) + (Xx((EHL+1)x32)) Data 5 Trong đó: V (Version - phiên bản) gồm 2 bit chỉ thị phiên bản của RTP P (Padding - đệm) gồm 1 bit chỉ thị số lượng octet không chứa dữ liệu nằm sau payload X (Extention - phần mở rộng) gồm 1 bit chứa header mở rộng CC (CSRC Count - bộ đếm CSRC) gồm 4 bit chứa số lượng CSRC trong header M (Marker - đánh dấu) gồm 1 bit chứa thông tin về mục đích của ứng dụng PT (Payload Type - Dạng payload) gồm 7 bit chứa thông tin về dạng của payload, diễn tả ứng dụng Sequence Number - dãy số gồm 16 bit được tăng lên tương ứng với lượng dữ liệu được gửi đi và cũng có thể được sử dụng tại nơi nhận để phát hiện gói tin bị mất, giá trị ban đầu thường là ngẫu nhiên Timestamp - tem thời gian bồm 32 bit phản ánh tốc độ lấy mẫu octet đầu tiên của gói dữ liệu RTP SSRC gồm 32 bit nhận diện nguồn đồng bộ CSRC chứa thông tin nhận diện về sự phân bố của nguồn dữ liệu chứa payload của gói tin, số lượng do CC quyết định, tối đa là 15. CSRC indentifer được chèn bởi các bộ trộn. 2.3. Vấn đề đồng bộ của RTP[29] Để có thể đồng bộ được, bên nhận cần phải có 3 thông tin về nguồn đồng bộ, trật tự của gói tin và thời gian lấy mẫu. Các thông tin này được cung cấp trong header. Nguồn đồng bộ (SSRC): Bên nhận có thể nhận dữ liệu từ nhiều nguồn phát khác nhau, do vậy để sắp xếp lại chúng thì cần phải có thông tin từ các nguồn đồng bộ của các gói tin đơn lẻ được cung cấp trong SSRC Chuỗi số (Sequence Number): khi không đủ thông tin để nhận ra nguồn phát, chuỗi số được thêm vào. Chuỗi số này được tăng lên khi các 6 gói tin được gửi đi và có thể được sử dụng tại nơi nhận để phát hiện các gói tin bị mất và khôi phục lại chuỗi của gói tin Tem thời gian (Timestamp): các gói tin được truyền trên mạng có tem thời gian, phía nhận có thể dựa vào thông tin về các tem thời gian này để tái tạo lại dữ liệu âm thanh và hình ảnh 2.4. Hoạt động của RTP Việc tách riêng các luồng âm thanh và hình ảnh sẽ cho phép nơi nhận có thể loại ra một số luồng đến chậm do sự nghẽn cổ chai của các đường truyền dẫn. Hơn nữa, đối với các loại dữ liệu âm thanh và hình ảnh khác nhau thì việc gắn các tem thời gian (timestamp) của các xung clock cũng khác nhau. Một Host trung gian trên mạng kết nối RTP có thể hoạt động như một bộ trộn (mixer), nghĩa là nó sẽ sử dụng một số phương pháp để kết hợp dữ liệu đến từ các nguồn khác nhau để tạo dòng dữ liệu đầu ra. Vì các nguồn dữ liệu sử dụng các định thời và các chuỗi khác nhau, do đó các gói dữ liệu của các luồng phải sử dụng các SSRC khác nhau để có thể nhận diện ra dữ liệu gốc. Bộ trộn lưu trữ các SSRC của các dữ liệu gốc dưới dạng danh sách nguồn (Contributing Source - CSRC) trong header của gói tin RTP. Node trung gian cần có kiểu gọi khác, gọi là bộ chuyển đổi (Translator), nó không là thay đổi SSRC nhưng nó có thể biến đổi thông tin mã hóa hoặc lọc các gói tin dữ liệu theo yêu cầu [7]. 7 Hình 1: Truyền trực tiếp một buổi hòa nhạc Hình 1 miêu tả một ví dụ về buổi hòa nhạc được truyền trực tiếp theo nền tảng của công nghệ IP. Các ca sĩ và nhà quay phim được nối với các Computer Box nhỏ để có thể truyền được âm thanh và hình ảnh bằng các gói tin RTP tới các máy trạm (Client). Bộ trộn (mixer) tập hợp trộn các dữ liệu âm thanh, xử lý chúng rồi chuyển tiếp tới máy trạm (Client). Bộ trộn sử dụng nguồn đồng bộ của nó (SSRC = 20) và lưu trữ SSRC của ca sĩ vào bảng CSRC trong header của RTP. Trên hình cũng chỉ ra rằng luồng Video và dữ liệu Audio không được kết hợp với nhau tại bất kỳ điểm nào mà nó được truyền tới các máy trạm (Client) một cách độc lập và riêng rẽ bởi các SSRC. Tại phía nhận, máy trạm (Client) không quan tâm tới sự khác nhau của các SSRC, mà nó kết hợp các dữ liệu với nhau dựa trên các thông tin về tem thời gian (timestamp) với giả sử rằng các xung clock của nhạc sĩ, bộ trộn và các camere được đồng bộ tại thời điểm truyền đi. Nơi gửi RTP sẽ gửi định kỳ các bản tin (sender report) trong các gói tin RCTP 64 bit với tem thời gian NTP. Tem thời gian NTP sử dụng giao thức thời gian mạng (Network Time Protocol) [16], biểu thị thời gian đã qua với mốc tính từ thể kỷ XX. Tuy nhiên, tem thời gian RTP cũng được dùng với cùng tần số đồng hồ và được bù ngẫu nhiên trong các gói dữ liệu. Sở dĩ phải dùng hai loại tem thời gian khác nhau như vậy là để đồng bộ các dữ liệu từ các nguồn khác nhau. Hơn nữa, dựa vào các thông tin định thời, nơi phát có thể cho biết về các gói đã được truyền đi. Nơi nhận RTP sẽ phản hồi lại thông tin về tem thời gian cho nơi phát thông qua bản tin nhận (receiver report) RCTP để cho nơi phát biết định thời và thống kê quá trình truyền. Hơn thế nữa, bản tin nhận còn cho biết về số lượng các gói bịn mất, các gói đã nhận được. Trong quá trình truyền dẫn hai chiều thì bản tin gửi đi có thể chứa thông tin về dữ liệu được gửi đi từ các nguồn khác. Mục đích chính của các bản tin là giám sát chất lượng truyền của dữ liệu thời gian thực, do hiện tượng mất các gói và nghẽn mạng trên đường truyền. Các bản tin RTP gửi đi tuỳ thuộc vào khoảng cách, tốc độ truyền 8 và cách mã hóa dữ liệu. Các gói tin này thường được xử lý bởi các bộ chuyển đổi trung gian nếu có sự thay đổi dữ liệu. Chẳng hạn như bộ chuyển đổi có thể thay đổi dữ liệu RTP mã hóa nếu nó làm ảnh hưởng đến số lượng các octet mà bộ chuyển đổi truyền đi. Tuy nhiên, tại nơi gửi cần ước lượng các octet chứa dữ liệu giống nhau trong quá trình truyền gói. 3. Profile và các dạng của payload Như đã đề cập từ trước, bản thân giao thức RTP không đủ khả năng để cung cấp một ứng dụng hoàn thiện cho quá trình truyền dữ liệu theo thời gian thực, mà nó cần thiết phải kết hợp với hoặc profile truyền dẫn, hoặc dạng của tải (payload) hoặc cả hai. Phần này sẽ giới thiệu một profile chung nhất, khái quát nhất của RTP được dùng trong các dạng payload âm thanh, hình ảnh khác nhau. Hơn nữa, phần này sẽ trình bày một cách tóm tắt về phương thức truyền các luồng hình ảnh bằng giao thức RTP với khuyến nghị H.261 và những vấn đề khác khi truyền các luồng hình ảnh thời gian thực bằng gói tin RTP, các dạng payload khác nhau. 3.1. Profile cho hội nghị âm thanh và hình ảnh Nhóm AVT đã đưa ra định nghĩa về một profile đơn giản cho hội nghị âm thanh/hình ảnh, theo như định nghĩa chỉ ra thì profile này được cấu hình tối thiểu, không có bất kỳ header mở rộng nào và được khởi tạo cùng với kiểu payload bằng cách ánh xạ, các xung clock của tem thời gian (timestamp) cũng tỉ lệ với các kiểu mã hóa khác nhau của payload. Vì các header của RTP có 7 bit dành cho việc mã hóa kiểu của chúng, do vậy có tất cả 128 loại mã có thể được sử dụng, trừ những trường hợp sử dụng mã cố định. Chính vì thế, có 22 loại mã cố định, chung và thông dụng nhất cho các payload profile âm thanh/hình ảnh. Các loại mã payload động được xác định gồm có 32 loại, còn lại các loại mã khác sẽ được sử dụng tuỳ thuộc vào giao thức phát triển của chúng. Tuy nhiên, giao thức điều khiển xác định các dạng payload động không được đề cập đến trong profile, các kiểu của profile tĩnh sẽ được cân nhắc kỹ trong cộng đồng rộng lớn sử dụng Internet [7]. Để nhận diện dạng payload, các xung clock của profile sẽ có tốc độ tỉ lệ với từng loại payload riêng biệt. Đối với các luồng âm thanh thì xung 9 clock này sẽ có tốc độ giống như tốc độ lấy mẫu của tín hiệu âm thanh được số hóa. Tốc độ lấy mẫu cơ bản của âm thanh là 8kHz, nhưng thông thường thì người ta vẫn hay sử dụng hai thêm hai loại tốc độ nữa là 16kHz và 44.1kHz cho một vài loại mã âm thanh khác. Với payload của tín hiệu hình ảnh thì tốc độ thường được sử dụng là 90kHZ, phụ thuộc vào các chuẩn truyền hình khác nhau. 3.2. Sự hoạt động H.261 trên RTP Khuyến nghị H.261 của ITU-T chỉ ra rằng mã dùng cho truyền dẫn dữ liệu âm thanh/hình ảnh được sử dụng trên băng tần thấp. Mặc dù được thiết kế cho các line có băng tần cố định, nhưng các nghiên cứu đã chỉ ra rằng H.261 cũng có thể được sử dụng trên cả các mạng chuyển mạch gói (packet-switched). Chính vì vậy mà AVT đã thiết kế các dạng của payload cho phép truyền dẫn dữ liệu của H.261 trên RTP [12]. Để truyền các luồng âm thanh/hình ảnh bằng RTP thì mã hóa H.261 phải có một số sự thay đổi so với ban đầu. Đầu tiên, về nguyên bản thì H.261 cho phép trộn lẫn các luồng âm thanh/hình ảnh với nhau, nhưng điều đó lại không phù hợp với RTP vì RTP đòi hỏi các luồng âm thanh/hình ảnh phải được truyền dẫn một cách riêng biệt. Chính vì vậy, các luồng âm thanh và hình ảnh phải được tách ra thành các gói RTP khác nhau. Một điểm khác biệt nữa của H.261 với RTP đó là sử dụng các mã sửa lỗi giữa các khung dữ liệu (data frame). Cho dù công việc sửa lỗi các frame của H.261 trong quá trình truyền dẫn được tiến hành khá tốt, nhưng khi sử dụng RTP thì điều đó lại không cần thiết, bởi việc phát hiện và sửa lỗi đã được thực hiện tốt ở các giao thức lớp dưới. H.261 luôn sử dụng các loại mã khác nhau nhằm mục đích giảm lượng dữ liệu cần phải truyền đi. Tuy nhiên, điều đó cũng làm nảy sinh vấn đề về mất gói, do đó cần phải có biện pháp để khắc phục hiện tượng này. Một phương pháp đơn giản nhất được sử dụng để làm giảm số lượng mã hóa trong nén dữ liệu là chỉ truyền đi những frame mà các frame này hoàn toàn độc lập với các frame khác (hay còn gọi là Intraframes). Mặc dù đây chưa phải là giải pháp toàn diện nếu có sự giới hạn về băng tần, dạng của payload H.261 được khuyến nghị nên dùng các phương thức khác nhau. Bên phát có thể khôi phục lại các luồng dữ liệu H.261 bằng cách gửi Intra-frame theo một chu kỳ nhất định, hoặc bên 10 nhận có thể gửi yêu cầu về Intra-frame khi phát hiện có hiện tượng mất gói [7]. 3.3. Dạng payload cho con trỏ thời gian thực Giao thức RTP có thể được sử dụng để truyền các loại dữ liệu thời gian thực khác nhau. Như ví dụ trên, dạng payload thời gian thực được kết hợp với dữ liệu được truyền trên giao thức RTP được miêu tả một cách ngắn gọn.Việc truyền các con trỏ thời gian thực trên Internet là cần thiết, bởi vì khi ứng dụng trong hội nghị truyền hình để truyền âm thanh và hình ảnh một cuộc hội thảo về đào tạo sử dụng thì lúc này con trỏ trở nên rất cần thiết cho bài giảng của một giảng viên [11]. Con trỏ này đòi hỏi phải có tính chính xác, thời gian di chuyển phải phù hợp với những gì mà người giảng viên trình bày, đồng thời phải đồng bộ với tốc độ của luồng thông tin âm thanh và hình ảnh. Sử dụng phương pháp mã hóa thông thường RTP cho các luồng hình ảnh này là không thích hợp, bởi vì tín hiệu hình ảnh sẽ không đạt được độ phân giải như mong muốn khi truyền trên mạng với băng thông bị hạn chế. Dạng của payload RTP cho con trỏ thời gian thực rất đơn giản. Nó sẽ được thêm 3 bit dữ liệu cho ứng dụng đặc biệt này, payload sẽ sử dụng 24 bit cho con trỏ kết hợp với khoảng trắng từ hai phía và 3 bit cho biểu tượng số của con trỏ (pointer icon number). Các tem thời gian RTP sử dụng xung clock có tần số 90kHz, bằng với tần số của các luồng hình ảnh được xác định trong profile cơ sở về âm thanh và hình ảnh, do vậy việc đồng bộ con trỏ với các dữ liệu hình ảnh trở nên dễ dàng hơn [7]. 4. Các khái niệm liên quan khác 4.1. Nén Header Việc nén các header của gói tin IP/UDP/RTP là một đặc điểm rất quan trọng để tận dụng hiệu quả băng tần trên Internet. Nếu header của RTP chưa được nén thì chiếm ít nhất 12 byte, còn header của gói tin IP và UDP lớn hơn 28 byte. Một số payload của dữ liệu RTP gồm có 20 byte hoặc hơn thế nữa, nhưng theo chuẩn nén RFC2508 thì các header của RTP chỉ còn chứa khoảng 2 đến 4 byte. Các header của RTP được nén hoạt động rất hiệu quả cho gói tin TCP/IP [. Thuật toán nén header cơ bản bỏ qua header của các field 11