Zgodba enega projekta ali kako sem 7 let ustvarjal telefonsko centralo na osnovi Asterisk in Php

Zagotovo ste mnogi od vas, tako kot jaz, imeli idejo narediti nekaj unikatnega. V tem članku bom opisal tehnične težave in rešitve, s katerimi sem se moral soočiti pri razvoju PBX. Morda bo to komu pomagalo, da se bo odločil za lastno idejo, nekomu pa, da bo šel po uhojeni poti, saj so mi koristile tudi izkušnje pionirjev.

Ideja in ključne zahteve

In vse se je začelo preprosto z ljubeznijo do Zvezdica (ogrodje za gradnjo komunikacijskih aplikacij), avtomatizacija telefonije in inštalacij freepbx (spletni vmesnik za Zvezdica). Če so bile potrebe podjetja brez posebnosti in so spadale v zmožnosti freepbx - vse je super. Celotna namestitev je potekala v XNUMX urah, podjetje je prejelo nastavljeno telefonsko centralo, uporabniku prijazen vmesnik in kratko izobraževanje ter podporo po želji.

Toda najbolj zanimive naloge so bile nestandardne in potem ni bilo tako čudovito. Zvezdica lahko naredi veliko, vendar je bilo za vzdrževanje spletnega vmesnika v delujočem stanju potrebno porabiti večkrat več časa. Tako lahko majhna podrobnost traja veliko dlje kot namestitev ostale PBX. In ne gre za to, da pisanje spletnega vmesnika traja veliko časa, ampak bistvo je v arhitekturnih značilnostih freepbx. Arhitekturni pristopi in metode freepbx je bil postavljen v času php4 in v tistem trenutku je že obstajal php5.6, na katerem je bilo vse mogoče narediti preprostejše in priročnejše.

Kaplja čez rob so bili grafični diagrami v obliki diagrama. Ko sem poskušal zgraditi nekaj takega za freepbx, sem ugotovil, da ga bom moral precej prepisati in lažje bom zgraditi nekaj novega.

Ključne zahteve so bile:

• preprosta nastavitev, intuitivno dostopna tudi skrbniku začetniku. Tako podjetja ne potrebujejo vzdrževanja PBX z naše strani,
• enostavno spreminjanje, tako da so naloge rešene pravočasno,
• enostavnost integracije s PBX. U freepbx ni bilo API-ja za spreminjanje nastavitev, tj. Ne morete na primer ustvariti skupin ali glasovnih menijev iz aplikacije tretje osebe, ampak samo iz samega API-ja Zvezdica,
• opensource - za programerje je to izjemno pomembno za spremembe za stranko.

Ideja hitrejšega razvoja je bila, da bi bile vse funkcionalnosti sestavljene iz modulov v obliki objektov. Vsi objekti so morali imeti skupni nadrejeni razred, kar pomeni, da so imena vseh glavnih funkcij že znana in zato že obstajajo privzete izvedbe. Objekti vam bodo omogočili dramatično zmanjšanje števila argumentov v obliki asociativnih nizov s ključi nizov, kar lahko najdete v freepbx To je bilo mogoče s pregledom celotne funkcije in ugnezdenih funkcij. V primeru predmetov bo banalno samodejno dokončanje pokazalo vse lastnosti in na splošno bo večkrat poenostavilo življenje. Poleg tega dedovanje in redefinicija že rešujeta številne težave s spremembami.

Naslednja stvar, ki je upočasnila čas predelave in se ji je bilo vredno izogniti, je bilo podvajanje. Če obstaja modul, odgovoren za klicanje zaposlenega, ga morajo vsi drugi moduli, ki morajo poslati klic zaposlenemu, uporabiti in ne ustvarjati lastnih kopij. Torej, če morate nekaj spremeniti, potem boste morali spremeniti samo na enem mestu in iskanje "kako deluje" je treba izvesti na enem mestu in ne iskati po celotnem projektu.

Prva verzija in prve napake

Prvi prototip je bil pripravljen v enem letu. Celotna PBX je bila, kot je bilo načrtovano, modularna, moduli pa so lahko dodali ne le nove funkcionalnosti za obdelavo klicev, ampak tudi spremenili sam spletni vmesnik.

Da, ideja o izdelavi dialplana v obliki takšne sheme ni moja, vendar je zelo priročna in enako sem naredil za Zvezdica.

S pisanjem modula bi lahko programerji že:

• ustvarite lastno funkcionalnost za obdelavo klicev, ki jo lahko postavite na diagram, kot tudi v meni elementov na levi strani,
• ustvarite lastne strani za spletni vmesnik in dodajte svoje predloge obstoječim stranem (če je razvijalec strani to predvidel),
• dodajte svoje nastavitve na glavni zavihek z nastavitvami ali ustvarite lasten zavihek z nastavitvami,
• programer lahko podeduje obstoječ modul, spremeni del funkcionalnosti in ga registrira pod novim imenom ali zamenja originalni modul.

Na primer, tako lahko ustvarite svoj glasovni meni:

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

Prve kompleksne izvedbe so prinesle prvi ponos in prva razočaranja. Vesel sem bil, da je delovalo, da sem že lahko reproducirala glavne značilnosti freepbx. Vesel sem bil, da je bila ljudem ideja sheme všeč. Možnosti za poenostavitev razvoja je bilo še veliko, a že takrat so se nekatera opravila že poenostavljala.

API za spreminjanje konfiguracije PBX je bil razočaranje - rezultat sploh ni bil tak, kot smo si želeli. Ubral sem isto načelo kot pri freepbx, s klikom na gumb Uporabi se ponovno ustvari celotna konfiguracija in znova zaženejo moduli.

Izgleda takole:

*Dialplan je pravilo (algoritem), po katerem se klic obdela.

Toda s to možnostjo ni mogoče napisati običajnega API-ja za spreminjanje nastavitev PBX. Prvič, postopek uporabe sprememb za Zvezdica predolg in zahteva veliko virov.
Drugič, ne morete poklicati dveh funkcij hkrati, ker oba bosta ustvarila konfiguracijo.
Tretjič, uporablja vse nastavitve, vključno s tistimi, ki jih je naredil skrbnik.

V tej različici, kot v Askozia, je bilo mogoče generirati konfiguracijo samo spremenjenih modulov in znova zagnati samo potrebne module, vendar so vse to polovični ukrepi. Treba je bilo spremeniti pristop.

Druga različica. Nos izvlečen rep zaljubljen

Zamisel za rešitev težave ni bila ponovna izdelava konfiguracije in klicnega načrta za Zvezdica, vendar shranite podatke v zbirko podatkov in jih preberite neposredno med obdelavo klica. Zvezdica Konfiguracije sem že znal brati iz baze, samo spremenite vrednost v bazi in naslednji klic bo obdelan ob upoštevanju sprememb, funkcija pa je bila popolna za branje parametrov dialplan REALTIME_HASH.

Na koncu niti ponovni zagon ni bil potreben Zvezdica pri spreminjanju nastavitev in vse nastavitve so se začele uporabljati takoj Zvezdica.

Edina sprememba klicnega načrta je dodajanje internih številk in nasveti. Toda to so bile majhne spremembe

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

Z lahkoto lahko dodate ali spremenite vrstico v načrtu klicanja Ami (kontrolni vmesnik Zvezdica) in ponovni zagon celotnega klicnega načrta ni potreben.

To je rešilo težavo s konfiguracijskim API-jem. Lahko celo greste neposredno v bazo podatkov in dodate novo skupino ali spremenite na primer čas klicanja v polju »čas klicanja« za skupino in naslednji klic bi že trajal določen čas (to ni priporočilo za dejanje, saj nekatere operacije API-ja zahtevajo Ami klice).

Prve težke izvedbe so spet prinesle prvi ponos in razočaranje. Vesel sem bil, da je uspelo. Baza je postala kritičen člen, odvisnost od diska se je povečala, več je bilo tveganj, a je vse delovalo stabilno in brez težav. In kar je najpomembnejše, zdaj je vse, kar je bilo mogoče storiti prek spletnega vmesnika, mogoče narediti prek API-ja in uporabljene so bile iste metode. Poleg tega se je spletni vmesnik znebil gumba »uporabi nastavitve za PBX«, na katerega so skrbniki pogosto pozabili.

Razočaranje je bilo, da se je razvoj zapletel. Od prve različice je jezik PHP ustvaril klicni načrt v jeziku Zvezdica in izgleda popolnoma neberljivo, poleg jezika samega Zvezdica za pisanje dialplana je izjemno primitivno.

Kako je bilo videti:

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

V drugi različici je dialplan postal univerzalen, vključeval je vse možne možnosti obdelave glede na parametre in njegova velikost se je znatno povečala. Vse to je močno upočasnilo razvojni čas in že sama misel, da je spet treba posegati v dialplan, me je razžalostila.

Tretja različica

Ideja za rešitev problema ni bila ustvarjanje Zvezdica dialplan iz php in uporabite FastAGI in napišite vsa pravila obdelave v samem PHP. FastAGI omogoča Zvezdica, za obdelavo klica se povežite z vtičnico. Od tam prejemajte ukaze in pošiljajte rezultate. Tako je logika dialplana že zunaj meja Zvezdica in se lahko napiše v katerem koli jeziku, v mojem primeru v PHP.

Bilo je veliko poskusov in napak. Glavna težava je bila, da sem imel že veliko razredov/datotek. Za ustvarjanje objektov, njihovo inicializacijo in medsebojno registracijo je trajalo približno 1,5 sekunde, in te zakasnitve na klic ni nekaj, kar bi lahko prezrli.

Inicializacija bi se morala zgoditi samo enkrat, zato se je iskanje rešitve začelo s pisanjem storitve v php z uporabo Pthreads. Po enem tednu eksperimentiranja je bila ta možnost opuščena zaradi zapletenosti delovanja razširitve. Po enem mesecu testiranja sem moral opustiti tudi asinhrono programiranje v PHP; potreboval sem nekaj preprostega, znanega vsakemu PHP začetniku, veliko razširitev za PHP pa je sinhronih.

Rešitev je bila naša lastna večnitna storitev v C, ki je bila prevedena s PHPLIB. Naloži vse datoteke ATS php, počaka, da se vsi moduli inicializirajo, med seboj doda povratni klic in ko je vse pripravljeno, predpomni. Pri povpraševanju po FastAGI ustvari se tok, v njem se reproducira kopija iz predpomnilnika vseh razredov in podatkov, zahteva pa se posreduje funkciji php.

S to rešitvijo čas od pošiljanja klica naši storitvi do prvega ukaza Zvezdica zmanjšal z 1,5s na 0,05s in je ta čas nekoliko odvisen od velikosti projekta.

Posledično se je čas za razvoj klicnega načrta znatno zmanjšal in to lahko cenim, saj sem moral celoten klicni načrt vseh modulov prepisati v PHP. Prvič, metode bi morale biti že napisane v php za pridobitev predmeta iz baze podatkov; potrebne so bile za prikaz v spletnem vmesniku, in drugič, in to je glavna stvar, končno je mogoče udobno delati z nizi s številkami in nizi z bazo podatkov in številnimi razširitvami PHP.

Za obdelavo klicnega načrta v razredu modula morate implementirati funkcijo dialplanDynamicCall in argument pbxCallRequest bo vseboval predmet za interakcijo Zvezdica.

Poleg tega je postalo mogoče odpraviti napake v dialplanu (php ima xdebug in deluje za našo storitev), korak za korakom se lahko premikate z ogledom vrednosti spremenljivk.

Klicni podatki

Vsaka analitika in poročila zahtevajo pravilno zbrane podatke in tudi ta PBX blok je šel skozi veliko poskusov in napak od prve do tretje različice. Pogosto so podatki o klicu znak. En klic = en posnetek: kdo je klical, kdo se je oglasil, koliko časa sta govorila. V bolj zanimivih možnostih je dodaten znak, ki označuje, kateri uslužbenec PBX je bil poklican med klicem. A vse to pokrije le del potreb.

Začetne zahteve so bile:

• shranite ne samo koga je PBX klicala, ampak tudi kdo je odgovoril, ker obstajajo prestrezanja in to bo treba upoštevati pri analizi klicev,
• čas pred povezovanjem z zaposlenim. noter freepbx in nekaterih drugih telefonskih centralah, velja, da je klic sprejet takoj, ko telefonska centrala sprejme slušalko. Toda za glasovni meni morate že dvigniti slušalko, zato so vsi klici sprejeti in čakalna doba za odgovor postane 0-1 sekunda. Zato je bilo odločeno, da se prihrani ne le čas pred odgovorom, ampak čas pred povezavo s ključnimi moduli (modul sam nastavi to zastavico. Trenutno je to »Zaposleni«, »Zunanja linija«),
• za bolj zapleten načrt klicanja, ko klic potuje med različnimi skupinami, je bilo treba imeti možnost pregledati vsak element posebej.

Najboljša možnost se je izkazala, da PBX moduli ob klicih pošiljajo podatke o sebi in jih na koncu shranijo v obliki drevesa.

Izgleda takole:

Najprej splošne informacije o razpisu (kot vsi drugi - nič posebnega).

1. Prejeli klic na zunanji liniji "Za testo"ob 05:55:52 iz številke 89295671458 na številko 89999999999, na koncu se je oglasila uslužbenka"Tajnik2» s številko 104. Stranka je čakala 60 sekund in govorila 36 sekund.
2. Zaposleni"Tajnik2"pokliče 112 in se oglasi uslužbenec"Vodja1» po 8 sekundah. Pogovarjata se 14 sekund.
3. Stranka se prenese na zaposlenega "vodja1« kjer se pogovarjata še 13 sekund

Toda to je vrh ledene gore, za vsak zapis lahko dobite podrobno zgodovino klicev prek PBX.

Vse informacije so predstavljene kot gnezdenje klicev:

1. Prejeli klic na zunanji liniji "Za testo» ob 05:55:52 s številke 89295671458 na številko 89999999999.
2. Ob 05:55:53 zunanja linija pošlje klic dohodnemu krogu "Test»
3. Pri obdelavi klica po shemi se modul “klic upravitelja", v katerem je klic 16 sekund. To je modul, razvit za stranko.
4. Modul "klic upravitelja" pošlje klic uslužbencu, odgovornemu za številko (stranka) "Vodja1” in počaka 5 sekund na odgovor. Upravitelj ni odgovoril.
5. Modul "klic upravitelja"pošlje klic skupini"Upravitelji CORP" To so drugi menedžerji iste smeri (sedijo v isti sobi) in čakajo 11 sekund na odgovor.
6. Skupina "Upravitelji CORP"pokliče zaposlene"Vodja1, Vodja2, Vodja3"hkrati za 11 sekund. Ni odgovora.
7. Klic upravitelja se konča. In vezje pošlje klic modulu "Izbira poti iz 1c" Tudi modul, napisan za naročnika. Tukaj je bil klic obdelan 0 sekund.
8. Vezje pošlje klic v glasovni meni "Osnovno z dodatnim izbiranjem" Naročnik je tam čakal 31 sekund, dodatnega izbiranja ni bilo.
9. Shema pošlje klic skupini "Tajnice«, kjer je naročnik čakal 12 sekund.
10. V skupini sta klicana 2 zaposlena hkrati "Tajnik1"In"Tajnik2" in po 12 sekundah se oglasi zaposleni "Tajnik2" Odgovor na klic se podvoji v nadrejene klice. Izkazalo se je, da je v skupini odgovoril "Tajnik2", pri klicu je vezje odgovorilo "Tajnik2" in odgovoril na klic na zunanji liniji z "Tajnik2".

Shranjevanje informacij o vsaki operaciji in njihovem gnezdenju bo omogočilo preprosto izdelavo poročil. Poročilo o glasovnem meniju vam bo pomagalo ugotoviti, koliko pomaga ali ovira. Izdelajte poročilo o zgrešenih klicih zaposlenih, pri čemer upoštevajte, da je bil klic prestrežen in se zato ne šteje za zgrešenega ter upoštevajte, da je šlo za skupinski klic in se je prej oglasil nekdo drug, kar pomeni, da tudi klic ni bil zgrešen.

Takšno shranjevanje informacij vam bo omogočilo, da vzamete vsako skupino posebej in ugotovite, kako učinkovito deluje, ter zgradite graf odgovorjenih in zgrešenih skupin po urah. Kako natančna je povezava z odgovornim upraviteljem, lahko preverite tudi z analizo nakazil po povezavi z upraviteljem.

Izvedete lahko tudi precej netipične študije, na primer, kako pogosto številke, ki niso v bazi podatkov, pokličejo pravo razširitev ali kolikšen odstotek odhodnih klicev je preusmerjen na mobilni telefon.

Kakšen je rezultat?

Za vzdrževanje telefonske centrale ni potreben strokovnjak, to lahko stori najbolj navaden skrbnik - preizkušeno v praksi.

Za spremembe niso potrebni strokovnjaki z resnimi kvalifikacijami, zadostuje poznavanje PHP, ker Napisani so že moduli za protokol SIP, pa za čakalno vrsto, pa za klicanje zaposlenega in drugo. Obstaja ovojni razred za Zvezdica. Za razvoj modula lahko programer (in v dobrem smislu bi moral) poklicati že pripravljene module. In znanje Zvezdica so popolnoma nepotrebni, če stranka zahteva dodajanje strani z novim poročilom. Toda praksa kaže, da čeprav so programerji tretjih oseb kos, se brez dokumentacije in normalnega pokrivanja komentarjev počutijo negotove, zato je še vedno prostor za izboljšave.

Moduli lahko:

• ustvarjanje novih zmogljivosti obdelave klicev,
• dodajte nove bloke v spletni vmesnik,
• podedovati katerega koli obstoječega modula, redefinirati funkcije in ga nadomestiti ali pa preprosto biti nekoliko spremenjena kopija,
• dodajte svoje nastavitve v predlogo nastavitev drugih modulov in še veliko več.

Nastavitve PBX prek API-ja. Kot je opisano zgoraj, so vse nastavitve shranjene v bazi podatkov in prebrane v času klica, tako da lahko spremenite vse nastavitve PBX prek API-ja. Pri klicu API-ja se konfiguracija ne ustvari znova in moduli ne zaženejo znova, zato ni pomembno, koliko nastavitev in zaposlenih imate. Zahteve API se izvajajo hitro in se ne blokirajo.

PBX shranjuje vse ključne operacije s klici s trajanjem (čakanje/pogovor), gnezdenjem in v smislu PBX (zaposleni, skupina, zunanja linija, ne kanal, številka). To vam omogoča sestavljanje različnih poročil za določene stranke, večina dela pa je ustvariti uporabniku prijazen vmesnik.

Čas bo pokazal, kaj bo naprej. Še vedno je veliko odtenkov, ki jih je treba predelati, še vedno je veliko načrtov, vendar je minilo leto dni od nastanka 3. različice in že lahko rečemo, da ideja deluje. Glavna pomanjkljivost različice 3 so viri strojne opreme, vendar je to običajno tisto, kar morate plačati za lažji razvoj.

Vir: www.habr.com