tìm hiểu về giao thức truyền tải thời gian thực rtp

tìm hiểu về giao thức truyền tải thời gian thực rtp

Tiểu luận Internet và Giao thức Đề tài: Tìm hiểu về giao thức truyền tải thời gian thực RTP (Real-time Transport Protocol) Mục lục Lời nói đầu Danh mục hình vẽ Danh mục bảng biểu Thuật ngữ viết tắt Chương 1 Giới thiệu tổng quan về RTP 1.1. Sự phát triển của các ứng dụng tương tác thời gian thực Việc truyền tải âm nhạc, lời nói, các audio cũng như video có tính tương tác cao đang ngày càng trở nên phổ biến và thay thế dần cho việc truyền tải các luồng video, text có nội dung tĩnh trên mạng internet. Những thay đổi này đòi hỏi việc đặt ra các ứng dụng mới, điều này đặt ra các thách thức mới cho các nhà thiết kế ứng dụng. Một thách thức đặt ra trong việc thiết kế các ứng dụng là phải đảm bảo được sự phân phối đáng tin cậy của audio và video trên một mạng IP khi đối mặt với các vấn đề của mạng. Vì vậy, các tổ chức tiêu chuẩn như IETF (Internet Engineering Task Force) và ITU (International Telecommunications Union- Liên minh Viễn thông Quốc tế) đã xây dựng các tiêu chuẩn cho lớp ứng dụng này mà dựa vào đó, các công ty độc lập sẽ có khả năng xây dựng các sản phẩm mới, dễ dàng hoạt động tương hợp với nhau. Hình 1.: Chồng giao thức IETF và ITU cho việc truyền audio/video trên Internet 1.2. Giới thiệu giao thức truyền tải thời gian thực RTP Một trong các giao thức được xây dựng cho các ứng dụng tương tác là giao thức truyền tải thời gian thực RTP. RTP được phát triển bởi IETF trong giai đoạn 1992- 1996, được định nghĩa cũng như trình bày rõ ràng trong RFC 1889 xuất bản năm 1996, và được thay thế bởi RFC 3550 vào năm 2003. Trong RFC 3550, RTP được mô tả là một giao thức cung cấp các chức năng truyền tải mạng đầu cuối tới đầu cuối phù hợp cho các ứng dụng truyền dữ liệu thời gian thực, chẳng hạn như audio, video hoặc dữ liệu mô phỏng qua các dịch vụ mạng đa hướng (multicast) hay đơn hướng (unicast). RTP không đề cập đến việc dự phòng tài nguyên và cũng không cung cấp các đảm bảo chất lượng QoS cho các dịch vụ thời gian thực. Việc truyền dữ liệu được bổ sung bằng một giao thức điều khiển RTCP để cho phép giám sát việc phân phối dữ liệu để có thể mở rộng các mạng đa hướng (multicast) lớn và để cung cấp chức năng kiểm soát và nhận dạng tối thiểu. RTP và RTCP được thiết kế để được độc lập bên dưới lớp truyền tải và lớp mạng. Hỗ trợ việc sử dụng giao thức RTP là các bộ dịch và bộ trộn RTP. RTP cung cấp các dịch vụ phân phối end-to-end cho dữ liệu có các đặc trưng của thời gian thực, như là audio/video có tính tương tác. Các dịch vụ này bao gồm nhận dạng loại tải trọng, gắn số thứ tự, nhãn thời gian và kiểm tra việc phân phối đối với các khúc audio/video trước khi đưa chúng tới tầng truyền tải. Các ứng dụng cơ bản sẽ chạy giao thức RTP trên UDP để thực hiện sử dụng các dịch vụ kết hợp và kiểm tra; cả hai giao thức đóng góp một phần vào chức năng của giao thức truyền tải. Tuy nhiên, RTP có thể được sử dụng với các giao thức phù hợp khác nằm bên dưới lớp mạng hoặc lớp truyền tải. RTP hỗ trợ truyền tải dữ liệu tới nhiều đích đến bằng cách sử dụng việc phân bổ đa hướng (multicast) nếu chúng được hỗ trợ ở bên dưới lớp mạng. Cần nhấn mạnh rằng RTP bản thân nó không cung cấp bất kì cơ chế nào để đảm bảo việc chuyển phát dữ liệu đúng thời hạn hay cung cấp đảm bảo các đảm bảo chất lượng QoS, độ tin cậy sẽ dựa vào các dịch vụ lớp dưới. Thậm chí nó cũng không đảm bảo chuyển gói tin đến đích hay ngăn ngừa chuyển gói tin đến sai thứ tự. Các trường số thứ tự (sequence number) trong RTP cho phép bên nhận được xây dựng lại chuỗi gói tin của bên gửi, cũng có thể được sử dụng để xác định chính xác vị trí của gói tin, ví dụ trong việc giải mã video mà không có các gói tin mã hóa cần thiết trong chuỗi. RTP được thiết kế để đáp ứng nhu cầu của các hội nghị đa phương tiện đa thành viên nhưng lại không được giới hạn các ứng dụng cần thiết. Sự tích lũy của dữ liệu liên tục, mô phỏng phân bố các tác động qua lại, dấu hiệu hoạt động và các ứng dụng điều khiển, đo lường có thể cũng tìm kiếm RTP thích hợp. Chương 2 Giao thức truyền tải thời gian thực RTP 2.1. Khái niệm cơ bản liên quan đến RTP Trước khi đi vào tìm hiểu cụ thể về giao thức RTP, chúng ta cần phải nắm được một số khái niệm cơ bản sau đây: - RTP payload: phần dữ liệu được truyền tải trong một gói tin RTP, ví dụ các mẫu audio hoặc dữ liệu video đã được nén. Việc phân định dạng dữ liệu (được chỉ định bởi trường Payload type) sẽ được đề cập đến trong phần sau. - RTP packet: một gói dữ liệu RTP, bao gồm phần cố định RTP header, phần danh sách các nguồn phân tán (có thể rỗng), phần dữ liệu payload. Một số giao thức tầng dưới có thể yêu cầu phải đóng gói lại các gói RTP. Thông thường một gói của giao thức lớp dưới chứa một gói RTP. Tuy nhiên cũng có trường hợp nhiều gói RTP được đóng gói vào một gói, điều này hoàn toàn phụ thuộc vào cách đóng gói của lớp dưới. - RTCP packet: gói tin điều khiển RTCP bao gồm phần tiêu đề cố định gần giống gói RTP, phần có cấu trúc mà dạng của cấu trúc tùy thuộc vào loại gói RTCP. Thông thường một số gói RTCP sẽ được ghép chung trong một gói của lớp dưới. Việc này có thể được thực hiện do các gói RTCP có phần tiêu đề cố định. - Port: cổng địa chỉ UDP được sử dụng. đây là khái niệm trừu tượng mà các giao thức truyền tải sử dụng để phân biệt các phiên truyền. Với giao thức TCP/IP, port là số nguyên dương 16 bit được chèn vào phần đầu của mỗi gói tin. Khái niệm port tương đương với khái niệm TSEL (transport selectors- bộ chọn lọc truyền tải) trong mô hình OSI. RTP dựa trên cac cơ chế tương tự sự phân cổng được cung cấp bởi giao thức lớp dưới để gửi đồng thời các gói dữ liệu RTP và gói tin điều khiển RTCP trong mỗi phiên truyền. - Transport address: là tổ hợp một địa chỉ mạng và cổng được định nghĩa ở tầng giao vận, ví dụ như một địa chỉ IP và một cổng UDP nhất định. Các gói tin được truyền từ transport address của nguồn tới transport address của đích. - RTP media type: một tập hợp các loại tải có cùng tính chất được mang trong phiên truyền RTP. Trong hội thảo đa phương tiện, có thể có hai loại RTP media type là video-MPEG2 và audio-PCMA. - Multimedia session: một tập hợp các phiên RTP đồng trời trong một nhóm chung của người tham gia. Ví dụ, một hội nghị truyền hình (mà là một multimedia session) có thể chứa một phiên RTP audio và một phiên RTP video. - RTP session: một liên kết giữa tập hợp các thành viên cùng tham gia giao tiếp với RTP. Một người tham gia có thể tham gia nhiều phiên RTP cùng một lúc. Trong một phiên họp đa phương tiện, mỗi phương tiện được thực hiện trong một phiên RTP riêng biệt với các gói RTCP riêng của mình. Mỗi thành viên được xác định dựa trên cặp địa chỉ nguồn (một dùng truyền gói RTP, một dùng truyền gói RTCP). Cặp địa chỉ đích có thể là chung cho tất cả các thành viên còn lại (trong trường hợp truyền đa hướng multicast) hoặc riêng biệt cho từng thành viên (trong trường hợp truyền đơn hướng unicast). Trong một phiên truyền multimedia, các tín hiệu thành phần (video/audio) được truyền theo một cặp cổng riêng. - Synchronization source (SSRC) (nguồn đồng bộ): nguồn phát dòng các gói tin RTP, được định danh bởi 32 bits SSRC trong phần tiêu đề gói RTP. Nó có giá trị hoàn toàn độc lập với địa chỉ mạng. Các gói dữ liệu được phát từ một nguồn được gắn thời gian và số thứ tự một cách thống nhất. Do đó phía thu sẽ dựa trên SSRC để khôi phục lại tín hiệu. Giá trị của định danh SSRC của mỗi nguồn RTP là đơn trị trên toàn mạng, nó được khởi tạo một cách ngẫu nhiên. - Contributing source (CSRC) (nguồn truyền báo): nguồn của một dòng của các gói tin RTP được tổng hợp nhờ bộ RTP mixer (bộ trộn RTP). Bộ mixer chèn một danh sách các định danh SSRC của nguồn để tạo ra một gói tin đặc biệt bằng cách gán vào phần tiêu đề của gói tin đó. Danh sách này được gọi là danh sách CSRC. Việc này giúp cho bên nhận có thể dễ dàng phân tách địa chỉ SSRC tương ứng với từng nguồn gói. - End system: một ứng dụng tạo ra các nội dung được gửi trong các gói tin RTP và/hoặc xử lý nội dung của gói tin RTP nhận được. Một end system có thể hoạt động như một hoặc nhiều nguồn đồng bộ trong một phiên RTP cụ thể, tùy thuộc vào số định danh SSRC mà nó sử dụng. - Mixer (bộ trộn): đây là một hệ thống trung gian, có thể nhận các gói RTP từ một hoặc nhiều nguồn đồng bộ khác nhau. Do đó dạng của dữ liệu thu được có thể khác nhau. Mixer sẽ kết hợp các gói có cùng dạng rồi chuyển tiếp trong một gói RTP mới. Khi đó thời gian được gắn theo các gói tin sẽ bị mất đồng bộ nên bộ mixer sẽ thay đổi lại các nhãn thời gian cho thích hợp với mỗi luồng ra. Bộ mixer khi hoạt động sẽ đóng vai trò như một nguồn đồng bộ. - Translator (bộ dịch): đây là một hệ thống trung gian có nhiệm vụ chuyển tiếp các gói RTP mà không làm thay đổi giá trị của SSRC - Monitor (bộ giám sát): một ứng dụng nhận gói tin RTCP được gửi bởi người tham gia trong một phiên RTP, đặc biệt là báo cáo cụ thể sự tiếp nhận, ước lượng chất lượng dịch vụ hiện thời để giám sát sự phân phối, chẩn đoán lỗi và thống kê dài hạn. Chức năng của monitor có thể được xây dựng bởi các ứng dụng có thể tham gia trong phiên hoặc không và không nhận hoặc gửi đi các gói dữ liệu RTP. Đây được gọi là các bộ monitor tham gia thứ ba. Bộ monitor thứ ba có thể nhận gói dữ liệu RTP nhưng không được gửi đi gói RTCP hoặc được tính trong phiên. - Non-RTP means: dùng để chỉ các giao thức hay các cơ chế được sử dụng để kết hợp với RTP để tạo ra những dịch vụ cụ thể, khả dụng. 2.2. Các trường tiêu đề RTP Tiêu đề RTP được định dạng theo khuôn mẫu dưới đây: Hình 2.: Cấu trúc RTP header Hình 2.1 biểu diễn các trường có mặt trong RTP header, trong đó thì 12 octets (byte) đầu tiên là cố định cho mọi gói tin RTP trừ trường CSRC identifier chỉ xuất hiện khi được thêm vào bởi một bộ mixer. Các trường có ý nghĩa như sau: - version (V): 2 bits Đây là trường định nghĩa phiên bản của RTP. Trường version được xác định là (2). Giá trị (1) được sử dụng để mô tả phiên bản nháp đầu tiên của RTP và giá trị (0) được sử dụng để biểu diễn cho các giao thức được bổ sung ban đầu trong công cụ “vat” audio. - padding (P): (trường đệm) Nếu bit padding được lập, gói dữ liệu sẽ có một vài octets thêm vào cuối gói dữ liệu. Octet cuối cùng của phần thêm vào này sẽ chỉ kích thước của phần thêm vào (tính theo byte). Những octets này không phải là thông tin. Chúng được thêm vào để đáp ứng các yêu cầu sau: phục vụ cho một vài thuật toán mã hóa thông tin cần kích thước dữ liệu xác định để có thể thực hiện, hoặc dùng để cách ly các gói RTP trong trường hợp nhiều gói thông tin được mang trong cùng một đơn vị dữ liệu của giao thức tầng dưới. - extension (X): 1 bit Nếu như bit extension được lập, theo sau phần tiêu đề cố định sẽ là một tiêu đề mở rộng. - CSRC count (CC): 4 bits Trường này xác định số lượng các định danh CSRC có trong danh sách được lưu trữ sau phần tiêu đề cố định. - marker (M): 1 bit. Tùy từng trường hợp cụ thể mà bit này mang những ý nghĩa khác nhau ý nghĩa của nó được chỉ ra trong một profile đi kèm. Nó bao gồm các thông tin về các sự kiện quan trọng như việc đánh dấu các biên của frame trong luồng packet. Profile có thể định nghĩa thêm các bit đánh dấu (marker) hoặc xác định rằng không có bit đánh dấu nào bằng cách thay đổi số lượng bit trong trường payload type. - payload type (PT): 7 bits. Trường này cho biết định dạng của RTP payload và xác định loại mã hóa mà ứng dụng sử dụng. Các mã sử dụng trong trường này ứng với các loại tải trọng được quy định trong một profile đi kèm. Nếu bên gửi quyết định thay đổi mã hóa trong phiên, bên gửi có thể thông báo với bên nhận về thay đổi này thông qua trường payload type. Bên gửi có thể muốn thay đổi mã hóa để tăng chất lượng audio/video hay giảm tốc độ bit luồng RTP. Bảng 2.1 và 2.2 dưới đây sẽ liệt kê một số loại tải trọng hiện đang được RTP hỗ trợ. Số của payload type Khuôn dạng audio Tốc độ lấy mẫu (kHz) Tốc độ (kbps) 0 PCM µ 8 64 1 1016 8 4.8 3 GSM 8 13 7 LPC 8 2.4 9 G.722 16 48-64 14 MPEG Audio 90 - 15 G.728 8 16 Bảng 2.: Một số loại payload type audio được RTP hỗ trợ Số của payload type Khuôn dạng video 26 JPEG hình ảnh động 31 H.261 32 Video MPEG1 33 Video MPEG2 Bảng 2.: Một số loại payload type video được RTP hỗ trợ - sequence number: 16 bits. Mang số thứ tự của gói RTP. Số thứ tự này được tăng lên một sau mỗi gói RTP được gửi đi. Trường này có thể được sử dụng để bên thu phát hiện được sự mất gói và khôi phục lại trình tự đúng của các gói như khi truyền. Giá trị khởi đầu của trường này là ngẫu nhiên, không thể dự đoán trước làm cho sự tấn công vào dữ liệu mã hóa trong quá trình mã hóa gặp khó khăn hơn bởi vì một gói tin có thể được truyền qua translator để thực hiện mã hóa mặc dù bản thân bên nguồn không thực hiện mã hóa. Có rất nhiều kỹ thuật tạo ra một số ngẫu nhiên không thể dự đoán trước được. - timestamp (nhãn thời gian): 32 bits. Trường timestamp phản ánh thời điểm lấy mẫu của byte đầu tiên trong gói tin dữ liệu RTP. Thời điểm lấy mẫu này phải được lấy từ một đồng hồ tăng đều đặn và tuyến tính theo thời gian để cho phép việc đồng bộ và tính toán độ jitter. Bước tăng của đồng hồ này phải đủ nhỏ để đạt được độ chính xác đồng bộ mong muốn khi phát lại và độ chính xác của việc tính toán jitter. Tần số đồng hồ này là không cố định, tùy thuộc vào loại khuôn dạng của tải trọng. Giá trị khởi đầu của nhãn thời gian cũng được chọn một cách ngẫu nhiên. Một vài gói RTP có thể mang cùng một giá trị nhãn thời gian nếu như chúng được phát đi cùng một lúc về mặt logic (ví dụ như các gói của cùng một khung hình video). Trong trường hợp các gói dữ liệu được phát ra sau những khoảng thời gian bằng nhau (tín hiệu đã mã hóa thoại tốc độ cố định, fixed-rate audio) thì nhãn thời gian được tăng một cách đều đặn. Trong trường hợp khác giá trị nhãn thời gian sẽ tăng không đều. - SSRC Identifiers: 32 bits. Trường SSRC chỉ ra nguồn đồng bộ của gói RTP. Định danh này được chọn một cách ngẫu nhiên nhằm mục đích để bất cứ hai nguồn đồng bộ nào trong cùng một phiên RTP không có cùng một định danh. Tuy nhiên, các cài đặt của RTP phải chuẩn bị cho việc phát hiện và xử lý đụng độ. Trong một phiên RTP có thể có nhiều hơn một nguồn đồng bộ. Mỗi một nguồn phát ra một dòng các gói RTP. Bên thu nhóm các gói của cùng một nguồn đồng bộ lại với nhau để phát lại tín hiệu thời gian thực. Nguồn đồng bộ có thể là nguồn phát các gói RTP phát ra từ một micro, camera hay một RTP mixer. - CSRC list: Có từ 0 đến 15 mục mỗi mục 32 bits Danh sách CSRC xác định các số nhận dạng nguồn đóng góp trong phần tiêu đề, chỉ ra những nguồn đóng góp thông tin và phần tải trọng của gói. Các số nhận dạng này được Mixer chèn vào tiêu đề của gói và nó chỉ mang nhiều ý nghĩa trong trường hợp dòng các gói thông tin là dòng tổng hợp tạo thành từ việc trộn nhiều dòng thông tin tới mixer. Trường này giúp cho bên thu nhận biết được gói thông tin này mang thông tin của những người nào trong một cuộc hội nghị. Số lượng các số nhận dạng nguồn đóng góp được xác định trong trường CC của phần tiêu đề. Số lượng tối đa của các số nhận dạng này là 15. Nếu có nhiều hơn 15 nguồn đóng góp thông tin vào trong gói thì chỉ có 15 số nhận dạng được liệt kê vào danh sách. Mixer chèn các số nhận dạng này vào gói nhờ số nhận dạng SSRC của các nguồn đóng góp. 2.3. Cấu trúc phần tiêu đề mở rộng (RTP Header Extension) Một cơ chế mở rộng được cung cấp để cho phép thử nghiệm thức thi những chức năng định dạng độc lập payload mới yêu cầu các thông tin bổ sung cần được mang theo trong tiêu đề RTP. Cơ chế này được thiết kế để phần tiêu đề mở rộng có thể được bỏ qua bởi các thực thi khác không hỗ trợ. Chú ý rằng phần tiêu đề mở rộng này chỉ được giới hạn sử dụng. Hầu hết các khả năng sử dụng của cơ chế này sẽ được thực hiện tốt hơn bất kì cách nào khác. Thông tin thêm vào đòi hỏi cho mỗi định dạng payload không nên sử dụng cho phần tiêu đề mở rộng nhưng nên được thực hiện trong phần payload của gói dữ liệu. Hình 2.: Cấu trúc phần tiêu đề mở rộng Nếu như bit X trong phần tiêu đề cố định được đặt bằng 1 thì theo sau phần tiêu đề cố định là phần tiêu đề mở rộng có chiều dài thay đổi được nối thêm vào ngay sau phần danh sách CSRC nếu danh sách này có trong phần tiêu đề. Phần tiêu đề mở rộng có một trường dài 16 bit cho biết chiều dài của nó tính theo word (32 bit) trừ phần tiêu đề phụ dài 4 byte. Chỉ có thể thêm được một phần tiêu đề mở rộng vào RTP header. Tuy nhiên 16 bit đầu tiên trong phần tiêu đề mở rộng được sử dụng với mục đích riêng cho từng ứng dụng được định nghĩa bởi profile. Thường nó được sử dụng để phân biệt các loại tiêu để mở rộng. Tiếp theo là trường length có độ dài 16 bits. Mang giá trị chiều dài của phần tiêu đề mở rộng tính theo đơn vị là word (32 bit). 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 phải được thiết kế với 16 bit đầu tiên được dùng cho việc nhận ra định danh hoặc tham số. 2.4. Ghép kênh các phiên RTP Để xử lý một cách hiệu quả thì số lượng các phiên RTP được đem ghép kênh phải càng nhỏ càng tối. Trong RTP, sự ghép kênh được thực hiện nhờ vào địa chỉ truyền đích (địa chỉ mạng và số cổng) xác định nên một phiên RTP. Ví dụ: trong một cuộc hội thảo từ xa bằng âm thanh và hình ảnh mà các dữ liệu này được mã hóa bởi hai bộ phận riêng biệt thì các dữ liệu này nên được truyền trên hai phiên RTP khác nhau với địa chỉ truyền đích riêng. Nếu truyền chung trong một phiên RTP, việc xen kẽ các gói với các kiểu payload khác nhau nhưng cùng một định danh SSRC sẽ dẫn đến một số vấn đề sau: 1. Nếu hai luồng âm thanh được chia sẻ trong cùng một phiên RTP với cùng một giá trị SSRC và một trong hai luồng được mã hóa khác đi dẫn đến loại payload khác nhau. Khi đó sẽ không có cách nào xác định loại payload của luồng đã thay đổi cách mã hóa. 2. SSRC được định nghĩa để xác định một cách tính thời gian và không gian số thứ tự riêng. Do đó, việc truyền xen kẽ nhiều loại payload sẽ cần nhiều cách tính thời gian khác nhau và cũng sẽ cần nhiều không gian số thứ tự hơn để biết các gói tin của loại payload nào bị mất. 3. Thông báo của bên gửi và bên nhận RTCP có thể chỉ mô tả một cách tính thời gian và một không gian số thứ tự riêng cho mỗi một SSRC và không kèm theo trường payload type. 4. Bộ RTP mixer không thể kết hợp các luồng dữ liệu xen kẽ không tương thích nhau thành một luồng. 5. Truyền nhiều loại dữ liệu trong cùng một phiên RTP sẽ không có được các khả năng: sử dụng sự phân phối các đường mạng và tài nguyên mạng khác nhau nếu có thể; chỉ nhận được một số loại dữ liệu trong số nhiều loại yêu cầu ví dụ như chỉ nhận được âm thanh nếu tín hiệu hình ảnh vượt quá băng thông; bên nhận cài đặt các xử lý riêng cho mỗi loại dữ liệu; việc dùng nhiều phiên RTP cho phép các cài đặt đơn hoặc đa xử lý. Sử dụng định danh SSRC khác nhau cho mỗi loại dữ liệu nhưng gửi trong cùng một phiên RTP giống nhau sẽ tránh được ba vấn đề đầu tiên nhưng không tránh được hai vấn đề cuối. Một cách khác, ghép kênh các nguồn đa phương tiện của cùng một loại dữ liệu trong một phiên RTP sử dụng các giá trị SSRC khác là quy tắc cho các phiên đa hướng (multicast). Các vấn đề liệt kê bên trên không áp dụng cho: một bộ RTP mixer có thể kết hợp các nguồn âm thanh mà sử dụng cùng một cách xử lý cho tất cả. Điều này cũng có thể thích hợp để ghép các luồng của cùng một loại dữ liệu sử dụng giá trị SSRC khác nhau trong các kịch bản khác nhau (hai vấn đề cuối không áp dụng). 2.5. Những thay đổi trong đặc tả profile của RTP header Cấu trúc hiện tại của phần tiêu đề RTP được coi là đầy đủ để đáp ứng tất cả các chức năng cho mọi lớp ứng dụng mà RTP có thể hỗ trợ. Tuy nhiên, với nguyên lý thiết kế ALF, tiêu đề RTP có thể được cải tiến bằng cách chỉnh sửa hoặc thêm vào [...]... hay xảy ra Jitter Để giải quyết vấn đề này, phần RTP header có chứa thông tin về thời gian và số thứ tự của các gói tin Do đó bên thu có thể dựa vào đó để khôi phục lại về mặt thời gian Trong trường hợp này, mỗi thành viên sẽ liên tục truyền đi các gói tin với chu kỳ 20ms Việc khôi phục thời gian này được biểu diễn riêng cho mỗi nguồn của các gói tin RTP trong cuộc hội thoại, do đó sẽ giúp cho bên nhận... dụng sử dụng RTP Trong các ví dụ này, RTP được thực hiện trên nền IP và UDP, và theo các quy ước trong RFC 3551 3.1 Hội thảo audio sử dụng multicast đơn giản Nhóm IETF đưa ra ý kiến việc sử dụng dịch vụ IP multicast cho việc truyền tín hiệu thoại trên mạng Internet Quan điểm chính là kết hợp việc truyền Multicast và sử dụng đồng thời hai cổng truyền dữ liệu Trong đó một cổng sẽ dùng để truyền các dữ... dụng audio và video Hình 2.5 RTP trong hội thảo sử dụng cả video/audio Trong trường hợp ta sử dụng đồng thời cả âm thanh và hình ảnh trong hội thảo, dữ liệu âm thanh và hình ảnh sẽ được truyền trong các phiên RTP riêng biệt Thật vậy, các gói tin RTP và RTCP được truyền riêng biệt cho mỗi luồng dữ liệu sử dụng hai cặp cổng UDP khác nhau và/hoặc các địa chỉ đa hướng Việc truyền tín hiệu tiếng và tín... phát triển ứng dụng thực sự viết mã thực hiện đóng gói gói tin RTP tại bên gửi và tháo gỡ RTP tại bên nhận 2 Phát triển ứng dụng sử dụng các thư viện RTP (đối với người lập trình C) và các lớp Java (đối với người lập trình Java) sẵn có để thực hiện đóng gói và tháo gỡ cho ứng dụng Tổng kết và kết luận Tài liệu tham khảo 1 2 [1, 2] H Schulzrinne, S.C., R Frederick and V Jacobson, RTP: A Transport Protocol... với profile vẫn có thể xử lý các gói tin RTP chỉ với 12 octet đầu tiên Nếu đến lúc nào đó các chức năng phụ được nhận thấy là cần thiết cho tất cả các profile thì một phiên bản mới hơn của RTP sẽ được xây dựng để cố định các thay đổi trong phần tiêu đề Chương 3 Các kịch bản sử dụng giao thức RTP Nội dung chương này sẽ mô tả một số khía cạnh của việc sử dụng RTP Các ví dụ đã được lựa chọn để minh họa... gần nơi có băng thông hẹp Bộ này sẽ tái đồng bộ các gói tin thoại, khôi phục lại chu kỳ 20ms của phía gửi, sau đó truyền lại dòng audio với tốc độ bit phù hợp với đường truyền Việc truyền lại này có thể sử dụng truyền đơn hướng cho một người nhận đơn, hoặc đa hướng cho nhiều người nhận Phần RTP header sẽ đảm nhận việc định danh lại người gửi phía nhận Một số những người tham gia trong hội thảo có thể... ví dụ khác về bộ translator là việc kết nối của một nhóm các máy chủ sử dụng IP/UDP với một nhóm các máy chủ chỉ có thể hiểu ST-II, hoặc mã hóa dịch gói-by-gói của các luồng video từ các nguồn cá nhân mà k cần đồng bộ hóa lại hay pha trộn chúng Chương 4 Phát triển ứng dụng phần mềm với RTP Có hai giải pháp để phát triển ứng dụng kết nối mạng dựa trên RTP: 1 Phát triển ứng dụng kết hợp RTP thủ công... phần RTP header; RTP header và dữ liệu được chứa trong một gói tin UDP Tiêu đề RTP sẽ xác định loại mã hóa tín hiệu thoại (PCM, ADPCM…) được mang trong phần dữ liệu, vì vậy kiểu mã hóa tín hiệu thoại của những thành viên tham gia có thể thay đổi trong quá trình hội đàm Điều này rất có ý nghĩa, đặc biệt đối với những thành viên sử dụng đường truyền tốc độ thấp hay trong trường hợp nghẽn mạng Việc truyền. .. dữ liệu Điều này không thể được trong trường hợp có thành viên sử dụng đường truyền tốc độ thấp, các thành viên khác lại sử dụng đường truyền ở tốc độ cao Khi đó ta không thể bắt tất cả các thành viên khác cùng sử dụng truyền ở tốc độ thấp, chất lượng thấp Hình 3.: Minh họa việc sử dụng bộ mixer Khi đó, ta có thể sử dụng bộ RTP chuyển tiếp cân bằng gọi là bộ mixer, đặt gần nơi có băng thông hẹp Bộ này... dùng để truyền các dữ liệu thoại cụ thể, cổng còn lại sẽ sử dụng để truyền các gói tin điều khiển RTCP Địa chỉ và cổng thông tin được phân chia cho những người tham gia Trong trường hợp cần yêu cầu bảo mật thì dữ liệu và các gói tin điều khiển trước khi truyền qua hai cổng này sẽ được mã hóa theo chuẩn, các khóa mã cũng sẽ được sinh ra và truyền kèm theo Mỗi thành viên tham gia thoại sẽ gửi dữ liệu thoại . lường có thể cũng tìm kiếm RTP thích hợp. Chương 2 Giao thức truyền tải thời gian thực RTP 2.1. Khái niệm cơ bản liên quan đến RTP Trước khi đi vào tìm hiểu cụ thể về giao thức RTP, chúng ta cần. Chồng giao thức IETF và ITU cho việc truyền audio/video trên Internet 1.2. Giới thiệu giao thức truyền tải thời gian thực RTP Một trong các giao thức được xây dựng cho các ứng dụng tương tác là giao. Tiểu luận Internet và Giao thức Đề tài: Tìm hiểu về giao thức truyền tải thời gian thực RTP (Real-time Transport Protocol) Mục lục Lời nói đầu Danh mục