a. Kiến trúc
Kiến trúc đầu tiên được thảo luận gồm có một server dùng chung mà mỗi client đều
liên lạc. Luồng phương tiện gồm một luồng song công đơn đó là dòng lưu lượng giữa client
và server. Server nhận mỗi luồng từ mỗi thành viên tham gia trong hội nghị, kết hợp chúng
với sau và sau đó gửi một luồng trộn trở lại mỗi thành viên tham gia. Luồng từ client tới
server, một luồng IP unicast được yêu cầu. Luồng mà server gửi lại có thể là luồng IP
unicast hoặc một luồng multicast mà mỗi client nhận được. Nếu một bộ trộn video phức tạp
hơn được tạo ra, vài luồng multicast khác có thể được cái đặt. Điều này cho phép client
nhận mức chất lượng phù hợp cho kết nối.
b. Báo hiệu.
Trong hai kiến trúc, một SIP AS đã được phát triển. Trong kiến trúc này, nó hoạt
động như một tác nhân người dùng đầu cuối (UA). Mỗi bên tham gia khởi tạo một phiên với
server của chính nó để tham gia vào hội nghị. Việc này hoàn thành khi gửi một yêu cầu SIP
INVITE tới server hội nghị. Tại thời điểm này, mạng IMS lõi xác định nguồn mạng phù hợp
cũng như thông tin tính cước cần thiết. Một server nhận được yêu cầu INVITE nó hồi đáp
với một phản hồi 200 OK. Sau đó người dùng thêm vào danh sách thành viên tham gia
(hoặc bảng phân công) và bắt đầu nhận nguồn video người dùng. Nguồn video này có thể
được gửi trở lại client, được điều khiển theo các chính sách vận hành mạng (đó là với quảng
cáo) hoặc là nó có thể bị trễ đến tận khi có hai hoặc nhiều thành viên tham gia.
c. Overhead báo hiệu
Trong cả hai kiến trúc, báo hiệu SIP thuần túy đã được dùng cho báo hiệu điều khiển.
Việc này cho phép nhà vận hành mạng có một mức điều khiển cao qua các phiên. Đó là
overhead tín hiệu nhỏ nhất trong thực thi này, vì mỗi khách hàng được thiết lập một phiên,
không quan tâm đến số lượng thành viên hiện tại. Điều này có nghĩa là báo hiệu cho mỗi
thành viên duy trì không đổi, và không tăng thêm. Điều này tương phản trực tiếp với việc
tăng trong báo hiệu được đề cập trong kiến trúc P2P
d. Overhead lưu lượng
Độ phân giải của kết quả nguồn video trộn đã được chọn là 640x480. Điều này được
cố định và không phụ thuộc vào việc có bao nhiêu nguồn video chúng ta trộn với nhau (các
nguồn video vào được mở rộng phù hợp). Trong hình 3.11 ta có thể thấy có vài sự thay đổi
nhỏ trong băng thông sử dụng phương tiện vì sự phức tạp của khung video được mã hóa
tăng phụ thuộc vào có bao nhiêu nguồn video đang tồn tại mà ta đã trộn. Ta mã hóa sử dụng
một mã tốc độ bit biến đổi (h263+), mã sử dụng một số lượng băng thông phù hợp phụ
thuộc vào độ phức tạp của bất cứ phần nào được đưa ra.
IMS - Hệ thống hội nghị truyền hình server client
Posted by All 0 Comments
Leave a Reply Cancel Reply