Nhóm 14 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 14:
Bùi Văn Hiếu- B18DCVT146
Hồ Khánh Linh- B18DCVT242
Đào Mạnh Quang- B18DCVT330

1


Mục lục
1. Giới thiệu: tại sao có MGCP? ………………………………4
1.1 : Các giao thức kích thích ………………………………………4
1.2: Các cổng phân chia và sự ra đời của MGCP………………………6
1.3: Một vài lịch sử của MGCP ……………………………………… 7

2. MGCP 1.0 ……………………………………………………… 9
2.1: Mơ hình kết nối của MGCP……………………………………… 11
2.2: Giao thức ………………………………………………………14
2.2.1: Tổng quan………………………………………………………14
2.2.2: Sự kiện và gói tín hiệu……………………………………………17
1. Định nghĩa và cú pháp………………………………………… 17
2. Các loại tín hiệu…………………………………………………17
3. Gói thơng thường……………………………………………18
2.2.3: Lớp truyền tải MGCP qua UDP………………………………… 19
1. Các lệnh phản hồi của MGCP được gửi qua UDP……………19

2. Một vài khả năng xử lý lệnh……………………………………21
2.2.4: Các lệnh MGCP từ đại lý cuộc gọi đến cổng………………………22
1. Lệnh cấu hình điểm cuối EPCF

………………………………22

2. Lệnh u cầu thơng báo RQNT

………………………………23

Tìm hiểu tham số của lệnh RQNT
2


3. Tạo lệnh kết nối CRCX…………………………………………30
4. Sửa đổi lệnh kết nối MDCX……………………………………35
5. Xóa lệnh kết nối DLCX…………………………………………35
6.Lệnh kiểm tra điểm cuối AUEP

………………………………36

7.Lệnh kết nối kiểm tra AUCX……………………………………36
2.2.5: Lệnh MGCP từ cổng vào đại lý cuộc gọi…………………………38
1. Thông báo lệnh………………………………………………38
2. Lệnh khởi động lại trong tiến trình………………………………39
2.3: Tiện ích mở rộng để kiểm soát giao diện người dùng điện thoại…… 40
 Các giả định để đưa ra một thỏa hiệp tốt ………… …… 40
 Các giả định để kiểm soát điện thoại của các gói MGCP.. 41

3: Lưu lượng cuộc gọi MGCP mẫu………………………………42

1. Thiết lập cuộc gọi
2. Âm DTMF

…………………………………………42

………………………………………………46

3. Giải phóng cuộc gọi…………………………………………449

4: Tương lai của MGCP…………………………………………46

3


1 Giới thiệu: tại sao có MGCP?
1.1 Các giao thức kích thích
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' (tức là, một điểm cuối triển khai máy trạng
thái cuộc gọi của chính nó và logic riêng của nó, chẳng hạn như để xử lý cuộc gọi chờ,
cung cấp một chuông- âm trở lại khi ngắt kết nối, v.v.)

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.

4


PBX là tên viết tắt của cụm từ tiếng Anh Private Branch Exchange (Tổng đài Nhánh Riêng), là một
mạng điện thoại riêng được sử dụng trong phạm vi một công ty. Những người sử dụng hệ thống điện
thoại PBX dùng chung một số đường điện thoại ngoài để thực hiện các cuộc gọi ra bên ngồi.

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ự đổ chng. 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 'đổ chng với kiểu chng X', sau đó
lệnh "thơng báo cho tơi nếu ai đó nhấc thiết bị cầm tay" (hoặc nó có thể gửi trực tiếp lệnh "kích
hoạt loa").
+ Đối với một cuộc gọi đi, sau khi được thông báo rằng thiết bị cầm tay bị ngắt kết nối, PBX
sẽ gửi một lệnh "play dial-tone", theo sau là một lệnh "thông báo cho tôi về các chữ số đã được
quay số" (nhưng nó cũng có thể gửi một lệnh 'phát lệnh tin nhắn âm thanh này').

Ưu điểm:
 Chúng đơn giản hóa thiết kế phần mềm điểm cuối và do đó giảm thiểu số lượng lỗi điểm
cuối có thể ảnh hưởng đến ứng dụng PBX
 Chúng 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.
 Chúng 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.
 Chúng 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.
Nhược điểm:
 Chúng hoàn toàn yêu cầu tài nguyên tập trung: hai điện thoại giao thức kích thích khơng
thể liên lạc nếu khơng có PBX.
 Ngồi ra, vì mức độ chi tiết của giao tiếp với bộ điều khiển cuộc gọi ở mức rất thấp, các
dịch vụ yêu cầu nhiều thông báo điều khiển hơn đáng kể so với các điểm cuối thông
minh .
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
lấp đầy khoảng trống.

5

MGCP


1.2 Cổng phân chia
Đặ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
hiệu kỹ thuật số (DSP) chuyên dụng xử lý phương tiện. Nhưng khi kích thước của các cổng
lớn lên để xử lý hàng trăm, hoặc hàng nghìn kênh, kiến trúc này bắt đầu có vấn đề:
 Khi đã đạt đến số lượng tối đa các ‘bo mạch con’ DSP trong một khung, một
khung khác cần được lắp đặt không chỉ với các bo mạch DSP mà còn cả một
phiên bản mới của phần mềm điều khiển cuộc gọi cổng vào. Điều này làm cho
khơng thể kiểm sốt tập trung tất cả các kênh và buộc phải trùng lặp các tài
nguyên kiểm soát cuộc gọi.
 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

6

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 số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.
 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 của MGCP
 Đề 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

7


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.

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-ECMGCP-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.

8


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ự thảo-huitemaMGCP-v0r1-00.txt và cuối cùng đã được xuất bản dưới dạng MGCP1.0 trong RFC 2705
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 đổ chng, để 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ế
•Máy chủ truy cập mạng (NAS). 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

9


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à giao thức ngang hàng: hai đại lý cuộc gọi MGCP không thể giao
tiếp bằng MGCP. MGCP đại lý cuộc gọi chỉ có thể ở rìa của một mạng và phải giao tiếp với
nhau bằng cách sử dụng giao thức điều khiển cuộc gọi khác (ví dụ: H.323 hoặc SIP).
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

10


2.1. 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, có thể bắt nguồn (nguồn phương tiện) và/hoặc kết thúc (phương tiện giảm
xuống) một phương tiện lưu lượng. 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. 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 (ko 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-

11


đ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 đá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: 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ự ‘@’:

12


 Tiền tố phải là số nhận dạng duy nhất của điểm cuối trong cổng. Cáccấ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 vng (ví dụ:

[10.10.10.10])
Cổng tương tự hai cổng thường sử dụng:


aaln/



aaln/
Trên giao diện trung chuyển TDM, nơi mỗi giao diện xử lý nhiều trung chuyển và mỗi

trung chuyển có nhiều mạch, mỗi mạch có số nhận dạng mạch của nó (được tham chiếu bởi
ISUP CIC), nhà cung cấp có thể sử dụng:
 IF3/2/ for circuit 1 on trunk 2 of interface IF3.
 IF5/4/$@large-trunk-gateway.anydomain.org for any circuit on trunk 4 of interface 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

13


2. Giao thức
2.2.1 Tổng quan
Các đại lý cuộc gọi và cổng MGCP trao đổi 'giao dịch', 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 (Hình 5.7).
Các lệnh và phản hồi sử dụng định dạng văn bản đơn giản. MGCP 1.0 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 (từ nay thường được gọi là
'cổng'). Mỗi lệnh bao gồm một tiêu đề, theo sau là một dịng trống và mơ tả phiên. Tiêu đề bao
gồm nhiều các dòng (được phân tách bằng CR, LF hoặc CR + LF):

• 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/ 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 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).

14


15


Bảng 5.1 Các thơng số MGCP phổ biến
K
B
C
I
N
X
L
M
R
S

D
O
P
E
Z
Z2
I2
F
Q
T
RM
RD
A
ES
MD

ResponseAck
BearerInformation
CallId
ConnectionId
NotifiedEntity
RequestIdentifier
LocalConnectionOptions
ConnectionMode
RequestedEvents
SignalRequests
DigitMap
ObservedEvents
ConnectionParameters
ReasonCode

SpecificEndpointID
SecondEndpointID
SecondConnectionID
RequestedInfo
QuarantineHandling
DetectEvents
RestartMethod
RestartDelay
Capabilities
EventStates
MaxMGCPDatagram

Dịng lệnh và dịng tham số khơng phân biệt chữ hoa chữ thường. Mỗi lệnh nhắm mục tiêu một
hoặc nhiều điểm cuối.Các động từ thử nghiệm cũng có thể được thêm vào, tên của chúng phải
bắt đầu bằng chữ ‘X’.
RFC 2705 cũng mô tả động từ ‘Move’ cho ‘MoveConnection’ trong phần phụ lục. Lệnh này đã
biến mất trong RFC 3435; nó hiện được cung cấp trong một gói riêng biệt (nhápandreasenmgcp moveconnection-00.txt). Ngồi ra, RFC 3435 đị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.

16


2.2.2: Sự kiện và gói tín hiệu
1: Định nghĩa và cú pháp
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 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’).

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 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 chng đượ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ó chng 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 ln hồ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.

17


3: Gói thơng thường

Nhiều gói đã được xác định. Bảng dưới đây là danh sách một số gói chính

 Gói phương tiện chung
Kể từ RFC 3435, các gói hiện có số phiên bản, phiên bản gốc là số không. Phiên bản
gốc của gói phương tiện chung là phiên bản 0, phiên bản hiện tại là phiên bản 1.
 Gói DTMF
 Gói thân cây
 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 vào.
 Gói mơ phỏng 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ố sự kiện
liên quan đến thiết bị cầm tay như ‘off hook’ và ‘on-hook’ có thể được báo hiệu cũng như phát
hiện. Điều này rất hữu ích để cung cấp tính năng ngắt kết nối tự động (kích hoạt điện thoại có
loa), cho điện thoại được điều khiển 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.

18


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

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 tác nhân
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 phải phát hiện mất
kết nối. 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 (1xx) 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 5.9.

19


Hình 5.9 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 30 s.
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.

20


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 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 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

21


đượ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
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 này được gửi bởi đại lý cuộc gọi đến cổng để định cấu hình loại mã hóa mang (‘B:’) để
mong đợi và gửi ở phía dịng (tức là khơng ở phía VoIP) của một điểm cuối hoặc một dải điểm
cuối. Hai giá trị được xác định cho đến nay là luật G.711 A (‘e: A’; ví dụ: Châu Âu) hoặc luật
µ (‘e: mu’; ví dụ: ở Hoa Kỳ). Cổng chỉ phản hồi bằng một mã trả về (Hình 5.13).

22


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

2. Lệnh u cầu thông báo (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 flashhook. Ví dụ về lệnh RQNT được đưa ra trong Hình 5.14.

23


Hình 5.14 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. Ngồ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 tác nhân cuộc gọi. Tham số NotifiedEntity ảnh
hưởng đến nơi gửi thông báo và các lệnh khác do cổng khởi tạo (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 q 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 được chỉ định), A để cộng dồn, D để tích lũy theo bản
đồ chữ số (xem Hình 5.15), S để hốn đổi kết nối phương tiện đang hoạt động sang kết nối tiếp

24


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 u cầu
thơng báo nhúng (Hình 5.15) á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 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 yêu cầu để hỗ trợ ít nhất một cấp độ nhúng. Hầu hết các triển
khai thương mại hỗ trợ chính xác một. 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 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 đế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 giải thích bên dưới, được thiết kế để tránh tình trạng chủng tộc này.
Ngồi ra, đơi khi tác nhân 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

25