Tìm hiểu về video conferences

Video coferences là gì?

Video Conference là một phương thức thông tin liên lạc mới, được kết hợp bởi những đặc tính của công nghệ viễn thông và công nghệ thông tin nhằm đem đến cho người sử dụng nhiều tiện ích hơn một cuộc điện thoại bình thường. Về cơ bản Video Conference giống như liên lạc bằng điện thoại nhưng được bổ xung hàng loạt các tiện ích khác như:

* Những người đàm thoại có thể nhìn thấy nhau

* Cùng chia sẻ dữ liệu trên máy tính như văn bản, bảng tính, cơ sở dữ liệu

* Có thể kết nối bằng bất kỳ phương thức nào như: kênh thuê riêng (Leased-Line), ISDN hay IP (Internet Protocol

Hội nghị truyền hình (video conference) cho phép người dùng (user) ở các địa điểm khác nhau có thể tiến hành trao đổi thông tin về âm thanh và hình ảnh. Phương thức thông tin theo thời gian thực với cả 2 chiều đầy đủ. Các tín hiệu âm thanh và hình ảnh được truyền trực tiếp trên hiện trường trong thời điểm đang xảy ra và không bị một sự hạn chế nào trong việc truyền đạt theo 2 chiều. Có thể nói 2 đặc tính: hai chiều và thời gian thực cho thấy sự khác biệt của Hệ thống hội nghị truyền hình VCS (Video conferencing System) với Hệ thống truyền hình quảng bá TV (Television).

Từ những năm 60 của thế kỷ 20, hội nghị truyền hình đã được nghiên cứu và ứng dụng tại các nước tiên tiến. Đến những năm 1970 hội nghị truyền hình ứng dụng công nghệ số hóa. Đến những năm 1980, công nghệ nén hình ảnh có bước nhảy vọt, kênh truyền tín hiệu hình số ra đời không chiếm nhiều dải thông rộng như kênh truyền hình analog. Với tốc độ truyền thấp hơn 34Mbit/s, tín hiệu hình đã được nén, chất lượng của hình ảnh vẫn thỏa mãn nhu cầu của người dùng. Từ những năm 1990 đến nay công nghệ máy tính và mạng Internet phát triển rất nhanh và có ảnh hưởng tới hệ thống hội nghị truyền hình.

Sơ đồ tổ chức một hội nghị truyền hình

Dưới đây chúng ta xét sơ đồ khối của hệ thống hội nghị truyền hình digital, của hội nghị có một số đại biểu ở địa điểm xa. Hình 1 là sơ đồ khối điển hình.

Thiết bị điều hành trung ương (CCU) thực hiện việc quản lý và điều hành toàn bộ hệ thống hội nghị truyền hình. Chức năng của CCU gồm có: điều khiển các micro, cung cấp các tư liệu và hiển thị phương thức biểu quyết...

Trong hội nghị, vị chủ tịch nắm quyền tối cao điều khiển cuộc họp và các diễn tiến của nó.

Máy chủ tịch gồm máy vi tính PC có màn hiển thị LCD, một bàn phím điều khiển micro ưu tiên. Trong hội nghị, nếu vị chủ tịch ấn nút của micro nào thì micro của đại biểu đang phát ngôn bị cắt tạm thời. Máy chủ tịch có thể khởi động, đình chỉ hội nghị hoặc lấy biểu quyết. Qua vị chủ tịch còn có thể cho hiển thị các tư liệu lên màn hình để hội nghị tham khảo.

Máy đại biểu là phương tiện để các đại biểu phát ngôn, yêu cầu đăng ký phát ngôn và nghe đại biểu khác phát ngôn hoặc biểu quyết. Kết quả biểu quyết thông qua thiết bị CCU tổng hợp sau đó hiển thị lên màn hình.

Trong hội nghị truyền hình quốc tế có nhiều đại biểu dùng ngôn ngữ khác nhau thì máy đại biểu cũng có chức năng chọn ngôn ngữ phiên dịch thích hợp.

Ngoài ra hệ thống CVS còn có giao diện multimedia audio, video. Thông qua giao diện này, các tin tức và dữ liệu của hội nghị đưa tới các thiết bị analog như truyền hình quảng bá hoặc phát thanh quảng bá.

<center>Hình 1</center>

Tín hiệu giữa các thiết bị trên được thực hiện qua dây cáp. Trong phòng hội nghị, tín hiệu video được ghi bằng camera và hiển thị lên màn hình cỡ lớn. Thiết bị điều khiển CCU điều khiển các camera di chuyển đến các vị trí thích hợp để ghi toàn bộ hình ảnh của hội nghị. Sau đó đưa lên màn hiển thị. Trường hợp có một số ít đại biểu tại địa điểm xa thì có thiết bị thu phát vô tuyến điện liên lạc song công với các đại biểu đó.

Đặc điểm của hệ thống hội nghị truyền hình và các khuyến nghị về tiêu chuẩn hội nghị truyền hình quốc tế

Sơ đồ khối như hình 1 cho biết cơ cấu tổ chức một hội nghị truyền hình đơn giản nhất. Trong hội nghị truyền hình có nhiều đại biểu ở các địa điểm cách xa nhau thì việc truyền tín hiệu cần có nhiều khâu xử lý như mã hóa và bảo mật.

Khác với truyền hình quảng bá, trong hệ thống hội nghị truyền hình, tốc độ biến đổi của hình ảnh tương đối chậm. Thông qua dự đoán tương quan giữa dòng và mành, người ta thực hiện phương pháp mã hóa biến đổi cosin rời rạc DCT (Discret Cosine Transform) kết hợp với điều xung mã vi sai DPCM (Differential PCM) đồng thời nén tín hiệu ảnh và truyền với tốc độ thấp hơn 2Mbit/s. Trên thực tế với tốc độ 384kbit/s các người dùng cũng đủ nhận được các hình ảnh động.

Một số hệ thống VCS còn dùng các thuật toán để giảm thấp tốc độ của hình ảnh động để tiết kiệm được các kênh tín hiệu. Như trên đã nói, từ năm 1990, hội nghị truyền hình đã phát triển trên toàn cầu, do đó ITU đã đưa ra một số khuyến nghị giải quyết các vấn đề nghiệp vụ cho hội nghị truyền hình quốc tế. Trong đó khuyến nghị H.261 là quan trọng nhất.

Khuyến nghị này thống nhất các thuật toán mã hóa xác định tốc độ mã hóa là P lần 64kbit/s, với P = 1 - 30. Khuyến nghị H.261 còn quy định các quy cách mã hóa thông dụng trong tiêu chuẩn truyền hình CIF của Tây Âu và Mỹ, Nhật để có thể tương thích với nhau. Như vậy hệ thống hội nghị truyền hình VCS "mở" hoặc có ghép nối với mạng viễn thông quốc gia hoặc quốc tế thì cần phải thỏa mãn các tiêu chuẩn, các quy định truyền dẫn thông tin cũng như phương thức bảo mật.

Hiện nay hệ thống VCS có hệ thống truyền thông trên mạng cáp điện, cáp quang, viba và mạng máy tính. Người sử dụng có thể tiếp nhập vào mạng HDSL hoặc ADSL. Cùng với sự phát triển của mạng máy tính IT, Hội nghị truyền hình có bước phát triển nhảy vọt. Việc kết hợp giữa mạng VCS với mạng Internet đã tập hợp được tài nguyên thông tin và các công cụ thông tin một cách có hiệu quả.

Sự hội tụ video và điện thoại IP

Hệ thống hội nghị truyền hình như sơ đồ khối hình 1 ở trên chỉ là mẫu đơn giản của hội nghị truyền hình. Nó có tên gọi là hội nghị truyền hình từ phòng đến phòng (room to room video conferencing)...

Sự phát triển của điện thoại IP đã cung cấp cơ sở hạ tầng để tín hiệu video trở thành một phần tử hoàn toàn tích hợp trong môi trường điện thoại. Nói một cách khác điện thoại IP tích hợp mạng thoại và mạng dữ liệu vào một mạng mạnh hơn có băng tần đủ rộng để sử dụng chương trình ứng dụng video. Ta đã tạo ra một lớp mạng (networking layer) để có thể sáp nhập luồng video vào trong cơ cấu chuyển vận. Nhờ vào điện thoại IP, ta thiết lập các cuộc họp có thể chứa nhiều luồng đa phương tiện. Như vậy ta chỉ dùng một cái click kích thích để thiết lập cuộc hội nghị truyền hình giữa các đối tác.

Chương trình ứng dụng trong điện thoại IP được gọi là chương trình thoại mềm (soft phone applications). Sử dụng soft phone applications người dùng tại bàn làm việc (desktop) thiết lập một cuộc hội nghị truyền hình để biết xem người đang liên lạc có sẵn sàng với cuộc gọi truyền hình (video call) chưa.

Tóm lại sự hội tụ công nghệ video và IP telephone đã làm cho desktop video telephony thành hiện thực. Tại các nước phát triển, hệ thống hội nghị truyền hình VCS kết hợp với IP Telephoy được sử dụng rộng rãi trong các xí nghiệp. Trong hội nghị giữa chủ và thợ, những hình ảnh tương tác làm cho cuộc họp được tập trung hơn, có hiệu quả và ngắn gọn hơn, sớm thống nhất được quyết định. Hội nghị truyền hình VCS kết hợp với IP Telephony cũng mở rộng cho các cuộc giao lưu giữa các cá nhân như trong trường học, siêu thị...

Việc tổ chức một cuộc hội nghị video telephony cũng đơn giản như tổ chức gọi điện thoại. Ta có thể tổ chức theo 3 phương thức:

- Desktop video - dùng IP Soft Phone hoặc Hardphone truyền thông có kèm theo video bằng cách ấn nút.

- Conference Room Video - tổ chức cuộc gọi giữa một nhóm người.

- Multi point video. tổ chức hội nghị có hình giữa các người dùng đang ở tại các địa điểm cách xa nhau.

Hình 2 minh họa cuộc họp được thiết lập trên giữa các người dùng

Hình 2

Bước 1. Cô M muốn nói chuyện với tổ của cô thông qua thiết bị điều khiển MCU

Bước 2. Ông J trong văn phòng dùng IP Soft phone tiếp nhận cuộc gọi.

Bước 3. Các thành viên của tiếp nhận cuộc gọi của cô M. Cuộc họp diễn ra trong phòng lớn.

Trên hình ta thấy bộ quản lý trung tâm CM, ghi nhận của các người dùng IP đăng ký và sử dụng khả năng bắc cầu để nối các user vào hội nghị.

Hình ảnh minh hoạ về hội nghị truyền hình trực tuyến

Do những tiện ích rất ưu việt như đã kể trên nên Video Conference được ứng dụng trong rất nhiều ngành kinh tế, xã hội cũng như an ninh, quốc phòng. Phổ biến nhất Video Conference được ứng dụng trong hội họp từ xa giúp những người tham gia không tốn thời gian đi lại mà vẫn có thể gặp mặt nhau, hơn nữa lại tiết kiệm nhiều chi phí khác. Có thể kể ra một vài ứng dụng của Video Conference như:

* Hội họp, giao ban từ xa

* Đào tạo từ xa

* Khám, chuẩn đoán bệnh từ xa, tư vấn sức khoẻ

* Tham mưu, tác chiến từ xa

* ...v.v

Vì sao cần lắp đặt Hệ thống này:

Với mỗi lĩnh vực, dịch vụ Hội nghị Truyền hình luôn là lựa chọn số một khi khoảng cách giữa các điểm liên lạc với nhau là khá xa, không thuận lợi cho việc đi lại để trực tiếp gặp mặt nhau trao đổi công việc. Dịch vụ Hội nghị Truyền hình đặc biệt hiệu quả trong việc giảng dạy và đào tạo trực tuyến từ xa.

Ngày nay, với sự phát triển mạnh mẽ của Công nghệ thông tin - Viễn thông, đã có khá nhiều giải pháp cho dịch vụ Hội nghị Truyền hình. Tuy nhiên với cơ sở hạ tầng mạng tại Việt Nam hiện nay thì các giải pháp phù hợp và khả thi cho Hội nghị Truyền hình là giải pháp dựa trên công nghệ IP và giải pháp dựa trên công nghệ ISDN.

Lợi ích của việc lắp đặt hệ thống này:

Dịch vụ này cung cấp khả năng truyền hình ảnh, âm thanh trực tuyến giữa nhiều điểm trên mạng, giúp tăng cường khả năng tương tác, trao đổi giữa các thành viên trong hội nghị

Tiết kiệm được thời gian và chi phí nhưng công việc vẫn hiệu quả

Truyền giọng nói qua Internet là công nghệ gọi điện thoại rẻ tiền đang được cá nhân và doanh nghiệp dần dần chấp nhận sử dụng rộng rãi. Khác với đường dây điện thoại thông thường, hệ thống VoIP có thể kết hợp hình ảnh video và giọng nói để tổ chức các cuộc hội nghị từ xa.

Trong công nghệ VoIP, tín hiệu thoại sau khi nén xuống tốc độ thấp được đóng gói lại để truyền đi trong mạng chuyển mạch gói. Có nhiều cách thức đóng gói tín hiệu thoại để truyền trong mạng IP. Một trong những cách thức được áp dụng nhiều nhất là bộ giao thức RTP/RTCP nhờ tính linh hoạt và khả năng giám sát trạng thái dòng thông tin một cách hiệu quả của nó.

Các lĩnh vực có thể áp dụng dịch vụ này:

Hội nghị, giao ban, trao đổi công việc của các đơn vị có vị trí địa lý cách xa nhau

Dạy và học trực tuyến từ xa theo mô hình học trên mạng (E-Learning)

Chăm sóc y tế từ xa: người bệnh có thể được khám bệnh, chẩn đoán hay thậm chí phẫu thuật gián tiếp từ các chuyên gia y tế tại những nơi rất xa

Các công việc và lĩnh vực yêu cầu trao đổi thông tin, hình ảnh, âm thanh thời gian thực khác.

Kết luận:

Hội nghị truyền hình là sự hoạt động tương tác giữa tín hiệu audio, video trong thời gian thực. Hệ thống hội nghị truyền hình đã được ứng dụng rộng rãi trong các trường đại học, các xí nghiệp, các trung tâm thương mại. Sự hội tụ của công nghệ hạ tầng kiến trúc và phần mềm ứng dụng cho phép Desktop video conferencing sẽ được dùng rộng rãi với phần mềm áp dụng đơn giản và tiện dụng. Video Conferencing cũng cải thiện mối quan hệ công tác, tăng nhanh hiệu quả sản xuất, kinh doanh dẫn tới các quyết định nhanh chóng giữa các thành viên hội nghị

Tim hieu ve giao thuc rtp va giao thuc rtcp .2 giao thuc chinh duoc su dung trong dich vu video conferences

Day la 2 giao thuc nam o tang ung dung trong mo hinh osi 7 tang

1.1 Giao thức truyền dữ liệu thời gian thực RTP

- RTP cung cấp chức năng mạng vận chuyển end-to-end cho những ứng dụng truyền dữ liệu mà yếu cầu thời gian thực (real-time) như là âm thanh và video. Những chức năng đó bao gồm nhận diện loại dự liệu, số trình tự, tham số thời gian và giám sát tiến trính gởi.

- RTP là thành phần quan trọng của VoIP bởi vì nó cho phép thiết bị đích sắp xếp và điều chỉnh lại thời gian cho gói tin thoại trước khi được gởi đến người dùng. Một header RTP chứa tham số thời gian và số trình tự nhằm để cho thiết bị nhận lưu vào bộ nhớ đệm, khử jitter và góc trể (lacency) bằng cách đồng bộ những gói tin để phát lại (playback) dòng âm thanh liên tục. RTP dùng số trình tự chỉ đế sắp xếp lại thứ tự gói tin. RTP không yêu cầu sự truyền lại nếu một gói tin bị mất.

- Ví dụ: Như những gói thoại khi được gởi đến đích, chúng có thể đi trên những con đường khác nhau để đến đích, mội con đường có thể khác nhau vế khảong cách, tốc độ truyền, kết quà là gói tin đến không đúng thứ thự khi chúng đến đích. Khi ở nguồn tạo ra cuộc gọi, dữ liệu thọai sẽ được đóng gói lại, RTP sẽ gắn vào những gói tin với tham số thời gian và số trình tự và gởi đi. Ở dích dên, RTP sẽ sắp xếp những gói tin và gởi chúng đến bộ xử lý tín hiệu số (digital signal processor-DSP) ở cùng tốc độ khi chúng được gởi đi ở nguồn gọi.

- Cau truc Rtp

1.1.1 Tiêu đề RTP

Cấu trúc của header :

Payload type

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. Toàn bộ danh sách trong chuẩn MIME được lưu trực tuyến tại địa chỉ http://www.iana.org/assignments/media-types.

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 dang đượ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ư sau:

v=0

o=bloggs 2890844526 2890842807 IN IP4 10.45.1.82

s=-

[email protected](Joe Bloggs)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

m=audio 49170 RTP/AVP 0

m=video 51372 RTP/AVP 98

a=rtpmap:98 H263-1998/90000

Ví dụ trên mô tả 2 phiên RTP, audio được gửi tới một nhóm IPv4 multicast 224.2.17.12 qua cổng 49170, Time-To-Live là 127, video được gửi tới cùng nhóm multicast nói trên qua cổng 51372. Cả audio và video đều sử dụng giao thức RTP/AVP làm giao thức chuyển vận.

Sequence number

Là số không dấu 16 bit 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)

Timestamp

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,đựoc dùng để đặt lịch của dữ liệu media

Nhãn thời gian là số nguyên 32 bit 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

SSRC

Được sử dụng để định danh các bên tham gia trong một phiên RTP. Giá trị của nó chỉ có ý nghĩa trong một phiên và đượ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 bit 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ị này. Những xung đột kiểu như vậy có thể được phát hiện khi một ứng dụng nhận được một gói từ một bên tham gia khác có số SSRC trùng với số 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.

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 bit 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.

Maker

Bit đá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, bit 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. Bit 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, bit 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. Bit 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, bit 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 bit Marker bị mất.

Version

Mỗi gói RTP chứa một số chỉ phiên bản hiện hành của RTP là trường V trong header RTP. Phiên bản hiện thời là 2, phiên bản cũ không còn được sử dụng rộng rãi. Mục đích duy nhất của trường này là kiểm tra tính hợp lệ của gói.

Padding

Bit Padding trong header RTP được sử dụng để chỉ thị rằng có một đoạn dữ liệu bổ sung ở phía sau dữ liệu chính. Khi bit P được đặt bằng 1, octet cuối cùng của phần dữ liệu sẽ chỉ kích thước (số lượng octet) của phần dữ liệu bổ sung. Phần dữ liệu bổ sung này ít khi được sử dụng nhưng đôi khi cần thiết trong một số phương thức mã hóa, sửa lỗi hoặc để điều chỉnh kích thước gói cho phù hợp với dung lượng kênh.

Header extension

RTP cho phép một phần header mở rộng được báo hiệu bằng bit X trong header RTP. Khi bit 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, chiều dài của header này không cố định nhưng đều bắt đầu bằng 16 bit chỉ kiểu và 16 bit chỉ chiều dài (không bao gồm 32 bit 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.

1.1.2 Tải dữ liệu của RTP cho h264

Chế độ đóng gói

Chế độ đóng gói của các slice vào các NAL unit:

• Single Nal unit mode

• Non-interleaved mode

• Interleaved mode

Bảng các loại NAL unit đựoc cho phép với mỗi chế độ đóng gói (yes=allowed, no=disallowed, ig=ignore)

Single NAL unit

Single NAL unit chỉ chứa duy nhất 1 NAL unit ở bên trong điều nay có nghĩa là không có 1 FU hoặc gói tổng hợp đựuoc sủ dung bên trong 1 gói Single NAL uniit

Một luồng NAL unit được tạo bởi việc mở gói Single NAL unit theo thứ tự của số RTP phù hợp với trật tự mã hoá của NAL unit

Cấu trúc của Single NAL unit

Single time aggregate packet(STAP)

STAP là gói có giá trị NAL là 24,chứa nhiều NAL unit bên trong với 1 nhãn thời gian xác định.STAP chia làm 2 loại:

STAP-A: không chứa DON(decoding order number)

STAP-B: có chứa DON

STAP và MTAP có luật đóng gói chung:Nhãn thời gian RTP phải đựoc đặt là thời gian sớm nhất của NAL unit trong các NAL unit đựoc đóng gói

Bít F đựoc đặt là 0 khi tất cả các gói NAL unit đựoc ghép đều có bit F là 0, còn lại thì đật là 1.Giá trị của NRi lá giá trị lơn nhất của tất cả các NAL đựoc mang trong gói tổng

Maker bit trong header của RTP được đặt giá trị của maker bit của NAL unit trong gói tổng sẽ có nếu nó được truyền trong chính gói RTP của nó

Trong gói STAP có 1 số 16 bit không dấu chỉ độ dài của NAL unit theo sau nó kể cả header

Riêng trong các gói STAP-B có DON dùng

STAP A

Byte đầu tiên của RTP payload chứa các thông tin về loại dữ liệu,,về mức độ ưu tiên khi truyền gói dữ liệu.Trước mỗi NAL unit đều có 1 số nguyên không dấu 16 bit chứa thông tin về độ dài của NAL unit theo sau đó.Các NAL unit chứa trong gói tổng hợp thì đều có cùng NAL unit

STAP B

Cấu trúc của STAP-B chỉ khác với STAP-A ở DON(decoding order number):conf lại giống với STAP-A

Multi time aggregate packet(MTAP)

Gói tổng hợp MTAP thì chứa các NAL unit có thời gian khác nhau.Trong đó

MTAP NAL header chứa các thông tin về loại dữ liệu chứa trong gói

DONB(decoding order number base) chứa thông tin về DON của NAL unit đầu tiên trong trật tự giải mã NAL unit.Tuy nhiên gói NAL unit đầu tiên không nhất thiết là NAL unit đầu tiên được đóng gói trong gói MTAP

NAL unit size là số nguyên 16 bit chứa độ dài của NAL unit theo sau đó

NALU DOND là là số nguyên không dấu 8 bit ,là giá trị lệch so với DONB=>DON =(DOND+DONB)%65536

Do sự khác nhau về giá trị của độ lệch thời gian :16 bit nguyên không dấu và 24 bit nguyên không dấu.Cho nên có 2 loại gói MTAP : M.TAP 16 và MTAP 24.

Độ lệch thời gian của các NAL unit được tính so với thời gian của NAL unit sớm nhất ,và được tính theo công thức sau

Nếu NALU-time lớn hơn nhãn thời gian của RTP thì timestamp offset =(NALU-time của NALU - RTP timestamp)

Nếu NALU-time nhỏ hơn nhãn thời gian của RTP thì timestamp offset =(NALU-time của NALU +(2^32 -RTP timestamp))

Độ lệch thời gian của gói NALU sớm nhất (so với các NALU trong gói tổng hợp)phải là 0

MTAP 16

MTAP 24

Fragmentation Unit(FU)

Việc phân đoạn (fragmentation) chia các NALU có kích thước lớn thành các phần nhỏ để thch hợp với việc truyền gói đi trên mạng.Phân đoạn chỉ được định nghĩa cho NAL đơn(single NALU)

Các phân đoạn của cùng NAL unit phải được gửi theo trật tự liên tiếp với việc tăng số thứ tự (sequnce number )của gói RTP (không có gói RTP khác bên trong luồng RTP đấy được gửi giữa đoạn đầu tiên và đoạn cuối cùng)

Cấu trúc của các octet của đầu tiên của gói FU:

FU indicator: giá trị trong trường F,NRI,type được định nghĩa giống trong trường F,NRI ,type của NALU header.Giá trị trong trường type là 28 hoặc 29

Do đó có 2 loại gói FU :có DON và không có DON

FU header:

S : được đặt là 1 khi phân đoạn là phân đoạn bắt đầu của NALU,các phân đoạn còn lại thì được đặt là 0

E : được đặt là 1 khi phân đoạn là phân đoạn kết thúc của NALU,các phân đoạn còn lại của cùng NALU thì được đặt là 0

R : bít ngược thường được đặt là 0

Type (5 bit): loại NALU được phân đoạn

Chú ý :

Nếu 1 phân đoạn bị mất thì bên thu huy tất cả FU phía sau (của cùng NALU)theo trật tự truyền.Tuy nhiên bên thu có thể tổng hợp (N-1) gói đầu tiên của 1 NALU thành một NALU không hoàn chỉnh và lúc đó bit F của NALu header được đặt là 1 để thông báo lỗi

FU-A

FU-B

-

1.2 Giao thức điều khiển luồng RTCP

RTCP(Real-Time Transport Control Protocol)

- RTCP giám sát chất lượng của quá trình phân phối dữ liệu và cung cấp tiến trình điều khiển thông tin. RTCP cung cấp thông tin phản hồi dựa theo điều kiện của mạng:

- RTCP cung cấp cơ chế cho những thiết bị liên quan trong phiên (session) RTP trao đổi thông tin về giám sát và điều khiển phiên. RTCP giám sát chất lượng của các yếu tố như là đếm gói (packet count), mất gói, độ trễ, jitter. RTCP truyền gói bằng 1% băng thông của phiên, nhưng ở một tốc độ xác định trong ít nhất mỗi 5 giây.

- Tham số thời gian Network Time Protocol(NTP) dưa vào các xung được đồng bộ. Tham số thời gian RTP tương ứng thì được tạo ngẫu nhiên và dựa vào tiến trính lấy mẫy gói dữ liệu. Cả hai NTP và RTP thì được đặt trong gói RTCP bởi người gởi dữ liệu.

- Ví dụ ứng dụng RTCP:

Trong suốt mỗi cuộc gọi RTP, những gói thông báo thì được tạo ít nhất mỗi 5 giây. Trong điều kiện mạng có chất lượng kém, một cuộc gọi có thể bị ngưng kết nối do lượng lớn gói bị mất. Khi xem xét những gói tin qua hệ htống phân tích gói, người quản trị có thể kiểm tra thông tin trong header của RTCP mà bao gồm số lựng gói mất, jitter....

Giao thức điều khiển RTCP gửi các thông tin phản hồi từ bên nhận một cách tuần hoàn, các thông tin đó bao gồm phản hồi về chất lượng, xác nhận các bên tham gia, thông tin mô tả nguồn, cảnh báo về sựthay đổi về các thành viên trong phiên, và các thông tin vềđồng bộ các luồng. Cấu trúc của gói điều khiển RTP được thể hiện trong Hình 26.

Hinh - Cấu trúc gói điều khiển RCTP

Version (V):

Kích thước 2 bit luôn có giá trị bằng 2 thể hiện phiên bản của RTP. Do hiện chưa có kế hoạch cho việc phát triển các phiên bản tiếp theo và các phiên bản cũ không còn sử dụng rộng rãi.Thường được sử dụng để kiểm tra tính hợp lệ của gói.

Padding (P):

bit P được đặt bằng 1 khi có một hay nhiều octet được bổ sung vào cuối gói, octet cuối cùng lưu thông tin về sốlượng octet được bổ sung. Mục đích sử dụng tương tựnhư trong gói RTP. Sử dụng sai bit P có thể gây ảnh hưởng tới hoạt động của giao thức RTCP.

Item count (IC):

Một số kiểu gói RTCP chứa một danh sách các phần tử. Trường này được sử dụng để chỉ sốlượng phần tửđược đặt trong gói. Số phần tử tối đa là 31, nếu cần hơn 31 phần tử thì cần tạo ra nhiều gói RTCP. IC có thể bằng 0, nghĩa là gói không chứa phần tử nào. Các kiểu gói không sửdụng đến sốlượng phần tử có thểdùng trường này vào mục đích khác.

Packet type (PT):

chỉđịnh kiểu thông tin chứa trong gói. Có 5 kiểu gói chuẩn được định nghĩa trong đặc tả của RTP. Các kiểu khác có thểđược định nghĩa trong tương lai.

Chiều dài (length):

Chỉchiều dài của phần dữ liệu theo sau phần header chung. Đơn vị của nó là 32 bit (4 octet) bởi kích thước của gói RTCP luôn là số nguyên lần của 32 bit. Giá trịđộ dài có thể bằng 0 nghĩa là gói chỉ chứa 4 octet header.

Theo sau header RTCP là phần dữ liệu và phần dữ liệu bổ sung nếu có.

Gói RTCP không bao giờđược truyền đi một cách riêng lẻ, thay vào đó chúng luôn được gộp lại với nhau tạo thành một nhóm gói (compound packets) để cùng truyền đi. Mỗi nhóm gói được đặt trong một gói ở lớp thấp hơn, thông thường là gói UDP/IP để truyền đi. Nếu nhóm gói được mã hóa, nhóm gói sẽ bắt đầu bằng một trường 32 bit có giá trị ngẫu nhiên.

1.2.1 RTCP RR: Receiver Reports

Một trong những chức năng chủ yếu của RTCP là ghi nhận về chất lượng đường truyền, chức năng này được thực hiện thông qua gói RR được gửi bởi tất cả các bên tham gia có nhận dữ liệu.

Cấu trúc một gói RR được thể hiện qua Hình 28. Một gói RR có thông tin về kiểu gói là 201, ngoài ra nó còn chứa số SSRC của bên tham gia đã gửi gói RR này và theo sau đó là các khối báo cáo nếu có được định lượng bằng trường RC.

Mỗi khối thông tin mô tả vềchất lượng dữ liệu nhận của một bên tham gia đang nhận dữ liệu RTP trong quá trình báo cáo. Tổng số có thểcó đến 31 khối báo cáo trong một gói RR. Nếu có hơn 31 bên tham gia trong phiên thì cần phải tạo ra nhiều gói RR và gộp chúng vào trong một nhóm gói. Mỗi khối thông tin có 7 trường và có kích thước tổng cộng là 24 octet.

Loss fraction: Tỷ lệ gói bị mất mát là số gói bị mất trong một chu kỳ báo cáo chia cho sốgói được mong đợi. Giá trị về jitter là một giá trịước lượng từ thống kê về sựthay đổi thời gian truyền trong mạng của các gói dữ liệu RTCP được gửi từ bên tham gia.

Last sender report (LSR) timestamp: nhãn thời gian báo cáo lần gửi cuối cùng của SR là một trường chứa 32 bit trong 64 bit NTP (Network Time Protocol) là thời điểm gói SR (Sender Report) gần đây nhất nhận được từ một bên tham gia có số nhận dạng SSRC. Nếu không nhận được gói SR nào thì trường này được đặt bằng 0.

Delay since last sender report (DLSR): Độ trễ tính từ lần gửi gói SR cuối, tính theo đơn vị1/65536 giây, là độ trễ giữa thời điểm nhận được gói SR gần đây nhất từ một bên gửi có số nhận dạng SSRC và thời điểm gửi khối báo cáo này. Nếu không có gói SR nào được nhận từ bên gửi có số nhận dạng SSRC thì DLSR được gán bằng 0.

Thông tin phản hồi chất lượng từ gói RR rất hữu ích không chỉđối với bên gửi mà với cả các bên tham gia khác và với một số công cụđo lường khác. Những thông tin này cho phép bên gửi điều chỉnh phương thức truyền dữ liệu hợp lý. Ngoài ra các bên tham gia khác cũng có thểxác định được các vấn đề xảy ra là do bản thân nó hay là vấn đề chung của các bên nhận khác, và các hệ thống quản lý mạng cũng có thể sử dụng thông tin này đểđánh giá hiệu năng của mạng.

Bên gửi cũng có thể sử dụng các giá trịLSR và DLSR để tính toán thời gian truyền từ nó với mỗi bên nhận. Tỷ lệ mất mát được sử dụng để lựa chọn định dạng media và phương thức sửa lỗi. Trường jitter thường dùng để phát hiện tắc nghẽn.

1.2.2 RTCP SR: Sender Reports

Ngoài việc sử dụng các thông tin phản hồi chất lượng từ các bên nhận, RTCP còn tạo ra các gói SR là các gói gửi bởi bên tham gia vừa thực hiện gửi dữ liệu. SR cung cấp thông tin về luồng dữliệu được gửi, chủ yếu phục vụ cho mục đích đồng bộ các luồng dữ liệu ở bên gửi (ví dụ đồng bộ hình và tiếng). Cấu trúc của một gói SR thể hiện trên Hình 29.

Mặc dù nhãn thời gian NTP trong gói SR sửdụng định dạng chuẩn của NTP tuy nhiên đồng hồ lại không được đồng bộ với Network Time Protocol hay một thứ gì đóchính xác, ổn định. Nếu bên nhận cần đồng bộ giữa các luồng media, các luồng này cần có chung đồng hồ.

RTP timestamp tương tự với NTP timestamp nhưng mục đích của nó là để chỉcác đơn vị của đồng hồ media RTP. Giá trị này nói chung không giống giá trị RTP timestamp của gói dữ liệu bởi đôi khi có những khoảng thời gian trôi đi từ lúc dữ liệu trong gói được lấy mẫu.

Sender's packet count: là số gói dữ liệu màmột bên gửi tạo ra kể từlúc bắt đầu phiên.

Sender's octet count: là số octet chứa trong phần dữ liệu của các gói dữ liệu nói trên (không bao gồm header và dữ liệu bổ sung).

Các trường packet count và Octet count sẽđược xác lập lại khi bên gửi thay đổi số nhận dạng SSRC (ví dụkhi xung đột SSRC). Các trường này cho phép các bên nhận tính toán tỉ lệ dữ liệu trung trình của nguồn gửi.

Nhờ các thông tin từ gói SR mà các ứng dụng có thể tính toán tỷlệ dữ liệu trung bình và tỷ lệ gói trung bình trong một khoảng thời gian mà không cần nhận dữ liệu. Tỷ số giữa hai thành phần trên gọi là kích thước tải tin trung bình. Nếu cho rằng các gói bị mất mát không phụ thuộc vào kích thước gói thì số gói nhận được bởi từng bên nhận nhân với kích thước tải tin trung bình là lưu lượng tới bên nhận đó.

Giảm kích thước header với CRTP

- Tương ứng với nhiều số lượng giao thức cần thiết để vận chuyển thoại qua một mạng IP, thì header của gói tin có thể lớn. Dùng CRTP (Compression RTP) trên những liên kết link-by-link để tiết kiệm băng thông.

- Dùng CRTP nén header IP/UDP/RTP từ 40 byte xuống còn 2 byte với không có checksum và từ 40 byte xuống 4 byte nếu có checksum. Nén header RTP thì rất có ích trong trường hợp kích cỡ dữ liệu của RTP là nhỏ, ví dụ như dữ liệu âm thanh sẽ được nén trong khoảng 20 và 50 byte.

- CRTP làm việc dựa vào giả thiết đó là hầu hết tất cả các trường trong header IP/UDP/RTP là không thay đổi hay sự thay đổi có thể nhân biết được. Những trường không thay đổi bao gồm địa chỉ nguồn-đích của IP và số cổng nguồn-đích của UDP, cũng như những trường khác trong tất cả 3 header.

- Ví dụ về CRTP: Trong môi trường thoại dựa vào gói tin thì khi giọng nói lấy mẫu được đóng khung (framing) mỗi 20 ms, phần dữ liệu 20 byte được tạo. Không có CRTP, kích thuớc gói bao gồm những thành phần sau:

• IP header (20 byte)

• UDP header (8 byte)

• RTP header (12 byte)

• Dữ liệu (20 byte)

Header là hai lần kích thước của dữ liệu: IP/UDP/RTP (20+8+12=40 byte) trong khi phần dữ liệu là 20 byte. Khi tạo những gói tin mỗi 20 ms trên liên kết có tốc độ chậm, phần header chiếm phần lớn băng thông.

Lưu ý khi dùng CRTP để nén header

Nên cấu hình RTCP trên những cổng giao tiếp có những điều kiện sau;

• Trên những liên kết có băng tần hẹp

• Liên kết tốc độ thấp (<2Mbps)

• Cần tiết kiệm băng thông trên những cổng giao tiếp WAN.

Nén hoạt động trên những liên kết link-by-link, kích hoạt nén trên cả hai đầu cuối của liên kết serial có băng thông thấp có thể tiết kiêm rất nhiều băng thông nếu như có số lượng lớn traffic RTP trên liên kết serial đó. Tuy nhiên, nén có thể yêu cầu phải xử lý nhiều sẽ gây ra tình trạng tiêu hao tài nguyên sẵn dùng trên các thiết bị.