🥇Անդամ՝ մեկ նախագծի պատմություն կամ ինչպես ես 7 տարի ստեղծեցի ԱՏՍ Asterisk և Php-ի հիման վրա

Հավանաբար, շատերիդ, ինչպես նաև ինձ մոտ, եղել է միտք անել ինչ-որ յուրահատուկ: Այս հոդվածում ես կպատմեմ տեխնիկական խնդիրների և լուծումների մասին, որոնց ես հանդիպեցի ԱԹՍ-ի մշակման ընթացքում: Հնարավոր է, սա ինչ-որ մեկին օգնի որոշվելու իր գաղափարի համար, իսկ մեկ другим անցել ավորված ճանապարհով, քանի որ ես էլ օգտագործել եմ նախապաշարների փորձը:

Գաղափարը և հիմնական պահանջները

Ամեն ինչ սկսվեց պարզաբար սիրուց դեպի Asterisk (կազմակերպման ծրագրերի հիմք), հեռախոսային ավտոմատացման և տեղադրումների FreePBX (այդ իսկ պատճառով Asterisk). Եթե ընկերության պահանջները ոչ մի առանձնահատուկ բան չեն պարունակել, ապա ամեն ինչ լավ է: Ընդհանուր տեղադրումը տևում էր մեկ օր, ընկերությունը ստանում էր կարգավորված ԱԹՍ, հարմար կարգավորիչ և հատվածական ուսուցում, ինչպես նաև աջակցություն ցանկության դեպքում: FreePBX Բայց ամենաընթերցվող խնդիրները անկանոն էին և այդ ժամանակ դեռևս այնքան հեքիաթային չէին:

Asterisk-ը կարող է շատ բան անել, բայց որպեսզի պահել աշխատանքային վիճակում բաժնի առցանց կարգավորումը, պետք էր ծախսել զգալիորեն ավելին ժամանակ: Այսպիսով, մի փոքր հարց կարող էր զբաղեցնել շատ ավելի ժամանակ, քան ողջ ԱԹՍ-ի տեղադրումը: Ժամանակը չէ, որ փոխելու կայքը երկար է, այլապես կայքի կառուցվածքային առանձնահատկության: Asterisk . Կառուցվածքի մոտեցումները և մեթոդները FreePBXնախագծվել էին php4-ի ժամանակ, իսկ այդ պահին արդեն գոյություն ուներ php5.6, որի վրա կարելի էր անել ավելի հեշտ և հարմար: FreePBX Ավելի ուշ տառատեսակները գնացին գրաֆիկական հեռախոսային սխեմաների տեսքով: Երբ այդպիսի բան փորձեցի կառուցել

, ինձ հասկացա, որ պետք է ծնկեն կարևոր փոխարինումներ և հեշտ կլիներ կառուցել ինչ-որ նոր: FreePBXՀիմնական պահանջները եղել են.

հեշտ կարգավորում, հասանելի նույնիսկ սկսնակ ադմինիստրատորին: Այդ ժամանակ ընկերություններին չի պահանջվում սպասարկել ԱԹՍ-ը մեր կողմից:

և հեշտ ընդլայնում, որպեսզի խնդիրները լուծվեն ընդունելի ժամանակներում:
հարմարավետ ինտեգրում ԱԹՍ-ին: ԱԹՍի մեջ
առկա չէր API կարգավորումներին փոփոխելու համար, այսինքն՝ օրինակ, հնարավոր չէ ստեղծել խմբեր կամ ձայնային մենյուներ արտաքին ծրագրից, միայն ինքն API-ն FreePBX opensource – ծրագրավորողների համար սա շատ կարևոր է, հաճախորդի պահանջներն իրականացնելու համար: Asterisk,
Աղջկա ավելի արագ զարգացումը նույնպես դա էր, որ ամբողջ ֆունկցիոնալությունը բաղկացած էր արտահայտություններից: Բոլոր արտահայտություններն ու իրավունքները պետք է ունեին ընդհանուր ծնողական դաս, որը նշանակում է՝ բոլոր հիմնական ֆունկցիաների անվանումները արդեն հայտնի են և արդեն կա բոլորն ըստ կանխադրվածների: Արտահայտությունները թույլ կտան արարել նշանակալի խոսքերի քանակության փաստարկներն ասոցացվող զանգվածների, որոնք կարելի է գտնել այդ ֆունկցիան ուսումնասիրելով և вложенная ֆունկցիաներով: Արտահայտություններով պարզ ավտոմատ լրացումը ցույց կտա բոլոր հատկությունները, իսկ առհասարակ համալրագրով խելահեղապես հեշտացնի կյանքը: Բացի այդ, ժառանգությունը և վերագործարկումը արդեն լուծում են բազմաթիվ խնդիրներ փոխառությունների հետ:

Անհրաժեշտ էր օգուտ ստանալ այն մասին, որ ֆունկցիոնալությունն ավելին էր, քան մոդուլների ձևափոխման մեջ: Բոլորը պետք է ունենային ընդհանուր ծնողական դաս, ինչը նշանակում էր, որ բոլոր հիմնական ֆունկցիաների անվանումները արդեն գիտակցված էին: FreePBX Արտահայտությունները թույլ կտան զգալիորեն կրճատել ելքային տվյալները ասոցացված զանգվածների միջոցով: Արտահայտությունների հնարավորությունը շատ ավելի աշխատանքային կյանք է դարձնում: Բացի այդ, ժառանգությունը և վերագործարկումը ավելացնում են մեծ թվով խնդիրներ հեշտացնում:

Հաջորդը, ինչ ուշացնում էր աշխատանքների ժամկետները և ինչից պետք է խուսափել՝ կրկնօրինակման պրոբլեմն էր։ Եթե գոյություն ունի մոդուլ, որը պատասխանատու է աշխատակցին զանգահարելու համար, ապա բոլոր մյուս մոդուլները, որոնք պետք է զանգը ուղարկեն աշխատակցին, պետք է օգտագործեն այն, այլ ոչ թե ստեղծեն իրենց սեփական կրկնօրինակները։ Այսպես, եթե ինչ-որ բան պետք է փոխվել, ապա փոխելու անհրաժեշտությունն առաջանում է միայն մեկ տեղում, և «այսը ինչպես է աշխատում» որոնումը պետք է անցկացվի մեկ տեղում, այլ ոչ թե ամբողջ նախագծի շրջանակներում։

Առաջին տարբերակը և առաջին սխալները

Առաջին պրոտոտիպը պատրաստ էր արդեն մեկ տարի անց։ Հասարակ ATS-ը, ինչպես նախատեսվել էր, մոդուլային էր, և մոդուլները կարող էին ոչ միայն ավելացնել նոր գործառույթներ զանգերի մշակման համար, այլ նաև փոխել ինքնության վեբ ինտերֆեյսը։

Այո, զանգերի պլանի կառուցման գաղափարը նման սխեմայի տեսքով իմը չէ, բայց այն շատ հարմար է, և ես նաև նույնը արեցի համար Asterisk.

Մոդուլ գրելու միջոցով ծրագրավորողները արդեն կարող էին:

զանգը մշակելու համար ստեղծել իրենց սեփական գործառույթները, որոնք կարելի էր տեղադրել սխեմայում, ինչպես նաև ձախի էլեմենտների մեջ։
ստեղծել իրենց սեփական էջերը վեբ ինտերֆեյսի համար և ավելացնել իրենց մայրաքաղաքները առկա էջերին (եթե էջի մշակողը դա ենթադրում էր)։
ավելացնել իրենց կարգավորումները հիմնական կարգավորումների նշկին կամ ստեղծել սեփական կարգավորումների նշունը։
ծրագրավորողը կարող է ժառանգել առկա մոդուլից, փոփոխել որոշ գործառույթ և գրանցել նոր անունով կամ փոխարինել առ Origami մոդուլը։

Օրինակ, այսպես կարելի է ստեղծել սեփական ձայնային մենյուն։

......
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։ Ճափտեց, որ մարդկանց գաղափարը схемի վերաբերյալ գոհացրեց։ Մեկ այլ շատ տարբերակներ կային նախագծման հեշտացնելու համար, բայց այդ պահին արդեն մի մասը անելիս դյուրացվել էր։

Հիասթափեցրեց ATS-ի կարգավորումների փոփոխության API-ն՝ ստացվեց այն, ինչը ցանկանում էի։ Ես վերցրի այն սկզբունքը, ինչ էլ FreePBX՝ սեղմելով Apply կոճակը վերաբերում է ամբողջ կարգավորումը և կրկին վերսկսում է մոդուլները։

Այսպես է դա տեսնում։

*Զանգերի պլանը՝ կանոն (ալգորիթմ), որով մշակվում է զանգը։

Բայց այս տարբերակի դեպքում հնարավոր չէ գրել նորմալ API՝ ATS-ի կարգավորումները փոփոխելու համար։ Նախ, փոփոխությունների կիրառման գործողությունը Asterisk ძალიან երկար է և ռեսուրսների պահանջում։
Երկրորդ, չի կարելի միաժամանակ կանչել երկու գործառույթ, քանի որ երկուսն էլ ստեղծելու են կառուցվածքը։
Երրորդ, կիրառվում են բոլոր կարգավորումները, այդ թվում՝ ադմինիստրատորի կողմից կատարվածները։

Այս տարբերակում, ինչպես նաև Askozia, հնարավոր էր գեներացնել միայն փոփոխված մոդուլների կոնֆիգուրացիան և վերագործարկել միայն անհրաժեշտ մոդուլները, բայց դա միայն կես լուծում էր: Պիտի փոխվեր մոտեցումը:

Երկրորդ տարբերակը. Այրուձը քաշեց պոչը:

Արտադրանքի խնդիրը լուծելու գաղափարը չլինել փոխհաստատման և զանգերի պլանը ստեղծելու համար, այլ պահպանել տեղեկատվությունը տվյալների մեջ և կարդալ տվյալներից անմիջապես զանգի ընթացքին: Asterisk, արդեն գիտեր, թե ինչպես կարդալ կոնֆիգուրացիաները տվյալներից, բավական էր փոխել արժեքը տվյալներում, և հաջորդ զանգը արդեն վերամշակվելու է հաշվի առնելով փոփոխությունները, իսկ զանգի պլանի պարամետրերը լավ էին աշխատում ֆունկցիայի միջոցով: Asterisk REALTIME_HASH Ի վերջո, անգամ հարկավոր չէր վերագործարկել.

համապատասխան հարմարանքներում, և բոլոր հարմարանքները անմիջապես սկսեցին կիրառվել Asterisk Զանգերի պլանի միակ փոփոխությունները ներմուծված համարների կամ Asterisk.

hints . Բայց դրանք փոքր կետային փոփոխություններ էին: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) ...

Ավելացնել կամ փոխել տողը զանգերի պլանում հեշտությամբ կարելի է միջոցով

Ami (կառավարման ինտերֆեյս) և պահելու ամբողջ զանգերի պլան պետք չէ: AsteriskԱյդպիսով լուծվեց API-ի հետ կոնֆիգուրացիայի խնդիրը: Կարելի էր նույնիսկ ուղիղ մտնել տվյալները և ավելացնել նոր խումբ կամ փոխել, օրինակ, զանգի տևողությունը “dialtime” դաշտում խմբի համար, և հաջորդ զանգը արդեն կլինի նշված ժամանակահատվածում ( Սա չէ խորհուրդ գործողություն, քանի որ որոշ API գործողությունների համար անհրաժեշտ են

զանգեր): (կառավարման ինտերֆեյս) Առաջին դժվար ինտեգրումները կրկին բերեցին առաջին հպարտություն և հուսալքություն: Հրաշալի էր, որ դա գործում է: Դրույթային տվյալները դարձան կենսական կարևոր կապ, աճեց կախվածություն սկավառակից, ռիսկերն ավելացան, բայց ամեն ինչը գործում էր կայուն և առանց խնդիրների: Եվ ինչպիսի կարևորություն ունի այն, որ ամեն ինչը, ինչը կարելի էր անել կայք-համակարգում, կարելի էր անել նաև API-ի միջոցով և դրանով էլ օգտագործվեցին նույն մեթոդները: Ընդհանուր առմամբ, կենցաղային կայք-համակարգը ազատվեց «կիրառել կարգավորումները ATC-ին» կոճակից, որի մասին ադմինիստրատորները հաճախ մոռացվում են:

Հուսալքությունը զարգացնելու բարդությանը։ Իսկ հետագայում ծրագրավորման առաջին տարբերակով php-ն գեներացնում է զանգի պլան

և դա տեսք ունի լրիվ անկարևոր, բացի այդ, ինքը լեզուն: Asterisk զանգի պլանի համար չափազանց պարզ է: Asterisk Այսպես էր դա տեսք ունեցել:

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

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

Երկրորդ տարբերակում բանալի պլանը դարձավ աստիճանական, մեջը մտավ բոլոր հնարավոր տարբերակները մշակելու համար, կախված պարամետրերից, և նրա չափը զգալիորեն մեծացավ: Դա շատ երկարաձգեց մշակման ժամանակը, և ինքնորոշման գաղափարը, որ আবার պետք էր միջամտել բանալի պլանին, հիասթափեցնող էր:

Երրորդ տարբերակը

Problema řešení myšlenka byla generovat Asterisk դուքի պլանը php-ով, այլ օգտագործել FastAGI և բոլոր մշակման կանոնները արդեն գրել php-ով: FastAGI թույլ է տալիս Asterisk, հեռախոսազանգի մշակման համար, միացնել սոկետին: Այնտեղից հրամաններ ստանալ և արդյունքները ուղարկել: Այսպիսով, բանալի պլանի տրամաբանությունը արդեն գտնվում է սահմաններից դուրս Asterisk և կարող է լինել գրություն ցանկացած լեզվով, իմ դեպքում php-ով:

Այստեղ շատ փորձեր և սխալներ եղան: Հիմնական խնդիրը այն էր, որ ինձ արդեն ուներ շատ դասեր/ֆայլեր: Օբյեկտների ստեղծմանը, սկսելու և փոխադարձ գրանցմանը նրանց անդրադառնալու համար պահանջվում էր մոտ 1,5 վայրկյան և այս ուշացումը յուրաքանչյուր զանգի համար այն չէր, ինչ կարող էրIgnoring:

Սկնդիրն էր, որ դա պետք էր միայն 1 անգամ և հետևաբար լուծման փնտրտուքները սկսվեցին php-ով ծառայություն գրելու միջոցով օգտագործելով Pthreads. Սպասելով շաբաթվա փորձարկումներից, այդ տարբերակը թող մնաց հանգստի պատճառով այս երկարաձգման աշխատանքների նրբություններից: Asynchronous ծրագրավորումից php-ից շաբաթների փորձարկումից հրաժարվելու համար պետք էր ինչ-որ պարզ, բոլոր նորեկներին հայտնի, ըստ այդմ, շատ php լրացումներSynchronised:

Լուծումը սեփական բազմաբնույթ ծառայություն էր ‘սի’ -ում, որը կոմպիլացնում էր PHPLIB. Այն բեռնում է բոլոր php ֆայլերը ATC-ից, սպասում է, երբ բոլոր մոդուլները սկսվեն, մեկ-մյուսի մեջ կհամընկնեն և երբ ամեն ինչ պատրաստ է – կրճատված է: Ներդիրի հարցը FastAGI ստեղծում է նավ, որի մեջ հիշատակվում է կեղևին մաքրից բոլոր դասերի և տվյալների և հարցումն ուղարկվում է php գործառույթ:

Այսպիսով, ժամանակը հեռախոսազանգի մեր ծառայությանը ուղարկելուց մինչև առաջին հրամանը Asterisk կրճատվեց 1,5 վայրկյանից 0,05 վայրկյանի, և այդ ժամանակը թույլ է կախված լինելու նախագիծերի չափից:

Ի վերջո, ժամանակը բանալի պլանի մշակման համար զգալիորեն կրճատվել է, և կարող եմ դա գնահատել, քանի որ ես ստիպված էի վերագրել բոլոր մոդուլների բանալի պլանը php-ով: Նախ, php-ով արդեն պետք էին գրել մեթոդներ տվյալների բազայից օբյեկտ ստանալու համար, դրանք անհրաժեշտ էին վեբ-հայեցքի ցուցադրության, իսկ երկրորդը, և սա գլխավորն է – վերջապես հնարավորություն ունեմ հարմարավետ աշխատանքի համար թվերի տողերի ու տվյալների բազաների դասերի մեծ քանակություն плюс բազմաթիվ php լրացումներ:

Բանալի պլանի մշակման համար մոդուլի դասում պետք է իրականացնել գործառույթ dialplanDynamicCall և փաստարկը pbxCallRequest կպահի օբյեկտը փոխադարձ կապի համար Asterisk.

Կողմում է ծառայության նրա շրջապատում, որը թույլ է տալիս բանալի պլանի լուծման հսկայական նայելու վրա (php-ում կա xdebug և մեր ծառայությունում այն աշխատում է), կարող ենք շարժվել քայլ առ քայլ դիտելով փոփոխականների արժեքները:

Հեռախոսազանգերի տվյալները

Բոլոր վերլուծությունների և հաշվետվությունների համար անհրաժեշտ են ճիշտ հավաքված տվյալներ, և այս ԱՏС բլոկն անցել է բազմաթիվ փորձարկումներ առաջինից երրորդ տարբերակին։ Հաճախ տվյալները զանգերի մասին ներկայացվում են որպես աղյուսակ։ Մի զանգ = մեկ գրառում. ով զանգել է, ով պատասխանել է, որքան ժամանակ են խոսել։ Ավելի հետաքրքիր տարբերակներում կա նաև լրացուցիչ աղյուսակ, թե որ ԱՏՍ աշխատակիցները կանչել են զանգի ընթացքում։ Սակայն սա փակել է միայն պահանջների մի մասը։

Ավերէն պահանջները հետևյալն էին՝

պահպանել ոչ միայն ում զանգել է ԱՏՍ-ը, այլեւ ով է պատասխանել, քանի որ կան զեղչեր, և զանգերի վերլուծության համար դա պետք է հաշվի առնել,
մանրամասնությունները աշխատակցին միանալու պահի։ Ընթացքում FreePBX և մի շարք այլ ԱՏՍ-ներում, զանգը համարվում է պատասխանված, երբ АՏС-ն վերցնում է հեռախոսը։ Սակայն ձայնային մենյուի համար արդեն պետք է վերցնել հեռախոսը, ուստի բոլոր զանգերը դառնում են պատասխանված, և սպասման ժամանակը դառնում է 0-1 վայրկյան։ Այդ պատճառով որոշվել է պահպանել ոչ միայն պատասխանին հասնելու ժամանակը, այլ նաև միացման ժամանակը հիմնական մոդուլներին (մոդուլը ինքնագիր տեղադրում է այս նշանը։ Այժմ սա «Աշխատակից», «Գործողություն»),
բարդ քարտեզի համար, երբ զանգը շրջում է տարբեր խմբերի միջև, անհրաժեշտ էր, որ յուրաքանչյուրը ուսումնասիրել հնարավորինս առանձին։

Լավագույն տարբերակը այն էր, երբ ԱՏՍ մոդուլները ինքնուրույն ուղարկում են զանգի մասին տեղեկատվություն և արդյունքում պահել տեղեկությունը ծառի տեսքով։

Այսպես է դա տեսվում՝

Այն տրված է, որ ընդհանուր տեղեկատվություն զանգի մասին (ինչպես բոլորի մոտ՝ ոչինչ հատուկ)։

Զանգ է ստացվել արտաքին գծով «Թեսթի համար» 05:55:52-ին հեռախոսահամարով 89295671458 89999999999 հեռախոսահամարին, արդյունքում պատասխանեց աշխատակից «Վերահսկիչ2» հեռախոսահամարով 104։ հաճախորդը սպասել է 60 վայրկյան և խոսել է 36 վայրկյան։
Աշխատակից «Վերահսկիչ2» զանգում է հեռախոսահամար 112 և նրան պատասխանում է աշխատակից «Վարձակալ1» 8 վայրկյան հետո։ Խոսում են 14 վայրկյան։
Հաճախորդը փոխանցվում է Աշխատակից «վարձակալ1» որտեղ նրանք շարունակում են խոսել ևս 13 վայրկյան։

Բայց սա սառույցի գլխավերավորությունն է, յուրաքանչյուր գրառման համար կարելի է ստանալ զանգի մանրամասն ընթացքը ԱՏՍ-ում։

Բոլոր տեղեկությունները ներկայացվում են զանգերի ընդլայնված տեսքով՝

Զանգ է ստացվել արտաքին գծով «Թեսթի համար» 05:55:52-ին հեռախոսահամարով 89295671458 89999999999 հեռախոսահամարին։
05:55:53-ին արտաքին գիծը ուղարկում է զանգը Մուտքային սխեմայի «test»
Զանգի տվյալները «ստրատեգիա մենեջերի», որում զանգը տեղակայված է 16 վայրկյան։ Սա մշակված մոդուլ է ըստ հաճախորդի։
Մոդուլ «ստրատեգիա մենեջերի» ուղարկում է զանգը պատասխանատու համար (հաճախորդի) աշխատակից «Վարձակալ1» և սպասում է 5 վայրկյան։ Մենեջեր չի պատասխանել։
Մոդուլ «ստրատեգիա մենեջերի» ուղարկում է զանգը «Մենեջերներ ԿՈՐՊ» խմբին։ Սա այլ մենեջերներ են նույն ուղղությամբ (նրանք նստած են նույն սենյակում) և սպասում են 11 վայրկյան։
«Մենեջերներ ԿՈՐՊ» խումբը կանչում է աշխատակիցներին «Վարձակալ1, Մենեջեր2, Մենեջեր3» միաժամանակ 11 վայրկյան։ Պատասխան չկա։
Մենեջերի զանգը ավարտվում է։ Զանգը ուղարկվում է "1С- ից ճանապարհի ընտրությունը"։ Դա նույնպես հաճախորդի համար գրանցված մոդուլ է։ Այստեղ զանգը մշակվել է 0 վայրկյան։
Սქեման ուղարկում է զանգը ձայնային մենյու "Կողմնակի համար"։ Հաճախորդն այնտեղ սպասել է 31 վայրկյան, նոր հավաքման չի եղել։
Սქեման զանգը ուղարկում է "Քարտուղարներ" խմբին, որտեղ հաճախորդն սպասել է 12 վայրկյան։
Խմբում միաժամանակ կանչվում են 2 աշխատակից "Քարտուղար1» և «Վերահսկիչ2", և 12 վայրկյան անց պատասխանում է աշխատակիցը "Վերահսկիչ2"։ Զանգի պատասխանը կրկնում է ծնողական զանգերում։ Ստացվում է այնպես, որ խմբում պատասխանեց "Վերահսկիչ2", схемան կանչեց "Վերահսկիչ2", և արտաքին գիծով պատասխանեց "Վերահսկիչ2».

Տեղեկությունների պահպանման յուրաքանչյուր գործընթացի և նրանց նվիրվածության մասին թույլ կտա հեշտորեն կազմել հաշվետվություններ։ Ձայնային մենյուի հաշվետվությունը կօգնի պարզել, արդյոք այն օգնում է կամ խանգարում է։ Կարող եք կազմել աշխատակիցների զանգերի բաց թողած հաշվետու՝ հաշվի առնելով, որ զանգը վերցվել է և, հետևաբար, չհամարվում է բաց թողած, և հաշվի առնելով, որ դա խմբային զանգ է, և որևէ ուրիշը վերցրեց ավելի վաղ, ինչը ևս դա չի թողնի բաց։

Այս տեղեկատվության պահպանումը թույլ կտա առանձնապես ուսումնասիրել յուրաքանչյուր խմբի և ճշտել, թե որքան արդյունավետ է այն աշխատում, կազմել պատասխանած և բաց թողած զանգերի գրաֆիկ ըստ ժամերի։ Ավելին, հնարավոր է ստուգել որքանով հաջողվում է կապը պատասխանատու մենեջերի հետ, վերլուծելով փոխարկումները մենեջերի հետ կապվելուց հետո։

Այնպես որ, կարելի է իրականացնել բավականին անսովոր հետազոտություններ, օրինակ, որքան հաճախ են այն հեռախոսահամարները, որոնք չկան տվյալների բազայում, հավաքում ճիշտ հավելել, կամ որքան տոկոս է ելքային զանգերի վերականգնումը մոբիլային հեռախոսներին։

Այսպիսով, ի վերջո:

ԱՏՍ-ի սպասարկման համար մասնագետներ չեն պահանջվում, դա կարող է անել ամենագլխավոր ադմինիստրատորը՝ գործնական փորձով փաստված։

Աշխատանքների համար անհրաժեշտ չեն բարձրակարգ մասնագետներ, բավարար են php գիտելիքները, քանի որ արդեն գրանցվել են մոդուլներ էֆ- պրոտոկոլի համար, հերթերի համար, աշխատակցի զանգելու համար և այլն։ Ինքնին կա կոդավորման դաս " Asterisk"։ Ծրագրային մշակողները մոդուլի մշակման համար կարող են (և պետք է) վարակվել արդեն պատրաստված մոդուլներից։ Եվ գիտելիքներ " Asterisk բոլորովին էլ անհրաժեշտ չեն, եթե հաճախորդը խնդրում է ավելացնել էջ ինչ-որ նոր հաշվետվությամբ։ Բայց պրակտիկան ցույց է տալիս, որ արտաքին ծրագրավորողները, թեև կարողանում են, բայց առանց փաստաթղթավորման և ծանոթագրությունների կանոնավոր ծածկույթով՝ հարմարավետ չեն զգում, այնպես որ, դեռ կան տեղեր, որտեղ կարող ենք առաջ ընթանալ։

Մոդուլները կարող են։

նոր հնարավորություն ստեղծել զանգը մշակման մասին,
ավելացնել նոր բլոկներ վեբ-հետազոտական թղթում,
պարունակում են որևէ գոյություն ունեցող մոդուլներից, վերագրել ֆունկցիաներ և փոխարինել կամ պարզապես լինել մի փոքր փոփոխված көшірոց,
ավելացնել իրենց կարգավորումները մյուս մոդուլների կարգավորումների ձևի մեջ և շատ այլ բաներ։

ԱՏՍ կարգավորումները API-ի միջոցով: Ինչպես նշված է վերևում, բոլոր կարգավորումները պահվում են տվյալներիբազայում և ընթերցվում են զանգի պահին, այդ պատճառով API-ի միջոցով կարող եք փոխել ԱՏՍ-ի բոլոր կարգավորումները: API կանչի ժամանակ կոնֆիգուրացիան նորից չի ստեղծվում և մոդուլները չեն վերագործարկվում, հետևաբար, կարևոր չէ, թե որքան շատ կարգավորումներ և աշխատակիցներ ունեք: API հարցումները կատարվում են արագ և չխանգարում են իրար:

ԱՏՍ-ը պահում է զանգերի հետ կապված բոլոր հիմնական գործողությունները, ներառյալ տևականությունները (սպասման/զրույցի), ներգրավվածությունները և ԱՏՍ-ի տերմիններով (աշխատող, խումբ, արտաքին գիծ, ոչ թե ալիք, թիվ): Սա թույլ է տալիս կազմել տարբեր հաշվետվություններ կոնկրետ հաճախորդների համար, և աշխատանքային հիմնական մասը՝ հարմար ինտերֆեյսի ստեղծումն է:

Ինչ կլինի հետագայում ցույց կտա ժամանակը: Պիտի վերանայվեն դեռ շատ մանրամասներ, դեռ շատ ծրագրեր կան, բայց երրորդ տարբերակի ստեղծումից մեկ տարի է անցել, և արդեն կարելի է ասել, որ գաղափարը գործում է: Երրորդ տարբերակի հիմնական բացասական կողմը՝ սարքային ռեսուրսներն են, բայց մշակումների հարմարեցման համար սովորաբար հենց这样 էլ պետք է վճարել:

Ընտանիք: habr.com