Luận văn Tìm hiểu kĩ thuật VOIP và triển khia ứng dụng IVR trong tra cứu đểm sinh

i. Thành phần thông tin fastSatrt này chứa một chuỗi cấu trúc OpenLogicalChanel mô tả đầy đủ các thông tin về kênh thông tin mà nó đề nghị thiết lập. Phía bị gọi có thể từ chối thủ tục kết nối nhanh bằng cách không gửi thành phần thông tin fastStart trong bất cứ gói tin trả lời nào. Lúc đó, kênh điều khiển H245 phải được thiết lập. Ngược lại, nếu phía bị gọi chấp nhận, trong gói tin trả lời sẽ có chứa thành phần thông tin fastStart lựa chọn một cấu trúc Open LogicalChanel trong số các cấu trúc mà bên gọi đề nghị. Qua đó, kênh thông tin được thiết lập giống như thủ tục đóng mở kênh logic của kênh H245. Phía bị gọi có thể bắt đầu truyền thông tin (media) ngay sau khi nhận được gói tin báo hiệu từ phía chủ gọi có chứa thành phần thông tin fastStart. Do đó phía chủ gọi phải chuẩn bị sẵn sàng để nhận bất cứ một kênh thông tin nào mà nó đã đưa ra trong bản tin Setup. Khi nhận được bản tin trả lời có chứa thành phần thông tin fastStart , phía chủ gọi có thể ngừng chuẩn bị nhận thông tin trên Các kênh không được chấp nhận. Phía chủ gọi có thể yêu cầu phía bị gọi chưa gửi thông tin trước khi trả lời bằng bản tin Connect. Nếu như trong bản tin Setup, thành phần thông tin mediaWaitForConnect được thiết lập là TRUE thì phía bị goi không được phép gửi dòng thông tin media cho đến khi đã gửi đi bản tin Connect. Phía chủ gọi có thể bắt đầu truyền thông tin media ngay khi nhận được bản tin trả lời có thành phần thông tin fastStart.Vì vậy, bên bị gọi phải sẵn sàng nhận thông tin media trên kênh mà nó đã chấp nhận. Chuyển sang kênh H.245 Sau khi thiết lập cuộc gọi sử dụng thủ tục kết nối nhanh, một trong hai bên có nhu cầu sử dụng các thủ tục chỉ có ở kênh H.245. Một trong hai bên có thể khởi động thủ tục thiết lập kênh H.245 trong bất kì thời điểm nào của cuộc gọi, sử dụng phương thức mã hoá gói tin H.245 trong gói tin H.225 hoặc sử dụng kết nối kênh H245 riêng. Khi sử dụng thủ tục kết nối nhanh, kênh báo hiệu phải được mở cho đến khi cuộc gọi kết thúc hoặc kênh H.245 được thiết lập. Khi sử dụng kênh H.245 riêng, tất cả các thủ tục bắt buộc của H.245 phải được thực hiện trước khi khởi động các thủ tục khác. Kênh thông tin đã được thiết lập trong thủ tục kết nối nhanh sẽ được thừa kế và được xem như chúng đã được mở bởi thủ tục mở kênh thông tin của H.245. Giải phóng cuộc gọi Nếu kênh thông tin được thiết lập bằng thủ tục kết nối nhanh và không chuyển sang kênh H245, cuộc gọi được giải phóng khi một trong hai bên gửi đi gói tin báo hiệu ReleaseComplete. 3.3.2.2.2 Thiết lập kênh điều khiển Sau khi trao đổi các bản tin thiết lập cuộc gọi, các điểm cuối sẽ thiết lập kênh điều khiển H.245 với địa chỉ được xác định trong bước 1. Kênh điều khiển này có thể do phía bị gọi thiết lập sau khi nó nhận được bản tin Setup hoặc do phía chủ gọi thiết lập khi nó nhận được bản tin Alerting hoặc Call Proceeding. Trong trường hợp không nhận được bản tin Connect hoặc một điểm cuối gửi Release Complete, thì kênh điều khiển H.245 sẽ bị đóng. Đầu tiên các điểm cuối trao đổi các bản tin để trao đổi khả năng thu phát luồng thông tin media. Sau đó chúng sẽ thực hiện thủ tục để xác định chủ - tớ (master - slave). Trong trường hợp cả hai điểm cuối đều có khả năng của MC, thủ tục này sẽ xác định điểm cuối nào là active MC (active MC sẽ là chủ trong cuộc gọi hội nghị). Sau khi thực hiện xong các thủ tục này, cuộc gọi chuyển sang bước thứ 3 để thiết lập kênh thông tin. Mã hoá bản tin H.245 trong bản tin báo hiệu H.225.0 Với mục đích duy trì tài nguyên, đồng bộ hoá giữa báo hiệu và điều khiển cuộc gọi, giảm thời gian thiết lập cuộc gọi, các bản tin H.245 sẽ được mã hoá trong bản tin báo hiệu H.225 truyền trên kênh báo hiệu thay vì thiết lập một kênh điều khiển H.245 riêng. Điểm cuối muốn sử dụng phương thức này sẽ thiết lập thành phần thông tin h245Tunneling lên giá trị TRUE trong bản tin Setup và các bản tin báo hiệu sau đó trong thời gian phương thức này vẫn được sử dụng. Nếu chấp nhận phương thức này, bên nhận sẽ thiết lập thành phần thông tin h245Tunneling lên giá trị TRUE trong bản tin trả lời cho bản tin Setup và trong các bản tin tiếp theo trong thời gian phương thức này vẫn được sử dụng. Một hoặc nhiều bản tin H.245 có thể được mã hoá trong một bản tin H.225.0. Trong thời gian không cần truyền bản tin báo hiệu nào mà cần phải gửi bản tin điều khiển H.245 thì bản tin H.245 sẽ đươc gửi đi trong bản tin báo hiệu Facility trên kênh báo hiệu. Nếu trong bản tin Setup có mã hoá bán tin H.245 nhưng phía bị gọi lại không chấp nhận thì phía chủ gọi phải coi như phía bị gọi đã bỏ qua thành phần thông tin này. Phía chủ gọi không được phép sử dụng thành phần thông tin fastStart và gói tin H.245 được mã hoá trong cùng bản tin Setup, bởi vì như vậy thì thủ tục kết nối nhanh sẽ bị bỏ qua. Mặc dù vậy, cả hai bên vẫn có thể gửi thành phần thông tin fastStart và thiết lập giá trị h245Tunneling bằng TRUE trong cùng bản tin Setup. Trong trường hợp này, thủ tục kết nối nhanh sẽ được thực hiện và kết nối H.245 vẫn chưa được thiết lập. Khi khởi động thiết lập kênh H.245 hoặc các bản tin H.245 được mã hoá trong gói tin H.225.0 được truyền đi thì thủ tục kết nối nhanh được kết thúc. Khi sử dụng phương thức này, kênh báo hiệu phải được duy trì cho đến khi cuộc gọi kết thúc hoặc kênh H.245 được thiết lập. Chuyển sang kết nối H245 riêng Khi phương thức mã hoá bản tin H.245 trong bản tin báo hiệu hoặc thủ tục kết nối nhanh được sử dụng, một trong hai điểm cuối có thể khởi động chuyển sang sử dụng một kênh H.245 riêng. Để có thể chuyển sang kênh H.245 tại một thời điểm bất kì, các bản tin báo hiệu phải luôn chứa địa chỉ của kênh H.245. Nếu một điểm cuối muối chuyển sang sử dụng kênh H.245 riêng mà chưa nhận được địa chỉ của kênh H.245 trong bản tin báo hiệu thì nó sẽ gửi đi một bản tin FACILITY kèm theo địa chỉ của nó, đồng thời yêu cầu bên kia gửi trả lại địa chỉ của kênh H.245. Sau khi đã có địa chỉ chúng sẽ mở kết nối TCP để thiết lập kênh điều khiển. Bên khởi tạo kênh điều khiển không được phép gửi thêm bất cứ bản tin báo hiệu nào có chứa bản tin H.245, đồng thời các bản tin H.245 cũng chưa được phép truyền cho đến khi kết nối TCP được xác nhận. Bên xác nhận kết nối TCP sau khi đã xác nhận không được phép gửi thêm các bản tin báo hiệu có mã hoá bản tin điều khiển nữa. Bởi vì có thể trong thời gian khởi tạo kênh H.245, các bản tin báo hiệu có mã hoá bản tin H245 vẫn có thể được truyền đi, nên các điểm cuối phải có khả năng xử lí các bản tin này cho đến khi nhận được bản tin báo hiệu có thành phần thông tin h245Tunneling là FALSE. Trả lời cho các bản tin này sẽ được truyền trên kênh điều khiển đã được thiết lập. Sau khi kênh H.245 được thiết lập thì không thể quay trở lại sử dụng phương thức mã hoá bản tin H.245 trong bản tin báo hiệu nữa. 3.3.2.2.3 Thiết lập kênh truyền thông thoại Sau khi trao đổi khả năng (tốc độ nhận tối đa, phương thức mã hoá..) và xác định master-slave trong giao tiếp trong giai đoạn 2, thủ tục điều khiển kênh H.245 sẽ thực hiện việc mở kênh logic để truyền thông tin. Sau khi mở kênh logic để truyền tín hiệu là âm thanh và hình ảnh thì mỗi điểm cuối truyền tín hiệu sẽ truyền đi một bản tin h2250MaximumSkewIndication để xác định thông số truyền. Thay đổi chế độ hoạt động Trong giai đoạn này các điểm cuối có thể thực hiện thủ tục thay đổi cấu trúc kênh, thay đổi khả năng và chế độ truyền cũng như nhận. Trao đổi các luồng tín hiệu video Việc sử dụng chỉ thị videoIndicateReadyToActive được định nghĩa trong khuyến nghị H.245 là không bắt buộc, nhưng khi sử dụng thì thủ tục của nó như sau. Đầu tiên phía chủ gọi sẽ không được phép truyền video cho đến khi phía bị gọi chỉ thị sẵn sàng để truyền video. Phía chủ gọi sẽ truyền bản tin videoIndicateReadyToActive sau khi kết thúc quá trình trao đổi khả năng, nhưng nó sẽ không truyuền tín hiệu video cho đến khi nhận được bản tin videoIndicateReadyToActive hoặc nhận được luồng tín hiệu video đến từ phía phía bị gọi. Phân phối các địa chỉ luồng dữ liệu Trong chế độ một địa chỉ, một điểm cuối sẽ mở một kênh logic tới MCU hoặc một điểm cuối khác. Địa chỉ của các kênh chứa trong bản tin openLogicalChannel và openLogicalChannelAck. Trong chế độ địa chỉ nhóm, địa chỉ nhóm sẽ được xác định bởi MC và được truyền tới các điểm cuối trong bản tin communicationModeCommand. Một điểm cuối sẽ báo cho MC việc mở một kênh logic với địa chỉ nhóm thông qua bản tin openLogicalChannel và MC sẽ truyền bản tin đó tới tất cả các điểm cuối trong nhóm. 3.3.2.2.4 Dịch vụ Lúc này, cuộc gọi đã được thiết lập, hai bên có thể trao đổi thông tin media. Các dịch vụ giám sát chất lượng hoạt động, thay đổi độ rộng băng tần, các dịch vụ bổ trợ khác cũng được tiến hành. Thay đổi độ rộng băng tần Độ rộng băng tần của một cuộc gọi được gatekeeper thiết lập trong khoảng thời gian thiết lập trao đổi. Một điểm cuối phải chắc chắn rằng tổng tất cả luồng truyền, nhận âm thanh và hình ảnh đều phải nằm trong độ rộng băng tần đã thiết lập. Tại mọi thời điểm trong khi hội thoại, điểm cuối hoặc gatekeeper đều có thể yêu cầu tăng hoặc giảm độ rộng băng tần. Một điểm cuối có thể thay đổi tốc độ truyền trên một kênh logic mà không yêu cầu gatekeeper thay đổi độ rộng băng tần nếu như tổng tốc độ truyền và nhận không vượt quá độ rộng băng tần hiện tại. Trong trường hợp ngược lại thì điểm cuối phải yêu cầu gatekeeper mà nó đăng ký thay đổi độ rộng băng tần. Giám sát trạng thái Để giám sát trạng thái hoạt động của điểm cuối, gatekeeper liên tục trao đổi cặp bản tin IRQ/IRR với các điểm cuối do nó kiểm soát. Khoảng thời gian đều đặn giữa các lần trao đổi các bản tin có thể lớn hơn 10 giây và giá trị của nó do nhà sản xuất quyết định. Gatekeeper có thể yêu cầu một điểm cuối gửi cho nó bản tin IRR một cách đều đặn nhờ giá trị của trường irrFrequency trong bản tin ACF gửi cho điểm cuối đó để xác định tốc độ truyền bản tin IRR. Khi xác định được giá trị của trường irrFrequency, điểm cuối sẽ gửi bản tin IRR với tốc độ đó trong suốt khoảng thời gian của cuộc gọi. Trong khi đó gatekeeper có thể vẫn gửi IRQ tới điểm cuối và yêu cầu trả lời theo cơ chế như đã trình bày ở trên. Trong khoảng thời gian diễn ra cuộc gọi, một điểm cuối hoặc gatekeeper có thể đều đặn hỏi trạng thái từ điểm cuối bên kia bằng cách sử dụng bản tin Status Enquiry. Điểm cuối nhận được bản tin Status Enquiry sẽ trả lời bằng bản tin chỉ thị trạng thái hiện thời. Thủ tục hỏi đáp này có thể được gatekeeper sử dụng để kiểm tra một cách đều đặn xem cuộc gọi có còn đang hoạt động không. Có một lưu ý là các bản tin này là bản tin H.225.0 được truyền trên kênh báo hiệu cuộc gọi không ảnh hưởng đến các bản tin IRR được truyền trên kênh RAS. 3.3.2.2.5 Kết thúc cuộc gọi Một điểm cuối có thể kết thúc cuộc gọi theo các bước của thủ tục sau: Dừng truyền luồng tín hiệu video khi kết thúc truyền một ảnh, sau đó đóng tất cả các kênh logic phục vụ truyền video. Dừng truyền dữ liệu và đóng tất cả các kênh logic dùng để truyền dữ liệu. Dừng truyền audio sau đó đóng tất cả các kênh logic dùng để truyền audio. Truyền bản tin H.245 endSessionCommand trên kênh điều khiển H.245 để báo cho thuê bao đầu kia biết nó muốn kết thúc cuộc gọi. Sau đó nó dừng truyền các bản tin H.245 và đóng kênh điều khiển H.245. Nó sẽ chờ nhận bản tin endSessionCommand từ bên kia và sẽ đóng kênh điều khiển H.245. Nếu kênh báo hiệu cuộc gọi đang mở, thì nó sẽ truyền đi bản tin Release Complete sau đó đóng kênh báo hiệu. Chú ý: Kết thúc một cuộc gọi không có nghĩa là kết thúc một hội nghị (cuộc gọi có nhiều điểm cuối tham gia), một hội nghị sẽ chắc chắn kết thúc khi sử dụng bản tin H.245 dropConference. Khi đó các điểm cuối sẽ chờ MC kết thúc cuộc gọi theo thủ tục trên. Trong một cuộc gọi không có sự tham gia của gatekeeper thì chỉ cần thực hiện các bước từ 1 đến 5. Hình 3.22: Điểm kết thúc cuộc gọi có sự tham của gatekeeper Nhưng trong cuộc gọi có sự tham gia của gatekeeper thì cần có hoạt động giải phóng băng tần, thủ tục này được thể hiện trên hình 3.22. Vì vậy sau khi thực hiện các bước từ 1 đến 5, mỗi điểm cuối sẽ truyền đi bản tin DRQ (3) tới gatekeeper để yêu cầu giải phóng khỏi gatekeeper. Sau đó gatekeeper sẽ trả lời bằng bản tin DCF (4). Sau khi gửi DRQ, thì điểm cuối sẽ không gửi bản tin IRR tới gatekeeper nữa và khi đó cuộc gọi kết thúc. Trên đây là thủ tục kết thúc cuộc gọi có sự tham gia của gatekeeper do điểm cuối thực hiện. Thủ tục kết thúc cuộc gọi do gatekeeper thực hiện được thể hiện trên hình 3.23. Đầu tiên gatekeeper gửi bản tin DRQ tới điểm cuối, khi nhận được bản tin này điểm cuối sẽ lần lượt thực hiện các bước từ 1 đến 6 sau đó trả lời gatekeeper bằng bản tin DCF. Thuê bao đầu kia khi nhận được bản tin endSessionCommand sẽ thực hiện thủ tục giải phóng giống trường hợp điểm cuối chủ động kết thúc cuộc gọi (hình 3.23). Nếu cuộc gọi là một hội nghị thì gatekeeper sẽ gửi DRQ tới tất cả các điểm cuối tham gia hội nghị Cuộc gọi có sự tham gia của đầu cuối trong mạng SCN (Switched Circuit Network). Đối với cuộc gọi có sự tham gia của mạng SCN có thể xảy ra các trường hợp sau: Hình 3.23: Kết thúc cuộc gọi bắt đầu từ gatekeeper Cuộc gọi từ đầu cuối H323 đến đầu cuối SCN. Cuộc gọi từ đầu cuối SCN đến đầu cuối H323. Cuộc gọi giữa hai đầu cuối SCN qua mạng IP (H323). Khi có sự tham gia của đầu cuối trong mạng SCN thì bắt buộc phải có gateway chuyển đổi giao thức giữa mạng SCN và mạng H323. Báo hiệu giữa gateway với đầu cuối hoặc một gateway khác tuân theo khuyến nghị H323 của ITU. Tuy nhiên không phải tất cả các thủ tục, bản tin của H323 đều được áp dụng cho VoIP, tiêu chuẩn kỹ thuật TS 101 322 và TS 101 471 của ESTI sẽ giới hạn các thủ tục của H323 áp dụng trong VoIP. Báo hiệu giữa đầu cuối SCN và gateway tuân theo giao thức của mạng SCN (có thể là báo hiệu R2, báo hiệu số 7..) CHƯƠNG 4: GIAO THỨC SIP 4.1 Giới thiệu SIP Giao thức khởi đầu phiên (Session Initiation Protocol) là giao thức báo hiệu được dùng để thiết lập, duy trì và kết thúc các cuộc gọi. Nó được đưa ra bởi IETF. Một cuộc gọi bao gồm một số thành viên tham gia hội thoại, trao đổi thông tin bằng hình thức đa phát đáp hoặc đơn phát đáp với phương thức truyền thông có thể là dữ liệu, tiếng nói hay hình ảnh. SIP là một giao thức điều khiển tầng ứng dụng, độc lập với với các giao thức khác. Đây là giao thức khả mở, hỗ trợ các dịch vụ ánh xạ tên và các dịch vụ gián tiếp một cách trong suốt. Vì thế nó cho phép thi hành một cách đầy đủ các dịch vụ trên ISDN, mạng thoại thông minh và hỗ trợ các cuộc gọi di động của người có địa chỉ không cố định. SIP cung cấp các khả năng sau: Định vị người dùng: cho phép xác định vị trí người dùng tiến hành hội thoại. Xác định phương thức giao tiếp và các tham số tương ứng cho hội thoại. Xác định những người sẵn sàng tham gia hội thoại. Thiết lập các tham số cần thiết cho cuộc gọi, giống như Q.931. Điều khiển cuộc gọi: bao gồm cả quá trình truyền và kết thúc cuộc gọi. SIP là một phần trong bộ giao thức chuẩn cho truyền dòng tin đa phương thức do IETF đưa ra như RSVP (giao thức giữ trước tài nguyên), RTP, RTSP (phân phối dòng tin đa phương thức), SAP (giao thức thông báo phiên), SDP (giao thức mô tả phiên), nhưng nó hoạt động độc lập với các giao thức trên. Ta cũng có thể kết hợp SIP với các giao thức báo hiệu và thiết lập cuộc gọi khác. Hiện tại ngoài SIP được phát triển bởi IETF còn có H.323 phát triển bởi ITU mang đầy đủ dáng vẻ của một giao thức báo hiệu. Cả SIP và H.323 đều định nghĩa các cơ chế chọn đường, báo hiệu cuộc gọi cũng như khả năng chuyển đổi, điều khiển và các dịch vụ bổ sung. SIP là giao thức mới hứa hẹn tính khả mở, linh hoạt và dễ dàng. Sự linh hoạt của SIP cho phép máy phục vụ liên kết với các máy phục vụ khác bên ngoài để xác định người sử dụng hay chính sách chọn đường, vì thế nó không trói buộc chỉ những người trong cùng một vùng. Thêm vào đó, để duy trì tính khả mở, các máy phục vụ SIP có thể duy trì các thông tin trạng thái hoặc chuyển tiếp yêu cầu. 4.2 Kiến trúc SIP Các thành phần chính trong một hệ thống SIP được mô tả bởi hình 4.1. Hình 4.1: Kiến trúc SIP Chức năng tóm tắt của từng thành phần được thể hiện ở bảng sau: Bảng 4.1: Chức năng các thành phần của kiến trúc SIP Thành phần Chức năng UAC (User Agent Client) Người dùng tại các đầu cuối SIP, đưa yêu cầu SIP. UAS (User Agent Server) Nhận và đáp ứng yêu cầu SIP, chấp nhận, chuyển tiếp, hay từ chối cuộc gọi. SIP terminal Hỗ trợ truyền thông hai chiều thời gian thực với các thực thể SIP khác. Cũng giống như H.323 Terminal, chứa UAC. PS (Proxy Server) Liên lạc một hay nhiều client hay server kề với nó, chuyển yêu cầu cuộc gọi đi xa hơn. Chứa UAC và UAS . RS (Redirect Server) Trả về địa chỉ người dùng khi được yêu cầu. LS (Location Server) Cung cấp thông tin về địa chỉ có thể có của người gọi cho Redirect và Proxy Server. Nó có thể nằm chung với SIP Server. SIP là một giao thức Client-Server có nghĩa là các yêu cầu tạo ra từ một thực thể gửi (như Client) và gửi đến một thực thể nhận (như Server) để xử lý chúng. SIP cho phép hệ thống đầu cuối bao gồm giao thức Client và Server (gọi chung là Server đại diện người sử dụng). Các Server đại diện người sử dụng nói chung trả lời các yêu cầu trên cơ sở trao đổi của con người hoặc một vài kiểu đầu vào khác. Hơn nữa SIP yêu cầu có thể duyệt qua nhiều Proxy Server, mỗi trong chúng nhận một yêu cầu và gửi nó theo bước nhảy đến Server tiếp theo, nó có thể là một Proxy Server khác hoặc Server đại diện người sử dụng cuối cùng. Một Server có thể đóng vai trò Server trung gian (Redirect Server), hoặc Client có thể liên lạc với nó trực tiếp. Chưa có giao thức phân biệt giữa Proxy Server và Redirect Server và Server đại diện người sử dụng; một Client hoặc Proxy Server không có cách nào để biết ai mà chúng đang truyền thông với. Sự phân biệt chỉ ở chức năng: một Proxy Server hoặc Redirect Server không được nhận hoặc không nhận một yêu cầu, nơi mà Server đại diện người sử dụng là có thể. Điều này giống với mô hình giao thức trao đổi siêu văn bản HTTP (Hypertext Transfer Protocol) của các Client, các Server gốc và Proxy Server. Một máy chủ có thể đóng vai trò cho Client và Server cho các yêu cầu giống nhau. Một kết nối được xây dựng bằng cách đưa ra một yêu cầu INVITE và loại bỏ bởi đưa ra một yêu cầu BYE. 4.3 Các bản tin SIP SIP là giao thức dạng text sử dụng bộ ký tự ISO 10646 trong mã hóa UTF-8. Điều này tạo cho SIP tính linh hoạt và mở rộng, dễ dàng thi hành các ngôn ngữ lập trình cấp cao như Java, Tcl, Perl. Cú pháp của nó gần giống với giao thức HTTP, 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. Thông điệp SIP được chia làm hai loại: SIP-message = Request | Response 4.3.1 Yêu cầu (Request) Một tiêu đề yêu cầu SIP có cấu trúc : Method Request URI SIP version Trong đó, SIP định nghĩa 6 yêu cầu cơ bản: Bảng 4.2: Các yêu cầu SIP Mã trạng thái Ý nghĩa INVITE Mời thành viên tham gia hội thoại. ACK Yêu cầu xác nhận đã nhận được đáp ứng chấp nhận (OK) cho yêu cầu INVITE. OPTIONS Hỏi khả năng của máy phục vụ SIP. BYE Yêu cầu giải phóng cuộc gọi. CANCEL Hủy bỏ yêu cầu sắp được thực hiện với cùng giá trị trong các trường Call-ID, To, From, CSeq của yêu cầu đó bằng cách ngừng quá trình tìm kiếm, báo hiệu. REGISTER Đăng ký danh sách địa chỉ liên hệ của người dùng với máy phục vụ. Trường Request-URI có khuôn dạng theo SIP URL và có thể được ghi lại trong trường hợp máy phục vụ ủy quyền, trường SIP Version chỉ phiên bản SIP được sử dụng (hiện tại là bản SIP/2.0). 4.3.2 Đáp ứng (Response) Đáp ứng bản tin SIP dựa trên sự chấp nhận và dịch các yêu cầu. Chúng dùng để chỉ thị cuộc gọi thành công hay thất bại, bao gồm cả trạng thái của server. Các đáp ứng SIP có tiêu đề theo khuôn dạng sau: SIP version Status code Reason phrase Phiên bản SIP/2.0 đưa ra bảng mã mở rộng và chức năng tương ứng cho các đáp ứng được mô tả dưới đây: Bảng 4.3: Các đáp ứng SIP Mã trạng thái Ý nghĩa 1xx Tìm kiếm , báo hiệu, sắp hàng đợi. 2xx Thành công. 3xx Chuyển tiếp yêu cầu. 4xx Lỗi phía người dùng 5xx Lỗi phía máy phục vụ 6xx Lỗi chung: đường đây đang bận, từ chối,… Ngoài ra, thành phần tùy chọn Reason phrase chú thích mã trả về tương ứng là đáp ứng gì. SIP định nghĩa 6 loại đáp ứng đối với các thông điệp mà chúng ta thấy trong phần trước. Mỗi loại đáp ứng dùng một mã trong một dải, như được liệt kê trong bảng mã đáp ứng (bảng 4.4 đến 4.9). Vài mã trả về yêu cầu sự phản ứng rõ ràng từ các server và endpoint, và vài mã khác dẫn đến một động thái nào đó của hệ thống. Các đáp ứng nhất thời được phát ra để cho biết mơi thu đang tiến hành thực thi yêu cầu. Các mã hợp lệ được liệt kê trong bảng 4.4. Bảng 4.4 Các mã thông báo của SIP Mã Ý nghĩa 100 Trying. Một đáp ứng tạm thời tương tự như Q.931 CALL PROCEEDING, và sẽ được trả về từ một proxy server hay SIP server trung gian khác trên đường báo hiệu của một cuộc gọi. 180 Ringing. Có ý nghĩa tương tự như Q.931 ALERTING. Có nghĩa là máy điện thoại đang rung chuông. 181 Call Forwarding. Nếu một proxy server trả về mã này, có thể nhận diện nơi mà nó đang chuyển cuộc gọi trong thân của thông điệp này. 182 Queued for Service. Hữu ích cho các ứng dụng có thể trì hoãn trả lời cuộc gọi cho đến khi chúng đã phục vụ cho các cuộc gọi đang xếp hàng. Các văn phòng phục vụ cho các tập đoàn lớn là các user chủ yếu của các dịch vụ này. 183 Session Progress. Một đáp ứng tạm thời tương tự như Q.931 CALL PROGRESS. Mã này được dùng để cung cấp sớm thông tin đặc tả phiên truyền thông từ các gateway trên đường dẫn đến nơi được gọi, như vậy một đường dẫn thoại có thể được chuyển mạch trước khi đổ chuông được áp đặt lên endpoint gọi. Ví dụ trường hợp sử dụng chúng là trong liên kết công tác SIP – PSTN, nhờ đó một mã Session Progress với SDP của PSTN gateway cho phép âm hiệu chuông được cấp bởi tổng đài kết nối. Các ứng dụng khác của đáp ứng này gồm thông báo hay mở nhạc khi gọi vào trong một domain, trước khi cuộc gọi được thiết lập. 189 Provisional response to a REFER method. Hữu ích trong việc cung cấp thông tin cề trạng thái của cuộc gọi đang được chuyển, trong khi đang đợi đáp ứng sau cùng chỉ thành công hay thất bại từ chi gọi đang được chuyển đến. Mã Success (2xx) chỉ ra yêu cầu đã được phân tích thành công và được thực thi bởi đối tác được gọi. Xem bảng 4.5 Mã Redirection (3xx) cho biết cuộc gọi cần xử lý nhiều hơn trước khi có thể xác định nó được hoàn tất hay không. Xem bảng 4.6 Bảng 4.5: Mã thông báo thành công của SIP Mã Ý nghĩa 200 Yêu cầu được thực thi một cách thành công. Bảng 4.6: Các mã định hướng lại của SIP Mã Ý nghĩa 300 Mục tiêu trong yêu cầu được phân giải thành nhiều chọn lựa. Nhiều chọn lựa được trả về và người gọi có thể lấy từ trong danh sách và định hướng lại cuộc gọi. Đây là một phương pháp khác của cái gọi là “ambiguous”, nheng sự phân giải tên mập mờ đưa đến mã lỗi của nó. 301 User được gọi đã di chuyển thường xuyên và nơi gọi sẽ thử vị trí mới, nó được trả về trong header của đáp ứng (trong “contact” field). Có thể có một danh sách các vị trí, và người gọi có thể chọn thứ tự mà nó sẽ quét qua danh sách để tạo cuộc gọi. Nếu server không tìm thấy bất kỳ thông tin nào về đối tác được gọi trong bộ nhớ của nó, nó trả lại một mã lỗi NOT FOUND. 302 User được gọi vừa di chuyển và có thể tìm thấy tại địa chỉ trả về. Điều này hữu dụng cho chuyển cuộc gọi bằng tay, bởi bản thân server không chuyển cuộc gọi (chỉ cung ứng sự định hướng lại). Tốt cho việc giải quyết vài nhu cầu di chuyển nào đó. 305 Không thể truy xuất User được gọi một cách trực tiếp, nhưng cuộc gọi phải được kiểm soát thông qua một proxy. Chỉ có agent gọi mới có thể truyền phúc đáp này. 380 Dịch vụ được yêu cầu không khả dụng, nhưng các dịch vụ khác là có thể. Đây là một thông điệp không chắc chắn. Sự không phù hợp về tham số SDP được khắc phục bằng mã khác. Mã về yêu cầu của client không thành (4xx), loại mã này cho biết server không thể phân tích yêu cầu và không thể phục vụ. Yêu cầu này phải được sửa đổi trước khi tiến hành trở lại. Xem bảng 4.7 Bảng 4.7: Các mã chỉ yêu cầu không thành công của SIP Mã Ý nghĩa 400 Yêu cầu hỏng, do lỗi về cú pháp. Điều này có nghĩa là thông điệp dạng text không thể phân tích được bởi đầu xa. Bất kỳ lỗi cú pháp nào đều trả về mã này. Thái độ của hệ thống là thực thi rõ. 401 User yêu cầu xác thực trước khi thực hiện yêu cầu này. Các qui định đặc biệt được áp dụng vào định dạng thông điệp khi nhận được mã lỗi này. Ví dụ: không có dạng thông điệp chắc chắn SIP nào được phép. 402 User còn nợ tiền (sử dụng trong tương lai). Hữu dụng cho các công ty điện thoại. Các hoạt động không được chỉ rõ, nhưng một hoạt động có thể đoán được. 403 Cấm yêu cầu – không thực hiện lại. Thông điệp được phân tích, nhưng yêu cầu sẽ không được đón nhận. Nếu cố gắng gọi một số không được chấp nhận từ thuê bao của bạn, bạn có thể nhận được thông điệp này. 404 Không tìm thấy user. Thông điệp này được gửi khi user không hề tồn tại hay các record của user đã bị xóa bởi server này. 405 Phương thức được mã hóa trong thông điệp này không được phép cho user được gọi. Lý tưởng là cho phép tất cả các phương thức, nhưng đây là một quyết định thực hiện. 406 Endpoint được gọi sẽ phát ra các đáp ứng mà người gọi sẽ không hiểu được (mã không thể chấp nhận). Đáp ứng này tránh gia tăng hội chứng “Tower of Babel” giữa các endpoint nếu xử lý gọi liên tục. 407 Xác thực proxy trước khi xúc tiến. 408 Server không tạo ra đáp ứng trong khoảng thời gian được yêu cầu bởi chủ gọi trong header yêu cầu. Các server bận không thể phát ra đáp ứng này theo thời gian. Phản ứng của người gọi là thực hiện phụ thuộc. 409 Có một xung đột giữa yêu cầu hiện hành với các điều kiện khác trong server, có khả năng do các đăng ký hiện hữu. Đáp ứng này được tạo ra nếu một yêu cầu REGISTER từ một user đụng độ với các yêu cầu khác. 410 User được yêu cầu hay dịch vụ đã bị di chuyển khỏi server này và không có để lại địa chỉ nào. 411 Server yêu cầu người gọi ghi chiều dài toàn bộ thông điệp trong header. Thông điệp có tính xoi mói này, nhưng nó phải được lý giải bởi ứng dụng. 413 Kích thước yêu cầu là quá lớn server không thể kiểm soát. Không thể nào dự báo được những loại thông điệp SIP nào có thể gây ra đáp ứng này, ngoại trừ một hỏng hóc bởi quá trình sẽ tạo ra các thông điệp này trong agent gọi. 414 Server đang gặp khó khăn trong việc diễn dịch Request URI bởi kích thước của nó quá lớn. Khống chế URI ngắn hơn. Không có cách nào để ngăn chặn lỗi này. 415 Server không thể chấp nhận yêu cầu bởi mã hóa của nó. Server có thể chỉ ra phương pháp thích hợp hơn để mã hóa yêu cầu. 420 Server không hiểu sự mở rộng của giao thức SIP đang cố truy cập server từ người gọi. Làm thích nghi hơn là giải pháp thỏa đáng nhất cho vấn đề ở đây, nhưng có thể giảm xác suất dẫn đến tình huống nàybawfng cách dùng các header “Allow” và “Support”. 480 Nơi được gọi tạm thời không khả dụng. Nếu server nhận biết được tên nhưng không biết đối tác hiện đang ở đâu, nó có thể truyền thông điệp này. 481 Server nhận một CANCEL trong một yêu cầu không tồn tại hay một BYE cho một cuộc gọi không có thực. Loại bỏ. 482 Đã phát hiện thấy vòng lặp trong định tuyến thông điệp. Đây là trường hợp mà Via rất hữu dụng trong việc phát hiện ra các vòng lặp do sai sót của các giao thức vận chuyển và mạng. Nếu một server tự phát hiện trong Via field một thông điệp đến của cuộc gọi chưa hoàn tất cho đến thời điểm này, là một chứng cứ tốt để đoán rằng có một vòng lặp đâu đó trong mạng. Là thời điểm ngừng các phân tích. 483 Số hop cần thiết để đạt đến đối tác bị gọi vượt quá giới hạn cho phép. Điều này là một sự bảo vệ hiệu quả chống lại các tuyến quá dài và không ổn định, đặc biệt là trong mạng công cộng mới dựa vào IP. 484 Địa chỉ chưa đầy đủ. Có thể được dùng để tiến hành truyền từng phần một, như trường hợp của chuỗi quay số từ máy điện thoại, được softswitch xem như chưa đầy đủ. 485 Địa chỉ mập mờ về đối tác được gọi. Server có thể đề nghị các thay đổi với người gọi. Trường hợp này có nhiều chọn lựa được gửi về cho người gọi. 486 Đối tác được gọi đang bận hoặc không sẵn sàng nhận cuộc gọi. Có thể phúc đáp vào một thời điểm tốt hơn sau đó (phụ thuộc vào sự hiện thực). Mã lỗi của server (5xx) cho biết yêu cầu có thể hợp lệ, nhưng server không thể thực thi chúng. Xem bảng 4.8 Bảng 4.8: Các mã lỗi server của SIP Mã Ý nghĩa 500 Lỗi server, có thể là lỗi phần cứng, phần mềm hay bất kỳ một lỗi nào bên trong. 501 Server không thể phục vụ yêu cầu bởi dịch vụ không được thực hiện. 502 Server nhận đáp ứng hỏng từ gateway hay server khác trên đường dẫn cuộc gọi. Đây có thể là một lỗi tiêu biểu trong các cuộc gọi trải dài qua nhiều segment và server mạng. 503 Dịch vụ tạm thời không khả dụng, có lẽ do quá tải xử lý hay cạn kiệt tài nguyên. 504 Server bị timeout khi truy cập gateway trên đường dẫn cuộc gọi đến endpoint. Cuộc gọi yêu cầu có lẽ vẫn còn lang thang đâu đó. 505 Phiên bản giao thức SIP này không được hỗ trợ. Thiết kế phù hợp hơn có thể tránh được lỗi này. Các server cũ hơn và các agent gọi có thể làm như vậy khi chúng nhận thấy một phiên bản mới hơn của SIP trong header của thông điệp. 506 Lỗi về điều kiện định trước (được dùng với COMET). Các mã lỗi toàn cục (6xx) cho biết server không thể nào phục vụ được yêu cầu của user. Xem bảng 4.9 Bảng 4.9: Các mã lỗi toàn cục của SIP Mã Ý nghĩa 600 Đối tác được gọi đang bận. Có thể chỉ ra một thời điểm tốt hơn để gọi lại. 603 Người được gọi khước từ cuộc gọi. 604 User được gọi không tồn tại trong bất cứ nơi đâu. 606 User sẵn sàng chấp nhận cuộc gọi, nhưng có những điều không phù hợp nào đó trong truyền thông được yêu cầu hay ở đâu đó, và do đó user không thể chấp nhận cuộc gọi. Ví dụ: nếu chỉ có một chọn lựa cấp cho agent được gọi là nén tiếng nói G.728, và đối tác được gọi lại chỉ hỗ trợ G.711, rất dễ đoán ra nguyên nhân nhận được thông điệp này. Đối tác được gọi có thể quyết định một cách đơn giản là không chấp nhận cuộc gọi. 4.4 Hoạt động của SIP 4.4.1 Quá trình định vị tới máy phục vụ SIP Khi một người (UAC) muốn gửi yêu cầu kết nối tới một người khác thì yêu cầu được gửi tới PS hoặc gửi địa chỉ và cổng cho trường Request-URI với cổng mặc định là 5060 và giao thức vận chuyển là UDP và sau đó là TCP. Quá trình tìm kiếm địa chỉ máy phục vụ SIP diễn ra như sau: UAC gửi yêu cầu tới máy phục vụ tương ứng, máy phục vụ lấy thông tin trong trường Request-URI để lấy được địa chỉ cần tìm: Nếu trường host trong Request-URI là địa chỉ IP thì UAC sẽ liên lạc với máy phục vụ qua địa chỉ này, nếu không thì nhảy sang bước tiếp theo. UAC hỏi địa chỉ IP của máy phục vụ qua máy phục vụ tên miền (Domain Name System Server). DNS Server trả về một danh sách tương ứng thông tin đăng ký của người đó. Việc lựa chọn một trong các địa chỉ trong danh sách này là hoàn toàn tùy ý. 4.4.2 Giao dịch SIP Khi đã có địa chỉ IP, yêu cầu được gửi đi theo tầng vận chuyển là TCP hay UDP. Các đáp ứng cho một yêu cầu phải chứa cùng các giá trị trong trường Call-ID, From, To, CSeq. Mỗi cuộc gọi trong SIP được định đanh nhất bởi bộ định danh cuộc gọi (Call-ID). Yêu cầu được gửi từ đâu (From), đến đâu (To). Trường From và To đều theo khuôn dạng SIP URL. Trường CSeq lưu thông tin về phương thức sử dụng trong phiên đó. 4.4.3 Lời mời SIP Đây là hoạt động diễn ra thường xuyên nhất, INVITE mời thành viên tham gia hội thoại, đáp ứng chấp nhận là 200 (OK). Thông điệp này còn chứa thành phần mô tả phiên (SDP) và phương thức tiến hành trao đổi ứng với phiên đó. Trong trường hợp máy phục vụ ủy quyền như hình 4.2. Hình 4.2 Sự hoạt động của trường hợp Proxy Mode. Proxy Server (PS) tiếp nhận lời mời PS tra cứu thông tin ở dịch vụ định vị ngoài SIP PS nhận về thông tin để tạo ra địa chỉ chính xác PS tạo lại INVITE trong trường Request-URI và chuyển tiếp UAS của người được gọi cảnh báo tới anh ta PS nhận đáp ứng chấp nhận 200 OK PS trả về kết quả thành công cho người gọi Người gọi gửi thông báo xác nhận ACK Yêu cầu xác nhận được chuyển tiếp qua PS Trường hợp máy phục vụ gián tiếp (RS) như hình 4.3: Hình 4.3 Sự hoạt động của trường hợp Redirect Mode. Sự khác biệt với PS là ở chỗ, RS không chuyển tiếp yêu cầu mà nó gửi trả về cho UAC, UAC gửi lời mời trực tiếp với trường Request-URI được xây dựng lại. 4.5 Các mô hình điện thoại Internet 4.5.1 Mô hình máy tính đến máy tính Đây là trường hợp đơn giản nhất và ra đời sớm nhất trong kỹ thuật điện thoại IP. Nó chỉ dựa vào các dịch vụ truy cập Internet được cung cấp bởi nhà cung cấp dịch vụ Internet như các môi trường để định tuyến cuộc gọi. Yêu cầu duy nhất là người sử dụng ở cả hai phía phải kết nối với Internet và trong máy tính đã có trang bị sẵn phần mềm ứng dụng phù hợp để gọi điện thoại. Phần mềm sẽ số hóa tín hiệu thoại analog, nén nó vào trong từng gói và truyền các gói đến bên nhận qua mang IP, ở đầu nhận sẽ thực hiện quá trình ngược lại. Hai bên có thể thực hiện một cuộc đàm thoại theo thứ tự như sau: thực hiện kết nối vào mạng (ở đây là mạng LAN thông qua Hub). Bên gọi yêu cầu địa chỉ IP của bên được gọi. Bên gọi có thể lấy phần địa chỉ này nhờ tham khảo một server định địa chỉ trên mạng mà tại đó mỗi bên phải đăng ký trước khi tiến hành các cuộc thông thoại. Hình 4.4: Mô hình PC to PC 4.5.2 Mô hình máy tính đến điện thoại và ngược lại Trong trường hợp này, một bên sẽ đăng ký với mạng điện thoại công cộng PSTN hay mạng điện thoại di động trong khi bên còn lại kết nối với Internet thông qua các nhà cung cấp dịch vụ. Trước khi cuộc gọi được tiến hành, máy tính phải được kết nối vào mạng. Một khi đã kết nối, nó sẽ tiến hành cuộc gọi với điện thoại trong mạng PSTN thông qua địa chỉ IP đã đăng ký với máy tính (cần phải có một ánh xạ giữa số điện thoại với địa chỉ IP). Ngược lại, khi một điện thoại muốn gọi cho máy tính thì nó cần biết số điện thoại ứng với máy tính. Cuộc gọi sẽ được chuyển qua cổng đa phương tiện, nơi mà sẽ diễn ra các hoạt động thông dịch giữa các định dạng dữ liệu và các phương thức báo hiệu trong từng mạng. Hình 4.5: PC - to - phone hoặc phone - to -PC 4.5.3 Mô hình điện thoại đến điện thoại Mô hình này có thể chia làm nhiều trường hợp nhỏ tùy thuộc loại điện thoại sử dụng và môi trường truyền giữa hai bên. Trường hợp 1: Analogue Phone-to-Analogue Phone Trường hợp này khá giống với trường hợp điện thoại trong mạng PSTN, nhưng ở đây môi trường truyền phải thông qua mạng IP. Do đó, cần có sự chuyển đổi định dạng các gói dữ liệu giữa mạng PSTN và mạng IP. Tùy thuộc sự thay đổi của môi trường truyền mà sự chuyển đổi qua lại giữa các định dạng có thể diễn ra một hay nhiều lần. Trường hợp 2: IP Phone-to-Analogue Phone IP Phone được tích hợp tính năng đầy đủ để có thể thực hiện cuộc gọi như một máy tính mà không cần sự hỗ trợ của phần cứng cũng như phần mềm. Cuộc đàm thoại được thực hiện qua một nhà cung cấp dịch vụ điện thoại IP và các cổng đa phương tiện. Trường hợp 3: IP Phone-to-IP Phone Trường hợp này khá đơn giản vì chỉ cần truyền dữ liệu trên mạng IP, thông qua nhà cung cấp dịch vụ điện thoại Internet. 4.6 Mô hình một cuộc gọi SIP điển hình Hình 4.6: Call Flow của hệ thống Hình trên mô tả các quá trình diễn ra cho một cuộc gọi SIP điển hình qua 16 bước. Bước 1 – Người sử dụng ở UA 1 muốn kết nối tới người được gọi. Khi đó phần mềm UA chạy trên UA1 sẽ tạo một yêu cầu INVITE và gửi đến proxy. Địa chỉ của proxy đã được cấu hình trước trên chương trình. Bước 2 – Proxy tiếp nhận được yêu cầu của sofpthone nhờ listen trên port 20050/UDP lập tức trả lời bằng một đáp ứng 100 (TRYING) nhằm yêu cầu client chờ kết nối. Sau đó qua bước 3 Bước 3 – Proxy xem xét yêu cầu INVITE, xác định host mà ở đó người được gọi đang login vào, chuyển tiếp yêu cầu INVITE đến đó. Bước 4 – UA 2 trả lời cho proxy bằng đáp ứng 100 (TRYING). Bước 5 – UA 2 gởi đáp ứng 180 (RINGING) về cho proxy để báo rằng đang đổ chuông. Bước 6 – proxy chuyển tiếp 180(RINGING) về UA 1. Bước 7 – UA 1 nhận được 180(RINGING) lập tức tự phát âm hiệu ringback tone dạng color ring dựa vào cấu hình nhạc chuông được thiết lập sẳn. Bước 8 – Người được gọi ở UA 2 nhấc máy. UA 2 thông báo cho proxy tín hiệu nhấc máy bằng 200 (OK). Bước 9 – proxy chuyển tiếp 200(OK) cho UA 1. Bước 10 – UA 1 gửi yêu cầu ACK cho proxy nhằm confirm rằng nó đã nhận được tín hiệu 200 (OK). Bước 11 – proxy chuyển tiếp ACK tới UA 2 Bước 12 – UA 1 tạo RTP stream với UA 2 và bắt đầu truyền voice. Bước 13, 14 – Giả sử người gọi ở UA 1 gác máy trước. UA 1 tạo yêu cầu BYE và gửi đến UA 2 thông qua proxy. Bước 15, 16 – UA 2 nhận được yêu cầu BYE của UA 1, nó trả lời bằng đáp ứng 200 (OK), đồng thời kết thúc cuộc gọi. 4.7 Các lệnh thực hiện Các yêu cầu: Thực hiện các phương thức sau: INVITE Thông báo bắt đầu thiết lập phiên (hoặc dùng sửa đổi các thông số của phiên) ACK Xác nhận đã nhận được đáp ứng cuối BYE Kết thúc phiên đang gọi (thành công) CANCEL Hủy phiên đang chờ thiết lập REGISTER Đăng ký địa chỉ mà người sử dụng login vào với proxy Các mã đáp ứng: Thực hiện các mã sau: 100 Continue (Trying) 180 Ringing 200 OK 400 Bad request 403 Forbidden 408 Request time-out 600 Busy 603 Decline 604 Does not exist 4.8 Đánh giá SIP SIP là giao thức đề cử được tổ chức IETF đưa ra. Nó ra đời với mục đích đơn giản hóa cơ chế báo hiệu và điều khiển cuộc gọi cho VoIP. SIP là giao thức dạng text, các lệnh SIP có cấu trúc đơn giản để các thiết bị đầu cuối dễ dàng phân tích và sửa đổi. Ưu điểm của SIP: Tính mở rộng một cách tự nhiên của giao thức cho phép dễ dàng định nghĩa và thi hành trong tương lai. Cho phép tạo các thiết bị đầu cuối một cách đơn giản và dễ dàng mà vẫn đảm bảo chi phí thấp. Nhược điểm của SIP: SIP là giao thức rất mới, cần được tiếp tục hoàn thiện. Nó chỉ đề cập tới một phạm vi hẹp trong toàn bộ phiên truyền thông nên cần phải được kết hợp với các giao thức khác trong quá trình xây dựng một hệ thống hoàn chỉnh. Khả năng giao tiếp với mạng chuyển mạch kênh kém. CHƯƠNG 5: TRIỂN KHAI ỨNG DỤNG IVR 5.1 Cài đặt SQL Server 2000 Sau khi cài đặt xong thì Microsoft SQL Server sẽ xuất hiện trên thanh Menu Start như hình sau: Và trên thanh Taskbar: Chọn mục Service Maneger dể kích hoạt cho phép server chạy như hình dưới đây: Để tạo cơ sở dữ liệu mới ta chọn mục Enterprise Maneger, giao diện như hình sau: Di chuyển đến mục Databases, click phải chọn New Database… để tạo Database mới, nhập tên của Database mới và chọn OK. Sau khi đã tạo Database mới, ta tiếp tục tạo các bảng dữ liệu trong Database vừa mới tạo bằng cách di chuyển đến mục Tables, click phải chọn mục New Table… để tạo bảng mới. Một bảng dữ liệu về điểm thi HKI của sinh viên có thể được thiết kế như sau: Để chọn cột bắt buộc có giá trị như vùng khóa chính thì chọn cột đó và click phải chọn Set Primary Key hoặc click chọn icon có hình chiếc chìa khóa trên thanh công cụ. Trong mỗi cột ta phải chọn kiểu dữ liệu cho cột đó và thuộc tính Allow Nulls tức là cho phép để trống hoặc không. Trong mục Tables có thể tạo nhiều bảng dữ liệu, ví dụ các bảng điểm cho các học kỳ khác nhau… Sau khi đã tạo xong các Tables, di chuyển đến mục Diagrams để tạo sơ đồ mối quan hệ cho các bảng dữ liệu vừa tạo ở trên. Click phải chọn New Database Diagram…, chọn Next ở cửa sổ tiếp theo sẽ xuất hiện hình như sau: Chọn các Tables vừa tạo ở danh sách bên trái Add qua danh sách bên phải như hình dưới đây: Sau khi Add xong thì chọn Next. Trong cửa sổ tiếp theo chọn Finish để kết thúc. Bây giờ sơ đồ Diagrams sẽ giống như hình dưới đây: Để tạo mối liên kết giữa cột MSSV trong bảng SINHVIEN với cột HKIMSSV trong bảng DIEMHKI thì thực hiện bằng cách dùng chuột chọn cột MSSV trong bảng SINHVIEN kéo và thả vào vị trí của cột HKIMSSV trong bảng DIEMHKI. Sau khi thực hiện sẽ xuất hiện cửa sổ như sau: Chọn OK thì sơ đồ Diagrams bây giờ sẽ giống như hình dưới đây: Tương tự như cách trên để tạo mối liên kết giữa bảng SINHVIEN và bảng DIEMHKII. Sơ đồ Diagrams sau khi vẽ xong có dạng như sau: Sau khi thiết kế xong Tables và Diagrams, ta có thể nhập dữ liệu vào các bảng bằng cách di chuyển đến bảng cần nhập dữ liệu, click phải chọn Open Table --> Return all rows, bây giờ ta có thể nhập dữ liệu vào và sau đó lưu lại. Nếu muốn thay đổi cấu trúc bảng thì chọn Design Table thay vì chọn Open Table. Trên đây chỉ là một số hướng dẫn cơ bản để làm cơ sở dữ liệu về điểm thi của sinh viên. Để tạo các dạng cơ sở dữ liệu khác nên tham khảo thêm các tài liệu về SQL Server 2000. 5.2 Cài đặt Microsoft Netframework 2.0 Đây là gói chương trình hỗ trợ nên chỉ cần download về và cài đặt là xong. 5.3 Cài đặt Microsoft Netframework 3.0 Đây là gói chương trình hỗ trợ nên chỉ cần download về và cài đặt là xong. 5.4 Cài đặt HMP 3.0 (Host Media Processing) su 192 Phần mềm HMP 3.0 (Host Media Processing) dùng để tạo một sự kết nối giao tiếp giữa hệ thống IVR chạy trong PC với mạng IP bên ngoài thông qua card mạng NIC, thay vì sử dụng card Dialogic.Có thể download HMP 3.0 và license của nó từ trang web sau: www.dialogic.com Sau khi cài đặt xong thì HMP 3.0 sẽ xuất hiện trên thanh Menu Start như sau: Chọn mục HMP License Maneger để chọn license mà đã lưu trên máy và kích hoạt để cho nó hoạt động, sau khi kích hoạt license xong sẽ có giao diện như sau: Chọn mục Configuration Maneger (DCM) để cấu hình HMP, tuy nhiên HMP đã cấu hình mặc định nên ta không cần cấu hình lại. Sau khi cấu hình HMP xong thì chọn nút Start để chạy HMP: 5.5 Cài đặt VoiceGuide 7.0.4 Sau khi cài đặt xong, chương trình VoiceGuide sẽ nằm trên thanh Menu Start: Và trên thanh Taskbar: Chọn mục Script Designer để mở cửa sổ dùng để thiết kế sơ đồ khối của hệ thống IVR. Tùy theo yêu cầu của người sử dụng mà có thể thiết kế nhiều sơ đồ hệ thống khác nhau. Trước khi thiết kế hệ thống IVR, ta cần tìm hiểu rõ chức năng của các khối trên thanh công cụ để có thể xây dựng ứng dụng cho phù hợp với yêu cầu đặt ra. Giao diện chương trình VoiceGuide có dạng như hình sau: Trên thanh công cụ của VoiceGuide có rất nhiều khối chức năng khác nhau, trong khuôn khổ đề tài này chỉ sử dụng 4 khối chức năng chính và thông dụng nhất là: Play Sound File : dùng để phát ra âm thanh từ các file đã có sẵn. Capture Entered Number : lưu lại các số của người gọi nhấn từ bàn phím. Query Database : truy xuất dữ liệu. Speak Number/Amount/Date etc. : đọc dữ liệu. 5.5.1 Play Sound File Khối này có chức năng là phát file âm thanh đã chỉ định trước, lưu ý là chỉ sử dụng file âm thanh định dạng WAV. Sau đó chuyển cuộc gọi đến khối tiếp theo tương ứng với số mà người gọi nhấn trên bàn phím điện thoại, điều này là do người lập trình quyết định khối nào tương ứng với số nào. Ví dụ như hình dưới đây, trong thẻ Play, đặt tên cho khối này là [Loi chao]. Click vào nút Select để dẫn đến file dạng wav muốn phát. Chọn số lần phát lại là 2 lần. Chọn thời gian giữa các lần phát lại là 5 giây. Trong thẻ Paths, thiết lập [Digit 1] nối đến khối [Khoa Dien – Dien tu], [Digit 2] nối đến khối [Nghe nhac]. 5.5.2 Capture Entered Number Khối này cũng có chức năng phát file âm thanh giống như khối Play Sound File. Ngoài ra nó còn có chức năng khác là tiếp nhận các chuỗi số của người gọi nhấn trên bàn phím điện thoại, sau đó xử lý rồi chuyển cuộc gọi đến khối tiếp theo trong sơ đồ hệ thống. Ví dụ như hình bên dưới, trong thẻ Get Numbers, đặt tên khối là [Nhap MSSV], chọn file âm thanh phát ra trước khi người gọi nhấn số là [Moi nhap MSSV.wav]. Ngoài ra có thể sử dụng thêm chức năng [Play back …] nếu muốn phát lại số người gọi vừa nhập từ bàn phím và hỏi để xác nhận là nhập đúng. Trong thẻ Sound Files cho phép chọn file để phát trước và sau khi người gọi nhập số. Ngoài ra có thể phát file âm thanh để thông báo là người gọi đã nhập sai. Thẻ Verify Entered Number dùng để lập trình theo ý muốn. Trong thẻ Paths bên dưới, chuyển cuộc gọi đến khối [Kiem tra MSSV] nếu như nhập số thành công. 5.5.3 Query Database Khối này có chức năng là truy xuất đến cơ sở dữ liệu và thực hiện lấy dữ liệu, thay đổi dữ liệu, thêm dữ liệu … tùy theo người lập trình trong khung SQL Query. Xem ví dụ bên dưới, trong thẻ Database Query, đặt tên khối này là [Kiem tra MSSV]. Chọn Database hoặc ODBC Data Source là [SINHVIEN]. Trong phần Connect String, tùy theo loại cơ sở dữ liệu mà nhập khác nhau. Trong ví dụ này sử dụng SQL server 2000, nên nhập vào dòng lệnh như sau: “ODBC; DRIVER=SQL SERVER; SERVER=TRI-0932606866\NGUYENMINHTRI; DATABASE=QUANLYSINHVIEN”. Trong thẻ Paths thiết lập như hình dưới, tức là nếu MSSV có trong cơ sở dữ liệu thì chuyển cuộc gọi đến khối [Doc MSSV], nếu không có thì chuyển đến khối [Thong bao nhap sai]. 5.5.4 Speak Number/Amount/Date etc. Khối này có chức năng là đọc dữ liệu là các con số. Có thể lập trình để đọc theo từng dạng khác nhau. Ví dụ như đọc theo từng số, đọc theo số đếm, đọc theo ngày tháng năm, đọc theo giờ, … Xem ví dụ bên dưới, tên khối là [Doc MSSV]. Có thể chọn file để phát trước khi đọc số bằng cách chọn nút Select. Trong khung Digits to be spoken, nhập dòng lệnh “$RV[Nhap MSSV]” tức là những con số do người gọi nhấn khi được hỏi về MSSV ở khối Nhap MSSV sẽ được lưu lại trong biến $RV[Nhap MSSV]. Trong khung Say number as, chọn [Digits] tức đọc từng con số trong chuỗi số. Trong thẻ Paths, thiết lập chuyển đến khối [Chon hoc ky] sau khi đọc xong dữ liệu. 5.5.5 Thiết kế Script Sau khi đã hiểu rõ chức năng của từng khối, bây giờ có thể thiết kế một sơ đồ hệ thống IVR theo ý muốn. Dưới đây là sơ đồ hệ thống IVR thiết kế để phục vụ cho việc nghe thông tin về điểm thi của sinh viên. Khi đã có được một sơ đồ hệ thống IVR hoàn chỉnh, bây giờ đến việc thay đổi lại file Config để VoiceGuide mới có thể chạy được sơ đồ IVR trên. Tìm và mở file theo đường dẫn sau: “C:\Program Files\VoiceGuide\Config\Config.xml”. Sau khi mở file trên, trên thanh công cụ chọn View à Source thì sẽ xuất hiện một cửa sổ như hình sau: Trong các dòng … , đánh vào đường dẫn đến file Script đã thiết kế ở trên, sau đó chọn File à Save là xong. 5.5.6 Test Sau khi đã hoàn tất xong việc Config, bây giờ chạy HMP bằng cách vào Menu Start à All Programs à Intel NetStructure HMP à Configuration Manager – DCM. Sau đó chạy VoiceGuide bằng cách nhấp phải chuột lên biểu tượng IVR trên thanh Taskbar rồi chọn Start. Nếu không có biểu tượng IVR trên thanh Taskbar thì vào Menu Start à VoiceGuide à Service Status Monitor. Khi IVR đã chạy, click phải chuột lên biểu tượng IVR và chọn Line Status, nếu xuất hiện 4 line của hệ thống IVR như hình bên dưới là hệ thống IVR đã sẵn sàng nhận cuộc gọi. Nếu chưa được thì phải khởi động lại máy, lưu ý là phải chạy HMP trước rồi mới chạy IVR. Cuối cùng, ta dùng X-Lite để gọi vào hệ thống IVR đã thiết kế ở trên và nghe nó tự động trả lời, người nghe chỉ việc chọn thông tin muốn nghe và gác máy khi muốn chấm dứt cuộc gọi. Xem cách cài đặt Softphone X-Lite ở phần 6. 5.6 Cài đặt Softphone X-Lite Softphone X-Lite sẽ xuất hiện trên thanh Menu Start sau khi cài đặt hoàn tất: Giao diện của phần mềm X-Lite như hình sau: Để cấu hình cho X-Lite hoạt động vào Show Menu à SIP Account Settings… như hình trên, sau đó sẽ xuất hiện cửa sổ sau: Để tạo tài khoản chọn Add… sẽ xuất hiện cửa sổ như hình dưới. Thiết lập Domain là địa chỉ IP của máy tính chạy hệ thống IVR, sau đó chọn OK. Bây giờ đã có thể dùng X-Lite để gọi vào hệ thống IVR (gọi bất cứ số nào). Lưu ý để sử dụng được phần mềm X-Lite thì máy tính phải kết nối mạng Internet. CHƯƠNG 6: NHẬN XÉT VÀ HƯỚNG PHÁT TRIỂN 6.1 Ứng dụng của đề tài Trung tâm hỗ trợ khách hàng: Ngày nay với sự phát triển của hệ thống mạng PSTN thì việc ứng dụng truy cập từ xa của hệ thống nhằm mang lại sự tiện lợi cho các công ty và phát triển thêm dịch vụ cho ngành Bưu điện. Khách hàng muốn truy cứu thông tin của một ngân hàng, công ty chứng khoán hay một công ty lớn có đầy đủ các dịch vụ thì khách hàng chỉ việc nhấc máy lên gọi vào số của công ty đó để có thể biết được thông tin mình quan tâm. Với sự phát triển của hệ thống này một mặt giúp cho các công ty về mặt nhân lực, chất lượng phục vụ khách hàng, đồng thời một mặt giúp cho khách hàng một cách tiện lợi là khỏi phải đi lại để biết được thông tin mình muốn biết. Ngoài ra nếu mà những thông tin chứa trong cơ sở dữ liệu của công ty đó không đủ đáp ứng với những thắc mắc của khách hàng thì hệ thống cũng có thể chuyển cuộc gọi đó tới người chịu trách nhiệm trả lời và tư vấn của công ty. Đối các công ty vừa và nhỏ: Làm câu chào quảng bá công ty và hướng dẫn khách hàng tới những bộ phận như phòng kinh doanh, kỹ thuật, nhân sự hay giám đốc của các công ty đó để có thể liên lạc với bộ phận mà khách hàng muốn gặp. Với sự ứng dụng này giúp cho các công ty có thể chuyên nghiệp hóa trong khâu tiếp khách hàng qua điện thoại, và với khách hàng thì có thể liên hệ trực tiếp với bộ phận mà mình muốn làm việc mà không cần qua reception. 6.2 Hướng phát triển của đề tài Với mục đích tạo sự tiện lợi và chăm sóc khách hàng ngày càng tốt hơn cùng với sự phát triển của điện thoại di động và hệ thống internet thì ngoài việc truy cập thông tin từ điện thoại thì chúng ta có thể truy cập những thông tin đó bằng tin nhắn SMS qua điện thoại di động hoặc bằng e-mail qua mạng internet. TÀI LIỆU THAM KHẢO 1. ITU-T Recommendation H323, Packet-based multimedia communication systems, 2/1998. 2. ITU-T Recommendation H225.0, Call signalling protocols andmedia stream packettization for packet-based mutimedia communication systems, 1998. 3. ITU-T Recommendtion H245, Control protocol for multimedia communication, 1998. 4. Nguyễn Hồng Sơn, Kỹ thuật điện thoại qua IP và Internet, Nhà xuất bản Lao Động Xã Hội, TP.HCM, 2003. 5. Nguyễn Hồng Sơn, Cơ sở kỹ thuật chuyển mạch và tổng đài, Nhà xuất bản Giáo Dục. 6. Nguyễn Quốc Cường, Internetworking với TCP/IP, Nhà xuất bản Giáo Dục. 7. Nguyễn Minh Khánh Ngọc, Đỗ Thanh Nguyên, Tìm hiểu kỹ thuật điện thoại IP và ứng dụng tích hợp điện thoại – máy tính, Đại học Bách Khoa, TP.HCM, 2004. 8. Đậu Quang Tuấn, Tự học lập trình cơ sở dữ liệu SQL Server 2000 và Visual Basic.Net, Nhà xuất bản Giao Thông Vận Tải, TP.HCM, 2005. 9. Trần Tuấn Ngọc, Triển khai tổng đài điện thoại VoIP bằng Trixbox, Đại học Bách Khoa, TP.HCM, 2007. 10. Trương Tấn Đức Anh, Bùi Quang Huy, Nghiên cứu giao thức SIP và thiết kế hệ thống ứng dụng thoại trên Internet, Đại học Bách Khoa, TP.HCM, 2008. MỤC LỤC