1.3.1 Những khái niệm ban đầu:
RTP là một giao thức chuẩn dùng cho việc truyền các dữ liệu thời gian thực như video, audio. Nó có thể được sử dụng trong media-on-demand cũng như trong các dịch vụ tương tác khác nhưđiện thoại internet…giao thức RTP bao gồm hai phần, dữ liệu và điều khiển (RTCP).
Hình 1.6: Mô hình tổng quát về giao thức RTP.
Giao thức RTP (Real-time transport protocol), cung cấp các hàm phục vụ việc truyền tải dữ liệu “end to end” cho các ứng dụng thời gian thực, qua các mạng multicast hay qua mạng unicast. Các dịch vụ này bao gồm:
- Sự phân loại tải: payload type identification. - Đánh số thứ tự: sequence numbering. - Đánh dấu thời gian phát, đồng bộ hoá:
Hình 1.7 :Nhãn thời gian và sựđồng bộ.
- Theo dõi quá trình truyền tải: delivery monitoring.
Để hỗ trợ cho RTP là giao thức điều khiển RTCP. Giao thức này nhằm đảm bảo cho việc truyền dữ liệu, cho phép theo dõi được quá trình truyền tải trên một mạng multicast. Ngoài ra nó còn cung cấp các dịch vụ các chức năng điều khiển và nhận dạng. Cả RTP và RTCP đều được thiết kế để có thể cài đặt một cách độc lập với các giao thức lớp mạng và lớp giao vận.
Các ứng dụng RTP hoạt động phía trên của chồng giao thức UDP, với vai trò điều chế và cung cấp các dịch vụ kiểm soát lỗi. Tuy nhiên RTP cũng có thể sử dụng kết hợp với các chồng giao thức dưới lớp mạng hay dưới lớp giao vận. RTP hỗ trợ truyền tải dữ liệu tới đa điểm theo cơ chế Mutilcast.
RTP bản thân nó không hề cung cấp một cơ chế nào nhằm đảm bảo về mặt thời gian, cũng như sự đảm bảo về chất lượng dịch vụ (QoS) của các ứng dụng thời gian thực. Nhưng điều này vẫn được đảm bảo dựa trên các dịch vụ lớp dưới.
Cũng như vậy RTP không đảm bảo độ tin cậy hay thứ tự của các gói tin. Nhưng các cơ chế đảm bảo độ tin cậy và việc đảm bảo thứ tự các gói tin nhận được sẽ được đảm bảo dưới các cơ chế của lớp mạng. Số thứ tự được đánh trong khung RTP cho phép bên nhận có thể khôi phục lại thứ tự gói phía gởi, nhưng có thể nó cũng được dùng để định vị gói tin như trong quá trình giải mã tín hiệu Video. Khi đó thì việc giải mã tín hiệu Video theo thứ tự là không nhất thiết.
Tuy mục đích đầu tiên của giao thức RTP là nhằm đảm bảo cho các ứng dụng multimedia conference. Tuy nhiên các ứng dụng truyền dòng, các chương trình mô phỏng phân tán, các ứng dụng trong điều khiển, đo lường cũng nhanh chóng tìm thấy sựứng của RTP.
Khi đề cập đến giao thức RTP là chúng ta đề cập đến hai vấn đề:
- Giao thức truyền tải thời gian thực (real-time transport protocol): Với chức năng truyền tải các dữ liệu có thuộc tính thời gian thực.
- Giao thức điều khiển RCTP: Với chức năng giám sát chất lượng dịch vụ và truyền các thông tin về những phiên truyền. RTCP giúp cho việc điều khiển các phiên.
Để tìm hiểu các ứng dụng của RTP ta xét trong trường hợp cụ thể, hội thảo đa phương tiện. Đây là trường hợp rất điển hình, có thểđại diện cho các ứng dụng truyền dòng thời gian thực.
Hình 1.9: Vị trí RTP trong các ứng dụng multimedia
1.3.2 Hội thảo thoại sử dụng multicast đơn giản
Nhóm làm việc của 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 Mutilcast 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ữ liệu thoại cụ thể, cổng còn lại sẽ sử dụng để truyền tín hiệu điều khiển RCTP. Trong trường hợp cần yêu cầu bảo mật thì dữ liệu trước khi truyền qua hai cổng này sẽđược mã hoá theo chuẩn, các khoá mã cũng sẽđược sinh ra và truyền kèm theo.
Mỗi thành viên tham gia hội thoại sẽ gởi dữ liệu thoại theo từng đoạn. Những đoạn dữ liệu sẽ được gắn thêm phần RTP header. Sau đó cả phần RTP header và phần dữ liệu sẽ được đóng vào gói UDP. Phần RTP header sẽ xác định loại mã hoá tín hiệu thoại (PCM, ADPCM…..) được mang trong phần dữ liệu, vì vậy kiểu mã hoá 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 với những thành viên sử dụng đường truyền tốc độ thấp hoặc hay trong trường hợp mạng bị nghẽn.
Việc truyền các gói tin trên mạng rất có thể bị thất lạc, mất thứ tự các gói tin 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 đó phía nhận 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 sẽ giúp cho bên nhận có thể phân được các nguồn tin khác nhau trong quá trình hội thoại.
Số thứ tự của các gói tin có thể dùng để nhận biết số lượng các gói tin bị thất lạc của mỗi nguồn, kể từ khi họ tham gia hội thoại. Việc này giúp chúng ta có thểđánh giá chất lượng mạng của từng thành viện. Trong quá trình hội thoại, những bản tin thông báo có kèm theo định danh của từng thành viên sẽđược chuyển qua cổng điều sử dụng RTCP. Những thông báo này sẽ xác định các gói tin do mỗi thành viên gởi đi được nhận có tốt không. Dựa vào đó ta có thểđiều chỉnh bộ mã hoá động.
Ngoài ra việc định danh thành viên cũng như các thông tin xác định khác có thể được sử dụng đểđiều khiển giới hạn băng thông của từng thành viên.
Khi một thành viên rời khỏi hội thoại, họ sẽ gởi một gói tin RTCP Bye để thông báo.
1.3.3 Hội thảo sử dụng thoại và video
Hình 1.10: 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, ta sẽ sử dụng đồng thời hai cặp RTP/RTCP. Việc truyền tín hiệu tiếng và tín hiệu hình là hoàn toàn độc lập. Không hề có sự kết nối trực tiếp nào giữa hai quá trình này. Tuy
nhiên nếu mỗi thành viên tham gia, sử dụng 1 định danh cho cả hai tiến trình này thì phía nhận vẫn hoàn toàn có thể ghép lại được từng cặp audio/video.
Với việc truyền tách biệt này, cho phép một thành viên tham gia hội thảo thiết lập cơ chế chỉ nhận một luồng Audio hoặc Video. Việc mất đồng bộ của tín hiệu hình và tiếng sẽ được giải quyết dựa vào thông tin định thời trong các gói tin RTCP của hai luồng.
Trên đây chúng ta đã giả định tất cả các thành viên đều cùng nhận 1 dạng format cho các dữ liệu Media. Đ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 có tốc độ cao. Khi đó ta không thể bắt tất cả các thành viên cùng sử dụng truyền ở tốc độ thấp, chất lượng tín hiệu thấp. (adsbygoogle = window.adsbygoogle || []).push({});
Khi đó ta có thể sử dụng bộ trộn RTP-level mixer, đặt 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 Unicast cho một người nhận đơn, hoặc Multicast cho một nhóm người nhận. Phần RTP header sẽ đảm nhiệm việc định danh lại người gởi phía nhận. RTP-level còn có thể sử dụng để thay đổi độ phân giải của tín hiệu Video cho phù hợp với từng thành viên tham gia.
Ngoài ra chúng ta còn kểđến trường hợp, một thành viên sử dụng đường truyền tốc độ cao, nhưng họ lại không thể nhận trực tiếp các gói IP multicast. Khi đó ta sẽ phải cài đặt 2 bộ RTP-level mixer. Một được đặt phía trước firewall, một phía sau firewall.
CHƯƠNG II: KHÁI QUÁT GIAO THỨC THỜI GIAN THỰC RTP, RTCP 2.1 GIAO THỨC TRUYỀN TẢI THỜI GIAN THỰC RTP
2.1.1 MỘT SỐ KHÁI NIỆM LIÊN QUAN ĐẾN RTP:
RTP payload: Đây là phần dữ liệu được truyền trong các gói RTP. Đây có thể là các mẫu tín hiệu thoại hoặc dữ liệu Video đã được nén. Việc phân định dạng dữ liệu (được chỉđịnh bởi phần payload type) sẽđược để cập đến ở phần sau.
RTP packet: Là 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 RTP 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 1 gói lớp dưới chứa 1 gói RTP. Tuy nhiên cũng có trường hợp nhiều gói RTP được đóng vào một gói, điều này hoàn toàn phụ thuộc cách đóng gói của lớp dưới.
RTCP packet:Đây là gói tin điều khiển RTCP, có phần tiêu đề cốđịnh gần giống gói RTP. Tiếp theo đến phần có cấu trúc, dạng của cấu trúc sẽ tuỳ 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. Điều này có thể thực hiện được do các gói RCTP 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 nó là số nguyên dương 16Bit. Khái niệm Port tương đương với khái niệm TSEL (transport selectors) trong mô hình OSI. RTP dựa trên các 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:Địa chỉ này phục vụ cho việc vận chuyển dữ liệu. Nó là sự kết hợp giữa địa chỉ mạng và các cổng được định nghĩa ở tầng giao vận. Ví dụ như sự kết hợp giữa địa chỉ IP với một cổng UDP nhất định. Các gói tin sẽđược truyền từđịa chỉ Transport address nguồn tới địa chỉ Transport address đích.
RTP media type: Đây là một tập các loại tải có cùng một số tính chất được mang trong phiên truyền RTP. Trong hội thảo đa phương tiện ta có thể có hai loại RTP media type là video-MPEG2 và audio-PCMA. Cụ thể hơn về các loại RTP được trình bày trong phụ lục 3.
RTP session: Một phiên RTP có thể có sự tham gia của một tập các thành viên cùng trao đổi thông tin. 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 RCTP). 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 điểm multicast ) hoặc riêng biệt cho từng thành viên(trong trường hợp truyền điểm điểm unicast). Trong một phiên truyền Mutilmedia, các tín hiệu thành phần (video/audio) được truyền theo một cặp cổng riêng.
Hình 2.1: Mô hình phiên RTP.
Synchronization source (SSRC): nguồn phát dòng các gói RTP, được định danh bởi 32-bit SSRC trong phần header của 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 nhận 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.
Hình 2.2: Minh hoạ các nguồn đồng bộ SSRC.
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 1 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 mixer sẽ thay đổi lại các nhãn thời gian cho thích hợp cho mỗi luồng ra. Mixer khi hoạt động có vai trò như một nguồn đồng bộ.
Hình 2.3: Hoạt động của Mixer.
Contributing source (CSRC): Khi dòng các gói RTP được tổng hợp nhờ bộ Mixer. Bộ Mixer sẽ chèn một danh sách CSRC chứa các định danh SSRC của các
nguồn đã được tổng hợp. 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.
Hình 2.4: Minh hoạ việc chèn danh sách CSRC khi đi qua bộ Mixer.
End system: Mỗi ứng dụng mà sinh ra dữ liệu để truyền đi trong những gói RTP, hoặc nhận những dữ liệu này để xử lý được gọi là hệ thống cuối RTP (End system). Một hệ thống cuối này có thể tương đương với một hay nhiều nguồn đồng bộ trong một RTP session, tuỳ thuộc vào sốđịnh danh SSRC mà nó sử dụng.
Translator:Đâ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.
Hình 2.5: Translator.
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.
TimeStamp:Được sử dụng theo qui định giao thức thời gian mạng (Network Time Protocol), thời gian tính bằng số giây kể từ 0h UTC ngày 1-1-1900. Giá trị này được biểu diễn bằng 64 Bits. 32 Bits đầu biểu diễn phần nguyên, 32 Bits sau biểu diễn phần thập phân. Tuy nhiên trong một số trường hợp, người ta chỉ dùng 32 Bits giữa, khi đó sẽ cần có sự phân biệt giữa 16Bits cao của phần nguyên và 16Bits cao của phần thập phân. Với cách đánh thời gian theo NTP, đến năm 2036 nó sẽ quay trở lại giá trị zero. Tuy nhiên với các ứng dụng thời gian thực, chúng ta chỉ cần xét khoảng thời gian chênh lệch do đó với chu kỳ như vậy là hoàn toàn thoả mãn.
2.1.2 CẤU TRÚC PHẦN TIÊU ĐỀ GÓI RTP:
Cấu trúc khung phần tiêu đề gói RTP như bảng:
Bảng 2.1: Cấu trúc phần header gói RTP.
Trong phần tiêu đề của gói RTP 12 Octets đầu tiên là cố định cho mọi gói RTP. Còn danh sách CSRC chỉ _ing vào khi ta cho qua bộ Mixer. Bây giờ ta sẽ phân tích _ing năng cụ thể của _ing trường:
a. version (V): 2 bits
Trường này _ing để xác định Verson của RTP. Hiện nay trong truyền Video và Audio RTP đang sử dụng Verson 2. Verson 1 là Verson được sử dụng đầu tiên. Còn Verson 0 chỉ là giao thức _ing cài đặt thêm các _ing năng cho Audio. (adsbygoogle = window.adsbygoogle || []).push({});
b. padding (P): 1 bit
Nếu bit đệm này được đặt giá trị 1, báo rằng gói tin có chứa 1 số byte điều kiện phụ ở phần cuối (cuối phần payload). Byte cuối cùng trong các byte đệm sẽ chứa số các byte đệm đã được thêm, kể cả chính byte đó. Các byte đệm này có thểđược _ing để mã hoá mật gói tin, hoặc _ing trong trường hợp đóng gói nhiều gói RTP trong 1 gói của lớp dưới.
c. extension (X): 1 bit
Khi bit này được gán giá trị 1 tức là sau phần tiêu đề cốđịnh sẽ là phần tiêu đề mở rộng. Việc mở rộng thêm phần tiêu đề nhằm tăng thêm lượng thông tin cho gói RTP khi cần thiết.
e. CSRC count (CC): 4 bits
Phần này chứa số lượng các bộ nhận dạng CSRC sẽ được thêm vào sau phần tiêu đề cốđịnh. Dùng để xác định số các phần tử 32 bit được chứa trong phần CSRC.
f. Marker (M): 1 bit
Bit này được _ing với mục đích báo hiệu. Ta có thể _ing nó để làm sự kiện báo hiệu khung trong trường hợp ta truyền các gói tin thành dòng. Bit này có thể được sử dụng hoặc không. Nừu không sử dụng ta có thể thay đổi số lượng bit trong trường payload type.
g. Payload type (PT): 7 bits
Trường này _ing để xác định dạng _ing_t của phần tải để chọn lựa các ứng dụng phù hợp. Giá trị của phần định dạng tải này có thể cốđịnh trong một phiên RTP nếu ta