Giới thiệu: tại sao có MGCP?
MGCP 1.0
Mô hình kết nối của MGCP
Mô hình kết nối MGCP được xây dựng dựa trên hai đối tượng:
Điểm cuối trong mạng có thể là nơi bắt nguồn hoặc kết thúc một luồng phương tiện Một mạch có khả năng nhận các gói RTP, giải mã và gửi dữ liệu G.711 tới khe thời gian trên đường trục TDM được coi là một điểm cuối Ngoài ra, một thực thể có thể nhận gói RTP và chuyển tiếp đến điểm đến khác cũng được xem là một điểm cuối Trong mạng ATM, bất kỳ thực thể nào có thể nhận hoặc khởi tạo các luồng phương tiện AAL2 cũng được xác định là một điểm cuối.
Mỗi điểm cuối trong MGCP có thể có một hoặc nhiều kết nối, với các trạng thái khác nhau như không hoạt động, gửi phương tiện, nhận phương tiện hoặc cả hai Mỗi kết nối được gắn với một điểm cuối cụ thể, nhưng việc gửi phương tiện được xác định bởi địa chỉ trong SDP, cho phép tạo kết nối từ điểm cuối MGCP đến các địa chỉ IP không nhất thiết phải là điểm cuối MGCP đã khai báo.
12 điểm hoặc điểm-đa điểm Kết nối điểm-đa điểm thường sẽ gửi đến một địa chỉ IP multicast
Mô hình MGCP có ưu điểm mạnh mẽ và khả năng mở rộng vượt trội so với khe thời gian TDM Tuy nhiên, nó lại gặp bất lợi so với TDM ở chỗ các kết nối điểm-đa điểm trong TDM rất dễ thiết lập và ẩn khỏi nguồn Điều này dẫn đến việc các tính năng như giám sát im lặng trong các trung tâm liên lạc hay hệ thống đánh chặn hợp pháp trở nên khó khăn hơn khi triển khai trong MGCP.
Hình: MGCP điểm cuối và kết nối
MGCP sử dụng cú pháp đơn giản cho số nhận dạng điểm cuối, với hai thành phần được tách biệt bởi ký tự ‘@’:
Tiền tố là số nhận dạng duy nhất cho điểm cuối trong cổng, với cấu trúc phân cấp (giao diện, kênh trên giao diện) được phân tách bằng dấu gạch chéo ('/') Các thành phần nhận dạng điểm cuối cục bộ có thể bao gồm bất kỳ ký tự nào ngoại trừ dấu cách và ký tự '@'.
Ký tự '/', '*', và '$' đều có ý nghĩa riêng trong việc xác định giá trị của thành phần Cụ thể, '*' biểu thị cho 'tất cả các giá trị được xác định của thành phần này', trong khi '$' có nghĩa là 'bất kỳ giá trị nào trong số các giá trị được xác định cho thành phần này'.
Tên miền DNS của cổng rất quan trọng Nếu cổng chưa được đăng ký trong DNS và đại lý cuộc gọi yêu cầu tên không phải DNS, tên đó có thể là bất kỳ chuỗi nào bao gồm chữ cái, số và các ký tự ‘.’ hoặc ‘-’, miễn là nó phải duy nhất trên mạng Nhiều nhà cung cấp cũng cho phép sử dụng địa chỉ IP dạng số của cổng, được đặt trong dấu ngoặc vuông (ví dụ: [192.168.1.1]).
Cổng tương tự hai cổng thường sử dụng:
aaln/1@analog-gateway.anydomain.org
aaln/2@analog-gateway.anydomain.org
Trên giao diện trung chuyển TDM, mỗi giao diện xử lý nhiều trung chuyển, với mỗi trung chuyển chứa nhiều mạch, và mỗi mạch được xác định bằng số nhận dạng mạch (ISUP CIC) Nhà cung cấp có thể tận dụng cấu trúc này để tối ưu hóa hiệu suất mạng.
IF3/2/1@large-trunk-gateway.anydomain.org for circuit 1 on trunk 2 of interface IF3
Địa chỉ IF5/4/$@large-trunk-gateway.anydomain.org đại diện cho bất kỳ mạch nào trên trunk 4 của giao diện IF5 Mỗi nhà cung cấp thường áp dụng quy ước riêng cho tên điểm cuối cục bộ; tuy nhiên, việc cấu hình mặt nạ tương ứng trên một đại lý cuộc gọi trở nên dễ dàng miễn là các trình tự được xác định bằng các số nguyên liên tiếp.
Giao thức
Các đại lý cuộc gọi và cổng MGCP thực hiện việc trao đổi 'giao dịch', trong đó bao gồm một lệnh, các phản hồi tạm thời tùy chọn và một phản hồi cuối cùng.
MGCP 1.0 sử dụng định dạng văn bản đơn giản cho các lệnh và phản hồi, bao gồm chín lệnh được trao đổi giữa tác nhân cuộc gọi và cổng đa phương tiện hoặc NAS Mỗi lệnh có một tiêu đề, theo sau là một dòng trống và mô tả phiên, trong đó tiêu đề bao gồm nhiều dòng được phân tách bằng CR, LF hoặc CR + LF.
Một dòng lệnh MGCP bao gồm mã lệnh, mã nhận dạng giao dịch, tên điểm cuối đích (có thể sử dụng ký tự đại diện '*' hoặc '$') và phiên bản giao thức MGCP, được phân tách bằng dấu cách ASCII (0 × 20) hoặc ký tự tab (0 × 09) Ví dụ về một dòng lệnh hợp lệ là 'RQNT 1207 endpoint/1@rgw2567.anydomain.net MGCP 1.0' Lưu ý rằng một số cổng MGCP vẫn đang sử dụng phiên bản MGCP 0.1, phiên bản ngay sau khi IPDC được hợp nhất.
SGCP), nhưng sự khác biệt so với MGCP 1.0 là tối thiểu
Một tập hợp các dòng tham số được định dạng theo kiểu ‘name: value’, trong đó tên tham số bao gồm một hoặc hai chữ cái, theo sau là dấu hai chấm (ví dụ: B: e: mu) Các thông số phổ biến nhất được trình bày trong Bảng 5.1.
Hình 5.7 Các lệnh và phản hồi của MGCP (mỗi giao dịch tham chiếu đến một hoặc nhiều điểm cuối cổng)
Bảng 5.1 Các thông số MGCP phổ biến
Dòng lệnh và dòng tham số không phân biệt chữ hoa chữ thường Mỗi lệnh có thể nhắm đến một hoặc nhiều điểm cuối Các động từ thử nghiệm có thể được thêm vào, với tên bắt đầu bằng chữ 'X'.
RFC 2705 mô tả động từ 'Move' cho 'MoveConnection' trong phần phụ lục, nhưng lệnh này đã bị loại bỏ trong RFC 3435 Hiện tại, nó được cung cấp trong một gói riêng biệt (nháp andreasen-mgcp moveconnection-00.txt) Bên cạnh đó, RFC 3435 cũng định nghĩa động từ 'Mesg' cho lệnh.
‘Message’ được định nghĩa trong RFC 3435, phụ lục B
Mỗi lệnh này sẽ kích hoạt một phản hồi, bao gồm một mã phản hồi gồm 3 chữ số Các lệnh và phản hồi được liên kết bởi một TransactionID
2.2.2: Sự kiện và gói tín hiệu
Định nghĩa và cú pháp
MGCP cung cấp một phương thức đơn giản để đại lý cuộc gọi hướng dẫn các điểm cuối có khả năng tạo tín hiệu cục bộ Nhiều ứng dụng yêu cầu đại lý cuộc gọi nắm bắt các sự kiện cụ thể trong băng tần, chẳng hạn như tín hiệu DTMF, hoặc thông qua các phương tiện chỉ có thể truy cập qua cổng Cổng có khả năng báo cáo thông tin này cho đại lý cuộc gọi thông qua các sự kiện MGCP.
Một gói là một không gian tên được xác định bởi một hoặc nhiều chữ cái, cho phép xác định các sự kiện và tín hiệu mà không lo bị nhầm lẫn với các không gian tên khác Tên của sự kiện hoặc tín hiệu cần có tiền tố là tên gói, phân tách bằng dấu gạch chéo (ví dụ: ‘L / HU’ chỉ đến sự kiện ‘HU’ trong gói ‘L’) Lưu ý rằng tên gói và sự kiện không phân biệt chữ hoa chữ thường, tức là ‘L / HU’ tương đương với ‘L / hu’ hoặc ‘l / hu’.
Các loại tín hiệu
Có ba loại tín hiệu tùy thuộc vào cách chúng tồn tại hay không sau khi được áp dụng:
Tín hiệu bật-tắt (OO) sẽ kéo dài cho đến khi được tắt rõ ràng bởi NotificationRequest với tín hiệu trống hoặc điểm cuối khởi động lại Những tín hiệu này có thể được bật hoặc tắt lặp đi lặp lại, chỉ đơn giản là bật hoặc tắt Một ví dụ điển hình cho điều này là chỉ báo chờ tin nhắn.
Các tín hiệu hết thời gian chờ (TO) sẽ kéo dài cho đến khi chúng bị hủy hoặc sau một bộ hẹn giờ Sự kiện 'hoàn thành hoạt động' sẽ xảy ra khi tín hiệu hết hạn, chẳng hạn như nhạc chuông cho thiết bị cầm tay bị ngắt kết nối thường hết hạn sau 3 phút Sau khi được áp dụng, tính năng gọi lại sẽ dừng lại nếu bị hủy (khi không có chuông trong dòng Tín hiệu), nếu xảy ra sự kiện do NotificationRequest yêu cầu, hoặc nếu hết thời gian Giá trị thời gian chờ cần được xác định bởi gói.
Tín hiệu ngắn gọn (BR) là những tín hiệu rất ngắn mà luôn hoàn thành ngay sau khi điểm cuối bắt đầu thực thi chúng, không phụ thuộc vào các sự kiện tiếp theo hoặc yêu cầu Thông báo.
Gói thông thường
Lớp truyền tải MGCP qua UDP
Các lệnh và phản hồi trong MGCP được truyền tải qua giao thức UDP, với cổng nhận mặc định cho tác nhân cuộc gọi là 2727 và cổng nhận cho cổng là 2427.
Ngăn xếp MGCP cần xử lý việc phát hiện mất gói và thực hiện truyền lại, đồng thời cũng phải nhận diện mất kết nối Hệ thống này dựa vào cơ chế 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 nhiều lần, tức là chỉ thực hiện ‘nhiều nhất một lần’.
Mỗi lệnh trong giao dịch có thể nhận một hoặc nhiều phản hồi tạm thời (1xx) và tối đa một phản hồi cuối cùng Giao dịch bao gồm lệnh, phản hồi tạm thời và phản hồi cuối cùng Mỗi lệnh được xác định bằng một mã giao dịch duy nhất từ 1 đến 999,999.999, mã này được sao chép trong tất cả các phản hồi liên quan Các thực thể MGCP duy trì danh sách các lệnh gần đây đang thực thi và các phản hồi đã gửi.
Các lệnh mới không có trong danh sách 'lệnh đang xử lý' hoặc chưa nhận được phản hồi sẽ được gửi đến công cụ thực thi MGCP để tạo ra phản hồi Số nhận dạng giao dịch sẽ vẫn nằm trong danh sách lệnh đang xử lý cho đến khi phản hồi cuối cùng được tạo ra Sau khi phản hồi cuối cùng được gửi, nó sẽ nằm trong danh sách 'câu trả lời gần đây' cho đến khi hết hạn Quy trình xử lý lệnh này được minh họa trong Hình 5.9.
Hình 5.9 Xử lý một lệnh mới của MGCP
Khi một lệnh được lặp lại bởi một tác nhân cuộc gọi sau khi đã được thực thi, phản hồi tương ứng sẽ được lấy từ đống phản hồi gần đây Thay vì thực hiện lại lệnh, hệ thống sẽ gửi phản hồi đã được lưu trữ, như minh họa trong Hình 5.10.
Nếu bộ máy thực thi chưa phản hồi lệnh đầu tiên, lệnh đó vẫn nằm trong quy trình và tự động tạo phản hồi tạm thời 100 PENDING.
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 quy trình sẽ hết hiệu lực ngay khi bộ máy thực thi MGCP tạo ra phản hồi cuối cùng Tuy nhiên, một mục nhập trong đống phản hồi gần đây sẽ không hết hạn nếu có khả năng nhận lệnh trùng lặp Để đảm bảo tính chính xác, bộ hẹn giờ hết hạn (T-HIST) cần lớn hơn thời gian tối đa của một giao dịch, 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 gói tin trong mạng Giá trị điển hình thường sử dụng là khoảng 30 giây.
MGCP cung cấp cho người gửi lệnh khả năng xác nhận các phản hồi trước đó thông qua thuộc tính xác nhận phản hồi, bao gồm 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ể được xóa ngay lập tức khỏi đống phản hồi gần đây mà không cần gửi lại, nhưng transactionID vẫn nên được giữ trong đống 'dài hạn' để phòng ngừa trường hợp có phần tử mạng nhân đôi gói UDP của lệnh gốc Điều này cho phép MGCP bỏ qua các bản sao mà không cần gửi thêm phản hồi nào.
Hình 5.10 Xử lý một lệnh trùng lặp đã được MGCP thực thi
Hình 5.11 Xử lý một lệnh trùng lặp đã được thực thi
Các thực thể MGCP cần đánh giá thời gian vòng quanh mạng dựa trên khoảng thời gian giữa việc gửi lệnh và nhận phản hồi, bao gồm độ trễ báo nhận trung bình (AAD) và độ lệch trễ trung bình (ADEV) Bộ hẹn giờ cho lệnh đầu tiên có thể được thiết lập là AAD cộng với N nhân ADEV Đối với các lệnh tiếp theo, bộ hẹn giờ thứ k phải được đặt thành AAD nhân 2^k cộng với N nhân ADEV và một thành phần ngẫu nhiên từ 0 đến ADEV, nhằm đảm bảo sự dự phòng theo cấp số nhân trong trường hợp xảy ra tắc nghẽn mạng, với giới hạn trên là B.
Khi đạt đến giới hạn tối đa cho bộ đếm thời gian truyền lại, việc triển khai cần giới hạn số lần R được truyền lại Một kịch bản hoàn chỉnh về quá trình truyền lại được minh họa trong Hình 5.12.
Hình 5.12 Truyền lại lệnh MGCP
2.2.4 Các lệnh MGCP từ đại lý cuộc gọi đến cổng
1 Lệnh cấu hình điểm cuối (EPCF)
Lệnh được gửi từ đại lý cuộc gọi đến cổng để cấu hình loại mã hóa mang ('B:') cho phía dòng, không phải phía VoIP, của một điểm cuối hoặc dải điểm cuối Hai giá trị mã hóa đã được xác định là luật G.711 A ('e: A'; ví dụ: Châu Âu) và luật à ('e: mu'; ví dụ: Hoa Kỳ) Cổng sẽ chỉ phản hồi bằng một mã trả về (Hình 5.13).
Hình 5.13 Ví dụ về lệnh EPCF
2 Lệnh yêu cầu thông báo (RQNT)
Lệnh phức tạp này yêu cầu cổng đa phương tiện theo dõi các sự kiện điện thoại cụ thể, bao gồm âm fax, DTMF, âm liên tục và các tín hiệu trạng thái đường truyền như ngắt kết nối, liên kết và đèn flash-hook Ví dụ về lệnh RQNT được minh họa trong Hình 5.14.
Hình 5.14 Ví dụ về lệnh RQNT / NOTIFY
EndpointId và RequestIdentifier là hai tham số bắt buộc, trong đó RequestIdentifier được dùng để liên kết yêu cầu với các thông báo mà nó kích hoạt Thông thường, lệnh RQNT sẽ bao gồm một số tham số bổ sung.
Tham số N (thực thể được thông báo) quyết định địa chỉ nơi phản hồi được gửi, mặc định là đến người khởi tạo yêu cầu qua cùng địa chỉ IP và cổng UDP Các lệnh khởi tạo cổng được chuyển đến địa chỉ IP của đại lý cuộc gọi, được phân giải từ tên tác nhân cuộc gọi Tham số NotifiedEntity ảnh hưởng đến vị trí gửi thông báo và các lệnh khác từ cổng khởi tạo (như DLCX và RSIP) cho đến khi cổng khởi động lại.
Tham số R là danh sách các sự kiện được phân tách bằng dấu phẩy, trong đó tên sự kiện được xác định trong gói sự kiện MGCP, ví dụ như 'hd' cho quá trình chuyển đổi ngoại tuyến Các chữ số từ 0 đến 9, # và thời gian chờ 4 giây cũng được coi là sự kiện Ký hiệu L được sử dụng để phát hiện tín hiệu DTMF dài, với tín hiệu DTMF được gửi trong thông báo đầu tiên và thông báo tiếp theo sau 2 giây nếu tín hiệu vẫn tồn tại Mỗi sự kiện có thể liên kết với một hoặc nhiều hành động, được chỉ định giữa các dấu ngoặc ngay sau tên sự kiện, bao gồm N để thông báo ngay lập tức (mặc định nếu không có hành động nào được chỉ định), A để cộng dồn, D để tích lũy theo bản đồ chữ số, và S để hoán đổi kết nối phương tiện đang hoạt động sang kết nối tiếp theo.
Một vài khả năng xử lý lệnh
Lệnh cấu hình điểm cuối EPCF
Lệnh được gửi từ đại lý cuộc gọi đến cổng nhằm cấu hình loại mã hóa mang ('B:') cho một điểm cuối hoặc dải điểm cuối, với hai giá trị chính là luật G.711 A ('e: A', thường thấy ở Châu Âu) và luật µ ('e: mu', phổ biến ở Hoa Kỳ) Cổng sẽ chỉ phản hồi bằng một mã trả về (Hình 5.13).
Hình 5.13 Ví dụ về lệnh EPCF
Lệnh yêu cầu thông báo RQNT
Lệnh phức tạp này yêu cầu cổng đa phương tiện theo dõi các sự kiện điện thoại cụ thể, bao gồm âm fax, DTMF, âm liên tục và các tín hiệu trạng thái đường truyền như ngắt kết nối, liên kết và đèn flash-hook Ví dụ về lệnh RQNT được minh họa trong Hình 5.14.
Hình 5.14 Ví dụ về lệnh RQNT / NOTIFY
EndpointId và RequestIdentifier là hai tham số bắt buộc, trong đó RequestIdentifier dùng để liên kết yêu cầu với các thông báo được kích hoạt Thêm vào đó, lệnh RQNT thường bao gồm một số tham số khác.
Tham số N (thực thể được thông báo) xác định rằng phản hồi mặc định sẽ được gửi đến địa chỉ IP và cổng UDP của người khởi tạo yêu cầu, trong khi các lệnh khởi tạo cổng sẽ được chuyển đến địa chỉ IP của đại lý cuộc gọi, được phân giải từ tên tác nhân cuộc gọi Tham số NotifiedEntity ảnh hưởng đến vị trí gửi thông báo và các lệnh khác từ cổng khởi tạo, như DLCX và RSIP, cho đến khi cổng khởi động lại.
Tham số R là danh sách các sự kiện được phân tách bằng dấu phẩy, trong đó tên sự kiện được xác định trong gói sự kiện MGCP, ví dụ như 'hd' cho quá trình chuyển đổi ngoại tuyến Các chữ số từ 0 đến 9, ký hiệu # và thời gian chờ 4 giây cũng được coi là sự kiện Ký hiệu L (thời lượng dài) có thể được sử dụng để phát hiện tín hiệu DTMF dài; tín hiệu này sẽ được gửi trong thông báo đầu tiên và tiếp theo sau 2 giây nếu vẫn tồn tại Mỗi sự kiện có thể liên kết với một hoặc nhiều hành động, được liệt kê trong dấu ngoặc ngay sau tên sự kiện, với các hành động như N để thông báo ngay lập tức (mặc định nếu không có hành động nào khác), A để cộng dồn, D để tích lũy theo bản đồ chữ số, và S để hoán đổi kết nối phương tiện đang hoạt động sang kết nối tiếp theo.
Trong quá trình xử lý yêu cầu thông báo, có thể sử dụng các tham số như I để bỏ qua sự kiện, K để giữ tín hiệu hoạt động, và E để kích hoạt một yêu cầu thông báo nhúng Các tín hiệu thường dừng lại ở sự kiện đầu tiên được phát hiện trong Dòng S của NotificationRequest Một yêu cầu thông báo nhúng áp dụng cho cùng một điểm cuối như NotificationRequest và bao gồm các thông tin cần thiết để thực thi.
• Tham số RequestEvents được nhúng tùy chọn: R (dòng RequestedEvents được nhúng)
• Tham số SignalRequests nhúng tùy chọn: S (yêu cầu tín hiệu) Ví dụ, S (dl)
Bản đồ DigitMap: D (bản đồ chữ số) có thể được nhúng tùy chọn, ví dụ như D ([0–9] [#T]) Trong trường hợp không có bản đồ chữ số nào được nhúng, giá trị hiện tại sẽ được áp dụng.
Hình 5.15 Ví dụ về yêu cầu tín hiệu nhúng và bản đồ số
Tất cả các triển khai MGCP cần hỗ trợ ít nhất một cấp độ nhúng, và hầu hết các triển khai thương mại chỉ hỗ trợ một cấp độ này Trong nhiều trường hợp, một sự kiện sẽ được nhận bởi một cổng ngay trước khi yêu cầu thông báo được gửi đi Nếu không có biện pháp xử lý thích hợp, điều này có thể dẫn đến tình huống chạy đua, khiến sự kiện có thể không được báo cáo cho đại lý cuộc gọi tùy thuộc vào thời điểm xảy ra.
Danh sách cách ly được thiết lập nhằm ngăn chặn tình trạng phân biệt chủng tộc Hơn nữa, trong một số trường hợp, tác nhân cuộc gọi có thể yêu cầu thông báo về các sự kiện liên quan.
Trước khi cổng vào gửi phản hồi đến lệnh RQNT, cần có một điều kiện đúng hoặc đã trở thành đúng, ví dụ như khi một tác nhân cuộc gọi yêu cầu thông báo cho sự kiện off-hook nhưng thiết bị cầm tay không hoạt động Trong tình huống này, cổng sẽ phản hồi với lỗi, chỉ ra trạng thái hiện tại, chẳng hạn như mã lỗi 401 cho biết điện thoại đã tắt.
Tham số D (bản đồ chữ số) là một tập hợp quy tắc thông báo cho cổng tại thời điểm tích lũy hoặc thông báo các chữ số được phát hiện trên máy mang điểm cuối Ví dụ, '00T' đại diện cho một chuỗi chữ số với quy tắc duy nhất, trong khi '(0T | 00T | [1–7] xxx | 8xxxxxxx | #xxxxxxx | * xx | 91xxxxxxxxxx | 9011x.T)' là một chuỗi chữ số với nhiều quy tắc khác nhau.
Cú pháp của mỗi quy tắc bắt nguồn từ lệnh Unix ‘egrep’:
‘[1–4]’ khớp với bất kỳ chữ số nào từ 1 đến 4, bao gồm cả 1 và 4
‘[1–79BT]’ khớp với bất kỳ chữ số nào từ 1 đến 7, hoặc 9, hoặc B, hoặc thời gian chờ
‘x’ khớp với bất kỳ chữ số đơn nào (tương đương với [0–9])
Toán tử dấu chấm ‘x.’ khớp với mọi số lần xuất hiện dương của ký hiệu được chỉ định trước đó Điều này có nghĩa là ‘x.’ hoặc ‘[0–9].’ đại diện cho bất kỳ số chữ số dương nào.
Hình 5.16 Xử lý tình trạng chói với MGCP
Nếu biểu tượng bộ hẹn giờ (T) là sự kiện cuối cùng cần thiết để khớp với quy tắc, thì sự kiện thời gian chờ sẽ được kích hoạt khi âm báo phát hiện cuối cùng xảy ra cách đây hơn 4 giây Điều này đặc biệt quan trọng khi có nhiều chữ số cần khớp sau sự kiện thời gian chờ.
Khi cần ít nhất một chữ số nữa để khớp với bất kỳ quy tắc bản đồ chữ số nào, sự kiện thời gian chờ sẽ chỉ được kích hoạt sau 16 giây Một chuỗi chữ số sẽ được tích lũy cho đến khi nó khớp với một trong các quy tắc hoặc không thể khớp với bất kỳ quy tắc nào nữa Cơ chế tích lũy này được minh họa trong Hình 5.17.
Hình 5.17 Tích lũy sự kiện MGCP (trạng thái bình thường)
Tham số S yêu cầu áp dụng tín hiệu cho điểm cuối, như đổ chuông hoặc nhạc chuông chờ Mặc định, các tín hiệu thời gian chờ sẽ dừng ngay khi một trong các sự kiện trong danh sách được phát hiện, trừ khi có yêu cầu rõ ràng thông qua hành động K để duy trì hoạt động.
Tham số Q (xử lý cách ly) mô tả cách xử lý các tín hiệu nhận được trước yêu cầu thông báo, với mặc định là xử lý chúng, nhưng tác nhân cuộc gọi có thể yêu cầu bỏ qua Tham số này cũng xác định việc gửi một hay nhiều thông báo Sau khi một cổng gửi thông báo, nó chuyển sang trạng thái "thông báo đang chờ xử lý" và bắt đầu tích lũy các sự kiện trong danh sách cách ly, cho đến khi nhận được phản hồi cho lệnh NOTIFY, bất kể thành công hay thất bại Nếu tác nhân cuộc gọi chỉ muốn một thông báo để phản hồi RQNT, cổng sẽ tiếp tục tích lũy các sự kiện cho đến khi hoàn tất.
RQNT tiếp theo Mặt khác, nếu cổng có thể gửi nhiều lệnh NOTIFY liên tiếp, thì nó sẽ xử lý danh sách các sự kiện đã cách ly (Hình 5.19)
