Tarina yhdestä projektista tai siitä, kuinka vietin 7 vuotta Asterisk- ja Php-pohjaisen PBX:n luomisessa

Varmasti monilla teistä, kuten minulla, oli idea tehdä jotain ainutlaatuista. Tässä artikkelissa kuvailen teknisiä ongelmia ja ratkaisuja, jotka minun oli kohdattava kehitettäessä PBX:ää. Ehkä tämä auttaa jotakuta päättämään omasta ideastaan ​​ja jotakuta seuraamaan syrjäytynyttä polkua, koska minäkin hyötyin pioneerien kokemuksista.

Idea ja keskeiset vaatimukset

Ja kaikki alkoi yksinkertaisesti rakkaudesta tähtimerkki (viestintäsovellusten rakennuskehys), puhelinliikenteen ja laitteistojen automaatio Ilmainen PBX (verkkokäyttöliittymä for tähtimerkki). Jos yrityksen tarpeet olisivat vailla erityispiirteitä ja osuisivat kykyjen sisälle Ilmainen PBX - kaikki on mahtavaa. Koko asennus tapahtui XNUMX tunnissa, yritys sai konfiguroidun PBX:n, käyttäjäystävällisen käyttöliittymän ja lyhyen koulutuksen sekä tarvittaessa tuen.

Mutta mielenkiintoisimmat tehtävät olivat epätyypillisiä, ja sitten se ei ollut niin upea. tähtimerkki voi tehdä paljon, mutta verkkokäyttöliittymän pitämiseksi toimintakunnossa piti käyttää monta kertaa enemmän aikaa. Joten pieni yksityiskohta voi kestää paljon kauemmin kuin muun PBX:n asentaminen. Ja pointti ei ole siinä, että verkkokäyttöliittymän kirjoittaminen vie kauan, vaan pointti on arkkitehtonisissa ominaisuuksissa Ilmainen PBX. Arkkitehtuurin lähestymistavat ja menetelmät Ilmainen PBX asetettiin php4:n aikaan, ja tuolloin oli jo php5.6, jossa kaikesta voitiin tehdä yksinkertaisempaa ja kätevämpää.

Viimeinen pisara oli graafiset kellotaulut kaavion muodossa. Kun yritin rakentaa jotain tällaista varten Ilmainen PBX, Tajusin, että minun pitäisi kirjoittaa se merkittävästi uudelleen ja olisi helpompi rakentaa jotain uutta.

Tärkeimmät vaatimukset olivat:

• yksinkertainen asennus, intuitiivisesti jopa aloittelevan järjestelmänvalvojan käytettävissä. Yritykset eivät siis vaadi PBX-huoltoa puoleltamme,
• helppo muokata niin, että tehtävät ratkaistaan ​​riittävän ajoissa,
• helppo integrointi PBX:n kanssa. U Ilmainen PBX asetusten muuttamiseen ei ollut API:ta, ts. Et voi esimerkiksi luoda ryhmiä tai äänivalikoita kolmannen osapuolen sovelluksesta, vain itse API:sta tähtimerkki,
• avoin lähdekoodi - ohjelmoijille tämä on erittäin tärkeää asiakkaan muokkauksille.

Nopeamman kehityksen ideana oli saada kaikki toiminnot koostumaan moduuleista objektien muodossa. Kaikilla objekteilla tuli olla yhteinen yläluokka, mikä tarkoittaa, että kaikkien päätoimintojen nimet ovat jo tiedossa ja siksi oletustoteutuksia on jo olemassa. Objektien avulla voit vähentää dramaattisesti argumenttien määrää assosiatiivisten taulukoiden muodossa merkkijonoavaimilla, jotka voit selvittää Ilmainen PBX Se oli mahdollista tarkastelemalla koko funktiota ja sisäkkäisiä funktioita. Objektien tapauksessa banaalinen automaattinen täydennys näyttää kaikki ominaisuudet ja yleensä yksinkertaistaa elämää monta kertaa. Lisäksi perinnöllisyys ja uudelleenmäärittely ratkaisee jo monia muutosten aiheuttamia ongelmia.

Seuraava asia, joka hidasti työskentelyaikaa ja jota oli syytä välttää, oli päällekkäisyys. Jos on moduuli, joka vastaa työntekijän soittamisesta, kaikkien muiden moduulien, joiden on lähetettävä puhelu työntekijälle, tulee käyttää sitä, eikä luoda omia kopioita. Joten jos sinun on muutettava jotain, sinun on muutettava vain yhdessä paikassa ja haku "miten se toimii" tulisi suorittaa yhdestä paikasta, eikä etsiä koko projektin ajan.

Ensimmäinen versio ja ensimmäiset virheet

Ensimmäinen prototyyppi valmistui vuodessa. Koko PBX oli suunnitellusti modulaarinen, ja moduulit pystyivät paitsi lisäämään uusia toimintoja puhelujen käsittelyyn, myös muuttamaan itse web-käyttöliittymää.

Kyllä, ajatus soittosuunnitelman rakentamisesta tällaisen kaavion muodossa ei ole minun, mutta se on erittäin kätevää ja tein samoin tähtimerkki.

Kirjoittamalla moduulin ohjelmoijat voivat jo:

• luo omat toiminnot puhelunkäsittelyyn, joka voidaan sijoittaa kaavioon sekä vasemmanpuoleiseen elementtivalikkoon,
• luo omat sivusi verkkokäyttöliittymään ja lisää mallisi olemassa oleville sivuille (jos sivun kehittäjä on varannut tämän),
• lisää asetuksesi pääasetusvälilehteen tai luo oma asetusvälilehti,
• ohjelmoija voi periä olemassa olevasta moduulista, muuttaa osan toimivuudesta ja rekisteröidä sen uudella nimellä tai korvata alkuperäisen moduulin.

Voit esimerkiksi luoda oman äänivalikon seuraavasti:

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

Ensimmäiset monimutkaiset toteutukset toivat ensimmäisen ylpeyden ja ensimmäiset pettymykset. Olin iloinen, että se toimi, että pystyin jo toistamaan tärkeimmät ominaisuudet Ilmainen PBX. Olin iloinen, että ihmiset pitivät suunnitelmasta. Vaihtoehtoja kehittämisen yksinkertaistamiseksi oli vielä monia, mutta silloinkin osa tehtävistä oli jo helpottunut.

PBX-kokoonpanon muuttamisen API oli pettymys - tulos ei ollut ollenkaan sitä mitä halusimme. Otin saman periaatteen kuin tuossa Ilmainen PBX, napsauttamalla Käytä-painiketta, koko kokoonpano luodaan uudelleen ja moduulit käynnistetään uudelleen.

Näyttää siltä:

*Dialplan on sääntö (algoritmi), jonka mukaan puhelu käsitellään.

Mutta tällä vaihtoehdolla on mahdotonta kirjoittaa normaalia APIa PBX-asetusten muuttamiseksi. Ensinnäkin muutosten soveltamisen toiminta tähtimerkki liian pitkä ja resurssiintensiivinen.
Toiseksi, et voi kutsua kahta funktiota samanaikaisesti, koska molemmat luovat kokoonpanon.
Kolmanneksi se käyttää kaikkia asetuksia, mukaan lukien järjestelmänvalvojan tekemät.

Tässä versiossa, kuten Askozia, oli mahdollista luoda vain muuttuneiden moduulien konfiguraatio ja käynnistää uudelleen vain tarvittavat moduulit, mutta nämä ovat kaikki puolimittoja. Oli tarpeen muuttaa lähestymistapaa.

Toinen versio. Nenä ulos vedetty häntä jumissa

Ajatuksena ongelman ratkaisemiseksi ei ollut luoda uudelleen kokoonpanoa ja soittosuunnitelmaa tähtimerkki, mutta tallenna tiedot tietokantaan ja lue tietokannasta suoraan puhelun käsittelyn aikana. tähtimerkki Osasin jo lukea konfiguraatioita tietokannasta, muuta vain arvoa tietokannassa ja seuraava puhelu käsitellään ottaen huomioon muutokset, ja toiminto oli täydellinen valintasuunnitelman parametrien lukemiseen REALTIME_HASH.

Lopulta ei tarvinnut edes käynnistää uudelleen tähtimerkki asetuksia muuttaessa ja kaikkia asetuksia alettiin soveltaa välittömästi tähtimerkki.

Ainoat muutokset soittosuunnitelmaan ovat alanumeroiden ja -numeroiden lisääminen vihjeitä. Mutta nämä olivat pieniä muutoksia

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

Voit helposti lisätä tai muuttaa linjan valintasuunnitelmaan käyttämällä Ami (ohjausliittymä tähtimerkki) eikä koko soittosuunnitelmaa tarvita uudelleen.

Tämä ratkaisi määrityssovellusliittymän ongelman. Voit jopa mennä suoraan tietokantaan ja lisätä uuden ryhmän tai muuttaa esimerkiksi soittoaikaa ryhmän "soittoaika"-kentässä ja seuraava puhelu kestäisi jo määritetyn ajan (tämä ei ole suositus toimintoa, koska jotkin API-toiminnot vaativat Ami puhelut).

Ensimmäiset vaikeat toteutukset toivat jälleen ensimmäisen ylpeyden ja pettymyksen. Olin iloinen, että se toimi. Tietokannasta tuli kriittinen linkki, riippuvuus levystä kasvoi, riskejä oli enemmän, mutta kaikki toimi vakaasti ja ilman ongelmia. Ja mikä tärkeintä, nyt kaikki, mikä voidaan tehdä verkkoliittymän kautta, voidaan tehdä API:n kautta, ja käytettiin samoja menetelmiä. Lisäksi verkkokäyttöliittymästä eroon "Käytä asetukset PBX:lle" -painikkeesta, jonka järjestelmänvalvojat usein unohtavat.

Pettymys oli, että kehityksestä tuli monimutkaisempi. Ensimmäisestä versiosta lähtien PHP-kieli on luonut soittosuunnitelman kielelle tähtimerkki ja se näyttää täysin lukemattomalta, plus itse kieli tähtimerkki soittosuunnitelman kirjoittaminen on erittäin alkeellista.

Miltä se näytti:

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

Toisessa versiossa puhelintaulusta tuli universaali, se sisälsi kaikki mahdolliset käsittelyvaihtoehdot parametreista riippuen ja sen koko kasvoi merkittävästi. Kaikki tämä hidasti kehitysaikaa suuresti, ja jo pelkkä ajatus siitä, että oli jälleen kerran tarpeen puuttua soittosuunnitelmaan, sai minut surulliseksi.

Kolmas versio

Ajatus ongelman ratkaisemisesta ei ollut synnyttäminen tähtimerkki dialplan php:stä ja käytä FastAGI ja kirjoittaa kaikki käsittelysäännöt itse PHP:hen. FastAGI sen avulla tähtimerkki, käsittele puhelu muodostamalla yhteys pistorasiaan. Vastaanota komentoja sieltä ja lähetä tulokset. Näin ollen soittosuunnitelman logiikka on jo rajojen ulkopuolella tähtimerkki ja voidaan kirjoittaa millä tahansa kielellä, minun tapauksessani PHP:llä.

Oli paljon yritystä ja erehdystä. Suurin ongelma oli, että minulla oli jo paljon luokkia/tiedostoja. Objektien luomiseen, alustamiseen ja toistensa rekisteröimiseen kului noin 1,5 sekuntia, eikä tätä puhelukohtaista viivettä voida jättää huomiotta.

Alustus olisi pitänyt tapahtua vain kerran ja siksi ratkaisun etsiminen alkoi palvelun kirjoittamisesta php:llä Pthreads. Viikon kokeilun jälkeen tämä vaihtoehto hylättiin tämän laajennuksen toiminnan monimutkaisuuden vuoksi. Kuukauden testauksen jälkeen jouduin myös luopumaan asynkronisesta ohjelmoinnista PHP:ssä; tarvitsin jotain yksinkertaista, jokaiselle PHP-aloittelijalle tuttua, ja monet PHP:n laajennukset ovat synkronisia.

Ratkaisu oli oma monisäikeinen palvelumme C-kielellä, joka on käännetty PHPLIB. Se lataa kaikki ATS php -tiedostot, odottaa kaikkien moduulien alustumista, lisää toisilleen takaisinkutsun ja kun kaikki on valmis, tallentaa sen välimuistiin. Kun tiedustelee osoitteesta FastAGI luodaan stream, kopio välimuistista kaikista luokista ja tiedoista toistetaan siihen ja pyyntö välitetään php-funktiolle.

Tällä ratkaisulla aika puhelun lähettämisestä palveluumme ensimmäiseen komentoon tähtimerkki laski 1,5 sekunnista 0,05 sekuntiin ja tämä aika riippuu hieman projektin koosta.

Tämän seurauksena puhelinsuunnitelman kehittämisen aika lyheni huomattavasti, ja voin arvostaa tätä, koska jouduin kirjoittamaan kaikkien moduulien koko valintasuunnitelman uudelleen PHP:ssä. Ensinnäkin menetelmät pitäisi jo kirjoittaa php:ssä objektin saamiseksi tietokannasta; niitä tarvittiin web-käyttöliittymässä näyttämiseen, ja toiseksi, ja tämä on tärkeintä, on vihdoin mahdollista työskennellä kätevästi numeroiden ja taulukoiden kanssa. tietokannan ja useiden PHP-laajennusten kanssa.

Moduuliluokan valintasuunnitelman käsittelemiseksi sinun on toteutettava funktio dialplanDynamicCall ja argumentti pbxCallRequest sisältää objektin, jonka kanssa voi olla vuorovaikutuksessa tähtimerkki.

Lisäksi valitsinsuunnitelman virheenkorjaus tuli mahdolliseksi (php:llä on xdebug ja se toimii palvelussamme), voit siirtyä askel askeleelta tarkastelemalla muuttujien arvoja.

Puhelutiedot

Kaikki analyysit ja raportit edellyttävät oikein kerättyä dataa, ja tämä PBX-lohko kävi myös läpi paljon yritystä ja virhettä ensimmäisestä kolmanteen versioon. Usein puhelutiedot ovat merkki. Yksi puhelu = yksi äänitys: kuka soitti, kuka vastasi, kuinka kauan he puhuivat. Mielenkiintoisemmissa vaihtoehdoissa on lisäkyltti, joka osoittaa, kenelle PBX:n työntekijöistä soitettiin puhelun aikana. Mutta kaikki tämä kattaa vain osan tarpeista.

Alkuperäiset vaatimukset olivat:

• Tallenna paitsi kenelle PBX soitti, myös kuka vastasi, koska kuunteluja tapahtuu, ja tämä on otettava huomioon puheluita analysoitaessa,
• aika ennen yhteydenottoa työntekijään. Sisään Ilmainen PBX ja joissakin muissa vaihteissa, puhelu katsotaan vastatuksi heti, kun PBX vastaa puhelimeen. Mutta äänivalikkoa varten sinun on jo nostettava puhelin, joten kaikkiin puheluihin vastataan ja vastauksen odotusaika on 0-1 sekunti. Siksi päätettiin säästää paitsi vastausta edeltävää aikaa, myös aikaa ennen yhteyden muodostamista avainmoduuleille (moduuli itse asettaa tämän lipun. Tällä hetkellä se on "Työntekijä", "Ulkoinen linja"),
• monimutkaisemmalla soittosuunnitelmalla, kun puhelu kulkee eri ryhmien välillä, oli tarpeen pystyä tarkastelemaan jokaista elementtiä erikseen.

Parhaaksi vaihtoehdoksi osoittautui, kun PBX-moduulit lähettävät itsestään tietoja puheluissa ja lopulta tallentavat tiedot puun muodossa.

Se näyttää tältä:

Ensinnäkin yleiset tiedot puhelusta (kuten kaikki muutkin - ei mitään erityistä).

1. Vastaanotettu puhelu ulkolinjaan"Taikina"klo 05:55:52 numerosta 89295671458 numeroon 89999999999, lopulta työntekijä vastasi"Sihteeri 2» numerolla 104. Asiakas odotti 60 sekuntia ja puhui 36 sekuntia.
2. Työntekijä"Sihteeri 2"soittaa 112 ja työntekijä vastaa"Johtaja 1» 8 sekunnin kuluttua. He puhuvat 14 sekuntia.
3. Asiakas siirtyy työntekijälle"johtaja 1", jossa he jatkavat puhumista vielä 13 sekuntia

Mutta tämä on jäävuoren huippu: jokaisesta tietueesta saat yksityiskohtaisen puheluhistorian PBX:n kautta.

Kaikki tiedot esitetään puhelujen sisäkkäinä:

1. Vastaanotettu puhelu ulkolinjaan"Taikina» klo 05:55:52 numerosta 89295671458 numeroon 89999999999.
2. Klo 05:55:53 ulkolinja lähettää puhelun saapuvaan piiriin "testi»
3. Kun puhelu käsitellään kaavion mukaisesti, moduuli "johtajan puhelu", jossa puhelu on 16 sekuntia. Tämä on asiakkaalle kehitetty moduuli.
4. Moduuli "johtajan puhelu"lähettää puhelun numerosta vastaavalle työntekijälle (asiakkaalle)"Johtaja 1” ja odottaa 5 sekuntia vastausta. Johtaja ei vastannut.
5. Moduuli "johtajan puhelu"lähettää puhelun ryhmälle"CORP:n johtajat" Nämä ovat muita saman suunnan johtajia (istuivat samassa huoneessa) ja odottavat 11 sekuntia vastausta.
6. Ryhmä "CORP:n johtajat"soittaa työntekijöille"Johtaja 1, Johtaja 2, Johtaja 3"samanaikaisesti 11 sekunnin ajan. Ei vastausta.
7. Johtajan puhelu loppuu. Ja piiri lähettää kutsun moduulille "Reitin valitseminen kohdasta 1c" Myös asiakkaalle kirjoitettu moduuli. Tässä puhelua käsiteltiin 0 sekuntia.
8. Piiri lähettää kutsun äänivalikkoon "Perus ja lisävalinta" Asiakas odotti siellä 31 sekuntia, lisävalintaa ei tullut.
9. Järjestelmä lähettää puhelun ryhmälle "Sihteerit", jossa asiakas odotti 12 sekuntia.
10. Ryhmässä 2 työntekijää kutsutaan samaan aikaan "Sihteeri 1"Ja"Sihteeri 2"ja 12 sekunnin kuluttua työntekijä vastaa"Sihteeri 2" Vastaus puheluun kopioidaan vanhempien puheluiksi. Kävi ilmi, että ryhmässä hän vastasi "Sihteeri 2", soitettaessa piiri vastasi"Sihteeri 2"ja vastasi ulkolinjan puheluun "Sihteeri 2'.

Tietojen tallentaminen kustakin toiminnasta ja niiden sisäkkäisyydestä mahdollistaa yksinkertaisesti raporttien tekemisen. Äänivalikon raportti auttaa sinua selvittämään, kuinka paljon se auttaa tai haittaa. Muodosta raportti työntekijöiden vastaamatta jääneistä puheluista ottamalla huomioon, että puhelu on siepattu, joten sitä ei pidetä vastaamattomana, ja ottaen huomioon, että kyseessä oli ryhmäpuhelu ja joku muu vastasi aiemmin, eli puhelua ei myöskään jäänyt vastaamatta.

Tällaisen tiedon tallennuksen avulla voit ottaa jokaisen ryhmän erikseen ja määrittää, kuinka tehokkaasti se toimii, ja rakentaa kaavion vastatuista ja vastaamattomista ryhmistä tunneittain. Voit myös tarkistaa, kuinka tarkka yhteys vastaavaan esimieheen on, analysoimalla siirrot, kun olet muodostanut yhteyden esimieheen.

Voit myös tehdä melko epätyypillisiä tutkimuksia, esimerkiksi kuinka usein numerot, jotka eivät ole tietokannassa, valitsevat oikean alaliittymän tai kuinka monta prosenttia lähtevistä puheluista siirtyy matkapuhelimeen.

Tulos?

PBX:n ylläpitoon ei vaadita asiantuntijaa, sen voi tehdä tavallisin ylläpitäjä - käytännössä testattu.

Muokkauksiin ei tarvita vakavasti koulutettuja asiantuntijoita, PHP:n tuntemus riittää, koska Moduulit on jo kirjoitettu SIP-protokollalle ja jonolle ja työntekijälle soittamista varten. Siellä on kääreluokka tähtimerkki. Moduulin kehittämiseksi ohjelmoija voi (ja hyvällä tavalla pitäisikin) kutsua valmiita moduuleja. Ja tietoa tähtimerkki ovat täysin tarpeettomia, jos asiakas pyytää lisäämään sivun jollakin uudella raportilla. Mutta käytäntö osoittaa, että vaikka kolmannen osapuolen ohjelmoijat voivat selviytyä, he tuntevat olonsa epävarmaksi ilman dokumentaatiota ja normaalia kommenttien kattavuutta, joten parantamisen varaa on vielä.

Moduulit voivat:

• luoda uusia puhelunkäsittelyominaisuuksia,
• lisää uusia lohkoja verkkokäyttöliittymään,
• periä mistä tahansa olemassa olevista moduuleista, määrittää funktiot uudelleen ja korvata ne tai olla vain hieman muokattu kopio,
• lisää asetuksesi muiden moduulien asetusmalliin ja paljon muuta.

PBX-asetukset API:n kautta. Kuten edellä on kuvattu, kaikki asetukset tallennetaan tietokantaan ja ne luetaan puhelun aikana, joten voit muuttaa kaikkia PBX-asetuksia API:n kautta. Sovellusta kutsuttaessa konfiguraatiota ei luoda uudelleen eikä moduuleja käynnistetä uudelleen, joten sillä ei ole väliä kuinka monta asetusta ja työntekijää sinulla on. API-pyynnöt suoritetaan nopeasti eivätkä estä toisiaan.

PBX tallentaa kaikki keskeiset toiminnot puheluilla kestoineen (odotus/keskustelu), sisäkkäin ja PBX-termein (työntekijä, ryhmä, ulkolinja, ei kanava, numero). Näin voit rakentaa erilaisia ​​raportteja tietyille asiakkaille, ja suurin osa työstä on käyttäjäystävällisen käyttöliittymän luominen.

Aika näyttää mitä tapahtuu seuraavaksi. Vielä on monia vivahteita, jotka pitää tehdä uusiksi, suunnitelmia on vielä paljon, mutta vuosi on kulunut kolmannen version luomisesta ja voimme jo sanoa, että idea toimii. Version 3 suurin haittapuoli on laitteistoresurssit, mutta siitä joutuu yleensä maksamaan, jotta kehitys olisi helppoa.

Lähde: will.com