🥇Ang kwento ng isang proyekto o kung paano ako gumugol ng 7 taon sa paggawa ng isang PBX batay sa Asterisk at Php

Tiyak na marami sa inyo, tulad ko, ang may ideya na gumawa ng kakaiba. Sa artikulong ito ay ilalarawan ko ang mga teknikal na problema at solusyon na kinailangan kong harapin sa pagbuo ng PBX. Marahil ito ay makakatulong sa isang tao na magpasya sa kanilang sariling ideya, at isang tao na sundan ang mahusay na tinatahak na landas, dahil nakinabang din ako sa karanasan ng mga pioneer.

Ideya at mga pangunahing kinakailangan

At nagsimula ang lahat sa simpleng pagmamahal Asterisk (balangkas para sa pagbuo ng mga aplikasyon ng komunikasyon), automation ng telephony at mga pag-install LibrengPBX (interface sa web para sa Asterisk). Kung ang mga pangangailangan ng kumpanya ay walang mga detalye at nahulog sa loob ng mga kakayahan LibrengPBX - lahat ay magaling. Ang buong pag-install ay naganap sa loob ng XNUMX na oras, ang kumpanya ay nakatanggap ng isang naka-configure na PBX, isang user-friendly na interface at maikling pagsasanay kasama ang suporta kung ninanais.

Ngunit ang pinaka-kagiliw-giliw na mga gawain ay hindi karaniwan at pagkatapos ay hindi ito napakaganda. Asterisk malaki ang magagawa, ngunit upang panatilihing gumagana ang interface ng web, kinakailangan na gumugol ng maraming beses ng mas maraming oras. Kaya ang isang maliit na detalye ay maaaring tumagal ng mas matagal kaysa sa pag-install ng natitirang bahagi ng PBX. At ang punto ay hindi na ito ay tumatagal ng mahabang panahon upang magsulat ng isang web interface, ngunit ang punto ay nasa mga tampok na arkitektura LibrengPBX. Mga diskarte at pamamaraan ng arkitektura LibrengPBX ay inilatag sa oras ng php4, at sa sandaling iyon ay mayroon nang php5.6 kung saan ang lahat ay maaaring gawing mas simple at mas maginhawa.

Ang huling dayami ay mga graphical na dialplan sa anyo ng isang diagram. Kapag sinubukan kong bumuo ng isang bagay tulad nito para sa LibrengPBX, napagtanto ko na kailangan kong isulat muli ito nang malaki at magiging mas madaling bumuo ng bago.

Ang mga pangunahing kinakailangan ay:

simpleng setup, madaling ma-access kahit sa isang baguhan na administrator. Kaya, ang mga kumpanya ay hindi nangangailangan ng pagpapanatili ng PBX sa aming panig,
madaling pagbabago upang ang mga gawain ay malutas sa sapat na oras,
kadalian ng pagsasama sa PBX. U LibrengPBX walang API para sa pagbabago ng mga setting, ibig sabihin. Halimbawa, hindi ka makakagawa ng mga grupo o voice menu mula sa isang third-party na application, ang API lang mismo Asterisk,
opensource - para sa mga programmer ito ay napakahalaga para sa mga pagbabago para sa kliyente.

Ang ideya ng mas mabilis na pag-unlad ay ang pagkakaroon ng lahat ng pag-andar na binubuo ng mga module sa anyo ng mga bagay. Ang lahat ng mga bagay ay kailangang magkaroon ng isang karaniwang klase ng magulang, na nangangahulugang ang mga pangalan ng lahat ng mga pangunahing pag-andar ay kilala na at samakatuwid ay mayroon nang mga default na pagpapatupad. Ang mga bagay ay magbibigay-daan sa iyo na kapansin-pansing bawasan ang bilang ng mga argumento sa anyo ng mga associative array na may mga string key, na maaari mong malaman sa LibrengPBX Ito ay posible sa pamamagitan ng pagsusuri sa buong function at nested function. Sa kaso ng mga bagay, ang banal na autocompletion ay magpapakita ng lahat ng mga katangian, at sa pangkalahatan ay pasimplehin ang buhay nang maraming beses. Dagdag pa, nalulutas na ng inheritance at redefinition ang maraming problema sa mga pagbabago.

Ang susunod na bagay na nagpabagal sa oras ng muling paggawa at dapat iwasan ay ang pagdoble. Kung mayroong isang module na responsable para sa pag-dial ng isang empleyado, ang lahat ng iba pang mga module na kailangang magpadala ng isang tawag sa isang empleyado ay dapat gamitin ito, at hindi lumikha ng kanilang sariling mga kopya. Kaya, kung kailangan mong baguhin ang isang bagay, pagkatapos ay kailangan mong baguhin lamang sa isang lugar at ang paghahanap para sa "kung paano ito gumagana" ay dapat isagawa sa isang lugar, at hindi maghanap sa buong proyekto.

Unang bersyon at unang mga error

Ang unang prototype ay handa na sa loob ng isang taon. Ang buong PBX, tulad ng pinlano, ay modular, at ang mga module ay hindi lamang maaaring magdagdag ng bagong pag-andar para sa pagproseso ng mga tawag, ngunit baguhin din ang web interface mismo.

Oo, ang ideya ng pagbuo ng isang dialplan sa anyo ng gayong pamamaraan ay hindi akin, ngunit ito ay napaka-maginhawa at ginawa ko ang parehong para sa Asterisk.

Sa pamamagitan ng pagsulat ng isang module, ang mga programmer ay maaaring:

lumikha ng iyong sariling pag-andar para sa pagproseso ng tawag, na maaaring ilagay sa diagram, pati na rin sa menu ng mga elemento sa kaliwa,
lumikha ng iyong sariling mga pahina para sa web interface at idagdag ang iyong mga template sa mga umiiral nang pahina (kung ang nag-develop ng pahina ay nagbigay para dito),
idagdag ang iyong mga setting sa pangunahing tab ng mga setting o lumikha ng iyong sariling tab ng mga setting,
ang programmer ay maaaring magmana mula sa isang umiiral na module, baguhin ang bahagi ng functionality at irehistro ito sa ilalim ng isang bagong pangalan o palitan ang orihinal na module.

Halimbawa, ito ay kung paano ka makakagawa ng sarili mong voice menu:

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

Ang mga unang kumplikadong pagpapatupad ay nagdala ng unang pagmamalaki at ang mga unang pagkabigo. Natuwa ako na gumana ito, na nagawa ko nang kopyahin ang mga pangunahing tampok LibrengPBX. Natutuwa ako na nagustuhan ng mga tao ang ideya ng scheme. Marami pa ring mga pagpipilian upang pasimplehin ang pag-unlad, ngunit kahit na sa oras na iyon ang ilan sa mga gawain ay pinadali na.

Ang API para sa pagbabago ng configuration ng PBX ay isang pagkabigo - ang resulta ay hindi lahat ng gusto namin. Kinuha ko ang parehong prinsipyo tulad ng sa LibrengPBX, sa pamamagitan ng pag-click sa button na Ilapat, muling gagawin ang buong configuration at magre-restart ang mga module.

Mukhang ito:

*Ang dialplan ay isang panuntunan (algorithm) kung saan pinoproseso ang isang tawag.

Ngunit sa pagpipiliang ito, imposibleng magsulat ng isang normal na API para sa pagbabago ng mga setting ng PBX. Una, ang pagpapatakbo ng paglalapat ng mga pagbabago sa Asterisk masyadong mahaba at masinsinang mapagkukunan.
Pangalawa, hindi ka maaaring tumawag ng dalawang function sa parehong oras, dahil parehong gagawa ng configuration.
Pangatlo, inilalapat nito ang lahat ng mga setting, kabilang ang mga ginawa ng administrator.

Sa bersyong ito, tulad ng sa Askozia, posible na bumuo ng pagsasaayos ng mga binagong module lamang at i-restart lamang ang mga kinakailangang module, ngunit lahat ito ay kalahating sukat. Ito ay kinakailangan upang baguhin ang diskarte.

Pangalawang bersyon. Hugot buntot ng ilong naipit

Ang ideya upang malutas ang problema ay hindi muling likhain ang pagsasaayos at dialplan para sa Asterisk, ngunit i-save ang impormasyon sa database at direktang basahin mula sa database habang pinoproseso ang tawag. Asterisk Alam ko na kung paano magbasa ng mga pagsasaayos mula sa database, baguhin lamang ang halaga sa database at ang susunod na tawag ay ipoproseso na isinasaalang-alang ang mga pagbabago, at ang pag-andar ay perpekto para sa pagbabasa ng mga parameter ng dialplan REALTIME_HASH.

Sa huli, hindi na kailangan pang i-restart Asterisk kapag binago ang mga setting at ang lahat ng mga setting ay nagsimulang mailapat kaagad sa Asterisk.

Ang tanging pagbabago sa dialplan ay ang pagdaragdag ng mga numero ng extension at pahiwatig. Ngunit ang mga ito ay maliit na pagbabago sa lugar

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

Madali kang makakapagdagdag o makakapagpalit ng linya sa dialplan gamit Ami (kontrol na interface Asterisk) at walang pag-reboot ng buong dialplan ang kinakailangan.

Nalutas nito ang problema sa configuration API. Maaari ka ring direktang pumunta sa database at magdagdag ng bagong grupo o magbago, halimbawa, ang oras ng dial-up sa field na "dialtime" ng grupo at ang susunod na tawag ay magtatagal sa tinukoy na oras (Hindi ito isang rekomendasyon para sa pagkilos, dahil nangangailangan ang ilang pagpapatakbo ng API Ami mga tawag).

Ang mga unang mahihirap na pagpapatupad ay muling nagdala ng unang pagmamalaki at pagkabigo. Natuwa ako na gumana ito. Ang database ay naging isang kritikal na link, ang pag-asa sa disk ay tumaas, mayroong higit pang mga panganib, ngunit ang lahat ay gumana nang matatag at walang mga problema. At ang pinakamahalaga, ngayon ang lahat ng maaaring gawin sa pamamagitan ng web interface ay maaaring gawin sa pamamagitan ng API, at ang parehong mga pamamaraan ay ginamit. Bukod pa rito, inalis ng web interface ang button na "ilapat ang mga setting sa PBX", na madalas nakalimutan ng mga administrator.

Ang pagkabigo ay ang pag-unlad ay naging mas kumplikado. Mula sa unang bersyon, ang wikang PHP ay nakabuo ng dialplan sa wika Asterisk at ito ay mukhang ganap na hindi nababasa, kasama ang wika mismo Asterisk para sa pagsulat ng dialplan ito ay napaka-primitive.

Ano ang hitsura nito:

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

Sa pangalawang bersyon, ang dialplan ay naging unibersal, kasama nito ang lahat ng posibleng mga opsyon sa pagproseso depende sa mga parameter at ang laki nito ay tumaas nang malaki. Ang lahat ng ito ay lubos na nagpabagal sa oras ng pag-unlad, at ang mismong pag-iisip na muli na kailangang makagambala sa dialplan ay nagpalungkot sa akin.

Ikatlong bersyon

Ang ideya upang malutas ang problema ay hindi upang bumuo Asterisk dialplan mula sa php at gamitin FastAGI at isulat ang lahat ng mga panuntunan sa pagproseso sa PHP mismo. FastAGI ay nagbibigay-daan sa Asterisk, para iproseso ang tawag, kumonekta sa socket. Tumanggap ng mga utos mula doon at magpadala ng mga resulta. Kaya, ang lohika ng dialplan ay nasa labas na ng mga hangganan Asterisk at maaaring isulat sa anumang wika, sa aking kaso sa PHP.

Nagkaroon ng maraming pagsubok at pagkakamali. Ang pangunahing problema ay marami na akong mga klase/file. Tumagal ng humigit-kumulang 1,5 segundo upang lumikha ng mga bagay, simulan ang mga ito, at irehistro ang isa't isa sa isa't isa, at ang pagkaantala sa bawat tawag ay hindi isang bagay na maaaring balewalain.

Ang pagsisimula ay dapat na nangyari nang isang beses lamang at samakatuwid ang paghahanap para sa isang solusyon ay nagsimula sa pagsulat ng isang serbisyo sa php gamit Mga Pthread. Pagkatapos ng isang linggong pag-eeksperimento, ang opsyong ito ay nai-sholl dahil sa mga pagkasalimuot ng kung paano gumagana ang extension na ito. Pagkatapos ng isang buwan ng pagsubok, kinailangan ko ring iwanan ang asynchronous na programming sa PHP; Kailangan ko ng isang bagay na simple, pamilyar sa sinumang nagsisimula sa PHP, at maraming extension para sa PHP ang magkakasabay.

Ang solusyon ay ang aming sariling multi-threaded na serbisyo sa C, na pinagsama-sama PHPLIB. Nilo-load nito ang lahat ng ATS php file, naghihintay para sa lahat ng mga module na masimulan, nagdadagdag ng callback sa isa't isa, at kapag handa na ang lahat, i-cache ito. Kapag nagtatanong ng FastAGI isang stream ay nilikha, isang kopya mula sa cache ng lahat ng mga klase at data ay muling ginawa sa loob nito, at ang kahilingan ay ipinasa sa php function.

Sa solusyon na ito, ang oras mula sa pagpapadala ng tawag sa aming serbisyo hanggang sa unang utos Asterisk bumaba mula 1,5s hanggang 0,05s at sa pagkakataong ito ay bahagyang nakadepende sa laki ng proyekto.

Bilang isang resulta, ang oras para sa pagbuo ng dialplan ay makabuluhang nabawasan, at maaari kong pahalagahan ito dahil kailangan kong muling isulat ang buong dialplan ng lahat ng mga module sa PHP. Una, ang mga pamamaraan ay dapat na nakasulat sa php upang makakuha ng isang bagay mula sa database; sila ay kinakailangan para sa pagpapakita sa web interface, at pangalawa, at ito ang pangunahing bagay, sa wakas ay posible na maginhawang gumana sa mga string na may mga numero at array. na may database at maraming PHP extension.

Upang maproseso ang dialplan sa klase ng module kailangan mong ipatupad ang function dialplanDynamicCall at argumento pbxCallRequest ay maglalaman ng isang bagay upang makipag-ugnayan sa Asterisk.

Ang karagdagan ay may kakayahang i-debug ang dialplan (may xdebug ang php at gumagana ito para sa aming serbisyo), maaari mong ilipat ang hakbang-hakbang sa pamamagitan ng pagtingin sa mga halaga ng mga variable.

Data ng tawag

Ang anumang analytics at ulat ay nangangailangan ng wastong nakolektang data, at ang PBX block na ito ay dumaan din sa maraming pagsubok at error mula sa una hanggang sa ikatlong bersyon. Kadalasan, ang data ng tawag ay isang senyales. Isang tawag = isang recording: sino ang tumawag, sino ang sumagot, kung gaano katagal sila nag-usap. Sa mas kawili-wiling mga opsyon, mayroong karagdagang sign na nagsasaad kung sinong empleyado ng PBX ang tinawag sa panahon ng tawag. Ngunit ang lahat ng ito ay sumasaklaw lamang sa bahagi ng mga pangangailangan.

Ang mga unang kinakailangan ay:

i-save hindi lamang kung sino ang tinawag ng PBX, kundi pati na rin kung sino ang sumagot, dahil may mga pagharang at ito ay kailangang isaalang-alang kapag sinusuri ang mga tawag,
oras bago kumonekta sa isang empleyado. Sa LibrengPBX at ilang iba pang mga PBX, ang tawag ay itinuturing na nasagot sa sandaling kinuha ng PBX ang telepono. Ngunit para sa voice menu kailangan mo nang kunin ang telepono, kaya lahat ng tawag ay sinasagot at ang oras ng paghihintay para sa isang sagot ay nagiging 0-1 segundo. Samakatuwid, napagpasyahan na i-save hindi lamang ang oras bago ang isang tugon, ngunit ang oras bago kumonekta sa mga pangunahing module (ang module mismo ang nagtatakda ng flag na ito. Sa kasalukuyan ito ay "Empleyado", "External na linya"),
para sa isang mas kumplikadong dialplan, kapag ang isang tawag ay naglalakbay sa pagitan ng iba't ibang mga grupo, ito ay kinakailangan upang masuri ang bawat elemento nang hiwalay.

Ang pinakamahusay na pagpipilian ay naging kapag ang mga module ng PBX ay nagpadala ng impormasyon tungkol sa kanilang sarili sa mga tawag at sa huli ay i-save ang impormasyon sa anyo ng isang puno.

Parang ganito:

Una, pangkalahatang impormasyon tungkol sa tawag (tulad ng iba - walang espesyal).

Nakatanggap ng tawag sa labas ng linya "Para sa pagsubok"sa 05:55:52 mula sa numerong 89295671458 hanggang sa numerong 89999999999, sa huli ay sinagot ito ng isang empleyado"Kalihim2» na may numerong 104. Naghintay ang kliyente ng 60 segundo at nagsalita ng 36 segundo.
Empleado "Kalihim2"tumatawag sa 112 at isang empleyado ang sumagot"Tagapamahala1» pagkalipas ng 8 segundo. Nag-uusap sila ng 14 segundo.
Ang Kliyente ay inilipat sa Empleyado "tagapamahala1" kung saan nagpatuloy sila sa pag-uusap ng isa pang 13 segundo

Ngunit ito ang dulo ng malaking bato ng yelo; para sa bawat tala maaari kang makakuha ng isang detalyadong kasaysayan ng tawag sa pamamagitan ng PBX.

Ang lahat ng impormasyon ay ipinakita bilang isang nesting ng mga tawag:

Nakatanggap ng tawag sa labas ng linya "Para sa pagsubok» sa 05:55:52 mula sa numerong 89295671458 hanggang sa numerong 89999999999.
Sa 05:55:53 ang labas na linya ay nagpapadala ng tawag sa Papasok na circuit "pagsusulit»
Kapag nagpoproseso ng isang tawag ayon sa scheme, ang module "tawag ng manager", kung saan ang tawag ay 16 segundo. Ito ay isang module na binuo para sa kliyente.
Module "tawag ng manager" nagpapadala ng tawag sa empleyado na responsable para sa numero (kliyente) "Tagapamahala1” at naghihintay ng 5 segundo para sa isang tugon. Hindi sumagot ang manager.
Module "tawag ng manager"nagpapadala ng tawag sa grupo"Mga tagapamahala ng CORP" Ito ang iba pang mga tagapamahala ng parehong direksyon (nakaupo sa parehong silid) at naghihintay ng 11 segundo para sa isang tugon.
Pangkat "Mga tagapamahala ng CORP"tumawag ng mga empleyado"Tagapamahala1, Tagapamahala2, Tagapamahala3"sabay-sabay sa loob ng 11 segundo. Walang sagot.
Natapos ang tawag ng manager. At ang circuit ay nagpapadala ng isang tawag sa module "Pagpili ng ruta mula sa 1c" Gayundin isang module na isinulat para sa kliyente. Dito naproseso ang tawag sa loob ng 0 segundo.
Ang circuit ay nagpapadala ng isang tawag sa voice menu "Basic na may karagdagang pag-dial" Naghintay doon ang kliyente ng 31 segundo, walang karagdagang pag-dial.
Ang scheme ay nagpapadala ng tawag sa Grupo "Mga kalihim", kung saan naghintay ang kliyente ng 12 segundo.
Sa isang grupo, 2 empleyado ang sabay na tinatawag "Kalihim1"At"Kalihim2"at pagkatapos ng 12 segundo ay sumagot ang empleyado"Kalihim2" Ang sagot sa tawag ay nadoble sa mga tawag ng magulang. Sa grupo pala niya sinagot “Kalihim2", kapag tumatawag ang circuit ay sumagot "Kalihim2" at sinagot ang tawag sa labas ng linya ng "Kalihim2'.

Ito ay ang pag-save ng impormasyon tungkol sa bawat operasyon at ang kanilang nesting na gagawing posible na simpleng gumawa ng mga ulat. Ang isang ulat sa voice menu ay makakatulong sa iyo na malaman kung gaano ito nakakatulong o nakakahadlang. Bumuo ng isang ulat sa mga tawag na hindi nakuha ng mga empleyado, na isinasaalang-alang na ang tawag ay naharang at samakatuwid ay hindi itinuturing na napalampas, at isinasaalang-alang na ito ay isang tawag sa grupo, at may ibang sumagot nang mas maaga, na nangangahulugang ang tawag ay hindi rin napalampas.

Ang ganitong pag-iimbak ng impormasyon ay magbibigay-daan sa iyo na kunin ang bawat grupo nang hiwalay at matukoy kung gaano ito kaepektibo, at bumuo ng isang graph ng mga nasagot at hindi nakuhang mga grupo ayon sa oras. Maaari mo ring suriin kung gaano kahusay ang paghula ng koneksyon sa responsableng manager sa pamamagitan ng pagsusuri sa mga paglilipat pagkatapos kumonekta sa manager.

Maaari ka ring magsagawa ng medyo hindi tipikal na pag-aaral, halimbawa, kung gaano kadalas ang mga numero na wala sa database ay nag-dial ng tamang extension o kung anong porsyento ng mga papalabas na tawag ang ipinapasa sa isang mobile phone.

Ang resulta?

Ang isang espesyalista ay hindi kinakailangan upang mapanatili ang PBX; ang pinaka-ordinaryong tagapangasiwa ay maaaring gawin ito - nasubok sa pagsasanay.

Para sa mga pagbabago, hindi kailangan ang mga espesyalista na may seryosong kwalipikasyon; sapat na ang kaalaman sa PHP, dahil Ang mga module ay naisulat na para sa SIP protocol, at para sa pila, at para sa pagtawag sa isang empleyado, at iba pa. Mayroong isang klase ng wrapper para sa Asterisk. Upang bumuo ng isang module, ang isang programmer ay maaaring (at sa isang mahusay na paraan ay dapat) tumawag ng mga yari na module. At kaalaman Asterisk ay ganap na hindi kailangan kung hihilingin ng kliyente na magdagdag ng isang pahina na may ilang bagong ulat. Ngunit ipinapakita ng kasanayan na kahit na makayanan ng mga third-party na programmer, nakakaramdam sila ng kawalan ng katiyakan nang walang dokumentasyon at normal na saklaw ng mga komento, kaya may puwang pa rin para sa pagpapabuti.

Ang mga module ay maaaring:

lumikha ng mga bagong kakayahan sa pagproseso ng tawag,
magdagdag ng mga bagong bloke sa web interface,
magmana mula sa alinman sa mga umiiral na module, muling tukuyin ang mga function at palitan ito, o maging isang bahagyang binagong kopya,
idagdag ang iyong mga setting sa template ng mga setting ng iba pang mga module at marami pang iba.

Mga setting ng PBX sa pamamagitan ng API. Tulad ng inilarawan sa itaas, ang lahat ng mga setting ay naka-imbak sa database at binabasa sa oras ng tawag, upang maaari mong baguhin ang lahat ng mga setting ng PBX sa pamamagitan ng API. Kapag tumatawag sa API, ang pagsasaayos ay hindi muling ginawa at ang mga module ay hindi na-restart, samakatuwid, hindi mahalaga kung gaano karaming mga setting at empleyado ang mayroon ka. Ang mga kahilingan sa API ay mabilis na isinasagawa at hindi hinaharangan ang isa't isa.

Iniimbak ng PBX ang lahat ng pangunahing operasyon na may mga tawag na may mga tagal (paghihintay/pag-uusap), pagpupugad at sa mga termino ng PBX (empleyado, grupo, panlabas na linya, hindi channel, numero). Nagbibigay-daan ito sa iyo na bumuo ng iba't ibang ulat para sa mga partikular na kliyente at karamihan sa gawain ay lumikha ng interface na madaling gamitin.

Oras ang magsasabi kung ano ang susunod na mangyayari. Mayroon pa ring maraming mga nuances na kailangang muling ayusin, marami pa ring mga plano, ngunit isang taon na ang lumipas mula noong paglikha ng ika-3 bersyon at maaari na nating sabihin na gumagana ang ideya. Ang pangunahing kawalan ng bersyon 3 ay ang mga mapagkukunan ng hardware, ngunit ito ay karaniwang kung ano ang kailangan mong bayaran para sa kadalian ng pag-unlad.

Pinagmulan: www.habr.com

Ang kwento ng isang proyekto o kung paano ako gumugol ng 7 taon sa paglikha ng isang PBX batay sa Asterisk at Php