Egy projekt története, vagy hogyan töltöttem 7 évet egy Asterisk és Php alapú alközpont létrehozásával

Bizonyára sokaknak, hozzám hasonlóan, volt ötletetek valami egyedire. Ebben a cikkben leírom azokat a technikai problémákat és megoldásokat, amelyekkel szembe kellett néznem az alközpont fejlesztése során. Talán ez segít valakinek a saját ötletének eldöntésében, és valakinek abban, hogy a jól kitaposott utat kövesse, mert nekem is hasznomra vált az úttörők tapasztalata.

Ötlet és legfontosabb követelmények

És az egész egyszerűen a szeretettel kezdődött Csillag (kommunikációs alkalmazások épületkerete), a telefonálás és a telepítés automatizálása Ingyenes PBX (web felület ehhez Csillag). Ha a cég szükségletei konkrétumok nélküliek és a képességeken belül esnének Ingyenes PBX - minden nagyszerű. A teljes telepítés XNUMX órán belül megtörtént, a cég konfigurált alközpontot, felhasználóbarát felületet és rövid oktatást, valamint igény esetén támogatást kapott.

De a legérdekesebb feladatok nem szabványosak voltak, és akkor nem volt olyan mesés. Csillag sok mindenre képes, de ahhoz, hogy a webes felület működőképes legyen, többszörösen több időre volt szükség. Így egy apró részlet sokkal tovább tarthat, mint az alközpont többi részének telepítése. És nem az a lényeg, hogy sokáig tart egy webes felület megírása, hanem az építészeti jellemzőkben van a lényeg Ingyenes PBX. Építészeti megközelítések és módszerek Ingyenes PBX php4 idején rakták ki, és abban a pillanatban már volt php5.6, amin mindent egyszerűbbé és kényelmesebbé lehetett tenni.

Az utolsó csepp a pohárban a grafikus számlapok voltak diagram formájában. Amikor megpróbáltam valami ilyesmit építeni Ingyenes PBX, rájöttem, hogy jelentősen át kell írnom és könnyebb lesz valami újat építeni.

A legfontosabb követelmények a következők voltak:

• egyszerű beállítás, intuitívan elérhető még a kezdő rendszergazdák számára is. Így a cégek nem igényelnek alközpont karbantartást a mi oldalunkon,
• egyszerű módosítás, hogy a feladatok megfelelő időben megoldódjanak,
• az alközponttal való egyszerű integráció. U Ingyenes PBX nem volt API a beállítások megváltoztatására, pl. Nem hozhat létre például csoportokat vagy hangmenüket egy harmadik féltől származó alkalmazásból, csak maga az API Csillag,
• nyílt forráskódú - a programozók számára ez rendkívül fontos a kliens módosításához.

A gyorsabb fejlesztés ötlete az volt, hogy az összes funkcionalitás objektumok formájú modulokból álljon. Minden objektumnak rendelkeznie kellett egy közös szülő osztálysal, ami azt jelenti, hogy az összes fő függvény neve már ismert, és ezért már léteznek alapértelmezett implementációk. Az objektumok lehetővé teszik az argumentumok számának drámai csökkentését karakterlánc-kulcsokkal ellátott asszociatív tömbök formájában, amelyeket megtudhat Ingyenes PBX Ez a teljes függvény és a beágyazott függvények vizsgálatával volt lehetséges. Az objektumok esetében a banális automatikus kiegészítés megmutatja az összes tulajdonságot, és általában többszörösen leegyszerűsíti az életet. Ráadásul az öröklődés és az újradefiniálás már sok problémát megold a módosításokkal.

A következő dolog, ami lelassította az átdolgozási időt, és érdemes volt elkerülni, az a párhuzamosság. Ha létezik egy alkalmazott tárcsázásáért felelős modul, akkor az összes többi modulnak, amelynek hívást kell küldenie egy alkalmazottnak, ezt kell használnia, nem pedig saját másolatot kell készítenie. Tehát, ha meg kell változtatnia valamit, akkor csak egy helyen kell változtatnia, és a „hogyan működik” keresést egy helyen kell elvégezni, nem pedig az egész projektben.

Első verzió és első hibák

Az első prototípus egy éven belül elkészült. Az egész alközpont a terveknek megfelelően moduláris volt, és a modulok nemcsak a hívásfeldolgozás új funkcióit tudták hozzáadni, hanem magát a webes felületet is megváltoztathatták.

Igen, nem az enyém az ötlet, hogy egy ilyen séma formájában tárcsázási tervet készítsek, de nagyon kényelmes, és én is ezt tettem Csillag.

Egy modul megírásával a programozók már:

• hozzon létre saját hívásfeldolgozási funkciót, amelyet elhelyezhet a diagramon, valamint a bal oldali elemek menüjében,
• hozzon létre saját oldalakat a webes felülethez, és adja hozzá sablonjait a meglévő oldalakhoz (ha az oldal fejlesztője ezt lehetővé tette),
• adja hozzá beállításait a fő beállítások laphoz, vagy hozzon létre saját beállítási lapot,
• a programozó örökölhet egy meglévő modult, megváltoztathatja a funkcionalitás egy részét és új néven regisztrálhatja, vagy lecserélheti az eredeti modult.

Például így hozhat létre saját hangmenüt:

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

Az első komplex megvalósítások meghozták az első büszkeséget és az első csalódásokat. Örültem, hogy sikerült, hogy már sikerült reprodukálni a főbb jellemzőket Ingyenes PBX. Örültem, hogy tetszett az embereknek a program ötlete. Sok lehetőség volt még a fejlesztés egyszerűsítésére, de már akkor is egyes feladatokat könnyítettek.

A PBX konfiguráció megváltoztatására szolgáló API csalódás volt – az eredmény egyáltalán nem az volt, amit szerettünk volna. Ugyanazt az elvet vettem fel, mint az előzőekben Ingyenes PBX, az Alkalmaz gombra kattintva a teljes konfiguráció újra létrejön, és a modulok újraindulnak.

Ez így néz ki:

*A Dialplan egy szabály (algoritmus), amely alapján a hívást feldolgozzák.

Ezzel az opcióval azonban lehetetlen normál API-t írni az alközponti beállítások megváltoztatásához. Először is, a módosítások alkalmazásának művelete Csillag túl hosszú és erőforrásigényes.
Másodszor, nem hívhat meg két függvényt egyszerre, mert mindkettő létrehozza a konfigurációt.
Harmadszor, minden beállítást alkalmaz, beleértve a rendszergazda által megadottakat is.

Ebben a verzióban, mint pl Askozia, csak a megváltozott modulok konfigurációját lehetett generálni és csak a szükséges modulokat újraindítani, de ezek mind félmértékek. A szemléletmód megváltoztatására volt szükség.

Második verzió. Az orr kihúzott farok beragadt

A probléma megoldásának ötlete nem az volt, hogy újra létrehozzuk a konfigurációt és a tárcsázási tervet Csillag, hanem mentse az információkat az adatbázisba, és a hívás feldolgozása közben közvetlenül az adatbázisból olvasson. Csillag Már tudtam, hogyan kell konfigurációkat kiolvasni az adatbázisból, csak módosítsa az értéket az adatbázisban és a következő hívás a változások figyelembevételével kerül feldolgozásra, és a funkció tökéletes volt a tárcsázási paraméterek olvasására REALTIME_HASH.

Végül nem is kellett újraindítani Csillag a beállítások megváltoztatásakor, és az összes beállítást azonnal alkalmazni kezdték Csillag.

A tárcsázási terv egyetlen változása a mellékszámok és a mellékállomások hozzáadása tanácsok. De ezek apró változtatások voltak

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

Könnyen hozzáadhat vagy módosíthat egy vonalat a tárcsázási tervben a segítségével Ami (vezérlő interfész Csillag), és nincs szükség a teljes tárcsázási terv újraindítására.

Ez megoldotta a konfigurációs API problémáját. Akár közvetlenül is beléphet az adatbázisba, és hozzáadhat egy új csoportot, vagy módosíthatja például a csoport betárcsázási idejét a „tárcsázási idő” mezőben, és a következő hívás már a megadott ideig tart (ez nem ajánlott művelet, mivel egyes API-műveletek megkövetelik Ami hívások).

Az első nehéz megvalósítások ismét meghozták az első büszkeséget és csalódást. Örültem, hogy sikerült. Az adatbázis kritikus láncszem lett, megnőtt a lemezfüggőség, több volt a kockázat, de minden stabilan és problémamentesen működött. És ami a legfontosabb, most már mindent, amit a webes felületen keresztül meg lehetett tenni, az API-n keresztül is meg lehetett tenni, és ugyanazokat a módszereket használtuk. Ezenkívül a webes felület megszabadult a „beállítások alkalmazása a PBX-hez” gombtól, amelyről a rendszergazdák gyakran megfeledkeztek.

A csalódás az volt, hogy a fejlesztés bonyolultabbá vált. Az első verzió óta a PHP nyelv tárcsázási tervet generált a nyelven Csillag és teljesen olvashatatlannak tűnik, plusz maga a nyelv Csillag tárcsázási terv írásához rendkívül primitív.

Hogy nézett ki:

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

A második változatban univerzálissá vált a tárcsázási terv, amely a paraméterektől függően minden lehetséges feldolgozási lehetőséget tartalmazott és mérete jelentősen megnőtt. Mindez nagyon lelassította a fejlesztési időt, és már a gondolat is elszomorított, hogy ismét be kell avatkozni a tárcsázási tervbe.

Harmadik verzió

A probléma megoldásának ötlete nem a generálás volt Csillag dialplan php-ról és használd FastAGI és az összes feldolgozási szabályt magában a PHP-ben írja meg. FastAGI lehetővé teszi Csillag, a hívás feldolgozásához csatlakozzon az aljzathoz. Parancsok fogadása onnan és eredmények elküldése. Így a tárcsázási terv logikája már a határokon kívül esik Csillag és bármilyen nyelven írható, esetemben PHP-ben.

Sok volt a próbálkozás és a hiba. A fő probléma az volt, hogy már sok osztályom/fájlom volt. Körülbelül 1,5 másodpercig tartott az objektumok létrehozása, inicializálása és egymás regisztrálása, és ezt a hívásonkénti késleltetést nem lehet figyelmen kívül hagyni.

Az inicializálásnak csak egyszer kellett volna megtörténnie, ezért a megoldás keresése a szolgáltatás php használatával kezdődött Pszálak. Egy hét kísérletezés után ezt a lehetőséget elvetették a bővítmény működésének bonyolultsága miatt. Egy hónapos tesztelés után az aszinkron programozást is fel kellett hagynom a PHP-ben; valami egyszerűre volt szükségem, ami minden PHP-kezdő számára ismerős, és sok PHP-kiterjesztés szinkron.

A megoldás a saját C nyelvű többszálas szolgáltatásunk volt, amivel összeállítottuk PHPLIB. Betölti az összes ATS php fájlt, megvárja, amíg az összes modul inicializálódik, visszahívást ad egymáshoz, és ha minden készen van, gyorsítótárazza. Érdeklődni a FastAGI létrejön egy folyam, az összes osztály és adat gyorsítótárából egy másolatot reprodukálunk benne, és a kérést átadjuk a php függvénynek.

Ezzel a megoldással a szolgáltatásunkra irányuló hívás elküldésétől az első parancsig eltelt idő Csillag 1,5 másodpercről 0,05 másodpercre csökkent, és ez az idő kissé függ a projekt méretétől.

Ennek eredményeként a dialplan fejlesztés ideje jelentősen lecsökkent, és ezt nagyra értékelem, mivel minden modul teljes tárcsázási tervét át kellett írnom PHP-ben. Először is, a metódusokat már php-ban kell írni egy objektum adatbázisból való kinyeréséhez, a webes felületen való megjelenítéshez kellettek, másodszor, és ez a legfontosabb, végre kényelmesen lehet dolgozni számokkal és tömbökkel rendelkező karakterláncokkal adatbázissal és sok PHP kiterjesztéssel.

A tárcsázási terv modulosztálybeli feldolgozásához meg kell valósítani a függvényt dialplanDynamicCall és érvelés pbxCallRequest tartalmaz egy objektumot, amellyel kölcsönhatásba léphet Csillag.

Ezenkívül lehetővé vált a tárcsázási terv hibakeresése (a php-n van xdebug, és működik a szolgáltatásunkban), lépésről lépésre mozoghat a változók értékeinek megtekintésével.

Hívásadatok

Minden elemzéshez és jelentéshez helyesen gyűjtött adatokra van szükség, és ez az alközponti blokk is sok próbálkozáson és hibán ment keresztül az elsőtől a harmadik verzióig. A hívásadatok gyakran jelek. Egy hívás = egy felvétel: ki hívott, ki vette fel, mennyi ideig beszélt. Az érdekesebb lehetőségeknél egy kiegészítő tábla jelzi, hogy melyik alközponti alkalmazottat hívták a hívás során. De mindez a szükségleteknek csak egy részét fedezi.

A kezdeti követelmények a következők voltak:

• nem csak azt menteni, hogy kit hívott az alközpont, hanem azt is, hogy ki válaszolt, mert vannak lehallgatások, és ezt figyelembe kell venni a hívások elemzésekor,
• időt, mielőtt kapcsolatba lépne egy alkalmazottal. Ban ben Ingyenes PBX és néhány más alközpont, a hívás fogadottnak tekintendő, amint az alközpont felveszi a telefont. De a hangmenühöz már fel kell venni a telefont, így minden hívást fogadnak, és a válaszadási várakozási idő 0-1 másodperc lesz. Ezért úgy döntöttek, hogy nemcsak a válaszadás előtti időt takarítjuk meg, hanem a kulcsmodulokhoz való kapcsolódás előtti időt is (maga a modul állítja be ezt a jelzőt. Jelenleg „Alkalmazott”, „Külső vonal”),
• bonyolultabb tárcsázási tervhez, amikor egy hívás különböző csoportok között halad, minden elemet külön-külön kellett vizsgálni.

A legjobb megoldásnak az bizonyult, amikor az alközponti modulok információkat küldenek magukról a hívások során, és végül elmentik az információt egy fa formájában.

Ez így néz ki:

Először is, általános információk a hívásról (mint mindenki más - semmi különös).

1. Hívás érkezett egy külső vonalon"A teszthez"05:55:52-kor a 89295671458-as számról a 89999999999-es számra, végül egy alkalmazott válaszolt"Titkár 2» 104-es számmal. Az ügyfél 60 másodpercet várt, és 36 másodpercig beszélt.
2. alkalmazott"Titkár 2"Hívja a 112-t és egy alkalmazott válaszol"Menedzser 1» 8 másodperc elteltével. 14 másodpercig beszélgetnek.
3. Az Ügyfél átkerül a Munkavállalóhoz"menedzser1"Ahol még 13 másodpercig beszélnek

De ez a jéghegy csúcsa: minden rekordhoz részletes hívástörténetet kaphat az alközponton keresztül.

Minden információ hívások egymásba ágyazásaként jelenik meg:

1. Hívás érkezett egy külső vonalon"A teszthez» 05:55:52-kor a 89295671458-as számról a 89999999999-es számra.
2. 05:55:53-kor a külső vonal hívást küld a bejövő áramkörre "teszt»
3. A hívás séma szerinti feldolgozásakor a „modulmenedzser hívás", amelyben a hívás 16 másodpercig tart. Ez egy ügyfél számára kifejlesztett modul.
4. modulmenedzser hívás" hívást küld a számért felelős alkalmazottnak (ügyfélnek)"Menedzser 1” és 5 másodpercet vár a válaszra. A menedzser nem válaszolt.
5. modulmenedzser hívás"hívást küld a csoportnak"CORP vezetők" Ezek ugyanabban az irányban lévő más menedzserek (ugyanabban a szobában ülnek), és 11 másodpercig várnak a válaszra.
6. Csoport "CORP vezetők"felhívja az alkalmazottakat"Menedzser 1, Menedzser 2, Menedzser 3"egyszerre 11 másodpercig. Nincs válasz.
7. A menedzser hívása véget ér. És az áramkör hívást küld a modulnak"Útvonal kiválasztása 1c" Az ügyfélnek írt modul is. Itt a hívás feldolgozása 0 másodpercig történt.
8. Az áramkör hívást küld a hangmenübe"Alapvető kiegészítő tárcsázással" Az ügyfél 31 másodpercig várt ott, nem volt további tárcsázás.
9. A rendszer hívást küld a csoportnakTitkárok", ahol az ügyfél 12 másodpercet várt.
10. Egy csoportban 2 alkalmazottat hívnak egyszerre "Titkár 1"És"Titkár 2"és 12 másodperc múlva az alkalmazott válaszol"Titkár 2" A hívásra adott válasz a szülői hívásokká duplikálódik. Kiderült, hogy a csoportban azt válaszolta:Titkár 2", az áramkör hívásakor válaszolt"Titkár 2"és a külső vonalon fogadta a hívást"Titkár 2".

Az egyes műveletek információinak mentése és egymásba ágyazása teszi lehetővé az egyszerű jelentések készítését. A hangmenüről készült jelentés segít megtudni, mennyiben segít vagy akadályoz. Készítsen jelentést a dolgozók által nem fogadott hívásokról, figyelembe véve, hogy a hívást elfogták, ezért nem számít nem fogadottnak, valamint figyelembe véve, hogy csoportos hívásról van szó, és valaki más korábban vette fel, vagyis a hívás sem volt elmulasztott.

Az ilyen információtárolás lehetővé teszi, hogy minden csoportot külön-külön megvizsgáljon, és meghatározza, hogy mennyire hatékonyan működik, valamint óránkénti grafikont készíthet a megválaszolt és nem fogadott csoportokról. Azt is ellenőrizheti, hogy mennyire pontos a kapcsolat a felelős vezetővel, ha a menedzserhez való kapcsolódást követően elemzi az átutalásokat.

Meglehetősen atipikus vizsgálatokat is végezhet, például azt, hogy az adatbázisban nem szereplő számok milyen gyakran tárcsázzák a megfelelő melléket, vagy a kimenő hívások hány százalékát irányítják át mobiltelefonra.

Az eredmény?

Az alközpont karbantartásához nem szükséges szakember, ezt a leghétköznapibb rendszergazda is megteheti - a gyakorlatban tesztelve.

Az átalakításokhoz nincs szükség komoly képzettségű szakemberekre, elegendő a PHP ismerete, mert A SIP protokollhoz, a sorhoz, az alkalmazottak hívásához és egyebekhez már írtak modulokat. Van egy csomagoló osztály Csillag. Egy modul fejlesztéséhez a programozó kész modulokat hívhat (és jó értelemben kell is). És tudás Csillag teljesen feleslegesek, ha az ügyfél új jelentést tartalmazó oldal hozzáadását kéri. A gyakorlat azonban azt mutatja, hogy bár a külső programozók megbirkóznak vele, bizonytalanságban érzik magukat a dokumentáció és a megjegyzések normál lefedettsége nélkül, így van még hova fejlődni.

A modulok:

• új hívásfeldolgozási képességek létrehozása,
• új blokkok hozzáadása a webes felülethez,
• örökölni bármelyik meglévő modulból, újradefiniálni a függvényeket és lecserélni, vagy egyszerűen csak egy kicsit módosított másolat,
• adja hozzá beállításait más modulok beállítási sablonjához és még sok máshoz.

PBX beállítások API-n keresztül. A fent leírtak szerint az összes beállítás az adatbázisban tárolódik, és a híváskor olvasható, így az összes alközponti beállítást módosíthatja az API-n keresztül. Az API hívásakor a konfiguráció nem jön létre és a modulok nem indulnak újra, ezért nem mindegy, hány beállítással és alkalmazottal rendelkezik. Az API kérések gyorsan végrehajtódnak, és nem blokkolják egymást.

Az alközpont az összes kulcsfontosságú műveletet tárolja a hívások időtartamával (várakozás/beszélgetés), egymásba ágyazással és alközponti kifejezéssel (alkalmazott, csoport, külső vonal, nem csatorna, szám). Ez lehetővé teszi, hogy különféle jelentéseket készítsen bizonyos ügyfelek számára, és a munka nagy része egy felhasználóbarát felület létrehozása.

Az idő majd eldönti, mi lesz ezután. Sok nüansz van még, amit át kell alakítani, sok terv van még, de eltelt egy év a 3. verzió megalkotása óta, és máris kijelenthetjük, hogy működik az ötlet. A 3-as verzió fő hátránya a hardver erőforrás, de általában ezért kell fizetni a könnyű fejlesztés érdekében.

Forrás: will.com