Wis, in protte fan jimme, lykas ik, hiene in idee om wat unyk te dwaan. Yn dit artikel sil ik de technyske problemen en oplossingen beskriuwe dy't ik te krijen hie by it ûntwikkeljen fan de PBX. Faaks sil dit ien helpe om te besluten oer har eigen idee, en ien om it goed tradearre paad te folgjen, om't ik ek profitearre fan de ûnderfining fan pioniers.
Idee en wichtige easken
En it begon allegear gewoan mei leafde foar Stjerke (ramt foar it bouwen fan kommunikaasjeapplikaasjes), automatisearring fan telefony en ynstallaasjes freebx (webynterface foar Stjerke). As de behoeften fan it bedriuw sûnder spesifiken wiene en binnen de mooglikheden foelen freebx - alles is geweldich. De hiele ynstallaasje fûn plak binnen XNUMX oeren, it bedriuw krige in ynstelde PBX, in brûkerfreonlike ynterface en koarte training plus stipe as winske.
Mar de meast nijsgjirrige taken wiene net-standert en dan wie it net sa fabulous. Stjerke kin in protte dwaan, mar om de webynterface yn wurking te hâlden, wie it nedich om in protte kearen mear tiid te besteegjen. Dat in lyts detail kin folle langer duorje dan it ynstallearjen fan de rest fan 'e PBX. En it punt is net dat it lang duorret om in webynterface te skriuwen, mar it punt is earder yn 'e arsjitektoanyske funksjes freebx. Arsjitektuer oanpakken en metoaden freebx waard oanlein yn 'e tiid fan php4, en op dat stuit wie d'r al php5.6 wêrop alles ienfâldiger en handiger makke wurde koe.
De lêste strie wie grafyske dialplannen yn 'e foarm fan in diagram. Doe't ik besocht te bouwen sa'n ding foar freebx, Ik realisearre dat ik it signifikant oerskriuwe moatte soe en it soe makliker wêze om wat nij te bouwen.
De wichtichste easken wiene:
- ienfâldige opset, yntuïtyf tagonklik sels foar in begjinnende behearder. Sa hawwe bedriuwen gjin PBX-ûnderhâld oan ús kant nedich,
- maklike wiziging sadat taken yn adekwate tiid wurde oplost,
- gemak fan yntegraasje mei PBX. U freebx der wie gjin API foar it feroarjen fan ynstellings, d.w.s. Jo kinne bygelyks gjin groepen of stimmenu's meitsje fan in applikaasje fan tredden, allinich de API sels Stjerke,
- opensource - foar programmeurs is dit ekstreem wichtich foar wizigingen foar de kliïnt.
It idee fan rapper ûntwikkeling wie dat alle funksjonaliteit bestiet út modules yn 'e foarm fan objekten. Alle objekten moasten in mienskiplike âlderklasse hawwe, wat betsjut dat de nammen fan alle haadfunksjes al bekend binne en dêrom binne der al standertimplementaasjes. Objekten kinne jo it oantal arguminten dramatysk ferminderje yn 'e foarm fan assosjative arrays mei tekenrige toetsen, dy't jo kinne fine yn freebx It wie mooglik troch it ûndersykjen fan de hiele funksje en nestele funksjes. Yn it gefal fan objekten sil banale autofoltôging alle eigenskippen sjen litte, en yn 't algemien sil it libben in protte kearen ferienfâldigje. Plus, erfenis en redefinisje oplost al in protte problemen mei oanpassings.
It folgjende ding dat de reworktiid fertrage en it wurdich wie om te foarkommen wie duplikaasje. As d'r in module is dy't ferantwurdlik is foar it skiljen fan in meiwurker, dan moatte alle oare modules dy't in oprop nei in meiwurker stjoere moatte it brûke, en net har eigen kopyen meitsje. Dus, as jo wat moatte feroarje, dan moatte jo mar op ien plak feroarje en it sykjen nei "hoe't it wurket" moat op ien plak útfierd wurde, en net troch it heule projekt trochsocht.
Earste ferzje en earste flaters
It earste prototype wie binnen in jier klear. De folsleine PBX, lykas pland, wie modulêr, en de modules koene net allinich nije funksjonaliteit tafoegje foar it ferwurkjen fan petearen, mar ek de webynterface sels feroarje.
Ja, it idee fan it bouwen fan in dialoochplan yn 'e foarm fan sa'n skema is net fan my, mar it is heul handich en ik die itselde foar Stjerke.
Troch in module te skriuwen kinne programmeurs al:
- meitsje jo eigen funksjonaliteit foar opropferwurking, dy't koe wurde pleatst op it diagram, lykas yn it menu fan eleminten oan 'e linkerkant,
- meitsje jo eigen siden foar de webynterface en foegje jo sjabloanen ta oan besteande siden (as de side-ûntwikkelder dit hat foarsjoen),
- foegje jo ynstellings ta oan de haadynstellingsljepper of meitsje jo eigen ynstellingsljepper,
- de programmeur kin ervje fan in besteande module, feroarje diel fan 'e funksjonaliteit en registrearje it ûnder in nije namme of ferfange de oarspronklike module.
Sa kinne jo bygelyks jo eigen stimmenu oanmeitsje:
......
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__); //Подменить существующий модульDe earste komplekse ymplemintaasjes brochten de earste grutskens en de earste teloarstellingen. Ik wie bliid dat it wurke, dat ik de haadfunksjes al wer werjaan koe freebx. Ik wie bliid dat minsken it idee fan it skema leuk fine. Der wiene noch in protte mooglikheden om de ûntwikkeling te ferienfâldigjen, mar ek op dat stuit waarden guon fan de taken al makliker makke.
De API foar it feroarjen fan de PBX-konfiguraasje wie in teloarstelling - it resultaat wie hielendal net wat wy woenen. Ik naam itselde prinsipe as yn freebx, troch te klikken op de knop Tapasse, wurdt de hiele konfiguraasje opnij oanmakke en de modules wurde opnij starte.
It sjocht der sa út:
*Dialplan is in regel (algoritme) wêrmei't in oprop ferwurke wurdt.
Mar mei dizze opsje is it ûnmooglik om in normale API te skriuwen foar it feroarjen fan de PBX-ynstellingen. Earst, de operaasje fan it tapassen fan feroarings oan Stjerke te lang en boarne yntinsyf.
Twads kinne jo net neame twa funksjes tagelyk, omdat beide sille meitsje de konfiguraasje.
Tredde, it jildt alle ynstellings, ynklusyf dy makke troch de behearder.
Yn dizze ferzje, lykas yn Askozia, It wie mooglik om de konfiguraasje fan allinich feroare modules te generearjen en allinich de nedige modules opnij te begjinnen, mar dit binne allegear heale maatregels. It wie nedich om de oanpak te feroarjen.
Twadde ferzje. Noas útlutsen sturt fêst
It idee om it probleem op te lossen wie net om de konfiguraasje en dialplan opnij te meitsjen foar Stjerke, mar bewarje ynformaasje nei de databank en lês út de databank direkt wylst it ferwurkjen fan de oprop. Stjerke Ik wist al hoe te lêzen konfiguraasjes út de databank, gewoan feroarje de wearde yn 'e databank en de folgjende oprop wurdt ferwurke rekken hâldend mei de feroarings, en de funksje wie perfekt foar it lêzen fan dialplan parameters REALTIME_HASH.
Uteinlik wie it net nedich om sels opnij te begjinnen Stjerke by it feroarjen fan de ynstellings en alle ynstellings begûn te wurde tapast fuortendaliks op Stjerke.
De ienige feroarings oan it dialplan binne de tafoeging fan tafoeging nûmers en oanwizings. Mar dit wiene lytse plakferoarings
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)
...Jo kinne maklik in rigel tafoegje of feroarje yn it dialplan mei Ami (kontrôle ynterface Stjerke) en gjin herstart fan it hiele dialplan is nedich.
Dit lost it probleem mei de konfiguraasje API. Jo kinne sels direkt yn 'e database gean en in nije groep taheakje of feroarje, bygelyks, de ynbeltiid yn it "dialtime" fjild foar de groep en de folgjende oprop soe al de opjûne tiid duorje (Dit is gjin oanbefelling foar aksje, sûnt guon API operaasjes fereaskje Ami oproppen).
De earste drege ymplemintaasjes brochten wer de earste grutskens en teloarstelling. Ik wie bliid dat it wurke. De databank waard in krityske keppeling, de ôfhinklikens fan 'e skiif ferhege, der wiene mear risiko's, mar alles wurke stabyl en sûnder problemen. En it wichtichste, no alles wat dien wurde koe fia de webynterface koe wurde dien fia de API, en deselde metoaden waarden brûkt. Derneist hat de webynterface de knop "Ynstellings tapasse op PBX" kwytrekke, dêr't behearders faaks ferjitte.
De teloarstelling wie dat de ûntwikkeling yngewikkelder waard. Sûnt de earste ferzje hat de PHP-taal in dialplan yn 'e taal generearre Stjerke en it liket folslein ûnlêsber, plus de taal sels Stjerke foar it skriuwen fan in dialplan is it ekstreem primityf.
Hoe seach it der út:
$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'))Yn 'e twadde ferzje waard it dialplan universeel, it omfette alle mooglike ferwurkingsopsjes ôfhinklik fan' e parameters en har grutte is signifikant tanommen. Dit alles fertrage de ûntwikkelingstiid tige, en de gedachte sels dat it nochris nedich wie om te bemuoien mei it dialoochplan makke my tryst.
Tredde ferzje
It idee om it probleem op te lossen wie net te generearjen Stjerke dialplan fan php en gebrûk FastAGI en skriuw alle ferwurkingsregels yn PHP sels. FastAGI stiet ta Stjerke, om de oprop te ferwurkjen, ferbine mei de socket. Untfang kommando's dêrwei en stjoer resultaten. Sa is de logika fan it dialoochplan al bûten de grinzen Stjerke en kin skreaun wurde yn elke taal, yn myn gefal yn PHP.
Der wie in protte probearjen en flaters. It wichtichste probleem wie dat ik al in protte klassen/bestannen hie. It duorre sawat 1,5 sekonden om objekten te meitsjen, se te initialisearjen en inoar te registrearjen, en dizze fertraging per oprop is net wat dat kin wurde negearre.
Inisjalisaasje soe mar ien kear moatte barre en dêrom begon it sykjen nei in oplossing mei it skriuwen fan in tsjinst yn php mei help fan Pthreads. Nei in wike fan eksperimintearjen waard dizze opsje opslein fanwegen de kompleksjes fan hoe't dizze útwreiding wurket. Nei in moanne fan testen moast ik ek asynchrone programmearring yn PHP ferlitte; Ik hie wat ienfâldich nedich, fertroud foar elke PHP-begjinner, en in protte útwreidingen foar PHP binne syngroan.
De oplossing wie ús eigen multi-threaded tsjinst yn C, dat waard gearstald mei PHPLIB. It laadt alle ATS php-bestannen, wachtet op alle modules om te inisjalisearjen, foeget in weromrop oan elkoar ta, en as alles klear is, cache it. By it freegjen fan FastAGI in stream wurdt oanmakke, in kopy fan 'e cache fan alle klassen en gegevens wurdt dêryn reprodusearre, en it fersyk wurdt trochjûn oan de php-funksje.
Mei dizze oplossing is de tiid fan it ferstjoeren fan in oprop nei ús tsjinst oant it earste kommando Stjerke ôfnommen fan 1,5 s nei 0,05 s en dizze tiid hinget in bytsje ôf fan de grutte fan it projekt.
As gefolch waard de tiid foar ûntwikkeling fan it dialoochplan signifikant fermindere, en ik kin dit wurdearje, om't ik it folsleine dialoochplan fan alle modules yn PHP moast oerskriuwe. As earste moatte metoaden al yn php skreaun wurde om in objekt út 'e databank te krijen; se wiene nedich foar werjefte yn 'e webynterface, en twad, en dit is it wichtichste, is it úteinlik mooglik om maklik te wurkjen mei snaren mei nûmers en arrays mei databank plus in protte PHP tafoegings.
Om it dialoochplan yn 'e moduleklasse te ferwurkjen moatte jo de funksje útfiere dialplanDynamicCall en argumint pbxCallRequest sil in objekt befetsje om mei te ynteraksje Stjerke.
Derneist waard it mooglik om it dialplan te debuggen (php hat xdebug en it wurket foar ús tsjinst), jo kinne stap foar stap ferpleatse troch de wearden fan fariabelen te besjen.
Skilje gegevens
Elke analytyk en rapporten fereaskje korrekt sammele gegevens, en dit PBX-blok gie ek troch in protte probearjen en flater fan 'e earste oant de tredde ferzje. Faak is opropgegevens in teken. Ien oprop = ien opname: wa belle, wa antwurde, hoe lang praten se. Yn mear nijsgjirrige opsjes is d'r in ekstra teken dat oanjout hokker PBX-meiwurker waard neamd tidens de oprop. Mar dit alles dekt mar in diel fan 'e behoeften.
De earste easken wiene:
- bewarje net allinnich wa't de PBX neamd, mar ek wa antwurde, omdat d'r binne ûnderskeppingen en dit sil rekken holden wurde moatte by it analysearjen fan petearen,
- tiid foar it ferbinen mei in meiwurker. Yn freebx en guon oare PBXs, de oprop wurdt beskôge beantwurde sa gau as de PBX nimt de telefoan. Mar foar it stimmenu moatte jo de tillefoan al opnimme, sadat alle oproppen wurde beantwurde en de wachttiid foar in antwurd wurdt 0-1 sekonde. Dêrom waard besletten om net allinich de tiid foar in antwurd te bewarjen, mar de tiid foar it ferbinen mei wichtige modules (de module sels set dizze flagge. Op it stuit is it "Employee", "Eksterne line"),
- foar in mear komplekse dialplan, doe't in oprop reizget tusken ferskillende groepen, it wie nedich om te kinnen ûndersiikje elk elemint apart.
De bêste opsje die bliken te wêzen as de PBX-modules ynformaasje oer harsels stjoere op petearen en úteinlik de ynformaasje yn 'e foarm fan in beam bewarje.
It sjocht der sa út:
Earst, algemiene ynformaasje oer de oprop (lykas elkenien oars - neat spesjaal).
- In oprop krigen op in bûtenline "Foar de test"om 05:55:52 fan it nûmer 89295671458 nei it nûmer 89999999999, op it lêst waard it beantwurde troch in meiwurker"Sekretaris 2»mei nûmer 104. De kliïnt wachte 60 sekonden en spruts 36 sekonden.
- Meiwurker"Sekretaris 2"makket in oprop nei 112 en in meiwurker antwurdet"Behearder 1» nei 8 sekonden. Se prate 14 sekonden.
- De klant wurdt oerdroegen oan de wurknimmer "behearder 1"wêr't se noch 13 sekonden fierder prate
Mar dit is it tip fan 'e iisberch; foar elk rekord kinne jo in detaillearre opropskiednis krije fia de PBX.
Alle ynformaasje wurdt presintearre as in nêst fan oproppen:
- In oprop krigen op in bûtenline "Foar de test» om 05:55:52 fan it nûmer 89295671458 nei it nûmer 89999999999.
- Om 05:55:53 stjoert de bûtenline in oprop nei it Ynkommende circuit "toets»
- By it ferwurkjen fan in oprop neffens it skema, de module "manager oprop", wêryn de oprop 16 sekonden is. Dit is in module ûntwikkele foar de klant.
- module"manager oprop" stjoert in oprop nei de meiwurker ferantwurdlik foar it nûmer (klant)"Behearder 1” en wachtet 5 sekonden foar in antwurd. De manager antwurde net.
- module"manager oprop"stjoert in oprop nei de groep"Corp managers" Dit binne oare managers fan deselde rjochting (sitte yn deselde keamer) en wachtsje 11 sekonden op in antwurd.
- Groep "Corp managers"ropt meiwurkers"Behearder 1, Behearder 2, Behearder 3"tagelyk foar 11 sekonden. Gjin antwurd.
- De oprop fan de manager einiget. En it circuit stjoert in oprop nei de module "Selektearje in rûte út 1c" Ek in module skreaun foar de klant. Hjir waard de oprop foar 0 sekonden ferwurke.
- It circuit stjoert in oprop nei it stimmenu "Basis mei ekstra dialling" De klant wachte dêr 31 sekonden, der wie gjin ekstra dialooch.
- It skema stjoert in oprop nei de groep "Sekretarissen", wêr't de kliïnt 12 sekonden wachte.
- Yn in groep wurde 2 meiwurkers tagelyk oproppen "Sekretaris 1"En"Sekretaris 2"en nei 12 sekonden antwurdet de meiwurker"Sekretaris 2" It antwurd op de oprop wurdt duplikearre yn âlderoproppen. It docht bliken dat hy yn 'e groep antwurde "Sekretaris 2", doe't it sirkwy rôp antwurde"Sekretaris 2"en beantwurde de oprop op 'e bûtenline mei"Sekretaris 2".
It is it bewarjen fan ynformaasje oer elke operaasje en har nêst dat it mooglik makket om gewoan rapporten te meitsjen. In rapport oer it stimmenu sil jo helpe út te finen hoefolle it helpt of hindert. Konstruearje in rapport oer petearen mist troch meiwurkers, rekken hâldend mei dat de oprop waard ûnderskept en dêrom wurdt net beskôge mist, en rekken hâldend mei dat it wie in groep oprop, en immen oars antwurde earder, wat betsjut dat de oprop waard ek net mist.
Sokke ynformaasje opslach sil tastean jo te nimmen eltse groep apart en bepale hoe effektyf it wurket, en bouwe in grafyk fan beantwurde en miste groepen troch oere. Jo kinne ek kontrolearje hoe krekt de ferbining mei de ferantwurdlike manager is troch de oerstappen te analysearjen neidat jo ferbine mei de manager.
Jo kinne ek frij atypyske stúdzjes útfiere, bygelyks hoe faak nûmers dy't net yn 'e databank steane de juste tafoeging kieze of hokker persintaazje fan útgeande oproppen wurdt trochstjoerd nei in mobile tillefoan.
Wat op it ein?
In spesjalist is net ferplichte om de PBX te ûnderhâlden; de meast gewoane behearder kin it dwaan - yn 'e praktyk testen.
Foar modifikaasjes binne spesjalisten mei serieuze kwalifikaasjes net nedich; kennis fan PHP is genôch, om't Modules binne al skreaun foar it SIP-protokol, en foar de wachtrige, en foar it oproppen fan in meiwurker, en oaren. Der is in wrapper klasse foar Stjerke. Om in module te ûntwikkeljen, kin in programmeur (en op in goede manier moat) ready-made modules neame. En kennis Stjerke binne folslein net nedich as de klant freget om in side ta te foegjen mei wat nij rapport. Mar de praktyk lit sjen dat hoewol programmeurs fan tredden kinne omgean, se fiele har ûnfeilich sûnder dokumintaasje en normale dekking fan opmerkingen, dus d'r is noch romte foar ferbettering.
Modules kinne:
- meitsje nije opropferwurkingsmooglikheden,
- nije blokken tafoegje oan 'e webynterface,
- erfje fan ien fan 'e besteande modules, definiearje funksjes opnij en ferfange it, of wês gewoan in wat feroare kopy,
- foegje jo ynstellings ta oan it ynstellingssjabloan fan oare modules en folle mear.
PBX ynstellings fia API. Lykas hjirboppe beskreaun, wurde alle ynstellings opslein yn 'e databank en lêzen op' e tiid fan 'e oprop, sadat jo alle PBX-ynstellingen kinne feroarje fia de API. By it roppen fan de API wurdt de konfiguraasje net opnij oanmakke en de modules wurde net opnij starte, dêrom makket it net út hoefolle ynstellings en meiwurkers jo hawwe. API-oanfragen wurde fluch útfierd en blokkearje inoar net.
De PBX bewarret alle kaai operaasjes mei petearen mei durations (wachtsjen / petear), nêst en yn PBX termen (meiwurker, groep, eksterne line, net kanaal, nûmer). Hjirmei kinne jo ferskate rapporten bouwe foar spesifike kliïnten en it measte fan it wurk is om in brûkerfreonlike ynterface te meitsjen.
De tiid sil fertelle wat der dan barre sil. D'r binne noch in protte nuânses dy't opnij wurde moatte, d'r binne noch in protte plannen, mar in jier is ferrûn sûnt de skepping fan 'e 3e ferzje en wy kinne al sizze dat it idee wurket. It wichtichste neidiel fan ferzje 3 is de hardware-boarnen, mar dit is normaal wat jo moatte betelje foar it gemak fan ûntwikkeling.
Boarne: www.habr.com