🥇 Sagan um eitt verkefni eða hvernig ég eyddi 7 árum í að búa til PBX byggða á stjörnu og Php

Margir ykkar, eins og ég, höfðuð örugglega hugmynd um að gera eitthvað einstakt. Í þessari grein mun ég lýsa tæknilegum vandamálum og lausnum sem ég þurfti að takast á við þegar ég þróaði PBX. Kannski mun þetta hjálpa einhverjum að ákveða sína eigin hugmynd og einhvern til að feta brautina, því ég naut líka góðs af reynslu frumkvöðla.

Hugmynd og helstu kröfur

Og allt byrjaði einfaldlega með ást fyrir Stjörnustöð (rammi til að byggja upp samskiptaforrit), sjálfvirkni símtækni og innsetningar ÓkeypisPBX (vefviðmót fyrir Stjörnustöð). Ef þarfir fyrirtækisins væru án sérstakra og féllu undir getu ÓkeypisPBX - allt er frábært. Öll uppsetningin fór fram innan sólarhrings, fyrirtækið fékk stillta PBX, notendavænt viðmót og stutta þjálfun auk stuðnings ef óskað var.

En áhugaverðustu verkefnin voru óstöðluð og þá var þetta ekki svo stórkostlegt. Stjörnustöð getur gert mikið en til að halda vefviðmótinu í lagi þurfti að eyða margfalt meiri tíma. Svo lítið smáatriði gæti tekið miklu lengri tíma en að setja upp restina af PBX. Og málið er ekki að það taki langan tíma að skrifa vefviðmót, heldur er málið í byggingareiginleikum ÓkeypisPBX. Arkitektúr nálganir og aðferðir ÓkeypisPBX var sett upp á þeim tíma sem php4, og á því augnabliki var þegar php5.6 þar sem allt var hægt að gera einfaldara og þægilegra.

Síðasta hálmstráið voru grafískar dialplans í formi skýringarmyndar. Þegar ég reyndi að smíða eitthvað svona fyrir ÓkeypisPBX, ég áttaði mig á því að ég þyrfti að endurskrifa það verulega og það væri auðveldara að byggja eitthvað nýtt.

Helstu kröfurnar voru:

einföld uppsetning, aðgengileg jafnvel fyrir nýliði stjórnanda. Þannig þurfa fyrirtæki ekki viðhald á PBX af okkar hálfu,
auðvelt að breyta þannig að verkefni séu leyst á hæfilegum tíma,
auðveld samþætting við PBX. U ÓkeypisPBX það var ekkert API til að breyta stillingum, þ.e. Þú getur til dæmis ekki búið til hópa eða raddvalmyndir úr forriti frá þriðja aðila, aðeins API sjálfu Stjörnustöð,
opensource - fyrir forritara er þetta afar mikilvægt fyrir breytingar fyrir viðskiptavininn.

Hugmyndin um hraðari þróun var að láta alla virkni samanstanda af einingum í formi hluta. Allir hlutir þurftu að hafa sameiginlegan yfirflokk, sem þýðir að nöfn allra helstu aðgerða eru þegar þekkt og því eru nú þegar sjálfgefnar útfærslur. Hlutir gera þér kleift að draga verulega úr fjölda færa í formi tengdra fylkja með strengjalyklum, sem þú getur fundið út í ÓkeypisPBX Það var hægt með því að skoða allt fallið og hreiður föll. Þegar um er að ræða hluti mun banal sjálfvirk útfylling sýna alla eiginleika og almennt einfalda lífið margfalt. Auk þess leysir erfðir og endurskilgreining nú þegar mörg vandamál með breytingum.

Það næsta sem hægði á endurvinnslutímanum og var þess virði að forðast var tvíverknað. Ef það er eining sem ber ábyrgð á að hringja í starfsmann, þá ættu allar aðrar einingar sem þurfa að senda símtal til starfsmanns að nota það, en ekki búa til sín eigin afrit. Svo ef þú þarft að breyta einhverju, þá þarftu að breyta aðeins á einum stað og leitin að „hvernig það virkar“ ætti að fara fram á einum stað og ekki leitað í öllu verkefninu.

Fyrsta útgáfa og fyrstu villur

Fyrsta frumgerðin var tilbúin innan árs. Öll PBX, eins og áætlað var, var einingakerfi og einingarnar gátu ekki aðeins bætt við nýjum virkni til að vinna úr símtölum, heldur einnig breytt vefviðmótinu sjálfu.

Já, hugmyndin um að búa til valmynd í formi slíks kerfis er ekki mín, en hún er mjög þægileg og ég gerði það sama fyrir Stjörnustöð.

Með því að skrifa einingu gætu forritarar nú þegar:

búa til þína eigin virkni fyrir símtalavinnslu, sem hægt er að setja á skýringarmyndina, sem og í valmyndinni með þáttum til vinstri,
búðu til þínar eigin síður fyrir vefviðmótið og bættu sniðmátunum þínum við núverandi síður (ef síðuframleiðandinn hefur séð um þetta),
bættu stillingunum þínum við aðalstillingaflipann eða búðu til þinn eigin stillingarflipa,
forritarinn getur erft frá núverandi einingu, breytt hluta af virkninni og skráð hana undir nýju nafni eða skipt út upprunalegu einingunni.

Til dæmis, þetta er hvernig þú getur búið til þína eigin raddvalmynd:

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

Fyrstu flóknu útfærslurnar færðu fyrsta stoltið og fyrstu vonbrigðin. Ég var ánægður með að það virkaði, að ég var nú þegar fær um að endurskapa helstu eiginleikana ÓkeypisPBX. Ég var ánægður með að fólki líkaði hugmyndin að kerfinu. Það voru enn margir möguleikar til að einfalda þróun, en jafnvel á þeim tíma var verið að gera sum verkefnin auðveldari.

Forritaskilin til að breyta PBX stillingum voru vonbrigði - niðurstaðan var alls ekki sú sem við vildum. Ég tók sömu reglu og í ÓkeypisPBX, með því að smella á Nota hnappinn er öll stillingin endurgerð og einingarnar endurræstar.

Það lítur svona út:

*Dialplan er regla (algrím) sem símtal er unnið eftir.

En með þessum valkosti er ómögulegt að skrifa venjulega API til að breyta PBX stillingum. Í fyrsta lagi aðgerðin að beita breytingum á Stjörnustöð of langur og auðlindafrekur.
Í öðru lagi geturðu ekki kallað til tvær aðgerðir á sama tíma, vegna þess að báðir munu búa til stillinguna.
Í þriðja lagi notar það allar stillingar, þar á meðal þær sem kerfisstjórinn gerir.

Í þessari útgáfu, eins og í Askozia, það var hægt að búa til stillingar á aðeins breyttum einingum og endurræsa aðeins nauðsynlegar einingar, en þetta eru allt hálfgerðir. Það var nauðsynlegt að breyta um nálgun.

Önnur útgáfa. Nef dregið út hali fastur

Hugmyndin til að leysa vandamálið var ekki að endurskapa stillingar og valmynd fyrir Stjörnustöð, en vista upplýsingar í gagnagrunninn og lesa beint úr gagnagrunninum á meðan símtalið er unnið. Stjörnustöð Ég vissi nú þegar hvernig á að lesa stillingar úr gagnagrunninum, breyttu bara gildinu í gagnagrunninum og næsta símtal verður unnið með hliðsjón af breytingunum og aðgerðin var fullkomin til að lesa dialplan færibreytur REALTIME_HASH.

Að lokum var engin þörf á að endurræsa Stjörnustöð þegar stillingum var breytt og byrjað var að beita öllum stillingum strax á Stjörnustöð.

Einu breytingarnar á símanúmerinu eru að bæta við viðbyggingarnúmerum og vísbending. En þetta voru litlar punktabreytingar

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

Þú getur auðveldlega bætt við eða breytt línu í valmyndinni með því að nota Ami (stýringarviðmót Stjörnustöð) og ekki er þörf á endurræsingu á öllu valmyndinni.

Þetta leysti vandamálið með stillingar API. Þú gætir jafnvel farið beint inn í gagnagrunninn og bætt við nýjum hópi eða breytt t.d. innhringingartímanum í „dialtime“ reitnum fyrir hópinn og næsta símtal myndi nú þegar endast í tilgreindan tíma (Þetta eru ekki ráðleggingar fyrir aðgerð, þar sem sumar API aðgerðir krefjast Ami símtöl).

Fyrstu erfiðu útfærslurnar ollu aftur fyrsta stolti og vonbrigðum. Ég var feginn að það virkaði. Gagnagrunnurinn varð mikilvægur hlekkur, ósjálfstæði á disknum jókst, áhættan var meiri, en allt virkaði stöðugt og án vandræða. Og síðast en ekki síst, nú var hægt að gera allt sem hægt var að gera í gegnum vefviðmótið í gegnum API og sömu aðferðir voru notaðar. Að auki losaði vefviðmótið við „beita stillingum á PBX“ hnappinn, sem stjórnendur gleymdu oft.

Vonbrigðin urðu að þróunin varð flóknari. Frá fyrstu útgáfunni hefur PHP tungumálið búið til dialplan á tungumálinu Stjörnustöð og það lítur algjörlega ólæsilegt út, auk tungumálsins sjálfs Stjörnustöð fyrir að skrifa dialplan er það mjög frumstætt.

Hvernig það leit ú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'))

Í seinni útgáfunni varð valmyndin alhliða, hún innihélt alla mögulega vinnslumöguleika eftir breytum og stærð hennar jókst verulega. Allt þetta hægði mjög á þróunartímanum og tilhugsunin um að enn og aftur væri nauðsynlegt að trufla valmyndina gerði mig hrygg.

Þriðja útgáfa

Hugmyndin um að leysa vandamálið var ekki að búa til Stjörnustöð dialplan frá php og nota FastAGI og skrifa allar vinnslureglur í PHP sjálft. FastAGI gerir Stjörnustöð, til að vinna úr símtalinu, tengdu við innstunguna. Fáðu skipanir þaðan og sendu niðurstöður. Þannig er rökfræði dialplansins þegar utan markanna Stjörnustöð og er hægt að skrifa á hvaða tungumáli sem er, í mínu tilfelli í PHP.

Mikið var um að reyna og villa. Aðal vandamálið var að ég var nú þegar með fullt af flokkum/skrám. Það tók um 1,5 sekúndur að búa til hluti, frumstilla þá og skrá hver annan hver við annan, og þessi seinkun á símtal er ekki eitthvað sem hægt er að hunsa.

Frumstilling hefði aðeins átt að gerast einu sinni og því hófst leit að lausn með því að skrifa þjónustu í php með því að nota Pthreads. Eftir viku tilraunir var þessi valkostur settur á hilluna vegna ranghala hvernig þessi framlenging virkar. Eftir mánaðarpróf þurfti ég líka að hætta við ósamstillta forritun í PHP; ég þurfti eitthvað einfalt, sem allir PHP byrjendur þekkja, og margar viðbætur fyrir PHP eru samstilltar.

Lausnin var okkar eigin fjölþráða þjónusta í C, sem var sett saman með PHPLIB. Það hleður inn öllum ATS php skránum, bíður eftir að allar einingarnar séu frumstilltar, bætir við svarhringingu við hvert annað og þegar allt er tilbúið, vistar það í skyndiminni. Þegar spurt er eftir FastAGI straumur er búinn til, afrit úr skyndiminni allra flokka og gögn eru afrituð í honum og beiðnin er send til php fallsins.

Með þessari lausn er tíminn frá því að hringt er í þjónustu okkar til fyrstu skipunar Stjörnustöð lækkað úr 1,5 sekúndum í 0,05 sekúndur og fer þessi tími aðeins eftir stærð verkefnisins.

Fyrir vikið styttist tíminn fyrir þróun dialplan verulega og ég kann að meta það þar sem ég þurfti að endurskrifa alla dialplan allra eininga í PHP. Í fyrsta lagi ættu aðferðir nú þegar að vera skrifaðar í php til að fá hlut úr gagnagrunninum, þær voru nauðsynlegar til að birtast í vefviðmótinu og í öðru lagi, og þetta er aðalatriðið, er loksins hægt að vinna með strengi með tölum og fylkjum á þægilegan hátt. með gagnagrunni ásamt mörgum PHP viðbótum.

Til að vinna úr dialplan í einingaflokknum þarftu að útfæra aðgerðina dialplanDynamicCall og rök pbxCallRequest mun innihalda hlut til að hafa samskipti við Stjörnustöð.

Að auki varð mögulegt að kemba dialplanið (php er með xdebug og það virkar fyrir þjónustu okkar), þú getur farið skref fyrir skref með því að skoða gildi breyta.

Símtalsgögn

Allar greiningar og skýrslur krefjast rétt safnaðra gagna, og þessi PBX-blokk gekk einnig í gegnum miklar tilraunir og villur frá fyrstu til þriðju útgáfu. Oft eru símtalagögn merki. Eitt símtal = ein upptaka: hver hringdi, hver svaraði, hversu lengi þeir töluðu. Í áhugaverðari valkostum er viðbótarskilti sem gefur til kynna hvaða starfsmaður PBX var hringt í í símtalinu. En allt þetta tekur aðeins til hluta af þörfunum.

Upphaflegar kröfur voru:

spara ekki aðeins hvern PBX hringdi, heldur líka hver svaraði, því það eru hleranir og það þarf að taka tillit til þess þegar símtöl eru greind,
tíma áður en þú tengist starfsmanni. Í ÓkeypisPBX og nokkrum öðrum símstöðvum, telst símtalinu svarað um leið og símstöðin tekur upp símann. En fyrir raddvalmyndina þarftu nú þegar að taka upp símann, þannig að öllum símtölum er svarað og biðtími eftir svari verður 0-1 sekúnda. Þess vegna var ákveðið að spara ekki aðeins tímann fyrir svar, heldur tímann fyrir tengingu við lykileiningar (einingin sjálf setur þennan fána. Eins og er er það „Starfsmaður“, „Ytri lína“),
fyrir flóknari valmynd, þegar símtal fer á milli mismunandi hópa, var nauðsynlegt að geta skoðað hvern þátt fyrir sig.

Besti kosturinn reyndist vera þegar PBX einingarnar senda upplýsingar um sig í símtölum og vista upplýsingarnar á endanum í formi trés.

Það lítur svona út:

Í fyrsta lagi almennar upplýsingar um símtalið (eins og allir aðrir - ekkert sérstakt).

Fékk símtal á utanlínu“Fyrir prófið"kl. 05:55:52 úr númerinu 89295671458 í númerið 89999999999, á endanum var svarað af starfsmanni"Ritari 2» með númer 104. Viðskiptavinurinn beið í 60 sekúndur og talaði í 36 sekúndur.
Starfsmaður "Ritari 2„hringir í 112 og starfsmaður svarar“Stjórnandi 1» eftir 8 sekúndur. Þeir tala í 14 sekúndur.
Viðskiptavinur er færður til starfsmanns“stjórnandi 1“ þar sem þeir halda áfram að tala í 13 sekúndur í viðbót

En þetta er toppurinn á ísjakanum; fyrir hverja skrá er hægt að fá nákvæma símtalasögu í gegnum PBX.

Allar upplýsingar eru settar fram sem hreiður af símtölum:

Fékk símtal á utanlínu“Fyrir prófið» á 05:55:52 úr númerinu 89295671458 í númerið 89999999999.
Klukkan 05:55:53 sendir ytri línan símtal í móttökurásina "próf»
Þegar unnið er úr símtali samkvæmt kerfinu er einingin „símtal stjórnanda", þar sem símtalið er 16 sekúndur. Þetta er eining þróuð fyrir viðskiptavininn.
Eining "símtal stjórnanda" sendir símtal til starfsmanns sem ber ábyrgð á númerinu (viðskiptavinur) "Stjórnandi 1“ og bíður í 5 sekúndur eftir svari. Forstjórinn svaraði engu.
Eining "símtal stjórnanda"sendir símtal í hópinn"Stjórnendur fyrirtækja" Þetta eru aðrir stjórnendur í sömu átt (sitja í sama herbergi) og bíða í 11 sekúndur eftir svari.
Hópur „Stjórnendur fyrirtækja"hringir í starfsmenn"Stjórnandi 1, Stjórnandi 2, Stjórnandi 3„samtímis í 11 sekúndur. Ekkert svar.
Símtali framkvæmdastjóra lýkur. Og hringrásin sendir símtal til einingarinnar "Val á leið frá 1c" Einnig eining skrifuð fyrir viðskiptavininn. Hér var símtalið afgreitt í 0 sekúndur.
Hringrásin sendir símtal í raddvalmyndina "Basic með viðbótarhringingu" Viðskiptavinurinn beið þar í 31 sekúndu, það var engin aukahringing.
Kerfið sendir símtal til hópsins "Ritarar“, þar sem viðskiptavinurinn beið í 12 sekúndur.
Í hóp er hringt í 2 starfsmenn á sama tíma "Ritari 1"Og"Ritari 2" og eftir 12 sekúndur svarar starfsmaðurinn "Ritari 2" Svarið við símtalinu er afritað í foreldrasímtöl. Það kemur í ljós að í hópnum svaraði hann „Ritari 2", þegar hringt var í hringinn svaraði "Ritari 2" og svaraði símtalinu á utanlínunni með "Ritari 2'.

Það er vistun upplýsinga um hverja aðgerð og varp þeirra sem gerir það mögulegt að gera skýrslur einfaldlega. Skýrsla um raddvalmyndina mun hjálpa þér að komast að því hversu mikið það hjálpar eða hindrar. Gerðu skýrslu um símtöl sem starfsmenn misstu, að teknu tilliti til þess að símtalið var hlerað og telst því ekki ósvarað, og að teknu tilliti til þess að það var hópsímtal og einhver annar svaraði fyrr, sem þýðir að símtalið var heldur ekki misst af.

Slík upplýsingageymsla gerir þér kleift að taka hvern hóp fyrir sig og ákvarða hversu áhrifaríkan hann virkar, og búa til línurit af svöruðum og gleymdum hópum eftir klukkustund. Einnig er hægt að athuga hversu nákvæm tengingin við ábyrga stjórnanda er með því að greina millifærslurnar eftir tengingu við stjórnandann.

Einnig er hægt að gera nokkuð óhefðbundnar rannsóknir, til dæmis hversu oft númer sem eru ekki í gagnagrunninum hringja í rétta viðsnúninginn eða hversu hátt hlutfall af úthringingum er flutt í farsíma.

Niðurstaðan?

Sérfræðingur þarf ekki að viðhalda PBX, venjulegur stjórnandi getur gert það - prófaður í reynd.

Fyrir breytingar er ekki þörf á sérfræðingum með alvarlega menntun; þekking á PHP er nægjanleg vegna þess Nú þegar hafa verið skrifaðar einingar fyrir SIP samskiptareglur og fyrir biðröðina og til að hringja í starfsmann og aðra. Það er umbúðanámskeið fyrir Stjörnustöð. Til að þróa einingar getur forritari (og á góðan hátt) kallað tilbúnar einingar. Og þekkingu Stjörnustöð eru algjörlega óþörf ef viðskiptavinurinn biður um að bæta við síðu með einhverri nýrri skýrslu. En æfingin sýnir að þrátt fyrir að forritarar frá þriðja aðila geti ráðið við þá finnst þeir óöruggir án skjala og eðlilegrar umfjöllunar um athugasemdir, svo það er enn hægt að gera betur.

Einingar geta:

búa til nýja símtalavinnslugetu,
bæta nýjum kubbum við vefviðmótið,
erfa frá hvaða einingum sem fyrir er, endurskilgreina aðgerðir og skipta um þær, eða einfaldlega vera örlítið breytt afrit,
bættu stillingunum þínum við stillingarsniðmát annarra eininga og margt fleira.

PBX stillingar í gegnum API. Eins og lýst er hér að ofan eru allar stillingar geymdar í gagnagrunninum og lesnar þegar hringt er, svo þú getur breytt öllum PBX stillingum í gegnum API. Þegar hringt er í API er stillingin ekki endurgerð og einingarnar eru ekki endurræstar, því skiptir ekki máli hversu margar stillingar og starfsmenn þú hefur. API beiðnir eru keyrðar hratt og loka ekki hver fyrir aðra.

PBX geymir allar lykilaðgerðir með símtölum með lengd (bið/samtal), hreiður og í PBX-skilmálum (starfsmaður, hópur, ytri lína, ekki rás, númer). Þetta gerir þér kleift að búa til ýmsar skýrslur fyrir tiltekna viðskiptavini og mest af vinnunni er að búa til notendavænt viðmót.

Tíminn mun leiða í ljós hvað gerist næst. Það eru enn mörg blæbrigði sem þarf að endurnýja, það eru enn margar áætlanir, en ár er liðið frá stofnun 3. útgáfunnar og við getum nú þegar sagt að hugmyndin sé að virka. Helsti ókosturinn við útgáfu 3 er vélbúnaðarauðlindir, en þetta er venjulega það sem þú þarft að borga fyrir til að auðvelda þróun.

Heimild: www.habr.com

Sagan um eitt verkefni eða hvernig ég eyddi 7 árum í að búa til PBX byggða á Stjörnu og Php