BÁO CÁO TIỂU LUẬN Môn Báo hiệu và điều khiển kết nối Đề tài Giao thức điều khiển cổng đa phương tiện MGCP

BÁO CÁO TIỂU LUẬN Môn: Báo hiệu và điều khiển kết nối Đề tài: Giao thức điều khiển cổng đa phương tiện MGCP Học viện Công Nghệ Bưu chính Viễn thông BÁO CÁO TIỂU LUẬN Môn: Báo hiệu và điều khiển kết nối Đề tài: Giao thức điều khiển cổng đa phương tiện MGCP

Học viện Công Nghệ Bưu chính Viễn thông

BÁO CÁO TIỂU LUẬN Môn: Báo hiệu và điều khiển kết nối

Đề tài: Giao thức điều khiển cổng đa phương tiện MGCP Giảng viên: Hoàng Trọng Minh

Thành viên nhóm 12:

Bùi Văn Hiếu- B18DCVT146

Hồ Khánh Linh- B18DCVT242 Đào Mạnh Quang- B18DCVT330

Hà Nội, tháng 12 năm 2021

Mục lục

Bảng từ viết tắt

Phụ lục Hình và bảng

LỜI NÓI ĐẦU 1

1 Giới thiệu: Tại sao có MGCP? 2

1.1 Các giao thức kích thích (Stimulus protocols) 2

1.2 Cổng phân chia (Decomposed gateways) 3

1.3 Hoàn cảnh lịch sử ra đời (Some history) 5

2 MGCP 1.0 6

2.1 Mô hình kết nối của MGCP 9

2.2 Giao thức 11

2.2.1 Tổng quan 11

2.2.2: Sự kiện và gói tín hiệu 13

2.2.3 Lớp truyền tải MGCP qua UDP 20

2.2.4 MGCP commands from the call agent to the gateway (Các lệnh MGCP từ đại lý cuộc gọi đến cổng) 23

2.2.5 MGCP commands from the gateway to the call agent(Lệnh MGCP từ cổng đến đại lý cuộc gọi) 40

2.3 Xử lý fax 42

2.4 Tiện ích mở rộng để kiểm soát giao diện người dùng điện thoại 47

3 LƯU LƯỢNG CUỘC GỌI MGCP MẪU (SAMPLE MGCP CALL FLOWS) 54

3.1 Thiết lập cuộc gọi (Call set-up) 54

3.2 Âm DTMF (DTMF tones) 59

3.3 Giải phóng cuộc gọi (Call release) 60

4 TƯƠNG LAI CỦA MGCP (THE FUTURE OF MGCP) 62

KẾT LUẬN 64

Bảng từ viết tắt

AAL2 ATM Adaptation Layer 2 ATM thích ứng lớp 2

ATM Asynchronous Transfer Mode Chế độ truyền không đồng bộ

API Application Programming Interface Giao diện lập trình ứng dụng

CTI Computer Telephony Integration Tích hợp điện thoại máy tính

DLCX delete connection Xóa kết nối

DNS Domain Name System Hệ thống tên miền

DTMF Dual-Tone Multi-Frequency Tần số Đa Tần kép

FIFO First in First Out Vào trước ra trước

IETF Internet Engineering Task Force Nhóm đặc nhiệm kỹ thuật Internet ISDN Integrated Services Digital Network Mạng số tích hợp đa dịch vụ

MGCP Media Gateway Control Protocol Giao thức kiểm soát cổng phương tiện

NASS Network Attachment Subsystem Hệ thống con phần đính kèm mạng

SDP Session Description Protocol Giao thức mô tả phiên

SIP Session Initiation Protocol Giao thức khởi tạo phiên

RFC Request for Comments Đề nghị duyệt thảo và bình luận RSIP Restart in progress Khởi động lại

RTP Real-time Protocol Giao thức thời gian thực

TDM Time Division Multiplexing Ghép kênh phân chia theo thời gian

PBX Private Branch Exchange Tổng đài Nhánh Riêng

XML Xtensible Markup Language Ngôn ngữ đánh dấu

NAS Network Access Server Máy chủ truy cập mạng

CR Carriage Return quay lại đầu dòng

ASCII American Standard Code for

Hình 2.3 Hình abcabc: MGCP điểm cuối và kết nối 10

Hình 2.2.1.1 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)

Hình 2.2.5.2.1 RSIP và sự thay đổi của tác nhân cuộc gọi 42

Hình 2.3.1 Xác nhận rằng đầu điều khiển từ xa hỗ trợ fax T.38 44

Hình 2.3.2 Xác nhận rằng đầu điều khiển từ xa hỗ trợ fax T.38 45

Hình 2.3.3 Chuẩn bị cổng để nhận dữ liệu phương tiện T.38 46

Hình 2.3.4 Cổng cục bộ được hướng dẫn để gửi dữ liệu T.38 47

Hình 2.4.1 Màn hình điện thoại với phím chức năng 48 Hình 2.4.2 Màn hình điện thoại IP hiển thị thẻ "home" 52

Hình 2.4.3 Cấu trúc màn hình của điện thoại hỗ trợ Cisco BTXML2

(7960 được hiển thị)

54

Hình 3.1 Cuộc gọi mới nhận được từ mạng SS7 và được truyền đến lõi

VoIP IAM = tin nhắn địa chỉ ban đầu

55

Hình 3.2 Gatekeeper 4 lớp định tuyến cuộc gọi đến R_CA thích hợp 56

Hình 3.3 Thông báo ALERTING được chuyển đổi thành ISUP ACM

ACM bằng địa chỉ hoàn thành Tin nhắn

57

Hình 3.4 Người dùng được gọi nhấc điện thoại 58

Hình 3.5 Bản tin CONNECT được chuyển đổi thành bản tin ISUP

ANM ANM = tin nhắn trả lời59

59

Hình 3.6 Xử lý DTMF ngoài băng tần UII = chỉ60 báo đầu vào của

người dùng

59

Hình 3.7 DTMF được tạo lại bằng cổng trung kế UII = chỉ báo đầu

vào của người dùng

60

Hình 3.8 Một người dùng cuối trên residential gateway MGCP ngắt

cuộc gọi

60

Hình 3.9 Bản tin RELEASE COMPLETE (RLC) được chuyển đổi

thành bản tin ISUP RELEASE (REL)

61

Hình 4.1 Bản tin RELEASE COMPLETE (RLC) được chuyển đổi

thành bản tin ISUP RELEASE (REL)

62

1

LỜI NÓI ĐẦU

Trong những năm gần đây, các nhà mạng ở nước ta như VNPT, Viettel, Mobifone, Vinaphone đang nỗ lực xây dựng và triển khai mạng thế hệ mới nhằm đáp ứng nhu cầu ngày càng tăng của khách hàng về dịch vụ thoại, số liệu, video, multimedia,… Trong giai đoạn này các thiết

bị NGN đang trong giai đoạn cài đặt, chạy thử và từng bước chuyển tải lưu lượng từ mạng truyền thống Cấu trúc mạng NGN của VNPT đã từng bước được định hình, một số giao thức báo hiệu cho mạng NGN cũng được lựa chọn như BICC, SIP, H323… trong đó là MGCP – đang được phát triển

Bằng kiến thức đã học và kiến thức tích lũy được, nhóm em đã nghiên cứu về đề tài

“MGCP – Giao thức điều khiển cổng phương tiện’’

Do khả năng và thời gian chuẩn bị còn hạn chế nên bài tiểu luận chắc chắn không tránh khỏi những thiếu sót, vì vậy nhóm em rất mong nhận được những lời góp ý và nhận xét của các thầy cô giáo bộ môn

2

1 Giới thiệu: Tại sao có MGCP?

1.1 Các giao thức kích thích (Stimulus protocols)

SIP và H.323 là các giao thức trạng thái, dựa trên phiên rất giống nhau Sự giống nhau ẩn đằng sau tất cả sự khác biệt do các cách khác nhau để tuần tự hóa thông tin về cơ bản giống nhau, cả hai giao thức đều có chung các đặc điểm:

 Chúng bao gồm giao thức điều khiển cuộc gọi (H.225.0, SIP) và giao thức điều khiển phương tiện (H.245, mô hình trả lời đề nghị SDP), với giao thức điều khiển phương tiện được gói gọn trong giao thức điều khiển cuộc gọi

 Giao thức điều khiển cuộc gọi là phiên bản đơn giản hơn một chút của ISDN Q.931 (H.225.0), với cách đóng kết nối cơ bản hơn (ba thông báo trong Q.931, chỉ một thông báo trong H.225.0 và SIP mặc dù điều này có thể xảy ra thay đổi vì trình tự đóng một tin nhắn gây ra một số vấn đề)

 Cả giao thức điều khiển cuộc gọi và giao thức điều khiển phương tiện đều giả định một trạng thái hoặc trạng thái cuối 'thông minh'

Nếu SIP hoặc H.323 là ngôn ngữ lập trình, chúng sẽ rất giống với ngôn ngữ BASIC Bạn có thể làm nhiều việc với BASIC miễn là bạn làm những việc mà BASIC có hướng dẫn thích hợp, nhưng bạn có thể làm nhiều việc khác với ngôn ngữ C hoặc với hợp ngữ Nếu một giao thức kích thích là một ngôn ngữ lập trình, nó sẽ là một hợp ngữ cấp thấp Ví dụ:

 Khi bạn cầm điện thoại H.323 hoặc điện thoại SIP, bạn sẽ nhận được nhạc chuông

Khi bạn cầm điện thoại PBX, đôi khi bạn nhận được thông báo như "bạn có thư thoại"

 Trên điện thoại H.323 hoặc SIP, bạn có các nút hoặc đèn tính năng, được mã hóa cứng bởi nhà sản xuất điện thoại, để giữ, chuyển, gọi ba chiều, chỉ báo chờ tin nhắn, v.v Trên điện thoại PBX, bạn có thể muốn để gán bất kỳ tính năng nào cho bất kỳ nút nào, để điều khiển bất kỳ đèn nào, chính xác như bạn muốn

 Trên điện thoại H.323 hoặc SIP (không có phần mở rộng độc quyền), bạn cần nhấc điện thoại hoặc nhấn nút loa để nhận cuộc gọi Trên điện thoại kích thích, loa có thể được kích hoạt từ xa bởi PBX

Giao thức kích thích mang các lệnh cấp thấp hơn ISDN, H.323 và SIP:

+ Đối với cuộc gọi đến, tất cả các giao thức này chỉ cần gửi một tin nhắn "bạn có cuộc gọi mới" và điện thoại sẽ tự đổ chuông Nó cũng dự kiến sẽ gửi lại nhạc chuông ngay sau khi bạn nhận điện thoại Một giao thức kích thích sẽ gửi lệnh 'đổ chuông với kiểu chuông X',

 Đơn giản hóa ảnh hưởng đến ứng dụng PBX

 Tạo điều kiện thuận lợi cho việc quản lý số lượng lớn các điểm cuối, bằng cách giảm thiểu các vấn đề gây ra bởi sự đa dạng của các loại phần mềm được triển khai tại các điểm cuối

 Tạo điều kiện thuận lợi cho việc triển khai tập trung các tính năng hoặc ứng dụng mới, ngay cả những tính năng hoặc ứng dụng tương tác với điểm cuối

 Giúp dễ dàng hơn trong việc lập trình các ứng dụng hoặc dịch vụ nâng cao yêu cầu

sự phối hợp của nhiều điểm cuối, bằng cách tập trung trạng thái của tất cả các điểm cuối tại PBX

Kết luận: Chỉ với H.323 và SIP, VoIP sẽ thiếu giao thức dựa trên kích thích — MGCP lấp

đầy khoảng trống

1.2 Cổng phân chia (Decomposed gateways)

Đặt vấn đề: Trong những ngày đầu của VoIP, hầu hết các cổng VoIP đều dựa trên PC, với

một số bo mạch phần cứng xử lý việc xử lý phương tiện Các cổng như vậy đã được

‘decomposed’ theo nghĩa là các tài nguyên xử lý điều khiển cuộc gọi và điều khiển phương tiện đang chạy trên các mô-đun khác nhau, với một số API độc quyền giữa bảng điện thoại

và phần mềm cổng dựa trên PC chính Ban đầu tất cả các cổng nhúng thường giữ lại kiến trúc này, với bộ xử lý trung tâm xử lý điều khiển cuộc gọi, trong khi bo mạch Bộ xử lý tín

 Trong PSTN, các kết nối nhà cung cấp dịch vụ với hàng nghìn kênh thường sử dụng hàng chục trung kế chỉ đa phương tiện và một kênh chỉ báo hiệu duy nhất (chủ yếu

là SS7 ISUP) mang thông tin điều khiển cuộc gọi cho tất cả các trung kế đa phương tiện Nếu ở phía VoIP, dung lượng yêu cầu đủ lớn để yêu cầu nhiều khung cổng, thì với mỗi cổng có phần mềm điều khiển cuộc gọi cục bộ riêng, sẽ cần một liên kết báo hiệu điều khiển cuộc gọi SS7 và ngăn xếp ISUP trên mỗi khung => quá đắt

Giải pháp:

 Giải pháp 1: Một trong những giao thức độc quyền ban đầu được sử dụng để giải quyết vấn đề này được gọi là Q.931 Một thiết bị điều khiển cuộc gọi chính nhận tín hiệu ISUP SS7 và điều khiển cuộc gọi phân tán tới mỗi cổng đa phương tiện, ở dạng giống Q.931, qua các đường hầm IP

=> giải pháp này vẫn yêu cầu một phiên bản kiểm soát cuộc gọi trong mỗi cổng đa phương tiện

 Giải pháp 2: Một số nhà cung cấp đã nhanh chóng tìm ra giải pháp tốt nhất, đó là có một mô-đun điều khiển cuộc gọi chính và các mô-đun xử lý phương tiện riêng biệt về mặt vật lý chỉ với tài nguyên DSP, giao diện chỉ dành cho phương tiện TDM và giao diện IP

(Điều này hơi giống với kiến trúc dựa trên PC với các bo mạch DSP riêng biệt và điều

khiển cuộc gọi trên PC, ngoại trừ việc các mô-đun hiện đã tách biệt về mặt vật lý, chúng không giao tiếp thông qua API như trong những ngày đầu của PC mà thông qua một giao thức)

=> Để thực hiện một giải pháp như vậy, cần có một giao thức tiêu chuẩn giữa chức năng điều khiển cuộc gọi và cổng đa phương tiện không có điều khiển cuộc gọi Tiêu chuẩn trên thực tế ngày nay là MGCP, được đặt tên hợp lý là ‘Giao thức điều khiển cổng phương tiện’(MGCP)

Nhận xét:

 Điều đáng ngạc nhiên là: cùng một giao thức có thể được sử dụng để kiểm soát điện thoại kích thích và các cổng phương tiện truyền thông dày đặc

5

 Trên thực tế, điện thoại là cổng đa phương tiện giữa micrô + loa và luồng phương tiện VoIP, cộng với một số thành phần giao diện người dùng (điện thoại có móc, bàn phím, các nút, v.v.) Do đó, một giao thức kích thích điện thoại IP nên bao gồm một phần điều khiển cổng phương tiện thuần túy, cộng với một số lệnh tùy chọn điều khiển giao diện người dùng

 Đây chính xác là MGCP: một tập hợp các lệnh cốt lõi để điều khiển phương tiện thuần túy

1.3 Hoàn cảnh lịch sử ra đời (Some history)

 Đề xuất đầu tiên đến từ Bellcore (nay là Telcordia) và Cisco nhằm giải quyết nhu cầu của các nhà khai thác cáp muốn trở thành nhà cung cấp dịch vụ trao đổi nội hạt (CLEC) cạnh tranh bằng cách sử dụng VoIP trên cơ sở hạ tầng HFC của họ => Giao thức điều khiển cổng đơn giản (SGCP) được Cisco giới thiệu vào đầu tháng 5 năm 1998 trong cuộc họp PacketCable (và trong các cơ quan tiêu chuẩn khác, IETF, ITU-T SG 16 và ETSI TIPHON) như một giao thức thay thế hiệu quả về chi phí và phù hợp hơn để thực hiện và

triển khai hơn các triển khai H.323 hiện tại trong bối cảnh thị trường của các nhà khai thác

cáp

 Đề xuất thứ hai, Kiểm soát thiết bị giao thức Internet (IPDC) đã được trình bày cho ITU-T SG 16, ETSI TIPHON và IETF một tháng sau đó IPDC giải quyết ít nhiều các yêu cầu giống như SGCP nhưng với cách tiếp cận truyền tải khác Trong khi SGCP chỉ dựa vào UDP, được tăng cường với các tính năng tin cậy cấp ứng dụng, IPDC đề xuất sử dụng DIAMETER (một phần mở rộng và thay thế RADIUS) để mang các đơn vị dữ liệu giao thức (PDUS) giữa các thực thể tương ứng

 Không lâu trước khi các lực lượng đằng sau hai giao thức này nhận ra rằng bằng cách thống nhất nỗ lực của họ, họ có thể nhận được sự đồng thuận lớn hơn và thúc đẩy việc

áp dụng vị trí của họ Bellcore và Level3 đã đóng một vai trò quan trọng trong việc hợp nhất hai đề xuất này thành MGCP MGCP được đề xuất cho tất cả các nhóm tiêu chuẩn chính: Nhóm công tác Bộ điều khiển cổng vào phương tiện truyền thông (MEGACO) của IETF, ETSI TIPHON và ITU-T SG 16 Ngoài ra, các công ty hỗ trợ giao thức này đã tạo ra một diễn đàn ngành, Diễn đàn Chuyển mạch Đa dịch vụ (http: //www.msforum.org) để phát triển các giao thức và dịch vụ bổ sung Đặc biệt, MGCP đã được mở rộng để hỗ trợ mạng lưới vận chuyển ATM và thoại trên AAL2

6

Hình 1.1 Cây họ Media Gateway Control Protocol + MGCP ban đầu được xuất bản dưới dạng RFC 2705 thông tin, ‘Giao thức điều khiển cổng phương tiện (MGCP)’ phiên bản 1.0; đặc điểm kỹ thuật đã được cập nhật thành RFC 3435 vào tháng 1 năm 2003 Một biến thể của MGCP cũng được sử dụng bởi sáng kiến PacketCable <=> với tên Giao thức báo hiệu cuộc gọi dựa trên mạng (NCS) và đặc điểm kỹ thuật có sẵn trên trang web PacketCable <=> ( hiện tại là PKT-SP-EC-MGCP-I06-

021 127)

+ Sau đó, ITU bắt đầu làm việc trên một thế hệ giao thức kích thích mới, được gọi là H.248, tương đương về mặt chức năng với MGCP

+ Giống như hầu hết các giao thức phương tiện IETF, MGCP sử dụng cú pháp SDP

để thể hiện định dạng, nguồn và đích của các luồng phương tiện

 Nhìn chung, chất lượng của thông số kỹ thuật MGCP tốt hơn chất lượng của thông

số kỹ thuật ban đầu của H.323 và SIP Giao thức đơn giản, tập trung vào phạm vi rõ ràng, có cấu trúc tốt, với lớp truyền tải riêng biệt rõ ràng, mô hình kết nối được xác định rõ và rất ít lỗi trong tiêu chuẩn Không có nhiều tiếng vang về tiếp thị, MGCP đã tiến vào thế giới của các giao thức VoIP và ngày nay nó là một trong những giao thức được triển khai rộng rãi nhất ở tất cả các thị trường mục tiêu ban đầu của nó: cổng dân dụng, điện thoại IP và cổng trục quy mô lớn

2 MGCP 1.0

Giao thức kiểm soát cổng phương tiện lần đầu tiên được chỉ định trong dự huitema-MGCP-v0r1-00.txt và cuối cùng đã được xuất bản dưới dạng MGCP1.0 trong RFC 2705

thảo-7

MGCP là một giao thức chủ-tớ, MGCP được thiết kế để giao diện một bộ điều khiển cổng đa phương tiện , cổng đa phương tiện và hỗ trợ một mô hình điều khiển cuộc gọi tập trung Giao thức dựa trên văn bản, cung cấp một tập hợp các nguyên bản đơn giản

Bộ điều khiển cổng đa phương tiện được gọi là đại lí cuộc gọi trong thuật ngữ MGCP và các cổng phương tiện có thể thuộc nhiều loại khác nhau:

 Các cổng VoIP Cửa ngõ con được thiết kế để trở thành thiết bị cơ sở của khách hàng, thường được kết nối đến một vài đường dây điện thoại analog Các cổng này, bên cạnh khả năng xử lý phương tiện thuần khiết của nó, nó cũng có thể làm nhiệm vụ: khi được kết nối với điện thoại analog hoặc PBXs, nó sẽ tạo điện áp đổ chuông,

để gửi các tín hiệu cụ thể cần thiết để đặt tin nhắn chờ đèn chỉ báo hoặc để gửi thông

tin ID người gọi đến điện thoại Cổng trung chuyển là các cổng mật độ cao kết nối

trung kế truyền thông TDM và mạng VoIP, với chỉ khả năng xử lý phương tiện

 Máy chủ truy cập mạng (NASs) Giao thức MGCP bao gồm một số phần mở rộng

cho phép một đại lý cuộc gọi kiểm soát các tập hợp modem Giao thức cũng có khả

năng điều kiển các cổng cổng thông dụng, có thể hoạt động như một cổng thoại nếu tín hiệu được phát hiện là giọng nói, và cũng có thể chấm dứt cục bộ kết nối modem nếu chúng phát hiện thấy tín hiệu modem Phần mở rộng NAS không còn là một phần của giao thức cơ sở trong RFC 3435; thay thế, chúng được cung cấp như một gói riêng biệt

 Thoại qua cổng ATM: Thiết lập cuộc gọi thoại qua ATM (VoATM) yêu cầu hai

chức năng báo hiệu riêng biệt, giả lập giao thức MGCP và báo hiệu thoại AAL-2 (loại 3) Adtech AX / 4000 cung cấp khả năng mô phỏng cả tín hiệu MGCP và AAL-

2 để mô phỏng luồng cuộc gọi Nó có thể thiết lập tới 600 cuộc gọi đồng thời trên mỗi cổng với tốc độ thiết lập cuộc gọi ít nhất là 40 cuộc gọi mỗi giây Để có tỷ lệ cuộc gọi cao hơn, việc thêm các mô-đun bổ sung là một vấn đề đơn giản Đối với kiểm tra hiệu suất, Adtech AX / 4000 cung cấp các thống kê báo hiệu như số lần gọi thất bại hoặc thành công, đồng thời cung cấp số liệu thống kê về trạng thái cuộc gọi, nguyên nhân thất bại và thời gian thiết lập

MGCP là một giao thức chủ-tớ Đại lí cuộc gọi là một bộ điều khiển trung tâm và các cổng

đa phương tiện là các thiết bị phụ chỉ có thể báo cáo các sự kiện do đại lý cuộc gọi yêu cầu

và thực hiện các lệnh của đại lí cuộc gọi

MGCP không phải là một tùy chọn cho giao thức điều khiển cuộc gọi mạng lõi Nó

là một giao thức rìa như minh họa trong Hình

Hình 2.2 MGCP là một giao thức biên, trong khi SIP hoặc H.323 phải được sử dụng trong

mạng lõi

9

2.1 Mô hình kết nối của MGCP

Thành phần cốt lõi của bộ chuyển mạch điện thoại truyền thống là một bus TDM Mỗi kênh giao diện được kết nối với một khe thời gian trên xe bus Nếu kênh A trên một giao diện gửi tín hiệu đa phương tiện trên khe thời gian 231 của bus TDM (hãy gọi nó là kênh 231), thì bất kỳ kênh B nào trên bất kỳ giao diện nào đang nghe khe thời gian 231 sẽ nhận được bản sao của tín hiệu đa phương tiện này Kết nối song công đầy đủ cho cuộc gọi điện thoại giữa các kênh 231 và 308 được thiết lập nếu kênh 231 nghe khe thời gian 308 và kênh 308 nghe khe thời gian 231 Công tắc truyền thống có thể thực hiện tất cả các chức năng chuyển đổi phương tiện mà nó cần chỉ bằng cách truyền 'gửi các lệnh 'và' lắng nghe 'đối với' các đối tượng 'của kênh giao diện chỉ được xác định bằng một số khe thời gian Chuyển mạch dựa trên gói phức tạp hơn vì thay vì sử dụng bus TDM làm ma trận chuyển mạch, nó sử dụng mạng gói Các điểm đến trên mạng gói được xác định bằng một địa chỉ

và một số tham số, không phải bằng một số nguyên đơn giản Ngoài ra, loại phương tiện cho bộ chuyển mạch TDM luôn là giọng nói được mã hóa 64 K G.711 hoặc dữ liệu rõ ràng, trong khi nó có thể là bất cứ thứ gì đối với bộ chuyển mạch dựa trên gói

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, có thể bắt đầu (nguồn phương tiện) và/hoặc kết thúc (phương tiện giảm xuống) một lưu lượng phương tiện Một mạch có thể nhận các gói RTP, giải mã chúng

và gửi kết quả dữ liệu G.711 tới một khe thời gian trên đường trục TDM là một điểm cuối Một thực thể có thể nhận các gói RTP và chuyển tiếp chúng đến một điểm đến khác là một điểm cuối Trên ATM mạng bất kỳ thực thể nào có thể nhận hoặc bắt đầu các luồng phương tiện AAL2 là một điểm cuối

 Các kết nối (hình 2.3)Mỗi điểm cuối có thể có một hoặc nhiều kết nối, mỗi trong số

đó có thể không hoạt động (không làm gì hết), gửi phương tiện, nhận phương tiện hoặc

cả hai Trong MGCP, mỗi kết nối được gắn với một điểm cuối được đặt tên, nhưng gửi phương tiện đến một địa chỉ do SDP xác định, vì vậy có thể tạo kết nối từ một điểm cuối MGCP đến địa chỉ IP không nhất thiết phải là điểm cuối MGCP đã khai báo Kết nối có thể là điểm-đ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 này thường mạnh mẽ hơn và có khả năng mở rộng hơn nhiều so với khe thời gian kiểu TDM Tuy nhiên, MGCP (giống như tất cả các giao thức VoIP khác) có một điểm yếu so với với mô hình TDM: trong TDM, các kết nối điểm-đa điểm là nguyên bản (tự nhiên), rất dễ dàng thiết lập (mỗi đích 'lắng nghe' khe thời gian nguồn) và ẩn khỏi nguồn Do đó, các tính năng như giám sát im lặng khi liên lạc các trung tâm, hoặc hệ thống

10

đánh chặn hợp pháp trong hệ thống điện thoại, khó xây dựng hơn nhiều so với ở trong TDM

Hình 2.3: hình abcabc: 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ố phải là số nhận dạng duy nhất của điểm cuối trong cổng Các cấu trúc tiền tố

có thể được phân cấp (giao diện, kênh trên giao diện), với mỗi thành phần của cấu trúc phân cấp đượ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ự hiển thị nào ngoại trừ dấu cách, ‘@’,

‘/’, ‘*’ hoặc ‘$’ '*' có ý nghĩa đặc biệt của 'tất cả các giá trị được xác định của thành phần này' và '$' 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 Nếu cổng không được đăng ký trong DNS và đại lý cuộc gọi yêu cầu các tên không phải DNS, khi đó tên phải là bất kỳ chuỗi nào được đặt bằng chữ cái, số và ‘.’ hoặc ‘-’, miễn là nó là duy nhất trên mạng Một vài nhà cung cấp cũng sử dụng địa chỉ IP dạng số của cổng, giữa các dấu ngoặc vuông (ví dụ: [10.10.10.10])

Một cổng analog hai-port thường sử dụng:

 IF3/2/1@large-trunk-gateway.anydomain.org cho mạch 1 trên đường trục 2 của giao diện IF3

 IF5/4/$@large-trunk-gateway.anydomain.org cho bất kì mạch nào trên đường trục 4 của giao diện IF5

Trên thực tế, mỗi nhà cung cấp sử dụng quy ước riêng cho tên điểm cuối cục bộ; nhưng như miễn là các trình tự được xác định bằng các số nguyên liên tiếp, rất dễ dàng định cấu hình mặt nạ tương ứng trên một đại lý cuộc gọi

• Một dòng lệnh, bao gồm mã lệnh, mã nhận dạng giao dịch, tên điểm cuối đích (tùy chọn với các ký tự đại diện của mã nhận dạng điểm cuối cục bộ '*' 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ụ: sau đây là dòng lệnh hợp lệ 'RQNT 1207 endpoint/1@rgw2567.anydomain.net MGCP 1.0') Một số cổng MGCP vẫn sử dụng MGCP 0.1 (phiên bản MGCP ngay sau khi hợp nhất IPDC và 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ố, mỗi dòng sử dụng định dạng ‘name: value’ 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 liệt kê trong Bảng 2.2.1.1

12

Hình 2.2.1.1 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)

2.2.2: Sự kiện và gói tín hiệu

1 Định nghĩa và cú pháp

Một tác nhân cuộc gọi chỉ điều khiển các kết nối phương tiện trên các thiết bị đầu cuối không thể dễ dàng tương tác với thông tin phương tiện (ví dụ: để gửi lại âm quay số tới một cổng tương tự, nhân viên cuộc gọi sẽ cần kết nối điểm cuối cổng với âm quay số dựa trên IP)

14

Hình2.2.1.2: Một lệnh MGCP mẫu

Bảng1: Động từ lệnh MGCP MGCP sử dụng các tín hiệu để cung cấp một cách đơn giản hơn để cho phép một đại lý cuộc gọi đưa ra hướng dẫn cho các điểm cuối có một số khả năng tạo tín hiệu cục

bộ Nhiều ứng dụng cũng yêu cầu đại lý cuộc gọi phải biết về các sự kiện nhất định hiện diện trong băng tần (ví dụ: tín hiệu DTMF) hoặc thông qua một số phương tiện chỉ có thể truy cập vào cổng Cổng có thể báo cáo loại thông tin này cho tác nhân cuộc gọi bằng cách sử dụng các sự kiện MGCP Một gói chỉ đơn giản là một không gian tên, được xác định bằng một hoặc nhiều chữ cái

Các sự kiện và tín hiệu có thể được xác định trong không gian tên này mà không có nguy

15

cơ nhập nhằng với các không gian tên khác Tên sự kiện hoặc tín hiệu phải có tiền tố là tên gói của nó, được phân tách bằng dấu gạch chéo (ví dụ: ‘L / HU’ đề cập đến sự kiện

‘HU’ trong dòng gói ‘L’) 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ó một số trường hợp đặc biệt mà tiền tố gói có thể bị bỏ qua:

 Đại lý cuộc gọi có thể bỏ qua tiền tố cho các sự kiện và tín hiệu là một phần của giá trị mặc định

gói, khi gửi lệnh đến một điểm cuối được biết là hỗ trợ một gói (ví dụ: nếu dòng gói là gói mặc định cho cổng tương tự, thì dl

và L / dl là các tín hiệu tương đương)

 Các sự kiện chữ số có thể được gửi mà không có tiền tố, mặc dù bạn nên gửi chúngvới tiền tố thích hợp (ví dụ: L / 8 cho chữ số 8) Tên gói không được phép chứa các chữ số để ngăn chặn bất kỳ sự mơ hồ nào

Những ngoại lệ này được cung cấp chủ yếu để cho phép MGCP duy trì khả năng chịu đựng với cáctriển khai, nhưng bạn nên luôn bao gồm tiền tố tên gói

Các sự kiện và tín hiệu được phát hiện / áp dụng theo mặc định trên các kênh không xác định được kết nối với các điểm cuối Cũng có thể yêu cầu sự kiện / tín hiệu áp dụng cho một kết nối; trong trường hợp này, số nhận dạng kết nối được thêm vào sau tên sự kiện, được phân tách bằng dấu ‘@’dấu (ví dụ: G / rt @ 234A2)

Các gói MGCP là một khu vực mà RFC 3435 đã mở rộng đáng kể trên RFC 2705; nhiều thứ (mã lý do, hành động, v.v.) có thể được mở rộng trong một gói ngay bây giờ, không chỉ sự kiện và tín hiệu (xem Phần 6 trong RFC 3435)

2 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) kéo dài cho đến khi chúng bị tắt rõ ràng bởi NotificationRequest với dòng 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’ (tương ứng ‘tắt’) lặp đi lặp lại, chúng chỉ đơn giản là ‘bật’ (tương ứng ‘tắt’) Chỉ báo chờ tin nhắn là một ví dụ điển hình

 Các tín hiệu hết thời gian chờ (TO) kéo dài cho đến khi chúng bị hủy bỏ rõ ràng

16

hoặc sau một bộ hẹn giờ Sự kiện 'hoàn thành hoạt động' được tạo ra khi tín hiệu như vậy hết hạn (ví dụ: nhạc chuông được cung cấp khi thiết bị cầm tay bị ngắt kết nối thường sẽ 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 (1) nếu bị hủy (NotificationRequest mới không có chuông trong dòng Tín hiệu), (2) nếu xảy ra sự kiện do NotificationRequest yêu cầu (đây là hành vi mặc định, mặc dù

có thể ghi đè it), hoặc (3) nếu hết thời gian Giá trị thời gian chờ phải được xác định bởi gói

 Tín hiệu ngắn gọn (BR) Các tín hiệu rất ngắn này luôn hoàn thành sau khi điểm cuối bắt đầu thực thi chúng, bất kể các sự kiện tiếp theo hoặc yêu cầu Thông báo

- Một số gói thông thường:

17

Bảng 2: Những gói MGCP chính

- Gói DTMF:

18

- Gói Trunk:

- Gói đường dây:

Các tần số chính xác tương ứng với một số tín hiệu của gói đường dây có thể khác nhau

mỗi quốc gia Các nhà cung cấp thường cung cấp bản địa hóa các tín hiệu này thông qua giao diện cấp phép cổng

19

- Gói thiết bị cầm tay:

Gói mô phỏng thiết bị cầm tay này giống như gói đường truyền, nhưng một số liên quan đến thiết bị cầm tay các sự kiện như ‘off-hook’ và ‘on-hook’ có thể được báo hiệu cũng như phát hiện Cái này hữu ích để cung cấp tính năng tự động ngắt kết nối (kích hoạt loa ngoài), cho điện thoại được điều khiển thông qua CTI (Tích hợp điện thoại máy tính) Điều này cũng cho phép cung cấp các tính năng như phân trang hoặc giám sát em bé từ xa

- Gói RTP:

Các sự kiện này có thể được sử dụng bởi một tác nhân cuộc gọi để có được cái nhìn năng động hơn về phương tiện cổng vào xử lý: ví dụ: một số cổng có thể tự động thay đổi mã của chúng từ nén bộ mã hóa bitrate thấp thành G.711 để fax; sự kiện UC có thể được sử dụng để tìm hiểu rằng điều này xảy ra

20

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

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 hoàn chỉnh được thể hiện trong Hình 2.2.3.4

24

Hình 2.2.4.1.1 Ví dụ về lệnh EPCF

2 Lệnh yêu cầu thông báo (RQNT)( Notification request command (RQNT))

Lệnh rất 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ể Các sự kiện này có thể được phát hiện trong băng tần, chẳng hạn như âm fax, DTMF, âm liên tục, hoặc các tín hiệu trạng thái đường truyền tương tự như ngắt kết nối, liên kết, đèn flash-hook Ví dụ về lệnh RQNT được đưa ra trong Hình 2.2.4.2.1

25

Hình 2.2.4.2.1 Ví dụ về lệnh RQNT / NOTIFY

EndpointId và RequestIdentifier là các tham số bắt buộc, RequestIdentifier được sử dụng để tương quan với yêu cầu và các thông báo mà nó kích hoạt Ngoài ra, lệnh RQNT thường sẽ chứa một số tham số sau:

• Tham số N (thực thể được thông báo): theo mặc định phản hồi được gửi đến người khởi tạo yêu cầu (cùng địa chỉ IP và cổng UDP), và các lệnh khởi tạo cổng được gửi đến địa chỉ IP của đại lý cuộc gọi được phân giải từ tên đại lý cuộc gọi The NotifiedEntity tham số ảnh hưởng đến nơi gửi thông báo và các lệnh khởi tạo cổng khác(ví dụ: DLCX và RSIP), cho đến khi cổng khởi động lại

Tham số R: danh sách các sự kiện được yêu cầu được phân tách bằng dấu phẩy Tên sự kiện được xác định trong gói sự kiện MGCP (ví dụ: 'hd' cho quá trình chuyển đổi ngoại tuyến), các chữ số cũng được coi là sự kiện ([0–9 # T]

có nghĩa là các chữ số từ 0 đến 9 hoặc # hoặc thời gian chờ là 4 s ) Ký hiệu

L (thời lượng dài) cũng có thể được sử dụng để phát hiện các tín hiệu DTMF dài Trong trường hợp này, tín hiệu DTMF được phát hiện sẽ được gửi trong thông báo đầu tiên và thông báo tiếp theo sẽ được gửi sau 2 giây nếu tín hiệu DTMF vẫn tồn tại Mỗi sự kiện có thể được liên kết với một hoặc nhiều hành động được liệt kê giữa các dấu ngoặc ngay sau tên sự kiện Các hành động có thể là N để thông báo ngay lập tức (mặc định nếu không có hành động nào

26

được chỉ định), A để cộng dồn, D để tích lũy theo bản đồ chữ số (xem Hình 2.2.4.2.2), S để hoán đổi kết nối phương tiện đang hoạt động sang kết nối tiếp theo nếu có, I để bỏ qua sự kiện, K để giữ tín hiệu hoạt động (thông thường, các tín hiệu hiện diện trong Dòng S của NotificationRequest dừng ở sự kiện được yêu cầu được phát hiện đầu tiên, xem bên dưới) và E để bật (thực thi) một yêu cầu thông báo được nhúng Một yêu cầu thông báo nhúng (Hình 2.2.4.2.2) áp dụng cho cùng một điểm cuối như NotificationRequest và bao gồm:

• Tham số RequestEvents được nhúng tùy chọn: R (dòng RequestedEvents được nhúng) Ví dụ, R ([0–9 # T] (D), hu (N))

• 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 nhúng tùy chọn Ví dụ: D ([0–9] [#T]) Nếu không có bản đồ chữ số được nhúng, giá trị hiện tại sẽ được sử

dụng

Hình 2.2.4.2.2 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 yêu cầu để hỗ trợ ít nhất một cấp độ nhúng Trong nhiều trường hợp, một sự kiện sẽ được nhận bởi một cổng ngay lập tức trước khi nó nhận được yêu cầu thông báo Nếu không có cách xử lý thích hợp, điều này sẽ dẫn

27

đến một 'tình huống chạy đua' trong đó, tùy thuộc vào thời điểm chính xác, sự kiện có thể được báo cáo hoặc có thể không được báo cáo cho đại lý cuộc gọi "Danh sách cách ly", được thiết kế để tránh tình trạng này Ngoài ra, đôi khi đại lý cuộc gọi sẽ yêu cầu được thông báo về một sự kiện tương ứng với một điều kiện đã đúng hoặc trở thành đúng trước khi cổng vào gửi phản hồi đến lệnh RQNT (điều kiện chói): ví dụ: một đại lý cuộc gọi yêu cầu một thông báo cho sự kiện off-hook (L / hd), nhưng thiết

bị cầm tay đã không hoạt động Trong trường hợp này, cổng phản hồi với lỗi cho biết trạng thái hiện tại (ví dụ: 401 Điện thoại Đã Tắt, như trong Hình 2.2.4.2.3)

• Tham số D (bản đồ chữ số): bản đồ chữ số là một tập hợp các quy tắc thông báo cho cổng vào 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 đích: ví dụ: '00T' là một chuỗi chữ số với một quy tắc duy nhất và '(0T | 00T | [1–7] xxx | 8xxxxxxx | #xxxxxxx | * xx | 91xxxxxxxxxx | 9011x.T) 'là một chuỗi chữ số có nhiều quy tắc 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])

 ‘x.’ (Toán tử dấu chấm) khớp với bất kỳ số lần xuất hiện dương nào của

ký hiệu được chỉ định trước đó Do đó, ‘x.’ Hoặc ‘[0–9].’ Có nghĩa là ‘bất

kỳ số chữ số dương nào’

28

Hình 2.2.4.2.3 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 yêu cầu để khớp với một quy tắc, thì sự kiện thời gian chờ sẽ được kích hoạt nếu âm báo phát hiện cuối cùng xảy ra cách đây hơn 4 giây (bộ hẹn giờ quan trọng) Nếu có nhiều chữ số hơn để khớp sau sự kiện thời gian chờ hoặc 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, thì sự kiện thời gian chờ chỉ được kích hoạt sau 16 giây (bộ đếm thời gian một phần) Một chuỗi chữ số được tích lũy cho đến khi nó khớp với một trong các quy tắc hoặc nếu nó không thể khớp với bất kỳ quy tắc nào nữa (quá đủ tiêu chuẩn) Cơ chế tích lũy được minh họa trong Hình 2.2.4.2.4

29

Hình 2.2.4.2.4 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 (ví dụ: đổ chuông hoặc nhạc chuông chờ) Theo mặc định, các tín hiệu thời gian chờ sẽ dừng ngay khi phát hiện một trong các sự kiện trong danh sách các sự kiện được yêu cầu (trừ khi sự kiện được tuyên bố rõ ràng thông qua hành động K rằng nó nên được duy trì hoạt động)

• Tham số Q (xử lý cách ly): điều này mô tả cách xử lý các tín hiệu nhận được ngay trước yêu cầu thông báo (danh sách cách ly, xem Hình 2.2.4.2.5) Mặc định là xử lý chúng, nhưng đại lý cuộc gọi có thể chỉ định rằng chúng nên được bỏ qua Tham số cũng chỉ định liệu chỉ nên gửi một thông báo hay nên gửi nhiều thông báo Ngay sau khi một cổng gửi một THÔNG BÁO, nó sẽ 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, một loại bộ đệm các sự kiện chưa được xử lý Cổng tiếp tục 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 đối với lệnh NOTIFY (thành công hay thất bại) Nếu đại lý cuộc gọi được chỉ định trong tham số Q mà nó chỉ muốn một THÔNG BÁO để phản hồi RQNT, thì cổng tiếp tục tích lũy các sự kiện cho đến 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 2.2.4.2.6)