- Gĩi thiết bị cầm tay:
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
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.
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
Hình 2.2.3.2 Xử lý một lệnh trùng lặp đã được MGCP thực thi MGCP entity Commands in process Repeated command 12347 Response: 100 12347 Pending ] 12347 MGCP execution engine 1234 5 200OK 1234 6 200OK 1234 8 200 Recent
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.