Cơ sở lý thuyết về dịch vụ ENUM
Tổng quan về ENUM
Với việc ngày càng có nhiều dịch vụ được phát triển trên mạng IP, chẳng hạn như công nghệ Voice Over IP (VoIP) ngày càng hoàn thiện và được ứng dụng rộng rãi cùng với sự ra đời của các giao thức báo hiệu mới như SIP, H323 đã làm xuất hiện các IP phone, giúp cho việc trao đổi thoại trên nền IP dễ dàng hơn với chất lượng cao và cước phí rẻ.
Hệ thống điện thoại truyền thống và điện thoại IP được xem xét đến do đây chính là các dịch vụ mấu chốt khiến cho ENUM được quan tâm ENUM có thể mang lại nhiều lợi ích khác nhau, nhưng trước hết, ENUM được xem như một công nghệ cách mạng đối với sự hội tụ hai loại hình dịch vụ thoại này.
Công nghệ ENUM cho phép ánh xạ số điện thoại tới địa chỉ Internet Như vậy, người sử dụng có thể thiết lập cuộc gọi từ các đầu cuối điện thoại truyền thống tới đầu cuối IP Tuy nhiên, khái niệm “gọi” ở đây được mở rộng
Trong ENUM, mỗi số điện thoại sẽ gắn với nhiều Contact khác nhau như: email, số điện thoại di động, cố định, địa chỉ Sip… Nên ứng dụng của ENUM cho phép lựa chọn phương thức, loại hình dịch vụ mềm dẻo, do người sử dụng quyết định. ENUM kết hợp với dịch vụ VoIP/IP Telephony cho khả năng sử dụng phương thức quay số thiết lập cuộc gọi tự nhiên.
ENUM cho phép người sử dụng dùng một số thoại duy nhất để truy nhập tới nhiều loại đầu cuối và dịch vụ như thoại, fax, e-mail, nhắn tin, thoại di động, truyền số liệu, web hay bất kỳ một loại hình dịch vụ nào có sử dụng địa chỉ IP, kể cả VoIP trên mạng Internet.
ENUM sẽ tạo khả năng phát triển dịch vụ mới có giá trị cao cho cả môi trường viễn thông truyền thống và Internet, góp phần hiện thực hoá khả năng hội tụ viễn thông và Internet Công nghệ ENUM sẽ giúp đưa tất cả dịch vụ như điện thoại, fax, email… hội tụ trên một số điện thoại và sẽ không còn ranh giới về địa lý
Có thể lấy ví dụ cụ thể như sau: một anh A ở Việt Nam khi ra nước ngoài công tác Nhưng khi tới nước khác, A không thể tiếp tục sử dụng số điện thoại đã đang kí ở Việt Nam, và những người khác không thể liên lạc với anh ta theo số cũ nữa Và ENUM có thể giải quyết vấn đề này A chỉ việc thay đổi lại Contact của mình, thay số điện thoại cũ bằng số mới Và mọi người khi quay tới số ENUM của A, cuộc gọi sẽ được chuyển tới số mới Cho dù A đang ở đâu, hay thay đổi số điện thoại thế nào, tất cả những gì những người cần liên lạc là số ENUM mà A đã đăng kí.
Hay có thể lấy ví dụ khác về một ứng dụng của ENUM Anh B đăng kí trong danh sách các Contact của mình là các số điện thoại di động, điện thoại cơ quan, điện thoại nhà riêng B thông qua hệ thống ENUM có thể đặt ra một qui tắc gọi cho mình Chẳng hạn như, khi có ai gọi tới số ENUM của B, cuộc gọi sẽ được tự động chuyển từ máy cơ quan sang di động rồi tới máy ở nhà nếu B không nghe máy.
Các ví dụ trên tuy chỉ là một trong những ứng dụng của ENUM, nhưng đã phần nào thể hiện được ý tưởng ban đầu tạo ra ENUM: “có thể nhận cuộc gọi ở bất kỳ đâu trên thế giới với cùng một số điện thoại và thông qua đường truyền tốt nhất, rẻ nhất”.
PSTN và mạng Internet
"Mạng điện thoại công cộng" PSTN là khái niệm được dùng để chỉ hệ thống điện thoại truyền thống được xây dựng từ thế kỷ 20, và được ứng dụng toàn cầu, có mặt tại hầu hết các quốc gia và vùng lãnh thổ trên thế giới Tính chất quan trọng cơ bản là ở chỗ mạng này là mạng chuyển mạch kênh, tức là khi có một cuộc gọi được thiết lập, một kênh kết nối (kênh) sẽ được thiết lập bằng các chuyển mạch từ đầu cuối gọi tới đầu cuối bị gọi Kênh kết nối này được thiết lập và duy trì cho tới khi cuộc gọi kết thúc
Trái với chuyển mạch kênh, mạng Internet là mạng chuyển mạch gói, trên đó các thông tin được chia thành các gói và truyền trên các hệ thống thông tin sử dụng chung Tập hợp các thủ tục xử lý các gói tin cùng với sự phát triển của các mạng kết nối với Internet đã làm cho Internet trở thành mạng kết nối lớn nhất toàn cầu Ngày nay đa số các dạng thức dữ liệu thông tin trao đổi toàn cầu được lưu chuyển trên nền mạng Internet. Điện thoại IP (voice over IP) là dịch vụ điện thoại sử dụng công nghệ chuyển đổi dữ liệu thoại thành các gói dữ liệu IP và truyền qua Internet thông qua các thủ tục Internet Hiện nay có rất nhiều dịch vụ VoIP khác nhau đã được triển khai thương mại trên thực tế, và đã trở thành một trào lưu phát triển mạnh mẽ Để có thể gọi được điện thoại IP, không cần thiết phải sử dụng ENUM Người ta có thể gọi trực tiếp tới đầu cuối sử dụng VoIP khác hay gọi thông qua 1 nhà cung cấp dịch vụ trung gian Một phương pháp thông thường nhưng không phải là duy nhất là sử dụng thủ tục thiết lập phiên (Session Initiation Protocol) hay SIP SIP làm nhiệm vụ thiết lập cuộc gọi, rung chuông người bị gọi thông qua Internet Gửi gói tin SIP đi cũng tương đương với việc quay số trên mạng PSTN truyền thông. Địa chỉ được sử dụng trong SIP có dạng gần giống với địa chỉ thư điện tử, ví dụ như
"sip:datvt@cdit.com.vn" có thể được dùng làm địa chỉ bị gọi bởi SIP
Một vấn đề tồn tại tại thời điểm này là sự tương tác giữa các đầu cuối điện thoại truyền thống và điện thoại IP có nhiều khó khăn Trong khi các đầu cuối điện thoại
IP có thể dễ dàng gọi tới đầu cuối PSTN thông qua các gateway chuyển đổi sử dụng phần mềm thì các đầu cuối thoại truyền thống, thông qua các chuyển mạch kênh kiểu cũ thường không thể hiểu được các đích định tuyến cần truyền tải, và do đó bắt buộc phải có 1 gateway cục bộ được định sẵn trong cùng mạng PSTN đó để kết cuối các cuộc gọi Đó là chưa kể các đầu cuối truyền thống thường chỉ có các phím số, không thể sử dụng cùng loại địa chỉ với các đầu cuối VoIP (có thể có địa chỉ dạng SIP) Đây chính là điểm ENUM được thiết kế để giải quyết.
Cụ thể hơn, giải pháp cho việc thực hiện cuộc gọi từ các thuê bao trong mạng IP sang các thuê bao trong mạng PSTN đã được thực hiện thành công thông qua các gateway chuyển đổi báo hiệu và gateway chuyển đổi media Tuy nhiên với chiều ngược lại là thực hiện cuộc gọi từ các thuê bao trong mạng PSTN sang các thuê bao trên mạng IP vẫn chưa thực hiện được Điều này là do sự khác biệt về hệ thống đánh địa chỉ trong mạng PSTN và trong mạng IP: trong mạng PSTN các thuê bao được đánh địa chỉ theo hệ thống E.164, trong khi mạng IP các thuê bao được đánh địa chỉ theo định dạng Uris Vậy cần có giải pháp chuyển đổi địa chỉ E164 sang các dạng địa chỉ Uris để cho các thuê bao trong mạng PSTN có thể thực hiện được cuộc gọi sang các thuê bao trong mạng IP.
Trước yêu cầu đó, vào năm 2000 tổ chức truyền thông Quốc tế IETF đã xây dựng nên giao thức ENUM trong RFC2916, sau đó đã nâng cấp lên trong RFC3761.
ENUM (tElephone Number Mapping) định nghĩa phương thức chuyển đổi, ánh xạ địa chỉ E164 sử dụng trong mạng truyền thống sang các định dạng địa chỉ được dùng trên mạng IP Cùng với các giao thức báo hiệu và media khác, nó thực hiện chức năng như một cầu nối để một thuê bao trong mạng truyền thông có thể trao đổi thông tin với một thuê bao trên mạng IP.
Với vai trò là cầu nối trao đổi thông tin giữa mạng thoại truyền thống và mạng thoại IP, mô hình ứng dụng của của một cuộc gọi từ mạng PSTN sang IP sử dụng ENUM có thể được thực hiện như sau:
Hình I.1Cuộc gọi từ PSTN tới IP
Hệ thống DNS
Mỗi thực thể trên Internet đều có một địa chỉ IP xác định duy nhất, và để trao đổi thông tin với một thực thể, người dùng có thể gửi trực tiếp thông tin đến địa chỉ IP của thực thể đó Tuy nhiên việc nhớ địa chỉ IP của thực thể là một việc khó khăn và không khả thi.
Hệ thống tên miền DNS (Domain Name System) ra đời với việc thực hiện việc phân giải từ một tên miền ra một địa chỉ IP và ngược lại Để có thể trao đổi thông tin với một thực thể khác trên mạng IP, thay vì phải nhớ chính xác địa chỉ IP của thực thể đó, người dùng chỉ cần nhớ tên của thực thể đó, việc này dễ dàng hơn rất nhiều.
Trên Internet có rất nhiều các dịch vụ thông tin khác nhau, ví dụ: dịch vụ web, dịch vụ email, dịch vụ nhắn tin nhanh, dịch vụ VoIP… Ứng với mỗi loại hình dịch vụ, có một định dạng bản ghi tương ứng với nó được lưu trữ trong cơ sở dữ liệu DNS Việc mở rộng các dịch vụ trên Internet là không có giới hạn, tương ứng với nó, hệ thống DNS hỗ trợ rất nhiều định dạng bản ghi khác nhau tương ứng với từng loại dịch vụ.
Bản ghi A: www.test.com.vn IN A 10.206.31.33 được sử dụng cho các máy chủ.
Bản ghi MX: test.com.vn IN MX 10 mail.test.com.vn được sử dụng cho các dịch vụ email
Hệ thống thông tin trên Internet được phân chia thành nhiều domain tuỳ theo các mục đích sử dụng khác nhau, mỗi domain lại được chia thành nhiều domain con (subdomains), sơ đồ phân cấp theo dạng hình cây như sau:
Hình I.2Sơ đồ phân cấp DNS Ở cấp cao nhất là các máy chủ lưu trữ thông tin về thư mục gốc Dưới thư mục gốc là hệ thống các DNS lưu trữ các thông tin về hệ thống tên miền cấp 1, ví dụ như: com, net, org, … hay các tên miền cấp quốc gia, ví dụ: vn, uk, jp, … Dưới tên miền cấp 1 là các cấp thấp hơn như cấp 2, 3, 4, …
Hiện nay trên thế giới có khoảng 6 máy chủ DNS lưu trữ thông tin thư mục gốc được đặt phân bố trên nhiều vùng địa lí khác nhau.
Với tính chất mở, việc thêm vào các hệ thống tên miền mới như cấp 1, 2, … là rất dễ dàng Hiện tại top level domain của DNS có các loại sau:
com: dùng cho các tổ chức về thương mại.
edu: dùng cho các tổ chức về giáo dục.
gov: dùng cho các tổ chức về chính phủ.
net: dùng cho các tổ chức cung cấp về kiến trúc mạng, nó cũng có thể sử dụng cho các tổ chức về thương mại.
mil: dùng cho các tổ chức quân sự.
int: dùng cho các tổ chức quốc tế.
arpar: dùng lưu trữ các dạng địa chỉ Trong đó: e164.arpar được khuyến nghị sử dụng để lưu trữ các địa chỉ E164.
Các tên miền cấp quốc gia: vn, uk, jp, …
Sơ đồ phân cấp hiện tại có thể được mô tả như sau:
Hình I.3Sơ đồ phân cấp các domain DNS
Việc truy xuất các bản tin DNS sử dụng giao thức mô tả trong RFC1035-Domain
ENUM và DNS
Thay vì ánh xạ tên miền IP như DNS, hệ thống ENUM cho phép chuyển đổi E164 tên miền
Do tính tương tự của 2 việc ánh xạ này, ITU đã khuyến nghị sử dụng hệ thống đánh tên miền DNS để hỗ trợ ENUM
Kiến trúc phân cấp của hệ thống ENUM
ENUM là một hệ thống phân cấp, mô hình phân cấp của ENUM tương ứng như mô hình phân cấp trong hệ thống địa chỉ E164.
Kiến trúc phân cấp của hệ thống ENUM được thể hiện như sau:
Hình I.4Kiến trúc phân cấp của ENUM
Trong kiến trúc phân cấp này, cấp cao nhất Tier 0: e164.arpa do tổ chức RIPE NCC quản lí.
Các cấp quốc gia Tier 1 chứa mã tên miền Quốc gia (ví dụ của Việt Nam là 4.8.e164.arpa) do các Quốc gia quản lí Để được chuyển giao mã Quốc gia, các nước cần phải làm các thủ tục đăng kí với RIPE NCC và ITU.
Dưới cấp Quốc gia là tên miền ENUM chứa mã của các nhà cung cấp dịch vụ tên miền ENUM Tier 2.
Với ứng dụng ENUM, IETF và ITU khuyến nghị sử dụng tên miền cấp một là arpar (Address and Routing Parameter Area), tên miền cấp 2 là e164.arpar, phân cấp tiếp theo là các mã quốc gia, ví dụ: 4.8.e164.arpar chứa nội dung mã 84 của Việt Nam Sơ đồ phân cấp được mô tả như sau:
Hình I.5Sơ đồ phân cấp ENUM/DNS
Bản tin NAPTR
Tương tự hệ thống DNS, bản ghi NAPTR (RFC2915-The Naming Authority
Pointer DNS Resource Record) được sử dụng để lưu trữ các thông tin cho dịch vụ
ENUM Cấu trúc của bản ghi NAPTR gồm có: trường thứ tự (order), trường ưu tiên (preference), trường dịch vụ (service), các cờ (flag), trường biểu thức (regexp – regular expression), và trường thay thế (replacement):
Tên miền IN NAPTR thứ tự mức ưu tiên cờ dịch vụ biểu thức thay thế
IN NAPTR 101 10 "u" "E2U+sip" "!^.*$!sip:datvt@enum.com.vn!"
IN NAPTR 102 10 "u" "E2U+mailto" "!^*$!mailto:datvt@enum.com.vn!"
"E2U+ldap" "!^+84(.*)$!ldap://ldap.enum.com.vn/cn!"
- Trường thứ tự “order” là một số 16 bit (0 đến 65535) xác định thứ tự (từ thấp đến cao) trong đó các bản ghi cần phải được xử lí khi mà có nhiều bản ghi NAPTR được trả về đối với một truy vấn đơn Khi đó bản ghi NAPTR có thứ tự thấp hơn sẽ được xử lí trước.
- Trường ưu tiên “preference” là một số 16 bit (0 đến 65535) xác định thứ tự (từ thấp đến cao) các bản ghi được xử lí khi có nhiều bản ghi NAPTR có cùng giá trị “order”.
- Trường dịch vụ “service” là một chuỗi ký tự, chỉ ra thủ tục phân giải và dịch vụ phân giải sẽ sẵn sàng khi việc viết lại được thực hiện thông qua các trường
"biểu thức" và "thay thế"
- Trường các cờ “flags” là một chuỗi ký tự, chứa tham số ảnh hưởng tới lần truy vấn tiếp theo, thường được dùng để tối ưu hoá quá trình truy vấn Cờ "u" được hiểu là luật này là luật áp dụng để kết thúc chu trình, và dữ liệu trả về là một URI.
- Trường biểu thức “regexp – regular expression” chứa một chuỗi biểu thức thay thế mà khi áp dụng vào chuỗi nguyên thuỷ sẽ tìm ra được tên miền nào sẽ được truy vấn tiếp theo.
- Trường thay thế “replacement” có thể là một tên miền mới để truy vấn tuỳ theo các giá trị có thể của trường "cờ" Trường này được sử dụng khi trường
"biểu thức" là một phép thay thế đơn giản Bất kỳ giá trị nào của trường này cũng phải là một tên miền đầy đủ (full qualified domain name). Để có thể sử dụng dịch vụ ENUM, người dùng sẽ cần phải đăng kí với nhà cung cấp dịch vụ Một số E164 sẽ đại diện cho một số các địa chỉ contact tương ứng, việc ánh xạ này sẽ được ghi vào cơ sở dữ liệu của hệ thống ENUM là các bản ghiNAPTR.
Kĩ thuật ánh xạ trong ENUM
Ánh xạ số điện thoại E.164 vào hệ thống DNS là nền tảng của ENUM Với 1 số điện thoại ứng với một cá nhân nào đó, thông qua các phép truy vấn (giống như tra cứu danh bạ, trang vàng) có thể tìm được rất nhiều các thông tin liên quan như mail,tel, address Ở đây chỉ khác là hệ thống lưu trữ thông tin là hệ thống DNS được sửa đổi, phép truy vấn là thủ tục DNS đã rất phát triển Với thế mạnh của dịch vụInternet, các truy vấn dựa trên DNS được coi là rất dễ triển khai và ứng dụng.
Các bước định dạng truy vấn ENUM:
1 Số E.164 phải được viết dưới dạng đầy đủ theo quy định của ITU, bao gồm cả các mã quốc gia IDDD, theo dạng (VD): +84-4-8226115
2 Bỏ đi các ký tự không phải số, trừ dấu "+": +8448226115
4 Bỏ dấu chấm "." vào giữa các chữ số: 8.4.4.8.2.2.6.1.1.5
6 Thêm chuỗi "e164.arpa" vào cuối: 5.1.1.6.2.2.8.4.4.8.e164.arpa
Việc xử lý các trường NAPTR được thực hiện thông qua một thuật toán gọi là thuật toán NAPTR, đầu vào của thuật toán này là chuỗi thể hiện số E.164 theo định dạng như định nghĩa trong bước 2 của quá trình chuyển đổi nói trên, tức là chuỗi đầu vào có dạng: "+8448226115", đầu ra của thuật toán là một chuỗi định danh tài nguyên thống nhất URI trong dạng thức tuyệt đối của nó.
Một số mô hình kết nối
I.8.1 Cuộc gọi bên trong mạng IP
Việc thực hiện cuộc gọi để kết nối rất đơn giản như sau:
Hình I.6Cuộc gọi bên trong mạng IP
(1) Đầu cuối A nhập số điện thoại E164 của đầu cuối B ví dụ 84-4-8226115 vào trường gọi, phần mềm ứng dụng sẽ biến số điện thoại này thành dạng tên miền5.1.1.6.2.2.8.4.4.8.e164.arpa.và hỏi DNS.
(2) DNS trả lời tất cả các dịch vụ đã đăng ký liên quan tới tên miền 5.1.1.6.2.2.8.4.4.8.e164.arpa này.
(3) Người gọi chọn dịch vụ để liên lạc ví dụ như mailto:thtc@vnnic.net.vn
I.8.2 Cuộc gọi từ mạng viễn thông sang mạng IP
Hình I.7Cuộc gọi mạng viễn thông sang mạng IP
Thuật ngữ SIP - Session Initiation Protocol, giao thức khởi tạo phiên làm việc là một giao thức cơ bản để thực hiện các dịch vụ liên quan tới số thoại E164.
(1) Đầu cuối B gọi số thoại E164 ví dụ của đầu cuối A là 8448226115
(2) Tổng đài chuyển mạch thoại chuyển tiếp số gọi này tới gateway tương ứng.
(3) a/ Gateway biến đổi số thoại thành tên miền 5.1.1.6.2.2.8.4.4.8.e164.arpa.và hỏi DNS. b/ DNS trả lời các dịch vụ đã đăng ký của số thoại (tên miền) này Ví dụ như mailto:thtc@vnnic net.vn
(4) a/ GW hỏi DNS xem vnnic.net.vn được host ở máy chủ nào, điạ chỉ IP là bao nhiêu. b/ DNS trả lời địa chỉ IP của vnnic.net.vn.
(5) Cuộc gọi được chuyển đến SIP server và tiếp tục tới địa chỉ của máy chủ thư vnnic.net.vn (6).Quan hệ của SIP server và SIP client sử dụng thủ tục client/server.
I.8.3 Cuộc gọi thoại từ mạng IP sang mạng viễn thông
Hình I.8Cuộc gọi từ mạng IP sang mạng viễn thông
(1) a/ Đầu cuối A quay số gọi đầu cuối B 84-4-8226115 ở mạng thoại viễn thông, chương trình máy trạm (SIP client) biến đổi số thoại thành tên miền và hỏi DNS b/ DNS trả lời dịch vụ thoại đã được đăng ký với số +8448226115.
(2) SIP client phát tín hiệu “invite” tới SIP server báo hiệu đã sẵn sàng.
(3) a/ SIP server hỏi địa chỉ của Gateway tương ứng tại máy chủ Location Server-LS. b/ LS trả lời địa chỉ IP của Gateway đó.
(4) SIP server chuyển cuộc gọi tới GW.
(5) GW biến đổi từ giao thức IP sang giao thức làm việc của mạng viễn thông và tổng đài chuyển mạch thoại thực hiện nốt công việc còn lại.
I.8.4 Cuộc gọi thoại trong mạng viễn thông
Hình I.9Cuộc gọi bên trong mạng viễn thông
Giả sử máy thoại 1 quay số thoại 8448226115 của máy 2, Gateway 1 biến đổi số thoại đó ra tên miền có đuôi e164.arpa và hỏi DNS Hệ thống DNS trả lời dịch vụ đã đăng ký của số thoại 2 (trong trường hợp này chỉ là IN NAPTR 10 10 “u”
Gateway 1 hỏi tiếp DNS gateway tương ứng với số thoại này có điạ chỉ IP là bao nhiêu.
DNS trả lời điạ chỉ IP của Gateway 2 Gateway1 chuyển cuộc gọi tới gateway 2 để nó thực hiện nốt phần còn lại của cuộc gọi.
Tình hình nghiên cứu, triển khai ENUM trên thế giới
Ngay từ khi rfc2916 được công bố vào tháng 12/2000, ở nhiều quốc gia đã thành lập các nhóm chuyên nghiên cứu về ENUM Một số nước đã tiến hành thử nghiệm thành công và bắt đầu khai thác thương mại ENUM Sau đây là tình hình nghiên cứu và giải pháp triển khai ENUM ở một số tổ chức và một số nước trên thế giới.
I.9.1 Tình hình nghiên cứu, chuẩn hóa về ENUM
IETF là một tổ chức chuẩn hoá các kĩ thụât được sử dụng cho mạng Internet, ví dụ TCP/IP Nó là một tổ chức cấp dưới của IAB quản lí việc chuẩn hoá kiến trúc
Internet và hoạt động suôn sẻ của Internet Các đặc tả kĩ thuật được chuẩn bị bởi IETF được cung cấp dưới dạng các RFC.
Nhóm đang làm việc về ENUM của IETF, ENUM-WG, được thành lập vào tháng 10 năm 1999 IETF kết hợp với “IP-Telecoms Interworking Workshop” được bảo trợ bởi ITU vào tháng 1 năm 2000 và đã tham gia làm việc với ITU-T Giao thức ENUM đã được chỉ định dưới dạng một RFC (RFC 2916) vào tháng 12 năm 2000.
Hiện nay ENUM-WG đã nâng cấp RFC2916 trong RFC3761.
Các địa chỉ liên quan:
- http://www.ietf.com/ (IETF).
- http://www.ietf.org/html.charters/77ENUM-charter.html (Telephone Number Mapping (ENUM) WG)
I.9.1.2 Tổ chức truyền thông Quốc tế ITU
ITU, trụ sở tại Geneva, Thuỵ Sĩ, là một tổ chức Quốc tế đưa ra các tiêu chuẩn Quốc tế cho truyền thông, thông tin ITU đã thông qua các đánh giá (các công bố) về sự phát triển, sự thực thi, sự cải tiến của điện thoại IP trên toàn thế giới trong hội thảo cơ chế truyền thông thế giới tháng 3 năm 2001.
ITU bắt đầu làm việc cùng với IETF trong “IP-Telecoms Interworking Workshop” vào tháng 1 năm 2000 Tại hội nghị ITU-T SG2 WP1 được tổ chức vào tháng 10 năm 2000 đã xác định hệ thống các thủ tục quản trị kho số E164 trong ENUM DNS.
Trong cuộc họp ITU ENUM Workshop tổ chức vào tháng 1 năm 2001, nhiều tổ chức liên quan của nhiều quốc gia đã trao đổi các quan điểm về các vấn đề chính sách liên quan tới hoạt động triển khai ENUM Sau cuộc họp của ITU-TSG2 vào tháng 1 và tháng 12, việc cung cấp các mã quốc gia ENUM được chỉ định theo vùng địa lí, các mạng và tiếp tục được thông qua vào tháng 5/2002.
Các địa chỉ liên quan:
- http://www.itu.int/home/index.html (ITU).
- http://www.itu.int/osg/spu/ENUM/index.html (ITU ENUM).
ENUM Forum được thiết lập vào tháng 8 năm 2001 để tạo ra một framework cho việc thông qua cơ chế của RFC2916, đặt cơ sở trên kiến trúc DNS sử dụng các số E164 với thư mục gốc E164.arpar, ở Bắc Mỹ dưới sự chi phối của NANP (kế hoach đánh số Bắc Mỹ).
ENUM Forum đã phát hành tài liệu thống nhất liệt kê các yêu cầu liên quan tới Tier1 và Tier2 vào tháng 10/2002 Tài liệu thống nhất ‘Unified Document’ đề cập tới quy trình phân cấp của ENUM, bao gồm an ninh, tính riêng tư, vai trò của Tier1, Tier2 và kết nối của chúng,
Các địa chỉ liên quan :
- http://www.ENUM-forum.org/ (ENUM Forum).
- http://www.ENUM-forum.org/documents.html (The ENUM Forum - documents).
UKEG được thành lập vào tháng 12/2001 để nghiên cứu các vấn đề hoạt động và hành chính về sự thực thi ENUM ở Vương quốc Anh và các cách giải quyết của họ ở tầm nhìn công nghiệp, và viết các kế hoạch gợi ý cho Bộ thương mại và công nghiệp Anh.
Báo cáo ban đầu đã đề xuất “một framework thích hợp mà sẽ làm cho thuận lợi cho việc thực thi ENUM ở UK’’ được đưa ra vào tháng 4/2002 Vào tháng 12, một công bố chính thức được đưa ra để kêu gọi sự tham gia cho các thử nghiệm ENUM. Các địa chỉ liên quan:
- http://www.dti.gov.uk/cii/regulatory/ENUM/index.shtml (DTI ENUM)
- http://www.dti.gov.uk/cii/regulatory/ENUM/egp_report.shtml (UKEGPreliminary Report on ENUM April 02).
- http://www.dti.gov.uk/industries/ecommunications/key_dti_contacts.html
ETSI là tổ chức đưa ra các tiêu chuẩn truyền thông ở Châu Âu Trong khi ITU là một tổ chức Quốc tế đại diện cho nhiều nước, ETSI là một tổ chức tiêu chuẩn vùng tập trung vào các hoạt động tiêu chuẩn hoá ETSI đang thiết lập tiêu chuẩn Châu Âu
EN liên quan đến truyền thông, và các tiêu chuẩn truyền thông Châu Âu ETSI.
Dự án TIPHON (Telecommunications and Internet Protocol Harmonization Over Networks) đã được thiết lập để thảo luận về sự chuẩn bị cho các yêu cầu thống nhất cho việc thực thi các dịch vụ thương mại cho hội thoại voice và truyền thông đa phương tiện trên mạng IP Nó cũng đưa ra các yêu cầu cho việc kết nối ENUM ở Châu Âu vào tháng 10/2002.
Các địa chỉ liên quan:
- http://www.etsi.org/ (ETSI).
- http://www.etsi.org/frameset/home.html/tiphonweb/ (TIPHON).
- http://portal.etsi.org/tiphon (TIPHON portal site).
RIPE NCC (RIPE Network Coordination Centre) là một tổ chức độc lập, phi lợi nhuận gồm nhiều thành viên bao gồm các nhà cung cấp dịch vụ Internet (ISP), các tổ chức truyền thông và các công ty lớn ở châu Âu, Trung Đông và Trung Á.
RIPE NCC hỗ trợ về cơ sở hạ tầng Internet qua sự phối hợp kĩ thuật trong miền dịch vụ của nó Hoạt động nổi bật nhất của RIPE NCC là hoạt động như nhà đăng kí Internet vùng cung cấp các tài nguyên Internet toàn cầu và các dịch vụ liên quan cho các thành viên trong RIPE NCC.
Với dịch vụ ENUM, RIPE NCC đã được IAB (Internet Architecture Board) chuyển giao cho việc quản lí Tier0 E164.arpar Các quốc gia muốn được chuyển giao mã ENUM Tier1 tương ứng cần phải đăng kí với RIPE NCC Các thủ tục đăng kí có thể xem trong trang web của RIPE.
Các địa chỉ liên quan:
- http://www.ripe.net/rs/ENUM/index.html
- http://www.ripe.net/info/ncc/
I.9.2 Tình hình triển khai ENUM tại một số khu vực
Mô hình và chỉ tiêu kỹ thuật
Giải pháp chung
Sau khi có những tìm hiểu tổng quan về hệ thống ENUM trong chương I, chương này sẽ trình bày về mô hình chung cũng như phân tích các thành phần chính trong thiết kế của hệ thống ENUM Từ đó sẽ đi vào mô tả chi tiết trong các chương tiếp theo.
Như đã trình bày trong chương I, có thể thấy bản thân hệ thống ENUM chỉ là hệ thống chuyển đổi địa chỉ và nó có thể hoạt động độc lập không thuộc quyền của nhà khai thác nào Nhưng để ứng dụng Enum trong Viễn thông thì khái niệm địa chỉ được nhắc tới trong sự chuyển đổi này chính là các thuê bao - khách hàng của mạng viễn thông Điều này đòi hỏi dữ liệu của bản thân khách hàng đăng kí và các dịch được cung cấp từ nhà mạng Từ đó dẫn tới mô hình hệ thống có thể chia làm 2 phân tương đối tách biệt: phần ENUM cơ sở (quản lý về mặt dữ liệu) và phần hỗ trợ dịch vụ trên ENUM Mô hình tổng quát của hệ thống như sau:
Hình II.14Mô hình tổng quát hệ thống ENUM
II.1.1 Phần ENUM cơ sở
Hình II.15Phần ENUM cơ sở
Gồm các thành phần hỗ trợ quản lý dịch vụ cũng như CSDL của hệ thống như: các chức năng quản lý và đăng ký thuê bao, quản lý dữ liệu khách hàng… Phần này độc lập với phần xử lý dịch vụ ENUM CSDL của ENUM có thể truy xuất bởi các hệ thống xử lý dịch vụ khác nhau nếu chúng hỗ trợ giao diện truy xuất ENUM chuẩn cũng như được cấp quyền làm việc này.
II.1.2 Phần hỗ trợ dịch vụ ENUM
Các chức năng trong việc hỗ trợ xử lý các dịch vụ liên quan đến dịch vụ ENUM được nhóm trong phần này Là thành phần hoàn toàn mở rộng, do các bên phát triển thực hiện Phương pháp tổng quát là khi có yêu cầu, sẽ thực hiện truy vấn tới phần ENUM cơ sở, lấy dữ liệu về và xử lý.
Hiện tại em đang thử nghiệm 1 dịch vụ:
First Number: thực hiện gọi vào số có độ ưu tiên nhỏ nhất
Trong thời gian tới sẽ thử nghiệm thêm các dịch vụ khác như:
UMS: thực hiện gửi qua tin nhắn SMS
Call Optimize: tối ưu hóa cuộc gọi, sẽ thực hiện gọi vào contact có giá thành rẻ nhất trước
Time Routing: thực hiện gọi tới các contact tùy theo thời gian định trước. VD: gọi đến số cơ quan khi trong giờ làm việc, gọi tới máy ở nhà vào buổi tối…
Follow Me: thự hiện gọi lần lượt tới từng Contact trong danh sách
One Number: thực hiện rung chuông đồng thời tất cả các Contact
Tiềm năng phát triển của ENUM nằm trong phần hỗ trợ dịch vụ này Có thể trong tương lai gần, do chính sách của các nước cũng như rào cản thói quen cũ,phần hỗ trợ dịch vụ chưa được phong phú cũng như hữu ích Nhưng với xu thế hội nhập toàn cầu, khả năng ứng dụng của ENUM trong tương lai là rất lớn.
Tiêu chí đặt ra cho các thành phần
II.2.1 Tiêu chí, chỉ tiêu chất lượng đặt ra cho phần ENUM cơ sở
Giải pháp được thiết kế phải tuân theo các tiêu chuẩn Quốc tế liên quan đến Enum, có thể sẵn sàng tích hợp vào hệ thống ENUM trên thế giới (cụ thể là tuân theo chuẩn RFC 3761).
Các server chứa cơ sở dữ liệu Enum cũng như các thao tác, vận hành, giao tiếp người sử dụng Enum đều thuộc miền Internet vì vậy yêu cầu của an ninh đảm bảo an toàn cho CSDL cũng như việc cấp quyền truy nhập cho các đối tượng nguời dùng khác nhau.
Việc thiết kế xây dựng phần ENUM cơ sở này sẽ được trình bày trong chương tiếp theo (chương III), gồm một số các thành phần sau:
Hệ thống Portal giúp quản lý CSDL hệ thống, phân quyền truy nhập dữ liệu cho các đối tượng.
Demo chương trình ENUM Client cho phép lấy thông tin từ hệ thốngENUM, đảm bảo rằng dữ liệu của hệ thống tuân theo đúng chuẩn quốc tếRFC 3761.
II.2.2 Tiêu chí cho phần dịch vụ Để thực hiện các dịch vụ gia tăng trong giải pháp cần phải có thêm một số thực thể mới (Voice mail, Mail server ) Tuỳ theo nhà khai thác muốn cung cấp dịch vụ gì thì số các thực thể này là cần thiết hay không?
Việc thực hiện các kịch bản dịch vụ có một số yêu cầu:
Các dịch vụ giàu tiện ích
Đảm bảo khả năng vận hành thông suốt
Việc này dẫn tới đòi hỏi nhà khai thác phải có khả năng chủ động tối đa trong việc thiết kế và tích hợp dịch vụ.
Trong chương IV của báo cáo, em sẽ trình bày về một ứng dụng thử nghiệm có tính thực tiễn cao cho phần dịch vụ này.
Quản lý cơ sở dữ liệu cho hệ thống ENUM
Mô tả chung
Trong chương này, sẽ trình bày chi tiết về phần ENUM cơ sở trong hệ thống chung Cụ thể là các thành phần như sau:
Potal quản lý cơ sở dữ liệu
Hình III.16Mô hình hệ thống CSDL Enum – Phần ENUM cơ sở
Name Server
Như ta thấy trong Mô hình hệ thống CSDL ENUM, Name Server được cài đặt ở đây là thuộc Tier 2 (ENUM Provider – nhà cung cấp dịch vụ), khi được áp dụng về thực tế nó thuộc quyền quản lý của các nhà cung cấp dịch vụ như VNPT, Viettel,
FPT Từ Tier 2 này sẽ được nối lên Tier 1 (cấp quốc gia – VNNIC), rồi từ đây nối tiếp với Tier 0 (cấp quốc tế).
Như vậy, sau khi được cấp tên miền cấp quốc gia, nhiệm vụ Tier 1 sẽ là cấp tiếp tới các phân mức thấp hơn trong quốc gia của mình Cũng tương tự như trong việc qui hoạch đầu số trong điện thoại, sau khi có đầu số 084 cấp quốc gia, việc tiếp là phân đầu số cho các nhà cung cấp dịch vụ (098 Viettel, 091 Vina ).
Hiện tại có nhiều sản phẩm Name Server mã nguồn mở chạy trên nền Linux Ở đây em sử dụng chương trình Bind 9.3 chạy trên nền Redhat 9 làm Name Server. Đầu số thử nghiệm là 84473085XX.
Việc cấu hình một tên miền trên Name Server được thực hiện chủ yếu trên 2 file:
/etc/named.conf : thể hiện đăng kí 1 tên miền, nơi lưu thông tin của tên miền này.
/var/named/db.enum.84473085: file này được tạo ra tương ứng với thông tin được trỏ tới trong named.conf Nội dung chính của file này lưu các thông tin liên quan tới tên miền mà nó được trỏ tới như: các sub domain, ngày tạo lập
III.2.1 File đăng kí tên miền
Nội dung cấu hình đầu số 84473085XX cho Name Server trong file named.conf:
… zone "5.8.0.3.7.4.4.8.e164.arpa" IN { type master; file "enum/db.enum.84473085"; allow-update { none; };
Như ta đã thấy trong nội dung trên, đầu số 84473085XX được viết đảo ngược vào thêm và đuôi e164.arpa (theo đúng như qui tắc ánh xạ trong ENUM – như đã trình bày trong chương I), được viết thành: 5.8.0.3.7.4.4.8.e164.arpa.
Các thông số còn lại:
Type master: thể hiện Name Server hiện tại là Server trực tiếp quản lý tên miền 5.8.0.3.7.4.4.8.e164.arpa.
File "enum/db.enum.84473085": chỉ ra file sẽ lưu các thông tin liên quan tới tên miền 5.8.0.3.7.4.4.8.e164.arpa Ở đây em tạo ra file db.enum.84473085 để lưu thông tin.
III.2.2 File thông tin cấu hình
CSDL của Name Server được lưu dưới dạng các file text, tùy theo các loại bản tin mà có các cách biểu diễn khác nhau Và CSDL thực sự của ENUM được lưu trong hệ thống DNS của Name Server dưới dạng các bản tin NAPTR Với bản tin NAPTR, nội dung được biểu diễn như sau:
Một phần nội dung trong CSDL Enum (trong file db.enum.84473085):
IN NS dns1 dns IN A 10.206.33.201
@ IN NAPTR 101 10 "u" "sip" "!^.*$!sip:dongpd@sip1.cdit.com.vn!"
@ IN NAPTR 101 10 "u" "sip" "!^.*$!sip:anhnv@sip1.cdit.com.vn!"
@ IN NAPTR 101 10 "u" "sip" "!^.*$!sip:anhnv@sip1.cdit.com.vn!"
@ IN NAPTR 101 10 "u" "sip" "!^.*$!sip:dunghd@sip1.cdit.com.vn!"
@ IN NAPTR 101 50 "u" "sip" "!^.*$! sip:hoangcuong@sip1.cdit.com.vn!"
@ IN NAPTR 101 10 "u" "sip" "!^.*$!sip:testuser@sip1.cdit.com.vn!"
Như ta thấy ở trên, mỗi đầu số sẽ được phân tách bằng kí hiệu $ORIGIN, và sau đó là các Contact tương ứng được bắt đầu bằng IN NAPTR.
Ví dụ từ đoạn thông tin như sau:
Nghĩa là đầu số 8447308505 sẽ có 2 contact với dạng là tel, gồm 2 số:
Nội dung của file thông tin cấu hình này được thực hiện thông qua việc đồng bộ dữ liệu từ CSDL khách hàng (được thực hiện tự động, không phải nhập bằng tay) thông qua 1 script viết bằng ngôn ngữ Perl Công việc của script đồng bộ này như sau:
Kết nối tới CSDL khách hàng (được trình bày trong phần tiếp theo), lấy ra
2 thông tin là số thuê bao và các contact tương ứng.
Mở file db.enum.84473085 ra, thực hiện ghi các thông tin mới vào.
III.2.3 Kiểm tra cấu hình
Sau khi thực hiện cấu hình như trên, bước tiếp theo là kiểm tra xem hệ thống Name Server có hoạt động như mong muốn hay không Ở đây em sử dụng hàm dig
(có sẵn trong hệ điều hành Linux).
Nếu hệ thống hiển thị các thông tin trả về như hình sau, nghĩa là đã sẵn sàng đi vào hoạt động Thành phần Name Server đã được cấu hình thành công.
Hình III.17Kiểm tra cấu hình Name Server
Portal quản lý cơ sở dữ liệu
Sau khi cấu hình xong Name Server, trong mục này sẽ trình bày việc thực hiện xây dựng Portal (dưới dạng Web) quản lý CSDL khách hàng cho hệ thống Đây là nơi quản lý tập trung toàn bộ dữ liệu cho cả hệ thống, gồm các thông tin đăng nhập, cấp phát đầu số cũng như các contact của các user Mọi thao tác với CSDL Enum sẽ được thông qua Portal này.
Portal được xây dựng trên nền PHP, với CSDL là MySQL Ngoài ra, với các tác vụ bên dưới có sử dụng thêm CSDL LDAP và ngôn ngữ Perl.
Sẽ có 2 đối tượng sẽ sử dụng dữ liệu trong ENUM:
Đối tượng quản lý: gồm nhà quản lý hệ thống và bản thân chủ sở hữu của mỗi đầu số ENUM Các đối tượng này sẽ quản lý CSDL của mình thông qua giao diện Web của hệ thống.
Đối tượng sử dụng: gồm các ứng dụng sẽ lấy thông tin từ CSDL ENUM để phục vụ nhu cầu nghiệp vụ của mình.
Các thay đổi sẽ được đồng bộ với CSDL trong LDAP Từ LDAP, qua một script, CSDL sẽ được đồng bộ với Name Server Ngoài ra các thông tin xác thực người dùng có thể được đồng bộ với các thành phần hỗ trợ dịch vụ ENUM.
III.3.1.1 Yêu cầu đặt ra
Hệ thống CSDL Enum được xử lý thông qua giao diện Web Dữ liệu ở đây gồm
2 phần chính: thông tin về User (Name, Password…), thông tin sẽ được lưu trong Name Server (gồm Enum Number và các Contact tương ứng).
Có 2 đối tượng sử dụng Website: User (khách hàng) và Admin (nhà quản trị). Thông qua Website, cho phép nhà quản trị và người sử dụng có thể quản lý được dữ liệu của mình
Với người dùng đã có tài khoản trong hệ thống, có thể đăng nhập vào để quản lý các thông tin của bản thân User đó như: Name, Password, các Contact…
Với người dùng chưa có tài khoản trong hệ thống, có thể đăng kí tài khoản mới. Tài khoản này sẽ được cho vào hàng đợi chờ quản trị kích hoạt Sau khi được kích hoạt, người dùng này mới có thể đăng nhập vào tài khoản của mình. Ở đây, phải đơn giản hóa cấu trúc các Contact với User dưới dạng dễ dàng thao tác, sau khi User thao tác xong với các Contact, khi lưu lại CSDL sẽ chuyển về dạng chuẩn của bản tin NAPTR.
Với nhà quản trị, sẽ có một giao diện quản lý riêng, với những công cụ giúp quản lý được dữ liệu cho cả hệ thống ENUM Cụ thể ở đây, nhà quản trị có thể:
Duyệt danh sách theo các phân nhóm người dùng (Admin và User)
Tìm kiếm theo các tiêu chí (Username, Name, Enum Number…)
Thêm sửa xóa các tài khoản.
Tất cả mọi thao tác trong hệ thống đều được ghi log lại
Do thông tin cần lưu trữ gồm 2 thành phần như đã nêu trên, nên trong giai đoạn thử nghiệm sẽ sử dụng 2 CSDL:
MySQL: là hệ quản trị CSDL cho Website
LDAP: các thông tin thay đổi từ website (ở đây chỉ quan tâm tới các Contact) sẽ được cập nhật vào LDAP, rồi từ đây sẽ được đồng bộ với Name Server (Enum Database).
Hình III.18Mô hình vật lý tổ chức dữ liệu trong hệ thống
III 3.1.2.1 Các tác nhân tham gia vào hệ thống:
+ Enum Custumer: người có tài khoản trong hệ thống, đăng nhập vào để quản lý các Contact của mình.
+ Administrator: người có quyền quản trị với hệ thống: quản lý các User (thêm sửa xóa các User và các thông tin của User), cấp phát quyền.
III 3.1.2.2 Các thông tin với mỗi tài khoản
Với mỗi tài khoản sẽ bao gồm các thông tin sau:
Username (tên đăng nhập vào hệ thống)
Website chia làm 2 modul chính: modul cho User và modul cho Admin.
+ Quản lý các Contact của bản thân tài khoản đó
Từ các chức năng trên, chia modul User thành các modul nhỏ hơn như sau:
Register: đăng kí tài khoản
Add Contact: thêm mới 1 Contact
Edit User (Edit tất cả các thông tin của User, trừ Enum Number, Username không thể thay đổi)
Write log: ghi log thông tin truy nhập
+ Kích hoạt tài khoản đang chờ đăng kí
+ Quản lý tất cả các tài khoản trong hệ thống (thêm sửa xóa các User và các Contact của User)
+ Tìm kiếm (theo các tiêu chí khác nhau)
+ Cấp quyền cho các User
Từ các chức năng trên, chia modul User thành các modul nhỏ hơn như sau:
Create User: Tạo mới User
Active User: Kích hoạt tài khoản trong hàng đợi
Edit User: Chỉnh sửa các thông tin của 1 User
Search: Tìm kiếm theo các tiêu chí: Username, Name, Enum Number
Write log: ghi log thông tin đăng nhập, thông tin chỉnh sửa các User
III 3.3.1.1 Giao diện đăng nhập
Nếu User login thành công, sẽ cho phép vào được trang quản trị acount của mình.Nếu login sai, hiển thị thông báo lỗi và yêu cầu nhập lại.
Ngoài ra tại đây, User có thể vào mục Register để đăng kí tài khoản, và tài khoản này sẽ có tác dụng khi được Admin kích hoạt.
III 3.3.1.2 Giao diện quản lý của User
Tại đây User có thể thực hiện thêm mới các Contact Việc thêm mới 1 Contact yêu cầu phải nhập đủ 3 trường: Order, Service, Contact và nhấn nút Add.
III 3.3.1.3 Giao diện Edit thông tin
Tại đây, User có thể thay đổi Password, Name và các Contact của mình (thứ tự, nội dung Contact…) Có một số mục User không được phép thay đổi: Username, Type, ENUM Number.
III 3.3.2.1 Giao diện quản lý
Chỉ đăng nhập với tài khoản Admin, người đăng nhập mới vào được trang quản trị này Ta có thể thấy một vài mục trong trang này:
Mục List by: cho phép hiển thị các User phân theo Type: Admin hay User.
Mục Search: cho phép tìm kiếm theo 1 trong 4 tiêu chí: Username, Name,
Mục hiển thị danh sách các User: Admin có thể Edit hay xóa các User bằng cách nhấn vào biểu tượng tương ứng trong mục Action.
Ngoài ra còn một số mục như: Create user, Active… (sẽ trình bày ở mục tiếp theo).
III 3.3.2.2 Giao diện thêm mới tài khoản Để thêm mới 1 tài khoản vào hệ thống, Admin cần nhập các thông tin sau:
Username: yêu cầu mang tính duy nhất trong CSDL
Type: cho phép chọn Acount mới này là User hay Admin
ENUM number: cũng yêu cầu phải có tính duy nhất trong toàn hệ thống.
III 3.3.2.3 Giao diện Edit User
Tại đây, Admin có thể Edit các thông tin của User như: Password, Name, Type,Contact, thêm mới contact…
ENUM Client
Sau khi xây dựng được CSDL cho hệ thống ENUM, cấu hình xong Name Server, vấn đề tiếp theo là làm sao sử dụng được dữ liệu trong hệ thống này Trong phạm vi một báo cáo Đồ án tốt nghiệp, em đã xây dựng demo một chương trình cho phép lấy các thông tin từ hệ thống ENUM và phân tích – ENUM Client.
Về nguyên tắc chung, 1 thực thể nào đó muốn có thông tin từ hệ thống phải gửi yêu cầu tới hệ thống và phân tích bản tin trả về Do vậy, để kiểm tra cũng như đặt cơ sở ban đầu cho các ứng dụng sau này, em xây dựng chương trình Client Enum (CeNum).
Chương trình được viết trên nền Net Framework 2.0 Gồm 2 module: thực hiện truy vấn bản tin NAPTR và đánh giá hiệu năng phản hồi của hệ thống.
III.4.2 Các tính năng của chương trình
Chương trình có 2 module chính: là ENUM Client và Test Tool.
ENUM Client có chức năng truy vấn các bản tin và hiển thị kết quả ENUM Client không chỉ có chức năng truy vấn các bản tin NAPTR, ngoài ra có thể truy vấn các loại bản tin khác như: A, MX, PTR, NS, CNAME, SOA. Để có thể thực hiện 1 truy vấn, cần cung cấp 3 thông số sau: DNS Server, số ENUM cần truy vấn và loại bản tin (Type).
Kết quả trả về sẽ gồm các thông tin:
Thời gian truy vấn (tính theo ms)
Số lượng bản tin trả về
Nội dung các bản tin
Test Tool có chức năng kiểm tra khả năng Response của Server bằng cách mô phỏng nhiều truy vấn 1 lúc tới Server. Để thực hiện truy vấn cần cung cấp thêm 1 thông tin so với ENUM Client là số lượng Thread cần mô phỏng
Kết quả trả về là tổng thời gian mà Server Response lại ứng với mỗi query gửi đến.
III.4.3 Cấu trúc chương trình
2 module tương ứng được đặt vào 2 Tab Cấu trúc chung của chương trình là thu thập các thông số Các action sẽ được thực hiện khi người dùng nhấn vào Truy vấn hoặc Test
Chương trình sử dụng bộ thư viện được phát triển bởi hãng Lumisoft Bộ thư viện bao gồm:
Các file mô tả các loại bản tin: A, NAPTR, SOA, MX…
Lớp DNS_Client, chứa các phương thức và thuộc tính để xử lý phía Client: o Đóng gói bản tin o Gửi nhận bản tin o Phân tích bản tin trả về o Tính toán thời gian Response từ Server (tự viết thêm)
III.4.3.2 Cơ chế thực hiện
2 module được thực hiện chung một cơ chế Điều khác biệt là Enum Client chỉ đóng gói và gửi đi 1 bản tin, hiển thị bản tin trả về, còn Test Tool đóng gói và gửi đi cùng lúc nhiều bản tin để tính tổng thời gian Response.
III.4.4.1 Đóng gói bản tin
Dựa vào 2 tham số người dùng nhập vào: loại bản tin và Enum Number (đối với trường hợp loại bản tin là NAPTR) Sau khi đã xác nhận được 2 thông số này, hệ thống tiến hành đóng gói bản tin theo định dạng tương ứng của bản tin.
Sau khi tiến hành đóng gói, hệ thống dựa vào thông số DNS Server để tiến hành kết nối tới Server, nếu thành công sẽ tiến hành gửi bản tin tới Server này (cổng 53). Ngay tại lúc này sẽ bắt đầu tính thời gian Response Chờ đợi phản hồi từ Server.
III.4.4.3 Nhận gói tin Đặt time out là 10ms Gói tin nhận về ở được đưa vào mảng byte với kích thước
1024 Byte Mảng này sẽ được phân tích đưa về các trường, và hiển thị lên màn hình kết quả.
Ứng dụng triển khai thử nghiệm dịch vụ ENUM
Mô tả chung
Sau khi xây dựng xong hệ thống quản lý dữ liệu cho hệ thống ENUM ở chương III (phần ENUM cơ sở), trong chương này sẽ trình bày về phần hỗ trợ dịch vụ
ENUM Giải pháp ứng dụng dịch vụ ENUM được sử dụng ở đây là hệ thống Asterisk Mô hình kết nối tổng quát của Asterisk kết nối tới hệ thống ENUM như sau:
Hình IV.21Mô hình tổng quát hệ thống Asterisk
Như ta thấy trong hình trên Asterisk với vai trò là bên cung cấp dịch vụ (cụ thể hơn là một tổng đài PBX) sẽ thực hiện kết nối tới hệ thống ENUM, khai thác và xử lý các thông tin, điều khiển các cuộc gọi từ các bản tin trả về từ ENUM
Yêu cầu đối với hệ thống Asterisk: Người dùng thông qua mạng Internet kết nối tới hệ thống Asterisk Sau đó khi thực hiện cuộc gọi tới một số ENUM, Asterisk sẽ tiến hành truy vấn DNS tới Name Server lấy về các bản tin và thực hiện thiết lập cuộc gọi (tùy theo kịch bản định sẵn của người dùng đăng kí) Cuộc gọi ở đây có thể là ra mạng IP hoặc mạng PSTN (tùy vào Type của Contact lấy về).
Theo mặc định ban đầu, Asterisk khi cài lên sẽ không thể kết nối ngay tới hệ thống ENUM Trong chương này, em sẽ mô tả cách thức cấu hình cũng như hiệu chỉnh để Asterisk có thể kết nối tới hệ thống ENUM Server cũng như thực hiện các tác vụ cần thiết với dữ liệu nhận được từ ENUM.
Giới thiệu về Asterisk
Asterisk là hệ thống chuyển mạch mềm, được viết bằng ngôn ngữ C chạy trên nền Linux Chức năng chính của Asterisk là thực hiện các tính năng của một tổng đài PBX Là một phần mềm mang tính cách mạng, tin cậy, mã nguồn mở và miễn phí, nó có thể biến một chiếc PC rẻ tiền thông thường chạy Linux thành một hệ thống điện thoại doanh nghiệp mạnh mẽ Asterisk ngoài việc là một bộ công cụ mã nguồn mở cho các ứng dụng thoại, nó còn là một Server xử lý cuộc gọi đầy đủ chức năng.
Hình IV.22Mô hình kết nối thông dụng IP-PSTN qua Asterisk
Asterisk ra đời năm 1999 bởi Mark Spencer Anh viết phần mềm này ban đầu dùng để hỗ trợ cho công ty của mình trong việc liên lạc đàm thoại Nhưng với tính hữu dụng và khả năng mở rộng của nó, Asterisk ngày càng được sử dụng rộng rãi.Asterisk ban đầu được phát triển trên GNU/Linux nên x86, nhưng giờ đây nó có thể được biên dịch và chạy trên nhiều nền tảng hệ điều hành khác nhau: OpenBSD,Mac, Microsoft Window…
Cài đặt Asterisk
IV.3.1 Lắp đặt phần cứng
Card giao tiếp mạng: Kết nối Server với mạng IP
Card giao tiếp analog: Kết nối Server với mạng PSTN Card này có hai loại o FXO – Foreign eXchange Office – Kết nối tới nhà cung cấp PSTN o FXS – Foreign eXchange Station – Kết nối các điện thoại PSTN vào PBX
Hình IV.23Mô hình kết nối phần cứng Asterisk server
Hiện tại em đang sử dụng 01 card TDM400B (4 port FXO) để kết nối với 3 line điện thoại cố định tới nhà cung cấp dịch vụ VNPT (với các đầu số 045770491,
IV.3.2 Cài đặt phần mềm
Nếu như trước đây, để có thể đưa vào sử dụng hệ thống Asterisk, cần cài đặt rất nhiều các gói khác nhau của nhiều nguồn (như gói Asterisk, Zaptel…), thì hiện tại với sự ra đời của Trixbox đã tích hợp tất cả trong 1 Tất cả những gì cần làm là cài bộ Trixbox lên, thực hiện chỉnh sửa các tham số cấu hình.
Các thành phần chính trong Trixbox:
Apache, PHP, MySQL: phục vụ cho Web Server.
FreePBX: cho phép thực hiện các thao tác cấu hình cho Asterisk Server thông qua giao diện Web.
Ngoài ra còn một số công cụ cho phép quản trị và vận hành hệ thốngTuy được đóng gói thành một sản phẩm hoàn chỉnh, nhưng thực chất lõi là sự vận hành của Asterisk Server.
Kiến trúc Asterisk
Hình IV.24Mô hình kiến trúc của Asterisk
IV.4.1 Một số module quan trọng trong hoạt động của Asterisk
Dynamic Module Loader : được kích hoạt khi khởi động hệ thống
Asterisk, thực hiện nạp driver cho thiết bị, nạp các kênh giao tiếp, các Format, Codec và các ứng dụng liên quan, đồng thời các hàm API cũng được liên kết nạp vào hệ thống.
PBX Switching Core : sau khi Dynamic Module Loader được kích hoạt,
PBX Switching Core chuyển sang trạng thái sẵn sàng hoạt động, với chức năng chuyển mạch cuộc gọi (các cuộc gọi được chuyển mạch tùy theo kế hoạch quay số - Dial Plan).
Application Launchar : có chức năng rung chuông thuê bao, quay số, định hướng cuộc gọi, kết nối tới hộp thư thoại…
Scheduler and I/O Manager : đảm nhiệm các ứng dụng nâng cao, các chức năng được phát triển bởi cộng đồng phát triển Asterisk.
Codec Translator : xác nhận các kênh nén dữ liệu ứng với các chuẩn khác nhau có thể kết hợp liên lạc được với nhau.
IV.4.2 Các API chính trong Asterisk
Asterisk Application API : Bao gồm tất cả các ứng dụng được thực thi trong hệ thống Asterisk như voicemail, callerID…
Codec Translator API : gồm các hàm đảm nhận thực thi và giải nén các chuẩn khác nhau như G711, G729, GMS…
Asterisk Channel API : giao tiếp các kênh liên lạc khác nhau, kết nối các cuộc gọi từ nhiều chuẩn khác nhau như: SIP, IAX, H232, Zaptel…
Asterisk File Format API : Asterisk Channel API Asterisk tương thích với việc xử lý các loại file có định dạng khác nhau như mp3, wav, gsm…
Ngoài ra Asterisk còn có các thư viện AGI (Asterisk Gateway Interface), cho phép kích hoạt các ứng dụng bên ngoài, cho phép viết kịch bản phức tạp với một số ngôn ngữ như PHP và Perl Chính nhờ có các thư viện AGI này mà khả năng tùy biến của Asterisk là rất lớn
Một số khái niệm khi sử dụng Asterisk
Khái niệm Trunk ở đây được sử dụng như là 1 đường trung kế khi thực hiện một cuộc gọi ra bên ngoài hệ thống Ví dụ khi thực hiện một cuộc gọi ra mạng PSTN, Asterisk sẽ định tuyến cuộc gọi ra 1 đường ZAP Trunk nào đó…
Phiên bản Asterisk vào thời gian thử nghiệm hệ thống là 1.4.18, hỗ trợ các trunk:
Zap: Giao tiếp qua card FXO để kết nối đến nhà cung cấp thoại Ví dụ khi sử dụng card với 4 khe FXO, thì với mỗi cuộc gọi qua 1 line FXO sẽ thông qua
IAX2 (Inter-Asterisk eXchange): là giao thức thực hiện trao đổi thông tin giữa các Asterisk Server.
SIP (Session Initiation Protocol): thường là giao thức được sử dụng tại VOIP phone kết nối tới Asterisk Server, bản thân Sip không truyền Media mà sử dụng RTP để truyền.
ENUM: khi có cuộc gọi ra sử dụng trunk này, sẽ thực hiện truy vấn ENUM để lấy ra các contact và thực hiện cuộc gọi.
DUNDi (Distributed Universal Number Discovery): cũng là giao thức để trao đổi giữa các Asterisk server nhưng ở đây các Asterisk Server đóng vai trò như 1 Phone Book, khi 1 server nào đó không biết định tuyến cuộc gọi đi đâu, sẽ hỏi các Ast Server khác về định tuyến này.
IV.5.2 Extension Để sử dụng được hệ thống, cần phải có 1 tài khoản (extension) gồm username và password, ngoài ra còn kèm theo một vài thông tin khác như: canreinvite, type, nat…
Khái niệm extension ở đây tương tự như 1 acount, trong đó tên của extension sẽ là số để thực hiện cuộc gọi trong hệ thống.
Việc tiếp theo là cần phải có 1 Soft Phone được cài đặt phía Client, sử dụng Soft Phone này với acount được cấp, người dùng có thể đăng nhập và tiến hành các cuộc gọi (tùy theo cấu hình của nhà quản trị: Dial Plan).
Có thể coi dialplan chính là trái tim của hệ thống Asterisk Nó sẽ quyết định Asterisk server làm gì với các cuộc gọi đến, các số gọi đi Thực chất, dialplan chính là một dãy các chỉ thị mà Asterisk server thực hiện theo ứng với một điều kiện đầu vào tương ứng với số gọi đi hoặc đến Các chỉ thị này được đặt trong file cấu hình extension.conf và các file include liên quan được chỉ ra trong file extension.conf.Kịch bản cuộc gọi trong Asterisk server được phân thành các vùng khác nhau được gọi là context Mỗi người dùng hoặc các phần tử hệ thống thuộc các context khác nhau thực hiện theo các chỉ thị của context đó Trong hệ thống thử nghiệm này, em sử dụng hai context sau:
Internal: Cho các thiết bị nối vào cổng FXS (sẽ trình bày trong mục sau) và các thuê bao SIP, IAX gọi lẫn nhau và gọi qua PSTN
Incoming: Cho kết nối gọi vào từ mạng PSTN
Ngoài ra, hệ thống còn một context chung chứa các tham số tổng quát đó là general Mỗi context sẽ được đặt trong một vùng bắt đầu bằng ký hiệu tên context trong cặp ngoặc [], ví dụ [incoming] Dưới đây là khai báo kịch bản cuộc gọi phục vụ mục tiêu sau:
Cuộc gọi đến từ mạng PSTN sẽ được chuyển đến địa chỉ thuê bao SIP datvt
Cuộc gọi đến các thuê bao SIP sẽ chuyển tới địa chỉ tương ứng
Cuộc gọi đến các thuê bao mạng PSTN sẽ bắt đầu với đầu số 9
File cấu hình extension.conf như sau:
[general] static=yes writeprotect=no clearglobalvars=no userscontext=internal
[incoming] exten => s,1,Dial(SIP/huydd)
[internal] exten => _[a-z].,1,Dial(SIP/${EXTERN},30) exten => _[a-z].,1,Hangup() exten => _9.,1,Dial(Zap/g1/${EXTERN:1}) exten => _9.,2,Hangup() Đến đây ta có thể sử dụng softphone cũng như điện thoại để kiểm tra và thử nghiệm hệ thống.
Trên đây là ví dụ đơn giản về việc thực hiện 1 cuộc gọi từ mạng IP vào IP và từ
IP sang PSTN Ngoài ra với Dial Plan ta có thể tạo một Voice Menu - IVR, cho phép đầu cuối PSTN thực hiện chọn xem gọi tiếp tới tài khoản nào trong hệ thống (thông qua bấm số).
[incoming] exten => s,1,Answer( ) exten => s,2,Background(enter-ext-of-person) exten => 101,1,Dial(SIP/datvt,10) exten => 101,2,Playback(vm-nobodyavail) exten => 101,3,Hangup( ) exten => 101,102,Playback(tt-allbusy) exten => 101,103,Hangup( ) exten => 102,2,Playback(vm-nobodyavail) exten => 102,3,Hangup( ) exten => 102,102,Playback(tt-allbusy) exten => 102,103,Hangup( ) exten => i,1,Playback(pbx-invalid) exten => i,2,Goto(incoming,s,1) exten => t,1,Playback(vm-goodbye) exten => t,2,Hangup( )
Trong ví dụ trên, khi từ mạng PSTN hoặc IP thực hiện cuộc gọi vào các tài khoản trong hệ thống, sẽ yêu được yêu cầu nhập tiếp số extension cần gặp Ở đây, nếu nhấn tiếp số 101, cuộc gọi sẽ được chuyển tiếp tới tài khoản của datvt, nếu nhấn
102, cuộc gọi sẽ chuyển tới tài khoản của huydd.
Cấu trúc thư mục tập tin cấu hình
Để hệ thống Asterisk hoạt động yêu cấu rất nhiều các file cấu hình Sau đây là 1 số các file (thư mục) cấu hình chính trong Asterisk:
/etc/asterisk/extensions.conf: chứa nội dung các context
/etc/asterisk/sip.conf: chứa thông tin đăng nhập của các tài khoản
/var/lib/asterisk: thư việc các AGI, file âm thanh…
/usr/lib/asterisk/modules: chứa các module động của Asterisk server.
Các module này sẽ được nạp khi chạy hoặc khởi động lại dịch vụ
Cấu hình Asterisk
IV.7.1 Cấu hình thời gian thực
Theo mặc định, thông tin cấu hình trong Asterisk được lưu trữ trong file dạng text như sip.conf, extension.conf… Cách thức này giúp Asterisk xử lý nhanh chóng các yêu cầu Tuy nhiên với cách lưu thông tin “cứng” như vậy sẽ có những hạn chế như: khi có một thay đổi nào đó, muốn thay đổi đó có tác dụng cần phải reload lại Asterisk (lệnh CLI>reload); hoặc rất dễ có sai sót cú pháp trong khi thực hiện cấu hình…
Một giải pháp đưa ra là thực hiện kiến trúc thời gian thực trong Asterisk (Asterisk
RealTime Architecture) Với kiến trúc thời gian thực, thay vì lưu trên tập tin dạng text, các thông tin cấu hình sẽ được lưu vào Database (ví dụ như MySQL) Việc này sẽ tiết kiệm chi phí tài nguyên hệ thống khá đáng kể với một lượng User lớn (không cần phải nạp tất cả các User cùng một lúc ngay khi khởi động Asterisk).
Ngoài việc tiết kiệm được chi phí tài nguyên hệ thống, với mục đích tích hợp được vào với hệ thống dịch vụ chung của ENUM, kiến trúc thời gian thực giúp đồng nhất về mặt dữ liệu người dùng giữa CSDL người dùng trong ENUM và Asterisk
Cụ thể, khi có một yêu cầu liên quan tới 1 extension nào đó Asterisk quản lý (chẳng hạn khi 1 extension thực hiện cuộc gọi), Asterisk sẽ thực hiện việc truy vấn tới Database để lấy thông tin về extension đó (các thông tin lấy về cũng tương tự như lấy trong file sip.conf) Asterisk sẽ nạp cả dòng (record) chứa extension vào bộ nhớ, đồng thời tiếp tục thực hiện hàm ứng dụng Application đã được khai báo trong Dial Plan, cuộc gọi được thiết lập Khi 1 trong 2 bên đầu cuối phát lệnh Hangup, Asterisk sẽ phát tín hiệu kết thúc kênh truyền thông và xóa Record đã nạp vào bộ nhớ.
/etc/asterisk/res_mysql.conf: trỏ tới CSDL cần thực hiện Realtime
/etc/asterisk/extconfig.conf: xác định bảng nào trong CSDL cần đọc thông tin Thêm vào nội dung sau:
Sipusers=>mysql,asteriskrealtime,sip_buddies
Sippeers=>mysql,asteriskrealtime,sip_buddies
Sau khi cấu hình như trên, Asterisk lúc này sẽ thực hiện xử lý song song trên 2 nguồn dữ liệu: dữ liệu người dùng được lưu trong file sip.conf và dữ liệu người dùng được lưu trong CSDL Khi không tìm thấy trong sip.conf, Asterisk sẽ thực hiện tìm kiếm trên CSDL.
Quản lý người dùng bằng Trixbox (file sip.conf):
Thông qua giao diện Web của Trixbox ta có thể quản lý các User mà không phải trực tiếp can thiệp vào file sip.conf Sau khi Save lại trên Web, thông tin trong file sip.conf sẽ được đồng bộ lại.
Vấn đề tiếp theo là đồng bộ dữ liệu từ phần ENUM cơ sở sang dữ liệu của Asterisk Việc này được thực hiện thông qua một đoạn script viết trên PHP, dữ liệu cần đồng bộ ở đây là username và password, sau đó sẽ thêm vào các thông tin cần thiết cho phù hợp với định dạng của Asterisk Theo cấu hình hiện tại, hệ thống sẽ tự động đồng bộ dữ liệu sau 5 phút.
IV.7.2 Cấu hình thực hiện định tuyến
Việc cấu hình kết nối tới mạng PSTN hay IP hoàn toàn được cấu hình trong file extension_custom.conf:
#include "/etc/asterisk/services/FirstNumber.conf"
#include "/etc/asterisk/services/OneNumber.conf"
[ext-local-custom] switch => Realtime/@
[from-internal-custom] switch => Realtime/@
;== Call to ENUM ====================================== exten => _73085XX,1,Macro(dial-enum,${EXTEN}) exten => _73085XX,n,Hangup()
;== Call Direct Mobile ================================ exten => _0XXXXXXXXX,1,Macro(dial-dr-mobile,${EXTEN})
;== Call Direct PSTN ================================== exten => _XXXXXXX,1,Macro(dial-dr-pstn,${EXTEN})
;== Macro thuc hien goi truc tiep vao may co dinh============= [macro-dial-dr-pstn] exten => s,1,Set(DIAL_NUMBER=${ARG1}) exten => s,n,Set(MOHCLASS=${IF($["x${MOHCLASS}"="x"]?datvt-music:$ {MOHCLASS})}) exten => s,n,Macro(user-callerid,SKIPTTL,) exten => s,n,Set(_NODEST=) exten => s,n,Macro(record-enable,${AMPUSER},OUT,) exten => s,n,Macro(dialout-trunk,1,${DIAL_NUMBER},,) exten => s,n,Macro(dialout-trunk,2,${DIAL_NUMBER},,) exten => s,n,Macro(dialout-trunk,3,${DIAL_NUMBER},,) exten => s,n,Macro(outisbusy,)
;== Macro thuc hien goi truc tiep vao Mobile =============
[macro-dial-dr-mobile] exten => s,1,Set(DIAL_NUMBER=${ARG1}) exten => s,n,Noop(DatVT: Call DIRECT to MOBILE-FXO) exten => s,n,Macro(dialout-trunk,1,${DIAL_NUMBER},,) exten => s,n,Macro(dialout-trunk,3,${DIAL_NUMBER},,) exten => s,n,Macro(dialout-trunk,2,${DIAL_NUMBER},,) exten => s,n,Hangup()
;== Macro thuc hien cuoc goi toi ENUM ===================
[macro-dial-enum] exten => s,1,Set(DIAL_NUMBER=${ARG1}) exten => s,n,AGI(get_service.pl, ${DIAL_NUMBER}) exten => s,n,Macro(${SERVICE}, ${DIAL_NUMBER}) exten => s,n,Hangup()
Như trong nội dung của file cấu hình, sẽ thực hiện định tuyến cuộc gọi theo các đường khác nhau tùy theo đầu số mà người dùng thực hiện Cụ thể như sau:
Khi người dùng quay số với định dạng _XXXXXXX (7 chữ số - nội hạt) hoặc _0XXXXXXXXX (thuê bao di động) sẽ thực hiện việc gọi tới Macro [dial-dr- pstn] hoặc [dial-dr-mobile] xử lý Các macro này sẽ thực hiện gọi tới 3 trunk Zaptel với các số đã được quay, từ đây cuộc gọi sẽ được route sang mạng PSTN.
Khi người dùng quay số với định dạng _73085XX, hệ thống sẽ triệu gọi tới Macro [dial-enum] Việc xử lý của Macro này cụ thể sẽ như sau: o Lưu lại số mà người dùng gọi, đưa vào làm tham số để gọi tới hàm Get_service (viết bằng Perl) o Hàm get_serice thực hiện truy vấn tới MySQL của phần ENUM cơ sở, lấy ra dịch vụ mà người dùng kích hoạt o Sau khi xác định được Service của người bị gọi đang kích hoạt, sẽ thực hiện gọi tới Macro tương ứng của Service đó với tham số đầu vào là số cần gọi Tại đây sẽ thực hiện truy vấn tới ENUM lấy ra các Contact Tùy theo là dịch vụ gì mà thực hiện cuộc gọi tới các Contact này. o Cuộc gọi được thiết lập.
IV.7.3 Cấu hình xử lý thông tin ENUM
Qui tắc chung của phần xử lý thông tin ENUM là thực hiện query với bản tin NAPTR tới Name Server, lấy các contact về, cho vào 1 mảng Thực hiện vòng lặp để truy xuất tới từng phần tử của mảng này (từng Contact), thông tin được lọc tách để lấy ra các dịch vụ mà người dùng đăng kí Rồi từ đó sẽ có các cách xử lý khác nhau đối với từng dịch vụ.
Cách thức truy vấn bản tin NAPTR tới Name Server được thực hiện như sau: exten => s,1,Set(DIAL_NUMBER=${ARG1}) exten => s,n,Set(E164NETWORKS=4.4.8.e164.arpa-e164.arpa-e164.info- e164.org) exten => s,n,GotoIf($["${DIAL_NUMBER:0:1}" = "+"]?begin) ; Skip next line if it already is prefixed by a plus exten => s,n,Set(DIAL_NUMBER=+${DIAL_NUMBER}) ; Add a plus to the start, becasue ENUMLOOKUP needs it
; Search all entries and all naptr records
; [BEGIN LABEL HERE] exten => s,n(begin),GotoIf($["${LEN(${E164NETWORKS})}" < "2"]?end)
; There are, take the first one exten => s,n,Set(ENUMNET=${CUT(E164NETWORKS,,1)})
; And trim it from the front of E164NETWORKS exten => s,n,Set(E164NETWORKS=${CUT(E164NETWORKS,,2-)})
; Iterate through, in order priority, the returned records exten => s,n,Set(ENUMCOUNT=${ENUMLOOKUP(${DIAL_NUMBER},ALL,c,,$
; Check the next network exten => s,n,GotoIf($["${ENUMCOUNT}" = "0"]?begin) exten => s,n,GotoIf($["x${ENUMCOUNT}" = "x"]?begin)
;Return Array Contacts exten => s,n(startloop),Set(ENUM=${ENUMLOOKUP(${DIAL_NUMBER},ALL,,
${ENUMPTR},${ENUMNET})}) exten => s,n,GotoIf($[${LEN(${ENUM})} = "0"]?continue) exten => s,n,GotoIf($["${ENUM:0:3}" = "iax"]?iaxuri) exten => s,n,GotoIf($["${ENUM:0:3}" = "sip"]?sipuri) exten => s,n,GotoIf($["${ENUM:0:3}" = "tel"]?teluri)
;exten => s,n,GotoIf($["${ENUM:0:4}" = "mail"]?mailuri)
;[CONTINUE LABEL HERE] exten => s,n(continue),Set(ENUMPTR=$[${ENUMPTR} + 1]) exten => s,n,GotoIf($[${ENUMPTR} > ${ENUMCOUNT}]?begin)
; OK If we're here, we've still got some enum entries to go through Back to
; the start with you! exten => s,n,Goto(startloop)
; If the prefix is 'sip:'
; PROCESS WITH TEL Đầu tiên, sẽ thực hiện lưu lại số người dùng gọi Sau đó thiết lập 1 array các mạng để truy vấn NAPTR với các hậu tố thêm vào.
Bước tiếp theo, sử dụng hàm ENUMLOOKUP chứa trong file
Thử nghiệm với hệ thống
Đến đây, khi các thành phần trong hệ thống đã được xây dựng xong Vấn đề tiếp theo là tiến hành bài đo để kiếm định sự hoạt động thông suốt trong toàn hệ thống.
Bài đo sẽ được thể hiện thông qua 1 chu trình từ lúc người sử dụng xin đăng kí sử dụng dịch vụ cho tới khi sử dụng các dịch vụ được cung cấp.
Môi trường thử nghiệm: được thực hiện trên PC cài hệ điều hành Windows XP sp2, trình duyệt Mozilla Firefox 2.11, soft phone eyeBeam 1.3.
IV.8.1 Đăng kí tài khoản
Người dùng thực hiện việc đăng kí bằng việc nhập các thông tin cần thiết và Submit Hệ thống sẽ kiếm tra tính duy nhất trong CSDL với Username và ENUM Number Sau khi các thông tin hợp lệ, dữ liệu mới sẽ được lưu vào trạng thái chờ kích hoạt trong mục Active của module Admin.
Sau khi Admin chấp nhận Active, User sẽ bị loại khỏi danh sách chờ Active, chuyển sang danh sách quản lý chung Từ lúc này User mới sẽ có quyền đăng nhập và sử dụng dịch vụ.
IV.8.2 Quản lý các Contact
Khi đã có thể đăng nhập, việc tiếp theo là User cần cung cấp các Contact của mình với các mức độ ưu tiên.
User có thể chỉnh sửa các Contact bằng cách nhấn vào mục Edit Profiles.
IV.8.3 Đăng kí sử dụng dịch vụ
Như đã thấy trong hình, có nhiều dịch vụ khác nhau như: UMS, One Number, Follow Me, First Number, Call Optimize, Time Routing… Nhưng trong giai đoạn thử nghiệm, chỉ cung cấp dịch vụ là First Number.
Tại một thời điểm, User chỉ được chọn 1 dịch vụ Giả sử ở đây là First Number
Sau khi đã Active dịch vụ, thực hiện cuộc gọi tới số 7308579 từ một thuê bao khác của hệ thống.
Thực hiện thành công cuộc gọi tới số có mức ưu tiên thấp nhất là số di động
IV.8.4 Thay đổi nội dung Contact
Thực hiện thêm mới số điện thoại khác (045770494) với mức ưu tiên thấp hơn. Lúc này trong danh sách sẽ có 2 Contact dạng Tel: số cố định 5770404 và số di động 0988429794 Vẫn thiết lập dịch vụ là First Number Cần kiểm tra xem khi quay số gọi tới 7308579, cuộc gọi có được route tới số mới này không.
Các bước thực hiện: Đăng nhập hệ thống với tài khoản khác, tiến hành cuộc gọi tới 7308579.
Kết quả: cuộc gọi được thiết lập thành công tới 045770494.
Sau khi được kích hoạt tài khoản trong hệ thống ENUM cơ sở, User có thể đăng nhập vào hệ thống Asterisk thông qua Soft Phone với cùng Username và Password(được thể hiện trong mục IV.7.1 về cấu hình thời gian thực trong Asterisk).
Kết quả: đăng nhập thành công.
IV.8.6 Thực hiện các cuộc gọi
Sau khi đăng nhập, kiểm tra khả năng thực hiện các cuộc gọi VD ở đây thực hiện các cuộc gọi sang các đầu số di động, cố định, enum (như trình bày trong mụcIV.7.2 về cấu hình định tuyến trong Asterisk).
Kết quả: thực hiện cuộc gọi thành công.
IV.8.7 Kết luận sau khi thử nghiệm
Mục đích của các bài đo này nhằm mục đích kiểm tra sự kết hợp giữa các thành phần trong hệ thống chung Từ việc thực hiện thành công các bài đo như trên, có thể khẳng định hệ thống đã đạt được những yêu cầu đã đặt ra trong phần đầu của chương.
Trên đây là thử nghiệm với người dùng thông qua Asterisk có thể sử dụng được dịch vụ ENUM Tuy nhiên hiện tại không thể thực hiện các cuộc gọi từ PSTN tới các đầu số ENUM Sở dĩ như vậy vì hiện tại tại Việt Nam chưa có qui hoạch đầu số cho ENUM, nên việc thử nghiệm tạm thời chỉ diễn ra trong mạng IP.
Giải pháp có thể như sau: Muốn thực hiện cuộc gọi vào từ mạng PSTN, cần được cung cấp một dải số thử nghiệm cho ENUM Các cuộc gọi từ mạng PSTN quay sốENUM, sẽ được các tổng đài route về một Softswitch qua đương E1 Rồi từ đây route tiếp về hệ thống Asterisk, Asterisk thực hiện truy vấn, thiết lập kênh cuộc gọi.