Các kịch bản: Sự phối hợp điều khiển giữa MG và MGC

Chương III Các kịch bản 3.1 Giới thiệu Sự phối hợp điều khiển giữa MG và MGC được thiết lập tại thời điểm MG khởi động và được thông báo bởi bản tin ServiceChange, nhưng có thể bị thay đổi bởi các sự kiện sau đó như các sự kiện lỗi hay do người vận hành thay đổi. Mặc dù giao thức không có một cơ chế rõ ràng để hỗ trợ nhiều MGC cùng điều khiển một MG vật lý nhưng nó được thiết kế để hỗ trợ nhiều MG logic (trong cùng một MG vật lý) và có thể phối hợp với các MGC khác nhau. H.248\MEGACO cung cấp các cơ chế giải quyết các vấn đề liên quan đến giao diện điều khiển MG-MGC như sau: Thoả thuận về phiên bản của giao thức cho phép các MG và MGC có thể cài đặt các phiên bản giao thức khác nhau vẫn có thể giao tiếp với nhau. Lệnh ServiceChange đầu tiên từ MG sẽ chứa số phiên bản của giao thức mà MG hỗ trợ trong tham số ServiceChangeVersion. Sau khi nhận được bản tin này, nếu MGC chỉ hỗ trợ phiên bản thấp hơn thì nó sẽ gửi một bản tin ServiceChangeReply với phiên bản thấp hơn và sau đó tất cả các bản tin giữa MG và MGC sẽ theo phiên bản thấp hơn. Nếu MG không đồng ý nó sẽ thiết lập một kết nối truyền tải tới MGC để thông báo lỗi, sau đó nó sẽ ngắt kết nối này. Nếu MGC hỗ trợ phiên bản giao thức cao hơn MG nhưng có thể hỗ trợ phiên bản thấp hơn của MG, nó sẽ gửi bản tin ServiceChangeReply trả lời chấp nhận phiên bản thấp hơn, sau đó tất cả các bản tin giữa MG và MGC sẽ theo phiên bản thấp hơn. Nếu MGC không hỗ trợ phiên bản giao thấp hơn của MG nó sẽ từ chối phối hợp và thông báo lỗi. Xử lý khi MG bị lỗi. Nếu một MG bị lỗi nhưng có thể gửi một bản tin tới MGC, nó sẽ gửi lệnh ServiceChange để MGC xử lý bằng phương pháp thích hợp (thoả thuận-graceful hay bắt buộc-forced) và xác định TermiantionID gốc. Khi nó hoạt động trở lại nó sẽ gửi lệnh ServiceChange với phương pháp “restart”. Giao thức cho phép MGC gửi các bản tin giống nhau tới các cặp MG cho mục đích dự phòng. Chỉ có các MG hoạt động mới chấp nhận hay từ chối các phiên. Khi có lỗi xảy ra, MG gửi lệnh ServiceChange tới MGC thông báo về tình trạng lỗi và nguyên nhân lỗi. Sau đó MGC sẽ sử dụng MG thứ cấp để hoạt động. Khi đã sửa lỗi, MG sơ cấp sẽ gửi lệnh ServiceChange với phương thức “Restart” để hoạt động trở lại. Xử lý khi MGC bị lỗi. Nếu MG phát hiện ra MGC đang điều khiển nó bị lỗi, nó sẽ cố gắng liên lạc với MGC khác trong danh sách các MGC có thể điều khiển nó để chuyển quyền điều khiển nó cho một MGC khác. Khi MGC sơ cấp bị lỗi nó sẽ bắt đầu với MGC thứ cấp đầu tiên. Phần tiếp theo sẽ tập trung đi sâu vào các kịch bản khởi tạo MG, thiết lập và giải phóng cuộc gọi. 3.2 Khởi tạo MG (khởi động lạnh) MG được cung cấp một cơ chế quản lý gồm một MGC sơ cấp và một danh sách các MGC thứ cấp. Tại thời điểm khởi động, MG phát lệnh ServiceChange với phương thức “Restart” trên Termination gốc tới MGC sơ cấp của nó. Nếu MGC chấp nhận MG nó sẽ gửi Transaction Accept chứa ServiceChangeMgcId được thiết lập cho chính nó. Nếu MG nhận được ServiceChangeMgcId không trùng với MGC mà nó kết nối thì nó sẽ gửi lệnh ServiceChange tới MGC được xác định trong ServiceChangeMgcId. Quá trình này tiếp tục cho đến khi có một MGC chấp nhận đăng ký của MG hoặc MG bị lỗi khi nhận trả lời. Trường hợp MG bị lỗi khi nhận trả lời từ MGC sơ cấp thì MG sẽ thử với các MGC thứ cấp theo một thứ tự trong danh sách. Nếu MG không thể thiếp lập một mối quan hệ điều khiển với bất kỳ MGC nào thì nó sẽ đợi một khoảng thời gian mặc định (như mô tả ở phần 9.2 của RFC 3015) sau đó lại bắt đầu liên lạc với MGC sơ cấp rồi có thể với cả các MGC thứ cấp trong danh sách. Đáp ứng cho lệnh ServiceChange với phương thức “Restart” có thể bị mất và MG nhận được một lệnh trước khi nhận được đáp ứng cho lệnh ServiceChange. MG sẽ phát lỗi 505 - Command Received before Restart Response. Như vậy, có 3 trường hợp khởi tạo khác nhau: Trường hợp thông thường (MGC sơ cấp) Không có đáp ứng từ MGC sơ cấp Không có đáp ứng từ MGC sơ cấp hay thứ cấp. Sau đây ta sẽ lần lượt xem xét cả 3 trường hợp trên. 3.2.1 Khởi tạo MG, trường hợp thông thường (MGC sơ cấp) Trong trường hợp này, MGA gửi lệnh ServiceChange tới MGC sơ cấp theo phương thức Restart trên termination gốc. MGC nhận được bản tin ServiceChange của MGA và gửi lại bản tin phản hồi ServiceChangeReply thông báo tới MGA rằng nó chấp nhận sự khởi động của MGA. 3.2.2 Khởi tạo MG, không có đáp ứng từ MGC sơ cấp Khi không có đáp ứng từ MGC sơ cấp lần đầu tiên, MGA sẽ đợi trong một khoảng thời gian nhất định rồi thử liên lạc lại một lần nữa. Nếu không có đáp ứng từ MGC sơ cấp thì MGA sẽ liên lạc với MGC thứ cấp. Trong trường hợp này MGC 2 là MGC thứ cấp, khi nhận được bản tin ServiceChange của MGA nó gửi bản tin ServiceChangeReply lại cho MGA để thông báo cho MGA rằng nó đã chấp nhận sự đăng nhập của MGA. 3.2.3 Khi không có đáp ứng của cả MGC sơ cấp và MGC thứ cấp Nó sẽ liên lạc lại với MGC sơ cấp sau một khoảng thời gian ngâu nhiên, thời gian này là từ 0 đến T (T là độ trì hoãn lớn nhất, phụ thuộc vào kiểu MG). Nếu không thể liên lạc được với MGC sơ cấp thì MGA sẽ liên lạc với các MGC thứ cấp. Để ngăn ngừa trường hợp nhiều MG sử dụng thời gian ngâu nhiên như nhau trong cùng một thời điểm khi liên lạc với cùng một MGC, các MG phải sử dụng chung một giải thuật thời gian giống nhau. 3.2 Thiết lập cuộc gọi Sau khi MGA đăng nhập được vào quyền điều khiển của một MGC, MGC sẽ điều khiển thiết lập cuộc gọi cho MGA. Quá trình thiết lập cuộc gọi bao gồm việc thiết lập kênh TDM, thiết lập phiên RTP, các thuộc tính của các luồng media mà MGA gửi cho thực thể từ xa. Quá trình được thực hiện thông qua các bước sau: Bước 1: MGC gửi lệnh ADD tới MGA, thiết lập một context mới đồng thời cộng một termination vật lý (đại diện bởi một khe thời gian TDM được xác định bởi MGC) vào trong đó, với địa chỉ IP và số cổng UDP chưa xác định (kí hiệu là $). Termination vật lý đựơc xác lập ở chế độ không hoạt động. Bước 2: MGA trả lời MGC bằng một đáp ứng ADD Reply kèm theo Ctxt_id là địa chỉ của context mới thiết lập, đồng thời thông báo cho MGC biết là quá trình tạo termination vật lý đã thành công, với địa chỉ IP và số cổng UDP dành cho kênh TDM. Bước 3: MGC gửi lệnh ADD thứ hai tới MGA, yêu cầu MGA thiết lập một termination nhất thời (với thuộc tính phiên RTP) và cộng nó vào context ở trên. Bước 4: MGA trả lời MGC bằng một đáp ứng ADD Reply, trong đó thông báo rằng phiên RTP đã được thiết lập thành công, với địa chỉ IP và số cổng UDP dành cho lưu lượng. Bước 5: MGC gửi tới MGA lệnh Modify, yêu cầu MGA thiết lập các thuộc tính của các luồng media mà MGA gửi cho thực thể từ xa, kích hoạt chế độ của hai termination vật lý và nhất thời trong context là nhận và gửi. Bước 6: MGA trả lời MGC bằng lệnh ModifyReply, thông báo việc kích hoạt kênh TDM và phiên RTP với các đặc tính đã thống nhất đã thành công. 3.3 Giải phóng cuộc gọi Quá trình giải phóng cuộc gọi thực hiện việc giải phóng phiên RTP và kênh TDM mà cuộc gọi chiếm giữ, trả lại tài nguyên cho mạng. Quá trình này có thể thực hiện theo các kịch bản sau: 3.3.1 Giải phóng cuộc gọi, kịch bản 1 Trong kịch bản này MGC thực hiện thiết lập phiên RTP ở chế độ không hoạt động trước khi xoá nó cùng với kênh TDM trong context. Các bước cụ thể như sau: Bước 1: MGC gửi lệnh Modify tới MGA, yêu cầu MGA thiết lập Termination nhất thời (Eph) ở chế độ không hoạt động. Bước 2: MGA gửi lệnh đáp ứng của nó ModifyReply thông báo với MGC là việc thiết lập đã thành công. Bước 3: MGC gửi lệnh Subtract tới MGA yêu cầu xoá 2 termination trong context, đồng thời xoá luôn context. Các số liệu thống kê mà MGC yêu cầu được chỉ ra trong Audit descriptor. Bước 4: MGA thực hiện lệnh và gửi Reply cho MGC thông báo việc xoá đã thành công và trả lại cho MGC các thông tin thống kê về liên kết vừa thiết lập. 3.3.2 Giải phóng cuộc gọi kịch bản 2 Trong kịch bản này, MGC giải phóng cuộc gọi tương tự như trên. Có một điểm khác kịch bản trên là việc xoá các termination được thực hiện trong hai bước. Ban đầu là xoá termination nhất thời sau đó là xoá termination vật lý và context. 3.3.3 Giải phóng cuộc gọi kịch bản 3 Kịch bản này, MGC thực hiện việc giải phóng cuộc gọi theo một thủ tục gọn nhẹ nhất. MGC giải phóng cuộc gọi bằng cách xoá các termination và context chỉ bằng duy nhất một lệnh Subtrac. 3.4 AuditValue Ngay sau khi cuộc gọi được giải phóng, bước kiểm tra giá trị AuditValue được MGC thực hiện để yêu cầu MGA gửi lại các giá trị thống kê hoạt động của các termination. MGC gửi lệnh AuditValue tới MGA yêu cầu trả lại các trạng thái hiện tại của các thuộc tính, sự kiện, tín hiệu và thống kê vủa các Termination TDM và RTP. MGA đáp trả MGC bằng lệnh AuditValueReply, trong đó kèm theo các giá trị hiện tại của các termination TDM và RTP về các thuộc tính, sự kiện, tín hiệu và thống kê (số gói nhận, số gói gửi, số gói mất...). Các số liệu này được MGC lưu trữ để phục vụ quá trình tính cước...