Приказната за еден проект или како потрошив 7 години создавајќи PBX базиран на Asterisk и Php

Сигурно многумина од вас, како мене, имале идеја да направат нешто уникатно. Во оваа статија ќе ги опишам техничките проблеми и решенија со кои морав да се соочам при развивањето на PBX. Можеби ова ќе помогне некој да одлучи за сопствената идеја, а некој да го следи добро изгазениот пат, бидејќи и јас имав корист од искуството на пионерите.

Идејата и клучните барања

И се започна едноставно со љубов кон Ѕвездичка (рамка за градење комуникациски апликации), автоматизација на телефонија и инсталации freepbx (веб интерфејс за Ѕвездичка). Доколку потребите на компанијата беа без специфики и беа во рамките на можностите freepbx - се е супер. Целата инсталација се одвиваше во рок од 24 часа, компанијата доби конфигуриран PBX, кориснички интерфејс и кратка обука плус поддршка по желба.

Но, најинтересните задачи беа нестандардни и тогаш не беше толку чудесно. Ѕвездичка може да направи многу, но за одржување на веб-интерфејсот во работна состојба, потребно беше да се потроши многу пати повеќе време. Така, еден мал детал може да потрае многу подолго од инсталирањето на остатокот од PBX. И поентата не е дека е потребно долго време за да се напише веб-интерфејс, туку поентата е во архитектонските карактеристики freepbx. Архитектонски пристапи и методи freepbx беше поставена во времето на php4, и во тој момент веќе имаше php5.6 на која сè можеше да се направи поедноставно и поудобно.

Последната капка беше графички дијаграми во форма на дијаграм. Кога се обидов да изградам вакво нешто за freepbx, сфатив дека ќе треба значително да го препишам и полесно ќе изградам нешто ново.

Клучните барања беа:

• едноставно поставување, интуитивно достапно дури и за почетник администратор. Така, компаниите не бараат одржување на PBX од наша страна,
• лесна модификација, така што задачите се решаваат на соодветно време,
• леснотија на интеграција со PBX. У freepbx немаше API за менување поставки, т.е. Не можете, на пример, да креирате групи или гласовни менија од апликација од трета страна, туку само од самиот API Ѕвездичка,
• opensource - за програмерите ова е исклучително важно за модификации за клиентот.

Идејата за побрз развој беше целата функционалност да се состои од модули во форма на објекти. Сите објекти мораа да имаат заедничка матична класа, што значи дека имињата на сите главни функции се веќе познати и затоа веќе има стандардни имплементации. Објектите ќе ви овозможат драматично да го намалите бројот на аргументи во форма на асоцијативни низи со копчиња со низа, кои можете да ги дознаете во freepbx Тоа беше можно со испитување на целата функција и вгнездени функции. Во случај на објекти, баналното автоматско комплетирање ќе ги прикаже сите својства и воопшто ќе го поедностави животот многукратно. Плус, наследувањето и редефинирањето веќе решаваат многу проблеми со модификациите.

Следното нешто што го забави времето за преработка и вредеше да се избегне беше дуплирањето. Ако постои модул одговорен за бирање на вработен, тогаш сите други модули што треба да испратат повик до вработен треба да го користат, а не да создаваат свои копии. Значи, ако треба да промените нешто, тогаш ќе треба да промените само на едно место и пребарувањето „како функционира“ треба да се изврши на едно место, а не да се пребарува низ целиот проект.

Првата верзија и првите грешки

Првиот прототип беше готов за една година. Целата PBX, како што беше планирано, беше модуларен, а модулите не само што можеа да додадат нова функционалност за обработка на повици, туку и да го променат самиот веб-интерфејс.

Да, идејата за изградба на бирање план во форма на таква шема не е моја, но е многу погодна и јас го направив истото за Ѕвездичка.

Со пишување на модул, програмерите веќе можеа:

• креирајте своја сопствена функционалност за обработка на повици, која може да се постави на дијаграмот, како и во менито со елементи лево,
• креирајте сопствени страници за веб-интерфејсот и додајте ги вашите шаблони на постоечките страници (ако развивачот на страницата го обезбедил тоа),
• додајте ги вашите поставки во главната картичка за поставки или креирајте сопствена картичка за поставки,
• програмерот може да наследи од постоечки модул, да смени дел од функционалноста и да ја регистрира под ново име или да го замени оригиналниот модул.

На пример, вака можете да креирате сопствено гласовно мени:

......
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__); //Подменить существующий модуль

Првите сложени имплементации ја донесоа првата гордост и првите разочарувања. Ми беше драго што функционираше, што веќе можев да ги репродуцирам главните карактеристики freepbx. Ми беше драго што на луѓето им се допадна идејата за шемата. Сè уште имаше многу опции за поедноставување на развојот, но дури и во тоа време некои од задачите веќе беа олеснети.

API за промена на конфигурацијата на PBX беше разочарување - резултатот воопшто не беше онаков каков што сакавме. Го зедов истиот принцип како и во freepbx, со кликнување на копчето Примени, целата конфигурација повторно се креира и модулите се рестартираат.

Изгледа вака:

*Dialplan е правило (алгоритам) со кое се обработува повик.

Но, со оваа опција, невозможно е да се напише нормален API за менување на поставките на PBX. Прво, операцијата за примена на промени на Ѕвездичка премногу долго и интензивно со ресурси.
Второ, не можете да повикате две функции истовремено, затоа што и двете ќе ја креираат конфигурацијата.
Трето, ги применува сите поставки, вклучувајќи ги и оние направени од администраторот.

Во оваа верзија, како и во Аскозија, беше можно да се генерира конфигурација само на променетите модули и да се рестартираат само потребните модули, но сите овие се полумерки. Беше неопходно да се промени пристапот.

Втора верзија. Носот извади опашка заглавени

Идејата да се реши проблемот не беше да се рекреираат конфигурацијата и планот за бирање Ѕвездичка, но зачувајте информации во базата на податоци и читајте директно од базата додека го обработувате повикот. Ѕвездичка Веќе знаев како да читам конфигурации од базата на податоци, само сменете ја вредноста во базата и следниот повик ќе се обработи земајќи ги предвид промените, а функцијата беше совршена за читање параметри на dialplan REALTIME_HASH.

На крајот, немаше потреба ниту да се рестартира Ѕвездичка при промена на поставките и сите поставки почнаа да се применуваат веднаш на Ѕвездичка.

Единствените промени во планот за бирање се додавање на броеви на екстензии и совети. Но, ова беа мали промени

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)
...

Можете лесно да додавате или менувате линија во планот за бирање користејќи Ами (контролен интерфејс Ѕвездичка) и не е потребно рестартирање на целиот план за бирање.

Ова го реши проблемот со конфигурацискиот API. Можете дури и директно да влезете во базата на податоци и да додадете нова група или да го промените, на пример, времето на dial-up во полето „dialtime“ за групата и следниот повик веќе ќе трае одредено време (ова не е препорака за акција, бидејќи некои API операции бараат Ами повици).

Првите тешки имплементации повторно ја донесоа првата гордост и разочарување. Мило ми беше што успеа. Базата на податоци стана критична врска, зависноста од дискот се зголеми, имаше повеќе ризици, но сè работеше стабилно и без проблеми. И што е најважно, сега се што можеше да се направи преку веб-интерфејсот можеше да се направи преку API, а беа користени истите методи. Дополнително, веб-интерфејсот се ослободи од копчето „примени поставки на PBX“, на кое администраторите често забораваа.

Разочарувањето беше што развојот стана покомплициран. Од првата верзија, јазикот PHP генерира план за бирање во јазикот Ѕвездичка и изгледа сосема нечитливо, плус самиот јазик Ѕвездичка за пишување dialplan е крајно примитивно.

Како тоа изгледаше:

$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'))

Во втората верзија, dialplan стана универзален, ги вклучуваше сите можни опции за обработка во зависност од параметрите и неговата големина значително се зголеми. Сето ова во голема мера го забави времето на развој, а самата помисла дека уште еднаш е неопходно да се меша со планот за бирање ме растажи.

Трета верзија

Идејата да се реши проблемот не беше да се генерира Ѕвездичка dialplan од php и употреба FastAGI и напишете ги сите правила за обработка во самиот PHP. FastAGI таа им овозможува на Ѕвездичка, за да го обработите повикот, поврзете се во штекерот. Примајте команди од таму и испраќајте резултати. Така, логиката на dialplan е веќе надвор од границите Ѕвездичка и може да се пишува на кој било јазик, во мојот случај во PHP.

Имаше многу обиди и грешки. Главниот проблем беше што веќе имав многу часови/датотеки. Беа потребни околу 1,5 секунди за да се создадат објекти, да се иницијализираат и да се регистрираат едни со други, а ова доцнење по повик не е нешто што може да се игнорира.

Иницијализацијата требаше да се случи само еднаш и затоа потрагата по решение започна со пишување услуга во php користејќи Нишки. По една недела експериментирање, оваа опција беше откажана поради сложеноста на тоа како функционира оваа екстензија. По еден месец тестирање, морав да го напуштам и асинхроното програмирање во PHP; ми требаше нешто едноставно, познато за секој почетник на PHP, а многу екстензии за PHP се синхрони.

Решението беше нашата сопствена услуга со повеќе нишки во C, која беше компајлирана со PHPLIB. Ги вчитува сите ATS php-датотеки, чека сите модули да се иницијализираат, додава повратен повик еден на друг и кога сè е подготвено, го кешира. Кога се распрашува од FastAGI се креира стрим, во него се репродуцира копија од кешот на сите класи и податоци, а барањето се пренесува на функцијата php.

Со ова решение, времето од испраќање повик до нашата услуга до првата команда Ѕвездичка се намали од 1,5 на 0,05 секунди и овој пат малку зависи од големината на проектот.

Како резултат на тоа, времето за развој на dialplan беше значително намалено, и можам да го ценам тоа бидејќи морав да го препишам целиот dialplan на сите модули во PHP. Прво, методите веќе треба да бидат напишани во php за да се добие објект од базата на податоци; тие беа потребни за прикажување во веб-интерфејсот, и второ, и ова е главната работа, конечно е можно погодно да се работи со низи со броеви и низи со база на податоци плус многу PHP екстензии.

За да го обработите планот за бирање во класата на модули, треба да ја имплементирате функцијата dialplanDynamicCall и аргумент pbxCallRequest ќе содржи објект за интеракција Ѕвездичка.

Дополнително, стана возможно да се дебагира планот за бирање (php има xdebug и работи за нашата услуга), можете да се движите чекор по чекор со прегледување на вредностите на променливите.

Податоци за повици

Секоја анализа и извештаи бараат правилно собрани податоци, а овој блок PBX исто така помина низ многу обиди и грешки од првата до третата верзија. Честопати, податоците за повици се знак. Еден повик = една снимка: кој се јавил, кој одговарал, колку време разговарале. Во поинтересните опции, има дополнителен знак кој покажува кој вработен во PBX бил повикан за време на повикот. Но, сето ова покрива само дел од потребите.

Првичните барања беа:

• спаси не само кој телефонски се јавил, туку и кој одговорил, затоа што има прислушувања и тоа ќе треба да се земе предвид при анализирање на повиците,
• време пред да се поврзете со вработен. Во freepbx и некои други телефонски централи, повикот се смета за одговорен штом централата ќе го подигне телефонот. Но, за гласовното мени веќе треба да го кренете телефонот, така што сите повици се одговорени и времето на чекање за одговор станува 0-1 секунда. Затоа, беше одлучено да се заштеди не само времето пред одговор, туку и времето пред поврзувањето со клучните модули (самиот модул го поставува ова знаме. Во моментов тоа е „Вработен“, „Надворешна линија“).
• за покомплексен план за бирање, кога повик патува помеѓу различни групи, неопходно беше да може да се испита секој елемент посебно.

Најдобрата опција се покажа кога PBX модулите испраќаат информации за себе на повици и на крајот ги зачувуваат информациите во форма на дрво.

Изгледа вака:

Прво, општи информации за повикот (како и сите други - ништо посебно).

1. Добив повик на надворешна линија "За тестот„во 05:55:52 часот од бројот 89295671458 на бројот 89999999999, на крајот е одговорено од вработен“секретар 2» со број 104. Клиентот чекал 60 секунди и зборувал 36 секунди.
2. вработен“секретар 2„Се јавува на 112 и одговара вработен“Менаџер 1» по 8 секунди. Зборуваат 14 секунди.
3. Клиентот се пренесува на вработениот "менаџер 1“ каде што продолжуваат да зборуваат уште 13 секунди

Но, ова е врвот на ледениот брег; за секој запис можете да добиете детална историја на повици преку PBX.

Сите информации се претставени како гнездење на повици:

1. Добив повик на надворешна линија "За тестот» во 05:55:52 од бројот 89295671458 до бројот 89999999999.
2. Во 05:55:53 надворешната линија испраќа повик до дојдовното коло "тест»
3. Кога обработувате повик според шемата, модулот „повик на менаџер“, во кој повикот е 16 секунди. Ова е модул развиен за клиентот.
4. Модул "повик на менаџер" испраќа повик до вработениот одговорен за бројот (клиент)"Менаџер 1“ и чека 5 секунди за одговор. Менаџерот не одговори.
5. Модул "повик на менаџер"испраќа повик до групата"Менаџери на CORP" Тоа се други менаџери од иста насока (седат во иста просторија) и чекаат 11 секунди за одговор.
6. Група "Менаџери на CORP„ги повикува вработените“Менаџер 1, Менаџер 2, Менаџер 3„истовремено 11 секунди. Нема одговор.
7. Повикот на менаџерот завршува. И колото испраќа повик до модулот "Избор на рута од 1в" Исто така, модул напишан за клиентот. Овде повикот беше обработен 0 секунди.
8. Колото испраќа повик до гласовното мени "Основно со дополнително бирање" Клиентот таму чекал 31 секунда, немало дополнително бирање.
9. Шемата испраќа повик до Групата "Секретари“, каде клиентот чекал 12 секунди.
10. Во група истовремено се повикуваат 2 вработени“секретар 1"И"секретар 2„И по 12 секунди вработениот одговара“секретар 2" Одговорот на повикот се дуплира во родителски повици. Излегува дека во групата тој одговорил „секретар 2", при повикување на колото одговори"секретар 2" и одговори на повикот на надворешната линија со "секретар 2".

Заштедата на информации за секоја операција и нивното вгнездување е она што ќе овозможи едноставно да се прават извештаи. Извештајот на гласовното мени ќе ви помогне да дознаете колку помага или попречува. Направете извештај за пропуштени повици од страна на вработените, земајќи предвид дека повикот бил пресретнат и затоа не се смета за пропуштен и имајќи предвид дека бил групен повик, а некој друг одговорил порано, што значи дека повикот исто така не бил пропуштен.

Таквото складирање на информации ќе ви овозможи да ја земете секоја група посебно и да одредите колку ефикасно функционира и да изградите график на одговорени и пропуштени групи по час. Можете исто така да проверите колку е точна врската со одговорниот менаџер со анализа на трансферите по поврзувањето со менаџерот.

Можете исто така да спроведете доста нетипични студии, на пример, колку често броевите што не се во базата на податоци ја повикуваат точната екстензија или колкав процент од појдовните повици се препраќаат на мобилен телефон.

Резултатот?

Не е потребен специјалист за одржување на PBX, тоа може да го направи најобичниот администратор - тестиран во пракса.

За модификации не се потребни специјалисти со сериозни квалификации, доволно е познавање на PHP, бидејќи Веќе се напишани модули за протоколот SIP, и за редот, и за повикување вработен и други. Постои класа за обвивка за Ѕвездичка. За да развие модул, програмерот може (и на добар начин треба) да повика готови модули. И знаење Ѕвездичка се целосно непотребни ако клиентот побара да додаде страница со некој нов извештај. Но, практиката покажува дека иако програмерите од трети страни можат да се справат, тие се чувствуваат несигурни без документација и нормално покривање на коментарите, па сè уште има простор за подобрување.

Модулите можат:

• креирајте нови можности за обработка на повици,
• додадете нови блокови на веб-интерфејсот,
• наследете од кој било од постоечките модули, редефинирајте ги функциите и заменете го, или едноставно бидете малку изменета копија,
• додадете ги вашите поставки во шаблонот за поставки на други модули и многу повеќе.

Поставки на PBX преку API. Како што е опишано погоре, сите поставки се зачувани во базата на податоци и се читаат во моментот на повикот, така што можете да ги промените сите поставки на PBX преку API. При повикување на API, конфигурацијата не се креира повторно и модулите не се рестартираат, затоа, не е важно колку поставки и вработени имате. Барањата за API се извршуваат брзо и не се блокираат едни со други.

PBX ги складира сите клучни операции со повици со времетраење (чекање/разговор), вгнездени и во термини на PBX (вработен, група, надворешна линија, не канал, број). Ова ви овозможува да креирате различни извештаи за одредени клиенти и најголемиот дел од работата е да создадете интерфејс кој е лесен за корисниците.

Времето ќе покаже што ќе се случи понатаму. Има уште многу нијанси кои треба да се преработат, има уште многу планови, но помина една година од создавањето на 3-та верзија и веќе можеме да кажеме дека идејата функционира. Главниот недостаток на верзијата 3 се хардверските ресурси, но тоа е обично она за што треба да платите за леснотија на развој.

Извор: www.habr.com