GIAO THỨC IGMP TRONG IPTV
IGMP là gì?
IGMP (Giao thức Quản lý Nhóm Internet) là giao thức truyền thông dùng để thông báo cho các bộ định tuyến rằng một máy trạm muốn nhận luồng multicast Khi một máy trạm tham gia vào một nhóm multicast, nó được xác định bởi một địa chỉ IP lớp D, trong khoảng từ 224.0.0.0 đến 239.255.255.255.
Địa chỉ 239.255.255.255 được sử dụng cùng với các thiết bị thu khác trong cơ chế MPR (Multicast Routing Protocol), chỉ hoạt động trên các thiết bị định tuyến Khi một máy trạm yêu cầu nhận một luồng multicast, các thiết bị định tuyến trong mạng sẽ quyết định cách xử lý yêu cầu đó, đảm bảo rằng host sẽ nhận được luồng mong muốn.
IGMP sử dụng hai loại bản tin cơ bản là Report và Query để quản lý các hoạt động tiêu chuẩn Các host gửi bản tin Report để tham gia hoặc rời khỏi một nhóm multicast Đồng thời, một host cũng nhận bản tin Query từ thiết bị định tuyến, bất kể host có mong muốn tham gia nhóm multicast hay không.
IGMP đã trải qua quá trình phát triển từ phiên bản 1 (IGMPver1) đến phiên bản 2 (IGMPver2) và cuối cùng là phiên bản 3 (IGMPver3) Các thông điệp IGMP được truyền tải trong gói tin IP với trường số giao thức (protocol number) là 2, và trường TTL (time to live) được thiết lập với giá trị bằng 1.
Ứng dụng
- Thông báo cho router multicast rằng có một máy muốn nhận multicast traffic của một nhóm cụ thể
Router thông báo về việc có một máy muốn rời nhóm multicast thông qua giao thức IGMP Giao thức này giúp router duy trì thông tin cho từng cổng, xác định các nhóm multicast mà router cần chuyển tiếp và danh sách các host muốn nhận dữ liệu.
IGMP là giao thức cơ bản trong hệ thống IPTV, cho phép người dùng đăng ký và chuyển đổi giữa các kênh truyền hình đa hướng Địa chỉ IP của các dòng truyền tải thông tin đa hướng hoạt động trên mạng LAN và WAN, thường được định tuyến trong mạng lõi thông qua giao thức PIM Điều này đảm bảo sự phân bổ chính xác của các kênh truyền hình từ nguồn phát sóng đến tay khách hàng.
Phiên bản và hoạt động của IGMP
Hiện nay, có ba phiên bản IGMP: Phiên bản 1 xác định các thành viên nhóm thông qua quá trình truy vấn và báo cáo Phiên bản 2 mở rộng từ phiên bản 1 với việc bổ sung cơ chế querier và cơ chế rời khỏi nhóm cho các thành viên Phiên bản 3 tiếp tục mở rộng từ phiên bản 2, cho phép các host chỉ định nguồn multicast mà họ muốn hoặc không muốn nhận dữ liệu Các router multicast hoạt động dựa trên các phiên bản IGMP này.
Nhóm 18 9 mới hơn có thể xác định được những bản tin IGMP gửi từ các host chạy phiên bản cũ hơn, mặc dù mỗi phiên bản thì message có những format khác nhau
Tất cả các phiên bản IGMP đều hỗ trợ multicast từ bất kỳ nguồn nào (ASM), trong khi IGMP phiên bản 3 có thể được áp dụng trực tiếp cho multicast nguồn cụ thể (SSM) Mặc dù IGMP phiên bản 1 và 2 cũng có khả năng áp dụng mô hình SSM, nhưng cần phải cấu hình trước.
Thông qua protocol Independent multicast – giao thức không phụ thuộc multicast (PIM)
Thông qua sự cạnh tranh giữa các router multicast trong một phân đoạn mạng cục bộ
Thông qua sự cạnh tranh giữa các router multicast trong một phân đoạn mạng cục bộ
Bản tin general query Được hỗ trợ Được hỗ trợ Được hỗ trợ
Bản tin Report Được hỗ trợ Được hỗ trợ Được hỗ trợ
Bản tin Group- specific query
(hàng đợi nhóm cụ thể)
Không hỗ trợ Được hỗ trợ Được hỗ trợ
Leave massage Không hỗ trợ Được hỗ trợ Không có bản tin leave Thay vào đó, thành viên nhóm gửi
1 bản tin report cụ thể để thông báo với multicast router rằng chúng đang rời nhóm
Bản tin Group- and-source- specific query
(nhóm và nguồn cụ thể)
Không hỗ trợ Không hỗ trợ Hỗ trợ
Chỉ định nguồn phát đa hướng trong bản tin report
Không hỗ trợ Không hỗ trợ Không hỗ trợ
ASM model Được hỗ trợ Được hỗ trợ Được hỗ trợ
SSM model Yêu cầu config
Yêu cầu config IGMP SSM mapping Được hỗ trợ
Các bản tin phiên bản giao thức được hỗ trợ
IGMPver1 IGMPver2 IGMPver1,ver2,ver3
1.3.1 IGMP version 1 Để tham gia vào một nhóm multicast, một host sẽ gửi thông điệp đăng ký nhóm đến router cục bộ của nó Thông điệp này có tên Membership Report IGMP chứa địa chỉ multicast, thông báo cho router về địa chỉ multicast mà host muốn tham gia vào
Cứ 60 giây, một router trên mỗi phân đoạn mạng sẽ gửi truy vấn đến tất cả các host để kiểm tra xem các host này có còn quan tâm nhận lưu lượng multicast nữa không Router này còn gọi là IGMPver1 Querier và chức năng của nó là mời các host tham gia vào nhóm
Mô hình query-response chủ yếu được sử dụng để giúp router multicast và switch multilayer xác định nhóm multicast đang hoạt động trên mạng cục bộ, nơi có một hoặc nhiều thiết bị quan tâm đến nhóm này.
IGMP version 1 xác định 2 loại bản tin:
Một truy vấn tổng quát (General Query) được gửi bởi một querier đến tất cả các host và router trong phân đoạn nội bộ nhằm khám phá nhóm multicast có các thành viên trong cùng phân đoạn mạng.
3 Report: các host gửi Report message tới multicast router để yêu cầu tham gia vào nhóm multicast hoặc phản hồi bản tin General query
Type Hai bản tin sẽ có 2 option: ã 0x1: general query ã 0x2: report
Unused Trong bản tin IGMPver1, trường này được set là 0 bởi người gửi và được bỏ qua bởi người nhận
Checksum Ban đầu trường này được set là 0, thiết bị gửi tính toán payload rồi điền vào trường này, thiết bị nhận xác minh trước khi xử lý
Trong bản tin General Query, trường này được thiết lập là 0, trong khi trong bản tin Membership Report, trường này chứa địa chỉ của nhóm mà thành viên muốn tham gia.
IGMP phiên bản 1 sử dụng cấu trúc truy vấn - báo cáo để quản lý các nhóm multicast Khi có nhiều router multicast trên cùng một phân đoạn mạng, tất cả các router này đều nhận được thông điệp báo cáo thành viên từ các host Do đó, chỉ cần một router multicast gửi thông điệp truy vấn tới phân đoạn mạng, và router được chọn để gửi thông điệp này được gọi là IGMP querier Trong quá trình thực hiện IGMP phiên bản 1, một router được PIM (Protocol Independent Multicast) lựa chọn làm querier.
Hình ảnh minh họa một mạng sử dụng IGMP phiên bản 1, trong đó Router A và Router B kết nối với một phân đoạn mạng có ba thiết bị nhận: Host A, Host B và Host C Trong phân đoạn mạng này, Router A đóng vai trò là IGMP querier Cả Host A và Host B đều mong muốn nhận dữ liệu từ nhóm G1, trong khi Host C muốn nhận dữ liệu từ nhóm G2.
IGMPver1 liên quan đến 3 cơ chế: cơ chế general query và report, cơ chế tham gia và cơ chế rời khỏi a Cơ chế general query và report
Bằng cách gửi bản tin General Query và nhận bản tin Report, một IGMP querier biết nhóm nào có thành viên trên phân đoạn mạng cục bộ
Hình 4: Trình bày general query và report process
1 IGMP querier gửi bản tin General query, với địa chỉ đích là 224.0.0.1 (chỉ ra tất cả các host và router trong cùng phân đoạn mạng) Tất cả các thành viên trong nhóm bắt đầu hẹn giờ khi chúng nhận được General Query message
IGMP querier gửi bản tin General query với tần suất mặc định là 60 giây/lần Trong mạng, Host A và Host B là thành viên của nhóm G1 và bắt đầu thiết lập bộ hẹn giờ cho G1 Thời gian hẹn giờ được chọn ngẫu nhiên trong khoảng từ 0 đến 10 giây, là thời gian phản hồi tối đa.
2 Host có bộ đếm thời gian hết hạn trước tiên sẽ gửi bản tin Report cho group
Trong trường hợp này, khi bộ đếm thời gian G1 trên Host A hết hạn, Host A sẽ gửi một bản tin Report đến G1 Khi Host B nhận được bản tin Report từ Host A, nó sẽ dừng bộ đếm giờ G1 và không gửi thêm bản tin Report nào cho G1 Cơ chế này giúp giảm số lượng bản tin Report trên mạng và giảm tải cho bộ định tuyến multicast.
3 Sau khi IGMP querier nhận bản tin Report từ host A, nó biết rằng group G1 có thành viên trong phân đoạn mạng cục bộ IGMP querier sử dụng giao thức định tuyến đa hướng (multicast routing protocol) để tạo 1 (*, G1) entry, trong đó * là viết tắt của nguồn bất kỳ đa hướng nào Khi IGMP querier nhận dữ liệu gửi đến G1, nó chuyển tiếp dữ liệu tới phân đoạn mạng này b Cơ chế join
Hình 5: Host C tham gia group G2
1 Host C gửi 1 bản tin Report cho G2 mà không cần đợi bản tin General Query
2 Sau khi nhận bản tin Report, IGMP querier biết rằng một thành viên của G2 đã kết nối với phân đoạn mạng cục bộ, và tạo 1 (*, G2) entry Khi IGMP querier nhận dữ liệu đến G2, nó sẽ chuyển tiếp dữ liệu tới phân đoạn mạng này c Cơ chế Leave
Giao thức RTSP (Real Time Streaming Protocol) trong IPTV
Giao thức truyền phát thời gian thực (Real Time Streaming Protocol - RTSP)
RTSP (Real Time Streaming Protocol) is a network control protocol designed to facilitate communication between client machines and streaming servers This protocol is utilized to establish and control sessions between computers, enabling efficient data exchange and streaming capabilities.
Giao thức cung cấp khung truyền dữ liệu phương tiện theo thời gian thực ở cấp ứng dụng, cho phép truyền tải thông tin từ đa phương tiện đến thiết bị đầu cuối Nó thực hiện việc này thông qua việc giao tiếp trực tiếp với máy chủ truyền dữ liệu, đảm bảo quá trình truyền diễn ra mượt mà và hiệu quả.
Giao thức RTSP (Real-Time Streaming Protocol) tập trung vào việc kết nối và kiểm soát các phiên phân phối dữ liệu cho các phương tiện liên tục như video và âm thanh Nó hoạt động như một điều khiển từ xa, cho phép quản lý các tệp phương tiện thời gian thực và máy chủ đa phương tiện một cách hiệu quả.
Các giao thức thiết lập và điều khiển phương tiện truyền thông dòng giữa thiết bị khách hàng và máy chủ, đóng vai trò như mạng lưới điều khiển từ xa cho dòng thời gian đồng bộ của âm thanh và video Chúng không trực tiếp truyền phát đa phương tiện mà thực hiện giao tiếp với máy chủ để truyền dữ liệu đa phương tiện Ví dụ, khi người dùng tạm dừng video đang phát trực tuyến, giao thức RTSP sẽ gửi yêu cầu tạm dừng đến máy chủ phát video.
Giao thức RTSP có hình thức tương đồng với HTTP, nhưng khác biệt ở chỗ RTSP định nghĩa một bộ tín hiệu điều khiển tuần tự để quản lý quá trình phát lại video Trong khi HTTP là giao thức không có trạng thái, RTSP lại có xác định trạng thái, sử dụng số hiệu session để theo dõi các phiên giao dịch streaming Giống như HTTP, RTSP cũng sử dụng TCP để duy trì kết nối đầu cuối và các thông điệp điều khiển được gửi từ máy client tới máy server.
Nó cũng thực hiện điều khiển các đáp trả từ máy server tới máy client Cổng mặc định được sử dụng bởi giao thức này là 554.
Các tính năng và thành phần chính của giao thức RTSP
2.2.1 Có 8 tính năng cơ bản của giao thức RTSP
Khả năng đa máy chủ: khả năng trình bày các luồng phương tiện từ các máy chủ đa phương tiện khác nhau
Khả năng đàm phán: máy chủ của khách hàng có thể tìm thấy các tính năng cơ bản có được bật hay là không
Thân thiện với HTTP: nó sử dụng các khái niệm HTTP bất cứ khi nào có thể
Dễ phân thích cú pháp: Trình phân tích cú pháp HTML hoặc MMIE có thể được sử dụng trong giao thức truyền phát thời gian thực
Khả năng mở rộng: có thể dễ dàng thêm các tham số hoặc phương thức mới trong giao thức
Tường lửa thân thiện: các tường lửa lớp ứng dụng và lớp vận chuyển đều có thể được xử lý dễ dàng bằng các phương tiện giao thức
Kiểm soát máy chủ là yếu tố quan trọng, đảm bảo rằng máy chủ có khả năng quản lý và kiểm soát tốt các hoạt động của mình Điều này có nghĩa là máy chủ không được phép truyền phát dữ liệu đến máy khách theo bất kỳ cách nào, nhằm ngăn chặn việc máy khách dừng quá trình phát trực tuyến.
Giao thức này phù hợp hơn cho các ứng dụng và phương tiện nhờ vào độ chính xác ở mức khung và việc sử dụng dấu thời gian SMPTE trong chỉnh sửa kỹ thuật số.
2.2.2 Thành phần chính của RTSP
Khi đàm phát, thương lượng và kiểm soát các luồng phương tiện, RTSP thường sử dụng các lệnh sau được gửi từ máy khách đến máy chủ:
Options: Một yêu cầu tùy chọn được gửi đến máy chủ để xác định loại yêu cầu mà máy chủ phương tiện hỗ trợ
Describe: Yêu cầu mô tả bao gồm URL và mô tả dữ liệu phát lại
Phương thức thông báo bản mô tả được sử dụng để gửi thông tin từ máy khách đến máy chủ, đồng thời cập nhật mô tả khi nhận được từ máy chủ về máy khách.
Setup: Yêu cầu thiết lập chỉ định các truyền một luồng phương tiện trước khi gửi yêu cầu phát
Play: Yêu cầu phát bắt đầu truyền phương tiện bằng cách yêu cầu máy chủ bắt đầu gửi dữ liệu
Pause: Yêu cầu tạm dừng tạm thời , dừng phân phối luồng
Record: Yêu cầu bắt đầu ghi phương tiện
Teardown: yêu cầu này chấm dứt (kết thúc hoàn toàn phiên) và dùng tất cả các luồng phương tiện
Redirect: Yêu cầu chuyển hướng yêu cầu khách hàng kết nối với một máy chủ phương tiện khác
Set_Parameter có khả năng kiểm tra hoạt động của máy khách hoặc máy chủ, đồng thời tiết lộ các giá trị của hướng dẫn trình bày hoặc luồng Bộ phận nhận dạng tài nguyên thống nhất (URI) chứa các ký tự xác định tài nguyên mà nó cung cấp.
2.2.3 Quá trình hoạt động của giao thức
Khi người dùng hoặc ứng dụng muốn truyền phát video từ xa, thiết bị khách gửi yêu cầu RTSP đến máy chủ để xác định các tùy chọn như tạm dừng, phát và ghi Máy chủ sau đó cung cấp danh sách các loại yêu cầu mà nó có thể chấp nhận qua RTSP.
Khi khách hàng hiểu cách thực hiện yêu cầu, họ sẽ gửi một yêu cầu mô tả phương tiện đến máy chủ phát trực tuyến Máy chủ sau đó sẽ phản hồi bằng cách cung cấp thông tin về phương tiện truyền thông Tiếp theo, máy khách sẽ tiến hành gửi yêu cầu thiết lập.
VCR (bộ điều khiển video) hỗ trợ để khách hàng có thể tua lại, dừng lại hoặc tới nhanh nội dung của video
Chức năng VCR trong RTSP cho phép IPTVCD yêu cầu và khôi phục một phần nội dung IPTV đặc biệt Phản hồi cho yêu cầu này liên quan đến địa chỉ IP của Server VoD phù hợp, cùng với các yêu cầu chỉ thị được phát bởi IPTVCD.
Mô hình tính toán Client-Server RTSP hoạt động dựa trên cấu trúc này, trong đó ba liên kết riêng biệt được thiết lập để đảm bảo sự giao tiếp hiệu quả giữa RTSP Client, thiết bị khách hàng IPTV (IPTV Customer Device), và máy chủ VoD.
Hình 13 Kiểu truyền thông RTSP Client-Server
Có 3 kết nối riêng biệt được thiết lập để cung cấp thông tin giữa máy con RTSP chạy trên một IPTVCD và Server VoD Ba loại kết nối này được chỉ ra và giải thích như sau:
1) Một dãy kết nối được thiết lập để mang thông tin điều khiển RTSP Tầng giao vận được sử dụng bởi các loại kết nối dựa trên UDP và TCP
Việc tích hợp chức năng điều khiển thông tin qua RTSP cho phép các loại kết nối được sử dụng để đưa vào hoặc xen kẽ nội dung IPTV.
2) Một RTP phân biệt qua một kết nối UDP được thiết lập để mang nội dung mã hóa
3) Kết nối thứ 3 mang RTCP qua thông tin đồng bộ UDP, luồng này được cung cấp trở lại Server trên chất lượng của luồng phần phối trên thiết bị IPTVCD
Hình 14 Quá trình hoạt động của RTSP
Các phương pháp RTSP đóng vai trò quan trọng trong việc quản lý phiên và phân bổ tài nguyên luồng trên máy chủ, bao gồm các lệnh SETUP, PLAY, RECORD, PAUSE và Teardown Máy chủ cần duy trì trạng thái phiên để tương quan với các yêu cầu RTSP và cung cấp thông tin cần thiết để mở cổng và bản đồ cho các cổng gần.
- Hỗ trợ cả Unicast và Multicast RTSP cho phép để điều khiển cả các luồng
Multicast và Unicast Nhưng trong luồng Multicast không cho phép khả năng tua nhanh, tua lùi
- Độc lập với giao thức lớp vận chuyển RTSP có thể hoạt đồng trên cả UDP và TCP
- Làm việt trong mối liên kết với RTP RTSP và RTP làm việc cùng nhau để phân phối nội dung qua mạng
- Cấu trúc bản tin của RTSP Bản tin được chia ra làm 2 loại: REQUEST và
Cấu trúc của RTSP REQUEST là:
{method name} {URL} {Protocol Version} CRLF {Parameters}
Cấu trúc chung của RTSP RESPONE là:
{Protocol Version} {status code} {Reason Pharse} CRLF {Parameters}
In the scenario where a client STB sends a request to the VoD server to stream a movie, the process involves the transmission of an RTSP (Real-Time Streaming Protocol) message This interaction is essential for establishing a connection and enabling the client to access the desired video content seamlessly.
Các bản tin truyền liên kết với tổng đài và người dùng như sau:
Hình 15 Ví dụ bản tin RTSP
(1) Kết nối giữa client và server Đầu tiên một kết nối TCP giữa STB và Server được thiết lập
(2) Phát bản tin yêu cầu “DESCRIBE” Khi yêu cầu đến Server để gửi
“Describe” về một bộ phim đó thì server sẽ hồi đáp bằng chỉ thị
The next message sent by STB is an "OPTIONS" request, which inquires about the supported command types from the server The server responds with a list of available RTSP commands.
(4) Phát bản tin yêu cầu “SETUP” Lệnh tiếp theo chỉ ra Server để cấp tài nguyên
Định nghĩa các thành phần
To implement video streaming using the RTSP protocol, the client must send specific requests to the streaming server in a defined sequence.
2.3.1 OPTIONS Đầu tiên, máy client sẽ gửi yêu cầu OPTIONS kèm với đường link trỏ tới file video cần xem tới máy server, để máy server chấp nhận đường link này
Khi máy server trả về mã chấp nhận đường link, máy client sẽ gửi yêu cầu DESCRIBE để phân tích đường link Yêu cầu DESCRIBE bao gồm một đường link RTSP (rtsp://) và kiểu dữ liệu đáp trả từ server Cổng mặc định cho giao thức RTSP là 554, được sử dụng cho cả giao thức UDP và TCP Phản hồi từ server cho yêu cầu DESCRIBE sẽ bao gồm bản tin mô tả chi tiết phiên giao dịch (Session Description Protocol - SDP).
Trong thông điệp trả về từ máy chủ, có liệt kê các đường link phù hợp để phát video khi video chứa cả phụ đề và âm thanh Một điểm quan trọng trong bản tin SDP là streamid của luồng video và streamid của luồng âm thanh, đặc biệt khi âm thanh được lồng ghép trong các khung hình của video.
Phương thức announce dùng cho 2 mục đích:
Khi gửi dữ liệu từ máy khách đến máy chủ, thông báo mô tả nội dung hoặc phương tiện truyền thông được xác định qua các URL yêu cầu Ngược lại, khi máy chủ gửi thông tin cho khách hàng, thông báo sẽ cập nhật mô tả phiên họp trong thời gian thực.
Nếu một phương tiện truyền thông mới được thêm vào mô tả nội dung, cần gửi lại bản mô tả này để có thể xóa bỏ, thay vì chỉ bổ sung thêm thành phần.
Sau khi máy client được thông điệp đáp trả từ máy server sau yêu cầu
Khi máy client gửi yêu cầu SETUP đến máy server, yêu cầu này chỉ ra cách thức truyền tải một dòng dữ liệu (single media stream) Yêu cầu SETUP phải được hoàn tất trước khi gửi yêu cầu PLAY Nó bao gồm đường link tới file video cần streaming và thông tin về giao vận, với hai cổng: một cổng cục bộ trên máy client để nhận gói tin RTP (audio và video) và một cổng khác cho gói tin RTCP (meta information) Máy server sẽ xác nhận các tham số đã chọn và có thể điều chỉnh cổng của mình Mỗi luồng dữ liệu sẽ được cấu hình cụ thể sau khi hoàn tất yêu cầu SETUP trước khi máy client gửi yêu cầu PLAY.
Sau khi hoàn tất yêu cầu SETUP và cấu hình luồng dữ liệu cho việc streaming, máy client sẽ gửi yêu cầu play để truyền tải các frame dữ liệu thực từ máy server Những frame dữ liệu này sẽ được lưu trữ trong bộ đệm của máy client, sau đó sẽ được giải mã và hiển thị qua VLC.
Yêu cầu PLAY cần một đường dẫn tới file video, có thể là đường tổng hợp cho nhiều luồng dữ liệu hoặc một đường link đơn lẻ cho một luồng duy nhất Trong yêu cầu này, máy client sẽ chỉ định một dải (range) để xác định cụ thể frame bắt đầu và frame kết thúc Nếu không chỉ rõ dải này, toàn bộ các frame sẽ được gửi tới máy client Ngoài ra, nếu luồng dữ liệu bị tạm dừng (PAUSE), nó sẽ được phục hồi từ frame mà nó đã tạm dừng.
Trong quá trình phát trực tuyến video, người dùng có thể tạm dừng streaming bằng cách gửi yêu cầu PAUSE đến máy chủ Yêu cầu này sẽ dừng lại một hoặc nhiều luồng dữ liệu đang truyền các khung hình đến máy client Khi nhận được yêu cầu, máy chủ sẽ ngừng gửi các khung hình dữ liệu tới máy client.
Âm thanh trong quá trình tắt tiếng cần được đồng bộ hóa khi phát lại hoặc ghi âm Các tài nguyên máy chủ phải được duy trì, mặc dù máy chủ có thể đóng các phiên họp và giải phóng tài nguyên sau khi tạm dừng theo thời gian quy định trong tiêu đề Session của thông điệp SETUP.
Yêu cầu PAUSE cho phép tạm dừng một hoặc tất cả các dòng phương tiện truyền thông, với khả năng nối lại sau đó thông qua yêu cầu PLAY Yêu cầu này bao gồm một URL của dòng tổng hợp hoặc các phương tiện truyền thông Tham số phạm vi trong yêu cầu PAUSE xác định thời gian tạm dừng; nếu tham số này bị bỏ qua, việc tạm dừng sẽ diễn ra ngay lập tức và không có thời hạn.
Trong quá trình streaming video, người dùng có thể gửi yêu cầu TEARDOWN để dừng truyền và kết thúc phiên giao dịch RTSP Sau khi nhận được yêu cầu TEARDOWN, máy chủ sẽ phản hồi và ngừng gửi các frame tới máy client.
Yêu cầu TEARDOWN yêu cầu ngừng cung cấp URI, một chuỗi ký tự dùng để xác định tên hoặc tài nguyên, và giải phóng các nguồn tài nguyên liên quan Nếu URI được trình bày trong các bài trình bày, bất kỳ định danh phiên RTSP nào liên kết với phiên sẽ không còn giá trị Trừ khi tất cả các thông số vận chuyển được xác định bởi mô tả phiên, một yêu cầu thiết lập đã được cấp trước phiên họp có thể được phát lại một lần nữa.
GET_PARAMETER cho phép trao đổi thông số bằng cách lấy giá trị của một tham số trong bài thuyết trình hoặc dòng quy định trong URI Nội dung của các phản hồi và yêu cầu khác sẽ được thực hiện dựa trên giá trị này Tuy nhiên, GET_PARAMETER không được sử dụng để kiểm tra client hoặc máy chủ server.
Phương pháp này yêu cầu để thiết lập giá trị của một tham số cho một bản môt tả hoặc dòng quy định của URL
Mô Phỏng giao thức RTSP qua phần mềm VLC (và phân tích gói tin qua Wireshark)
2.4.1 Giới thiệu phần mềm streaming VLC
VLC Media Player, hay còn gọi là VLC, là phần mềm đa phương tiện miễn phí giúp người dùng nghe nhạc, xem phim và thực hiện các hoạt động giải trí khác trên máy tính Với giao diện đơn giản và thân thiện, VLC tích hợp nhiều tính năng hữu ích, mang đến trải nghiệm tuyệt vời cho người dùng.
Phần mềm này cho phép bạn phát nhiều loại tệp video khác nhau, mở radio trực tuyến, và thực hiện các chỉnh sửa đơn giản cho tệp đa phương tiện Tuy nhiên, nhược điểm là dung lượng phần mềm còn hạn chế.
Ngoài xem phim, nghe nhạc thì người dùng có thể biến VLC thành công cụ phát trực tiếp hoặc xem cả TV trực tuyến (streaming)
VLC cho phép người dùng phát trực tiếp video cho các tài khoản khác trong mạng nội bộ của phần mềm Bên cạnh đó, người dùng cũng có thể chia sẻ video rộng rãi trên các trang mạng Internet khác.
VLC cho phép người dùng sử dụng lệnh "Stream" từ menu file, đây là phương pháp đơn giản nhất để phát trực tiếp Tuy nhiên, để thực hiện điều này, bạn cần cấu hình địa chỉ IP của máy tính mà bạn muốn phát trực tiếp tới.
2.4.2 Thực hiện demo RTSP a Mục tiêu:
Cấu hình máy client cho phép xem hoặc nghe audio trực tuyến từ máy Server trong thời gian thực thông qua giao thức RTSP Điều này giúp bắt gói tin và theo dõi quá trình hoạt động của RTSP Địa chỉ IP của các thành phần cần được xác định rõ ràng.
Interface IP address Subnet mask GW
192.168.172.254 255.255.255.0 192.168.172.2 b Mô hình Demo qua GNS3
Hình 16 Mô hình demo RTSP
1 cloud cho Server được kết nối với máy chủ thật (qua cổng Ethernet 3)
1 cloud cho Client được kết nối với máy ảo Windows 7 trên VM Ware
- Các thiết bị được nối với nhau như hình trên
- Chạy mô phỏng thì máy Client có thể xem được đoạn video hay audio mà máy Server đang phát c Công cụ thực hiện
- Phần mềm ảo hóa VM ware chạy máy ảo (client) d Các bước thực hiện
1) Cấu hình router để 2 bên client và server có thể Ping thông đến nhau
Như trên mô hình thì ta dùng giao thức OSPF để chạy
- Thực hiện Ping từ Server đến Client và ngược lại:
Hình 17 Server đến Client (thực hiện trên máy chủ Windows)
Hình 18 Client đến Server (thực hiện trên máy ảo Win 7 VM ware)
2) Cấu hình VLC Media Player
Ta sẽ thực hiện cấu hình trên cả 2 máy đó là máy Server và máy Client a Cấu hình trên máy Server
- Setup VLC media Player, trong giao diện chọn menu Media -> Stream
- Click vào “Add” và chọn video mình muốn stream trong máy -> Stream
- Chọn giao thức RTSP và ấn “Add”
- Chọn port 554, Part “/stream” -> ấn Next
- Profile -> chọn “Video - H.264 + MP3 (MP4)” -> Next
- Tích vào ô “Stream all elementary streams” -> rồi ấn Stream ở góc bên dưới b Cấu hình trên máy Client
- Setup VLC media player, trong giao diện VLC => Open Network Stream
- Gõ đường đãn đến máy chủ Server mình đặt trong bài là 10.0.0.20 thì đường dẫn sẽ là: rtsp://10.0.0.20:554/stream -> Play
- Dùng Wireshark để bắt gói tin RTSP
Quá trình khởi tạo kết nối giữa Client và Server:
