Chương 4:
Các giao thức điều khiển kênh
m
ạng
- ITU-T Q1970: “BICC IP bearer control protocol ”, định
nghĩa giao thức điều khiển kênh mang BICC IP (IPBCP). IPBCP
được sử dụng cho việc trao đổi các thuộc tính kết nối media
stream, số cổng, địa chỉ IP để thiết lập và thay đổi các kênh mang
IP. Thông tin trao đổi bằng IPBCP được thực hiện trong hoặc sau
giai đoạn thiết lập cuộc gọi BICC. IPBCP sử dụng giao thức mi
êu
t
ả phiên (SDP) được định nghĩa trong RFC 2327 để mã hóa các
thông tin c
ần trao đổi.
- ITU-T Q1970: “Bearer Control Tunneling Protocol” định
nghĩa giao thức điều khiển kênh mang BICC theo phương pháp
đường hầm. Đây l
à một kỹ thuật đường ngầm chung để chuyển tải
thông tin của các giao thức điều khiển kênh mang (Bearer Control
Protocol-
BCP) theo phương pháp nằm ngang qua giao diện BICC
giữa các CCU (Call Control Unit) và theo phương thức nằm dọc
qua giao diện CBC giữa CCU và BCU (Bearer Control Unit).
2.1.9 ITU-T Q.765.5
Q.765 có tên là “Signalling System No.7 – Application
Transport Mechanism” là ph
ần bổ sung của ISUP. Q. 765 cung cấp
kỹ thuật truyền tải cho các ứng dụng có yêu cầu kênh mang và liên
k
ết báo hiệu. Kỹ thuật truyền tải này có năng lực truyền tải như
chuyển tải báo hiệu đã được ITU-T định nghĩa.
- ITU-T Q 2150.1: “Signalling Transport Converterr on
MTP3 & MTP3b ”, ch
ỉ thị bộ chuyển đổi phương thức chuyển tải
báo hiệu trên MTP3 & MTP3b. Bộ chuyển đổi này sử dụng các
dịch vụ được cung cấp bởi lớp MTP của hệ thống báo hiệu số 7.
Mục đích của tiêu chuẩn này là cung cấp một giao thức có thể sử
dụng trong môi trường ISDN hoặc B- ISDN để chuyển tải báo
hi
ệu. Cụ thể hơn giao thức này cung cấp dịch vụ chuyển tải báo
hiệu chung cho AAL type 2 và BICC.
- ITU-T Q. 2150.2 “Signalling Transport Converteron
SSCOP& SSCOPMCE” b
ộ chuyển đổi phương thức chuyển tải
báo hiệu
Trên SSCOP và SSCOPMCE. Bộ chuyển đổi này có thể được
triển khai trên bất kỳ giao thức nào hỗ trợ SSCOP (AAL type 2
hoặc AAL type 5 )hoặc SSCOPMCE (kết nối đa AAL type 5 hoặc
IP với DIFFSERV). Mục đích của tiêu chuẩn này là cung cấp một
giao thức có thể sử dụng trong môi trường B- ISDN ATM hoặc
môi trường phi kết nối để chuyển tải thông tin báo hiệu (cụ thể l
à
AAL type 2 và BICC).
ITU-T Q. 2150.3: “signalling transport converter on SCTP ”
ch
ỉ thị phương thức chuyển đổi chuyển tải báo hiệu trên SCTP.
2.1.11. Kết luận
Phần này đã trình bày tổng quan các vấn đề liên quan đến báo
hiệu BICC. BICC ra đời xuất phát từ nhu cầu chuyển đổi từng
bước từ cấu trúc chuyển mạch k
- Residential Gateway (RGW): là thiết bị cung cấp các giao
diện thoại tương tự truyền thống qua mạng VoIP. RGW có thể là
m
ột trong các thiết bị xDSL, thiết bị vô tuyến băng rộng.
- Access Gateway (AGW): là thiết bị cung cấp các giao diện
thoại tương tự truyền thống hoặc giao diện số cho tổng đài PBX
qua m
ạng VoIP. AGW có thể là VoIP Gateway dung lượng nhỏ.
- Business Gateway (BGW): là thiết bị cung cấp giao diện cho
tổng đài PBX qua mạng VoIP.
Network Access Server: là thiết bị kết nối với mạng chuyển
mạch kênh thông qua modem để cung cấp đường truy nhập số liệu
qua mạng Internet. MGCP là giao diện chủ/tớ trong đó MGC quản
lý trạng thái cuộc gọi và định hướng cho MG từng bước trong quá
trình thiết lập cuộc gọi. MG sẽ không thực hiện bất cứ một hoạt
động n
ào có liên quan đến cuộc gọi như cung cấp âm mời quay số,
chuông, nếu như không có yêu cầu của MGC.
2.2.2 Mô hình kết nối
Mô hình kết nối trong giao thức MGCP được xác định dựa
trên đầu cuối v
à các kết nối được nhóm trong các cuộc gọi , một
cuộc gọi có thể tương ứng với một hay nhiều kết nối. Tuy theo
từng loại MG mà đầu cuối có thể là một trong các loại sau:
- Kênh số (DS0)
- Thuê bao tương tự
- Điểm truy nhập máy chủ cáp âm thông báo
- Điểm truy nhập đáp ứng thoại tương tác (IVR)
- Cầu hội nghị
-
2.2.2.3 Nhận dạng kết nối (ConnectionID)
Nhận dạng kết nối (ConnectionID) do MG tạo ra khi nó nhận
được y
êu cầu tạo kết nối. Nó là một chuỗi có độ dài lớn nhất là 32
ký t
ự. Ít nhất là 3 phút tính từ khi kết nối sử dụng một bộ nhận
dạng được giải phóng thì MG mới được sử dụng lại nhận dạng kết
nối cho một kết nối mới cho cùng một đầu cuối.
2.2.2.4 Tên MGC và các phần tử khác
Giao thức MGCP được thiết kế cho phép triển khai MGC dự
phòng để tăng độ tin cậy của mạng. Điều đó có nghĩa là không có
sự liên kết cố định giữa các phần tử với phần cứng hệ thống hoặc
giữa các giao diện mạng.
Tương tự như
nhận dạng thiết bị đầu cuối, tên MGC bao gồm
hai phần tên Local và tên miền: Thông
thường tên MGC có đầy đủ cả hai phần này, tuy nhiên tên miền
cũng được chấp nhận.
Tăng độ tin cây được thực
hiện thông qua các thủ tục sau:
- Các phần tử chẳng hạn như các đầu cuối hoặc MGC được
nhận dạng thông qua tên miền của chúng chứ không được nhận
dạng thông qua địa chỉ của chúng trong mạng. Ứng với một tên
mi
ền có thể có nhiều địa chỉ. Nếu như một lệnh hoặc một đáp ứng
không thể chuyển tiếp đến một địa chỉ mạng thì nó có sẽ được
truyền đi tới địa chỉ mạng khác.
- Các phần tử có thể chuyển sang hệ thống khác. Liên kết giữa
tên logic (tên miền và hệ thống cụ thể được lưu trong DNS. Các
MGC và MG phải giám sát thời gian hiệu lực đối với các bản tin
tra trạng thái của một đầu cuối.
- RSIP (RestarInProgress): là lệnh gửi từ MG tới MGC để
thông báo việc khởi động lại một đầu cuối để đưa đầu cuối từ trạng
thái không hoạt động (Out of service) sang trạng thái hoạt động (In
service) hoặc ngược lại từ trạng thái hoạt động sang trạng thái
không hoạt động.
2.2.4 Sự kiện và tín hiệu
Trong giao thức MGCP,các hoạt động tại đầu cuối được chia
thành hai loại là sự kiện và tín hiệu. MGC có tín hiệuẻ yêu cầu MG
thông báo việc xuất hiện một sự kiện nào đó tại một đầu cuối(ví dụ
như sự kiện nhấc máy) bằng cách đưa tên sự kiện vào tham số
RequestedEvents trong lệnh RQNT. MGC cũng có tín hiệuể yêu
c
ầu MG cấp một tín hiệu tới đầu cuối (ví dụ như am mời quay số)
băng cách đưa tên của sự kiện v
ào tham số SingalRequets trong
lệnh RQNT.
MGC cũng có tín hiệuể yêu cầu MG phát hiện một nhóm sự
kiện thông qua việc sử dụng các kí tự “*” thay cho tên gói và “all”
thay cho tên s
ự kiện: chẳng hạn như: “foo/all”được hiểu là tất cả
các sự kiện trong gói “foo” “*/bar” được hiểu là sự kiện “bar”
trong tất cả các gói do MG hỗ trợ;
2.2.5 Mã phúc đáp và mã lỗi
Trong giao thức MGCP tất cả các lệnh đều phải được phúc
đáp xác nhận. Trong các bản tin phúc đáp có chứa m
ã phúc đáp chỉ
tín hiệu trạng thái của lệnh. Mã phúc đáp là một số nguyên và có ý
ngh
ĩa như sau:
hạn như lệnh ModifyConnection bị loại bỏ bằng lệnh
DeleteConnection)
- 409 quá t
ải nội bộ
- 410 không có đầu cuối nào khả dụng.
- 500 đầu cuối không xác định
- 501 đầu cuối không sẵn sàng hoặc ở trạng thái Out-off-
service
-
502 không đủ tài nguyên
- 503 s
ử dụng ký tự thay thế * trong trường hợp quá phức tạp
không xác định được trạng thái của tất cả các đầu cuối
- 504 lệnh không biết hoặc không được hỗ trợ
- 505 RemoteConnectionDescriptor không được hỗ trợ
- 506 không thể hỗ trợ đồng thời giá trị của
LocalConnectionOpions và RemoteConnectionDescriptor
- 507 chức năng không được hỗ trợ
- 509 lỗi RemoteConnectionDescriptor
- 510 lỗi giao thức
- 511 không nhận dạng được tham số mở rộng
- 512 MG không hỗ trợ phát hiện một trong các sự được yêu
c
ầu
- 513 MG không hỗ trợ tạo tín hiệu được yêu cầu
- 514 MG không gửi được thông báo yêu cầu
- 515 ConnectionID không đúng
- 516 CallID không đúng
- 517 chế độ kết nối không được hỗ trợ
- 518 gói không được hỗ trợ
Bảng 3-1. Danh sách các gói cơ bản của giao thức MGCP
STT Gói Ký hiệu
1 Generic media G
2 DTMF D
3 R2 R2
4 Trunk T
5 Line L
6 Handset Emulation H
7 Supplementary Services SST
8 Digit Map Extension DM1
9 Signal List SL
10 Media Format FM
11 RTP R
12 Resource Reservation RES
13 Annoucement Server A
14 Script Script
Các gói bao gồm tập hợp các sự kiện và tín hiệu được hỗ trợ
bởi các loại đầu cuối. Tùy theo chức năng mỗi loại Media Gateway
s
ẽ hỗ trợ một tập hợp các gói, bảng 3-2 sau đây chỉ ra các loại
Media Gateway và các gói mà chúng hỗ trợ.
Bảng 3-2. Các loại Gateway và các gói mà chúng hỗ trợ
Loại Media Gateway Các gói hỗ trợ
Trunking Gateway (ISSUP) G, D, T, R
Trunking Gateway (R2) G, D, T, R, R2
Network Access Server
(NAS)
G, T, R2
NAS kết hợp với VoIP
Gateway
cc Country Code x R2
cd Conference Depart BR SST
cf Confirm Tone BR G
cf Clear Forward S BR R2
cg Congestion Tone TO G
ci (ti,nu,na) Caller-id x BR L,H
cj Conference Join BR SST
cm Comfort Tone TO SST
cng Congestion BR R2
co1 Continuity Tone x, C TO T, R
co2 Continuity Test x, C TO T, R
ct ( ) Continuity
Transponder
OO T
cw Caller Waiting Tone TO SST
dd ( ) DTMF Tone
Duration
x TO D
dl Dial Tone x TO L, H
dn Destination Number x R2
do ( ) DTMF OO Signal OO D
ds Discriminating Ind. x R2
e Error Tone x TO L, H
Es Echo Suppression
Ind.
x R2
ft Fax Tone x G
hd Off Hook Transition S BR L, H
hf Flash Hook x BR L, H
ht On Hold Tone x OO L, H, SST
nc Nature of Circuit x R2
ni Negative Indication TO SST
nm New Miliwatt Tone x TO T
nu Number
Unobtainable
TO SST
oc Operation Complete x G, D, T,
L, SST,
SL, R,
Script, R2
of Operation Failure x G, D, T,
L, SST,
SL, R,
Script, R2
osi Network Disconnect x TO L, H
ot Off Hook Warning
Tone
x TO L, H
giao thức Prompt Tone x BR L, H
pat(###) Pattern Detected x OO G
perl(url,…) Load & Run perl
script
TO Script
pl(…) Packet Loss Exeeded C R
pr Pay Phone
Recognition
BR SST
pst Permanent Signal
Tone
TO T
C R
sup Call Setup TO R2
sz Seizure S R2
t Interdigit Timer x TO D
tcl (url,…) Load & Run TCL
script
TO Script
tl Test Line x TO T
tp (###) Test Pattern x TO T
ubl Unblock S BR R2
uc Used Codec Changed C R
v Alerting Tone x OO L, H
vmwi Visual Message
Waiting Indicator
x OO L, H
vxml
(url,…)
Load & Run VXML
doc
TO Script
wt Call Waiting Tone x TO L, H
wt1,…wt4 Alternative Call
Waiting Tones
x TO L, H
X DTMF Tone wildcard x D
xml Load & Run XML
script
TO Script
y Recorder Warning
Tone