Bài giảng Báo hiệu và điều khiển kết nối

ề trạng thái rỗi. Các bƣớc báo hiệu để thiết lập và giải phóng cuộc gọi thông thƣờng gồm: 1) Khi bên chủ gọi nhấc máy, tổng đài nhận đƣợc yêu cầu thiết lập cuộc gọi và gửi âm mời quay số. 2) Khi nhận và xử lý xong số thuê bao bị gọi, tổng đài sẽ chiếm dùng một kênh thoại ngõ ra đồng thời gửi đi bản tin IAM hoặc IAI tuỳ theo bản tin gửi đi có kèm theo thông tin phụ trợ hay không. Đồng thời lúc bản tin IAM hoặc IAI PT IT 49 đƣợc gửi, nếu cần kiểm tra tính liên tục của đƣờng thoại (Continuity Checking) thì bộ phận gửi và nhận các âm hiệu kiểm tra đƣợc điều khiển kết nối vào. 3) Khi nhận đƣợc bản tin IAM hoặc IAI, tổng đài kết cuối phải xác định rằng có cần phải thực hiện việc kiểm tra tính liên tục của đƣờng thoại hay không bằng cách xem xét nội dung thông tin trong bản tin IAM hoặc IAI. Tổng đài bên bị gọi bắt đầu phân tích các chữ số địa chỉ nhận đƣợc trong bản tin IAM hay IAI. 4) Kiểm tra tính liên tục thành công để đảm bảo mạch thoại tốt gồm: Bộ phận gửi âm hiệu kiểm tra đƣợc giải toả, và bản tin báo hiệu tính liên tục đƣợc gửi đi đến tổng đài bên bị gọi. 5) Khi tổng đài kết cuối cuộc gọi nhận đƣợc bản tin báo hiệu tính liên tục của đƣờng truyền (Continuity signal) điều này biểu thị rằng việc kiểm tra tính liên tục của đƣờng thông thoại đã thành công. Tổng đài sẽ giải toả việc nối mạch cho việc kiểm tra này. 6) Nhận đƣợc thêm các con số khi thuê bao sử dụng phƣơng thức quay số overlap thì các con số tiếp theo đƣợc gửi trong bản tin SAM hay SAO. 7) Khi tổng đài bên bị gọi đã hoàn tất việc phân tích số và thiết lập cuộc nối thì sẽ gửi bản tin ACM để thông báo hoàn thành việc nhận địa chỉ. Bản tin ACM chứa thông tin về cƣớc (tính cƣớc, không tính cƣớc và dạng coin-box) cũng nhƣ trạng thái thuê bao bị gọi (rỗi, chƣa xác định). 8) Khi nhận đƣợc bản tin ACM, tổng đài bên chủ thực hiện nối thông đƣờng thoại cho tín hiệu hồi âm chuông từ phía tổng đài bị gọi tới thuê bao chủ gọi. 9) Khi thuê bao bị gọi nhấc máy, bản tin trả lời ANM sẽ đƣợc gửi đi kèm theo thông tin tính cƣớc (có, không). 10) Khi nhận đƣợc bản tin ANM, tổng đài chủ gọi thực hiện việc tính cƣớc. 11) Khi thuê bao bị gọi đặt máy kết thúc cuộc gọi, bản tin giải toả cuộc gọi theo hƣớng về (CBK) sẽ đƣợc gửi tới tổng đài chủ gọi. PT IT 50 12) Khi nhận đƣợc bản tin CBK, tổng đài chủ gọi sẽ báo cho thuê bao gọi bằng âm hiệu báo gác máy. Khi thuê bao gọi gác máy, bản tin giải toả cuộc gọi theo hƣớng đi (CLF) sẽ đƣợc gửi đi. 13) Khi tổng đài kết cuối nhận đƣợc bản tin CLF, mạch thoại sẽ đƣợc giải toả và trở về trạng thái rỗi. Bản tin RLG sẽ đƣợc gửi đến tổng đài xuất phát cuộc gọi để kết thúc. 14) Nhận đƣợc bản tin RLG tổng đài kết thúc cuộc nối. Bên cạnh các bản tin sử dụng để thiết lập cuộc gọi tƣơng tự nhƣ cho cuộc gọi thông thƣờng, cuộc gọi ISDN đƣợc bổ sung bởi một số bản tin để quản lý và giải phóng kênh gồm: Bản tin giải phóng cuộc nối REL (release) để giải phóng kênh nối kể cả kết nối không thành công; bản tin giải phóng hoàn toàn REC (realease complete) để xác nhận kênh hoàn toàn rỗi để sử dụng cho các kết nối khác. Các bƣớc thủ tục chính trong quá trình thiết lập, quản lý và giải phóng cuộc gọi ISDN chỉ ra trên hình 2.16 gồm: 1) Khi thuê bao ISDN bắt đầu cuộc gọi, bản tin SETUP đƣợc truyền từ thiết bị đầu cuối đến mạch DSLC sử dụng kênh D. 2) Tổng đài xuất phát cuộc gọi chuyển đổi bản tin SETUP nhận đƣợc thành bản tin ISUP IAM rồi gửi tới tổng đài bên bị gọi. 3) Khi tổng đài bên bị gọi nhận đƣợc bản tin IAM, tổng đài gửi bản tin SETUP tới thiết bị đầu cuối thuê bao bị gọi. 4) Thiết bị đầu cuối bên bị gọi thông báo cho thuê bao bên đó nhu cầu liên lạc. Đồng thời thiết bị đầu cuối gửi bản tin ALERT tới tổng đài bên đó để báo rằng thuê bao đang bị gọi. 5) Khi tổng đài bên bị gọi nhận đƣợc bản tin ALERT, tổng đài gửi bản tin ISUP ACM (địa chỉ hoàn thành) cho tổng đài bên gọi. 6) Khi thuê bao bên bị gọi trả lời, thiết bị đầu cuối bên đó gửi bản tin CONN tới tổng đài bên bị gọi mà ở đó bản tin chuyển đổi thành bản tin ANM (trả lời) rồi gửi tới tổng đài bên gọi. PT IT 51 Kết thúc cuộc gọi từ phía chủ gọi hoặc bị gọi. Khi phía chủ gọi hoặc bị gọi đặt máy, cuộc đàm thoại kết thúc, thiết bị đầu cuối gửi bản tin DISC tới tổng đài. Khi tổng đài nhận đƣợc bản tin này, tổng đài gửi bản tin REL cho tổng đài bên kia. Hình 2.10: Lưu đồ báo hiệu cho cuộc gọi ISDN 2.3 BỘ GIAO THỨC BÁO HIỆU H.323 2.3.1 Thành phần mạng báo hiệu H.323 H.323 là bộ giao thức của ITU-T định nghĩa các dịch vụ truyền thông đa phƣơng tiện trên cơ sở mạng chuyển mạch gói. Phiên bản đầu tiên đƣợc đƣa ra vào năm 1996 và gồm 5 phiên bản. Phiên bản 1 và 2 hỗ trợ giao thức H.245 trên nền giao thức điều khiển truyền dẫn TCP (Transmision Control Protocol), Q.931 trên nền TCP và các thủ tục đăng ký, quản trị và trạng thái RAS (Registration, Admission and Status) trên nền giao thức dữ liệu ngƣời dùng UDP (User Datagram PT IT 52 Protocol). Các phiên bản 3 và 4 hỗ trợ thêm H.245 và Q.931 trên cả nền TCP và UDP. Phiên bản 5 hỗ trợ các kiến trúc báo hiệu đảm bảo chất lƣợng dịch vụ. Hình 2.11: Các thành phần mạng H.323 Kiến trúc H.323 đƣợc sử dụng rộng rãi trên cả mạng cục bộ LAN hoặc mạng gói diện rộng WAN. Phiên thiết lập truyền thông đa điểm trong hệ thống H.323 đƣợc điều khiển bởi khối điều khiển đa điểm H.323. H.323 sử dụng trong mạng WAN thông qua Gatekeeper hoặc các thiết bị Gateway. Gatekeeper còn có các chức năng biên dịch địa chỉ, quản lý vùng, điều khiển băng thông, quản lý băng thông, điều khiển cuộc gọi. Mọi kết nối WAN đều đƣợc xử lý bằng một hoặc nhiều gateway H.323.Về mặt kỹ thuật, bất kể thiết bị nào nằm ngoài gateway H.323 đều không đƣợc đề cập trong khuyến nghị H.323, nhƣng các gateway H.323 có thể phối hợp hoạt động với các loại thiết bị khác nhau trong các cấu trúc mạng khác nhau. Cấu hình mạng H.323 điển hình bao gồm các thành phần sau: (i) Đầu cuối H.323 Thiết bị đầu cuối H.323 gắn liền với với ngƣời sử dụng để thực hiện truyền thông chiều đa phƣơng tiện. Các đầu cuối H.323 cần phải hỗ trợ các chuẩn báo hiệu và thủ tục kết nối sau: o Chuẩn H.225 cho quá trình báo hiệu và thiết lập cuộc gọi. Đầu cuối H.323 Gateway Mạng chuyển mạch kênh Gatekeeper Khối đa điểm Mạng chuyển mạch gói Mạng chuyển mạch kênh PT IT 53 o Chuẩn H.245 cho việc trao đổi khả năng của đầu cuối và để tạo các kênh thông tin. o RAS cho việc đăng ký và điều khiển các hoạt động quản lý khác với GK o RTP/RTCP đƣợc sử dụng cho việc truyền các gói tin đa phƣơng tiện. o Các chuẩn mã hoá thoại. (ii) Gateway Gateway thực hiện chức năng chuyển đổi báo hiệu và dữ liệu giữa mạng IP và các mạng khác. Làm cầu nối cho phép các mạng hoạt động dựa trên các giao thức khác nhau có thể phối hợp với nhau. Cấu trúc của Gateway bao gồm bộ điều khiển cổng đa phƣơng tiện MGC (Media Gateway controller), cổng đa phƣơng tiện MG (Media Gateway) và cổng báo hiệu SG (Signalling Gateway) đƣợc minh họa trong hình 2.12. Hình 2.12: Cấu tạo của Gateway. Các đặc tính cơ bản của một Gateway trong giao thức H.323 gồm có: o Một Gateway phải hỗ trợ các giao thức báo hiệu hoạt động trong mạng H.323 và mạng sử dụng chuyển mạch kênh. o Về phía H.323, Gateway phải hỗ trợ báo hiệu điều khiển H.245 cho quá trình trao đổi khả năng hoạt động của đầu cuối cũng nhƣ của Gateway, báo hiệu cuộc gọi H.225, báo hiệu RAS. Về phía mạng chuyển mạch kênh, Gateway phải hỗ trợ các giao thức hoạt động trong mạng chuyển mạch kênh (nhƣ SS7 sử dụng trong PSTN). PT IT 54 (iii) Gatekeeper Một Gatekeeper đƣợc xem là khối trung tâm điều khiển cuộc gọi trong mạng sử dụng H.323. Mặc dù là thành phần tuỳ chọn, nhƣng Gatekeeper cung cấp các dịch vụ quan trọng nhƣ biên dịch địa chỉ, sự phân quyền và nhận thực cho thiết bị đầu cuối và Gateway, quản lý băng thông, thu thập số liệu và tính cƣớc. Các chức năng này đƣợc mô tả trong hình 2.13. Hình 2.13: Chức năng của một Gatekeeper (iv) Khối điều khiển đa điểm MCU MCU là thành phần hỗ trợ dịch vụ hội nghị điểm đa điểm nếu phiên làm việc có sự tham gia của từ 2 đầu cuối H.323 trở lên. Mọi đầu cuối tham gia vào hội nghị đều phải thiết lập một kết nối với MCU. MCU gồm hai chức năng cơ bản: Điều khiển đa điểm và nhận, xử lý các luồng dữ liệu cho phiên đa điểm. 2.3.2 Các giao thức báo hiệu cuộc gọi trong H.323 Tiêu chuẩn H.323 có tham chiếu đến một tiêu chuẩn khác của ITU-T là H.225. H.225 thực hiện báo hiệu cho việc điều khiển cuộc gọi. H.225 có quyền giống nhƣ H.323 để xác định một tập hợp các khả năng báo hiệu cuộc gọi cho luồng đa phƣơng tiện. H.225 sử dụng các bản tin đƣợc định nghĩa theo chuẩn báo hiệu điều khiển H.245 để thiết lập và giải phóng các kênh dữ liệu đa phƣơng tiện. Gatekeeper H.225.0 RAS (server) H.225.0 Báo hiệu cuộc gọi H.245 Báo hiệu điều khiển Dịch vụ tính cƣớc Dịch vụ bảo mật Dịch vụ thƣ mục Quản lý cuộc gọi/ chính sách Các giao thức truyền tải và giao diện mạng PT IT 55 Hình 2.14: Mô hình kết nối báo hiệu trong H.323 Các thủ tục H.225 cho phép chuyển các bản tin báo hiệu từ thiết bị gửi tới thiết bị nhận. Yêu cầu thiết lập cuộc gọi đƣợc thực hiện trên các kênh H.225 là đăng ký, quản lý và báo hiệu RAS (Register, Administrator and Signalling). RAS đƣợc định nghĩa nhƣ một tài nguyên mạng và sử dụng UDP nhƣ một phƣơng thức truyền tải. Kênh RAS giúp các thiết bị có thể giám sát đƣợc tín hiệu khởi tạo của các cuộc kết nối. Khi các yêu cầu đƣợc truyền trên RAS tới Gatekeeper, Gatekeeper trả lời các thông tin về phía chủ gọi các thông tin bao gồm địa chỉ IP và số cổng TCP của thiết bị bên bị gọi, cho phép ngƣời gọi thiết lập một kết nối TCP. Để xem xét các luồng thông tin báo hiệu trong H.323, ta xem xét một mô hình kết nối đơn giản nhƣ trên hình 2.14. Các thông tin báo hiệu điều khiển cuộc gọi đƣợc thực hiện trên các kết nối từ thiết bị đầu cuối tới Gatekeeper và gateway. Các bản tin của Q.931 đƣợc sử dụng tiếp theo sau khi quá trình bắt tay thành công qua RAS. Nếu hệ thống không có Gatekeeper thì không cần đến RAS và Q.931 là giao thức sẽ đƣợc sử dụng để thiết lập cuộc thoại giữa các đầu cuối. Q.931 thực hiện việc trao đổi trực tiếp các thông báo giữa 2 đầu cuối với mục đích thiết lập cuộc gọi và chấm dứt cuộc gọi khi một trong các bên kết thúc hội thoại. Khi hai bên đồng ý tham gia cuộc gọi sau quá trình bắt tay qua Q.931 thì bƣớc tiếp theo là hai bên thống nhất một cách thức hội thoại phù hợp bao gồm các công việc sau: thỏa thuận về bộ CODEC đƣợc sử dụng, mở hai cổng UDP kề nhau cho các kênh logic truyền và điều khiển dòng thông tin đa phƣơng tiện, quản lý kênh PT IT 56 logic thông qua việc xác lập máy chủ/máy khách, điều khiển tốc độ truyền dòng bit. Các công việc trên đƣợc thực hiện qua H.245. 2.3.3 Nguyên tắc hoạt động của thủ tục báo hiệu cuộc gọi Trong quá trình thiết lập cuộc gọi qua H.323 gồm 5 giai đoạn theo ví dụ chỉ trên hình 2.15 trên đây gồm: Giai đoạn 1: Giai đoạn thiết lập cuộc gọi. Trong quá trình này, đầu cuối chủ gọi thông báo cho bên bị gọi yêu cầu mở một kênh audio. Giai đoạn này cũng xác định bản tin với mục đích thông báo cho chủ gọi là bên bị gọi đã nhận đƣợc thông báo về cuộc gọi. Độ chính xác của tín hiệu thiết lập cuộc gọi tuỳ thuộc vào cấu hình mạng, cụ thể là sự tồn tại và vị trí của các Gatekeeper. Trong mọi trƣờng hợp, đầu cuối chủ gọi sẽ bắt đầu một kết nối có chƣa địa chỉ IP kênh điều khiển H245 với mục đích thiết lập kênh truyền thông bằng bản tin H.245. Hình 2.15: Tiến trình xử lý báo hiệu một cuộc gọi đơn giản trong H.323 Giai đoạn 2: Giai đoạn truyền thông và thiết lập khả năng trao đổi. Khi hoàn thành giai đoạn thiết lập cuộc gọi, cả 2 đầu cuối sẽ bƣớc sang giai đoạn 2. Giai đoạn này PT IT 57 liên quan đến thiết lập kênh điều khiển H.245 thông qua việc trao đổi thông tin có liên quan đến khả năng của từng điểm trong cuộc gọi. Trong trƣờng hợp này là khả năng liên quan đến kiểu loại kênh truyền thông đƣợc hỗ trợ. Ví dụ các gateway H.323 phải hỗ trợ cho các kênh audio. Giai đoạn 3: Giai đoạn thiết lập và truyền thông audio. Trong giai đoạn này, các đầu cuối sẽ trao đổi để thiết lập các kênh logic sẽ truyền tải các luồng thông tin. Đối với thông tin audio, mỗi đầu cuối cuộc gọi sẽ mở một kênh duy nhất bởi vì sẽ không có một yêu cầu nào có cùng mã hoặc tốc độ bit đƣợc sử dụng theo cả hai hƣớng. Giai đoạn 4: Giai đoạn xác lập tham số cuộc gọi. Tham số cuộc gọi là những thay đổi các tham số đã đƣợc thoả thuận trong 3 giai đoạn trên. Các tham số này gồm cả việc điều chỉnh băng tần mà cuộc gọi đòi hỏi, bổ sung hoặc loại bỏ các thành phần tham gia cuộc gọi hoặc trao đổi trạng thái giữ tham số giữa gateway và đầu cuối. Giai đoạn 5: Giải phóng cuộc gọi: Thiết bị muốn giải phóng cuộc gọi H.323 có thể tiến hành đơn giản bằng cách cho phép chuyển các bản tin xoá cuộc gọi giống nhƣ chuyển các bản tin thiết lập cuộc gọi đƣợc sử dụng lúc bắt đầu cuộc gọi. Cũng giống nhƣ khi thiết lập, các thủ tục giải phóng cuộc gọi khác nhau tuỳ thuộc vào vai trò của Gatekeeper trong cuộc gọi. Nhƣ vậy, qua mô tả một cuộc gọi điển hình trên đây cho thấy các giao thức nguyên thuỷ sử dụng điều khiển cuộc gọi trong H.323 là các giao thức H.225 và H.245. Ngoài ra, giao thức báo hiệu từ đầu cuối tới đầu cuối đƣợc hỗ trợ bởi Q.931. 2.4 GIAO THỨC KHỞI TẠO PHIÊN SIP Theo định nghĩa của IETF, “Giao thức khởi tạo phiên” SIP (Session Initiation Protocol) là “giao thức báo hiệu lớp ứng dụng mô tả việc khởi tạo, thay đổi và giải phóng các phiên kết nối tƣơng tác đa phƣơng tiện giữa những ngƣời sử dụng”. SIP dựa trên ý tƣởng và cấu trúc của HTTP (HyperText Transfer Protocol) là giao thức trao đổi thông tin của World Wide Web. SIP đƣợc định nghĩa nhƣ một giao thức chủ/tớ (Client/Server), trong đó các yêu cầu đƣợc chủ gọi (Client) đƣa ra PT IT 58 và bên bị gọi (Server) trả lời. SIP sử dụng một số kiểu bản tin và các trƣờng mào đầu của HTTP, xác định nội dung luồng thông tin theo mào đầu thực thể (mô tả nội dung - kiểu loại) và cho phép xác nhận các phƣơng pháp sử dụng giống nhau đƣợc sử dụng trên Web. SIP định nghĩa các bản tin INVITE và ACK giống nhƣ bản tin Setup và Connect trong H.225, trong đó cả hai đều định nghĩa quá trình mở một kênh đáng tin cậy mà thông qua đó cuộc gọi có thể đi qua. Tuy nhiên khác với H.225, độ tin cậy của kênh này không phụ thuộc vào TCP mà có thể tích hợp vào lớp ứng dụng nhằm nâng cao khả năng tối ƣu hóa. SIP dựa vào giao thức mô tả phiên SDP (Session Description Protocol) để thực hiện sự sắp xếp tƣơng tự theo cơ cấu chuyển đổi dung lƣợng của H.245. SDP đƣợc dùng để nhận dạng mã thiết bị chuyển mạch và can thiệp vào giao thức báo hiệu luồng thời gian thực RTSP (Real Time Stream Protocol) để sắp xếp các tham số và khuôn dạng dữ liệu chung cho nhiều loại thông tin khi chuyển trong SIP. SIP là một giao thức điều khiển lớp ứng dụng mà có thể thiết lập, sửa đổi và kết thúc các phiên truyền thông đa phƣơng tiện. SIP có thể mời các thành viên tham gia vào các phiên truyền thông đơn hƣớng hoặc đa hƣớng. SIP hỗ trợ việc ánh xạ tên và các dịch vụ chuyển tiếp một cách trong suốt, vì thế cho phép thực hiện các dịch vụ thuê bao điện thoại của mạng thông minh và mạng ISDN. SIP hỗ trợ 5 khía cạnh của việc thiết lập và kết thúc các truyền thông đa phƣơng tiện sau: o Định vị ngƣời dùng (User location): xác định hệ thống đầu cuối đƣợc sử dụng trong truyền thông. o Các khả năng ngƣời dùng (User capabilities): xác định phƣơng tiện và các thông số phƣơng tiện đƣợc sử dụng. o Tính khả dụng ngƣời dùng (User Availability): xác định sự sẵn sàng của bên đƣợc gọi để tiến hành truyền thông. o Thiết lập cuộc gọi (Call setup): thiết lập các thông số của cuộc gọi tại cả hai phía bị gọi và chủ gọi. PT IT 59 o Xử lý cuộc gọi (Call handling): bao gồm truyền tải và kết thúc cuộc gọi. 2.4.1 Thành phần mạng báo hiệu SIP Các thành phần chính của một hệ thống SIP bao gồm các thành phần sau: Đầu cuối SIP (UAC/UAS); Proxy server; Location server; Redirect server; Registrar server. Hình 2.16: Cấu trúc của hệ thống SIP User Agent là thiết bị đầu cuối trong mạng SIP, nó có thể là một máy điện thoại SIP hay một máy tính chạy phần mềm đầu cuối SIP. UA có thể khởi tạo, thay đổi hay giải phóng cuộc gọi. Trong đó phân biệt hai loại UA: UAC (User Agent Client) và UAS (User Agent Server). UAC là một thực thể thực hiện việc khởi tạo một cuộc gọi còn UAS là một thực thể thực hiện việc nhận cuộc gọi. Nhƣng cả UAC và UAS đều có thể giải phóng cuộc gọi. Proxy Server là phần mềm trung gian hoạt động cả nhƣ Server và cả nhƣ Client để thực hiện các yêu cầu thay thế cho các đầu cuối khác. Tất cả các yêu cầu đƣợc xử lý tại chỗ bởi Proxy Server (nếu có thể) hoặc nó chuyển đến cho các máy chủ khác. Trong trƣờng hợp Proxy Server không trực tiếp đáp ứng các yêu cầu này thì Proxy Server sẽ thực hiện khâu chuyển đổi hoặc dịch sang khuôn dạng thích hợp trƣớc khi chuyển đi. PT IT 60 Location Server là phần mềm định vị thuê bao, cung cấp thông tin về những vị trí có thể của phía bị gọi cho các phần mềm Proxy Server và Redirect Server. Redirect Server là phần mềm nhận yêu cầu SIP và chuyển đổi địa chỉ SIP sang một số địa chỉ khác và gửi lại những địa chỉ này cho đầu cuối. Không giống nhƣ Proxy Server, Redirect Server không bao giờ hoạt động nhƣ một đầu cuối, tức là không gửi đi bất cứ một yêu cầu nào. Redirect Server cũng không thực hiện việc chấp nhận hay huỷ cuộc gọi. Registrar Server là phần mềm nhận các yêu cầu đăng ký Register. Trong nhiều trƣờng hợp Registrar Server đảm nhiệm luôn một số chức năng an ninh nhƣ xác nhận ngƣời sử dụng. Thông thƣờng Registrar Server đƣợc cài đặt cùng với Proxy hoặc Redirect Server hoặc cung cấp dịch vụ định vị thuê bao. Mỗi lần đầu cuối đƣợc bật lên (thí dụ máy điện thoại hoặc phần mềm SIP) thì đầu cuối lại đăng ký với Server. Nếu đầu cuối cần thông báo với Server về địa điểm của mình thì bản tin Register đƣợc gửi đi. Nói chung các đầu cuối đều thực hiện việc đăng ký lại một cách định kỳ. 2.4.2 Kiến trúc chức năng SIP là một giao thức phân lớp cho phép nhiều module khác nhau thực hiện chức năng độc lập với sự kết nối lỏng giữa mỗi lớp. Cấu trúc của SIP trong quá trình gửi yêu cầu và nhận đáp ứng đƣợc phân lớp nhƣ trên hình 2.17. Cú pháp và mã hóa Truyền tải Giao dịch Giao dịch người dùng Hình 2.17: Các lớp giao thức SIP Lớp đầu tiên trong giao thức là lớp cú pháp và mã hóa. Lớp này sử dụng văn phạm ABNF (Augmented Backus-Naur Form) để đƣa ra các nguyên tắc mã hóa và PT IT 61 khuôn dạng cú pháp cho bản tin SIP. Khuôn dạng này đƣợc mô tả chi tiết trong RFC2234. Lớp thứ hai trong cấu trúc SIP là lớp truyền tải. Đây là lớp chỉ thị cho client gửi yêu cầu và nhận các đáp ứng và server nhận yêu cầu và gửi các đáp ứng nhƣ thế nào. Lớp truyền tải gần giống với lớp socket của một thực thể SIP. Lớp thứ ba trong cấu trúc SIP là lớp giao dịch. Một giao dịch trong các thuật ngữ SIP là một yêu cầu đƣợc gửi bởi một client tới một server, cùng với tất cả các đáp ứng cho yêu cầu đƣợc đó đƣợc gửi từ server về client. Lớp giao dịch xử lý việc tƣơng thích đáp ứng cho yêu cầu. Thời gian hết hạn của quá trình phát lại và giao dịch của lớp ứng dụng cũng đƣợc xử lý trong lớp này và phụ thuộc vào giao thức truyền tải đƣợc sử dụng. Các giao dịch sử dụng lớp truyền tải để gửi và nhận yêu cầu và đáp ứng. Lớp thứ tƣ là lớp giao dịch chứa bốn cơ chế trạng thái giao dịch. Mỗi cơ chế trạng thái giao dịch có các tham số định thời, nguyên tắc phát lại và nguyên tắc kết cuối riêng biệt. 2.4.3 Bản tin SIP và giao thức SDP SIP là giao thức dạng văn bản, sử dụng bộ ký tự ISO 10646 trong mã hoá UTF-8 trong RFC 2279. Điều này tạo cho SIP tính linh hoạt, mở rộng và dễ thực thi các ngôn ngữ lập trình cấp cao nhƣ Java, Tol, Perl. Cú pháp của SIP gần giống với giao thức HTTP, nó cho phép dùng lại mã và đơn giản hóa sự liên kết của các máy phục vụ SIP với các máy phục vụ Web. Tuy nhiên, SIP không phải là một dạng mở rộng của HTTP và có thể sử dụng với giao thức UDP. Các dạng bản tin của SIP nhƣ sau: INVITE - Bắt đầu thiết lập cuộc gọi bằng cách gửi bản tin mời đầu cuối khác tham gia ACK - Bản tin này khẳng định client đã nhận đƣợc bản tin trả lời bản tin INVITE BYE - Bắt đầu kết thúc cuộc gọi CANCEL - Huỷ yêu cầu đang nằm trong hàng đợi REGISTER - Đầu cuối SIP sử dụng bản tin này để đăng ký với Registrar Server OPTIONS - Sử dụng để xác định năng lực của server PT IT 62 INFO - Sử dụng để tải các thông tin nhƣ tone DTMF Giao thức SIP có nhiều điểm trùng hợp với giao thức HTTP. Các bản tin trả lời các bản tin SIP nêu trên gồm có: 1xx - Các bản tin chung 2xx - Thành công 3xx - Chuyển địa chỉ 4xx - Yêu cầu không đƣợc đáp ứng 5xx - Sự cố của server 6xx - Sự cố toàn mạng. Cấu trúc bản tin SIP Cả hai loại bản tin trên đều sử dụng chung một định dạng cơ bản đƣợc quy định trong RFC 2822 với cấu trúc gồm một dòng khởi đầu (start – line), một số trƣờng tiêu đề và một phần thân bản tin tuỳ chọn (hình 2.18). Hình 2.18: Cấu trúc bản tin SIP Trong đó, dòng bắt đầu, các dòng tiêu đề hay các dòng trắng phải đƣợc kết thúc bằng một ký tự xuống dòng (CRLF) và phải lƣu ý rằng dòng trắng vẫn phải có để ngăn cách phần tiêu đề và phần thân của bản tin ngay cả khi phần thân bản tin là rỗng. Start line: Mỗi bản tin SIP đƣợc bắt đầu với một Start Line, Start Line vận chuyển loại bản tin (phƣơng thức trong các Request, và mã đáp ứng trong các bản tin đáp ứng) và phiên bản của giao thức. Start line có thể là Request-Line (trong các yêu cầu) hoặc là Status-Line (trong các đáp ứng). Headers: Các trƣờng Hearder của SIP đƣợc sử dụng để vận chuyển các thuộc tính của bản tin và để thay đổi ý nghĩa của bản tin. Chúng tƣơng tự nhƣ các trƣờng tiêu PT IT 63 để của bản tin HTTP theo cả cú pháp và ngữ nghĩa. Tiêu đề bản tin bao gồm bốn loại: tiêu đề chung, tiêu đề yêu cầu, tiêu đề đáp ứng và tiêu để thực thể. Body: Thân bản tin đƣợc sử dụng để mô tả phiên đƣợc khởi tạo (ví dụ: trong một phiên multimedia phần này sẽ mang loại mã hóa audio và video, tốc độ lấy mẫu …), hoặc nó có thể đƣợc sử dụng để mang dữ liệu dƣới dạng text hoặc nhị phân (không đƣợc dịch) mà liên quan đến phiên đó. Phần thân bản tin có thể xuất hiện trong cả bản tin yêu cầu và đáp ứng. Các loại Body bao gồm: giao thức mô tả phiên SDP, mở rộng thƣ điện tử internet đa mục đích MIME (Multipurpose Internet Mail Extentions) và các phần định nghĩa trong IETF. SDP là một giao thức lớp ứng dụng đƣợc IETF thiết kế để mô tả các phiên đa phƣơng tiện và là giao thức dựa trên văn bản. SDP mang thông tin về các luồng phƣơng tiện để các bên tham gia phiên đa phƣơng tiện có thể biết đƣợc thông tin thiết lập tƣơng ứng. SDP chỉ có mục đích mô tả phiên chứ không phải để đàm phán các phƣơng thức mã hoá phƣơng tiện. Nó không chứa bất kỳ giao thức chuyển tải nào. Vì thế thông thƣờng SDP đƣợc chứa trong phần tải tin của các giao thức khác. Chẳng hạn phần tải tin trong bản tin INVITE có thể chứa SDP nếu có chỉ thị về nó trong tiêu đề content-type và content-application. Một bản tin SDP bao gồm các mức thông tin sau: o Mô tả mức phiên. Mức này bao gồm nhận dạng phiên và các thông số mức phiên khác nhƣ địa chỉ IP, chủ đề, thông tin giao tiếp về bộ tạo và/hay phiên. o Mô tả mức định thời. Thời gian bắt đầu và kết thúc, thời gian lặp lại, một hay nhiều mô tả mức phƣơng tiện. o Khuôn dạng và loại phƣơng tiện. Giao thức truyền tải và số cổng, các thông số mức phƣơng tiện khác. 2.4.4 Thủ tục trao đổi thông tin của SIP Trong một cuộc hội thoại SIP, mỗi bên tham gia đƣợc gắn một địa chỉ SIP (SIP URL), địa chỉ này do ngƣời dùng đăng ký với SIP Server. Để tạo một cuộc gọi SIP, phía chủ gọi định vị tới máy phục vụ thích ứng và sau đó gửi một yêu cầu SIP. Hoạt PT IT 64 động SIP thƣờng xuyên nhất là lời mời các thành viên tham gia hội thoại. Thành phần Register đóng vai trò tiếp nhận các yêu cầu đăng ký từ UA và lƣu trữ các thông tin này tại một dịch vụ phi SIP (Non-SIP). Một địa chỉ SIP có dạng user@host. Phần user là một tên của ngƣời sử dụng hay tên của một máy điện thoại. Phần host có thể là một tên miền hoặc một địa chỉ mạng. SIP URL đƣợc dùng trong các bản tin SIP để thông báo về nơi gửi (From), đích hiện thời (Request URI) và nơi nhận cuối cùng (To) của một yêu cầu SIP và chỉ rõ địa chỉ gián tiếp. Một SIP URL có thể gắn vào một trang Web hoặc những siêu liên kết (Hyperlink) khác để thông báo rằng ngƣời dùng hoặc dịch vụ có thể gọi thông qua SIP. Quá trình định vị tới máy chủ SIP Khi một Client muốn gửi đi một yêu cầu, Client sẽ gửi bản tin yêu cầu đó tới SIP máy chủ Proxy, hoặc tới địa chỉ IP và cổng tƣơng ứng trong địa chỉ của yêu cầu SIP (Request-URI). Trƣờng hợp đầu, yêu cầu đƣợc gửi tới máy chủ Proxy không phụ thuộc vào địa chỉ của yêu cầu. Với trƣờng hợp sau, Client phải xác định giao thức, cổng và địa chỉ IP của Server mà yêu cầu đƣợc gửi đến. Một Client thực hiện các bƣớc tiếp theo để có đƣợc những thông tin này. Client cố gắng liên lạc với Server theo số cổng đƣợc chỉ ra trong địa chỉ yêu cầu SIP (Request-URI). Nếu không có số cổng nào chỉ ra trong Request-URI, Client sẽ sử dụng địa chỉ cổng mặc định là 5060. Nếu Request-URI chỉ rõ là sử dụng giao thức TCP hay UDP, Client sẽ làm việc với Server theo giao thức đó. Nếu không có giao thức nào đƣợc chỉ ra thì Client cố gắng dùng giao thức UDP (nếu không hỗ trợ TCP) hoặc sử dụng giao thức TCP cho hoạt động của mình (chỉ đƣợc hỗ trợ TCP mà không đƣợc hỗ trợ UDP). Client cố gắng tìm một hay nhiều địa chỉ cho SIP Server bằng việc truy vấn DNS (Domain Name System) theo các thủ tục sau: Nếu địa chỉ Host trong địa chỉ Request-URI là một địa chỉ IP thì Client làm việc với Server bằng địa chỉ đƣợc đƣa ra. Nếu đó không phải là một địa chỉ IP, Client thực hiện bƣớc tiếp theo. PT IT 65 Client đƣa ra câu hỏi tới DNS Server về bản ghi địa chỉ cho địa chỉ Host trong địa chỉ Request-URI. DSN sẽ trả về một bản ghi danh sách các địa chỉ. Lúc đó việc lựa chọn một trong các địa chỉ này là tùy ý. Còn nếu DNS Server không đƣa ra bản ghi địa chỉ, Client sẽ kết thúc hoạt động, có nghĩa nó không thực hiện đƣợc việc định vị máy chủ. Nhờ bản ghi địa chỉ, sự lựa chọn tiếp theo cho giao thức mạng của Client có nhiều khả năng thành công hơn. Một quá trình thực hiện thành công là quá trình có một bản ghi chứa trong phần trả lời và Server làm việc ở một trong những địa chỉ chứa trong trả lời đó. Giao dịch SIP Khi có địa chỉ IP của SIP Server thì yêu cầu sẽ đƣợc gửi đi theo tầng vận chuyển giao thức TDP hay UDP. Client gửi một hoặc nhiều yêu cầu SIP đến máy chủ đó và nhận lại một hoặc nhiều các phúc đáp từ máy chủ. Một yêu cầu cùng với các phúc đáp đƣợc tạo ra bởi yêu cầu đó tạo thành một giao dịch SIP. Tất cả các phúc đáp cho một yêu cầu mang cùng các giá trị trong các trƣờng: Call – ID, Cseq, To, và From. Yêu cầu ACK xác định sự nhận một phúc đáp INVITE không là một phần của giao dịch vì nó có thể di chuyển giữa một tập các host khác nhau. Mỗi cuộc gọi trong SIP đƣợc định danh bởi một trƣờng định danh cuộc gọi (Call-ID). Một yêu cầu phải cần có thông tin gửi đi từ đâu (From) và tới đâu (To). Trƣờng From và To đều có cấu trúc theo khuôn dạng SIP-URL. Trƣờng CSeq lƣu trữ thông tin về phƣơng thức sử dụng trong phiên, trƣờng CSeq có dạng: CSeq = “CSeq”: “DIGIT Method”. Trong đó DIGIT là số nguyên không dấu 32 bit. Nếu một giao thức điều khiển luồng tin cậy đƣợc sử dụng, yêu cầu và các phúc đáp trong một giao dịch đơn lẻ đƣợc mang trên cùng kết nối. Một vài yêu cầu SIP từ cùng máy khách đến cùng máy chủ có thể sử dụng cùng kết nối hoặc có thể sử dụng một kết nối mới cho mỗi yêu cầu. Nếu một client gửi yêu cầu thông qua một giao thức datagram đơn hƣớng nhƣ UDP thì các UA thu sẽ định hƣớng phúc đáp theo thông tin chứa trong các trƣờng PT IT 66 mào đầu Via. Mỗi proxy server trong tuyến chuyển tiếp của yêu cầu chuyển tiếp phúc đáp sử dụng các trƣờng mào đầu Via này. Lời mời SIP Một lời mời SIP thành công gồm hai yêu cầu INVITE và ACK. Yêu cầu INVITE thực hiện lời mời một thành viên tham gia hội thoại. Khi phía bị gọi đồng ý tham gia, phía chủ gọi xác nhận đã nhận một bản tin đáp ứng bằng cách gửi đi một yêu cầu ACK. Nếu phía chủ gọi không muốn mời thành viên tham gia cuộc gọi nữa nó sẽ gửi yêu cầu BYE thay cho ACK. Thông điệp INVITE chứa thành phần mô tả phiên của giao thức SDP và phƣơng thức tiến hành trao đổi ứng với phiên đó. Với các phiên đa hƣớng, phần mô tả phiên liệt kê kiểu và khuôn dạng của các dữ liệu đa phƣơng tiện để phân phối cho phiên hội thoại. Với một phiên đơn hƣớng, phần mô tả phiên liệt kê kiểu và khuôn dạng của các phƣơng tiện mà phía chủ gọi muốn sử dụng và nơi những dữ liệu muốn gửi đi. Định vị người dùng Một đối tƣợng bị gọi có thể di chuyển giữa một số các hệ thống đầu cuối khác nhau theo thời gian. Một máy chủ định vị cũng có thể sử dụng một hay nhiều giao thức khác nhau để xác định hệ thống đầu cuối mà tại đó một ngƣời sử dụng có thể liên lạc. Một máy chủ định vị có thể đƣa ra một vài vị trí vì ngƣời sử dụng đƣợc đăng nhập vào tại một vài host đồng thời hoặc bởi vì máy chủ định vị lỗi. Máy chủ SIP kết hợp các kết quả để đƣa ra một danh sách các vị trí. Đối với từng kiểu SIP Server thì hoạt động sau khi nhận đƣợc danh sách các vị trí khác nhau là khác nhau. Một SIP Redirect Server sẽ trả lại danh sách địa chỉ cho Client với các mào đầu Contact. Một SIP proxy server có thể thử lần lƣợt hoặc song song các địa chỉ cho đến khi cuộc gọi thành công (phúc đáp 2xx) hoặc bên bị gọi từ chối cuộc gọi (phúc đáp 6xx). PT IT 67 Nếu một proxy server chuyển tiếp một yêu cầu SIP, nó phải bổ sung địa chỉ của nó vào vị trí bắt đầu của danh sách các trạm chuyển tiếp đƣợc ghi trong các mào đầu Via. Dấu vết Via đảm bảo rằng các trả lời có thể đi theo cùng tuyến đó theo hƣớng ngƣợc lại, việc đảm bảo hoạt động chính xác nhờ tuân theo các tƣờng lửa và tránh lặp lại yêu cầu. Ở hƣớng phúc đáp, mỗi host phải xoá bỏ Via của nó, do đó thông tin định tuyến nội bộ đƣợc che khuất đối với phía bị gọi và các mạng bên ngoài. Thay đổi một phiên hiện tại Trong một vài trƣờng hợp, cần phải thay đổi các thông số của phiên hội thoại hiện tại. Việc đó đƣợc thực hiện bởi việc phát lại các yêu cầu INVITE. Các yêu cầu INVITE đó có cùng trƣờng Call-ID nhƣng có trƣờng mào đầu và trƣờng bản tin khác với yêu cầu ban đầu để mang thông tin mới. Các bản tin INVITE đó phải có chỉ số CSeq cao hơn các yêu cầu trƣớc. Ví dụ: có hai thành viên đang hội thoại và muốn có thêm một ngƣời thứ ba tham gia. Một trong hai thành viên sẽ mời thành viên thứ ba tham gia với một địa chỉ đa hƣớng (Multicast) mới và đồng thời gửi một bản tin INVITE đến thành viên thứ hai với trƣờng miêu tả phiên đa hƣớng nhƣng có trƣờng Call-ID cũ. 2.5 GIAO THỨC ĐIỀU KHIỂN CỔNG PHƯƠNG TIỆN MEGACO 2.5.1 Kiến trúc chức năng báo hiệu Megaco/H.248 Megaco/H.248 là giao thức đƣợc ra đời trên sự kế thừa và phát huy các tính năng của giao thức điều khiển công đa phƣơng tiện MGCP (Media Gateway Control Protocol). Đây là giao thức đƣợc xây dựng theo sự hợp tác của hai tổ chức ITU và IETF. So với MGCP thì Megaco có những cải tiến sau: o Cung cấp dịch vụ đa phƣơng tiện và dịch vụ hội nghị đa điểm. o Cho phép lựa chọn giao thức truyền tải TCP hoặc UDP. o Cải tiến cú pháp lệnh để việc xử lý bản tin hiệu quả hơn. o Cho phép mã hoá cả dƣới dạng text và nhị phân. PT IT 68 o Dễ dàng cải thiện và nâng cấp các chức năng. o Đƣa ra khái niệm mới “Context” nhằm hỗ trợ kết nối đa dịch vụ, đa điểm . Giao thức MEGACO/H.248 định nghĩa giao diện điều khiển của MGC đối với MG tƣơng tự và sẽ thay thế MGCP. MEGACO/H.248 cung cấp các chức năng sau: o Điều khiển các loại MG khác nhau. o Hỗ trợ đàm phán quyết định các thuộc tính cuộc gọi. o Có khả năng xử lý cuộc gọi đa ngƣời dùng. o Hỗ trợ QoS và đo lƣờng lƣu lƣợng (các thông tin thống kê sau mỗi kết nối). o Thông báo lỗi giao thức, lỗi mạng hay các thuộc tính cuộc gọi. Các bản tin MEGACO/H.248 có thể đƣợc truyền dẫn qua lớp UDP/IP hoặc TCP/IP. Các MG và MGC sẽ đƣợc gán các địa chỉ IP. Các luồng lƣu lƣợng đi và đến sẽ qua các cổng UDP hay TCP đƣợc chỉ ra. Ví dụ nhƣ cổng dành cho lệnh Service Change request là 2944 khi sử dụng mã hóa văn bản và 2945 khi sử dụng mã hóa nhị phân (đối với cả UDP và TCP). Hình 2.17: Kiến trúc điều khiển của MEGACO Kiến trúc giao thức MEGACO đƣợc chỉ ra trên hình 2.17 gồm các thành phần: Lớp MGC chứa tất cả các phần mềm điều khiển, xử lý cuộc gọi. Lớp này thực hiện các tính năng thuộc mức cuộc gọi nhƣ phát triển cuộc gọi, chuyển cuộc gọi, hội thoại hay giữ máy. Lớp MGC cũng thực hiện giao tiếp với các MGC khác cũng PT IT 69 nhƣ các thực thể ngang cấp hay cấp dƣới. MGC quản lý mọi thuộc tính trong quá trình giao tiếp. Lớp MG thực hiện kết nối lƣu lƣợng đi và tới các mạng khác, tƣơng tác với các luồng lƣu lƣợng này qua ứng dụng báo hiệu và sự kiện. Lớp MG cũng điều khiển các thuộc tính thiết bị của cổng phƣơng tiện (ví dụ nhƣ giao diện với ngƣời dùng). Lớp này không quan tâm tới việc điều khiển các thuộc tính cuộc gọi và hoạt động theo sự điều khiển của lớp MGC. Lớp điều khiển giao thức MEGACO/H248 quy định cách thức mà lớp MGC điều khiển lớp MG. Vị trí của giao thức MEGACO trong mô hình OSI nhƣ chỉ ra trong hình 2.18. Giao thức MEGACO thực hiện chức năng của mình ở 3 lớp trên cùng trong mô hình OSI: lớp ứng dụng, lớp trình diễn và lớp phiên. Hình 2.18: Giao thức MEGACO trong mô hình OSI 2.5.2 Các lệnh và thủ tục trao đổi thông tin Giao thức MEGACO sử dụng 8 lệnh cơ bản trong giao diện điều khiển giữa MGC và MG. Bao gồm: o Add: Đƣợc sử dụng để thêm một termination vào context, cũng có thể để tạo một context (nếu đó là termination đầu tiên trong context này). o Modify: Sử dụng để thay đổi thuộc tính, sự kiện hay các báo hiệu ở một termination. o Subtract: Sử dụng để xoá một termination khỏi context, cũng có thể là xoá luôn cả context (nếu đó là termination cuối cùng trong context này). PT IT 70 o Move: Chuyển một termination từ một context này sang một context khác. o Audit Value: Trả lại trạng thái hiện tại của termination (báo hiệu, sự kiện, thuộc tính, số liệu thống kê). o Audit Capability: Trả lại tất cả các giá trị có thể có của termination (báo hiệu, sự kiện, thuộc tính, số liệu thống kê). Các bản tin MEGACO có thể đƣợc mã hoá bằng hai cách: mã hoá nhị phân (binary encoding) và mã hoá văn bản (text encoding). Trong phƣơng pháp mã hoá nhị phân, tiêu chuẩn ISO/ITU ASN.1 đƣợc sử dụng. ASN.1 là ngôn ngữ định nghĩa cách gửi dữ liệu giữa các hệ thống khác nhau. Nó định nghĩa ở các hệ thống theo cùng một cú pháp dữ liệu (trong các giao thức tầng ứng dụng). ASN.1 đƣợc viết bằng các ngôn ngữ khác nhau trong từng hệ thống sao cho phù hợp. Khi một hệ thống muốn gửi dữ liệu, hệ thống đó sẽ mã hoá dữ liệu cần gửi theo ASN.1, sau đó gửi đi. Hệ thống nhận sẽ tiến hành giải mã theo chuẩn định sẵn ASN.1. Các luật mã hoá theo chuẩn ASN.1 bao gồm : BER(Basic Encoding Rule), CER (Canonial Encoding Rule), PER (Package Encoding Rule), DER (Distinguished Encoding Rule). Việc sử dụng luật mã hoá nào là tuỳ ngƣời thiết kế. Trong phƣơng pháp mã hoá văn bản, chuẩn ABNF đƣợc sử dụng (RFC2234). Có thể sử dụng 2 khuôn dạng : rút gọn (compact text) và đầy đủ (pretty text). Cả hai format đều có ƣu và nhƣợc điểm của mình. Khuôn dạng rút gọn cho bản tin có kích thƣớc nhỏ hơn, thời gian mã hoá ngắn hơn tuy nhiên độ tin cậy không cao bằng khuôn dạng đầy đủ. Thiết lập cuộc gọi thông qua giao thức MEGACO/H248 Khi một đầu cuối nào đó nhấc máy và định thực hiện cuộc gọi, sự kiện off-hook này sẽ đƣợc phát hiện bởi MG quản lý. MG sẽ thông báo sự kiện này tới MGC mà nó trực thuộc. MGC sẽ chỉ định MG bằng một lệnh để gửi âm báo mời quay số tới đầu cuối đó, đồng thời bản đồ các con số cũng đƣợc MG này cập nhật từ MGC, để phục vụ cho việc thu các chữ số và gửi toàn bộ số đƣợc quay về MGC. Giả sử đầu PT IT 71 cuối bị gọi thuộc một MG khác nhƣng cùng đƣợc quản lý bởi MGC nhƣ trên hình 2.19. Quá trình thiết lập liên kết đƣợc tiến hành theo 3 bƣớc cơ bản sau: MGC yêu cầu MG thứ nhất thiết lập một kết nối tại điểm kết cuối thứ nhất. MG này sẽ phân bổ tài nguyên cho kết nối yêu cầu và đáp ứng lại bằng bản tin trả lời. Bản tin trả lời sẽ chứa các thông tin cần thiết để MG thứ hai có thể gửi các bản tin một cách tin cậy tới liên kết vừa thiết lập. Các thông tin này có thể là: địa chỉ IP, tên cổng UDP, TCP hay các thông tin đóng gói bản tin. Tƣơng tự, MGC cũng yêu cầu MG thứ hai thiết lập một liên kết ở điểm kết cuối thứ hai. MG này phân bổ tài nguyên cho kết nối này trên cơ sở các thông tin trong bản tin đáp ứng của MG thứ nhất. MG thứ hai cũng đáp ứng lại bằng bản tin chứa các thông tin cần thiết nhằm đảm bảo MG thứ nhất có thể gửi các bản tin một cách tin cậy tới liên kết vừa thiết lập bởi MG thứ hai. Các thông tin trong bản tin đáp ứng của MG thứ hai sẽ đƣợc gửi tới MG thứ nhất. Khi này liên kết đã đƣợc thiết lập, quá trình truyền thông có thể diễn ra theo hai chiều. Lƣu lƣợng đƣợc truyền tải nhờ các giao thức RTP hay RTCP. Hình 2.19: Mô tả cuộc gọi MEGACO Trong trƣờng hợp hai MG đƣợc quản lý bởi 2 MGC khác nhau, các MGC này sẽ trao đổi các thông tin báo hiệu thông qua một giao thức báo hiệu từ MGC này tới MGC kia (có thể là SIP hay H323) để đảm bảo đồng bộ trong thiết lập kết nối tới hai điểm kết cuối. PT IT 72 Khi liên kết đã đƣợc thiết lập, các tham số của nó đƣợc giám sát bởi MGC và có thể đƣợc thay đổi dƣới các lệnh của MGC (ví dụ nhƣ thêm một kết cuối vào liên kết). Các bƣớc xử lý chi tiết đƣợc thể hiện thông qua lƣu đồ xử lý cuộc gọi trên hình 2.20. Giả sử có hai đầu cuối ngƣời sử dụng đƣợc kết nối với hai RGW. Trong đó, hai RGW này đƣợc quản lý bởi cùng một MGC. Quá trình MGC điều khiển các RGW diễn ra nhƣ sau: Bước 1: Ban đầu MGC gửi lệnh Modify tới tất cả các RGW để phát hiện sự kiện offhook. Bước 2: Các RGW lần lƣợt trả lời lệnh trên của MGC bằng các reply Bước 3: Giả sử ngƣời dùng A thuộc RGW1 offhook, sự kiện này sẽ đƣợc RGW1 báo cáo tới MGC bằng lệnh Notify. Bước 4: MGC gửi reply của lệnh này cho RGW1. Bước 5: MGC sẽ gửi lệnh Modify tới RGW1, lệnh này gồm 3 đặc tả (descriptor): signal descriptor đƣợc sử dụng để gửi âm mời quay số tới ngƣời dùng A, digitmap descriptor chứa mô hình mẫu các số có thể quay theo kế hoạch đánh số, event descriptor liệt kê các gói DTMF, gói tin hoàn thành quay số và gói tin giám sát trạng thái onhook của đầu cuối. Bước 6: RGW1 trả lời MGC bằng một reply. RGW1 tiến hành xử lý các descriptor theo thứ tự signal, digitmap, event descriptor. Đầu tiên âm mời quay số sẽ đƣợc gửi tới termination A, sau đó digitmap sẽ đƣợc cập nhật vào cơ sở dữ liệu của RGW1, digitmap đƣợc kích hoạt khi RGW1 thu đƣợc sự kiện hoàn thành quay số. Termination A sau khi nhận đƣợc âm mời quay số sẽ tiến hành quay số. Bước 7: Khi các con số đƣợc RGW1 thu đầy đủ và hợp lệ, chúng sẽ đƣợc gửi tới MGC bằng lệnh Notify. PT IT 73 Bước 8: MGC xác nhận lệnh trên bằng reply gửi tới RGW1. MGC sau khi nhận lệnh trên sẽ phân tích số bị gọi và biết đầu cuối termination B đó thuộc RGW2 (giả sử đầu cuối này rỗi và sẵn sàng nhận cuộc gọi). MGC tiếp tục điều khiển RGW1. Hình 2.20: Lưu đồ các bản tin xử lý cuộc gọi qua giao thức MEGACO/H248 PT IT 74 Bước 9: MGC sẽ gửi cho RGW1 hai lệnh. Lệnh Add để tạo một context và thêm ngay termination A vào đó. MGC biết rằng termination B rỗi,nó sẽ gửi hồi âm chuông cho termination A. Lệnh thứ 2 để tạo một đầu cuối logic A và thêm đầu cuối này vào context vừa tạo ra. Bước 10: RGW1 sẽ gửi reply cho MGC bao gồm contextID(1), địa chỉ IP và số cổng dành cho lƣu lƣợng. Bước 11: MGC sẽ gửi tới RGW2 2 lệnh. Lệnh 1 để tạo một context và Add termination B vào context này. Báo hiệu chuông cũng đƣợc gửi tới termination B nhờ signal descriptor. Lệnh thứ hai sẽ tạo một đầu cuối logic B và thêm đầu cuối này vào context vừa tạo ra. Các thông tin địa chỉ IP, số cổng của termination A cũng đƣợc gửi tới RGW2. Bước 12:RGW2 sau khi nhận lệnh sẽ thực hiện lệnh và gửi kết quả thực hiện tới MGC, bao gồm contextID(2), địa chỉ IP và số cổng dành cho lƣu lƣợng. MGC đợi cho termination B offhook. Bước 13: Khi termination B offhook, RGW2 sẽ báo cáo với MGC bằng lệnh Notify. Bước 14: MGC đáp ứng bằng một reply. Bước 15: MGC gửi lệnh Modify để chuyển 2 termination ở RGW2 sang chế độ gửi và nhận . Signal descriptor cũng ngắt báo hiệu chuông ở termination B. Event descriptor chuẩn bị sự kiện onhook để chờ. Bước 16: RGW2 trả lời bằng reply. Bước 17: MGC gửi lệnh Modify tới RGW1 để chuyển chế độ của 2 termination sang chế độ gửi và nhận, ngắt hồi âm chuông ở termination A, thông báo các thông tin về địa chỉ IP, số cổng cho đầu cuối logic A. Bước 18: RGW1 sau khi thực hiện các lệnh trên sẽ gửi reply cho MGC. Lúc này hai đầu cuối có thể trao đổi lƣu lƣợng theo các giao thức RTP/RTCP. Giả sử ngƣời dùng A đặt máy, sự kiện này đƣợc RGW1 phát hiện và báo cáo với MGC qua lệnh Notify. PT IT 75 Bước 19: RGW1 gửi lệnh Notify cho MGC báo cáo ngƣời dùng A offhook. Bước 20: MGC gửi reply cho RGW1. Bước 21: MGC gửi lệnh Modify tới RGW2 yêu cầu chuyển hai đầu cuối ở context 2 sang chế độ chỉ nhận và gửi âm báo bận tới đầu cuối ngƣời dùng A. Bước 22: RGW2 thực hiện lệnh và gửi reply cho MGC. Bước 23: MGC gửi lệnh Subtract tới RGW1 yêu cầu xoá 2 termination trong context 1, đồng thời xoá luôn context 1. Các số liệu thống kê mà MGC yêu cầu đƣợc chỉ ra trong Audit descriptor. Bước 24: RGW1 thực hiện lệnh và gửi reply cho MGC bao gồm các thông tin thống kê về liên kết vừa thiết lập. Bước 25: Tƣơng tự bƣớc 23, nhƣng thực hiện với RGW2. Bước 26:Tƣơng tự bƣớc 24, nhƣng thực hiện với RGW2. Nhƣ vậy, trên mối quan hệ điều khiển Client/Server các giao thức điều khiển nhƣ MGCP và Megaco/H.248 đóng vai trò làm bộ thủ tục cho các lệnh điều khiển, các bản tin báo hiệu, chỉ định vùng tài nguyên cho các kết nối. Tính đơn giản và hƣớng tới đảm bảo chất lƣợng dịch vụ là hai mục tiêu chính của các hệ thống giao thức. 2.6 GIAO THỨC ĐIỀU KHIỂN CUỘC GỌI ĐỘC LẬP KÊNH MANG BICC Để đáp ứng nhu cầu ngày càng tăng của lƣu lƣợng thoại một số nhà cung cấp đã đề nghị giải quyết vấn đề bằng cách tách biệt chức năng điều khiển cuộc gọi và chức năng điều khiển kênh mang trong mạng PSTN/ISDN. Giao thức ISUP đồng nhất nhƣ hiện nay trong báo hiệu số 7 sẽ đƣợc sủa đổi theo quan điểm trên. Kết quả là xuất hiện một giao thức mới giao thức điều khiển cuộc gọi độc lập kênh mang BICC. Giao thức điều khiển độc lập kênh mang đƣợc phát triển bởi nhóm làm việc 11 của ITU-T (ITU-T SG11). BICC cho phép các nhà điều hành phát triển mạng PSTN PT IT 76 hiện có trên công nghệ chuyển mạch kênh tới các cấu trúc mạng mới trên nền công nghệ chuyển mạch gói nhƣng vẫn duy trì toàn bộ các dịch vụ thoại truyền thống với những ảnh hƣơng nhỏ nhất tới công việc khai thác hiện thời. BICC đƣợc giới hạn chặt chẽ nhƣ sau: o Giao thức BICC đƣợc xây dựng trên giao thức báo hiệu số 7 phần ISUP để tƣơng thích hoàn toàn với các dịch vụ hiện co trên mạng PSTN/IDSN. o BICC hoạt động độc lập với các công nghệ thiết lập đƣờng truyền (độc lập kênh mang). o Có khả năng phối hợp với các giao thức báo hiệu hiện có. Điểm khởi đầu của BICC là các cuộc gọi phải vào/ra các thành phần mạng mới thông qua các điểm dịch vụ giao tiếp (ISN- Interface serving nodes). Nút phục vụ là một điểm trong mạng cung cấp chức năng cho các dịch vụ PSTN/ISDN hiện tại. ISN cung cấp một giao diện báo hiệu giữa ISUP băng hẹp và các ISN ngang cấp nhau nhƣ trên hình 2.21. ISN IWU new network IWU ISUP ISUP - BICC I/W BICC ISUP N/B exchange TDM connection TDM connection Connection signalling (user plane connection) Hình 2.21: Kiến trúc giao thức BICC Trong một kịch bản khác, các điểm phục vụ làm việc ở biên của mạng PSTN cho phép kết nối hai mạng BICC với nhau. Theo quy ƣớc gọi tên trong PSTN, cặp nút này đƣợc gọi là điểm phục vụ cổng (GSN – Gateway Serving node). Kịch bản minh họa cho giao thức BICC đƣợc trình bày dƣới đây. Nếu nhƣ hai nhà điều hành mạng BICC có thể kết nối với nhau qua PSTN/ISDN thì từng nhà điều hành cũng có thể cung cấp các dịch vụ PSTN/ISDN ngay tại các PT IT 77 nút trong mạng của mình. Các nút làm việc đó có vai trò nhƣ một vai trò chuyển tiếp nên đƣợc gọi là điểm phục vụ chuyển tiếp (TSN- Transit Serving Node). Hình 2.22: Cấu trúc các nút mạng BICC Theo yêu cầu BICC phải làm việc với mọi công nghệ mạng chuyển mạch gói, nên với mạng chuyển mạch gói ATM trong kiến trúc mạng BICC sẽ có thêm các nút BRN (Bearer Relay Node), đƣợc ATM sử dụng nhƣ những chuyển mạch trung gian dành cho báo hiệu. Kiến trúc BICC dƣợc phân tích theo 4 góc độ: Mô hình hoạt động, mô hình chức năng của từng nút mạng, mô hình tham chiếu đầy đủ và mô hình giao thức. Tuy nhiên, mục này sẽ trình bày hai khía cạnh cơ bản nhất là mô hình chức năng và mô hình giao thức của BICC. (i) Mô hình chức năng Trên quan điểm về mô hình mạng BICC, các nút mạng đƣợc phân chia thành hai loại chính. Loại thứ nhất, nút dịch vụ (SN), là nút có bao gồm cả chức năng điều khiển cuộc gọi (CSF) và chức năng điều khiển kênh mang (BCF). Loại thứ hai, nút dàn xếp cuộc gọi (CMN) là các nút chỉ có chức năng của CSS mà không bao gồm chức năng của BCF. Hình 2.23 và 2.24 tƣơng ứng là hai mô hình chức năng của hai loại nút mạng này. ISN ISNGSN BICC IWU ISUP - BICC I/W IWU BICC IWU IWU new network IWU BICC BRN (Sw) BRN (Sw) BRN (Sw) new network GSNTSN PT IT 78 Trong nút SN, các thực thể thực hiện chức năng dịch vụ cuộc gọi (CSF) và chức năng điều khiển kênh mang (BCF) có thể xây dựng tách biết. Báo hiệu điều khiển kênh mang cuộc gọi CBC đƣợc quy định trong ITU-T Q.1950. Thủ tục báo hiệu đầu vào Thủ tục báo hiệu đầu ra Chức năng dịch vụ cuộc gọi(CSF) Báo hiệu điều khiển kênh mang cuộc gọi(CBC) Nút dịch vụ (SN) BCF BIWF Báo hiệu điều khiển kênh mangBáo hiệu điều khiển kênh mang Báo hiệu điều khiển cuộc gọi Báo hiệu điều khiển cuộc gọi Kênh mang Hình 2.23: Cấu trúc chức năng nút dịch vụ Việc liên lạc giữa các SN để điều khiển kênh mang đƣợc thực hiện bởi giao thức báo hiệu điều khiển kênh mang (BCS). Báo hiệu điều khiển kênh mang có thể đƣợc triển khai trên một phƣơng thức truyền tải tách biệt hoặc có thể đƣợc truyền tải theo cơ chế đƣờng hầm theo phƣơng năm ngang trong giao thức BICC giữa hai CSF đồng cấp và theo phƣơng năm dọc giữa CSF và BCF. Giao thức đƣờng hầm điều khiển kênh mang (BCTP) đƣợc miêu tả trong Q.1990. Thủ tục báo hiệu đầu vào Thủ tục báo hiệu đầu ra Chức năng dịch vụ cuộc gọi(CSF) Nút mediation cuộc gọi(CMN) BCF BIWF Báo hiệu điều khiển kênh mangBáo hiệu điều khiển kênh mang Báo hiệu điều khiển cuộc gọi Kênh mang Báo hiệu điều khiển cuộc gọi Hình 2.24: Cấu trúc chức năng nút dàn xếp dịch vụ Cả SN và CMN đƣợc mô hình hóa kỹ bằng thuật “Half Call”. Mọi kịch bản xử lý cuộc gọi đƣợc chia thành một thủ tục báo hiệu đầu vào và một thủ tục báo hiệu đầu ra trong phạm vi của Q.1902, ít nhất một trong hai thủ tục này là BICC. PT IT 79 (ii) Mô hình chức năng Hình 2.25 chỉ ra mô hình giao thức của BICC chứa các phần tử chức năng trong hình 2.23 và 2.24 bao gồm: o Khối các chu trình BICC bao gồm các chức năng của thành phần CSF trong mô hình chức năng. o Các chức năng giao thức của thành phần BCF của mô hình chức năng đƣợc phân tán giữa các khối chức năng ánh xạ và điều khiển vật mang. Các chức năng khác đƣợc chứa trong thành phần BCF. o Vị trí mô tả BICC để cập tới các sự kiện báo hiệu vật mang thu nhận/gửi từ/đi BCF, nó liên quan tới sự sử dụng giao diện chung cho khối chức năng ánh xạ trong hình 2.25. Giao thức BICC Signalling Transport Converter Mapping Function Điều khiển kênh mang Signalling Transport Layers Giao thức điều khiển kênh mang Giao thức điều khiển cuộc gọi Transport Specific interface Bearer Specific interface Giao diện chung Giao diện chung Hình 2.25: Mô hình giao thức của BICCC o Vị trí mô tả BICC liên quan tới các bản tin BICC đang gửi/nhận liên quan tới sử dụng giao diện chung cho khối chuyển đổi truyền dẫn báo hiệu, xem ITU- T Q.2150.0. 2.7 KẾT LUẬN CHƯƠNG Nôi dung chƣơng 2 đƣa ra các vấn đề báo hiệu trong mạng cố định theo hƣớng tiếp cận máy chủ cuộc gọi tiến tới mạng thế hệ kế tiếp. Hệ thống báo hiệu số 7 trong PT IT 80 mạng điện thoại công cộng truyền thống là thành phần then chốt chung cho cả mạng di động công cộng mặt đất. Sự hội tụ mạng IP và mạng PSTN đã đƣợc ITU đƣa ra cấu trúc hệ thống báo hiệu và điều khiển mới bao gồm các giao thức trong chồng giao thức H.323 và các giao thức phụ trợ. Trong chƣơng cũng đã khái quát giao thức báo hiệu kết nối sử dụng phổ biến hiện nay không chỉ cho xu hƣớng hội tụ mạng internet và PSTN mà còn với các mạng di động thế hệ sau (SIP). Các giao thức điều khiển cổng kết nối và báo hiệu điều khiển ngang cấp giữa các thành phần điều khiển mạng cũng đƣợc trình bày dƣới khía cạnh kiến trúc chức năng, bản tin và mô hình hoạt động. Các nội dung ôn tập chính trong chương - Kiến trúc mạng hội tụ tiến tới mạng thế hệ kế tiếp; - Kiến trúc chức năng và hoạt động của hệ thống báo hiệu số 7; - Kiến trúc chức năng, các giao thức báo hiệu trong H.323; - Đặc điểm hoạt động của giao thức khởi tạo phiên SIP; - Kiến trúc và hoạt động của giao thức điều khiển cổng đa phƣơng tiện. PT IT