🥇Hadithi ya mradi mmoja au jinsi nilivyotumia miaka 7 kuunda PBX kulingana na Nyota na Php

Hakika wengi wenu, kama mimi, mlikuwa na wazo la kufanya jambo la kipekee. Katika makala hii nitaelezea matatizo ya kiufundi na ufumbuzi ambao nilipaswa kukabiliana nao wakati wa kuendeleza PBX. Labda hii itasaidia mtu kuamua juu ya wazo lake mwenyewe, na mtu kufuata njia iliyopigwa vizuri, kwa sababu pia nilifaidika kutokana na uzoefu wa waanzilishi.

Wazo na mahitaji muhimu

Na yote yalianza tu kwa upendo kinyota (mfumo wa kujenga maombi ya mawasiliano), automatisering ya simu na mitambo BurePBX (kiolesura cha wavuti cha kinyota) Ikiwa mahitaji ya kampuni hayakuwa na maalum na yalianguka ndani ya uwezo BurePBX - kila kitu ni kubwa. Usakinishaji mzima ulifanyika ndani ya saa XNUMX, kampuni ilipokea PBX iliyosanidiwa, kiolesura kinachofaa mtumiaji na mafunzo mafupi pamoja na usaidizi ikihitajika.

Lakini kazi za kufurahisha zaidi hazikuwa za kiwango na kisha haikuwa nzuri sana. kinyota inaweza kufanya mengi, lakini kuweka kiolesura cha wavuti katika utaratibu wa kufanya kazi, ilikuwa ni lazima kutumia mara nyingi zaidi wakati. Kwa hivyo maelezo madogo yanaweza kuchukua muda mrefu zaidi kuliko kusakinisha sehemu nyingine ya PBX. Na jambo sio kwamba inachukua muda mrefu kuandika kiolesura cha wavuti, lakini hoja iko katika sifa za usanifu. BurePBX. Mbinu na mbinu za usanifu BurePBX iliwekwa wakati wa php4, na wakati huo tayari kulikuwa na php5.6 ambayo kila kitu kinaweza kufanywa rahisi na rahisi zaidi.

Majani ya mwisho yalikuwa michoro ya picha katika mfumo wa mchoro. Wakati nilijaribu kuunda kitu kama hiki BurePBX, niligundua kuwa nitalazimika kuiandika tena na itakuwa rahisi kuunda kitu kipya.

Mahitaji muhimu yalikuwa:

usanidi rahisi, unaopatikana kwa urahisi hata kwa msimamizi wa novice. Kwa hivyo, kampuni hazihitaji matengenezo ya PBX kwa upande wetu,
marekebisho rahisi ili kazi zitatuliwe kwa wakati wa kutosha,
urahisi wa kuunganishwa na PBX. U BurePBX hapakuwa na API ya kubadilisha mipangilio, i.e. Huwezi, kwa mfano, kuunda vikundi au menyu za sauti kutoka kwa programu ya mtu wa tatu, tu API yenyewe kinyota,
opensource - kwa watengeneza programu hii ni muhimu sana kwa marekebisho ya mteja.

Wazo la maendeleo ya haraka lilikuwa kuwa na utendaji wote unajumuisha moduli katika mfumo wa vitu. Vitu vyote vililazimika kuwa na darasa la kawaida la mzazi, ambayo inamaanisha kuwa majina ya kazi zote kuu tayari zinajulikana na kwa hivyo tayari kuna utekelezaji chaguo-msingi. Vitu vitakuruhusu kupunguza kwa kiasi kikubwa idadi ya hoja katika mfumo wa safu za ushirika na funguo za kamba, ambazo unaweza kujua ndani. BurePBX Iliwezekana kwa kuchunguza kazi nzima na kazi zilizowekwa. Katika kesi ya vitu, ukamilishaji wa banal utaonyesha mali zote, na kwa ujumla itarahisisha maisha mara nyingi. Zaidi ya hayo, urithi na ufafanuzi upya tayari hutatua matatizo mengi na marekebisho.

Jambo lililofuata ambalo lilipunguza kasi ya muda wa kufanya kazi upya na lilifaa kuepukwa ilikuwa kurudia. Ikiwa kuna moduli inayohusika na kupiga simu kwa mfanyakazi, basi moduli zingine zote zinazohitaji kutuma simu kwa mfanyakazi zinapaswa kuitumia, na sio kuunda nakala zao wenyewe. Kwa hivyo, ikiwa unahitaji kubadilisha kitu, basi itabidi ubadilishe mahali pekee na utaftaji wa "jinsi inavyofanya kazi" unapaswa kufanywa mahali pamoja, na sio kutafutwa katika mradi wote.

Toleo la kwanza na makosa ya kwanza

Mfano wa kwanza ulikuwa tayari ndani ya mwaka mmoja. PBX nzima, kama ilivyopangwa, ilikuwa ya msimu, na moduli hazikuweza tu kuongeza utendakazi mpya wa usindikaji wa simu, lakini pia kubadilisha kiolesura cha wavuti yenyewe.

Ndio, wazo la kujenga dialplan katika mfumo wa mpango kama huo sio langu, lakini ni rahisi sana na nilifanya vivyo hivyo kwa kinyota.

Kwa kuandika moduli, waandaaji wa programu wanaweza tayari:

unda utendaji wako mwenyewe wa usindikaji wa simu, ambayo inaweza kuwekwa kwenye mchoro, na pia kwenye menyu ya vitu upande wa kushoto,
unda kurasa zako mwenyewe za kiolesura cha wavuti na ongeza violezo vyako kwa kurasa zilizopo (ikiwa msanidi wa ukurasa ametoa kwa hili),
ongeza mipangilio yako kwenye kichupo kikuu cha mipangilio au unda kichupo chako cha mipangilio,
programu inaweza kurithi kutoka kwa moduli iliyopo, kubadilisha sehemu ya utendaji na kuisajili chini ya jina jipya au kubadilisha moduli asili.

Kwa mfano, hivi ndivyo unavyoweza kuunda menyu yako ya sauti:

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

Utekelezaji tata wa kwanza ulileta kiburi cha kwanza na tamaa za kwanza. Nilifurahi kwamba ilifanya kazi, kwamba nilikuwa tayari na uwezo wa kuzaliana sifa kuu BurePBX. Nilifurahi kwamba watu walipenda wazo la mpango huo. Bado kulikuwa na chaguzi nyingi za kurahisisha maendeleo, lakini hata wakati huo baadhi ya kazi zilikuwa tayari zimerahisishwa.

API ya kubadilisha usanidi wa PBX ilikuwa ya kukatisha tamaa - matokeo hayakuwa kile tulichotaka. Nilichukua kanuni sawa na katika BurePBX, kwa kubofya kitufe cha Tumia, usanidi mzima unafanywa upya na moduli zinaanzishwa tena.

Inaonekana kama hii:

*Dialplan ni sheria (algorithm) ambayo simu inachakatwa.

Lakini kwa chaguo hili, haiwezekani kuandika API ya kawaida ya kubadilisha mipangilio ya PBX. Kwanza, uendeshaji wa kutumia mabadiliko kwa kinyota muda mrefu sana na rasilimali nyingi.
Pili, huwezi kuita kazi mbili kwa wakati mmoja, kwa sababu zote mbili zitaunda usanidi.
Tatu, inatumika kwa mipangilio yote, pamoja na ile iliyofanywa na msimamizi.

Katika toleo hili, kama katika Askozia, iliwezekana kuzalisha usanidi wa moduli zilizobadilishwa tu na kuanzisha upya moduli muhimu tu, lakini haya yote ni hatua za nusu. Ilikuwa ni lazima kubadili mbinu.

Toleo la pili. Pua vunjwa mkia kukwama

Wazo la kutatua tatizo halikuwa kuunda upya usanidi na kupiga simu kwa kinyota, lakini hifadhi taarifa kwenye hifadhidata na usome kutoka kwa hifadhidata moja kwa moja wakati unashughulikia simu. kinyota Tayari nilijua jinsi ya kusoma usanidi kutoka kwa hifadhidata, badilisha tu thamani kwenye hifadhidata na simu inayofuata itashughulikiwa kwa kuzingatia mabadiliko, na kazi ilikuwa kamili kwa kusoma vigezo vya dialplan. REALTIME_HASH.

Mwishowe, hakukuwa na haja ya kuanza tena kinyota wakati wa kubadilisha mipangilio na mipangilio yote ilianza kutumika mara moja kwa kinyota.

Mabadiliko pekee kwenye dialplan ni nyongeza ya nambari za ugani na vidokezo. Lakini haya yalikuwa mabadiliko madogo ya doa

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

Unaweza kuongeza au kubadilisha laini kwa urahisi kwenye dialplan ukitumia Ami (kiolesura cha kudhibiti kinyota) na hakuna kuwasha upya kwa dialplan nzima inahitajika.

Hii ilitatua tatizo na API ya usanidi. Unaweza hata moja kwa moja kwenda kwenye hifadhidata na kuongeza kikundi kipya au kubadilisha, kwa mfano, muda wa kupiga simu katika sehemu ya "muda wa kupiga simu" kwa kikundi na simu inayofuata tayari itadumu kwa wakati maalum (Hili sio pendekezo kwa action, kwani shughuli zingine za API zinahitaji Ami simu).

Utekelezaji mgumu wa kwanza tena ulileta kiburi cha kwanza na tamaa. Nilifurahi kwamba ilifanya kazi. Database ikawa kiungo muhimu, utegemezi wa diski uliongezeka, kulikuwa na hatari zaidi, lakini kila kitu kilifanya kazi kwa utulivu na bila matatizo. Na muhimu zaidi, sasa kila kitu ambacho kinaweza kufanywa kupitia kiolesura cha wavuti kinaweza kufanywa kupitia API, na njia sawa zilitumiwa. Zaidi ya hayo, kiolesura cha wavuti kiliondoa kitufe cha "tumia mipangilio kwa PBX", ambayo wasimamizi mara nyingi waliisahau.

Kukatishwa tamaa ni kwamba maendeleo yamekuwa magumu zaidi. Tangu toleo la kwanza, lugha ya PHP imezalisha dialplan katika lugha kinyota na inaonekana haisomeki kabisa, pamoja na lugha yenyewe kinyota kwa kuandika dialplan ni primitive sana.

Ilionekanaje:

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

Katika toleo la pili, dialplan ikawa ya ulimwengu wote, ilijumuisha chaguzi zote za usindikaji zinazowezekana kulingana na vigezo na ukubwa wake uliongezeka kwa kiasi kikubwa. Yote hii ilipunguza sana wakati wa maendeleo, na mawazo sana kwamba mara nyingine tena ilikuwa ni lazima kuingilia kati na dialplan ilinifanya huzuni.

Toleo la tatu

Wazo la kutatua tatizo halikuwa kuzalisha kinyota dialplan kutoka kwa php na utumie FastAGI na uandike sheria zote za usindikaji katika PHP yenyewe. FastAGI inaruhusu kinyota, kusindika simu, unganisha kwenye tundu. Pokea amri kutoka hapo na utume matokeo. Kwa hivyo, mantiki ya dialplan tayari iko nje ya mipaka kinyota na inaweza kuandikwa kwa lugha yoyote, kwa upande wangu katika PHP.

Kulikuwa na majaribio mengi na makosa. Shida kuu ilikuwa kwamba tayari nilikuwa na madarasa / faili nyingi. Ilichukua kama sekunde 1,5 kuunda vitu, kuvianzisha, na kusajili kila mmoja na kila mmoja, na ucheleweshaji huu kwa kila simu sio jambo ambalo linaweza kupuuzwa.

Uanzishaji ulipaswa kutokea mara moja tu na kwa hivyo utaftaji wa suluhisho ulianza kwa kuandika huduma kwa kutumia php Mizizi. Baada ya wiki ya majaribio, chaguo hili liliwekwa rafu kwa sababu ya ugumu wa jinsi kiendelezi hiki kinavyofanya kazi. Baada ya mwezi wa majaribio, pia ilibidi niachane na programu ya asynchronous katika PHP; Nilihitaji kitu rahisi, kinachojulikana kwa Kompyuta yoyote ya PHP, na viendelezi vingi vya PHP vinalingana.

Suluhisho lilikuwa huduma yetu ya nyuzi nyingi katika C, ambayo iliundwa na PHPLIB. Inapakia faili zote za php za ATS, inasubiri moduli zote kuanzishwa, inaongeza kurudi kwa kila mmoja, na wakati kila kitu kiko tayari, kihifadhi. Wakati wa kuuliza kwa FastAGI mkondo huundwa, nakala kutoka kwa kashe ya madarasa yote na data hutolewa ndani yake, na ombi hupitishwa kwa kazi ya php.

Kwa suluhisho hili, wakati wa kutuma simu kwa huduma yetu hadi amri ya kwanza kinyota ilipungua kutoka 1,5s hadi 0,05s na wakati huu inategemea kidogo ukubwa wa mradi.

Kama matokeo, wakati wa ukuzaji wa dialplan ulipunguzwa kwa kiasi kikubwa, na ninaweza kufahamu hili kwani ilinibidi kuandika upya dialplan nzima ya moduli zote katika PHP. Kwanza, njia zinapaswa kuandikwa katika php kupata kitu kutoka kwa hifadhidata; zilihitajika kwa kuonyesha kwenye kiolesura cha wavuti, na pili, na hii ndio jambo kuu, hatimaye inawezekana kufanya kazi kwa urahisi na kamba na nambari na safu. na hifadhidata pamoja na viendelezi vingi vya PHP.

Ili kuchakata dialplan katika darasa la moduli unahitaji kutekeleza kazi dialplanDynamicCall na hoja pbxCallRequest itakuwa na kitu cha kuingiliana nacho kinyota.

Kwa kuongezea, iliwezekana kurekebisha dialplan (php ina xdebug na inafanya kazi kwa huduma yetu), unaweza kusonga hatua kwa hatua kwa kutazama maadili ya anuwai.

Data ya simu

Uchanganuzi wowote na ripoti zinahitaji data iliyokusanywa kwa usahihi, na kizuizi hiki cha PBX pia kilipitia majaribio na hitilafu nyingi kutoka toleo la kwanza hadi la tatu. Mara nyingi, data ya simu ni ishara. Simu moja = kurekodi moja: ni nani aliyepiga, nani alijibu, walizungumza kwa muda gani. Katika chaguzi za kuvutia zaidi, kuna ishara ya ziada inayoonyesha mfanyakazi wa PBX aliitwa wakati wa simu. Lakini hii yote inashughulikia sehemu tu ya mahitaji.

Mahitaji ya awali yalikuwa:

kuokoa sio tu ambao PBX waliita, lakini pia ni nani aliyejibu, kwa sababu kuna uingiliaji na hii itahitaji kuzingatiwa wakati wa kuchambua simu,
muda kabla ya kuunganishwa na mfanyakazi. Katika BurePBX na PBX zingine, simu inazingatiwa kujibiwa mara tu PBX inapochukua simu. Lakini kwa orodha ya sauti tayari unahitaji kuchukua simu, hivyo simu zote zinajibiwa na muda wa kusubiri jibu unakuwa sekunde 0-1. Kwa hiyo, iliamua kuokoa sio muda tu kabla ya jibu, lakini wakati kabla ya kuunganishwa na moduli muhimu (moduli yenyewe inaweka bendera hii. Hivi sasa ni "Mfanyakazi", "Mstari wa Nje").
kwa dialplan ngumu zaidi, wakati simu inasafiri kati ya vikundi tofauti, ilikuwa ni lazima kuweza kuchunguza kila kipengele tofauti.

Chaguo bora zaidi iligeuka kuwa wakati moduli za PBX zinatuma habari kuhusu wao wenyewe kwenye simu na hatimaye kuhifadhi habari kwa namna ya mti.

Inaonekana kama hii:

Kwanza, habari ya jumla juu ya simu (kama kila mtu mwingine - hakuna kitu maalum).

Alipokea simu kwenye laini ya nje "Kwa mtihani"saa 05:55:52 kutoka nambari 89295671458 hadi nambari 89999999999, mwisho ilijibiwa na mfanyakazi"Katibu 2» yenye namba 104. Mteja alisubiri sekunde 60 na kuzungumza kwa sekunde 36.
Mfanyakazi"Katibu 2"anapiga simu kwa 112 na mfanyakazi anajibu"Msimamizi 1»baada ya sekunde 8. Wanazungumza kwa sekunde 14.
Mteja anahamishiwa kwa Mfanyakazi"meneja 1" ambapo wanaendelea kuongea kwa sekunde 13 nyingine

Lakini hii ndio ncha ya barafu; kwa kila rekodi unaweza kupata historia ya simu ya kina kupitia PBX.

Taarifa zote zinawasilishwa kama kiota cha simu:

Alipokea simu kwenye laini ya nje "Kwa mtihani» saa 05:55:52 kutoka nambari 89295671458 hadi nambari 89999999999.
Saa 05:55:53 laini ya nje inatuma simu kwa saketi inayoingia "mtihani»
Wakati wa kusindika simu kulingana na mpango, moduli "simu ya meneja", ambayo simu ni sekunde 16. Hii ni moduli iliyoundwa kwa ajili ya mteja.
Moduli"simu ya meneja"Hutuma simu kwa mfanyakazi anayehusika na nambari (mteja)"Msimamizi 1” na subiri sekunde 5 kwa jibu. Meneja hakujibu.
Moduli"simu ya meneja"inatuma simu kwa kikundi"Wasimamizi wa CORP" Hawa ni wasimamizi wengine wa mwelekeo sawa (wameketi katika chumba kimoja) na kusubiri sekunde 11 kwa jibu.
Kikundi "Wasimamizi wa CORP"ita wafanyakazi"Msimamizi 1, Msimamizi 2, Msimamizi 3"wakati huo huo kwa sekunde 11. Hakuna jibu.
Simu ya meneja inaisha. Na mzunguko hutuma simu kwa moduli "Kuchagua njia kutoka 1c" Pia moduli iliyoandikwa kwa mteja. Hapa simu ilichakatwa kwa sekunde 0.
Mzunguko hutuma simu kwenye menyu ya sauti "Msingi na upigaji simu wa ziada" Mteja alingoja hapo kwa sekunde 31, hakukuwa na upigaji simu wa ziada.
Mpango hutuma simu kwa Kikundi "Makatibu", ambapo mteja alisubiri sekunde 12.
Katika kikundi, wafanyikazi 2 wanaitwa kwa wakati mmoja "Katibu 1"Na"Katibu 2"na baada ya sekunde 12 mfanyakazi anajibu"Katibu 2" Jibu la simu linarudiwa katika simu za wazazi. Ilibainika kuwa katika kikundi alijibu "Katibu 2", wakati wa kupiga mzunguko ulijibu "Katibu 2" na kujibu simu kwenye laini ya nje na "Katibu 2'.

Ni uhifadhi wa taarifa kuhusu kila operesheni na uwekaji wao ambao utafanya iwezekane kutoa ripoti kwa urahisi. Ripoti kwenye menyu ya sauti itakusaidia kujua ni kiasi gani inasaidia au inazuia. Tengeneza ripoti juu ya simu zilizokosa na wafanyikazi, kwa kuzingatia kwamba simu ilikatwa na kwa hivyo haizingatiwi kuwa imekosa, na kwa kuzingatia kuwa ilikuwa simu ya kikundi, na mtu mwingine alijibu mapema, ambayo inamaanisha kuwa simu pia haikukosekana.

Uhifadhi kama huo wa habari utakuruhusu kuchukua kila kikundi kando na kuamua jinsi inavyofanya kazi kwa ufanisi, na kuunda grafu ya vikundi vilivyojibiwa na vilivyokosa kwa saa. Unaweza pia kuangalia jinsi muunganisho sahihi kwa meneja anayewajibika kwa kuchambua uhamishaji baada ya kuunganishwa na meneja.

Unaweza pia kufanya tafiti zisizo za kawaida, kwa mfano, ni mara ngapi nambari ambazo haziko kwenye hifadhidata hupiga kiendelezi sahihi au ni asilimia ngapi ya simu zinazotoka zinatumwa kwa simu ya rununu.

matokeo?

Mtaalam hahitajiki kudumisha PBX; msimamizi wa kawaida anaweza kuifanya - iliyojaribiwa kwa mazoezi.

Kwa marekebisho, wataalam wenye sifa kubwa hawahitajiki; ujuzi wa PHP ni wa kutosha, kwa sababu Moduli tayari zimeandikwa kwa itifaki ya SIP, na kwa foleni, na kwa kumwita mfanyakazi, na wengine. Kuna darasa la wrapper kinyota. Ili kutengeneza moduli, mpangaji programu anaweza (na kwa njia nzuri anapaswa) kuita moduli zilizotengenezwa tayari. Na maarifa kinyota sio lazima kabisa ikiwa mteja atauliza kuongeza ukurasa na ripoti mpya. Lakini mazoezi yanaonyesha kwamba ingawa watengenezaji programu wa wahusika wengine wanaweza kustahimili, wanahisi kutokuwa na usalama bila nyaraka na chanjo ya kawaida ya maoni, kwa hivyo bado kuna nafasi ya kuboresha.

Moduli zinaweza:

kuunda uwezo mpya wa usindikaji wa simu,
ongeza vizuizi vipya kwenye kiolesura cha wavuti,
kurithi kutoka kwa moduli zozote zilizopo, fafanua upya vitendaji na ubadilishe, au uwe nakala iliyorekebishwa kidogo,
ongeza mipangilio yako kwenye kiolezo cha mipangilio ya moduli zingine na mengi zaidi.

Mipangilio ya PBX kupitia API. Kama ilivyoelezwa hapo juu, mipangilio yote huhifadhiwa kwenye hifadhidata na kusomwa wakati wa simu, ili uweze kubadilisha mipangilio yote ya PBX kupitia API. Wakati wa kupiga API, usanidi haujaundwa tena na moduli hazijaanzishwa tena, kwa hivyo, haijalishi ni mipangilio ngapi na wafanyikazi unao. Maombi ya API yanatekelezwa haraka na hayazuiani.

PBX huhifadhi shughuli zote muhimu zilizo na simu zenye muda (kungoja/mazungumzo), kuweka kiota na kwa masharti ya PBX (mfanyikazi, kikundi, laini ya nje, si chaneli, nambari). Hii hukuruhusu kuunda ripoti mbalimbali kwa wateja mahususi na kazi nyingi ni kuunda kiolesura kinachofaa mtumiaji.

Muda utasema nini kitatokea baadaye. Bado kuna nuances nyingi ambazo zinahitaji kufanywa upya, bado kuna mipango mingi, lakini mwaka umepita tangu kuundwa kwa toleo la 3 na tunaweza kusema tayari kuwa wazo hilo linafanya kazi. Hasara kuu ya toleo la 3 ni rasilimali za vifaa, lakini kwa kawaida hii ndiyo unapaswa kulipa kwa urahisi wa maendeleo.

Chanzo: mapenzi.com

Hadithi ya mradi mmoja au jinsi nilivyotumia miaka 7 kuunda PBX kulingana na Asterisk na Php