2.6.1 Sử dụng RTSP trong DVB.
Phần này sẽ nói về Real Streaming Protocol (RTSP) xác định khả năng phát của HNED.
RTSP là một giao thức lớp ứng dụng để điều khiểu phân tán dữ liệu thời gian thực. Việc sử dụng RSTP cho quảng bá cổ điển như là một loại phân tán dữ liệu của hình ản (video) và âm thanh (radio) cũng như phân phát dữ liệu hình ảnh và âm thanh theo yêu cầu.
2.6.1.1 Lựa chọn dịch vụ
Tiến trình phát hiện và lựa chọn dịch vụ được mô tả trong phần 5 sẽ cung cấp các HNED với RSTP URL để truy cập vào RSTP dựa trên yêu cầu dịch vụ. Ví dụ các HNED lắng nghe từ một địa chỉ multicast và số cổng để đưa ra mô tả SD&S được trình bày với người sử dụng và sau đó từ người dùng có thể thực hiện lựa chọn. Khi dịch vụ được chọn, các HNED có thể sử dụng các liên kết URL để truy cập vào dịch vụ. URL sẽ quyết định phiên điều khiển dựa trên RSTP. Trong trường hợp này các HNED sẽ sử dụng RSTP để truy cập vào dịch vụ trong yêu cầu.
2.6.2 Phiên truyền.
DVB tuân thủ các HNED nên sử dụng kết nối TCP liên tục để trao đổi các tin nhắn RSTP máy chủ RSTP. Nó đề nghị sử dụng một kết nối TCP liên tục; còn có một cách khác đáng tin cậy cho các máy chủ RSTP tiếp cận với HNED đó là bức tường lửa. Ví dụ máy chủ có thể sử dụng kết nối liên tục để gửi tin nhắn không đồng bộ RSTP ANNOUNCE (bảng 10) cho HNED.
2.6.3 Thông tin dịch vụ
HNED sử dụng thông tin dịch vụ để khai báo cho các người dùng về loại và các dịch vụ đang hoạt động nhằm mục đích định vị và truy cập chúng. Thông tin này cần phải luôn luôn được cập nhật.
Nơi có thể thực hiện, máy chủ RSTP có thể gửi thông tin dịch vụ không đồng bộ tới HNED bằng cách sử dụng phương thức ANNOUNCE (bảng 10). Hoặc HNED cũng có thể thăm dò máy chủ với sự giúp đỡ của phương thức DESCRIBE (bảng 10) để tìm những thông tin dịch vụ đã được cập nhật. việc này có thể sử dụng trong trường hợp kết nối tạm thời được sử dụng giữa HNED và máy chủ RSTP.
Các phương thức ANNCOUNCE và DESCRIBE sử dụng mô tả XML để vận chuyển dữ liệu dịch vụ tới HNED.
2.6.4 Vấn đề bảo mật
DVB được dùng dựa trên RSTP và HTTP, cân nhắc về bảo mật được đưa ra với các giao thức này (xem trong phần mô tả các RFC).
Các thuộc tính
Định nghĩa các thuộc tính
DVB xác định các đặc điểm kỹ thuật theo 3 thuộc tính RSTP: Live Media Broadcast (LMB): Quảng bá đa dữ liệu thực Media Broadcast with Trick Modes (MBwTM)
Content on Demand (CoD): Nội dung theo yêu cầu
Mỗi thuộc tính chứa một tập con các phương thức và tiêu đề định nghĩa trong giao thức RSTP. Mối liên hệ giữa các thuộc tính như thuộc tính LMB là một tập con của MBwTM, mà nó có thể trả về một tập con của một CoD.
Live Media Broadcast
Thuộc tính Live Media Broadcast có đặc điểm tương đương với quảng bá truyền thống như là TV và radio. Luồng đa dữ liệu hiện tại có thể được phân phát trong cùng kiểu unicast hoặc multicast.
Media Broadcast with Trick Modes
Media Broadcast with Trick Modes có đặc điểm tương đương với quảng bá đa dữ liệu thực và thêm phần hỗ trợ Trick mode như là pause, fastforwad…Luồng dữ liệu hiện tại được phân phát chỉ theo một kiểu unicast duy nhất. Sự khác biệt giữa thuộc tính này và CoD đó là người dùng không thể khỏi tạo chúng.
Contend on Demand
Thuộc tính Contend on Demand thêm vào Media Broadcast với Trick Modes có thể thiết lập bắt đầu hoặc kết thúc cũng như là phân tách các sự kiện. Điều đó có nghĩa là thuộc tính này hỗ trợ pause, fast forwad hữu ích như mà khả năng truy cập dữ liệu trong thời gian lựa chọn của người dùng. Vì thế luồng đa dữ liệu thực được chỉ được phân phát trong kiểu unicast.
Chú ý: Thuộc tính RSTP sử dụng dựa trên các ứng dụng và nơi dịch vụ yêu cầu được phân phát trên kiểu unicast hoặc multicast. Chỉ có LMB là có thể được phân phát theo kiểu multicast.
Các phương thức RSTP:
Kiểu phân phát dữ liệu unicast được đặc biệt chỉ ra trong bảng 10 cho mỗi một thuộc tính của phương thức RSTP được hỗ trợ bởi giao diện IPI-1
2.6.5 DVB sử dụng các phƣơng thức RSTP
2.6.5.1 Thông báo (ANNOUNCE)
Phương thức thông báo được sử dụng để cập nhật không đồng bộ thông tin máy chủ tại HNED. Việc này có thể sử dụng trong một ví dụ cho một LMB để cập nhật tên dịch vụ.
DVB SRTP khách được yêu cầu để hỗ trợ tiếp nhận của mô tả trong định dạng XML như mô tả trong 5.2.6 cho thuộc tính quảng bá (LMB và MBwTM) và 5.2.6.3 cho CoD. Thuộc tính quảng bá sử dụng phương thức này sẽ chứa cấu trúc phức tạp của quảng bá đề nghị XML.
MIME Type trong tiêu đề Content-Type như một bản tin định đạng text/xml, nội dung của tiêu đề Content-Encoding và mô tả XML sẽ theo chuẩn UTF-8.
2.6.5.2 Mô tả
DVB SRTP khách được yêu cầu để hỗ trợ tiếp nhận của mô tả trong định dạng XML như mô tả trong 5.2.6 cho thuộc tính quảng bá (LMB và MBwTM) và 5.2.6.3 cho CoD. Thuộc tính quảng bá sử dụng phương thức DESCRIBE sẽ chứa cấu trúc phức tạp của BroadcastOffering XML.
MIME Type trong tiêu đề Content-Type như một bản tin định đạng text/xml, nội dung của tiêu đề Content-Encoding và mô tả XML sẽ theo chuẩn UTF-8.
2.6.5.3 Thiết lập thông số (GET_PARAMETER)
MIME trong tiêu đề Content-Type của thiết lập thông số trả lời sẽ có định dạng text/parameter và nội dung của tiêu đề Content-Encoding theo chuẩn định dạng UTF- 8.
Trong yêu cầu, tên của thông số được theo chuẩn (“:”) và được tách ra bằng những khoảng trắng và có thể nằm trên nhiều dòng riêng biệt hoặc nằm trên một dòng. Thông số trong bản tin trả về trên một dòng theo định dạng:
parameter = name ":" *(VCHAR) CR
Bảng 11 định nghĩa giá trị nhỏ nhất thiết lập cho thông số GET_PARAMETER được hỗ trợ bởi giao diện IPI-1 trong trường hợp phương thức GET_PARAMETER được hỗ trợ.
Bảng 11: Các thông số GET_PARAMETER Thông số
GET_PARAMETER Kết quả Mô tả
Stream-state <current stream state> Đây là thông số trả về