एका प्रकल्पाची कथा किंवा मी 7 वर्षे Asterisk आणि Php वर आधारित PBX तयार करण्यासाठी कशी घालवली

माझ्यासारख्या तुमच्यापैकी अनेकांना काहीतरी अनोखे करण्याची कल्पना आली असेल. या लेखात मी PBX विकसित करताना मला ज्या तांत्रिक समस्या आणि उपायांचा सामना करावा लागला त्याचे वर्णन करेन. कदाचित हे एखाद्याला स्वतःच्या कल्पनांवर निर्णय घेण्यास मदत करेल आणि कोणीतरी चांगल्या मार्गावर चालण्यास मदत करेल, कारण मला पायनियरांच्या अनुभवाचा देखील फायदा झाला.

कल्पना आणि मुख्य आवश्यकता

आणि हे सर्व फक्त प्रेमाने सुरू झाले चौफुली (संप्रेषण अनुप्रयोग तयार करण्यासाठी फ्रेमवर्क), टेलिफोनी आणि स्थापनांचे ऑटोमेशन फ्रीपीबीएक्स (यासाठी वेब इंटरफेस चौफुली). जर कंपनीच्या गरजा विशिष्ट नसल्या आणि क्षमतांमध्ये पडल्या फ्रीपीबीएक्स - सर्व काही छान आहे. संपूर्ण इंस्टॉलेशन XNUMX तासांच्या आत झाले, कंपनीला कॉन्फिगर केलेले PBX, एक वापरकर्ता-अनुकूल इंटरफेस आणि इच्छित असल्यास लहान प्रशिक्षण आणि समर्थन प्राप्त झाले.

परंतु सर्वात मनोरंजक कार्ये मानक नसलेली होती आणि नंतर ती इतकी कल्पित नव्हती. चौफुली बरेच काही करू शकते, परंतु वेब इंटरफेस कार्यरत क्रमाने ठेवण्यासाठी, अनेक वेळा जास्त वेळ घालवणे आवश्यक होते. त्यामुळे उर्वरित PBX स्थापित करण्यापेक्षा एक लहान तपशील जास्त वेळ घेऊ शकतो. आणि मुद्दा असा नाही की वेब इंटरफेस लिहिण्यासाठी बराच वेळ लागतो, परंतु मुद्दा आर्किटेक्चरल वैशिष्ट्यांमध्ये आहे. फ्रीपीबीएक्स. आर्किटेक्चर दृष्टिकोन आणि पद्धती फ्रीपीबीएक्स php4 च्या वेळी मांडले गेले होते, आणि त्या क्षणी आधीच php5.6 होते ज्यावर सर्वकाही सोपे आणि अधिक सोयीस्कर केले जाऊ शकते.

शेवटचा पेंढा आकृतीच्या स्वरूपात ग्राफिकल डायलप्लॅन्स होता. जेव्हा मी असे काहीतरी तयार करण्याचा प्रयत्न केला फ्रीपीबीएक्स, मला जाणवले की मला ते लक्षणीयरीत्या पुन्हा लिहावे लागेल आणि काहीतरी नवीन तयार करणे सोपे होईल.

मुख्य आवश्यकता होत्या:

• साधे सेटअप, अगदी नवशिक्या प्रशासकासाठी देखील अंतर्ज्ञानी प्रवेशयोग्य. अशा प्रकारे, कंपन्यांना आमच्या बाजूने पीबीएक्स देखभाल आवश्यक नाही,
• सोपे बदल जेणेकरून कामे पुरेशा वेळेत सोडवली जातील,
• PBX सह एकत्रीकरणाची सुलभता. यू फ्रीपीबीएक्स सेटिंग्ज बदलण्यासाठी कोणतेही API नव्हते, उदा. तुम्ही, उदाहरणार्थ, तृतीय-पक्ष अनुप्रयोगावरून गट किंवा व्हॉइस मेनू तयार करू शकत नाही, फक्त API स्वतः चौफुली,
• ओपनसोर्स - प्रोग्रामरसाठी क्लायंटसाठी बदलांसाठी हे अत्यंत महत्वाचे आहे.

जलद विकासाची कल्पना अशी होती की सर्व कार्यक्षमतेमध्ये ऑब्जेक्ट्सच्या स्वरूपात मॉड्यूल असतात. सर्व ऑब्जेक्ट्सचा एक सामान्य पालक वर्ग असणे आवश्यक आहे, याचा अर्थ सर्व मुख्य फंक्शन्सची नावे आधीच ज्ञात आहेत आणि म्हणून आधीच डीफॉल्ट अंमलबजावणी आहेत. ऑब्जेक्ट्स तुम्हाला स्ट्रिंग की सह असोसिएटिव्ह अॅरेच्या स्वरूपात वितर्कांची संख्या नाटकीयपणे कमी करण्यास अनुमती देतील, ज्यामध्ये तुम्ही शोधू शकता. फ्रीपीबीएक्स संपूर्ण फंक्शन आणि नेस्टेड फंक्शन्सचे परीक्षण करून हे शक्य झाले. वस्तूंच्या बाबतीत, बॅनल स्वयंपूर्णता सर्व गुणधर्म दर्शवेल आणि सर्वसाधारणपणे जीवन अनेक वेळा सोपे करेल. शिवाय, वारसा आणि पुनर्व्याख्या आधीच बदलांसह अनेक समस्या सोडवते.

पुढील गोष्ट जी रीवर्कची वेळ कमी करते आणि टाळण्यासारखी होती ती म्हणजे डुप्लिकेशन. कर्मचार्‍याला डायल करण्यासाठी जबाबदार मॉड्यूल असल्यास, कर्मचार्‍याला कॉल पाठवण्याची आवश्यकता असलेल्या इतर सर्व मॉड्यूल्सनी ते वापरावे आणि त्यांच्या स्वतःच्या प्रती तयार करू नये. म्हणून, जर तुम्हाला काही बदलायचे असेल तर तुम्हाला फक्त एकाच ठिकाणी बदलावे लागेल आणि "ते कसे कार्य करते" याचा शोध एकाच ठिकाणी केला पाहिजे आणि संपूर्ण प्रकल्पात शोधू नये.

प्रथम आवृत्ती आणि प्रथम त्रुटी

पहिला प्रोटोटाइप वर्षभरात तयार झाला. संपूर्ण पीबीएक्स, नियोजित प्रमाणे, मॉड्यूलर होते, आणि मॉड्यूल केवळ कॉल प्रक्रिया करण्यासाठी नवीन कार्यक्षमता जोडू शकत नाहीत तर वेब इंटरफेस देखील बदलू शकतात.

होय, अशा योजनेच्या स्वरूपात डायलप्लॅन बनवण्याची कल्पना माझी नाही, परंतु ती खूप सोयीची आहे आणि मी तेच केले चौफुली.

मॉड्यूल लिहून, प्रोग्रामर आधीच हे करू शकतात:

• कॉल प्रोसेसिंगसाठी तुमची स्वतःची कार्यक्षमता तयार करा, जी आकृतीवर तसेच डावीकडील घटकांच्या मेनूमध्ये ठेवली जाऊ शकते,
• वेब इंटरफेससाठी आपली स्वतःची पृष्ठे तयार करा आणि विद्यमान पृष्ठांवर आपले टेम्पलेट जोडा (जर पृष्ठ विकसकाने यासाठी प्रदान केले असेल),
• तुमची सेटिंग्ज मुख्य सेटिंग्ज टॅबवर जोडा किंवा तुमचा स्वतःचा सेटिंग्ज टॅब तयार करा,
• प्रोग्रामर विद्यमान मॉड्यूलमधून वारसा मिळवू शकतो, कार्यक्षमतेचा भाग बदलू शकतो आणि नवीन नावाखाली नोंदणी करू शकतो किंवा मूळ मॉड्यूल पुनर्स्थित करू शकतो.

उदाहरणार्थ, तुम्ही तुमचा स्वतःचा व्हॉइस मेनू कसा तयार करू शकता:

......
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 सेटिंग्ज बदलण्यासाठी सामान्य API लिहिणे अशक्य आहे. प्रथम, मध्ये बदल लागू करण्याचे ऑपरेशन चौफुली खूप लांब आणि संसाधन गहन.
दुसरे म्हणजे, तुम्ही एकाच वेळी दोन फंक्शन्स कॉल करू शकत नाही, कारण दोन्ही कॉन्फिगरेशन तयार करतील.
तिसरे म्हणजे, हे प्रशासकाद्वारे तयार केलेल्या सर्व सेटिंग्जसह लागू होते.

या आवृत्तीमध्ये, जसे की आस्कोझिया, केवळ बदललेल्या मॉड्यूल्सचे कॉन्फिगरेशन व्युत्पन्न करणे आणि फक्त आवश्यक मॉड्यूल्स रीस्टार्ट करणे शक्य होते, परंतु हे सर्व अर्धे उपाय आहेत. दृष्टिकोन बदलणे गरजेचे होते.

दुसरी आवृत्ती. नाक बाहेर काढलेले शेपूट अडकले

समस्येचे निराकरण करण्याचा विचार म्हणजे कॉन्फिगरेशन आणि डायलप्लॅन पुन्हा तयार करणे नाही चौफुली, परंतु डेटाबेसमध्ये माहिती जतन करा आणि कॉलवर प्रक्रिया करताना थेट डेटाबेसमधून वाचा. चौफुली डेटाबेसमधील कॉन्फिगरेशन कसे वाचायचे हे मला आधीच माहित होते, फक्त डेटाबेसमधील मूल्य बदला आणि पुढील कॉलवर बदल लक्षात घेऊन प्रक्रिया केली जाईल आणि डायलप्लॅन पॅरामीटर्स वाचण्यासाठी फंक्शन योग्य आहे. 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 ची समस्या सोडवली. तुम्ही थेट डेटाबेसमध्ये जाऊन एक नवीन गट जोडू शकता किंवा बदल करू शकता, उदाहरणार्थ, गटासाठी “डायलटाइम” फील्डमधील डायल-अप वेळ आणि पुढील कॉल आधीच निर्दिष्ट वेळेपर्यंत टिकेल (यासाठी ही शिफारस नाही. क्रिया, काही API ऑपरेशन आवश्यक असल्याने अमी कॉल).

पहिल्या कठीण अंमलबजावणीने पुन्हा पहिला अभिमान आणि निराशा आणली. ते काम केले याचा मला आनंद झाला. डेटाबेस एक गंभीर दुवा बनला, डिस्कवरील अवलंबित्व वाढले, अधिक जोखीम होती, परंतु सर्वकाही स्थिरपणे आणि समस्यांशिवाय कार्य करते. आणि सर्वात महत्त्वाचे म्हणजे, आता वेब इंटरफेसद्वारे जे काही केले जाऊ शकते ते API द्वारे केले जाऊ शकते आणि त्याच पद्धती वापरल्या गेल्या. याव्यतिरिक्त, वेब इंटरफेस "पीबीएक्सवर सेटिंग्ज लागू करा" बटणापासून मुक्त झाले, जे प्रशासक अनेकदा विसरले.

निराशा अशी होती की विकास अधिक गुंतागुंतीचा झाला. पहिल्या आवृत्तीपासून, PHP भाषेने भाषेमध्ये डायलप्लॅन तयार केला आहे चौफुली आणि ते पूर्णपणे अवाचनीय दिसते, तसेच भाषा स्वतःच चौफुली डायलप्लॅन लिहिण्यासाठी ते अत्यंत प्राचीन आहे.

ते कसे दिसले:

$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 वरून dialplan करा आणि वापरा फास्टॅजी आणि सर्व प्रक्रिया नियम PHP मध्येच लिहा. फास्टॅजी तो संमत चौफुली, कॉलवर प्रक्रिया करण्यासाठी, सॉकेटशी कनेक्ट करा. तेथून आदेश प्राप्त करा आणि निकाल पाठवा. अशा प्रकारे, डायलप्लॅनचे तर्क आधीच सीमांच्या बाहेर आहे चौफुली आणि PHP मध्ये माझ्या बाबतीत, कोणत्याही भाषेत लिहिले जाऊ शकते.

खूप चाचण्या आणि त्रुटी होत्या. मुख्य समस्या अशी होती की माझ्याकडे आधीपासूनच बरेच वर्ग/फाईल्स आहेत. ऑब्जेक्ट्स तयार करण्यासाठी, त्यांना प्रारंभ करण्यासाठी आणि एकमेकांना नोंदणी करण्यासाठी सुमारे 1,5 सेकंद लागले आणि प्रत्येक कॉलसाठी हा विलंब दुर्लक्षित केला जाऊ शकत नाही.

इनिशियलायझेशन एकदाच व्हायला हवे होते आणि म्हणून php वापरून सेवा लिहिण्यापासून समाधानाचा शोध सुरू झाला थ्रेड्स. एका आठवड्याच्या प्रयोगानंतर, हा विस्तार कसा कार्य करतो या गुंतागुंतीमुळे हा पर्याय रद्द करण्यात आला. एका महिन्याच्या चाचणीनंतर, मला PHP मध्ये असिंक्रोनस प्रोग्रामिंग देखील सोडावे लागले; मला काहीतरी सोपे, कोणत्याही PHP नवशिक्याला परिचित असले पाहिजे आणि PHP साठी बरेच विस्तार समकालिक आहेत.

उपाय म्हणजे सी मधील आमची स्वतःची मल्टी-थ्रेडेड सेवा, जी संकलित केली गेली होती PHPLIB. हे सर्व ATS php फाइल्स लोड करते, सर्व मॉड्यूल सुरू होण्याची प्रतीक्षा करते, एकमेकांना कॉलबॅक जोडते आणि सर्वकाही तयार झाल्यावर ते कॅश करते. द्वारे चौकशी केली असता फास्टॅजी एक प्रवाह तयार केला जातो, सर्व वर्गांच्या कॅशेची एक प्रत आणि त्यात डेटा पुनरुत्पादित केला जातो आणि विनंती php फंक्शनकडे पाठविली जाते.

या सोल्यूशनसह, आमच्या सेवेला कॉल पाठविण्यापासून ते पहिल्या आदेशापर्यंत वेळ चौफुली 1,5s ते 0,05s पर्यंत कमी झाले आणि हा वेळ प्रकल्पाच्या आकारावर थोडा अवलंबून आहे.

परिणामी, डायलप्लॅन डेव्हलपमेंटसाठी लागणारा वेळ लक्षणीयरीत्या कमी झाला आणि मी याचे कौतुक करू शकतो कारण मला PHP मधील सर्व मॉड्यूल्सचा संपूर्ण डायलप्लॅन पुन्हा लिहावा लागला. प्रथम, डेटाबेसमधून ऑब्जेक्ट मिळविण्यासाठी पद्धती आधीपासूनच php मध्ये लिहिल्या पाहिजेत; ते वेब इंटरफेसमध्ये प्रदर्शित करण्यासाठी आवश्यक होते आणि दुसरे म्हणजे, आणि ही मुख्य गोष्ट आहे, शेवटी संख्या आणि अॅरेसह स्ट्रिंगसह सोयीस्करपणे कार्य करणे शक्य आहे. डेटाबेस आणि अनेक PHP विस्तारांसह.

मॉड्यूल क्लासमध्ये डायलप्लॅनवर प्रक्रिया करण्यासाठी तुम्हाला फंक्शन लागू करणे आवश्यक आहे dialplanDynamicCall आणि वाद pbxCallRequest संवाद साधण्यासाठी एक ऑब्जेक्ट असेल चौफुली.

याव्यतिरिक्त, डायलप्लान डीबग करणे शक्य झाले (php मध्ये xdebug आहे आणि ते आमच्या सेवेसाठी कार्य करते), आपण व्हेरिएबल्सची मूल्ये पाहून चरण-दर-चरण हलवू शकता.

कॉल डेटा

कोणत्याही विश्लेषणे आणि अहवालांसाठी योग्यरित्या गोळा केलेला डेटा आवश्यक आहे आणि या PBX ब्लॉकला पहिल्यापासून तिसऱ्या आवृत्तीपर्यंत अनेक चाचणी आणि त्रुटी देखील आल्या. अनेकदा, कॉल डेटा एक चिन्ह आहे. एक कॉल = एक रेकॉर्डिंग: कोणी कॉल केला, कोणी उत्तर दिले, ते किती वेळ बोलले. अधिक मनोरंजक पर्यायांमध्ये, कॉल दरम्यान कोणत्या PBX कर्मचार्‍याला कॉल केले होते हे दर्शविणारे एक अतिरिक्त चिन्ह आहे. परंतु हे सर्व केवळ गरजांचा भाग समाविष्ट करते.

प्रारंभिक आवश्यकता होत्या:

• केवळ पीबीएक्सने कोणाला कॉल केला नाही तर कोणी उत्तर दिले हे देखील जतन करा, कारण तेथे व्यत्यय आहेत आणि कॉलचे विश्लेषण करताना हे लक्षात घेतले पाहिजे,
• कर्मचाऱ्याशी संपर्क साधण्यापूर्वीचा वेळ. मध्ये फ्रीपीबीएक्स आणि काही इतर PBX, PBX फोन उचलताच कॉलला उत्तर दिले जाते. परंतु व्हॉइस मेनूसाठी तुम्हाला आधीच फोन उचलण्याची आवश्यकता आहे, त्यामुळे सर्व कॉल्सचे उत्तर दिले जाते आणि उत्तराची प्रतीक्षा वेळ 0-1 सेकंद होते. म्हणून, केवळ प्रतिसादापूर्वीचा वेळच नाही तर की मॉड्यूलशी कनेक्ट होण्यापूर्वीचा वेळ वाचवण्याचा निर्णय घेण्यात आला (मॉड्यूल स्वतःच हा ध्वज सेट करते. सध्या तो “कर्मचारी”, “बाह्य रेषा” आहे),
• अधिक जटिल डायलप्लॅनसाठी, जेव्हा कॉल वेगवेगळ्या गटांमध्ये प्रवास करतो, तेव्हा प्रत्येक घटकाचे स्वतंत्रपणे परीक्षण करण्यास सक्षम असणे आवश्यक होते.

जेव्हा पीबीएक्स मॉड्यूल्स कॉलवर स्वतःबद्दल माहिती पाठवतात आणि शेवटी झाडाच्या रूपात माहिती जतन करतात तेव्हा सर्वोत्तम पर्याय ठरला.

हे असे दिसते:

प्रथम, कॉलबद्दल सामान्य माहिती (इतर प्रत्येकाप्रमाणे - विशेष काही नाही).

1. बाहेरील लाईनवर कॉल आला "चाचणीसाठी"०५:५५:५२ वाजता ८९२९५६७१४५८ क्रमांकावरून ८९९९९९९९९९ पर्यंत, शेवटी एका कर्मचाऱ्याने उत्तर दिले"सचिव2» 104 क्रमांकासह. क्लायंटने 60 सेकंद वाट पाहिली आणि 36 सेकंद बोलले.
2. कर्मचारी"सचिव2"112 वर कॉल करतो आणि एक कर्मचारी उत्तर देतो"व्यवस्थापक1» 8 सेकंदांनंतर. ते 14 सेकंद बोलतात.
3. क्लायंट कर्मचाऱ्याकडे हस्तांतरित केला जातो "व्यवस्थापक1" जिथे ते आणखी 13 सेकंद बोलत राहतात

पण हे हिमनगाचे टोक आहे; प्रत्येक रेकॉर्डसाठी तुम्ही PBX द्वारे तपशीलवार कॉल इतिहास मिळवू शकता.

सर्व माहिती कॉलच्या नेस्टिंग म्हणून सादर केली जाते:

1. बाहेरील लाईनवर कॉल आला "चाचणीसाठी» ०५:५५:५२ वाजता ८९२९५६७१४५८ क्रमांकावरून ८९९९९९९९९९९ पर्यंत.
2. 05:55:53 वाजता बाहेरील ओळ इनकमिंग सर्किटला कॉल पाठवते "चाचणी»
3. योजनेनुसार कॉलवर प्रक्रिया करताना, मॉड्यूल “व्यवस्थापक कॉल", ज्यामध्ये कॉल 16 सेकंदांचा असतो. हे क्लायंटसाठी विकसित केलेले मॉड्यूल आहे.
4. मॉड्यूल "व्यवस्थापक कॉल"क्रमांक (क्लायंट) साठी जबाबदार असलेल्या कर्मचाऱ्याला कॉल पाठवते"व्यवस्थापक1” आणि प्रतिसादासाठी ५ सेकंद प्रतीक्षा करते. व्यवस्थापकाने उत्तर दिले नाही.
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 चे ज्ञान पुरेसे आहे, कारण मॉड्यूल्स आधीपासूनच एसआयपी प्रोटोकॉलसाठी आणि रांगेसाठी आणि कर्मचाऱ्याला कॉल करण्यासाठी आणि इतरांसाठी लिहिलेले आहेत. साठी रॅपर क्लास आहे चौफुली. मॉड्यूल विकसित करण्यासाठी, प्रोग्रामर तयार मॉड्यूल कॉल करू शकतो (आणि चांगल्या मार्गाने) आणि ज्ञान चौफुली जर क्लायंटने काही नवीन अहवालासह पृष्ठ जोडण्यास सांगितले तर ते पूर्णपणे अनावश्यक आहेत. परंतु सराव दर्शवितो की जरी तृतीय-पक्ष प्रोग्रामर सामना करू शकतात, तरीही त्यांना दस्तऐवजीकरण आणि टिप्पण्यांच्या सामान्य कव्हरेजशिवाय असुरक्षित वाटते, त्यामुळे सुधारणेसाठी अद्याप जागा आहे.

मॉड्यूल हे करू शकतात:

• नवीन कॉल प्रोसेसिंग क्षमता तयार करा,
• वेब इंटरफेसमध्ये नवीन ब्लॉक्स जोडा,
• अस्तित्वात असलेल्या कोणत्याही मॉड्यूल्समधून इनहेरिट करा, फंक्शन्स पुन्हा परिभाषित करा आणि ते बदला, किंवा फक्त थोडी सुधारित प्रत बनवा,
• इतर मॉड्यूल्सच्या सेटिंग्ज टेम्पलेटमध्ये तुमची सेटिंग्ज जोडा आणि बरेच काही.

API द्वारे PBX ​​सेटिंग्ज. वर वर्णन केल्याप्रमाणे, सर्व सेटिंग्ज डेटाबेसमध्ये संग्रहित केल्या जातात आणि कॉलच्या वेळी वाचल्या जातात, त्यामुळे तुम्ही API द्वारे सर्व PBX सेटिंग्ज बदलू शकता. API ला कॉल करताना, कॉन्फिगरेशन पुन्हा तयार केले जात नाही आणि मॉड्यूल रीस्टार्ट केले जात नाहीत, म्हणून, आपल्याकडे किती सेटिंग्ज आणि कर्मचारी आहेत हे महत्त्वाचे नाही. API विनंत्या त्वरीत कार्यान्वित केल्या जातात आणि एकमेकांना अवरोधित करत नाहीत.

PBX कालावधी (प्रतीक्षा/संभाषण), नेस्टिंग आणि PBX अटींसह (कर्मचारी, गट, बाह्य लाइन, चॅनेल, नंबर नाही) कॉलसह सर्व प्रमुख ऑपरेशन्स संग्रहित करते. हे तुम्हाला विशिष्ट क्लायंटसाठी विविध अहवाल तयार करण्यास अनुमती देते आणि बहुतेक काम वापरकर्ता-अनुकूल इंटरफेस तयार करणे आहे.

पुढे काय होणार हे काळच सांगेल. अजूनही अनेक बारकावे आहेत ज्या पुन्हा करणे आवश्यक आहे, अजूनही अनेक योजना आहेत, परंतु 3 री आवृत्ती तयार होऊन एक वर्ष उलटून गेले आहे आणि आम्ही आधीच असे म्हणू शकतो की कल्पना कार्यरत आहे. आवृत्ती 3 चा मुख्य गैरसोय हा हार्डवेअर संसाधने आहे, परंतु विकासाच्या सुलभतेसाठी आपल्याला सहसा हेच द्यावे लागते.

स्त्रोत: www.habr.com