एउटा परियोजनाको कथा वा कसरी मैले Asterisk र Php मा आधारित PBX बनाउन ७ वर्ष बिताएँ

पक्कै पनि म जस्तै तपाईंहरूमध्ये धेरैलाई केही अनौठो गर्ने विचार थियो। यस लेखमा म PBX विकास गर्दा मैले सामना गर्नुपर्ने प्राविधिक समस्या र समाधानहरूको वर्णन गर्नेछु। सायद यसले कसैलाई आफ्नै विचारमा निर्णय गर्न मद्दत गर्नेछ, र कसैलाई राम्ररी कुचलेको बाटो पछ्याउन, किनकि मैले अग्रगामीहरूको अनुभवबाट पनि लाभ उठाएको छु।

विचार र प्रमुख आवश्यकताहरू

र यो सबै केवल प्रेम संग सुरु भयो Asterisk (सञ्चार अनुप्रयोगहरू निर्माणको लागि फ्रेमवर्क), टेलिफोनी र स्थापनाहरूको स्वचालन freepbx (का लागि वेब इन्टरफेस Asterisk)। यदि कम्पनीको आवश्यकताहरू विशेष बिना थिए र क्षमताहरू भित्र परे freepbx - सबै कुरा महान छ। सम्पूर्ण स्थापना XNUMX घण्टा भित्र भयो, कम्पनीले कन्फिगर गरिएको PBX, प्रयोगकर्ता-मैत्री इन्टरफेस र छोटो प्रशिक्षण प्लस समर्थन प्राप्त गर्यो यदि चाहियो भने।

तर सबैभन्दा रोचक कार्यहरू गैर-मानक थिए र त्यसपछि यो धेरै शानदार थिएन। Asterisk धेरै गर्न सक्छ, तर वेब इन्टरफेस कार्य क्रममा राख्न, यो धेरै पटक धेरै समय खर्च गर्न आवश्यक थियो। त्यसैले एउटा सानो विवरणले बाँकी PBX स्थापना भन्दा धेरै समय लिन सक्छ। र बिन्दु यो होइन कि यसले वेब इन्टरफेस लेख्न लामो समय लिन्छ, बरु बिन्दु वास्तुकला सुविधाहरूमा छ। freepbx। वास्तुकला दृष्टिकोण र विधिहरू freepbx php4 को समयमा राखिएको थियो, र त्यस समयमा त्यहाँ पहिले नै php5.6 थियो जसमा सबै कुरा सरल र अधिक सुविधाजनक बनाउन सकिन्छ।

अन्तिम स्ट्रा रेखाचित्रको रूपमा ग्राफिकल डायलप्लानहरू थिए। जब मैले यसका लागि केहि निर्माण गर्ने प्रयास गरें freepbx, मैले महसुस गरें कि मैले यसलाई महत्त्वपूर्ण रूपमा पुन: लेख्नुपर्छ र केहि नयाँ निर्माण गर्न सजिलो हुनेछ।

मुख्य आवश्यकताहरू थिए:

• सरल सेटअप, एक नौसिखिया प्रशासकलाई पनि सहज पहुँचयोग्य। यसरी, कम्पनीहरूलाई हाम्रो पक्षमा PBX मर्मत आवश्यक पर्दैन,
• कार्यहरू पर्याप्त समयमा समाधान गर्न सजिलो परिमार्जन,
• PBX संग एकीकरण को सजिलो। U freepbx सेटिङहरू परिवर्तन गर्नको लागि कुनै API थिएन, अर्थात्। तपाईं, उदाहरणका लागि, तेस्रो-पक्ष अनुप्रयोगबाट समूह वा भ्वाइस मेनुहरू सिर्जना गर्न सक्नुहुन्न, केवल API आफैं Asterisk,
• ओपनसोर्स - प्रोग्रामरहरूको लागि यो क्लाइन्टको लागि परिमार्जनहरूको लागि अत्यन्त महत्त्वपूर्ण छ।

द्रुत विकासको विचार भनेको सबै प्रकार्यहरू वस्तुहरूको रूपमा मोड्युलहरू समावेश हुनु थियो। सबै वस्तुहरूमा साझा अभिभावक वर्ग हुनुपर्छ, जसको अर्थ सबै मुख्य प्रकार्यहरूको नाम पहिले नै थाहा छ र त्यसैले त्यहाँ पहिले नै पूर्वनिर्धारित कार्यान्वयनहरू छन्। वस्तुहरूले तपाइँलाई स्ट्रिङ कुञ्जीहरूसँग सहयोगी एरेहरूको रूपमा तर्कहरूको संख्या नाटकीय रूपमा घटाउन अनुमति दिनेछ, जुन तपाइँले फेला पार्न सक्नुहुन्छ। freepbx सम्पूर्ण प्रकार्य र नेस्टेड प्रकार्यहरू जाँच गरेर यो सम्भव थियो। वस्तुहरूको मामलामा, साधारण स्वत: पूर्णताले सबै गुणहरू देखाउनेछ, र सामान्यतया जीवनलाई धेरै पटक सरल बनाउनेछ। साथै, विरासत र पुन: परिभाषाले परिमार्जनहरूसँग धेरै समस्याहरू समाधान गर्दछ।

अर्को कुरा जसले पुन: कार्य समयलाई सुस्त बनायो र बेवास्ता गर्न लायक थियो नक्कल थियो। यदि कर्मचारीलाई डायल गर्नको लागि जिम्मेवार मोड्युल छ भने, कर्मचारीलाई कल पठाउन आवश्यक पर्ने अन्य सबै मोड्युलहरूले यसलाई प्रयोग गर्नुपर्छ, र तिनीहरूको आफ्नै प्रतिलिपिहरू सिर्जना गर्नु हुँदैन। त्यसोभए, यदि तपाइँ केहि परिवर्तन गर्न आवश्यक छ भने, तपाइँ एक ठाउँमा मात्र परिवर्तन गर्नुपर्नेछ र "कसरी यो काम गर्दछ" को लागी खोजी एकै ठाउँमा गरिनु पर्छ, र सम्पूर्ण परियोजनामा ​​खोजी गर्नुपर्दैन।

पहिलो संस्करण र पहिलो त्रुटिहरू

पहिलो प्रोटोटाइप एक वर्ष भित्र तयार भयो। सम्पूर्ण PBX, योजना अनुसार, मोड्युलर थियो, र मोड्युलहरूले कलहरू प्रशोधन गर्नका लागि नयाँ कार्यक्षमता मात्र थप्न सक्दैन, तर वेब इन्टरफेस पनि परिवर्तन गर्न सक्छ।

हो, यस्तो योजनाको रूपमा डायलप्लान निर्माण गर्ने विचार मेरो होइन, तर यो धेरै सुविधाजनक छ र मैले त्यसको लागि पनि गरें। Asterisk.

मोड्युल लेखेर, प्रोग्रामरहरूले पहिले नै:

• कल प्रशोधनका लागि आफ्नै कार्यक्षमता सिर्जना गर्नुहोस्, जुन रेखाचित्रमा राख्न सकिन्छ, साथै बायाँमा तत्वहरूको मेनुमा,
• वेब इन्टरफेसको लागि आफ्नै पृष्ठहरू सिर्जना गर्नुहोस् र अवस्थित पृष्ठहरूमा तपाईंको टेम्प्लेटहरू थप्नुहोस् (यदि पृष्ठ विकासकर्ताले यसको लागि प्रदान गरेको छ भने),
• मुख्य सेटिङ्स ट्याबमा आफ्नो सेटिङहरू थप्नुहोस् वा आफ्नै सेटिङ ट्याब सिर्जना गर्नुहोस्,
• प्रोग्रामरले अवस्थित मोड्युलबाट इनहेरिट गर्न, कार्यक्षमताको अंश परिवर्तन गर्न र नयाँ नाममा दर्ता गर्न वा मूल मोड्युललाई प्रतिस्थापन गर्न सक्छ।

उदाहरण को लागी, यो तपाईं आफ्नो आवाज मेनु कसरी सिर्जना गर्न सक्नुहुन्छ:

......
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, लागू गर्नुहोस् बटन क्लिक गरेर, सम्पूर्ण कन्फिगरेसन पुन: सिर्जना गरिन्छ र मोड्युलहरू पुन: सुरु हुन्छन्।

यो यो जस्तो देखिन्छ:

*डायलप्लान एउटा नियम (एल्गोरिदम) हो जसद्वारा कल प्रशोधन गरिन्छ।

तर यस विकल्पको साथ, PBX सेटिङहरू परिवर्तन गर्नको लागि सामान्य API लेख्न असम्भव छ। पहिलो, मा परिवर्तनहरू लागू गर्ने सञ्चालन Asterisk धेरै लामो र संसाधन गहन।
दोस्रो, तपाईं एकै समयमा दुई प्रकार्यहरू कल गर्न सक्नुहुन्न, किनभने दुबैले कन्फिगरेसन सिर्जना गर्नेछ।
तेस्रो, यो प्रशासक द्वारा बनाईएको सहित सबै सेटिङहरू लागू गर्दछ।

यस संस्करणमा, जस्तै मा Askozia, यो केवल परिवर्तन गरिएको मोड्युलहरूको कन्फिगरेसन उत्पन्न गर्न र आवश्यक मोड्युलहरू मात्र पुन: सुरु गर्न सम्भव थियो, तर यी सबै आधा उपायहरू हुन्। दृष्टिकोण परिवर्तन गर्न आवश्यक थियो।

दोस्रो संस्करण। नाक तानिएको पुच्छर अड्कियो

समस्या समाधान गर्ने विचार कन्फिगरेसन र डायलप्लान पुन: सिर्जना गर्नु थिएन Asterisk, तर डाटाबेसमा जानकारी बचत गर्नुहोस् र कल प्रशोधन गर्दा डाटाबेसबाट सीधै पढ्नुहोस्। Asterisk मलाई डाटाबेसबाट कन्फिगरेसनहरू कसरी पढ्ने भनेर पहिले नै थाहा थियो, केवल डाटाबेसमा मान परिवर्तन गर्नुहोस् र अर्को कल परिवर्तनहरूलाई ध्यानमा राखेर प्रशोधन गरिनेछ, र प्रकार्य डायलप्लान प्यारामिटरहरू पढ्नको लागि उपयुक्त थियो। REALTIME_HASH.

अन्तमा, पुन: सुरु गर्न पनि आवश्यक थिएन Asterisk सेटिङ्हरू परिवर्तन गर्दा र सबै सेटिङहरू तुरुन्तै लागू हुन थाले Asterisk.

डायलप्लानमा मात्र परिवर्तनहरू एक्स्टेन्सन नम्बरहरू र थपिएका छन् संकेतहरू। तर यी साना स्थान परिवर्तनहरू थिए

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

तपाईं सजिलैसँग डायलप्लान प्रयोग गरेर लाइन थप्न वा परिवर्तन गर्न सक्नुहुन्छ अमी (नियन्त्रण इन्टरफेस Asterisk) र सम्पूर्ण डायलप्लानको कुनै रिबुट आवश्यक पर्दैन।

यसले कन्फिगरेसन API को साथ समस्या समाधान गर्यो। तपाईं सीधै डाटाबेसमा गएर नयाँ समूह थप्न वा परिवर्तन गर्न सक्नुहुन्छ, उदाहरणका लागि, समूहको लागि "डायलटाइम" फिल्डमा डायल-अप समय र अर्को कल पहिले नै तोकिएको समयसम्म रहनेछ (यो यसका लागि सिफारिस होइन। कार्य, केही API अपरेशनहरू आवश्यक भएकोले अमी कल)।

पहिलो कठिन कार्यान्वयनले फेरि पहिलो गर्व र निराशा ल्यायो। काम गरेकोमा म खुसी थिएँ। डाटाबेस एक महत्वपूर्ण लिङ्क भयो, डिस्कमा निर्भरता बढ्यो, त्यहाँ धेरै जोखिमहरू थिए, तर सबै कुरा स्थिर र समस्या बिना काम गर्यो। र सबैभन्दा महत्त्वपूर्ण कुरा, अब वेब इन्टरफेस मार्फत गर्न सकिने सबै कुरा एपीआई मार्फत गर्न सकिन्छ, र उही विधिहरू प्रयोग गरियो। थप रूपमा, वेब इन्टरफेसले "PBX मा सेटिङहरू लागू गर्नुहोस्" बटनबाट छुटकारा पायो, जुन प्रशासकहरूले प्राय: बिर्सन्छन्।

निराशा यो थियो कि विकास थप जटिल भयो। पहिलो संस्करणदेखि, 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'))

दोस्रो संस्करणमा, डायलप्लान सार्वभौमिक भयो, यसले मापदण्डहरूमा आधारित सबै सम्भावित प्रशोधन विकल्पहरू समावेश गर्यो र यसको आकार महत्त्वपूर्ण रूपमा बढ्यो। यी सबैले विकासको समयलाई धेरै सुस्त बनायो, र एक पटक फेरि डायलप्लानमा हस्तक्षेप गर्न आवश्यक छ भन्ने सोचाइले मलाई दुःखी बनायो।

तेस्रो संस्करण

समस्या समाधान गर्ने विचार उत्पन्न गर्ने थिएन Asterisk php बाट dialplan र प्रयोग गर्नुहोस् फास्टाजी र PHP मा सबै प्रशोधन नियमहरू लेख्नुहोस्। फास्टाजी यसलाई अनुमति दिन्छ Asterisk, कल प्रशोधन गर्न, सकेटमा जडान गर्नुहोस्। त्यहाँबाट आदेशहरू प्राप्त गर्नुहोस् र परिणामहरू पठाउनुहोस्। यसरी, डायलप्लानको तर्क पहिले नै सीमा बाहिर छ Asterisk र कुनै पनि भाषामा लेख्न सकिन्छ, मेरो मामलामा PHP मा।

त्यहाँ धेरै परीक्षण र त्रुटि थियो। मुख्य समस्या यो थियो कि मसँग पहिले नै धेरै कक्षाहरू/फाइलहरू थिए। वस्तुहरू सिर्जना गर्न, तिनीहरूलाई सुरु गर्न, र एकअर्कासँग एकअर्कालाई दर्ता गर्न लगभग 1,5 सेकेन्ड लाग्यो, र प्रति कल यो ढिलाइ बेवास्ता गर्न सकिने कुरा होइन।

प्रारम्भिकरण एक पटक मात्र भएको हुनुपर्छ र त्यसैले समाधानको खोजी php प्रयोग गरेर सेवा लेखेर सुरु भयो थ्रेडहरू। प्रयोगको एक हप्ता पछि, यो विस्तार कसरी काम गर्दछ भन्ने जटिलताहरूको कारणले गर्दा यो विकल्प सुरक्षित गरिएको थियो। एक महिनाको परीक्षण पछि, मैले PHP मा एसिन्क्रोनस प्रोग्रामिङ त्याग्नुपर्‍यो; मलाई केहि सरल चाहिन्छ, कुनै पनि PHP शुरुवातकर्तालाई परिचित छ, र PHP को लागि धेरै विस्तारहरू सिंक्रोनस छन्।

समाधान C मा हाम्रो आफ्नै बहु-थ्रेडेड सेवा थियो, जसको साथ कम्पाइल गरिएको थियो PHPLIB। यसले सबै ATS php फाइलहरू लोड गर्दछ, सबै मोड्युलहरू प्रारम्भ हुनको लागि पर्खन्छ, एक अर्कामा कलब्याक थप्छ, र जब सबै तयार हुन्छ, यसलाई क्यास गर्दछ। द्वारा सोधपुछ गर्दा फास्टाजी एउटा स्ट्रिम सिर्जना गरिएको छ, सबै वर्गहरूको क्यासबाट प्रतिलिपि बनाइएको छ र यसमा डेटा पुन: उत्पादन गरिन्छ, र अनुरोधलाई php प्रकार्यमा पास गरिन्छ।

यस समाधानको साथ, पहिलो आदेशमा हाम्रो सेवामा कल पठाउने समय Asterisk 1,5s बाट 0,05s मा घट्यो र यो समय परियोजना को आकार मा थोरै निर्भर गर्दछ।

नतिजाको रूपमा, डायलप्लान विकासको लागि समय महत्त्वपूर्ण रूपमा घटाइएको थियो, र म यसको कदर गर्न सक्छु किनकि मैले PHP मा सबै मोड्युलहरूको सम्पूर्ण डायलप्लान पुन: लेख्नुपर्‍यो। पहिलो, विधिहरू पहिले नै डाटाबेसबाट वस्तु प्राप्त गर्न php मा लेखिएको हुनुपर्छ; तिनीहरू वेब इन्टरफेसमा प्रदर्शनको लागि आवश्यक थियो, र दोस्रो, र यो मुख्य कुरा हो, यो अन्तमा संख्या र arrays संग स्ट्रिङ संग सजिलै संग काम गर्न सम्भव छ। डाटाबेस र धेरै PHP विस्तारहरूको साथ।

मोड्युल वर्गमा डायलप्लान प्रशोधन गर्न तपाईंले प्रकार्य कार्यान्वयन गर्न आवश्यक छ dialplanDynamicCall र तर्क pbxCallRequest अन्तरक्रिया गर्न वस्तु समावेश हुनेछ Asterisk.

थप रूपमा, यो डायलप्लान डिबग गर्न सम्भव भयो (php मा xdebug छ र यसले हाम्रो सेवाको लागि काम गर्दछ), तपाईं चरहरूको मानहरू हेरेर चरणबद्ध रूपमा सार्न सक्नुहुन्छ।

कल डाटा

कुनै पनि एनालिटिक्स र रिपोर्टहरूलाई सही रूपमा सङ्कलन गरिएको डाटा चाहिन्छ, र यो PBX ब्लक पनि पहिलो देखि तेस्रो संस्करणसम्म धेरै परीक्षण र त्रुटिहरूबाट गुज्र्यो। अक्सर, कल डाटा एक संकेत हो। एक कल = एक रेकर्डिङ: कसले बोलायो, ​​कसले जवाफ दियो, उनीहरूले कति लामो कुरा गरे। थप चाखलाग्दो विकल्पहरूमा, कलको समयमा कुन PBX कर्मचारीलाई कल गरिएको थियो भनेर संकेत गर्ने अतिरिक्त चिन्ह छ। तर यी सबैले आवश्यकताको अंश मात्र समेट्छ।

प्रारम्भिक आवश्यकताहरू थिए:

• PBX ले कसलाई बोलाएको मात्र होइन, कसले जवाफ दियो भनेर पनि बचाउनुहोस् त्यहाँ अवरोधहरू छन् र कलहरूको विश्लेषण गर्दा यसलाई ध्यानमा राख्न आवश्यक छ,
• एक कर्मचारी संग जडान गर्नु अघि समय। मा freepbx र केहि अन्य PBX हरू, PBX ले फोन उठाउने बित्तिकै कललाई जवाफ दिइन्छ। तर भ्वाइस मेनुको लागि तपाईंले पहिले नै फोन उठाउनु पर्छ, त्यसैले सबै कलहरू जवाफ दिइन्छ र जवाफको लागि प्रतीक्षा समय ०-१ सेकेन्ड हुन्छ। त्यसकारण, यो प्रतिक्रिया अघिको समय मात्र नभई कुञ्जी मोड्युलहरूसँग जडान गर्नु अघिको समय बचत गर्ने निर्णय गरियो (मोड्युलले यो झण्डा सेट गर्दछ। हाल यो "कर्मचारी", "बाह्य रेखा" हो),
• अधिक जटिल डायलप्लानको लागि, जब कल विभिन्न समूहहरू बीच यात्रा गर्दछ, प्रत्येक तत्वलाई अलग-अलग जाँच गर्न सक्षम हुनु आवश्यक थियो।

PBX मोड्युलहरूले कलहरूमा आफ्नो बारेमा जानकारी पठाउँदा र अन्ततः रूखको रूपमा जानकारी बचत गर्दा उत्तम विकल्प भयो।

यो यस्तो देखिन्छ:

पहिलो, कलको बारेमा सामान्य जानकारी (जस्तै सबैजना - विशेष केहि छैन)।

1. बाहिरको लाइनमा कल आयो "परीक्षणको लागि"05:55:52 मा नम्बर 89295671458 बाट नम्बर 89999999999 मा, अन्तमा यो एक कर्मचारी द्वारा जवाफ दिइयो"सचिव २» 104 नम्बरको साथ। ग्राहकले 60 सेकेन्ड पर्खनुभयो र 36 सेकेन्ड बोल्नुभयो।
2. कर्मचारी"सचिव २"112 मा कल गर्छ र एक कर्मचारीले जवाफ दिन्छ"प्रबन्धक १» 8 सेकेन्ड पछि। उनीहरु १४ सेकेन्डसम्म कुरा गर्छन् ।
3. ग्राहक कर्मचारीलाई हस्तान्तरण गरिएको छ "प्रबन्धक १"जहाँ तिनीहरूले अर्को 13 सेकेन्डको लागि कुरा जारी राख्छन्

तर यो आइसबर्गको टिप हो; प्रत्येक रेकर्डको लागि तपाईंले PBX ​​मार्फत विस्तृत कल इतिहास प्राप्त गर्न सक्नुहुन्छ।

सबै जानकारी कलहरूको नेस्टिंगको रूपमा प्रस्तुत गरिएको छ:

1. बाहिरको लाइनमा कल आयो "परीक्षणको लागि» ०५:५५:५२ मा ८९२९५६७१४५८ नम्बरबाट ८९९९९९९९९९९ सम्म।
2. ०५:५५:५३ मा बाहिरी रेखाले आगमन सर्किटमा कल पठाउँछ "परीक्षण»
3. योजना अनुसार कल प्रशोधन गर्दा, मोड्युल "प्रबन्धक कल", जसमा कल १६ सेकेन्डको हुन्छ। यो ग्राहकको लागि विकसित मोड्युल हो।
4. मोड्युल "प्रबन्धक कल"नम्बर (ग्राहक) को लागी जिम्मेवार कर्मचारीलाई कल पठाउँदछ"प्रबन्धक १"र प्रतिक्रियाको लागि 5 सेकेन्ड पर्खनुहोस्। प्रबन्धकले जवाफ दिएनन्।
5. मोड्युल "प्रबन्धक कल"समूहमा कल पठाउँछ"CORP प्रबन्धकहरू" यी उही दिशाका अन्य प्रबन्धकहरू हुन् (एउटै कोठामा बसेर) र प्रतिक्रियाको लागि 11 सेकेन्ड पर्खिरहेका छन्।
6. समूह "CORP प्रबन्धकहरू"कर्मचारीहरू बोलाउँछन्"प्रबन्धक १, प्रबन्धक १, प्रबन्धक १"एकै साथ 11 सेकेन्डको लागि। जवाफ छैन।
7. प्रबन्धकको कल समाप्त हुन्छ। र सर्किटले मोड्युलमा कल पठाउँछ "1c बाट मार्ग चयन गर्दै" ग्राहकको लागि लेखिएको मोड्युल पनि। यहाँ कल ० सेकेन्डको लागि प्रशोधन गरिएको थियो।
8. सर्किटले भ्वाइस मेनुमा कल पठाउँछ "अतिरिक्त डायलिङको साथ आधारभूत" ग्राहकले त्यहाँ 31 सेकेन्ड पर्खनुभयो, त्यहाँ कुनै अतिरिक्त डायलिङ थिएन।
9. योजनाले समूहलाई कल पठाउँछ "सचिवहरू", जहाँ ग्राहकले १२ सेकेन्ड पर्खनुभयो।
10. एक समूहमा, 2 कर्मचारी एकै समयमा बोलाइन्छ "सचिव २"र"सचिव २"र १२ सेकेन्ड पछि कर्मचारीले जवाफ दिन्छ"सचिव २" कलको जवाफ अभिभावक कलहरूमा डुप्लिकेट गरिएको छ। यो बाहिर जान्छ कि समूह मा उनले जवाफ दिए "सचिव २", सर्किटलाई फोन गर्दा जवाफ आयो "सचिव २"र बाहिरको लाइनमा कलको जवाफ दिनुभयो"सचिव २"।

यो प्रत्येक अपरेशन र तिनीहरूको नेस्टिङको बारेमा जानकारीको बचत हो जसले यसलाई केवल रिपोर्टहरू बनाउन सम्भव बनाउँदछ। भ्वाइस मेनुमा रहेको रिपोर्टले तपाईंलाई यसले कति मद्दत गर्छ वा अवरोध गर्छ भनी पत्ता लगाउन मद्दत गर्नेछ। कर्मचारीहरूले छुटेको कलको रिपोर्ट बनाउनुहोस्, कल इन्टरसेप्ट गरिएको थियो र त्यसैले मिस भएको मानिएको छैन, र यो समूह कल थियो भन्ने कुरालाई ध्यानमा राख्दै, र अरू कसैले पहिले जवाफ दियो, जसको मतलब कल पनि छुटेको थिएन।

यस्तो जानकारी भण्डारणले तपाइँलाई प्रत्येक समूहलाई अलग-अलग लिन र यसले कसरी प्रभावकारी रूपमा काम गर्दछ भनेर निर्धारण गर्न, र घण्टाको आधारमा जवाफ र छुटेका समूहहरूको ग्राफ निर्माण गर्न अनुमति दिन्छ। तपाईले प्रबन्धकसँग जडान गरेपछि स्थानान्तरणहरू विश्लेषण गरेर जिम्मेवार प्रबन्धकसँगको जडान कत्तिको सही छ भनेर जाँच गर्न सक्नुहुन्छ।

तपाईले धेरै असामान्य अध्ययनहरू पनि सञ्चालन गर्न सक्नुहुन्छ, उदाहरणका लागि, डाटाबेसमा नभएका नम्बरहरू कति पटक सही एक्सटेन्सन डायल गर्छन् वा बाहिर जाने कलहरूको कति प्रतिशत मोबाइल फोनमा फर्वार्ड गरिन्छ।

अन्तमा के भयो?

PBX कायम राख्न विशेषज्ञ आवश्यक छैन; सबैभन्दा साधारण प्रशासकले यो गर्न सक्छ - अभ्यासमा परीक्षण गरिएको।

परिमार्जनका लागि, गम्भीर योग्यता भएका विशेषज्ञहरू आवश्यक पर्दैन; PHP को ज्ञान पर्याप्त छ, किनभने मोड्युलहरू पहिले नै SIP प्रोटोकलको लागि लेखिएका छन्, र लामका लागि, र कर्मचारीलाई कल गर्नका लागि, र अन्य। को लागी एक र्यापर वर्ग छ Asterisk। मोड्युल विकास गर्न, एक प्रोग्रामरले (र राम्रो तरिकाले) रेडिमेड मोड्युलहरू कल गर्न सक्छ। र ज्ञान Asterisk यदि ग्राहकले केहि नयाँ रिपोर्टको साथ पृष्ठ थप्न सोध्छ भने पूर्ण रूपमा अनावश्यक छन्। तर अभ्यासले देखाउँछ कि यद्यपि तेस्रो-पक्ष प्रोग्रामरहरूले सामना गर्न सक्छन्, तिनीहरू कागजातहरू र टिप्पणीहरूको सामान्य कभरेज बिना असुरक्षित महसुस गर्छन्, त्यसैले सुधारको लागि अझै ठाउँ छ।

मोड्युलहरूले गर्न सक्छन्:

• नयाँ कल प्रशोधन क्षमताहरू सिर्जना गर्नुहोस्,
• वेब इन्टरफेसमा नयाँ ब्लकहरू थप्नुहोस्,
• कुनै पनि अवस्थित मोड्युलहरूबाट इनहेरिट गर्नुहोस्, प्रकार्यहरू पुन: परिभाषित गर्नुहोस् र यसलाई बदल्नुहोस्, वा थोरै परिमार्जित प्रतिलिपि बन्नुहोस्,
• अन्य मोड्युलहरूको सेटिङ टेम्प्लेटमा आफ्नो सेटिङहरू थप्नुहोस् र थप धेरै।

API मार्फत PBX सेटिङहरू। माथि वर्णन गरिए अनुसार, सबै सेटिङहरू डाटाबेसमा भण्डारण गरिन्छ र कलको समयमा पढिन्छ, त्यसैले तपाईंले API मार्फत सबै PBX सेटिङहरू परिवर्तन गर्न सक्नुहुन्छ। एपीआई कल गर्दा, कन्फिगरेसन पुन: सिर्जना गरिएको छैन र मोड्युलहरू पुन: सुरु हुँदैन, त्यसैले, तपाइँसँग कति सेटिङहरू र कर्मचारीहरू छन् भन्ने कुराले फरक पार्दैन। API अनुरोधहरू चाँडै कार्यान्वयन गरिन्छ र एक अर्कालाई रोक्दैन।

PBX ले अवधि (प्रतीक्षा/वार्तालाप), नेस्टिङ र PBX सर्तहरूमा (कर्मचारी, समूह, बाह्य रेखा, च्यानल, नम्बर होइन) कलहरू सहित सबै प्रमुख कार्यहरू भण्डारण गर्दछ। यसले तपाईंलाई विशिष्ट ग्राहकहरूको लागि विभिन्न रिपोर्टहरू निर्माण गर्न अनुमति दिन्छ र धेरै जसो काम प्रयोगकर्ता-अनुकूल इन्टरफेस सिर्जना गर्न हो।

अब के हुन्छ समयले बताउनेछ। त्यहाँ अझै धेरै सूक्ष्मताहरू छन् जुन पुन: गर्न आवश्यक छ, त्यहाँ अझै धेरै योजनाहरू छन्, तर तेस्रो संस्करणको सिर्जना भएको एक वर्ष बितिसकेको छ र हामी पहिले नै भन्न सक्छौं कि विचार काम गरिरहेको छ। संस्करण 3 को मुख्य हानि हार्डवेयर स्रोतहरू हो, तर यो सामान्यतया विकासको सहजताको लागि तपाईंले तिर्नु पर्ने कुरा हो।

स्रोत: www.habr.com