(1) và (2) có thể được thỏa mãn bằng nhiều cách. Tất cả bao gồm truyền thông tin trong một SDP và truyền nó cho UE. Ngoài ra, SIP sẽ được sử dụng cho thiết lập phiên ,và kể từ đó phương thức SIP thắch hợp cho mục đắch này, một INVITE sẽ cần được gửi từ UE đến MCF qua SCF. Với sự khắa cạnh này, đến nay, đây là một số trong những giải pháp có thể thực hiện được:
Chương 3
a) Một SDP có thể được đắnh kèm vào tin nhắn trả lời 200 OK từ MCF trong phiên bắt đầu. Trong trường hợp này, UE có thể có giành được địa chỉ RTSP của MCF sử dụng "điều khiển" thuộc tắnh được định nghĩa :
a=control:rtsp://someserver.com/stream_identifier
Giải pháp này có hiệu lực (tác động) có nghĩa là một yêu cầu DESCRIBE (MÔ TẢ) không cần phát ra, kể từ khi mô tả về phiên đã có sẵn thông qua trả lời 200 OK MỜI tới INVITE
b) Địa chỉ MCF có thể được truyền đến UE bằng cách sử dụng một yêu cầu SIP REFER(GIỚI THIỆU ), nơi SCF hoạt động (làm việc) như UAC. Các tham khảo-Để tiêu đề khi đó sẽ bao gồm MCF URL. SDP sau đó có thể được gửi đến UE như là một phần thân của trả lời đến đến một yêu cầu RTSP thông qua điểm tham chiếu Xc sau khi khởi tạo phiên SIP.
c) Các SDP có thể khôi phục (được lấy lại) bằng UE trước khi khởi tạo phiên họp diễn ra bởi đưa ra "yêu cầu luồng chi tiết" cho SSF, yêu cầu một SDP trên luồng người dùng lựa chọn. Ngay cả ở đây, một REFER nơi SCF hoạt động như UAC sẽ cần thiết cho các UE để có được địa chỉ MCF, từ khi lựa chọn MCF được thực hiện bởi SCF trong khởi tạo phiên.
(3) Có thể đáp ứng bằng cách sử dụng bản tin INFO nơi SCF hoạt động như UAC và UE như là UAS. Bản tin này phải được kắch hoạt bởi các ACK khi kết thúc khởi tạo phiên, kể từ khi INFO được sử dụng cho báo hiệu (truyền tắn hiệu) phiên. Sự bù lại (offset) sau đó được gửi ở một số định dạng phù hợp là tất cả (phần thân) của yêu cầu INFO SIP. Bản tin INFO nhận được ở trên, các UE có thể sử dụng tiêu đề Range của yêu cầu RTSP PLAY để cho biết nơi sắp xếp (streaming) bắt đầu.Vắ dụ, nếu bản tin INFO chỉ ra rằng trong 40 giây đầu tiên của một video đã được xem, các UE sử dụng tiêu đề này để cho biết MF này sẽ gửi phần còn lại của Video:
Range: npt = 40 Ờ
Một lựa chọn có thể theo hướng sử dụng INFO sẽ được dùng phương pháp MESSAGE tại cùng một cách. Không có lợi ắch rõ ràng khi sử dụng một phương pháp khác trong qua phục hồi (bù lại) truyền từ UE, nhưng từ lúc MESSAGE thường được sử dụng cho gửi bản tin tức thời giữa người sử dụng, INFO có thể thắch hợp hơn.
(4) có thể đáp ứng bằng cách sử dụng một phần người dùng của To-URI và / hoặc Request-URI trong INVITE chỉ trong luồng người dùng được quan tâm Vắ dụ: nếu alice @ atlanta.com quan tâm đến xem "The Big Lebowski", UE của cô có thể sau đó, sau khi đã tham khảo các dữ liệu nhận được từ các SSF và kết luận rằng "The Big Lebowski" có một nhận dạng luồng của "9399981", gửi một INVITE đến Core IMS với một Request URI của sip: 9399981@vodscf.atlanta.com. Core IMS (Chắnh xác
Chương 3
hơn, S-CSCF) sau đó có thể đánh giá IFC cái nào nói nó để chuyển tiếp tất cả các yêu cầu SIP mà phương pháp lúc này là INVITE và có Request-URI kết thúc bằng "@ Vodscf.atlanta.com" tới SCF.
(5) có thể hài lòng bằng cách sử dụng các tiêu đề nhận dạng khẳng định P. Tiêu đề này có bởi P-CSCF trên khi nhận được một tin nhắn từ một UE chứng thực. Từ tiêu đề sẽ có IMPU của khởi tạo (gốc) là tốt của người khởi tạo là tốt, tuy nhiên, SCF không nên dựa vào giá trị của thông tin này. Nhận dạng tắnh cước IMS (IMS charging identifier) (ICID) được tạo ra bởi P-CSCF có thể được sử dụng như một định danh để tắnh phắ. Thông tin khác đó sẽ được bao gồm trong bản ghi dữ liệu tắnh cước Charging Data Record (CDR) là thông tin luồng và người dùng.
(6) có thể đạt được bằng cách sử dụng một yêu cầu INFO, miễn là phiên vẫn còn hoạt động. Điều này sau đó sẽ làm việc tương tự (3), với khác biệt, các UE hoạt động như UAC thời gian này và các SCF là UAS. Tùy chọn này là để cho các MCF gửi thông tin này, nhờ lợi thế này mà UE có nhiều khả có kết nối không tin cậy - đặc biệt nếu nó là một thiết bị di động - và gây ra một phiên không thất bại (Trong đó sẽ có nghĩa là offset mới không được lưu trong mạng). Tuy nhiên, UE là đơn vị duy nhất biết chắnh xác có bao nhiêu của video đó đã thực sự được phát cho người dùng. Do đệm và độ trễ, các MCF không có thể có chắnh xác các thông tin như UE.
INFO cần phải được gửi sau khi RTSP TEARDOWN chuyển vòng, nhưng trước khi kết thúc phiên SIP (trước khi BYE). Tuy nhiên, điều này đặt ra một vấn đề cho các phiên được kết thúc với SCF. Vắ dụ, giả sử người dùng muốn tiếp tục xem một video trên UEB khi UEA của người dùng đã có một phiên đang chạy. Chuỗi các sự kiện sau đó sẽ là:
1. Người sử dụng bắt đầu một phiên sử dụng UE, có nghĩa là một INVITE đạt (tới) SCFB.
2. SCFB tham khảo các dữ liệu hoạt động dịch vụ IPTV cho người sử dụng và phát hiện ra nó có một phiên đang chạy.
3. SCFB cho SCFA biết để kết thúc phiên đang chạy với người dùng 4. SCFA kết thúc phiên với UEA (sử dụng BYE).
5. UEA gửi offset cho SCFA.
6. SCFA chứa offset trong các dữ liệu hoạt động dịch vụ IPTV và loại bỏ tiếp nhận của phiên đã kết thúc
7. SCFA báo hiệu để SCFB biết rằng phiên đã kết thúc. 8. SCFB tiếp tục với việc bắt đầu phiên ở bước đầu tiên.
Chương 3
Vấn đề với việc sử dụng INFO cùng với trình tự của cá hoạt động là phiên SIP đã kết thúc trước khi offset được lưu, nhưng INFO chỉ nên sử dụng cho truyền tắn hiệu (báo hiệu) phiên. Như vậy, MESSAGE là thắch hợp hơn, vì nó không có hạn chế này.
(7) có thể hài lòng bằng cách kết hợp thông tin này vào các nhận dạng luồng. Điều này có thể đạt được bằng cách cho phép các SDF tham khảo (tra cứu) hồ sơ người dùng sử dụng IPTV trong file đắnh kèm dịch vụ VOD, và gửi địa chỉ thắch hợp cho SSF tới người sử dụng. Vắ dụ, giả sử các SDF đã phát hiện ra rằng UE là một điện thoại thông minh với truy cập HSDPA và hiển thị QVGA. Các SDF sau đó có thể gửi một địa chỉ SSF hình thức sau đây để các UE:
http://ssf.provider.vodcatalog com /? bitrate = 768kbps & res = QVGA Đối với (8), xem ở phần dưới của chương (Bảo mật).