Hoạt động phát hiện Gatekeeper
Đây là hoạt động bắt buộc đối với mỗi đầu cuối H.323 mỗi khi nó đăng nhập mạng. Trong giai đoạn 1, đầu cuối gửi một bản tin yêu cầu GK (GRQ: Gatekeeper Request). Bản tin này đ−ợc khảo sát bởi GK, nó có thể đáp ứng lại bằng bản tin công nhận GK (GCF: Gatekeeper Confirmation).
Đầu cuối bắt đầu đặt định thời dựa vào việc phát bản tin GRQ. Nếu không
nhận đ−ợc đáp ứng, thời gian quá hạn và một GRQ khác đ−ợc phát đi. Nếu
vấn đề này tiếp tục, nhà điều hành mạng phải dàn xếp để quyết định các vấn đề này. GK có thể trả lại bản tin từ chối GK (GRJ: Gatekeeper Reject) nếu nó chọn không làm GK của điểm cuối.
Tiến trình phát hiện GK có thể hoạt động theo hai cơ chế là multicast và unicast.
Theo cơ chế unicast, các bản tin GRQ sẽ đ−ợc gởi trên cổng 1719 của giao
thức UDP với địa chỉ IP mặc định đã đ−ợc cấu hình cho nó.
Trong cơ chế multicast, để tìm kiếm GK, các đầu cuối phải phát các bản tin của nó theo địa chỉ multicast 224.0.1.41 vì nó không đ−ợc cấu hình địa chỉ IP
đ−ợc nhiều bản tin GCF từ các GK trên mạng. Khi đó nó phải có cơ chế để lựa chọn một trong số các GK đó.
Thủ tục đăng ký với Gatekeeper
Sau khi hoạt động phát hiện GK xảy ra, các hoạt động đăng ký bắt đầu. Thủ tục này giúp đầu cuối tham gia vào một vùng và cung cấp cho GK số cổng và địa chỉ của nó. Đầu tiên đầu cuối gửi bản tin yêu cầu đăng ký (RRQ: Registration Request) tới GK. Tiếp đó, GK đáp ứng với bản tin công nhận đăng ký (RCF: Registration Confirmation) hoặc bản tin từ chối đăng ký (RRJ: Registration Reject).
Đầu cuối hoặc GK có thể hủy bỏ việc đăng ký và kết thúc sự liên hệ giữa hai thực thể bằng việc gửi yêu cầu hủy bỏ đăng ký (URQ: Unregister Request), đối tác sẽ gửi trả lại bản tin công nhận hủy đăng ký (UCF: Unregister Confirm). Nếu đối tác là GK nó có thể từ chối không cho đầu cuối hủy đăng ký bằng cách gửi trả lại bản tin từ chối hủy đăng ký (URJ: Unregister Reject)
Thủ tục thiết lập kênh media
Hình 3.5 trình bày các hoạt động thiết lập kênh media. Kênh điều khiển H.245
Hình 3.4 Tiến trình thiết lập kênh media
• B−ớc 1: GW A trao đổi khả năng của nó với GW B bằng cách gửi bản
tin TerminalCapbilitySet H.245.
• B−ớc 2: GW B công nhận khả năng của A bằng các gửi bản tin công
nhận TerminalCapabilitySetAcknowledge.
• B−ớc 3: GW B trao đổi khả năng của nó với GW A bằng cách gửi bản
tin TerminalCapabilitySet.
• B−ớc 4: GW A công nhận khả năng của GW B bằng cách gửi trả lại bản
tin TerminalCapabilitySetAcknowledge.
• B−ớc 5: GW A mở kênh media với GW B bằng cách gửi bản tin
OpenLogicalChannel và địa chỉ truyền tải của kênh RTCP (nếu luồng media đ−ợc quản lý bởi RTCP).
• B−ớc 6: GW B công nhận sự thiết lập kênh logic của GW A bằng cách
Địa chỉ truyền tải RTP đ−ợc phân phối bởi GW B (địa chỉ này sẽ đ−ợc sử dụng để truyền luồng media RTP).
Địa chỉ RTCP nhận đ−ợc từ GW A.
• B−ớc 7: GW B mở kênh media với GW A bằng cách gửi bản tin
OpenLogicalChannel bao gồm địa chỉ truyền tải của kênh RTCP. (adsbygoogle = window.adsbygoogle || []).push({});
• B−ớc 8: để hoàn thành việc thiết lập thông tin media hai chiều, GW A
công nhận việc thiết lập kênh logic của GW B bằng cách gửi bản tin công nhận OpenLogicalChannelAcknowledge, bản tin này bao gồm: Địa chỉ truyền tải RTP đ−ợc phân phối bởi GW A.
Địa chỉ RTCP nhận đ−ợc từ GW B.
Thủ tục thay đổi băng thông
Các đầu cuối (hoặc GW) cũng có thể yêu cầu thay đổi băng thông. GK phải quản lý các yêu cầu thay đổi băng thông này (tăng hoặc giảm). Tiến trình trao đổi giữa các bản tin đ−ợc trình bày trong hình.
Hình 3.5 Thủ tục thay đổi băng thông
• B−ớc 1: GW khởi tạo gửi bản tin yêu cầu băng thông (BRQ: Bandwidth
Request) đến GK để yêu cầu băng thông mong muốn.
• B−ớc 3: kênh logic đ−ợc thiết lập giữa hai GW với băng thông đ−ợc chỉ định.
• B−ớc 4: một bản tin BRQ đ−ợc gửi đến GK để yêu cầu thay đổi băng
thông của kết nối (giả sử GW này không thỏa mãn băng thông đã chỉ định).
• B−ớc 5: GK đáp ứng GW với bản tin BCF để xác nhận băng thông mới.
• B−ớc 6: kênh logic đ−ợc thiết lập lại với băng thông mới.
GK có thể từ chối các yêu cầu khởi tạo và thay đổi băng thông bằng bản tin từ chối cấp băng thông BRJ (Bandwidth Reject)
Thiết lập cuộc gọi nội vùng
Hình 3.6 Thủ tục thiết lập cuộc gọi nội vùng
• B−ớc 1: đầu cuối A quay số điện thoại để gọi cho đầu cuối B.
• B−ớc 2: GW A gửi cho GK một bản tin ARQ, yêu cầu cho phép gọi đến
đầu cuối B.
• B−ớc 3: GK tìm đầu cuối B và trả lại một bản tin ACF với địa chỉ IP
• B−ớc 4: GW A gửi bản tin thiết lập cuộc gọi Q.931 cho GW B với số điện thoại của đầu cuối B.
• B−ớc 5: GW B gửi bản tin ARQ cho GK, yêu cầu cho phép trả lời cuộc
gọi của GW A.
• B−ớc 6: GK trả lại bản tin ACF với địa chỉ IP của GW A. • B−ớc 7: GW B thiết lập một cuộc gọi đến đầu cuối B.
• B−ớc 8: khi đầu cuối B trả lời, GW B gửi kết nối Q.931 đến GW A.
Thiết lập cuộc gọi liên vùng
6 10 2 3 8 7 Gatekeeper A Gateway A Gatekeeper B Gateway B 3 4 1 5 9 A B
Hình 3.7 Thủ tục thiết lập cuộc gọi liên vùng
• B−ớc 1: đầu cuối A quay số điện thoại của đầu cuối B.
• B−ớc 2: GW A gửi bản tin ARQ cho GK A, yêu cầu cho phép gọi đến (adsbygoogle = window.adsbygoogle || []).push({});
đầu cuối B.
• B−ớc 3: GK A tìm và không tìm thấy sự đăng ký của đầu cuối B. GW A
tra các số đầu và nhận thấy trùng khớp với GK B. Nó gửi bản tin LRQ cho GK B và bản tin RIP cho GW A.
• B−ớc 4: GK B tìm và nhận thấy sự đăng ký của đầu cuối B, nó gửi trả lại GK A bản tin LCF với địa chỉ IP của GW B.
• B−ớc 5: GK A trả lại bản tin ACF cho GW A với địa chỉ IP của GW B.
• B−ớc 6: GW A gửi bản tin thiết lập cuộc gọi Q.931 đến GW B với số
điện thoại của đầu cuối B.
• B−ớc 7: GW B gửi cho GK B bản tin ARQ, yêu cầu cho phép trả lời
cuộc gọi của GW A.
• B−ớc 8: GK B trả lại bản tin ACF với địa chỉ IP của GW A. • B−ớc 9: GW B thiết lập một cuộc gọi đến đầu cuối B.
• B−ớc 10: khi đầu cuối B trả lời, GW B gửi bản tin kết nối Q.931 đến GW A.
Ngắt kết nối giữa hai đầu cuối H.323 liên vùng
• B−ớc 1: đầu cuối B gác máy.
• B−ớc 2: GW B gửi bản tin DRQ đến GK B để yêu cầu ngắt kết nối giữa
A và B.
• B−ớc 3: GK B gửi lại bản tin DCF công nhận bản tin DRQ.
• B−ớc 4: GW B gửi bản tin giải phóng kết nối Q.931 đến GW A.
• B−ớc 5: GW A gửi bản tin DRQ đến GK A để yêu cầu ngắt kết nối giữa
A và B.
• B−ớc 6: GK A gửi lại bản tin DCF.
Hình 3.8 Thủ tục ngắt kết nối 3.2. MEGACO
Megaco (Media Gateway Control): Giao thức điều khiển cổng truyền thông (ITU cũng định nghĩa một giao thức t−ơng tự là H.248) nó là giao thức điều khiển giữa MGC và MG.
SIP (Session Initiation Protocol): Giao thức khởi tạo phiên, nó là giao thức điều khiển cuộc gọi hoạt động giữa MGC hoặc giữa MGC và điện thoại IP.
RTP đặc tả giao thức thời gian thực nh− H.323 nhằm vận chuyển gói truyền
thông.
3.2.1. Cấu trúc của MEGACO
Cấu trúc của Megaco có một vài đặc điểm giống H.323 về bộ điều khiển
Gateway. Bộ điều khiển trong H.323 đ−ợc gọi là Gatekeeper, còn trong
Megaco đ−ợc gọi là Media Gateway Controller (MGC). Trong cả hai hệ
thống, các bộ điều khiển này giám sát các hoạt động của Gateway t−ơng ứng, cũng nh− là hỗ trợ xử lý cuộc gọi. (adsbygoogle = window.adsbygoogle || []).push({});
Tuy nhiên, Megaco thì dựa vào Web và sử dụng cơ chế khác biệt cho các hoạt
động của nó. Megaco có hai khái niệm mang tính trừu t−ợng là: Termination
Gateway
Media Gateway Controller
PSTN
PSTN
Hình 3.9 Mô hình của hệ thống Megaco
Megaco định nghĩa việc thêm vào hoặc bớt Termination ra khỏi Context nh−
thế nào và di chuyển Termination giữa hai Context nh− thế nào. Nó định nghĩa Termination đ−ợc lập trình nh− thế nào để phát hiện các sự kiện, nh− là các sự kiện thêm vào hoặc bớt ra từ các Termination đó. Termination cũng có thể đ−ợc sửa đổi, nh− thay đổi một Termination từ trạng thái rỗi sang trạng thái gửi/nhận. Các GW có thể gửi các bản tin chú ý đến bộ điều khiển MGC về trạng thái của Termination hoặc về các sự kiện xảy ra ở Termination.
3.2.2. CONTEXT
Context là một sự kết hợp giữa một số Termination. Có một Context đặc biệt
đ−ợc gọi là Context rỗng. Nó chứa các Termination không kết hợp với các
Termination khác. Các Termination trong Context rỗng có thể có các tham số đ−ợc khảo sát hoặc sửa đổi và có thể có các sự kiện xảy ra trên chúng.
Lệnh Add dùng để thêm Termination vào Context. Nếu MGC không chỉ định
một Context tồn tại để Termination đ−ợc thêm vào thì MG (Media Gateway)
sẽ tạo một Context mới. Lệnh Subtract dùng để xóa bỏ Termination ra khỏi
một Context. Termination cũng có thể đ−ợc di chuyển từ Context này sang
một Context khác với lệnh Move. Một Termination chỉ tồn tại trong một Context ở một thời điểm.
Số l−ợng Termination lớn nhất trong một Context phụ thuộc vào MG. Chẳng hạn, MG chỉ đ−a ra kết nối điểm điểm thì có thể chỉ cho phép hai Termination trên một Context. Các MG hỗ trợ các cuộc hội nghị đa điểm có thể cho phép 3 hoặc nhiều Termination trên một Context.
Các thuộc tính của Context:
ContextID.
Mô hình (topology). Mô hình của Context mô tả luồng media giữa các Termination trong một Context. Ng−ợc lại, chế độ của Termination (nhận/gửi) mô tả luồng media ở ngõ vào/ra của MG.
Sự −u tiên đ−ợc sử dụng cho một Context để cung cấp cho MG thông tin về
việc điều khiển −u tiên. MGC cũng có thể điều khiển sự −u tiên l−u l−ợng trong MG khi nhiều Context phải đ−ợc điều khiển đồng thời.
Bộ chỉ thị (indicator) cho cuộc gọi khẩn cấp cũng đ−ợc cung cấp để cho phép việc điều khiển −u tiên trong MG.
Tạo, xóa và sửa đổi Context:
Megaco có thể đ−ợc dùng để tạo Context và sửa đổi các giá trị tham số của
Context đang tồn tại. Megaco có các lệnh để thêm Termination vào Context, bỏ Termination ra khỏi Context và di chuyển Termination giữa các Context. Context bị xóa hoàn toàn khi Termination còn lại sau cùng bị xóa bỏ hoặc di chuyển khỏi Context.
3.2.3. TEMINATION
Termination là một thực thể luận lý trên MG, nh− là các nguồn hoặc các luồng điều khiển, …. Termination có duy nhất một số nhận dạng (TerminationID) đ−ợc phân phối bởi MG ở thời điểm chúng đ−ợc tạo ra. (adsbygoogle = window.adsbygoogle || []).push({});
Termination cũng biểu hiện cho các thực thể vật lý có thời gian tồn tại bán th−ờng trực, nh− là một kênh TDM.
Termination cũng biểu hiện cho các luồng thông tin ngắn hạn nh− là các
luồng RTP, th−ờng tồn tại trong thời gian chúng đ−ợc sử dụng. Các
Termination ngắn hạn đ−ợc tạo bởi lệnh Add và đ−ợc hủy bỏ bởi lệnh
Subtract. Ng−ợc lại, một Termination vật lý đ−ợc thêm vào và bỏ ra khỏi một Context thì chúng đ−ợc lấy ra hoặc đ−a vào một Context rỗng t−ơng ứng. Các tín hiệu có thể áp dụng lên các Termination, các tín hiệu này nh− là các
âm hiệu hoặc các thông báo. Các Termination cũng có thể đ−ợc lập trình để
phát hiện các sự kiện.
3.2.4. Một số lệnh MEGACO
Add: lệnh Add dùng để thêm một Termination vào một Context. Lệnh Add
trên Termination đầu tiên trong Context đ−ợc dùng để tạo Context.
Modify: dùng để sửa đổi các thuộc tính, sự kiện và tín hiệu của Termination.
Subtract: dùng để ngắt một Termination từ một Context. Lệnh này trên Termination sau cùng trong một Context dùng để xóa Context đó.
Move: dùng để di chuyển Termination trong Context này đến Context khác.
AuditValue: trả lại trạng thái hiện tại của các đặc tính, các sự kiện, các tín hiệu và thống kê của Termination.
Auditcapabilities: trả lại tất cả các giá trị đối với các tính chất của Termination, các sự kiện và các tín hiệu đ−ợc cho phép bởi MG.
Notify: cho phép MG thông báo cho MGC biết các sự kiện xảy ra trong MG.
ServiceChange: cho phép MG thông báo MGC rằng một Termination hoặc một nhóm Termination chuẩn bị rời khỏi hoặc trả lại dịch vụ. Lệnh này cũng
đ−ợc dùng bởi MG để thông báo cho MGC sự sẵn sàng của nó. MGC cũng có thể thông báo chuyển giao tới MG bằng các gửi lệnh ServiceChange.
3.2.5. Hoạt động của MEGACO
Để đơn giản ta lấy ví dụ sử dụng một MGC điều khiển cả hai Gateway (Gateway cục bộ và Gateway ở xa). Mục đích của ví dụ này là trình bày 3 trạm thiết lập một Context và một Termination nh− thế nào. Các bản tin ACK ngoài việc xác nhận cho bản tin đã nhận mà còn chứa các thông tin cộng thêm nh− kết quả của việc thiết lập cổng RTP mới, đặt tên cho một Context rỗng, … MGC cũng sử dụng bộ mô tả cục bộ (LocalDesc) và bộ mô tả xa (RemoteDesc) để dành riêng và giao nguồn tài nguyên MG cho bộ mã hóa và giải mã media đối với các luồng media cho tr−ớc và Termination mà chúng áp dụng. Quá trình hoạt động của luồng giao thức Megaco nh− sau:
Hình 3.10 Hoạt động của Megaco
• B−ớc 1: MGC gửi bản tin Modify đến Gateway cục bộ để yêu cầu
Termination 1 (T1) phát hiện nhắc máy. Khi sự nhắc máy đ−ợc phát
hiện, Gateway cục bộ thu thập các chữ số. Context thì rỗng (CTX=Null) do nó ch−a có liên hệ với một kết nối.
• B−ớc 3: Gateway cục bộ phát hiện sự nhắc máy.
• B−ớc 4: nó thông báo cho MGC bằng bản tin Notify.
• B−ớc 5: MGC ghi nhận lại sự kiện này. • B−ớc 6: MGC công nhận bản tin Notify.
• B−ớc 7: Gateway cục bộ tích lũy các chữ số đ−ợc quay từ ng−ời dùng theo kế hoạch đánh số đ−ợc tải từ MGC, th−ờng trong lệnh Modify. Kế
hoạch đánh số đơn giản là một biểu đồ đ−ợc gửi đến Gateway để thông
báo và giải thích cho nó biết các chữ số đ−ợc quay nh− thế nào. • B−ớc 8: các chữ số đ−ợc gửi đến MGC trong lệnh Notify. (adsbygoogle = window.adsbygoogle || []).push({});
• B−ớc 9: MGC công nhận việc nhận các chữ số.
• B−ớc 10: MGC quyết định chuỗi số đúng và tạo cuộc gọi. Nó gửi lệnh Add đến Gateway cục bộ để tạo Context chứa T1. Chú ý là CTX=* nghĩa là Context ch−a đ−ợc đặt tên. Gateway cục bộ sẽ cung cấp một
tên cho Context trong b−ớc 11. Trong bản tin này cũng định gói
Termination không tên RTP/*. Trong bản tin Add có tr−ờng LocalDesc
có thể chỉ định bộ mã hóa cho cuộc gọi.
• B−ớc 11: Gateway cục bộ trả lời MGC với ACK và Context đ−ợc đặt tên là C1. Nó cũng xác định bộ nhận dạng Termination RTP (RTP/ID).
LocalDesc của Gateway cục bộ chỉ định bộ mã hóa đ−ợc hỗ trợ trên
cổng RTP.
• B−ớc 12: dựa vào thông tin nhận đ−ợc từ Gateway cục bộ, MGC có thể
thông báo cho Gateway ở xa thêm Termination (T1r) t−ơng ứng với
chuỗi số quay mà MGC nhận đ−ợc từ Gateway cục bộ. Nhiệm vụ của
MGC là ánh xạ T1r và T1 vào một Context. Nó cũng gửi tr−ờng cổng
của T1 đ−ợc đ−a đến Gateway ở xa trong tr−ờng RemoteDesc, thông tin
này chỉ định bộ mã hóa cho T1r từ Gateway cục bộ. Tr−ờng LocalDesc
trong bản tin này có thể rỗng hoặc có thể chứa đựng các thông số mà