Hình 7: Mở các kênh phương tiện bằng bản tin OpenMediaChannel H .245
1.2 Tiến trình thiết lập cuộc gọi qua H.323
1.2.3 Mơ hình định tuyến Gatekeeper
Ban đầu, hầu như tất cả các sự bổ sung gatekeeper đều sử dụng mơ hình cuộc gọi trực tiếp. Mơ hình này, nơi mà Gatekeeper thực sự chỉ được sử dụng như một loại thư mục, thoạt nhìn có vẻ rất hấp dẫn.
Trên thực tế, mơ hình trực tiếp có nhiều khuyết điểm khơng cho phép mạng VoIP đạt được chất lượng dịch vụ ngang bằng với mạng TDM truyền thống. Chế độ trực tiếp chỉ thực sự được chấp nhận đối với các mạng doanh nghiệp đơn giản.
Gatekeeper sử dụng mơ hình định tuyến xử lý tất cả thông tin báo hiệu cuộc gọi
và không để các thiết bị đầu cuối thiết lập cuộc gọi trực tiếp. Một số Gatekeeper có thể được cấu hình để sử dụng mơ hình định tuyến hoặc mơ hình trực tiếp trên cơ sở mỗi tuyến.
Mơ hình được định tuyến hoàn toàn giống với cách các thiết bị chuyển mạch TDM truyền thống xử lý các cuộc gọi điện thoại, với một ngoại lệ: khi sử dụng mơ hình được định tuyến, các luồng phương tiện vẫn được trao đổi trực tiếp bởi các điểm cuối. Mơ hình định tuyến cung cấp tất cả các ưu điểm của định tuyến lớp 4 đầy đủ (khả năng phân tích nguyên nhân phát hành, định tuyến lại cuộc gọi, bảo mật tốt hơn), trong khi vẫn khơng u cầu phần cứng viễn thơng chun dụng vì khơng cần ma trận chuyển mạch TDM. Do đó, mật độ và chi phí liên quan đến phần cứng của các softswitch tốt hơn nhiều so với các đối tác TDM của chúng.
Bên cạnh việc giải quyết tất cả các vấn đề không thể giải quyết với Gatekeeper ở chế độ trực tiếp, Gatekeeper chế độ định tuyến cung cấp nhiều khả năng hơn. Ví dụ, chúng có thể hoạt động như các bộ chuyển mạch đa giao thức hoạt động như một Gatekeeper chế độ định tuyến H.323 và như một proxy SIP với quyền truy cập vào đủ thông tin để chuyển đổi giữa các giao thức báo hiệu (ví dụ: H.323 và SIP).
1.2.4 Cuộc gọi H.323 qua nhiều vùng hoặc miền quản trị
1.2.4.1 Mơ hình cuộc gọi trực tiếp1.2.4.1.1 Thiết lập cuộc gọi 1.2.4.1.1 Thiết lập cuộc gọi
Admission request được A gửi đến Gatekeeper mà nó đã đăng ký (Hình 2.15).
Gatekeeper này biết rằng tất cả các cuộc gọi đến PSTN đều do Cybercall xử lý. Do đó, nó sẽ gửi một u cầu vị trí (LRQ) đến gatekeeper của Cybercall,
Nhóm 15
Bài tập lớn mơn Báo hiệu và điều khiển kết nối
bản tin LRQ truy vấn Cybercall gatekeeper về một địa chỉ IP bước nhảy tiếp theo mà tín hiệu Q.931 có thể được gửi cho một điểm đến cụ thể. Vì LRQ đến từ một Gatekeeper đã được biết đến và giả sử A được ủy quyền thực hiện cuộc gọi, Gatekeeper của Cybercall sẽ chấp nhận nó và trả lại Location Confirm (LCF) cho gatekeeper của A. Bản tin LCF chứa địa chỉ IP của gateway mà đầu cuối của A sẽ gửi bản tin SETUP. Gatekeeper của A vẫn chưa trả lời ARQ ban đầu, vì nó khơng có đủ thơng tin để làm như vậy. Bây giờ, với địa chỉ IP có trong LCF, Gatekeeper biết nơi cuộc gọi nên được định tuyến và gửi thông tin này đến thiết bị đầu cuối của A trong một ACF. Nếu việc này diễn ra quá lâu, Gatekeeper có thể gửi tin nhắn Request In Progress (RIP) đến thiết bị đầu cuối của A để ngăn chặn bất kỳ thời gian chờ nào có thể khiến thiết bị đầu cuối của A từ chối cuộc gọi hoặc gửi lại ARQ.
Hình 12. Mơ hình cuộc gọi trực tiếp qua hai miền, sử dụng bản tin LRQ / LCF.
Cybercall cũng có thể bao gồm một token trong LCF. Tuy nhiên, Cybercall, để tập trung quản lý bảo mật, đã không cung cấp cho cổng đủ thông tin để giải mã và xác minh mã bản tin cục bộ. Gateway sẽ chỉ cần chuyển mã bản tin này cho
Gatekeeper trong ARQ bên nhận, Gatekeeper của Cybercall sẽ kiểm tra nó và trả
lại ACF nếu mã bản tin chính xác. Nếu khơng, cuộc gọi sẽ bị từ chối với bản tin ARJ (Admission Reject) và cổng sẽ giải phóng cuộc gọi với bản tin Q.931 RELEASE COMPLETE. Khi nhận được ACF, gateway sẽ thiết lập cuộc gọi ở
Nhóm 15
phía PSTN và gửi tin nhắn CONNECT cho A ngay khi B nhấc máy. Sau đó, A thiết lập kênh điều khiển H.245 tới cổng kết nối bằng địa chỉ và cổng được chỉ định bởi cổng trong bản tin CONNECT. Sau đó, các kênh logic được thiết lập bằng cách sử dụng các bản tin OpenLogicalChannel và A có thể nói chuyện.
1.2.4.1.2 Chia nhỏ cuộc gọi
Nếu người bà gác máy trước, cổng kết nối sẽ gửi một bản tin EndSessionCommand và RELEASE COMPLETE đến thiết bị đầu cuối của A
Hình 13. Cuộc gọi được giải phóng kết thúc ở mức H.245 và Q.931, cục bộ ở mức RAS.
Sau đó, gateway sẽ gửi một bản tin DRQ đến Gatekeeper của Cybercall và thiết bị đầu cuối của A sẽ gửi một bản tin DRQ đến Gatekeeper của chính nó.
1.2.4.2 Mơ hình định tuyến Gatekeeper1.2.4.2.1 Thiết lập cuộc gọi 1.2.4.2.1 Thiết lập cuộc gọi
Trong Gatekeeper của Cybercall quyết định định tuyến cuộc gọi bằng cách đặt địa chỉ IP của chính nó (10.1.2.2) vào địa chỉ báo hiệu cuộc gọi LCF . Gatekeeper của A cũng quyết định định tuyến cuộc gọi bằng cách đặt địa chỉ IP của chính nó vào địa chỉ báo hiệu cuộc gọi ACF. Nếu Gatekeeper của A biết trước rằng
Nhóm 15
Bài tập lớn mơn Báo hiệu và điều khiển kết nối
Cybercall ln sử dụng mơ hình định tuyến, thì LRQ là khơng cần thiết và một SETUP trực tiếp có thể được gửi đến địa chỉ IP của Gatekeeper của Cybercall. Yếu tố thông tin quan trọng nhất của bản tin ALERTING hoặc CONNECT là địa chỉ kênh điều khiển cuộc gọi H.245 mà thiết bị đầu cuối của A phải sử dụng để thiết lập kênh điều khiển cuộc gọi. Ở đây, kênh H.245 cũng sẽ được định tuyến vì cả người gác cổng của Cybercall và A đã đặt địa chỉ IP của riêng họ vào trường địa chỉ truyền tải điều khiển cuộc gọi của bản tin ALERTING.
Hình 14. Mơ hình cuộc gọi định tuyến qua hai miền
Bằng cách cho phép các luồng phương tiện truyền trực tiếp giữa các điểm cuối, độ trễ của phương tiện được tối ưu hóa, ngay cả khi việc báo hiệu cuộc gọi phải đi qua nhiều gatekeeper, vì các giao thức định tuyến đường ngắn nhất IP sẽ được sử dụng để định tuyến các gói RTP. Việc này cho phép khách hàng được phục vụ từ những Gatekeeper từ xa, do đó giảm số lượng điểm hiện diện cần thiết để cung cấp dịch vụ.
1.2.4.2.2 Chia nhỏ cuộc gọi
Việc chia nhỏ cuộc gọi rất giống với trường hợp mơ hình trực tiếp, ngoại trừ tất nhiên là các tin nhắn Q.931 và các tin nhắn H.245 tùy chọn được định tuyến thơng qua Gatekeeper.
Nhóm 15
1.3 Thiết lập hội nghị với H.323
1.3.1 Cầu nối hội nghị MCU, các thành phần MC và MP
Có hai chức năng riêng biệt có thể có trong bất kỳ hội nghị nào. Đầu tiên là chức năng kiểm soát, quyết định ai được phép tham gia hay không, cách thức những người mới tham gia được giới thiệu trong các hội nghị hiện có, cách những người tham gia đồng bộ hóa trên một phương thức hoạt động, ai được phép phát sóng phương tiện,…Vai trị này được đảm nhận trong H.323 bởi một thành phần chức năng được gọi là bộ điều khiển đa điểm (MC).
Khi nhiều người nói chuyện trong một hội nghị âm thanh, họ có thể chỉ phát đa hướng âm thanh của họ, và tất cả các thiết bị đầu cuối có thể tự trộn các luồng phương tiện riêng lẻ. Trong hầu hết các trường hợp, tuy nhiên, các thiết bị đầu cuối riêng lẻ sẽ có các khả năng hạn chế hoặc có thể khơng thực tế đối với phát đa hướng tất cả các luồng phương tiện (đặc biệt là trong trường hợp video). Nếu không thể sử dụng phát đa hướng, một thực thể trong mạng cần thực hiện việc trộn hoặc chuyển đổi các luồng phương tiện đến, và chỉ gửi luồng đi đã xử lý kết quả tới mỗi thiết bị đầu cuối. Trong trường hợp video nó có thể là hình ảnh từ loa hoạt động cuối cùng, trong trường hợp âm thanh mỗi thiết bị đầu cuối sẽ nhận được một luồng do việc bổ sung tất cả các luồng từ những người nói khác trong hội nghị (cộng với một số của riêng nó, nhưng đã giảm bớt). Trong H.323, thành phần chức năng này là được gọi là bộ xử lý đa điểm (MP). Một thiết bị đầu cuối hoặc Gateway có đủ tài nguyên cũng có thể có khả năng hoạt động như một MC và có thể thực hiện một số phương tiện trộn cục bộ. Tuy nhiên, thành phần chức năng MC trong một thiết bị đầu cuối hoặc một gateway không thể được gọi trực tiếp, nhưng sẽ được bao gồm trong cuộc gọi khi nó trở thành đa bên.
Một hội nghị được gọi là hội nghị tập trung khi một nghị sĩ trung tâm được sử dụng để trộn hoặc chuyển đổi tất cả các luồng phương tiện cho các điểm cuối tham gia. Khi mỗi thiết bị đầu cuối gửi phương tiện của nó , luồng đến tất cả các thiết bị đầu cuối tham gia khác (trong đa hướng hoặc đa đơn hướng), nó được gọi là hội nghị phi tập trung.
Nhóm 15
Bài tập lớn mơn Báo hiệu và điều khiển kết nối
1.3.2 Tạo và tham gia vào hội nghị
1.3.2.1 Sử dụng trực tiếp khối điều khiển đa điểm1.3.2.1.1 Mời những người tham dự mới 1.3.2.1.1 Mời những người tham dự mới
Sau khi thiết bị đầu cuối tham gia hội nghị, thiết bị đầu cuối có thể mời những người khác (ví dụ: thiết bị đầu cuối C) tham gia bằng cách gửi bản tin CÀI ĐẶT đến MC đang hoạt động với CRV mới, CID của hội nghị và thông số . Mục tiêu hội nghị được đặt để mời Địa chỉ đích và, tùy chọn, địa chỉ báo hiệu cuộc gọi đích của bản tin SETUP phải là địa chỉ của thiết bị đầu cuối C. Khi nhận được bản tin này, MCU sẽ gửi một bản tin CÀI ĐẶT tới đầu cuối C với
CID của hội nghị và hội thảo Goal = mời đầu cuối C chấp nhận bằng cách gửi tin nhắn CONNECT. Tại thời điểm này, MCU gửi bản tin HOÀN THÀNH tới thiết bị đầu cuối mời. MC thiết lập kênh điều khiển H.245 với thiết bị đầu cuối C sử dụng địa chỉ vận chuyển được cung cấp trong kết nối. Họ trao đổi TerminalCapabilitySets. MC báo hiệu trong thủ tục client –sever rằng nó là đã là MC hoạt động và có thể gửi tin nhắn MCLocationIndication. Khi đến đây là xong, MC sẽ gửi một tin nhắn Multipoint Conference đến những người mời và được mời tại các thiết bị đầu cuối. Nếu đã có các thiết bị đầu cuối khác trong cuộc gọi, MCU sẽ gửi cho họ một yêu cầu gia nhập, H.245 thông báo để cho họ biết về người mới tham gia. Bởi vì thiết bị đầu cuối đến có thể có các tính năng khơng tương thích với các kênh phương tiện hiện có tại chỗ trong hội nghị, MCU phải gửi một bản tin cationModeCommand tới tất cả các thiết bị đầu cuối chỉ định tập hợp truyền mới được phép thực hiện các chế độ cho mỗi luồng. Tất cả các kênh truyền thơng khơng phù hợp phải bị đóng lại. Tại thời điểm này, MC có thể bắt đầu gửi các thơng điệp OpenLogicalChannel đến các điểm cuối. Các điểm cuối sẽ trong trạng thái đợi, trước khi họ đã nhận được bản tin về hội nghị đa điểm, cho đến khi họ nhận được bản tin CommunicationModeCommand để mở logic kênh truyền hình.Tất cả các điểm cuối phải gửi bản tin openLogicalChannel đến MC .
Nhóm 15
Hình 15. Mời những người tham dự vào trong hội nghị được điều khiển bởi MCU
MCU cũng có thể tự bắt đầu lời mời (ví dụ: nếu lời mời khơng được thực hiện từ một thiết bị đầu cuối H.323, mà từ giao diện Web của MCU). Trong các sản phẩm thương mại H323, đây là mơ hình được sử dụng rộng rãi nhất, vì nó khơng u cầu hỗ trợ cho bất kỳ luồng cuộc gọi H.323 cụ thể trên các điểm cuối tham gia .
1.3.2.1.2 Tham gia một hội nghị đang diễn ra
Một thiết bị đầu cuối có thể dễ dàng tham gia một hội nghị hiện có bằng cách gửi một bản tin CÀI ĐẶT đến MCU với CID tại hội nghị và conferenceGoal- join. Nếu đầu cuối chỉ biết bí danh của hội nghị, nó phải cung cấp bí danh của
Nhóm 15
Bài tập lớn mơn Báo hiệu và điều khiển kết nối
mình và để CID ở mức 0. Hầu hết các MCU thương mại sử dụng mơ hình đơn giản hơn này, trong đó tất cả những người tham dự khi gọi cùng một số sẽ đều được kết nối vào cùng một hội nghị. Để đảm bảo hội nghị và ngăn bất kỳ người dùng ngẫu nhiên nào gọi kết nối trực tiếp, cuộc gọi có thể được định tuyến thơng qua một gatekeeper ở chế độ định tuyến, điều này sẽ quyết định nhanh nếu người tham gia được cho phép và có thể đổi số của bên được gọi ban đầu của bản tin cài đặt thành một số của hội nghị.
1.3.2.1.3 Duyệt qua các hội nghị hiện có
Về lý thuyết, MCU có thể cung cấp danh sách các hội nghị hiện có mà một thiết bị đầu cuối có thể tham gia bằng cách gửi một bản tin conferenceListChoice H.245 tới một thiết bị đầu cuối. Ngoài ra, hầu hết các MCU thương mại sử dụng giao diện quản trị viên dựa trên Web đơn giản hơn để duyệt cho các hội nghị đang diễn ra.
1.3.2.2 Hội nghị và RAS
Trong hầu hết các trường hợp, thiết bị đầu cuối sẽ chỉ biết tên của hội nghị mà họ muốn tham gia. Do đó, ARQ ban đầu sẽ chỉ chứa tên hội nghị trong tham số Thơng tin đích của ARQ. Tham số CID sẽ được đặt thành 0, có nghĩa là khơng xác định. CallIdentifier phải được đặt bởi người gọi như bình thường. Gatekepeer sẽ trở lại địa chỉ truyền tải Q.931 tại điểm cuối chứa MC (MCU hoặc điểm cuối với khả năng MC) trong ACF. Về lý thuyết, ngay sau khi người gọi biết giá trị chính xác của CID là gì (sau khi nhận được kết nối từ MC), nó phải thơng báo cho gatekeeper bằng bản tin IRR RAS; nhưng, trong thực tế, chúng ta không biết bất kỳ điểm cuối nào làm điều này.
1.3.3 H.332
Các hội nghị với số lượng lớn người tham gia có xu hướng được tổ chức với một ban quản trị (thường ít hơn 10 người) và một lượng lớn khán giả nghe hầu hết các thời gian và chỉ nói khi người điều hành yêu cầu. H.332 được mô tả tương đương với hội nghị ban quản trị được gọi là hội nghị kết hợp lỏng lẻo, và được thiết kế để mở rộng quy mơ đến hàng nghìn người tham gia. H.332 là một hỗn hợp của một số giao thức thông thường kết hợp (được sử dụng bởi các diễn giả cố định) và hội nghị RTP / RTCP đa hướng (được biết đến trên mBone) dành cho người nghe thụ động. Người nghe dùng RTP / RTCP phải biết codec nào được sử dụng và các chi tiết khác (cổng UDP, ...). H.332 sử dụng cú pháp của IETF thuộc loại Giao thức mơ tả phiên (SDP) để mã hóa giá trị của các tham số
Nhóm 15
đó. Một giao thức mới Loại SDP (a = type: H332) được xác định để cho người nghe RTP biết rằng đây là hội nghị H.332. Thơng tin có thể được truyền đạt bằng Thơng báo phiên giao thức (SAP) hoặc một tệp đơn giản trên trang web hoặc được gửi qua email. Do số lượng lớn người tham gia, hội nghị có tính kết hợp cao giữa các ban quản trị, và các thành viên phải chịu một số ràng buộc: codec được sử dụng phải duy trì ổn định. Nếu một thành viên mới có khả năng thay đổi và kích hoạt thay đổi codec, một thơng báo SDP mới phải được tạo. Truyền bá thông tin này bằng SAP hoặc cách khác sẽ rất mất thời gian và hầu hết các trình nghe RTP bị bỏ qua cho đến khi người nghe nhận được thơng báo mới. Cái khó là cho phép ban quản trị mời một người nghe nói chuyện, để cho người nghe yêu cầu. và được cấp quyền đặt câu hỏi. Để tham gia hoặc được mời bởi ban hội thẩm, Trình nghe RTP cũng phải có một số khả năng H.323. Các thiết bị đầu cuối RTP / RTCP đơn giản có thể chỉ lắng nghe. Để tham gia