🥇 Hanes un prosiect neu sut treuliais 7 mlynedd yn creu PBX yn seiliedig ar Asterisk a Php

Does bosib fod gan lawer ohonoch chi, fel fi, syniad i wneud rhywbeth unigryw. Yn yr erthygl hon byddaf yn disgrifio'r problemau technegol a'r atebion y bu'n rhaid i mi eu hwynebu wrth ddatblygu'r PBX. Efallai y bydd hyn yn helpu rhywun i benderfynu ar eu syniad eu hunain, a rhywun i ddilyn y llwybr sathredig, oherwydd fe wnes i elwa hefyd o brofiad arloeswyr.

Syniad a gofynion allweddol

A dechreuodd y cyfan yn syml gyda chariad at Seren (fframwaith ar gyfer adeiladu cymwysiadau cyfathrebu), awtomeiddio teleffoni a gosodiadau Rhad PBX (rhyngwyneb gwe ar gyfer Seren). Pe bai anghenion y cwmni heb fanylion ac yn dod o fewn y galluoedd Rhad PBX - popeth yn wych. Digwyddodd y gosodiad cyfan o fewn XNUMX awr, derbyniodd y cwmni PBX wedi'i ffurfweddu, rhyngwyneb hawdd ei ddefnyddio a hyfforddiant byr ynghyd â chefnogaeth os dymunir.

Ond roedd y tasgau mwyaf diddorol yn ansafonol ac yna nid oedd mor wych. Seren yn gallu gwneud llawer, ond er mwyn cadw'r rhyngwyneb gwe yn gweithio, roedd angen treulio llawer mwy o amser. Felly gallai manylyn bach gymryd llawer mwy o amser na gosod gweddill y PBX. Ac nid y pwynt yw ei bod yn cymryd amser hir i ysgrifennu rhyngwyneb gwe, ond yn hytrach mae'r pwynt yn y nodweddion pensaernïol Rhad PBX. Dulliau a dulliau pensaernïaeth Rhad PBX wedi'i osod allan ar adeg php4, a bryd hynny roedd php5.6 eisoes y gellid gwneud popeth yn symlach ac yn fwy cyfleus arno.

Cynlluniau deialu graffigol ar ffurf diagram oedd y gwelltyn olaf. Pan geisiais adeiladu rhywbeth fel hyn ar gyfer Rhad PBX, sylweddolais y byddai'n rhaid i mi ei ailysgrifennu'n sylweddol a byddai'n haws adeiladu rhywbeth newydd.

Y gofynion allweddol oedd:

gosodiad syml, hygyrch yn reddfol hyd yn oed i weinyddwr newydd. Felly, nid oes angen cynnal a chadw PBX ar gwmnïau ar ein hochr ni,
addasiad hawdd fel bod tasgau'n cael eu datrys mewn digon o amser,
rhwyddineb integreiddio â PBX. U Rhad PBX nid oedd API ar gyfer newid gosodiadau, h.y. Ni allwch, er enghraifft, greu grwpiau neu ddewislenni llais o raglen trydydd parti, dim ond yr API ei hun Seren,
opensource - ar gyfer rhaglenwyr mae hyn yn hynod o bwysig ar gyfer addasiadau ar gyfer y cleient.

Y syniad o ddatblygiad cyflymach oedd cael yr holl ymarferoldeb yn cynnwys modiwlau ar ffurf gwrthrychau. Roedd yn rhaid i bob gwrthrych gael dosbarth rhiant cyffredin, sy'n golygu bod enwau'r holl brif swyddogaethau eisoes yn hysbys ac felly mae yna weithrediadau rhagosodedig eisoes. Bydd gwrthrychau yn caniatáu ichi leihau'n sylweddol nifer y dadleuon ar ffurf araeau cysylltiadol gydag allweddi llinynnol, y gallwch chi eu darganfod yn Rhad PBX Roedd yn bosibl trwy archwilio'r swyddogaeth gyfan a swyddogaethau nythu. Yn achos gwrthrychau, bydd awtolenwi banal yn dangos yr holl eiddo, ac yn gyffredinol bydd yn symleiddio bywyd lawer gwaith drosodd. Hefyd, mae etifeddiaeth ac ailddiffiniad eisoes yn datrys llawer o broblemau gydag addasiadau.

Y peth nesaf a arafodd yr amser ail-weithio ac yr oedd yn werth ei osgoi oedd dyblygu. Os oes modiwl sy'n gyfrifol am ddeialu cyflogai, yna dylai pob modiwl arall sydd angen anfon galwad at weithiwr ei ddefnyddio, a pheidio â chreu eu copïau eu hunain. Felly, os oes angen i chi newid rhywbeth, yna dim ond mewn un lle y bydd yn rhaid i chi newid a dylid chwilio am “sut mae'n gweithio” mewn un lle, ac ni ddylid ei chwilio trwy gydol y prosiect cyfan.

Fersiwn gyntaf a gwallau cyntaf

Roedd y prototeip cyntaf yn barod o fewn blwyddyn. Roedd y PBX cyfan, fel y cynlluniwyd, yn fodiwlaidd, a gallai'r modiwlau nid yn unig ychwanegu ymarferoldeb newydd ar gyfer prosesu galwadau, ond hefyd newid y rhyngwyneb gwe ei hun.

Ydy, nid fy un i yw’r syniad o adeiladu cynllun deialu ar ffurf cynllun o’r fath, ond mae’n gyfleus iawn a gwnes yr un peth ar gyfer Seren.

Drwy ysgrifennu modiwl, gallai rhaglenwyr eisoes:

creu eich swyddogaeth eich hun ar gyfer prosesu galwadau, y gellir eu gosod ar y diagram, yn ogystal ag yn y ddewislen o elfennau ar y chwith,
creu eich tudalennau eich hun ar gyfer y rhyngwyneb gwe ac ychwanegu eich templedi at dudalennau presennol (os yw datblygwr y dudalen wedi darparu ar gyfer hyn),
ychwanegu eich gosodiadau i'r prif dab gosodiadau neu greu eich tab gosodiadau eich hun,
gall y rhaglennydd etifeddu o fodiwl sy'n bodoli eisoes, newid rhan o'r swyddogaeth a'i gofrestru o dan enw newydd neu ddisodli'r modiwl gwreiddiol.

Er enghraifft, dyma sut y gallwch chi greu eich dewislen llais eich hun:

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

Daeth y gweithrediadau cymhleth cyntaf â'r balchder cyntaf a'r siomedigaethau cyntaf. Roeddwn yn falch ei fod yn gweithio, fy mod eisoes yn gallu atgynhyrchu'r prif nodweddion Rhad PBX. Roeddwn yn falch bod pobl yn hoffi’r syniad o’r cynllun. Roedd llawer o opsiynau o hyd i symleiddio datblygiad, ond hyd yn oed bryd hynny roedd rhai o'r tasgau eisoes yn cael eu gwneud yn haws.

Roedd yr API ar gyfer newid cyfluniad PBX yn siom - nid oedd y canlyniad o gwbl yr hyn yr oeddem ei eisiau. Cymerais yr un egwyddor ag yn Rhad PBX, trwy glicio ar y botwm Gwneud Cais, mae'r cyfluniad cyfan yn cael ei ail-greu ac mae'r modiwlau'n cael eu hailddechrau.

Mae'n edrych fel hyn:

*Rheol (algorithm) yw Dialplan ar gyfer prosesu galwad.

Ond gyda'r opsiwn hwn, mae'n amhosibl ysgrifennu API arferol ar gyfer newid y gosodiadau PBX. Yn gyntaf, gweithrediad cymhwyso newidiadau i Seren yn rhy hir ac yn defnyddio llawer o adnoddau.
Yn ail, ni allwch alw dwy swyddogaeth ar yr un pryd, oherwydd bydd y ddau yn creu'r cyfluniad.
Yn drydydd, mae'n cymhwyso pob gosodiad, gan gynnwys y rhai a wneir gan y gweinyddwr.

Yn y fersiwn hwn, fel yn Askozia, roedd yn bosibl cynhyrchu cyfluniad modiwlau wedi'u newid yn unig ac ailgychwyn y modiwlau angenrheidiol yn unig, ond mae'r rhain i gyd yn hanner mesurau. Roedd angen newid y dull gweithredu.

Ail fersiwn. Trwyn tynnu allan gynffon yn sownd

Nid y syniad i ddatrys y broblem oedd ail-greu'r cyfluniad a'r cynllun deialu ar gyfer Seren, ond arbed gwybodaeth i'r gronfa ddata a darllenwch o'r gronfa ddata yn uniongyrchol wrth brosesu'r alwad. Seren Roeddwn eisoes yn gwybod sut i ddarllen ffurfweddiadau o'r gronfa ddata, dim ond newid y gwerth yn y gronfa ddata a bydd yr alwad nesaf yn cael ei phrosesu gan ystyried y newidiadau, ac roedd y swyddogaeth yn berffaith ar gyfer darllen paramedrau cynllun deialu REALTIME_HASH.

Yn y diwedd, nid oedd angen hyd yn oed ailgychwyn Seren wrth newid y gosodiadau a dechreuwyd cymhwyso pob gosodiad ar unwaith Seren.

Yr unig newidiadau i'r cynllun deialu yw ychwanegu rhifau estyniad a awgrymiadau. Ond mân newidiadau oedd y rhain

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

Gallwch chi ychwanegu neu newid llinell yn hawdd yn y cynllun deialu gan ddefnyddio Ami (rhyngwyneb rheoli Seren) ac nid oes angen ailgychwyn y cynllun deialu cyfan.

Roedd hyn yn datrys y broblem gyda'r API ffurfweddu. Gallech hyd yn oed fynd yn uniongyrchol i'r gronfa ddata ac ychwanegu grŵp newydd neu newid, er enghraifft, yr amser deialu yn y maes “amser deialu” ar gyfer y grŵp a byddai'r alwad nesaf eisoes yn para'r amser penodedig (Nid yw hwn yn argymhelliad ar gyfer gweithredu, gan fod angen rhai gweithrediadau API Ami galwadau).

Unwaith eto daeth y gweithrediadau anodd cyntaf â'r balchder a'r siom gyntaf. Roeddwn yn falch ei fod wedi gweithio. Daeth y gronfa ddata yn gyswllt hanfodol, cynyddodd y ddibyniaeth ar y ddisg, roedd mwy o risgiau, ond gweithiodd popeth yn sefydlog a heb broblemau. Ac yn bwysicaf oll, nawr gellid gwneud popeth y gellid ei wneud trwy'r rhyngwyneb gwe trwy'r API, a defnyddiwyd yr un dulliau. Yn ogystal, cafodd y rhyngwyneb gwe wared ar y botwm “cymhwyso gosodiadau i PBX”, y mae gweinyddwyr yn aml yn anghofio amdano.

Y siom oedd bod y datblygiad wedi mynd yn fwy cymhleth. Ers y fersiwn gyntaf, mae'r iaith PHP wedi cynhyrchu cynllun deialu yn yr iaith Seren ac y mae yn edrych yn hollol annarllenadwy, yn nghyda'r iaith ei hun Seren am ysgrifenu dialplan y mae yn hynod gyntefig.

Sut olwg oedd arno:

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

Yn yr ail fersiwn, daeth y cynllun deialu yn gyffredinol, roedd yn cynnwys yr holl opsiynau prosesu posibl yn dibynnu ar y paramedrau a chynyddodd ei faint yn sylweddol. Arafodd hyn oll yr amser datblygu yn fawr, ac roedd yr union feddwl bod angen ymyrryd â'r cynllun deialu unwaith eto yn fy ngwneud yn drist.

Trydydd fersiwn

Nid cynhyrchu oedd y syniad i ddatrys y broblem Seren cynllun deialu o php a defnyddio FastAGI ac ysgrifennu'r holl reolau prosesu yn PHP ei hun. FastAGI yn caniatáu Seren, i brosesu'r alwad, cysylltu â'r soced. Derbyn gorchmynion oddi yno ac anfon canlyniadau. Felly, mae rhesymeg y cynllun deialu eisoes y tu allan i'r ffiniau Seren a gellir ei ysgrifennu mewn unrhyw iaith, yn fy achos i yn PHP.

Bu llawer o brofi a methu. Y brif broblem oedd bod gen i lawer o ddosbarthiadau/ffeiliau yn barod. Cymerodd tua 1,5 eiliad i greu gwrthrychau, eu cychwyn, a chofrestru ei gilydd â'i gilydd, ac nid yw'r oedi hwn fesul galwad yn rhywbeth y gellir ei anwybyddu.

Dim ond unwaith y dylai cychwyniad fod wedi digwydd ac felly dechreuwyd chwilio am ateb trwy ysgrifennu gwasanaeth yn php gan ddefnyddio Pthreads. Ar ôl wythnos o arbrofi, rhoddwyd yr opsiwn hwn o'r neilltu oherwydd cymhlethdodau sut mae'r estyniad hwn yn gweithio. Ar ôl mis o brofi, roedd yn rhaid i mi hefyd roi'r gorau i raglennu asyncronig yn PHP; roedd angen rhywbeth syml arnaf, a oedd yn gyfarwydd i unrhyw ddechreuwr PHP, ac mae llawer o estyniadau ar gyfer PHP yn gydamserol.

Yr ateb oedd ein gwasanaeth aml-edau ein hunain yn C, a luniwyd gyda PHPLIB. Mae'n llwytho'r holl ffeiliau php ATS, yn aros i'r holl fodiwlau gychwyn, yn ychwanegu galwad yn ôl at ei gilydd, a phan fydd popeth yn barod, yn ei storio. Wrth ymholi gan FastAGI mae ffrwd yn cael ei chreu, copi o storfa'r holl ddosbarthiadau a data yn cael ei atgynhyrchu ynddo, a'r cais yn cael ei drosglwyddo i'r swyddogaeth php.

Gyda'r ateb hwn, mae'r amser o anfon galwad i'n gwasanaeth i'r gorchymyn cyntaf Seren gostwng o 1,5s i 0,05s ac mae'r amser hwn yn dibynnu ychydig ar faint y prosiect.

O ganlyniad, lleihawyd yr amser ar gyfer datblygu cynllun deialu yn sylweddol, a gallaf werthfawrogi hyn oherwydd bu'n rhaid i mi ailysgrifennu cynllun deialu cyfan yr holl fodiwlau yn PHP. Yn gyntaf, dylid ysgrifennu dulliau eisoes yn php i gael gwrthrych o'r gronfa ddata; roedd eu hangen i'w harddangos yn y rhyngwyneb gwe, ac yn ail, a dyma'r prif beth, o'r diwedd mae'n bosibl gweithio'n gyfleus gyda llinynnau gyda rhifau ac araeau gyda chronfa ddata ynghyd â llawer o estyniadau PHP.

I brosesu'r cynllun deialu yn y dosbarth modiwl mae angen i chi weithredu'r swyddogaeth deialuDynamicCall a dadl pbxCaisGalw bydd yn cynnwys gwrthrych i ryngweithio ag ef Seren.

Yn ogystal, daeth yn bosibl dadfygio'r cynllun deialu (mae gan php xdebug ac mae'n gweithio i'n gwasanaeth), gallwch symud gam wrth gam trwy edrych ar werthoedd newidynnau.

Data galwadau

Mae angen data a gasglwyd yn gywir ar gyfer unrhyw ddadansoddeg ac adroddiadau, ac aeth y bloc PBX hwn hefyd trwy lawer o brawf a gwall o'r fersiwn gyntaf i'r trydydd fersiwn. Yn aml, mae data galwadau yn arwydd. Un alwad = un recordiad: pwy ffoniodd, pwy atebodd, pa mor hir y buont yn siarad. Mewn opsiynau mwy diddorol, mae arwydd ychwanegol yn nodi pa weithiwr PBX a alwyd yn ystod yr alwad. Ond dim ond rhan o'r anghenion y mae hyn i gyd yn ei gwmpasu.

Y gofynion cychwynnol oedd:

arbed nid yn unig pwy a alwodd y PBX, ond hefyd pwy a atebodd, oherwydd ceir rhyng-syniadau a bydd angen cymryd hyn i ystyriaeth wrth ddadansoddi galwadau,
amser cyn cysylltu â gweithiwr. Yn Rhad PBX a rhai PBXs eraill, ystyrir bod yr alwad yn cael ei hateb cyn gynted ag y bydd y PBX yn codi'r ffôn. Ond ar gyfer y ddewislen llais mae angen i chi godi'r ffôn yn barod, felly mae pob galwad yn cael ei hateb ac mae'r amser aros am ateb yn dod yn 0-1 eiliad. Felly, penderfynwyd arbed nid yn unig yr amser cyn ymateb, ond yr amser cyn cysylltu â modiwlau allweddol (mae'r modiwl ei hun yn gosod y faner hon. Ar hyn o bryd mae'n "Gweithiwr", "llinell allanol"),
ar gyfer cynllun deialu mwy cymhleth, pan fydd galwad yn teithio rhwng gwahanol grwpiau, roedd angen gallu archwilio pob elfen ar wahân.

Yr opsiwn gorau oedd pan fydd y modiwlau PBX yn anfon gwybodaeth amdanynt eu hunain ar alwadau ac yn y pen draw yn arbed y wybodaeth ar ffurf coeden.

Mae'n edrych fel hyn:

Yn gyntaf, gwybodaeth gyffredinol am yr alwad (fel pawb arall - dim byd arbennig).

Wedi derbyn galwad ar linell allanol"Ar gyfer y prawf"am 05:55:52 o'r rhif 89295671458 i'r rhif 89999999999, yn y diwedd fe'i hatebwyd gan weithiwr"Ysgrifennydd2» gyda rhif 104. Arhosodd y cleient 60 eiliad a siarad am 36 eiliad.
Gweithiwr"Ysgrifennydd2"gwneud galwad i 112 a gweithiwr yn ateb"Rheolwr1» ar ôl 8 eiliad. Maen nhw'n siarad am 14 eiliad.
Mae'r Cleient yn cael ei drosglwyddo i'r Gweithiwr "rheolwr 1" lle maen nhw'n parhau i siarad am 13 eiliad arall

Ond dyma flaen y mynydd iâ; ar gyfer pob cofnod gallwch gael hanes galwadau manwl trwy'r PBX.

Cyflwynir yr holl wybodaeth fel nythu galwadau:

Wedi derbyn galwad ar linell allanol"Ar gyfer y prawf» am 05:55:52 o'r rhif 89295671458 i'r rhif 89999999999.
Am 05:55:53 mae'r llinell allanol yn anfon galwad i'r gylched sy'n dod i mewn "prawf»
Wrth brosesu galwad yn ôl y cynllun, mae'r modiwl “galwad rheolwr", lle mae'r alwad yn 16 eiliad. Mae hwn yn fodiwl a ddatblygwyd ar gyfer y cleient.
Modiwl "galwad rheolwr" yn anfon galwad at y gweithiwr sy'n gyfrifol am y rhif (cleient) "Rheolwr1” ac yn aros 5 eiliad am ymateb. Wnaeth y rheolwr ddim ateb.
Modiwl "galwad rheolwr"yn anfon galwad i'r grŵp"rheolwyr CORP" Mae'r rhain yn reolwyr eraill o'r un cyfeiriad (yn eistedd yn yr un ystafell) ac yn aros 11 eiliad am ymateb.
Grŵp "rheolwyr CORP"yn galw gweithwyr"Rheolwr1, Rheolwr2, Rheolwr3"ar yr un pryd am 11 eiliad. Dim Ateb.
Mae galwad y rheolwr yn dod i ben. Ac mae'r gylched yn anfon galwad i'r modiwl "Dewis llwybr o 1c" Hefyd modiwl wedi'i ysgrifennu ar gyfer y cleient. Yma cafodd yr alwad ei phrosesu am 0 eiliad.
Mae'r gylched yn anfon galwad i'r ddewislen llais "Sylfaenol gyda deialu ychwanegol" Arhosodd y cleient yno am 31 eiliad, nid oedd unrhyw ddeialu ychwanegol.
Mae'r cynllun yn anfon galwad i'r Grŵp "Ysgrifenyddion", lle bu'r cleient yn aros 12 eiliad.
Mewn grŵp, gelwir 2 weithiwr ar yr un pryd "Ysgrifennydd1"Ac"Ysgrifennydd2" ac ar ôl 12 eiliad mae'r gweithiwr yn ateb "Ysgrifennydd2" Mae'r ateb i'r alwad yn cael ei ddyblygu i alwadau rhieni. Mae'n ymddangos iddo ateb yn y grŵp “Ysgrifennydd2" , wrth ffonio atebodd y gylched "Ysgrifennydd2" ac atebodd yr alwad ar y llinell allanol gyda "Ysgrifennydd2'.

Arbed gwybodaeth am bob gweithrediad a'u nythu fydd yn ei gwneud hi'n bosibl gwneud adroddiadau. Bydd adroddiad ar y ddewislen llais yn eich helpu i ddarganfod faint mae'n helpu neu'n rhwystro. Llunio adroddiad ar alwadau a gollwyd gan weithwyr, gan gymryd i ystyriaeth bod yr alwad wedi’i rhyng-gipio ac felly nid ystyrir ei bod wedi’i cholli, a chan gymryd i ystyriaeth mai galwad grŵp ydoedd, a rhywun arall wedi’i ateb yn gynharach, sy’n golygu na methwyd yr alwad ychwaith.

Bydd storio gwybodaeth o'r fath yn caniatáu ichi gymryd pob grŵp ar wahân a phenderfynu pa mor effeithiol y mae'n gweithio, ac adeiladu graff o grwpiau a atebwyd ac a gollwyd fesul awr. Gallwch hefyd wirio pa mor gywir yw'r cysylltiad â'r rheolwr cyfrifol trwy ddadansoddi'r trosglwyddiadau ar ôl cysylltu â'r rheolwr.

Gallwch hefyd gynnal astudiaethau eithaf annodweddiadol, er enghraifft, pa mor aml y mae rhifau nad ydynt yn y gronfa ddata yn deialu'r estyniad cywir neu pa ganran o alwadau sy'n mynd allan sy'n cael eu hanfon ymlaen i ffôn symudol.

Y canlyniad?

Nid oes angen arbenigwr i gynnal y PBX; gall y gweinyddwr mwyaf cyffredin ei wneud - wedi'i brofi'n ymarferol.

Ar gyfer addasiadau, nid oes angen arbenigwyr â chymwysterau difrifol; mae gwybodaeth am PHP yn ddigonol, oherwydd Mae modiwlau eisoes wedi'u hysgrifennu ar gyfer protocol SIP, ac ar gyfer y ciw, ac ar gyfer galw cyflogai, ac eraill. Mae dosbarth lapio ar gyfer Seren. I ddatblygu modiwl, gall rhaglennydd (a dylai mewn ffordd dda) alw modiwlau parod. A gwybodaeth Seren yn gwbl ddiangen os bydd y cleient yn gofyn am ychwanegu tudalen gyda rhyw adroddiad newydd. Ond mae arfer yn dangos, er y gall rhaglenwyr trydydd parti ymdopi, eu bod yn teimlo'n ansicr heb ddogfennaeth a sylw arferol i sylwadau, felly mae lle i wella o hyd.

Gall modiwlau:

creu galluoedd prosesu galwadau newydd,
ychwanegu blociau newydd i'r rhyngwyneb gwe,
etifeddu o unrhyw un o'r modiwlau presennol, ailddiffinio swyddogaethau a'u disodli, neu fod yn gopi wedi'i addasu ychydig,
ychwanegwch eich gosodiadau at dempled gosodiadau modiwlau eraill a llawer mwy.

Gosodiadau PBX trwy API. Fel y disgrifir uchod, mae'r holl leoliadau yn cael eu storio yn y gronfa ddata a'u darllen ar adeg yr alwad, felly gallwch chi newid pob gosodiad PBX trwy'r API. Wrth alw'r API, nid yw'r ffurfweddiad yn cael ei ail-greu ac nid yw'r modiwlau'n cael eu hailddechrau, felly, nid oes ots faint o leoliadau a gweithwyr sydd gennych. Mae ceisiadau API yn cael eu gweithredu'n gyflym ac nid ydynt yn rhwystro ei gilydd.

Mae'r PBX yn storio'r holl weithrediadau allweddol gyda galwadau sy'n para (aros / sgwrs), nythu ac mewn termau PBX (gweithiwr, grŵp, llinell allanol, nid sianel, rhif). Mae hyn yn eich galluogi i adeiladu adroddiadau amrywiol ar gyfer cleientiaid penodol a'r rhan fwyaf o'r gwaith yw creu rhyngwyneb hawdd ei ddefnyddio.

Amser a ddengys beth fydd yn digwydd nesaf. Mae yna lawer o arlliwiau y mae angen eu hail-wneud o hyd, mae yna lawer o gynlluniau o hyd, ond mae blwyddyn wedi mynd heibio ers creu'r 3ydd fersiwn a gallwn ddweud eisoes bod y syniad yn gweithio. Prif anfantais fersiwn 3 yw'r adnoddau caledwedd, ond fel arfer dyma'r hyn y mae'n rhaid i chi dalu amdano er mwyn hwyluso datblygiad.

Ffynhonnell: hab.com

Hanes un prosiect neu sut treuliais 7 mlynedd yn creu PBX yn seiliedig ar Asterisk a Php