🥇Прича о једном пројекту или како сам провео 7 година стварајући централу засновану на Астериск и ПХП

Сигурно су многи од вас, попут мене, имали идеју да ураде нешто јединствено. У овом чланку ћу описати техничке проблеме и решења са којима сам морао да се суочим приликом развоја ПБКС-а. Можда ће то некоме помоћи да се определи за своју идеју, а некоме да крене утабаним путем, јер је и мени користило искуство пионира.

Идеја и кључни захтеви

А све је почело једноставно љубављу према Астериск (оквир за изградњу комуникационих апликација), аутоматизација телефоније и инсталација ФрееПБКС (веб интерфејс за Астериск). Ако су потребе компаније биле без специфичности и спадале у оквире могућности ФрееПБКС - све је супер. Целокупна инсталација је обављена у року од 24 сата, компанија је добила конфигурисану ПБКС, кориснички интерфејс и кратку обуку плус подршку по жељи.

Али најзанимљивији задаци су били нестандардни и тада није било тако фантастично. Астериск може много, али да би веб интерфејс био у исправном стању, било је потребно потрошити вишеструко више времена. Дакле, мали детаљ може потрајати много дуже од инсталирања остатка ПБКС-а. И поента није у томе да је за писање веб интерфејса потребно много времена, већ је ствар у архитектонским карактеристикама ФрееПБКС. Архитектонски приступи и методе ФрееПБКС је био постављен у време пхп4, а у том тренутку је већ постојао пхп5.6 на коме је све могло да буде једноставније и погодније.

Кап која је прелила чашу били су графички дијаграми у облику дијаграма. Када сам покушао да направим нешто овако за ФрееПБКС, схватио сам да ћу морати да га значајно преправим и да ће бити лакше изградити нешто ново.

Кључни захтеви су били:

једноставно подешавање, интуитивно доступно чак и администратору почетнику. Дакле, компаније не захтевају одржавање ПБКС-а на нашој страни,
лака модификација тако да се задаци решавају у одговарајућем времену,
једноставност интеграције са ПБКС-ом. У ФрееПБКС није постојао АПИ за промену подешавања, тј. Не можете, на пример, да креирате групе или гласовне меније из апликације треће стране, већ само из самог АПИ-ја Астериск,
опенсоурце - за програмере је ово изузетно важно за модификације за клијента.

Идеја бржег развоја је била да се сва функционалност састоји од модула у облику објеката. Сви објекти су морали да имају заједничку родитељску класу, што значи да су имена свих главних функција већ позната и стога већ постоје подразумеване имплементације. Објекти ће вам омогућити да драматично смањите број аргумената у облику асоцијативних низова са стринг кључевима, што можете сазнати у ФрееПБКС То је било могуће испитивањем целе функције и угнежђених функција. У случају објеката, банално аутодовршавање ће показати сва својства и генерално ће поједноставити живот вишеструко. Плус, наслеђивање и редефинисање већ решавају многе проблеме са модификацијама.

Следећа ствар која је успорила време прераде и вредело је избегавати је дуплирање. Ако постоји модул одговоран за позивање запосленог, онда би сви остали модули који треба да пошаљу позив запосленом требало да га користе, а не да креирају сопствене копије. Дакле, ако треба нешто да промените, онда ћете морати да промените само на једном месту и потрагу за „како то функционише“ треба да се врши на једном месту, а не да се тражи током целог пројекта.

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

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

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

Писањем модула, програмери су већ могли:

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

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

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

Прве сложене имплементације донеле су први понос и прва разочарања. Било ми је драго што је успело, што сам већ успео да репродукујем главне карактеристике ФрееПБКС. Било ми је драго што се људима допала идеја о шеми. Још је било много опција за поједностављење развоја, али су и у то време неки задаци већ били олакшани.

АПИ за промену конфигурације ПБКС-а је био разочарање - резултат уопште није био оно што смо желели. Узео сам исти принцип као у ФрееПБКС, кликом на дугме Примени, цела конфигурација се поново креира и модули се поново покрећу.

То изгледа овако:

*Диалплан је правило (алгоритам) којим се позив обрађује.

Али са овом опцијом, немогуће је написати нормалан АПИ за промену поставки ПБКС-а. Прво, операција примене промена на Астериск предуго и захтева пуно ресурса.
Друго, не можете позвати две функције истовремено, јер оба ће креирати конфигурацију.
Треће, примењује се сва подешавања, укључујући и она која је направио администратор.

У овој верзији, као у Аскозиа, било је могуће генерисати конфигурацију само промењених модула и поново покренути само неопходне модуле, али то су све половичне мере. Било је неопходно променити приступ.

Друга верзија. Нос извучен реп заглавио

Идеја да се реши проблем није била поновно креирање конфигурације и плана бирања Астериск, али сачувајте информације у бази података и читајте их директно из базе података током обраде позива. Астериск Већ сам знао како да читам конфигурације из базе података, само промените вредност у бази и следећи позив ће бити обрађен узимајући у обзир промене, а функција је била савршена за читање параметара диалплан-а РЕАЛТИМЕ_ХАСХ.

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

Једине промене у плану бирања су додавање бројева локала и савети. Али то су биле мале промене

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

Можете једноставно додати или променити линију у плану бирања помоћу Da li sam (контролни интерфејс Астериск) и није потребно поновно покретање читавог плана бирања.

Ово је решило проблем са конфигурационим АПИ-јем. Можете чак и директно да одете у базу података и додате нову групу или промените, на пример, време позивања у пољу „време бирања“ за групу и следећи позив би већ трајао наведено време (ово није препорука за радњу, пошто неке АПИ операције захтевају Da li sam позива).

Прве тешке имплементације поново су донеле први понос и разочарење. Било ми је драго што је успело. База података је постала критична карика, зависност од диска се повећала, било је више ризика, али је све функционисало стабилно и без проблема. И што је најважније, сада је све што је могло да се уради преко веб интерфејса могло да се уради преко АПИ-ја, а коришћене су исте методе. Поред тога, веб интерфејс се ослободио дугмета „примени подешавања на ПБКС“, на шта су администратори често заборављали.

Разочарење је било то што је развој постао компликованији. Од прве верзије, ПХП језик је генерисао план бирања у језику Астериск и изгледа потпуно нечитљиво, плус сам језик Астериск за писање дијалплана је изузетно примитиван.

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

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

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

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

Идеја да се проблем реши није била генерисање Астериск Диалплан из пхп-а и користите ФастАГИ и написати сва правила обраде у самом ПХП-у. ФастАГИ Он омогућава Астериск, да бисте обрадили позив, повежите се на утичницу. Примајте команде одатле и шаљите резултате. Дакле, логика дијалплана је већ изван граница Астериск и може се написати на било ком језику, у мом случају у ПХП-у.

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

Иницијализација је требало да се деси само једном и стога је потрага за решењем почела писањем сервиса у пхп користећи Птхреадс. После недељу дана експериментисања, ова опција је одложена због сложености начина на који ово проширење функционише. После месец дана тестирања, такође сам морао да напустим асинхроно програмирање у ПХП-у; требало ми је нешто једноставно, познато сваком ПХП почетнику, а многа проширења за ПХП су синхрона.

Решење је била наша сопствена вишенитна услуга у Ц-у, са којом је компајлирано ПХПЛИБ. Учитава све АТС пхп датотеке, чека да се сви модули иницијализују, додаје један другом повратни позив и када је све спремно, кешира га. Приликом распитивања од ФастАГИ креира се стреам, у њему се репродукује копија из кеша свих класа и података, а захтев се прослеђује пхп функцији.

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

Као резултат тога, време за развој дијалплан-а је значајно смањено, и могу да ценим ово пошто сам морао да препишем цео дијалплан свих модула у ПХП-у. Прво, методе би већ требале бити написане у пхп-у за добијање објекта из базе података; биле су потребне за приказ у веб интерфејсу, а друго, а ово је главна ствар, коначно је могуће погодно радити са стринговима са бројевима и низовима са базом података плус много ПХП екстензија.

Да бисте обрадили план бирања у класи модула, потребно је да имплементирате функцију диалпланДинамицЦалл и аргумент пбкЦаллРекуест садржаће објекат за интеракцију Астериск.

Поред тога, постало је могуће отклонити грешке у дијалплану (пхп има кдебуг и ради за нашу услугу), можете се кретати корак по корак гледајући вредности променљивих.

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

Свака аналитика и извештаји захтевају правилно прикупљене податке, а и овај блок ПБКС-а је прошао кроз доста покушаја и грешака од прве до треће верзије. Често су подаци о позивима знак. Један позив = један снимак: ко је звао, ко се јавио, колико су разговарали. У занимљивијим опцијама постоји додатни знак који показује који је запосленик ПБКС позван током позива. Али све ово покрива само део потреба.

Почетни захтеви су били:

сачувајте не само кога је ПБКС звала, већ и ко се јавио, јер постоје пресретања и то ће се морати узети у обзир приликом анализе позива,
време пре повезивања са запосленим. У ФрееПБКС и неке друге ПБКС, позив се сматра одговорним чим ПБКС подигне слушалицу. Али за гласовни мени већ морате да подигнете слушалицу, тако да се на све позиве одговара и време чекања на одговор постаје 0-1 секунда. Због тога је одлучено да се уштеди не само време до одговора, већ и време пре повезивања са кључним модулима (модул сам поставља ову заставицу. Тренутно је то „Запослени“, „Спољна линија“),
за сложенији план бирања, када позив путује између различитих група, било је неопходно да се сваки елемент посебно испита.

Испоставило се да је најбоља опција када ПБКС модули шаљу информације о себи током позива и на крају их чувају у облику стабла.

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

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

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

Али ово је врх леденог брега; за сваки запис можете добити детаљну историју позива преко ПБКС-а.

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

Примљен позив на спољној линији "За тест» у 05:55:52 са броја 89295671458 на број 89999999999.
У 05:55:53 спољна линија шаље позив долазном колу "тест»
Приликом обраде позива према шеми, модул „позив менаџера“, у којој је позив 16 секунди. Ово је модул развијен за клијента.
Модул "позив менаџера" шаље позив запосленом одговорном за број (клијенту) "Менаџер1” и чека 5 секунди на одговор. Менаџер није одговорио.
Модул "позив менаџера"шаље позив групи"ЦОРП менаџери" Ово су други менаџери истог смера (седе у истој просторији) и чекају 11 секунди на одговор.
Група "ЦОРП менаџери"позива запослене"Менаџер1, Менаџер2, Менаџер3„истовремено 11 секунди. Нема одговора.
Позив менаџера се завршава. И коло шаље позив модулу "Избор руте од 1ц" Такође модул написан за клијента. Овде је позив обрађен 0 секунди.
Коло шаље позив гласовном менију "Основни са додатним бирањем" Клијент је тамо чекао 31 секунду, није било додатног бирања.
Шема шаље позив групи "секретарице“, где је клијент чекао 12 секунди.
У групи се истовремено позивају 2 запослена "секретар1"И"секретар2" и после 12 секунди запослени одговара "секретар2" Одговор на позив се дуплира у родитељске позиве. Испоставило се да је у групи одговорио „секретар2", када је коло одговорило на позив "секретар2" и одговорио на позив на спољној линији са "секретар2'.

Чување информација о свакој операцији и њихово угнежђивање ће омогућити једноставно прављење извештаја. Извештај на гласовном менију ће вам помоћи да сазнате колико помаже или омета. Саставити извештај о пропуштеним позивима од стране запослених, водећи рачуна да је позив пресретнут и да се стога не сматра пропуштеним, и водећи рачуна да се радило о групном позиву, а да се неко други јавио раније, што значи да позив такође није пропуштен.

Такво складиштење информација ће вам омогућити да сваку групу узмете засебно и утврдите колико ефикасно функционише, и да направите графикон одговорних и пропуштених група по сату. Колико је прецизна веза са одговорним менаџером можете проверити и анализом трансфера након повезивања са менаџером.

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

Резултат?

За одржавање ПБКС-а није потребан специјалиста, то може учинити и најобичнији администратор - тестирано у пракси.

За модификације нису потребни стручњаци са озбиљним квалификацијама, довољно је познавање ПХП-а, јер Модули су већ написани и за СИП протокол, и за ред, и за позивање запосленог и остало. Постоји класа омотача за Астериск. Да би развио модул, програмер може (и на добар начин би требало) да позове готове модуле. И знање Астериск потпуно су непотребни ако клијент тражи да се дода страница са неким новим извештајем. Али пракса показује да иако програмери трећих страна могу да се изборе, осећају се несигурно без документације и нормалног покривања коментара, тако да још увек има простора за побољшање.

Модули могу:

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

ПБКС подешавања преко АПИ-ја. Као што је горе описано, сва подешавања се чувају у бази података и читају у тренутку позива, тако да можете променити сва подешавања ПБКС-а преко АПИ-ја. Приликом позивања АПИ-ја, конфигурација се не креира поново и модули се не покрећу поново, стога није важно колико подешавања и запослених имате. АПИ захтеви се извршавају брзо и не блокирају једни друге.

ПБКС складишти све кључне операције са позивима са трајањем (чекање/разговор), угњежђењем и у терминима ПБКС (запослени, група, екстерна линија, а не канал, број). Ово вам омогућава да направите различите извештаје за одређене клијенте и највећи део посла је да креирате интерфејс прилагођен кориснику.

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

Извор: ввв.хабр.цом

Прича о једном пројекту или како сам провео 7 година стварајући централу засновану на Астериск и Пхп