🥇Câu chuyện về một dự án hay việc tôi đã dành 7 năm để tạo ra một PBX dựa trên Asterisk và Php

Chắc hẳn nhiều bạn cũng như tôi đều có ý tưởng làm điều gì đó độc đáo. Trong bài viết này, tôi sẽ mô tả các vấn đề kỹ thuật và giải pháp mà tôi phải đối mặt khi phát triển PBX. Có lẽ điều này sẽ giúp ai đó quyết định ý tưởng của riêng họ và ai đó đi theo con đường đã được vạch sẵn, bởi vì tôi cũng được hưởng lợi từ kinh nghiệm của những người tiên phong.

Ý tưởng và yêu cầu chính

Và tất cả đều bắt đầu đơn giản bằng tình yêu dành cho Dấu hoa thị (khung xây dựng các ứng dụng truyền thông), tự động hóa điện thoại và lắp đặt tổng đài miễn phí (giao diện web cho Dấu hoa thị). Nếu nhu cầu của công ty không có thông tin cụ thể và nằm trong khả năng tổng đài miễn phí - mọi thứ đều tuyệt vời. Toàn bộ quá trình cài đặt diễn ra trong vòng XNUMX giờ, công ty nhận được một PBX đã được cấu hình, giao diện thân thiện với người dùng và đào tạo ngắn hạn kèm theo hỗ trợ nếu muốn.

Nhưng những nhiệm vụ thú vị nhất là không chuẩn và sau đó nó không quá tuyệt vời. Dấu hoa thị có thể làm được rất nhiều việc, nhưng để giữ cho giao diện web hoạt động tốt thì cần phải tốn thời gian gấp nhiều lần. Vì vậy, một chi tiết nhỏ có thể mất nhiều thời gian hơn việc cài đặt phần còn lại của PBX. Và vấn đề không phải là viết giao diện web mất nhiều thời gian mà vấn đề nằm ở đặc điểm kiến trúc tổng đài miễn phí. Cách tiếp cận và phương pháp kiến trúc tổng đài miễn phí đã được ra mắt vào thời điểm có php4 và tại thời điểm đó đã có php5.6, trên đó mọi thứ có thể được thực hiện đơn giản và thuận tiện hơn.

Rơm rạ cuối cùng là các sơ đồ quay số đồ họa dưới dạng sơ đồ. Khi tôi cố gắng xây dựng một cái gì đó như thế này cho tổng đài miễn phí, Tôi nhận ra rằng tôi sẽ phải viết lại nó một cách đáng kể và việc xây dựng một cái gì đó mới sẽ dễ dàng hơn.

Các yêu cầu chính là:

thiết lập đơn giản, có thể truy cập trực quan ngay cả với quản trị viên mới làm quen. Vì vậy, các công ty không yêu cầu chúng tôi bảo trì PBX,
sửa đổi dễ dàng để các nhiệm vụ được giải quyết trong thời gian thích hợp,
dễ dàng tích hợp với PBX. bạn tổng đài miễn phí không có API để thay đổi cài đặt, tức là. Ví dụ: bạn không thể tạo nhóm hoặc menu thoại từ ứng dụng của bên thứ ba, chỉ có chính API Dấu hoa thị,
mã nguồn mở - đối với các lập trình viên, điều này cực kỳ quan trọng đối với các sửa đổi dành cho máy khách.

Ý tưởng phát triển nhanh hơn là có tất cả các chức năng bao gồm các mô-đun ở dạng đối tượng. Tất cả các đối tượng phải có một lớp cha chung, có nghĩa là tên của tất cả các hàm chính đã được biết đến và do đó đã có các triển khai mặc định. Các đối tượng sẽ cho phép bạn giảm đáng kể số lượng đối số ở dạng mảng kết hợp bằng các khóa chuỗi, bạn có thể tìm hiểu điều này trong tổng đài miễn phí Có thể thực hiện được bằng cách kiểm tra toàn bộ hàm và các hàm lồng nhau. Trong trường hợp các đối tượng, tính năng tự động hoàn thành tầm thường sẽ hiển thị tất cả các thuộc tính và nhìn chung sẽ đơn giản hóa cuộc sống hơn nhiều lần. Ngoài ra, tính kế thừa và định nghĩa lại đã giải quyết được nhiều vấn đề về sửa đổi.

Điều tiếp theo làm chậm thời gian làm lại và cần tránh là sự trùng lặp. Nếu có một mô-đun chịu trách nhiệm quay số cho nhân viên, thì tất cả các mô-đun khác cần gửi cuộc gọi đến nhân viên nên sử dụng mô-đun đó và không được tạo bản sao của riêng chúng. Vì vậy, nếu bạn cần thay đổi điều gì đó, thì bạn sẽ chỉ phải thay đổi ở một nơi và việc tìm kiếm “cách thức hoạt động” phải được thực hiện ở một nơi chứ không phải tìm kiếm trong toàn bộ dự án.

Phiên bản đầu tiên và những lỗi đầu tiên

Nguyên mẫu đầu tiên đã sẵn sàng trong vòng một năm. Toàn bộ PBX, theo kế hoạch, là mô-đun và các mô-đun không chỉ có thể thêm chức năng mới để xử lý cuộc gọi mà còn thay đổi chính giao diện web.

Đúng, ý tưởng xây dựng một dialplan theo dạng sơ đồ như vậy không phải của tôi, nhưng nó rất tiện lợi và tôi cũng đã làm như vậy đối với Dấu hoa thị.

Bằng cách viết một mô-đun, các lập trình viên có thể:

tạo chức năng của riêng bạn để xử lý cuộc gọi, chức năng này có thể được đặt trên sơ đồ, cũng như trong menu các thành phần ở bên trái,
tạo các trang của riêng bạn cho giao diện web và thêm mẫu của bạn vào các trang hiện có (nếu nhà phát triển trang đã cung cấp tính năng này),
thêm cài đặt của bạn vào tab cài đặt chính hoặc tạo tab cài đặt của riêng bạn,
lập trình viên có thể kế thừa từ mô-đun hiện có, thay đổi một phần chức năng và đăng ký nó dưới tên mới hoặc thay thế mô-đun ban đầu.

Ví dụ: đây là cách bạn có thể tạo menu giọng nói của riêng mình:

......
class CPBX_MYIVR extends CPBX_IVR
{
 function __construct()
 {
 parent::__construct();
 $this->_module = "myivr";
 }
}
.....
$myIvrModule = new CPBX_MYIVR();
CPBXEngine::getInstance()->registerModule($myIvrModule,__DIR__); //Зарегистрировать новый модуль
CPBXEngine::getInstance()->registerModuleExtension($myIvrModule,'ivr',__DIR__); //Подменить существующий модуль

Việc triển khai phức tạp đầu tiên mang lại niềm tự hào đầu tiên và những thất vọng đầu tiên. Tôi rất vui vì nó hoạt động và tôi đã có thể tái tạo các tính năng chính tổng đài miễn phí. Tôi rất vui vì mọi người thích ý tưởng của kế hoạch này. Vẫn còn nhiều lựa chọn để đơn giản hóa việc phát triển, nhưng ngay cả vào thời điểm đó, một số nhiệm vụ đã được thực hiện dễ dàng hơn.

API để thay đổi cấu hình PBX thật đáng thất vọng - kết quả hoàn toàn không như những gì chúng tôi mong muốn. Tôi đã thực hiện nguyên tắc tương tự như trong tổng đài miễn phí, bằng cách nhấp vào nút Áp dụng, toàn bộ cấu hình sẽ được tạo lại và các mô-đun được khởi động lại.

Dường như thế này:

*Dialplan là một quy tắc (thuật toán) để xử lý cuộc gọi.

Nhưng với tùy chọn này, không thể viết API thông thường để thay đổi cài đặt PBX. Đầu tiên, thao tác áp dụng các thay đổi đối với Dấu hoa thị quá dài và tốn nhiều tài nguyên.
Thứ hai, bạn không thể gọi hai hàm cùng một lúc, bởi vì cả hai sẽ tạo ra cấu hình.
Thứ ba, nó áp dụng tất cả các cài đặt, bao gồm cả những cài đặt do quản trị viên thực hiện.

Trong phiên bản này, như trong Askozia, có thể tạo cấu hình chỉ các mô-đun đã thay đổi và chỉ khởi động lại các mô-đun cần thiết, nhưng đây đều là các biện pháp nửa vời. Nó là cần thiết để thay đổi cách tiếp cận.

Phiên bản thứ hai. Mũi rút ra đuôi kẹt

Ý tưởng để giải quyết vấn đề không phải là tạo lại cấu hình và sơ đồ quay số cho Dấu hoa thị, nhưng lưu thông tin vào cơ sở dữ liệu và đọc trực tiếp từ cơ sở dữ liệu trong khi xử lý cuộc gọi. Dấu hoa thị Tôi đã biết cách đọc cấu hình từ cơ sở dữ liệu, chỉ cần thay đổi giá trị trong cơ sở dữ liệu và cuộc gọi tiếp theo sẽ được xử lý có tính đến các thay đổi và chức năng này hoàn hảo để đọc các tham số của kế hoạch quay số REALTIME_HASH.

Cuối cùng, thậm chí không cần phải khởi động lại Dấu hoa thị khi thay đổi cài đặt và tất cả cài đặt bắt đầu được áp dụng ngay lập tức cho Dấu hoa thị.

Những thay đổi duy nhất đối với sơ đồ quay số là việc bổ sung số máy nhánh và gợi ý. Nhưng đây chỉ là những thay đổi nhỏ

exten=>101,1,GoSub(‘sub-callusers’,s,1(1)); - точечное изменение, добавляется/изменяется через ami

; sub-callusers – универсальная функция генерится при установке модуля.
[sub-callusers]
exten =>s,1,Noop()
exten =>s,n,Set(LOCAL(TOUSERID)=${ARG1})
exten =>s,n,ClearHash(TOUSERPARAM)
exten =>s,n,Set(HASH(TOUSERPARAM)=${REALTIME_HASH(rl_users,id,${LOCAL(TOUSERID)})})
exten =>s,n,GotoIf($["${HASH(TOUSERPARAM,id)}"=""]?return)
...

Bạn có thể dễ dàng thêm hoặc thay đổi một đường trong sơ đồ quay số bằng cách sử dụng Ami (giao diện điều khiển Dấu hoa thị) và không cần phải khởi động lại toàn bộ kế hoạch quay số.

Điều này đã giải quyết được vấn đề với API cấu hình. Bạn thậm chí có thể trực tiếp vào cơ sở dữ liệu và thêm một nhóm mới hoặc thay đổi, ví dụ: thời gian quay số trong trường “thời gian quay số” cho nhóm và cuộc gọi tiếp theo sẽ kéo dài theo thời gian đã chỉ định (Đây không phải là khuyến nghị dành cho hành động, vì một số hoạt động API yêu cầu Ami cuộc gọi).

Những lần triển khai khó khăn đầu tiên lại mang đến niềm tự hào và thất vọng đầu tiên. Tôi rất vui vì nó đã hoạt động. Cơ sở dữ liệu trở thành một mắt xích quan trọng, sự phụ thuộc vào đĩa ngày càng tăng, có nhiều rủi ro hơn nhưng mọi thứ đều hoạt động ổn định và không có vấn đề gì. Và quan trọng nhất, giờ đây mọi thứ có thể được thực hiện thông qua giao diện web đều có thể được thực hiện thông qua API và các phương pháp tương tự đã được sử dụng. Ngoài ra, giao diện web đã loại bỏ nút “áp dụng cài đặt cho PBX”, nút mà quản trị viên thường quên.

Điều đáng thất vọng là sự phát triển trở nên phức tạp hơn. Kể từ phiên bản đầu tiên, ngôn ngữ PHP đã tạo ra một dialplan trong ngôn ngữ Dấu hoa thị và nó trông hoàn toàn không thể đọc được, cộng với chính ngôn ngữ Dấu hoa thị để viết một dialplan thì nó cực kỳ thô sơ.

Nó trông như thế nào:

$usersInitSection = $dialplan->createExtSection('usersinit-sub','s');
$usersInitSection
 ->add('',new Dialplanext_gotoif('$["${G_USERINIT}"="1"]','exit'))
 ->add('',new Dialplanext_set('G_USERINIT','1'))
 ->add('',new Dialplanext_gosub('1','s','sub-AddOnAnswerSub','usersconnected-sub'))
 ->add('',new Dialplanext_gosub('1','s','sub-AddOnPredoDialSub','usersinitondial-sub'))
 ->add('',new Dialplanext_set('LOCAL(TECH)','${CUT(CHANNEL(name),/,1)}'))
 ->add('',new Dialplanext_gotoif('$["${LOCAL(TECH)}"="SIP"]','sipdev'))
 ->add('',new Dialplanext_gotoif('$["${LOCAL(TECH)}"="PJSIP"]','pjsipdev'))

Trong phiên bản thứ hai, sơ đồ quay số đã trở nên phổ biến, nó bao gồm tất cả các tùy chọn xử lý có thể có, tùy thuộc vào các thông số và kích thước của nó tăng lên đáng kể. Tất cả những điều này đã làm chậm đáng kể thời gian phát triển, và chính ý nghĩ rằng một lần nữa cần phải can thiệp vào kế hoạch quay số đã khiến tôi buồn.

phiên bản thứ ba

Ý tưởng giải quyết vấn đề không phải là tạo ra Dấu hoa thị dialplan từ php và sử dụng FastAGI và viết tất cả các quy tắc xử lý trong chính PHP. FastAGI cho phép Dấu hoa thị, để xử lý cuộc gọi, hãy kết nối với ổ cắm. Nhận lệnh từ đó và gửi kết quả. Như vậy, logic của dialplan đã nằm ngoài ranh giới Dấu hoa thị và có thể được viết bằng bất kỳ ngôn ngữ nào, trong trường hợp của tôi là PHP.

Đã có rất nhiều thử nghiệm và sai sót. Vấn đề chính là tôi đã có rất nhiều lớp/tệp. Mất khoảng 1,5 giây để tạo các đối tượng, khởi tạo chúng và đăng ký lẫn nhau và độ trễ trên mỗi cuộc gọi này không phải là điều có thể bỏ qua.

Việc khởi tạo lẽ ra chỉ diễn ra một lần và do đó việc tìm kiếm giải pháp bắt đầu bằng việc viết một dịch vụ bằng php bằng cách sử dụng Pthread. Sau một tuần thử nghiệm, tùy chọn này đã bị tạm dừng do cách hoạt động phức tạp của tiện ích mở rộng này. Sau một tháng thử nghiệm, tôi cũng phải từ bỏ lập trình bất đồng bộ trong PHP, tôi cần một thứ gì đó đơn giản, quen thuộc với bất kỳ người mới bắt đầu học PHP nào và nhiều tiện ích mở rộng cho PHP đều đồng bộ.

Giải pháp là dịch vụ đa luồng của chúng tôi trong C, được biên dịch bằng PHPLIB. Nó tải tất cả các tệp php ATS, đợi tất cả các mô-đun khởi tạo, thêm lệnh gọi lại cho nhau và khi mọi thứ đã sẵn sàng, hãy lưu nó vào bộ đệm. Khi hỏi thăm bằng FastAGI một luồng được tạo, một bản sao từ bộ đệm của tất cả các lớp và dữ liệu được sao chép trong đó và yêu cầu được chuyển đến hàm php.

Với giải pháp này, thời gian từ khi gửi cuộc gọi đến dịch vụ của chúng tôi đến lệnh đầu tiên Dấu hoa thị giảm từ 1,5 giây xuống 0,05 giây và thời gian này phụ thuộc một chút vào quy mô của dự án.

Kết quả là thời gian phát triển sơ đồ quay số đã giảm đáng kể và tôi có thể đánh giá cao điều này vì tôi phải viết lại toàn bộ sơ đồ quay số của tất cả các mô-đun trong PHP. Thứ nhất, các phương thức phải được viết bằng php để lấy một đối tượng từ cơ sở dữ liệu; chúng cần thiết để hiển thị trong giao diện web và thứ hai, và đây là điều chính, cuối cùng có thể làm việc thuận tiện với các chuỗi có số và mảng với cơ sở dữ liệu cộng với nhiều phần mở rộng PHP.

Để xử lý sơ đồ quay số trong lớp mô-đun, bạn cần triển khai hàm kế hoạch quay sốĐộngGọi và lập luận pbxYêu cầu cuộc gọi sẽ chứa một đối tượng để tương tác với Dấu hoa thị.

Ngoài ra, có thể gỡ lỗi sơ đồ quay số (php có xdebug và nó hoạt động cho dịch vụ của chúng tôi), bạn có thể di chuyển từng bước bằng cách xem giá trị của các biến.

Dữ liệu cuộc gọi

Mọi phân tích và báo cáo đều yêu cầu dữ liệu được thu thập chính xác và khối PBX này cũng đã trải qua rất nhiều lần thử và sai từ phiên bản đầu tiên đến phiên bản thứ ba. Thông thường, dữ liệu cuộc gọi là một dấu hiệu. Một cuộc gọi = một bản ghi âm: ai gọi, ai trả lời, họ nói chuyện bao lâu. Trong các tùy chọn thú vị hơn, có một dấu hiệu bổ sung cho biết nhân viên PBX nào đã được gọi trong cuộc gọi. Nhưng tất cả điều này chỉ đáp ứng một phần nhu cầu.

Các yêu cầu ban đầu là:

lưu ý không chỉ người mà tổng đài đã gọi mà còn cả người đã trả lời, bởi vì có sự can thiệp và điều này sẽ cần được tính đến khi phân tích cuộc gọi,
thời gian trước khi kết nối với nhân viên. TRONG tổng đài miễn phí và một số tổng đài khác, cuộc gọi được coi là đã trả lời ngay khi tổng đài nhấc máy. Nhưng đối với menu thoại, bạn đã cần phải nhấc máy nên tất cả cuộc gọi đều được trả lời và thời gian chờ trả lời trở thành 0-1 giây. Do đó, người ta đã quyết định tiết kiệm không chỉ thời gian trước khi phản hồi mà còn tiết kiệm thời gian trước khi kết nối với các mô-đun chính (bản thân mô-đun này đặt cờ này. Hiện tại nó là “Nhân viên”, “Đường dây bên ngoài”),
đối với một sơ đồ quay số phức tạp hơn, khi một cuộc gọi di chuyển giữa các nhóm khác nhau, cần phải có khả năng kiểm tra từng phần tử một cách riêng biệt.

Tùy chọn tốt nhất hóa ra là khi các mô-đun PBX gửi thông tin về chính chúng trong các cuộc gọi và cuối cùng lưu thông tin dưới dạng cây.

Nó trông như thế này:

Đầu tiên, thông tin chung về cuộc gọi (giống như những người khác - không có gì đặc biệt).

Đã nhận được cuộc gọi từ đường dây bên ngoài "Đối với thử nghiệm"Lúc 05:55:52 từ số 89295671458 đến số 89999999999, cuối cùng đã có nhân viên trả lời"Thư ký2» với số 104. Khách hàng đợi 60 giây và nói trong 36 giây.
Người lao động "Thư ký2"gọi tới 112 và nhân viên trả lời"Người quản lý1» sau 8 giây. Họ nói chuyện trong 14 giây.
Khách hàng được chuyển giao cho Nhân viên "quản lý1" nơi họ tiếp tục nói chuyện thêm 13 giây nữa

Nhưng đây chỉ là phần nổi của tảng băng chìm; đối với mỗi bản ghi, bạn có thể nhận được lịch sử cuộc gọi chi tiết thông qua PBX.

Tất cả thông tin được trình bày dưới dạng lồng các lệnh gọi:

Đã nhận được cuộc gọi từ đường dây bên ngoài "Đối với thử nghiệm» lúc 05:55:52 từ số 89295671458 đến số 89999999999.
Lúc 05:55:53 đường dây bên ngoài gửi cuộc gọi đến mạch Đến "thử nghiệm»
Khi xử lý cuộc gọi theo sơ đồ, mô-đun “cuộc gọi của người quản lý", trong đó cuộc gọi là 16 giây. Đây là một mô-đun được phát triển cho khách hàng.
mô-đun "cuộc gọi của người quản lý" gửi cuộc gọi đến nhân viên chịu trách nhiệm về số (khách hàng)"Người quản lý1” và đợi 5 giây để nhận phản hồi. Người quản lý không trả lời.
mô-đun "cuộc gọi của người quản lý"gửi cuộc gọi đến nhóm"người quản lý CORP" Đây là những người quản lý khác cùng hướng (ngồi cùng phòng) và chờ phản hồi 11 giây.
Nhóm "người quản lý CORP"gọi nhân viên"Người quản lý1, Người quản lý2, Người quản lý3"đồng thời trong 11 giây. Không có câu trả lời.
Cuộc gọi của người quản lý kết thúc. Và mạch sẽ gửi cuộc gọi đến mô-đun "Chọn tuyến đường từ 1c" Cũng là một mô-đun được viết cho khách hàng. Ở đây cuộc gọi được xử lý trong 0 giây.
Mạch gửi cuộc gọi đến menu thoại "Cơ bản với quay số bổ sung" Khách hàng đợi ở đó 31 giây, không quay số thêm.
Đề án gửi một cuộc gọi đến Nhóm "Thư ký", nơi khách hàng đợi 12 giây.
Trong một nhóm có 2 nhân viên được gọi cùng lúc"Thư ký1"Và"Thư ký2"và sau 12 giây nhân viên trả lời"Thư ký2" Câu trả lời cho cuộc gọi được sao chép vào cuộc gọi cha mẹ. Thì ra trong nhóm anh ấy đã trả lời “Thư ký2", khi gọi thì mạch trả lời"Thư ký2" và trả lời cuộc gọi ở đường dây bên ngoài bằng "Thư ký2'.

Việc lưu thông tin về từng hoạt động và sự lồng ghép của chúng sẽ giúp bạn có thể lập báo cáo một cách đơn giản. Một báo cáo trên menu giọng nói sẽ giúp bạn biết nó giúp ích hay cản trở đến mức nào. Lập báo cáo về các cuộc gọi nhỡ của nhân viên, có tính đến việc cuộc gọi đã bị chặn và do đó không được coi là nhỡ, đồng thời tính đến việc đó là cuộc gọi nhóm và đã có người khác trả lời trước đó, nghĩa là cuộc gọi cũng không bị nhỡ.

Việc lưu trữ thông tin như vậy sẽ cho phép bạn tách riêng từng nhóm và xác định mức độ hiệu quả của nó, đồng thời xây dựng biểu đồ các nhóm đã trả lời và nhóm bị bỏ lỡ theo giờ. Bạn cũng có thể kiểm tra mức độ chính xác của kết nối với người quản lý chịu trách nhiệm bằng cách phân tích các giao dịch chuyển tiền sau khi kết nối với người quản lý.

Bạn cũng có thể tiến hành các nghiên cứu khá không điển hình, chẳng hạn như tần suất các số không có trong cơ sở dữ liệu quay đúng số máy nhánh hoặc bao nhiêu phần trăm cuộc gọi đi được chuyển tiếp đến điện thoại di động.

Kết quả ra sao?

Không cần phải có chuyên gia để bảo trì PBX, quản trị viên bình thường nhất cũng có thể làm được việc đó - đã được thử nghiệm trong thực tế.

Để sửa đổi, không cần phải có chuyên gia có trình độ chuyên môn cao; kiến thức về PHP là đủ, bởi vì Các mô-đun đã được viết cho giao thức SIP, cho hàng đợi cũng như để gọi nhân viên và những người khác. Có một lớp bao bọc cho Dấu hoa thị. Để phát triển một mô-đun, lập trình viên có thể (và theo cách tốt nên) gọi các mô-đun được tạo sẵn. Và kiến thức Dấu hoa thị hoàn toàn không cần thiết nếu khách hàng yêu cầu thêm một trang với một số báo cáo mới. Nhưng thực tế cho thấy rằng mặc dù các lập trình viên bên thứ ba có thể đối phó nhưng họ cảm thấy không an toàn nếu không có tài liệu và mức độ đưa ra bình luận bình thường, vì vậy vẫn còn chỗ để cải thiện.

Các mô-đun có thể:

tạo ra khả năng xử lý cuộc gọi mới,
thêm các khối mới vào giao diện web,
kế thừa từ bất kỳ mô-đun hiện có nào, xác định lại các chức năng và thay thế nó hoặc đơn giản là một bản sao được sửa đổi một chút,
thêm cài đặt của bạn vào mẫu cài đặt của các mô-đun khác và hơn thế nữa.

Cài đặt PBX thông qua API. Như đã mô tả ở trên, tất cả cài đặt đều được lưu trữ trong cơ sở dữ liệu và được đọc tại thời điểm cuộc gọi, do đó bạn có thể thay đổi tất cả cài đặt PBX thông qua API. Khi gọi API, cấu hình không được tạo lại và các mô-đun không được khởi động lại, do đó, việc bạn có bao nhiêu cài đặt và nhân viên không quan trọng. Các yêu cầu API được thực thi nhanh chóng và không chặn lẫn nhau.

PBX lưu trữ tất cả các hoạt động chính với các cuộc gọi có thời lượng (chờ/đàm thoại), lồng ghép và theo thuật ngữ PBX (nhân viên, nhóm, đường dây bên ngoài, không phải kênh, số). Điều này cho phép bạn tạo nhiều báo cáo khác nhau cho các khách hàng cụ thể và hầu hết công việc là tạo giao diện thân thiện với người dùng.

Thời gian sẽ trả lời điều gì sẽ xảy ra tiếp theo. Vẫn còn nhiều sắc thái cần phải làm lại, vẫn còn nhiều kế hoạch, nhưng đã một năm trôi qua kể từ khi tạo ra phiên bản thứ 3 và chúng ta có thể nói rằng ý tưởng này đang thành công. Nhược điểm chính của phiên bản 3 là tài nguyên phần cứng, nhưng đây thường là thứ bạn phải trả để dễ dàng phát triển.

Nguồn: www.habr.com

Câu chuyện về một dự án hay việc tôi đã dành 7 năm để tạo ra một tổng đài dựa trên Asterisk và Php