Нэг төслийн түүх эсвэл би Asterisk болон Php дээр суурилсан PBX бүтээхдээ 7 жил зарцуулсан

Над шиг та нарын олонх нь өвөрмөц зүйл хийх санаатай байсан нь лавтай. Энэ нийтлэлд би PBX-ийг хөгжүүлэхэд тулгарч байсан техникийн асуудал, шийдлүүдийг тайлбарлах болно. Магадгүй энэ нь хэн нэгэнд өөрийн санаагаа шийдэхэд тусалж, хэн нэгэнд сайн гишгэсэн замаар явахад тусална, учир нь би ч гэсэн анхдагчдын туршлагаас ашиг тустай байсан.

Санаа ба гол шаардлага

Тэгээд энэ бүхэн зүгээр л хайраас эхэлсэн Астэриск (харилцаа холбооны хэрэглээг бий болгох хүрээ), телефон утас, суурилуулалтыг автоматжуулах ҮнэгүйPBX (вэб интерфэйс Астэриск). Хэрэв компанийн хэрэгцээ тодорхойгүй, боломжийн хэмжээнд таарч байсан бол ҮнэгүйPBX - бүх зүйл гайхалтай. Суулгацыг бүхэлд нь XNUMX цагийн дотор хийсэн бөгөөд компани нь тохируулсан PBX, хэрэглэгчдэд ээлтэй интерфэйс, богино хэмжээний сургалт, хэрэв хүсвэл дэмжлэг авсан.

Гэхдээ хамгийн сонирхолтой даалгаврууд нь стандарт бус байсан бөгөөд энэ нь тийм ч гайхалтай биш байв. Астэриск маш их зүйлийг хийж чадна, гэхдээ вэб интерфэйсийг хэвийн байлгахын тулд хэд дахин илүү цаг зарцуулах шаардлагатай болсон. Тиймээс жижиг нарийн ширийн зүйл нь PBX-ийн үлдсэн хэсгийг суулгахаас хамаагүй удаан хугацаа шаардагдах болно. Гол нь вэб интерфэйс бичихэд удаан хугацаа шаардагдахгүй, харин гол нь архитектурын онцлогт байгаа юм. ҮнэгүйPBX. Архитектурын арга барил, арга барил ҮнэгүйPBX php4-ийн үед тавигдсан бөгөөд тэр үед бүх зүйлийг илүү хялбар, илүү хялбар болгох боломжтой php5.6 аль хэдийн байсан.

Сүүлчийн сүрэл бол диаграм хэлбэрээр график диаграммууд байв. Би ийм зүйл барих гэж оролдсон үед ҮнэгүйPBX, Би үүнийг нэлээд дахин бичих шаардлагатай болж, шинэ зүйл бүтээхэд хялбар байх болно гэдгийг ойлгосон.

Гол шаардлага нь:

• Энгийн тохиргоо, шинэхэн администратор хүртэл хялбархан ашиглах боломжтой. Тиймээс компаниуд манай талаас PBX засвар үйлчилгээ шаарддаггүй.
• даалгавруудыг хангалттай хугацаанд шийдвэрлэхийн тулд хялбархан өөрчлөх,
• PBX-тэй нэгтгэх хялбар байдал. У ҮнэгүйPBX Тохиргоог өөрчлөх API байхгүй байсан, өөрөөр хэлбэл. Жишээлбэл, та гуравдагч талын програмаас бүлэг эсвэл дуут цэс үүсгэх боломжгүй, зөвхөн API өөрөө Астэриск,
• нээлттэй эх сурвалж - програмистуудын хувьд энэ нь үйлчлүүлэгчийн хувьд өөрчлөлт хийхэд маш чухал юм.

Илүү хурдан хөгжүүлэх санаа нь бүх функцийг объект хэлбэрээр модулиудаас бүрдэх явдал байв. Бүх объектууд нийтлэг эцэг эх ангитай байх ёстой бөгөөд энэ нь бүх үндсэн функцүүдийн нэр аль хэдийн мэдэгдэж байгаа тул анхдагч хэрэгжүүлэлтүүд аль хэдийн байгаа гэсэн үг юм. Объектууд нь стринг товчлуурууд бүхий ассоциатив массив хэлбэрийн аргументуудын тоог эрс багасгах боломжийг танд олгоно. ҮнэгүйPBX Энэ нь функц болон үүрлэсэн функцуудыг бүхэлд нь шалгаж үзэх замаар боломжтой байсан. Объектуудын хувьд улиг болсон автомат бөглөх нь бүх шинж чанарыг харуулах бөгөөд ерөнхийдөө амьдралыг олон дахин хялбаршуулах болно. Дээрээс нь өв залгамжлал, дахин тодорхойлолт нь өөрчлөлтийн олон асуудлыг аль хэдийн шийддэг.

Дахин боловсруулах хугацааг удаашруулж, зайлсхийх нь зүйтэй дараагийн зүйл бол давхардал байв. Хэрэв ажилтан руу залгах үүрэгтэй модуль байгаа бол ажилтан руу дуудлага илгээх шаардлагатай бусад бүх модулиуд үүнийг ашиглах ёстой бөгөөд өөрсдийн хуулбарыг үүсгэхгүй байх ёстой. Тиймээс, хэрэв та ямар нэг зүйлийг өөрчлөх шаардлагатай бол зөвхөн нэг газар өөрчлөх шаардлагатай бөгөөд "энэ нь хэрхэн ажилладаг вэ" гэсэн хайлтыг нэг дороос хийх ёстой бөгөөд төслийн туршид хайх хэрэггүй.

Эхний хувилбар ба анхны алдаанууд

Эхний загвар нь жилийн дотор бэлэн болсон. Төлөвлөсний дагуу 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__); //Подменить существующий модуль

Эхний нарийн төвөгтэй хэрэгжилт нь анхны бахархал, анхны урам хугарал авчирсан. Энэ нь ажиллаж байгаад би аль хэдийн үндсэн шинж чанаруудыг хуулбарлаж чадсандаа баяртай байсан ҮнэгүйPBX. Уг схемийн санаа хүмүүст таалагдсанд би баяртай байсан. Хөгжлийг хялбарчлах олон сонголт байсаар байсан ч тэр үед зарим ажлуудыг аль хэдийн хөнгөвчилж байсан.

PBX-ийн тохиргоог өөрчлөх API нь сэтгэл дундуур байсан - үр дүн нь бидний хүссэнээр огтхон ч байгаагүй. Би өмнөхтэй ижил зарчмыг баримталсан ҮнэгүйPBX, Apply товчийг дарснаар бүх тохиргоог дахин үүсгэж, модулиудыг дахин эхлүүлнэ.

Энэ нь иймэрхүү харагдаж байна:

*Dialplan нь дуудлага боловсруулах дүрэм (алгоритм) юм.

Гэхдээ энэ сонголтоор PBX тохиргоог өөрчлөх ердийн API бичих боломжгүй юм. Нэгдүгээрт, өөрчлөлт оруулах үйл ажиллагаа Астэриск хэтэрхий урт бөгөөд нөөц их шаарддаг.
Хоёрдугаарт, та хоёр функцийг нэгэн зэрэг дуудаж болохгүй, учир нь хоёулаа тохиргоог бий болгоно.
Гуравдугаарт, энэ нь администраторын хийсэн тохиргоог оруулаад бүх тохиргоонд хамаарна.

Энэ хувилбарт байгаа шиг Аскозия, зөвхөн өөрчлөгдсөн модулиудын тохиргоог үүсгэж, зөвхөн шаардлагатай модулиудыг дахин эхлүүлэх боломжтой байсан ч эдгээр нь бүгд хагас хэмжүүр юм. Арга барилаа өөрчлөх шаардлагатай байсан.

Хоёр дахь хувилбар. Хамар сүүл нь гацсан

Асуудлыг шийдэх санаа нь тохиргоо болон залгах төлөвлөгөөг дахин үүсгэхгүй байх явдал байв Астэриск, гэхдээ мэдээллийн санд мэдээллийг хадгалж, дуудлагыг боловсруулах явцад мэдээллийн сангаас шууд уншина. Астэриск Мэдээллийн сангаас тохиргоог хэрхэн уншихыг би аль хэдийн мэдэж байсан, мэдээллийн сан дахь утгыг өөрчлөхөд л дараагийн дуудлагыг өөрчлөлтийг харгалзан үзэх болно, функц нь dialplan параметрүүдийг уншихад төгс төгөлдөр байсан. 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-д тохиргоо хийх" товчлуураас салсан.

Хөгжил улам төвөгтэй болсонд сэтгэл дундуур байсан. Эхний хувилбараас хойш РНР хэл нь тухайн хэлээр залгах төлөвлөгөөг үүсгэсэн Астэриск мөн энэ нь бүрэн унших боломжгүй харагдаж байна, дээр нь хэл нь өөрөө Астэриск залгах төлөвлөгөө бичихийн тулд энэ нь маш энгийн зүйл юм.

Энэ нь ямар харагдаж байсан:

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

Хоёрдахь хувилбарт залгах төлөвлөгөө нь бүх нийтийнх болж, параметрүүдээс хамааран боловсруулах бүх боломжит хувилбаруудыг багтаасан бөгөөд хэмжээ нь мэдэгдэхүйц нэмэгдсэн. Энэ бүхэн нь хөгжлийн хугацааг ихээхэн удаашруулж, дахин нэг удаа залгах төлөвлөгөөнд хөндлөнгөөс оролцох шаардлагатай байна гэсэн бодол намайг гунигтай болгосон.

Гурав дахь хувилбар

Асуудлыг шийдэх санаа нь үүсгэх биш байсан Астэриск php-ээс залгах ба ашиглах FastAGI PHP дээр боловсруулах бүх дүрмийг өөрөө бичнэ. FastAGI Энэ нь олгодог Астэриск, дуудлагыг боловсруулахын тулд залгуурт холбоно уу. Тэндээс тушаал хүлээн авч үр дүнг илгээнэ үү. Тиймээс залгах төлөвлөгөөний логик нь аль хэдийн хил хязгаараас гадуур байна Астэриск PHP дээр миний хувьд ямар ч хэлээр бичиж болно.

Туршилт, алдаа маш их байсан. Гол асуудал нь надад маш олон анги/файлтай байсан. Объект үүсгэх, тэдгээрийг эхлүүлэх, бие биенээ бүртгэхэд 1,5 секунд зарцуулсан бөгөөд дуудлага бүрт энэ удаашрал нь үл тоомсорлож болохгүй зүйл биш юм.

Эхлүүлэх нь зөвхөн нэг удаа хийгдсэн байх ёстой байсан тул шийдлийг хайх нь php ашиглан үйлчилгээг бичихээс эхэлсэн Илтгэлүүд. Долоо хоногийн турш туршилт хийсний дараа энэ өргөтгөл хэрхэн ажилладаг талаар нарийн төвөгтэй байдлаас болж энэ сонголтыг зогсоосон. Сарын турш туршилт хийсний дараа би PHP дээр асинхрон програмчлалыг орхих шаардлагатай болсон; надад PHP-д анхлан суралцагчдад танил болсон энгийн зүйл хэрэгтэй байсан бөгөөд PHP-д зориулсан олон өргөтгөлүүд синхрон байдаг.

Үүний шийдэл нь C хэл дээрх бидний олон урсгалт үйлчилгээ байсан бөгөөд үүнийг эмхэтгэсэн PHPLIB. Энэ нь бүх ATS php файлуудыг ачаалж, бүх модулиудыг эхлүүлэхийг хүлээж, бие биедээ дахин залгалт нэмж, бүх зүйл бэлэн болсон үед кэш хийдэг. -аас лавлах үед FastAGI урсгал үүсгэгдэж, бүх ангиудын кэшээс хуулбар, өгөгдлүүдийг хуулбарлаж, хүсэлтийг php функц руу шилжүүлнэ.

Энэхүү шийдлийн тусламжтайгаар манай үйлчилгээ рүү дуудлага илгээхээс эхлээд эхний команд хүртэлх хугацаа Астэриск 1,5 секундээс 0,05 секунд хүртэл буурсан бөгөөд энэ хугацаа нь төслийн хэмжээнээс бага зэрэг хамаарна.

Үүний үр дүнд dialplan боловсруулах цаг ихээхэн багассан бөгөөд би PHP-ийн бүх модулиудын залгах төлөвлөгөөг бүхэлд нь дахин бичих шаардлагатай болсон тул үүнийг талархаж байна. Нэгдүгээрт, өгөгдлийн сангаас объект авахын тулд аргуудыг аль хэдийн php дээр бичсэн байх ёстой; тэдгээрийг вэб интерфэйс дээр харуулахад шаардлагатай байсан, хоёрдугаарт, энэ нь хамгийн гол зүйл бол тоо, массив бүхий мөрүүдтэй хялбар ажиллах боломжтой юм. мэдээллийн сан болон олон PHP өргөтгөлүүдтэй.

Модулийн ангид залгах төлөвлөгөөг боловсруулахын тулд та функцийг хэрэгжүүлэх хэрэгтэй dialplanDynamicCall болон маргаан pbxCallRequest харилцах объектыг агуулна Астэриск.

Нэмж дурдахад dialplan-ыг дибаг хийх боломжтой болсон (php нь xdebug-тэй бөгөөд энэ нь манай үйлчилгээнд ажилладаг) хувьсагчийн утгыг харах замаар алхам алхмаар хөдөлж болно.

Дуудлагын өгөгдөл

Аливаа аналитик болон тайланд зөв цуглуулсан өгөгдлийг шаарддаг бөгөөд энэ PBX блок нь эхний хувилбараас гурав дахь хувилбар хүртэл маш олон туршилт, алдааг туулсан. Ихэнхдээ дуудлагын өгөгдөл нь шинж тэмдэг болдог. Нэг дуудлага = нэг бичлэг: хэн залгасан, хэн хариулсан, хэр удаан ярьсан. Илүү сонирхолтой сонголтуудад дуудлагын үеэр ямар PBX ажилтан дуудагдсаныг харуулсан нэмэлт тэмдэг байдаг. Гэхдээ энэ бүхэн хэрэгцээний зөвхөн нэг хэсгийг л хамардаг.

Эхний шаардлага нь:

• Зөвхөн PBX хэн дуудсаныг төдийгүй хэн хариулсныг ч хэмнэдэг тасалдалт байдаг бөгөөд дуудлагад дүн шинжилгээ хийхдээ үүнийг анхаарч үзэх шаардлагатай.
• ажилтантай холбогдохоос өмнөх хугацаа. онд ҮнэгүйPBX болон бусад зарим PBX-ууд утсаа авмагц дуудлагад хариулсан гэж үзнэ. Гэхдээ дуут цэсний хувьд та утсаа авах шаардлагатай байгаа тул бүх дуудлагад хариу өгөх бөгөөд хариу хүлээх хугацаа 0-1 секунд болно. Тиймээс зөвхөн хариу өгөхөөс өмнө төдийгүй гол модулиудтай холбогдохын өмнөх цагийг хэмнэхээр шийдсэн (модул нь өөрөө энэ тугийг тохируулдаг. Одоогоор "Ажилтан", "Гадаад шугам"),
• илүү төвөгтэй залгах төлөвлөгөөний хувьд дуудлага өөр өөр бүлгүүдийн хооронд дамжих үед элемент бүрийг тусад нь шалгах боломжтой байх шаардлагатай байв.

Хамгийн сайн сонголт бол PBX модулиуд дуудлагаар өөрсдийнхөө тухай мэдээллийг илгээж, эцэст нь мэдээллийг мод хэлбэрээр хадгалах явдал байв.

Энэ нь иймэрхүү харагдаж байна:

Нэгдүгээрт, дуудлагын талаархи ерөнхий мэдээлэл (бусдын нэгэн адил - онцгой зүйл байхгүй).

1. Гаднах утсанд дуудлага ирсэн "Туршилтын хувьд"05:55:52 цагт 89295671458 дугаараас 89999999999 дугаар руу залгахад эцэст нь ажилтан хариу өгсөн"Нарийн бичгийн дарга 2» 104 дугаартай. Үйлчлүүлэгч 60 секунд хүлээж, 36 секунд ярьсан.
2. Ажилтан"Нарийн бичгийн дарга 2"112 руу залгаж, ажилтан хариулдаг"Менежер1» 8 секундын дараа. Тэд 14 секундын турш ярьдаг.
3. Үйлчлүүлэгчийг ажилтан руу шилжүүлсэн "менежер1"Тэд 13 секундын турш үргэлжлүүлэн ярина

Гэхдээ энэ бол мөсөн уулын орой бөгөөд бичлэг бүрийн хувьд та PBX-ээр дамжуулан дэлгэрэнгүй дуудлагын түүхийг авах боломжтой.

Бүх мэдээллийг дуудлагын үүр болгон харуулав:

1. Гаднах утсанд дуудлага ирсэн "Туршилтын хувьд» 05:55:52 цагт 89295671458 дугаараас 89999999999 дугаарт холбогдоно уу.
2. 05:55:53 цагт гадна шугам нь ирж буй хэлхээнд дуудлага илгээдэг "туршилтын»
3. Схемийн дагуу дуудлагыг боловсруулахдаа модуль "менежерийн дуудлага", дуудлага 16 секунд байна. Энэ бол үйлчлүүлэгчид зориулагдсан модуль юм.
4. Модуль "менежерийн дуудлага" дугаар (үйлчлүүлэгч) хариуцсан ажилтан руу дуудлага илгээдэг"Менежер1” гэж бичээд хариу ирэхийг 5 секунд хүлээнэ. Менежер хариулсангүй.
5. Модуль "менежерийн дуудлага"бүлэг рүү дуудлага илгээх"CORP менежерүүд" Эдгээр нь ижил чиглэлийн бусад менежерүүд (нэг өрөөнд сууж байгаа) бөгөөд хариу өгөхийг 11 секунд хүлээж байна.
6. Бүлэг "CORP менежерүүд"ажилчдыг дууддаг"Менежер1, Менежер2, Менежер3"11 секундын турш нэгэн зэрэг. Хариултгүй.
7. Менежерийн дуудлага дуусна. Мөн хэлхээ нь модуль руу дуудлага илгээдэг "1c-ээс зам сонгох" Мөн үйлчлүүлэгчид зориулж бичсэн модуль. Энд дуудлага 0 секундын турш боловсруулагдсан.
8. Хэлхээ нь дуут цэс рүү дуудлага илгээдэг "Нэмэлт залгалттай үндсэн" Үйлчлүүлэгч тэнд 31 секунд хүлээсэн бөгөөд нэмэлт залгалт хийгдээгүй.
9. Уг схем нь групп руу дуудлага илгээдэг "Нарийн бичгийн дарга нар", үйлчлүүлэгч 12 секунд хүлээсэн.
10. Бүлэгт 2 ажилтныг нэгэн зэрэг дууддаг "Нарийн бичгийн дарга 1"Мөн"Нарийн бичгийн дарга 2"болон 12 секундын дараа ажилтан хариулдаг"Нарийн бичгийн дарга 2" Дуудлагын хариу нь эцэг эхийн дуудлагад давхарддаг. Тэр бүлэгт "гэж хариулсан нь харагдаж байна.Нарийн бичгийн дарга 2", залгахад хэлхээг хариулсан"Нарийн бичгийн дарга 2"Гадна утсан дээрх дуудлагад" гэж хариулав.Нарийн бичгийн дарга 2".

Үйл ажиллагаа бүрийн талаархи мэдээллийг хадгалах, үүрлэх нь зүгээр л тайлан гаргах боломжийг олгоно. Дуут цэсний тайлан нь энэ нь хэр их тусалдаг эсвэл саад болж байгааг олж мэдэхэд тусална. Ажиллагсдын дуудлагыг тасалсан, тиймээс аваагүйд тооцогдохгүй, бүлгийн дуудлага байсан, өөр хэн нэгэн өмнө нь хариулсан, энэ нь дуудлагыг бас аваагүй гэсэн үг гэдгийг харгалзан ажилчдын алдсан дуудлагын тайланг бүрдүүлэх.

Ийм мэдээллийн хадгалалт нь бүлэг бүрийг тусад нь авч, хэр үр дүнтэй ажиллаж байгааг тодорхойлох, хариулсан болон орхигдсон бүлгүүдийн графикийг цаг тутамд гаргах боломжийг олгоно. Мөн менежертэй холбогдсоны дараа шилжүүлэгт дүн шинжилгээ хийх замаар хариуцлагатай менежертэй холбогдох нь хэр үнэн зөв болохыг шалгаж болно.

Та мөн нэлээд хэвийн бус судалгаа хийж болно, жишээлбэл, мэдээллийн санд байхгүй дугаарууд зөв өргөтгөл рүү залгах эсвэл гарч буй дуудлагын хэдэн хувийг гар утас руу дамжуулдаг вэ.

Эцсийн эцэст юу вэ?

PBX-ийн засвар үйлчилгээ хийхэд мэргэжилтэн шаардлагагүй, хамгийн энгийн администратор үүнийг хийж чадна - практик дээр туршиж үзсэн.

Өөрчлөлт хийхийн тулд ноцтой мэргэшсэн мэргэжилтнүүд шаардлагагүй, учир нь PHP-ийн мэдлэг хангалттай SIP протокол, дараалал, ажилтныг дуудах гэх мэт модулиудыг аль хэдийн бичсэн байна. Боодлын ангилал байдаг Астэриск. Модуль боловсруулахын тулд програмист бэлэн модулиудыг дуудаж болно (мөн сайн аргаар). Мөн мэдлэг Астэриск Хэрэв үйлчлүүлэгч шинэ тайлан бүхий хуудас нэмэхийг хүсвэл энэ нь огт шаардлагагүй болно. Гэвч практикээс харахад гуравдагч талын програмистууд үүнийг даван туулж чаддаг ч бичиг баримтгүй, сэтгэгдлийг хэвийн хамруулахгүйгээр өөртөө итгэлгүй байдаг тул сайжруулах боломж байсаар байна.

Модуль нь:

• дуудлага боловсруулах шинэ чадварыг бий болгох,
• вэб интерфэйс дээр шинэ блок нэмэх,
• Одоо байгаа модулиудын аль нэгийг нь өвлөн авах, функцуудыг дахин тодорхойлж, солих, эсвэл зүгээр л бага зэрэг өөрчлөгдсөн хуулбар байх,
• тохиргоогоо бусад модулиудын тохиргооны загварт нэмж оруулах гэх мэт.

API-ээр дамжуулан PBX тохиргоо. Дээр дурдсанчлан бүх тохиргоонууд нь мэдээллийн санд хадгалагдаж, дуудлага хийх үед уншдаг тул та API-ээр дамжуулан бүх PBX тохиргоог өөрчлөх боломжтой. API-г дуудах үед тохиргоо дахин хийгдээгүй бөгөөд модулиуд дахин ачаалагдахгүй тул хичнээн тохиргоо, ажилтантай байх нь хамаагүй. API хүсэлтийг хурдан гүйцэтгэдэг бөгөөд бие биенээ хаадаггүй.

PBX нь дуудлагын үргэлжлэх хугацаа (хүлээлгэх/харилцах), үүрлэх болон PBX-ийн нэр томъёо (ажилтан, бүлэг, гадаад шугам, суваг, дугаар биш) бүхий бүх үндсэн үйлдлүүдийг хадгалдаг. Энэ нь танд тодорхой үйлчлүүлэгчдэд зориулсан янз бүрийн тайлан гаргах боломжийг олгодог бөгөөд ихэнх ажил нь хэрэглэгчдэд ээлтэй интерфэйсийг бий болгох явдал юм.

Цаашид юу болохыг цаг хугацаа харуулна. Дахин засварлах шаардлагатай олон нюансууд байсаар байгаа, олон төлөвлөгөө байгаа ч 3-р хувилбарыг бүтээснээс хойш нэг жил өнгөрсөн бөгөөд санаа нь ажиллаж байна гэж бид аль хэдийн хэлж чадна. 3-р хувилбарын гол сул тал бол техник хангамжийн нөөц юм, гэхдээ үүнийг хөгжүүлэхэд хялбар болгохын тулд ихэвчлэн төлөх ёстой зүйл юм.

Эх сурвалж: www.habr.com