Անշուշտ ձեզնից շատերի մոտ, ինչպես ես, մտահղացել եք ինչ-որ յուրահատուկ բան անել։ Այս հոդվածում ես նկարագրելու եմ տեխնիկական խնդիրներն ու լուծումները, որոնց հետ ես ստիպված էի հանդիպել PBX-ը մշակելիս: Թերևս սա կօգնի ինչ-որ մեկին որոշել սեփական գաղափարը, և ինչ-որ մեկին գնալ ոտնահարված ճանապարհով, քանի որ ես նույնպես օգտվեցի ռահվիրաների փորձից։
Գաղափարը և հիմնական պահանջները
Եվ ամեն ինչ սկսվեց պարզապես սիրուց Աստղանիշ (կոմունիկացիոն հավելվածների կառուցման շրջանակ), հեռախոսակապի և տեղակայումների ավտոմատացում freepbx (վեբ ինտերֆեյսի համար Աստղանիշ) Եթե ընկերության կարիքները զերծ էին յուրահատկություններից և մտնում էին հնարավորությունների մեջ freepbx - ամեն ինչ հիանալի է: Ամբողջ տեղադրումը տեղի ունեցավ XNUMX ժամվա ընթացքում, ընկերությունը ստացավ կազմաձևված PBX, օգտագործողի համար հարմար ինտերֆեյս և կարճ ուսուցում, գումարած աջակցություն, եթե ցանկանաք:
Բայց ամենահետաքրքիր առաջադրանքները ոչ ստանդարտ էին, իսկ հետո այնքան էլ առասպելական չէր։ Աստղանիշ կարող է շատ բան անել, բայց վեբ ինտերֆեյսը աշխատանքային վիճակում պահելու համար անհրաժեշտ էր շատ անգամ ավելի շատ ժամանակ ծախսել: Այսպիսով, փոքր մանրամասնությունը կարող է շատ ավելի երկար տևել, քան PBX-ի մնացած մասը տեղադրելը: Եվ բանն այն չէ, որ երկար ժամանակ է պահանջվում վեբ ինտերֆեյս գրելու համար, այլ այն ճարտարապետական առանձնահատկությունների մեջ է։ freepbx. Ճարտարապետության մոտեցումներն ու մեթոդները freepbx դրված էր php4-ի ժամանակ, և այդ պահին արդեն կար php5.6, որի վրա ամեն ինչ կարելի էր ավելի պարզ և հարմար դարձնել:
Վերջին կաթիլը գրաֆիկական թվային պլաններն էին դիագրամի տեսքով: Երբ ես փորձեցի նման բան կառուցել freepbx, ես հասկացա, որ պետք է զգալիորեն վերաշարադրեմ այն և ավելի հեշտ կլինի նոր բան կառուցել։
Հիմնական պահանջներն էին.
- պարզ կարգավորում, ինտուիտիվ հասանելի նույնիսկ սկսնակ ադմինիստրատորի համար: Այսպիսով, ընկերությունները մեր կողմից չեն պահանջում PBX-ի սպասարկում,
- հեշտ փոփոխություն, որպեսզի խնդիրները լուծվեն համապատասխան ժամանակում,
- PBX-ի հետ ինտեգրվելու հեշտությունը: U freepbx կարգավորումները փոխելու համար API չկար, այսինքն. Դուք չեք կարող, օրինակ, ստեղծել խմբեր կամ ձայնային ընտրացանկեր երրորդ կողմի հավելվածից, միայն հենց API-ից Աստղանիշ,
- opensource - ծրագրավորողների համար սա չափազանց կարևոր է հաճախորդի համար փոփոխությունների համար:
Ավելի արագ զարգացման գաղափարն այն էր, որ ամբողջ ֆունկցիոնալությունը բաղկացած լինի օբյեկտների տեսքով մոդուլներից: Բոլոր օբյեկտները պետք է ունենան ընդհանուր ծնող դաս, ինչը նշանակում է, որ բոլոր հիմնական գործառույթների անուններն արդեն հայտնի են, և հետևաբար կան արդեն լռելյայն իրականացումներ: Օբյեկտները թույլ կտան կտրուկ նվազեցնել արգումենտների թիվը լարային ստեղներով ասոցիատիվ զանգվածների տեսքով, որը կարող եք պարզել freepbx Դա հնարավոր եղավ ուսումնասիրելով ամբողջ ֆունկցիան և ներդիր ֆունկցիաները։ Օբյեկտների դեպքում սովորական ինքնալրացումը ցույց կտա բոլոր հատկությունները, և ընդհանրապես կյանքը բազմապատիկ կհեշտացնի։ Բացի այդ, ժառանգությունն ու վերասահմանումը արդեն իսկ լուծում են բազմաթիվ խնդիրներ՝ փոփոխությունների հետ կապված:
Հաջորդ բանը, որը դանդաղեցրեց վերամշակման ժամանակը և արժեր խուսափել, կրկնօրինակումն էր: Եթե կա մոդուլ, որը պատասխանատու է աշխատողին հավաքելու համար, ապա բոլոր մյուս մոդուլները, որոնք պետք է զանգահարեն աշխատողին, պետք է օգտագործեն այն, այլ ոչ թե ստեղծեն իրենց սեփական պատճենները: Այսպիսով, եթե դուք պետք է ինչ-որ բան փոխեք, ապա դուք ստիպված կլինեք փոխել միայն մեկ վայրում, և «ինչպես է այն աշխատում» որոնումը պետք է իրականացվի մեկ տեղում, այլ ոչ թե որոնվի ամբողջ նախագծի ընթացքում:
Առաջին տարբերակը և առաջին սխալները
Առաջին նախատիպը պատրաստ էր մեկ տարվա ընթացքում։ Ամբողջ PBX-ը, ինչպես նախատեսվում էր, մոդուլային էր, և մոդուլները կարող էին ոչ միայն նոր գործառույթներ ավելացնել զանգերի մշակման համար, այլ նաև փոխել վեբ ինտերֆեյսը:
Այո, նման սխեմայի տեսքով թվային պլան կառուցելու գաղափարը իմը չէ, բայց դա շատ հարմար է, և ես նույնն արեցի դրա համար. Աստղանիշ.
Մոդուլ գրելով՝ ծրագրավորողներն արդեն կարող էին.
- ստեղծեք ձեր սեփական գործառույթը զանգերի մշակման համար, որը կարող է տեղադրվել դիագրամի վրա, ինչպես նաև ձախ կողմում գտնվող տարրերի ցանկում,
- ստեղծեք ձեր սեփական էջերը վեբ ինտերֆեյսի համար և ավելացրեք ձեր ձևանմուշները առկա էջերին (եթե էջի մշակողը դա նախատեսել է),
- ավելացրեք ձեր կարգավորումները հիմնական կարգավորումների ներդիրին կամ ստեղծեք ձեր սեփական կարգավորումների ներդիրը,
- ծրագրավորողը կարող է ժառանգել գոյություն ունեցող մոդուլից, փոխել ֆունկցիոնալության մի մասը և գրանցել այն նոր անունով կամ փոխարինել բնօրինակ մոդուլը:
Օրինակ, այսպես կարող եք ստեղծել ձեր սեփական ձայնային ընտրացանկը.
......
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__); //Подменить существующий модульԱռաջին բարդ իրականացումները բերեցին առաջին հպարտությունն ու առաջին հիասթափությունները։ Ուրախ էի, որ ստացվեց, որ արդեն կարողացա վերարտադրել հիմնական հատկանիշները freepbx. Ուրախ էի, որ մարդկանց դուր եկավ սխեմայի գաղափարը։ Դեռևս շատ տարբերակներ կային զարգացումը պարզեցնելու համար, բայց նույնիսկ այդ ժամանակ որոշ առաջադրանքներ արդեն հեշտացվում էին։
PBX-ի կոնֆիգուրացիան փոխելու API-ն հիասթափություն էր. արդյունքն ամենևին էլ այն չէր, ինչ մենք ուզում էինք: Ես վերցրեցի նույն սկզբունքը, ինչ որ freepbx, սեղմելով Դիմել կոճակը, ամբողջ կոնֆիգուրացիան վերստեղծվում է, և մոդուլները վերագործարկվում են:
Այն կարծես այսպիսին է.
*Dialplan-ը կանոն (ալգորիթմ) է, որով զանգը մշակվում է:
Բայց այս տարբերակով անհնար է սովորական API գրել PBX-ի կարգավորումները փոխելու համար։ Նախ, փոփոխությունների կիրառման գործողությունը Աստղանիշ չափազանց երկար և ռեսուրսների ինտենսիվ:
Երկրորդ, դուք չեք կարող միաժամանակ զանգահարել երկու գործառույթ, քանի որ երկուսն էլ կստեղծեն կոնֆիգուրացիան:
Երրորդ, այն կիրառում է բոլոր կարգավորումները, ներառյալ ադմինիստրատորի կողմից արվածները:
Այս տարբերակում, ինչպես Ասկոզիա, հնարավոր եղավ գեներացնել միայն փոխված մոդուլների կոնֆիգուրացիան և վերագործարկել միայն անհրաժեշտ մոդուլները, բայց սրանք բոլորը կիսով չափ միջոցներ են։ Պետք էր փոխել մոտեցումը.
Երկրորդ տարբերակը. Քիթ քաշեց դուրս պոչը խրված
Խնդիրը լուծելու գաղափարը չէր վերստեղծել կոնֆիգուրացիան և թվային պլանը Աստղանիշ, բայց տեղեկատվությունը պահեք տվյալների բազայում և զանգը մշակելիս անմիջապես կարդացեք տվյալների բազայից: Աստղանիշ Ես արդեն գիտեի, թե ինչպես կարդալ կոնֆիգուրացիան տվյալների բազայից, պարզապես փոխեք արժեքը տվյալների բազայում, և հաջորդ զանգը կմշակվի՝ հաշվի առնելով փոփոխությունները, և ֆունկցիան կատարյալ էր հավաքագրման պլանի պարամետրերը կարդալու համար: REALTIME_HASH.
Ի վերջո, նույնիսկ վերագործարկման կարիք չկար Աստղանիշ երբ փոխելով կարգավորումները, և բոլոր կարգավորումները սկսեցին անմիջապես կիրառվել Աստղանիշ.
Թվային պլանի միակ փոփոխությունները ընդլայնման համարների ավելացումն է և ում խոսել. Բայց դրանք փոքր տեղային փոփոխություններ էին
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)
...Դուք կարող եք հեշտությամբ ավելացնել կամ փոխել գիծը հավաքագրման պլանում՝ օգտագործելով Ամի (վերահսկման ինտերֆեյս Աստղանիշ) և ամբողջ թվային պլանի վերագործարկում չի պահանջվում:
Սա լուծեց կոնֆիգուրացիայի API-ի հետ կապված խնդիրը: Դուք նույնիսկ կարող եք ուղղակիորեն մտնել տվյալների բազա և ավելացնել նոր խումբ կամ փոխել, օրինակ, խմբի համար «dialtime» դաշտում հավաքելու ժամանակը, իսկ հաջորդ զանգն արդեն կտևի նշված ժամանակը (սա առաջարկություն չէ գործողություն, քանի որ որոշ API գործողություններ պահանջում են Ամի զանգեր):
Առաջին դժվար իրականացումները կրկին բերեցին առաջին հպարտությունն ու հիասթափությունը։ Ուրախ էի, որ ստացվեց։ Տվյալների բազան դարձավ կրիտիկական հղում, կախվածությունը սկավառակից ավելացավ, ռիսկերն ավելի շատ էին, բայց ամեն ինչ աշխատում էր կայուն և առանց խնդիրների։ Եվ ամենակարեւորը, հիմա այն ամենը, ինչ կարելի էր անել վեբ ինտերֆեյսի միջոցով, կարելի էր անել API-ի միջոցով, և կիրառվեցին նույն մեթոդները։ Բացի այդ, վեբ ինտերֆեյսը ազատվեց «կիրառել կարգավորումները PBX-ին» կոճակից, որի մասին ադմինիստրատորները հաճախ մոռանում էին:
Հիասթափությունն այն էր, որ զարգացումն ավելի բարդացավ։ Առաջին տարբերակից ի վեր, PHP լեզուն ստեղծել է լեզվով հավաքագրման պլան Աստղանիշ և այն ամբողջովին անընթեռնելի է թվում, գումարած հենց լեզուն Աստղանիշ Dialplan գրելու համար դա չափազանց պարզունակ է:
Ինչ տեսք ուներ.
$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'))Երկրորդ տարբերակում dialplan-ը դարձավ ունիվերսալ, այն ներառում էր բոլոր հնարավոր մշակման տարբերակները կախված պարամետրերից և դրա չափը զգալիորեն ավելացավ: Այս ամենը մեծապես դանդաղեցրեց զարգացման ժամանակը, և հենց այն միտքը, որ ևս մեկ անգամ անհրաժեշտ է խանգարել թվային պլանին, ինձ տխրեց:
Երրորդ տարբերակ
Խնդիրը լուծելու գաղափարը գեներացնելը չէր Աստղանիշ dialplan php-ից և օգտագործել FastAGI և գրեք մշակման բոլոր կանոնները հենց PHP-ում: FastAGI թույլ է տալիս Աստղանիշ, զանգը մշակելու համար միացեք վարդակից: Ստացեք հրամաններ այնտեղից և ուղարկեք արդյունքները: Այսպիսով, dialplan-ի տրամաբանությունն արդեն սահմաններից դուրս է Աստղանիշ և կարող է գրվել ցանկացած լեզվով, իմ դեպքում՝ PHP-ով։
Կային շատ փորձեր և սխալներ: Հիմնական խնդիրն այն էր, որ ես արդեն ունեի շատ դասեր/ֆայլեր։ Մոտ 1,5 վայրկյան պահանջվեց օբյեկտներ ստեղծելու, դրանք սկզբնավորելու և միմյանց գրանցելու համար, և մեկ զանգի համար այս ուշացումը այն չէ, որը կարելի է անտեսել:
Նախաձեռնումը պետք է տեղի ունենար միայն մեկ անգամ, և, հետևաբար, լուծման որոնումը սկսվեց php-ով ծառայություն գրելով Թելեր. Մեկ շաբաթ տեւած փորձարկումներից հետո այս տարբերակը դադարեցվեց՝ այս ընդլայնման աշխատանքի բարդությունների պատճառով: Մեկ ամսվա փորձարկումից հետո ես նույնպես ստիպված էի հրաժարվել PHP-ում ասինխրոն ծրագրավորումից, ինձ պետք էր ինչ-որ պարզ, ծանոթ PHP-ի ցանկացած սկսնակի համար, և PHP-ի շատ ընդլայնումներ համաժամանակյա են:
Լուծումը մեր սեփական բազմաթելային ծառայությունն էր C-ով, որը կազմվել էր PHPLIB. Այն բեռնում է ATS-ի բոլոր php ֆայլերը, սպասում է բոլոր մոդուլների սկզբնավորմանը, ավելացնում է միմյանց հետ կանչը և երբ ամեն ինչ պատրաստ է, քեշավորում է այն: Երբ հարցնում է FastAGI ստեղծվում է հոսք, բոլոր դասերի և տվյալների քեշից պատճենը վերարտադրվում է դրանում, և հարցումը փոխանցվում է php ֆունկցիային։
Այս լուծմամբ՝ մեր ծառայության զանգ ուղարկելուց մինչև առաջին հրամանը Աստղանիշ նվազել է 1,5 վրկ-ից մինչև 0,05 վրկ և այս անգամ փոքր-ինչ կախված է նախագծի չափից:
Արդյունքում, dialplan-ի մշակման ժամանակը զգալիորեն կրճատվեց, և ես կարող եմ գնահատել դա, քանի որ ես ստիպված էի վերաշարադրել բոլոր մոդուլների ամբողջ թվային պլանը PHP-ում: Նախ, մեթոդները պետք է արդեն գրվեն php-ով տվյալների բազայից օբյեկտ ստանալու համար, դրանք անհրաժեշտ էին վեբ ինտերֆեյսում ցուցադրելու համար, և երկրորդ, և սա է հիմնականը, վերջապես հնարավոր է հարմար աշխատել թվերով և զանգվածներով տողերի հետ: տվյալների բազայով, գումարած բազմաթիվ PHP ընդլայնումներ:
Dialplan-ը մոդուլի դասում մշակելու համար անհրաժեշտ է իրականացնել գործառույթը dialplanDynamicCall և փաստարկ pbxCallRequest կպարունակի առարկա, որի հետ փոխազդելու համար Աստղանիշ.
Բացի այդ, հնարավոր դարձավ կարգաբերել dialplan-ը (php-ն ունի xdebug և այն աշխատում է մեր ծառայության համար), կարող եք քայլ առ քայլ շարժվել՝ դիտելով փոփոխականների արժեքները։
Զանգի տվյալներ
Ցանկացած վերլուծություն և հաշվետվություն պահանջում է ճիշտ հավաքագրված տվյալներ, և PBX-ի այս բլոկը նույնպես շատ փորձությունների և սխալների միջով անցավ առաջինից երրորդ տարբերակից: Հաճախ զանգի տվյալները նշան են: Մեկ զանգ = մեկ ձայնագրություն՝ ով զանգեց, ով պատասխանեց, ինչքան խոսեցին։ Ավելի հետաքրքիր տարբերակներում կա լրացուցիչ նշան, որը ցույց է տալիս, թե որ PBX աշխատակիցն է կանչվել զանգի ժամանակ: Բայց այս ամենը ներառում է կարիքների միայն մի մասը։
Նախնական պահանջներն էին.
- փրկեք ոչ միայն, թե ում է զանգահարել PBX-ը, այլև ով է պատասխանել, որովհետև կան գաղտնալսումներ, և դա պետք է հաշվի առնել զանգերը վերլուծելիս,
- աշխատակցի հետ կապվելուց առաջ։ Մեջ freepbx և որոշ այլ PBX-ներ, զանգը համարվում է պատասխանված, հենց որ PBX-ը վերցնում է հեռախոսը: Բայց ձայնային ընտրացանկի համար դուք արդեն պետք է վերցնեք հեռախոսը, այնպես որ բոլոր զանգերը պատասխանվում են, և պատասխանի սպասման ժամանակը դառնում է 0-1 վայրկյան: Հետևաբար, որոշվեց խնայել ոչ միայն պատասխանից առաջ, այլև հիմնական մոդուլների հետ միանալու ժամանակը (մոդուլն ինքն է սահմանում այս դրոշը: Ներկայումս դա «Աշխատակից», «Արտաքին գիծ» է):
- Ավելի բարդ թվային պլանի համար, երբ զանգը անցնում է տարբեր խմբերի միջև, անհրաժեշտ էր յուրաքանչյուր տարր առանձին ուսումնասիրել:
Լավագույն տարբերակը պարզվեց, երբ PBX մոդուլները զանգերի ժամանակ ուղարկում են տեղեկատվություն իրենց մասին և, ի վերջո, պահպանում են տեղեկատվությունը ծառի տեսքով:
Կարծես այսպիսին է.
Նախ, ընդհանուր տեղեկություններ զանգի մասին (ինչպես բոլորը. ոչ մի առանձնահատուկ բան):
- Զանգ է ստացել դրսի գծով»Համար խմոր«ժամը 05:55:52-ին 89295671458 համարից մինչև 89999999999, վերջում պատասխանել է աշխատողը».քարտուղար 2» 104 համարով: Հաճախորդը սպասեց 60 վայրկյան և խոսեց 36 վայրկյան:
- Աշխատակից»քարտուղար 2«Զանգում է 112, և աշխատակիցը պատասխանում է».Կառավարիչ 1» 8 վայրկյան հետո: Նրանք խոսում են 14 վայրկյան։
- Հաճախորդը փոխանցվում է աշխատակցին»կառավարիչ 1«որտեղ նրանք շարունակում են խոսել ևս 13 վայրկյան
Բայց սա այսբերգի գագաթն է, յուրաքանչյուր ռեկորդի համար դուք կարող եք մանրամասն զանգերի պատմություն ստանալ PBX-ի միջոցով:
Ամբողջ տեղեկատվությունը ներկայացված է որպես զանգերի բույն.
- Զանգ է ստացել դրսի գծով»Համար խմոր» ժամը 05:55:52-ին 89295671458 համարից մինչև 89999999999 համարը:
- Ժամը 05:55:53 արտաքին գիծը զանգ է ուղարկում մուտքային միացում:փորձարկում»
- Զանգը ըստ սխեմայի մշակելիս մոդուլը «ղեկավարի զանգ», որում զանգը 16 վայրկյան է։ Սա հաճախորդի համար մշակված մոդուլ է:
- Մոդուլ»ղեկավարի զանգ«Զանգ է ուղարկում համարի համար պատասխանատու աշխատողին (հաճախորդին)»Կառավարիչ 1» և պատասխանի համար սպասում է 5 վայրկյան: Տնօրենը չպատասխանեց։
- Մոդուլ»ղեկավարի զանգ«Զանգ է ուղարկում խմբին»CORP մենեջերներ« Սրանք նույն ուղղության այլ մենեջերներ են (նստած նույն սենյակում) և սպասում են պատասխանի 11 վայրկյան:
- Խումբ »CORP մենեջերներ«Զանգահարում է աշխատակիցներին»Կառավարիչ 1, Կառավարիչ 2, Կառավարիչ 3«միաժամանակ 11 վայրկյան. Պատասխան չկա.
- Տնօրենի զանգն ավարտվում է։ Եվ միացումը զանգ է ուղարկում մոդուլին »Ընտրելով երթուղի 1c-ից« Նաև հաճախորդի համար գրված մոդուլ: Այստեղ զանգը մշակվել է 0 վայրկյան։
- Շղթան զանգ է ուղարկում ձայնային մենյու »Հիմնական լրացուցիչ հավաքումով« Հաճախորդն այնտեղ սպասել է 31 վայրկյան, լրացուցիչ հավաքում չի եղել։
- Սխեման զանգ է ուղարկում Խմբին «Քարտուղարներ», որտեղ հաճախորդը սպասել է 12 վայրկյան։
- Խմբում միաժամանակ կանչվում են 2 աշխատակիցներ»քարտուղար 1"Եւ"քարտուղար 2«Եվ 12 վայրկյան հետո աշխատակիցը պատասխանում է».քարտուղար 2« Զանգի պատասխանը կրկնօրինակվում է ծնողական զանգերի: Պարզվում է, որ խմբում նա պատասխանել է «քարտուղար 2«, երբ զանգահարելով շրջանը պատասխանեց «քարտուղար 2«Եվ արտաքին գծի զանգին պատասխանեց»քարտուղար 2.
Հենց յուրաքանչյուր գործողության և դրանց բնադրման մասին տեղեկատվության պահպանումն է, որ հնարավոր կլինի պարզապես հաշվետվություններ կազմել։ Ձայնային մենյուի հաշվետվությունը կօգնի ձեզ պարզել, թե որքանով է դա օգնում կամ խանգարում: Աշխատակիցների կողմից բաց թողնված զանգերի մասին հաշվետվություն կազմել՝ հաշվի առնելով, որ զանգը գաղտնալսվել է և հետևաբար չի համարվում բաց թողնված, և հաշվի առնելով, որ դա խմբակային զանգ է եղել, և ինչ-որ մեկը պատասխանել է ավելի վաղ, ինչը նշանակում է, որ զանգը նույնպես բաց չի թողնվել։
Նման տեղեկատվության պահպանումը թույլ կտա ձեզ վերցնել յուրաքանչյուր խումբ առանձին և որոշել, թե որքան արդյունավետ է այն աշխատում, և կազմել պատասխանված և բաց թողնված խմբերի գրաֆիկը ըստ ժամերի: Կարող եք նաև ստուգել, թե որքանով է ճշգրիտ կապը պատասխանատու մենեջերի հետ՝ վերլուծելով փոխանցումները կառավարչի հետ միանալուց հետո։
Կարող եք նաև բավականին անտիպ ուսումնասիրություններ կատարել, օրինակ՝ տվյալների բազայում չգտնվող համարները որքան հաճախ են հավաքում ճիշտ ընդլայնում կամ ելքային զանգերի քանի տոկոսն է փոխանցվում բջջային հեռախոսին:
Արդյունքը:
PBX-ը սպասարկելու համար մասնագետ չի պահանջվում, դա կարող է անել ամենասովորական ադմինիստրատորը՝ փորձված պրակտիկայում:
Փոփոխությունների համար լուրջ որակավորում ունեցող մասնագետներ պետք չեն, PHP-ի իմացությունը բավարար է, քանի որ Մոդուլներ արդեն գրվել են SIP արձանագրության, հերթի, աշխատողին կանչելու և այլոց համար: Կա փաթաթման դաս Աստղանիշ. Մոդուլ մշակելու համար ծրագրավորողը կարող է (և լավ իմաստով պետք է) կանչի պատրաստի մոդուլներ։ Եվ գիտելիք Աստղանիշ բոլորովին ավելորդ են, եթե հաճախորդը խնդրում է ավելացնել նոր զեկույցով էջ: Բայց պրակտիկան ցույց է տալիս, որ չնայած երրորդ կողմի ծրագրավորողները կարող են հաղթահարել, նրանք իրենց անապահով են զգում առանց փաստաթղթերի և մեկնաբանությունների նորմալ լուսաբանման, այնպես որ դեռ բարելավման տեղ կա:
Մոդուլները կարող են.
- ստեղծել զանգերի մշակման նոր հնարավորություններ,
- ավելացնել նոր բլոկներ վեբ ինտերֆեյսին,
- ժառանգել գոյություն ունեցող մոդուլներից որևէ մեկից, վերասահմանել գործառույթները և փոխարինել այն, կամ պարզապես լինել մի փոքր փոփոխված պատճեն,
- ավելացրեք ձեր կարգավորումները այլ մոդուլների կարգավորումների ձևանմուշին և շատ ավելին:
PBX-ի կարգավորումները API-ի միջոցով: Ինչպես նկարագրված է վերևում, բոլոր կարգավորումները պահվում են տվյալների բազայում և կարդացվում են զանգի պահին, այնպես որ կարող եք փոխել PBX-ի բոլոր կարգավորումները API-ի միջոցով: API-ն կանչելիս կոնֆիգուրացիան չի վերստեղծվում, և մոդուլները չեն վերագործարկվում, հետևաբար, կարևոր չէ, թե քանի կարգավորում և աշխատող ունեք: API հարցումները կատարվում են արագ և չեն արգելափակում միմյանց:
PBX-ը պահում է բոլոր հիմնական գործառնությունները զանգերի տեւողությամբ (սպասում/խոսակցություն), բնադրում և PBX տերմիններով (աշխատող, խումբ, արտաքին գիծ, ոչ ալիք, համար): Սա թույլ է տալիս ստեղծել տարբեր հաշվետվություններ կոնկրետ հաճախորդների համար, և աշխատանքի մեծ մասը օգտագործողի համար հարմար ինտերֆեյսի ստեղծումն է:
Թե ինչ կլինի հետո, ցույց կտա ժամանակը։ Դեռ շատ նրբերանգներ կան, որոնք պետք է վերամշակվեն, դեռ շատ ծրագրեր կան, բայց 3-րդ տարբերակի ստեղծումից մեկ տարի է անցել, և արդեն կարելի է ասել, որ գաղափարն աշխատում է։ 3-րդ տարբերակի հիմնական թերությունը ապարատային ռեսուրսներն են, բայց սովորաբար դա այն է, ինչի համար պետք է վճարեք զարգացման հեշտության համար:
Source: www.habr.com