IMS - Hệ thống hội nghị truyền hình P2P

a. Kiến trúc

Kiến trúc này sử dụng một sơ đồ báo hiệu lai và một tiếp cận phân bố với sự phân bố

lưu lượng phương tiện. Khi tạo một hệ thống phân phối, mỗi khách hàng có thể hoặc thiết
lập một luồng song công với mỗi khách hàng khác nhau, hoặc là họ có thể mỗi broadcast tới
một địa chỉ IP multicast. Một broadcast đơn từ mỗi khách hàng tới một địa chỉ IP multicast
sẽ đạt hiệu quả sử dụng nhất của băng thông upload của khách hàng, nhưng không may
multicast không được thực hiện mở rộng trong internet và vì vậy nó phù hợp hơn trong môi
trường kín. Việc này cũng sẽ làm giảm độ linh hoạt của mỗi khách hàng có thể thương
lượng mức chất lượng phù hợp cho mỗi phiên. Với việc đánh giá mô hình này, ta chọn thực
hiên luồng song công unicast giữa mỗi khách hàng.
Để mỗi khách hàng phân phối liên lạc với một khách hàng khác, cần thiết có một
điểm trung tâm. Một SIP AS hoạt động như là một server phối hợp hội nghị trong thiết kế
này. Nếu không có server trung tâm, mỗi thành viên sẽ phải tự khám phá các thành viên
khác trong hội nghị qua một cơ chế ngoài, hoặc là họ sẽ phải có hiểu biết quan trọng về các
thành viên hội nghị tương lai trước khi hội nghị bắt đầu. SIP AS duy trì một danh sách
những ai hiện tại đang trong hội nghị, cũng như thông báo các thành viên hiện tại khi nào
một thành viên mới tham gia hội nghị hoặc khi nào một thành viên dời khỏi hội nghị.
b. Báo hiệu
Như được đề cập bên trên, server phối hợp là một SIP AS, AS này thực hiện gói sự
kiện hội nghị SIP. Đây là chức năng tương tự khái niệm “hiện diện”. Mỗi người dùng gửi
một yêu cầu SIP SUBSCRIBE tới server hội nghị để được thêm vào danh sách thành viên
hiện tại (roster). Bất cứ khi nào một người dùng đăng ký, một bản tin SIP NOTIFY được
phát cho tất cả các thành viên tham gia. Các bản tin NOTIFY này chức một SIP URI định
dạng XML của người dùng mới trong nội dung của một bản tin. Việc này cho biết các thành
viên khác những thành viên mới là ai và làm cách nào để liên lạc với họ.
Khi nhận một yêu cầu NOTIFY các thành thành viên hội nghị mỗi người sẽ gửi một
bản tin SIP INVITE cho URI khám phá mới. Mỗi bản tin INVITE này được xử lý riêng biệt,
với khả năng thương lượng SDP cho phép client xác định mã tốt nhất để sử dụng, cùng với
các cổng sử dụng phù hợp. vì với bất cứ thiết lập phiên IMS nào, mạng lõi có thể xác định
các tài nguyên phù hợp cũng như bắt đầu các cơ chế tính cước cần thiết. Một hồi đáp 200
OK được phát ra bở thành viên mới mỗi khi chấp nhận bản tin INVITE, và phương tiện có
thể bắt đầu qua giữa các user agent.
Được so sánh với kiến trúc đã đề cập trước đó, kiến trúc này cho phép độ linh hoạt
hơn, cho phép các khách hàng với khả năng băng thông không phù hợp và các bộ mã hóa
khác nhau tương tác với nhau. Các phiên chất lượng thấp hơn có thể được thiết lập, mà
không bị ảnh hưởng bởi toàn bộ kinh nghiệm của các thành viên hội nghị khác. Có thể lưu ý
rằng một client chỉ hỗ trợ một bộ con chức năng, đó là voice chỉ có thể vẫn tham gia vào hội
nghị vì mỗi phiên được thương lượng riêng biệt. Ngược lại, một luồng chất lượng thấp hơn
có thể được thiết lập giữa các khách hàng với băng thông khả dụng kém hơn.
c. Overhead báo hiệu
Ngược lại với mô hình server – client đã đề cập trước, lược đồ báo hiệu lai đề cập ở
đây phát triển theo hàm mũ mỗi khi thêm mỗi thành viên mới. Báo hiệu vẫn dựa hoàn toàn
trên SIP cho phép khả năng điều khiển nhiều và các cơ chế tính cước IMS khác nhau được
sử dụng. Tuy nhiên, việc này đặt ra một gánh nặng lớn trên mạng lõi IMS.
d. Overhead lưu lượng
Có một luồng song công giữa mỗi thành viên của hội nghị có nghĩa là có rất nhiều
băng thông được dùng trong hệ thống này. Trong khi toàn bộ băng thông đã dùng đang tăng
theo hàm mũ với mỗi thành viên mới tham gia, băng thông tại mỗi node client chỉ tăng trong
một mô hình tuyến tính vì mỗi thành viên mới tham gia có nghĩa là một luồng song công
mới được tạo ra tại mỗi node khác hàng. Sự tăng băng thông này có thể thấy trong hình
, chỉ ra thông lượng phương tiện trung bình tại mỗi node khách hàng.