4. 3 Tính năng của Asterisk
CHƯƠNG V: TỔNG ĐÀI OPENSER
5.1 Lịch sử phát triển của SER - OpenSER
SER được phát triển bởi một nhóm các nhà phát triển thuộc Fraunhofer Fokus, một viện nghiên cứu của Đức. Dự án iptel.org đã xây dựng nên một website về dịch vụ thoại trên nền IP và thông tin về dịch vụ thoại trên nền IP. SIP Express Router (SER) được phát triển như một phần trong nỗ lực này, điều hành bởi Jiri Kuthan. SER được xem như một mã nguồn mở (giấy phép đăng ký chính thức GNU, GPL) và website iptel.org vẫn là một địa chỉ tham khảo thông tin về SER, như là những nguồn về SIP và các nguồn liên quan khác ( mặc dù bây giờ không còn được duy trì hoạt động).
Như những kết quả khác của dự án iptel.org, Fraunhofer Fokus đã phát triển iptel.com như một dự án thương mại để xa hơn nữa phát triển SER ( cho cả mã nguồn mở và mục đích thương mại) và để đưa các dịch vụ và các gói phần mềm và những hỗ trợ dựa trên dự án iptel.org được phát triển mã. Iptel.com có trách nhiệm và điều hành chính cho phát triển SER, máy chủ SIP mã nguồn mở. Jiri Kuthan và Jan Janak (kiến trúc sư phần mềm chính) cả hai đều là một phần của nhóm này. Andrei Pelinescu Onciul là một cái tên khác mà cóthể xem trên danh sách mail của serusers.
Một vài nhân viên trước đây trong dự án iptel.org của Fraunhofer đã chuyển sang một dự án về SER mang tính thương mại khác được gọi là Voice System (http://www.voice-system.ro/). Daniel-Constantin Mierla và Bogdan-Andrei Iancu là hai cái tên được biết tới trong danh sách mail của serusers.
Đây là các thành viên được biết tới như là những nhà phát triển lõi được chia thành hai nhóm. Tuy nhiên, tất cả họ đều tham gia vào việc phát triển SER. Hơn
nữa, các công ty khác và những nhà phát triển khác đã tham gia thành một nhóm các nhà phát triển. Vào thời điểm này, SER đã có 25 nhà phát triển đăng ký.
Vào ngày 14 tháng 6 năm 2005, Voice System thông báo rằng họ đã tạo ra Openser. Đây là lý do hình thành website Openser. Lý do của dự án mới này là thiếu quá trình xử lý và phân phối tới dự án SER từ các thành viên trong nhóm SER khác.
Những nhà phát triển SER Voice System nhận thấy iptel.com , người mà đã đưa ra quyết định cuối cùng về mã và các phiên bản, đã bị lỗi trong các phân phối mã mới và cũng quá chậm trong các phiên bản mới của SER. Và sự thông báo này đã làm xôn xao các khách hàng sử dụng SER. Cảm giác chung là các đặc tính mới rất tốt, thật khó để có được mã trong hệ thống phiên bản mã (CVS) bởi vì kết quả chậm trễ từ những nhà phát triển những người đã chấp nhận mã này, nhưng hầu hết mọi người đều cảm thấy nó trở nên dễ dàng hơn cho cộng đồng sử dụng nếu cả sự đảm bảo về chất lượng và ổn định được thấy ở SER có thể được kết hợp trong một dự án tương tự với những mục đích của OpenSER.
5.2 Các đặc tính
Trên cơ sở những tiêu chuẩn mới nhất, SER bao gồm sự hỗ trợ cho chế độ chuyển tiếp, uỷ quyền, đăng ký. Xa hơn nữa nó còn hoạt động như một máy chủ ứng dụng với sự hỗ trợ cho dịch vụ gửi tin nhắn tức thì và presence gồm cả cổng Jabber và 2G/SMS, một ngôn ngữ chính sách điều khiển cuộc gọi, truyền đạt số cuộc gọi, tính toán và những kế hoạch quay số cá nhân, ENUM, những dịch vụ uỷ quyền và xác thực(AAA). SER có thể chạy trên nền Sun/Solaris, PC/Linux,
PC/BSD, IPAQ/Linux và hỗ trợ cả chuẩn Ipv4 và Ipv6. Tính dư cơ sở dữ liệu và miền đa máy chủ cũng được hỗ trợ.
SER đã được nghiên cứu kỹ lưỡng với các mục đích thiết kế sau đây:
• Tốc độ - Với SER, hàng nghìn cuộc gọi trên giây thực hiện được thậm chí trên cả các những nền giá rẻ. Khả năng cạnh tranh này cho phép
tạo nên một mạng giá rẻ và dễ dàng quản lý đối với một số lượng thiết bị được yêu cầu. Khả năng xử lý có thể giải quyết nhiều tác nhân phức tạp một cách dễ dàng. Các tác nhân phức tạp có thể bao gồm nhưng không giới hạn để phá vỡ những sự cài đặt và cấu hình, những ứng dụng lưu lượng cao như dịch vụ presence, sự tái tạo tính dư và cố định việc huỷ dịch vụ.
Tốc độ sẽ đạt được bởi việc tối ưu hoá mã mở rộng và sử dụng mã khách hàng, ANSI C được kết hợp với cấu trúc assembly và việc cải tiến SIP phiên bản mới nhất. Khi được thực thi trên PC Linux dual- CPU, SER có thể xử lý hàng nghìn cuộc gọi trong một giây, dung lượng cẩn để phục vụ báo hiệu cuộc gọi phụ thuộc vào mật độ dân số vùng.
• Tính linh hoạt - SER cho phép người sử dụng nó xác định cách thức hoạt động của nó. Những nhà quản trị có thể viết những kịch bản dạng văn bản mà xác định những quyết định định tuyến SIP, công việc chính của một máy chủ uỷ quyền. Có thể sử dụng kịch bản để cấu hình nhiều tham số và đưa ra logic thêm vào. Ví dụ, các kịch bản có thể xác định cho nó mà mục đích là ghi lại sự định tuyến nên được thực hiện, người mà được xác thực, mà sự thực hiện sẽ được xử lý hoản hảo, những yêu cầu sẽ được uỷ quyền hoặc chuyển tiếp.
• Tính co giãn – tính co giãn của SER cho phép kết nối mã C mới với SER để xác định lại hoặc mở rộng tính logic của nó. Những mã mới có thể được phát triển độc lập trên lõi của SER và liên kết với nó trong thời gian thực hiện. Khái niệm tương tự như khái niệm module được biết đến như ví dụ trong máy chủ Apache Web. Thậm chí những phần chính như là quản lí sự thực hiện đã được phát triển như các module giữ cho lõi SER chặt và cố định.
• Tính di chuyển được - SER được viết trên ANSI C. Nó được kiểm tra kỹ trên PC/Linux và Sun/Solaris. Dẫn tới sự tồn tại của IPAQ/Linux.
• Tính tương kết – SER được giựa trên chuẩn của SIP, nó đã trải qua sự kiểm tra kỹ càng của với những sản phẩm của các nhà cung cấp khác nhau cả trong lab của iptel.org và trong các bài kiểm tra tính tương thích SIP(SIPIT). SER đã cung cấp cho địa chỉ iptel.org 24 giờ một ngày, 365 ngày một năm phục vụ cho nhiều việc thực hiện SIP được sử dụng trên địa chỉ này.
• Điện thế nhỏ - điện thế của lõi khoảng 300K, thêm các module thì có thể lên đến 630K
5.3Kiến trúc OpenSER
OpenSER được xây dựng ở phần đầu của một core đảm nhiệm chức năng cơ bản và điều khiển các bản tin SIP. Các module đảm nhiệm phần lớn các chức năng của OpenSER. Các module OpenSER thể hiện các chức năng của nó trong
OpenSER với các câu lệnh và các tham số mới được sử dụng trong các kịch bản. OpenSER được cấu hình trong một file được gọi là openser.cfg. File cấu hình này điều khiển module nào được load và các tham số tương ứng của nó. Tất cả các luồng SIP cũng được điều khiển trong một vài khối định tuyến (routing block) được định nghĩa trong file. File openser.cfg là file cấu hình chính của OpenSER.
Các phần của file openser.cfg
File openser.cfg có 7 phần logic chính
i. Phần các định nghĩa chung: Phần này thường chứa địa chỉ IP và port để lắng nghe, mức debug, vv. Thiết lập trong phần này ảnh hưởng đến deamon SER.
ii. Phần các module: Phần này chứa một danh sách các thư viện bên ngoài cần thiết để cung cấp các chức năng không được cung cấp bởi core như được lưu ý ở trên. Các module này các file đối tượng chia sẽ (đuôi .so - shared object) và được tải với câu lệnh load-module.
iii. Phần cấu hình module: Nhiều thư viện bên ngoài được chỉ định trong phần các module (ở trên) cần có thiết lập tham số cho các module hoạt động hợp lý. Những tham số module này được thiết lập bằng lệnh modpram, có dạng
modparam(module_name, module_parameter, parameter_value).
iv. Khối định tuyến chính (Main Route Block): Khối định tuyến chính tương tự như hàm main trong lập trình C. Đây là điểm
vào để xử lý một bản tin SIP và điều khiển cách mà mỗi bản tin nhận được được xử lý.
v. Các khối định tuyến phụ (Secondary Route Blocks): Ngoài khối định tuyến chính, openser.cfg có thể chứa các khối định tuyến phụ có thể được gọi từ khối định tuyến chính hay từ các khối định tuyến phụ khác. Một khối định tuyến phụ tương tự như một chương trình con.
vi. Các khối định tuyến trả lời (Reply Route Blocks): Các khối định tuyến trả lời có thể được sử dụng để điều khiển trả lời đến các bản tin SIP. Thường là các bản tin 200 OK.
vii. Các khối định tuyến thất bại (Failure Route Blocks): Các khối định tuyến thất bại tùy chọn có thể được sử dụng khi xử lý đặc biệt là cần thiết để điều khiển trong các điều kiện không thành công như bận hay timeout.
Các giao dịch (Transactions), hội thoại (Dialogs), và phiên (Sessions) Để hiểu openser.cfg một cách đúng đắn, chúng ta cần hiểu 3 khái niệm SIP:
i. Giao dịch SIP (Transaction): Một bản tin SIP (kể cả gửi lại) và đáp ứng trực tiếp (thông thường là trực tiếp) của nó (ví dụ User agent gửi REGISTER đến SER và nhận OK)
ii. Hội thoại SIP (SIP Dialog): Một quan hệ giữa (ít nhất) hai SIP phone tồn tại trong một thời gian nào đó (ví dụ hội thoại được thiết lập với một bản tin INVITE và được kết thúc bởi một bản tin BYE)
Quá trình xử lý bản tin
Openser.cfg là một kịch bản được thực hiện cho mỗi bản tin SIP nhận được. Ví dụ, nêu user A muốn nói chuyện với user B, nó gửi một bản tin INVITE. Bản tin này được xử lý trong khối định tuyến chính. Quá trình xử lý tiếp tục cho đến khi nó tìm thấy lệnh t_reply() (forward bản tin) hay
sl_send_reply (gửi một bản tin báo lỗi) hay rốt cuộc là hủy bỏ bản tin ở cuối khối định tuyến sử dụng lệnh exit.
b- SIP proxy – cách thức hoạt động mong đợi
Sẽ rất quan trọng để hiểu quá trình xử lý cơ bản của một SIP proxy theo chuẩn RFC3261. Nếu không hiểu điều này sẽ rất khó khăn để cấu hình một máy chủ uỷ quyền.
Mỗi proxy sẽ đưa ra các quyết định định tuyến, chỉnh sửa các request trước khi gửi nó đến thành phần tiếp theo. Các đáp ứng sẽ được định tuyến qua cùng một tập các proxy mà request ban đầu đi qua nhưng theo thứ tụ đảo ngược.
Một SIP proxy có thể hoạt động trong chế độ stateless hay stateful. Khi một SIP proxy làm việc như là một máy chuyển tiếp gói SIP đơn giản, nó chuyển tiếp các gói đến các thành phần đơn được xác định bởi các request. Một proxy làm việc trong chế độ stateless loại bỏ bất kỳ thông tin nào về bản tin sau khi bản tin đó vừa được gửi. Đặc tính này làm giới hạn đến các chức năng như xử lý lỗi và tính cước.
Khi OpenSER biết rằng bản tin 200 OK là tương ứng với một bản tin INVITE nào đó (trước đó), chúng ta nói rằng nó đang làm việc trong chế độ stateful. Điều này đơn giản có nghĩa là bạn có thể quản lý các đáp ứng trong khối định tuyến onreply_route(). Với xứ lý stateless mỗi bản tin được điều khiển không theo ngữ cảnh. Xứ lý stateless được sử dụng trong các ứng dụng như cân bằng tải; nó sử dụng câu lệnh forward() trong script.
Khi chúng ta cần các chức năng phức tạp hơn như tính cước, chuyển tiếp cuộc gọi, và voicemail, thì cần phải sử dụng xử lý stateful. Mỗi giao dịch sẽ được
giao dịch nhất định. Các giao dịch stateful được điều khiển bởi module TM (Transaction Module) và thường sử dụng câu lệnh t_relay().
Một khái niệm thường nhầm lẫn là qua trình xử lý stateful là theo từng phiên chứ không phải theo từng hội thoại. Vì thế, quá trình xử lý stateful ví dụ là từ
request INVITE đến response OK (một giao dịch) chứ không phải từ request INVITE đến request BYE (của một hội thoại).
c- Hoạt động theo chế độ stateful
Hình 5.1 Chế độ stateful của openser
Hình trên là một mô tả đơn giản một hoạt động trong chế độ stateful. Trong đó có sự tương đồng giữa các phần trong file openser.cfg với các phần ở trên.
Khi hoạt động trong chế độ stateful, một proxy đơn giản chỉ là một bộ xử lý giao dịch SIP và tất cả các bước xử lý sau được yêu cầu:
• Phê chuẩn các request
• Tiền xử lý thông tin định tuyến
• Xác định đích của request
• Chuyển tiếp request đến đích
Một stateful proxy tạo ra một giao dịch server mới cho mỗi request mới nhận được. Bất kỳ sự truyền lại nào của request sau đó sẽ được điều khiển bởi giao dịch server đó.
Ví dụ: Đối với mỗi request đang truyền qua SIP proxy của chúng ta, chúng ta sẽ:
Bước 1: Phê chuẩn các request
• Kiểm tra kích thước bản tin để tránh tràn bộ đệm
• Kiểm tra tiêu đề Max-forward để tìm các vòng lặp
Bước 2: Tiền xử lý thông tin định tuyến
• Nếu có tiêu đề record-route thì xử lý nó Bước 3: Xác định đích của request
• Xem nó có thuộc trong database (là các user đã được đăng ký) không ?
• Có một tuyến đến đích không (các gateway destination) ?
• Nó có được điều khiển đến các domain bên ngoài không (các external address)
Bước 4: Chuyển tiếp request đến đích
• Gọi chức năng t_relay() và OpenSER sẽ làm tất những công việc cho bạn một cách stateful.
Bước 5: Xử lý tất cả các response
• Thông thường công việc này được hoàn thành một cách tự động bởi OpenSER. Thỉnh thoảng chúng ta có thể sử dụng phần onreply_route[] để điều khiển một vài response. Ví dụ: trong trường hợp “chuyển tiếp cuộc
gọi khi bận”, chúng ta có thể sử dụng đáp ứng 486 (Busy) để điều khiển cuộc gọi đến voice server.