2. MGCP 1.0
2.2 Giao thức
2.2.3 Lớp truyền tải MGCP qua UDP
Các lệnh và phản hồi của MGCP được gửi qua UDP. Cổng nhận mặc định của đại lý cuộc gọi MGCP là 2727 và cổng nhận mặc định của cổng là 2427.
Ngăn xếp MGCP phải xử lý phát hiện mất gói và truyền lại, đồng thời cũng phải phát hiện sự mất kết nối. Cơ chế của MGCP rất phức tạp, nó dựa trên việc truyền lại, nhưng đảm bảo rằng một lệnh nhất định không thể được thực hiện hai lần (‘nhiều nhất một lần’).
Mỗi lệnh có thể nhận được một hoặc nhiều phản hồi tạm thời và nhiều nhất là một phản hồi cuối cùng. Lệnh, phản hồi tạm thời và phản hồi cuối cùng tạo thành một giao dịch. Mỗi lệnh chứa một mã định danh giao dịch từ 1 đến 999,999.999 (bao gồm cả hai), mã này được sao chép trong tất cả các phản hồi liên quan đến lệnh đó. Mỗi thực thể MGCP duy trì một danh sách các lệnh gần đây đang trong quá trình thực thi cục bộ và các phản hồi được gửi gần đây.
Các lệnh mới nhận được, khơng có trong danh sách 'lệnh đang xử lý' hoặc khơng có bất kỳ phản hồi nào trong đống phản hồi gần đây, sẽ được gửi đến công cụ thực thi MGCP, công cụ này sẽ tạo ra phản hồi. Số nhận dạng giao dịch vẫn còn trong đống lệnh đang xử lý cho đến khi phản hồi cuối cùng được tạo. Khi câu trả lời cuối cùng đã được gửi đi, câu trả lời đó vẫn nằm trong đống 'câu trả lời gần đây' cho đến khi hết hạn. Chu trình xử lý lệnh này được minh họa trong Hình 2.2.3.1
21
Hình 2.2.3.1 Xử lý một lệnh mới của MGCP.
Nếu một lệnh được lặp lại bởi một tác nhân cuộc gọi sau khi nó đã được thực thi đầy đủ, thì phản hồi tương ứng đã có trong đống các phản hồi gần đây. Lệnh khơng được thực hiện lại, thay vào đó, phản hồi được lưu trữ sẽ được gửi như trong Hình 5.10.
Mặt khác, nếu bộ máy thực thi chưa tạo ra phản hồi cho lệnh đầu tiên, thì lệnh đó vẫn nằm trong các lệnh trong quy trình và phản hồi tạm thời 100 PENDING được tạo tự động (hoặc 101 trong trường hợp quá tải) . Như trong Hình 5.11, lệnh trùng lặp không được gửi đến bộ máy thực thi.
Một lệnh trong các lệnh trong quy trình sẽ hết hiệu lực ngay sau khi bộ máy thực thi MGCP tạo ra phản hồi cuối cùng. Một mục nhập trong đống phản hồi gần đây sẽ khơng hết hạn nếu vẫn có bất kỳ cơ hội nào mà một lệnh trùng lặp sẽ được nhận. Bộ hẹn giờ hết hạn (T-HIST) phải lớn hơn thời lượng tối đa của một giao dịch có tính đến số lần truyền lại tối đa, độ trễ giữa mỗi lần truyền lại và độ trễ truyền tối đa của một gói trong mạng. Giá trị điển hình được sử dụng thường là khoảng 30s.
MGCP cũng cung cấp một cách để người gửi lệnh xác nhận các phản hồi trước đó: thuộc tính xác nhận phản hồi chứa một loạt các giao dịch đã được xác nhận. Trong trường hợp này, các chuỗi phản hồi tương ứng có thể bị xóa ngay lập tức khỏi đống phản hồi gần đây (sẽ không bao giờ cần phải gửi lại chúng), nhưng transactionID vẫn nên ở trong đống 'dài hạn' trong trường hợp không chắc chắn là một số phần tử mạng nhân đơi gói UDP của lệnh gốc. Điều này cho phép thực thể MGCP bỏ qua bản sao. Khơng có phản hồi nào được gửi.
22
Hình 2.2.3.2 Xử lý một lệnh trùng lặp đã được MGCP thực thi
Hình 2.2.3.3 Xử lý một lệnh trùng lặp đã được thực thi.
Các thực thể MGCP được yêu cầu đánh giá động thời gian vòng quanh mạng từ thời gian trôi qua giữa việc gửi lệnh và nhận phản hồi: ví dụ: chúng có thể đánh giá độ trễ báo nhận trung bình (AAD) và độ lệch trễ trung bình (ADEV). Bộ hẹn giờ truyền lại lệnh đầu tiên sau đó có thể được đặt thành AAD + N * ADEV. Bộ hẹn giờ truyền lại thứ k tiếp theo cho
23
cùng một lệnh phải được đặt thành AAD * 2k + N * ADEV + thành phần ngẫu nhiên (giữa 0 và ADEV), đảm bảo dự phòng theo cấp số nhân trong trường hợp tắc nghẽn mạng, với giới hạn trên B thường được đặt thành 4 s . Khi đã đạt đến giới hạn trên cho bộ đếm thời gian truyền lại, việc triển khai cũng nên giới hạn số R truyền lại. Một kịch bản truyền lại hồn chỉnh được thể hiện trong Hình 2.2.3.4.
Hình 2.2.3.4 Truyền lại lệnh MGCP.