ერთი პროექტის ისტორია ან როგორ გავატარე 7 წელი PBX-ის შექმნაზე Asterisk-ზე და Php-ზე

რა თქმა უნდა, ბევრ თქვენგანს, ჩემსავით, ჰქონდა იდეა, გაეკეთებინა რაიმე უნიკალური. ამ სტატიაში მე აღვწერ ტექნიკურ პრობლემებსა და გადაწყვეტილებებს, რომელთა წინაშეც მომიწია PBX-ის შემუშავებისას. შესაძლოა, ეს ვინმეს დაეხმარება გადაწყვიტოს საკუთარი იდეა და ვიღაცას გავლილი გზა გაუყვეს, რადგან მეც ვისარგებლე პიონერების გამოცდილებით.

იდეა და ძირითადი მოთხოვნები

და ეს ყველაფერი უბრალოდ სიყვარულით დაიწყო ასტერიქსი (საკომუნიკაციო აპლიკაციების მშენებლობის ჩარჩო), ტელეფონისა და დანადგარების ავტომატიზაცია უფასოPBX (ვებ ინტერფეისი ასტერიქსი). თუ კომპანიის საჭიროებები იყო სპეციფიკის გარეშე და შედიოდა შესაძლებლობებში უფასოPBX - ყველაფერი მშვენიერია. მთელი ინსტალაცია განხორციელდა XNUMX საათის განმავლობაში, კომპანიამ მიიღო კონფიგურირებული PBX, მოსახერხებელი ინტერფეისი და მოკლე ტრენინგი და სურვილის შემთხვევაში მხარდაჭერა.

მაგრამ ყველაზე საინტერესო ამოცანები იყო არასტანდარტული და მაშინ არც ისე ზღაპრული იყო. ასტერიქსი ბევრი რამის გაკეთება შეუძლია, მაგრამ ვებ ინტერფეისის მუშა მდგომარეობაში შესანარჩუნებლად საჭირო იყო ბევრჯერ მეტი დროის დახარჯვა. ასე რომ, მცირე დეტალს შეიძლება გაცილებით მეტი დრო დასჭირდეს, ვიდრე დანარჩენი PBX-ის დაყენება. და საქმე ის კი არ არის, რომ ვებ ინტერფეისის დაწერას დიდი დრო სჭირდება, არამედ საქმე არქიტექტურულ მახასიათებლებშია. უფასოPBX. არქიტექტურის მიდგომები და მეთოდები უფასოPBX განლაგებული იყო php4-ის დროს და იმ მომენტში უკვე იყო php5.6, რომელზეც ყველაფერი უფრო მარტივი და მოსახერხებელი იყო.

ბოლო წვეთი იყო გრაფიკული აკრიფეთ გეგმები დიაგრამის სახით. როდესაც ვცდილობდი მსგავსი რამის აშენებას უფასოPBX, მივხვდი, რომ საგრძნობლად მომიწევდა მისი გადაწერა და ახლის აშენება უფრო ადვილი იქნებოდა.

ძირითადი მოთხოვნები იყო:

• მარტივი დაყენება, ინტუიციურად ხელმისაწვდომი დამწყები ადმინისტრატორისთვისაც კი. ამრიგად, კომპანიებს არ სჭირდებათ PBX-ის მოვლა ჩვენი მხრიდან,
• მარტივი მოდიფიკაცია ისე, რომ ამოცანები გადაწყდეს ადეკვატურ დროში,
• PBX-თან ინტეგრაციის სიმარტივე. უ უფასოPBX არ იყო API პარამეტრების შესაცვლელად, ე.ი. თქვენ არ შეგიძლიათ, მაგალითად, შექმნათ ჯგუფები ან ხმოვანი მენიუები მესამე მხარის აპლიკაციიდან, მხოლოდ თავად API ასტერიქსი,
• opensource - პროგრამისტებისთვის ეს ძალიან მნიშვნელოვანია კლიენტისთვის ცვლილებებისთვის.

უფრო სწრაფი განვითარების იდეა იყო, რომ ყველა ფუნქციონირება მოდულისგან შედგებოდეს ობიექტების სახით. ყველა ობიექტს უნდა ჰქონდეს საერთო მშობელი კლასი, რაც ნიშნავს, რომ ყველა ძირითადი ფუნქციის სახელები უკვე ცნობილია და, შესაბამისად, უკვე არსებობს ნაგულისხმევი განხორციელება. ობიექტები საშუალებას მოგცემთ მკვეთრად შეამციროთ არგუმენტების რაოდენობა ასოციაციური მასივების სახით სიმებიანი კლავიშებით, რაც შეგიძლიათ გაიგოთ უფასო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-ის დაწერა. პირველი, ცვლილებების გამოყენების ოპერაცია ასტერიქსი ძალიან გრძელი და რესურსი ინტენსიური.
მეორეც, თქვენ არ შეგიძლიათ ერთდროულად გამოიძახოთ ორი ფუნქცია, რადგან ორივე შექმნის კონფიგურაციას.
მესამე, ის იყენებს ყველა პარამეტრს, მათ შორის ადმინისტრატორის მიერ დაყენებულ პარამეტრებს.

ამ ვერსიაში, როგორც ასკოზია, შესაძლებელი იყო მხოლოდ შეცვლილი მოდულების კონფიგურაციის გენერირება და მხოლოდ საჭირო მოდულების გადატვირთვა, მაგრამ ეს ყველაფერი ნახევარი ზომაა. საჭირო იყო მიდგომის შეცვლა.

მეორე ვერსია. ცხვირი გამოყვანილი კუდი ჩარჩა

პრობლემის გადაჭრის იდეა არ იყო კონფიგურაციისა და აკრიფეთ გეგმის ხელახლა შექმნა ასტერიქსი, მაგრამ შეინახეთ ინფორმაცია მონაცემთა ბაზაში და წაიკითხეთ უშუალოდ მონაცემთა ბაზიდან ზარის დამუშავებისას. ასტერიქსი მე უკვე ვიცოდი, როგორ წავიკითხო კონფიგურაციები მონაცემთა ბაზიდან, უბრალოდ შეცვალეთ მნიშვნელობა მონაცემთა ბაზაში და შემდეგი ზარი დამუშავდება ცვლილებების გათვალისწინებით და ფუნქცია შესანიშნავი იყო აკრიფეთ გეგმის პარამეტრების წასაკითხად 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)
...

თქვენ შეგიძლიათ მარტივად დაამატოთ ან შეცვალოთ ხაზი აკრიფეთ გეგმაში გამოყენებით Ami (კონტროლის ინტერფეისი ასტერიქსი) და არ არის საჭირო მთელი ციფრული გეგმის გადატვირთვა.

ამან გადაჭრა პრობლემა კონფიგურაციის API-სთან დაკავშირებით. თქვენ შეგიძლიათ პირდაპირ შეხვიდეთ მონაცემთა ბაზაში და დაამატოთ ახალი ჯგუფი ან შეცვალოთ, მაგალითად, ჯგუფის ველში dial-up დრო და შემდეგი ზარი უკვე გაგრძელდება მითითებულ დროს (ეს არ არის რეკომენდაცია მოქმედება, რადგან ზოგიერთი API ოპერაცია მოითხოვს Ami ზარები).

პირველმა რთულმა განხორციელებამ კვლავ მოიტანა პირველი სიამაყე და იმედგაცრუება. გამიხარდა, რომ მუშაობდა. მონაცემთა ბაზა გახდა კრიტიკული ბმული, გაიზარდა დისკზე დამოკიდებულება, მეტი რისკი იყო, მაგრამ ყველაფერი მუშაობდა სტაბილურად და უპრობლემოდ. და რაც მთავარია, ახლა ყველაფერი, რისი გაკეთებაც შესაძლებელი იყო ვებ-ინტერფეისის მეშვეობით, შეიძლებოდა API-ის საშუალებით და იგივე მეთოდები გამოიყენებოდა. გარდა ამისა, ვებ ინტერფეისმა მოიშორა ღილაკი „პარამეტრების გამოყენება PBX-ზე“, რასაც ადმინისტრატორები ხშირად ივიწყებდნენ.

იმედგაცრუება ის იყო, რომ განვითარება უფრო გართულდა. პირველი ვერსიიდან მოყოლებული, 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'))

მეორე ვერსიაში 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-მა, არამედ ვინ უპასუხა, რადგან არის მოსმენები და ეს გასათვალისწინებელია ზარების გაანალიზებისას,
• თანამშრომელთან დაკავშირებამდე დრო. In უფასო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 პროტოკოლისთვის, რიგისთვის, თანამშრომლის გამოძახებისთვის და სხვა. ამისთვის არის შეფუთვის კლასი ასტერიქსი. მოდულის შესაქმნელად, პროგრამისტს შეუძლია (და კარგი თვალსაზრისით უნდა) გამოძახება მზა მოდულები. და ცოდნა ასტერიქსი სრულიად არასაჭიროა, თუ კლიენტი ითხოვს გვერდის დამატებას ახალი ანგარიშით. მაგრამ პრაქტიკა გვიჩვენებს, რომ მიუხედავად იმისა, რომ მესამე მხარის პროგრამისტებს შეუძლიათ გაუმკლავდნენ, ისინი თავს დაუცველად გრძნობენ დოკუმენტაციისა და კომენტარების ნორმალური გაშუქების გარეშე, ამიტომ გაუმჯობესების ადგილი ჯერ კიდევ არსებობს.

მოდულებს შეუძლიათ:

• ზარის დამუშავების ახალი შესაძლებლობების შექმნა,
• დაამატეთ ახალი ბლოკები ვებ ინტერფეისში,
• მემკვიდრეობა რომელიმე არსებული მოდულიდან, ხელახლა განსაზღვრეთ ფუნქციები და შეცვალეთ იგი, ან უბრალოდ იყოს ოდნავ შეცვლილი ასლი,
• დაამატეთ თქვენი პარამეტრები სხვა მოდულების პარამეტრების შაბლონში და მრავალი სხვა.

PBX პარამეტრები API-ის საშუალებით. როგორც ზემოთ იყო აღწერილი, ყველა პარამეტრი ინახება მონაცემთა ბაზაში და იკითხება ზარის დროს, ასე რომ თქვენ შეგიძლიათ შეცვალოთ ყველა PBX პარამეტრი API-ს მეშვეობით. API-ს გამოძახებისას, კონფიგურაცია არ ხელახლა იქმნება და მოდულები არ გადაიტვირთება, შესაბამისად, არ აქვს მნიშვნელობა რამდენი პარამეტრი და თანამშრომელი გყავთ. API მოთხოვნები სწრაფად სრულდება და არ ბლოკავს ერთმანეთს.

PBX ინახავს ყველა საკვანძო ოპერაციებს ზარებით ხანგრძლივობით (ლოდინი/საუბარი), ბუდობრივი და PBX-ის ტერმინებით (თანამშრომლები, ჯგუფი, გარე ხაზი, არა არხი, ნომერი). ეს საშუალებას გაძლევთ შექმნათ სხვადასხვა ანგარიშები კონკრეტული კლიენტებისთვის და სამუშაოს უმეტესი ნაწილი არის მოსახერხებელი ინტერფეისის შექმნა.

დრო გვიჩვენებს, რა მოხდება შემდეგ. ჯერ კიდევ ბევრი ნიუანსია, რაც გადაკეთებას საჭიროებს, ჯერ კიდევ ბევრი გეგმაა, მაგრამ მე-3 ვერსიის შექმნიდან ერთი წელი გავიდა და უკვე შეგვიძლია ვთქვათ, რომ იდეა მუშაობს. მე-3 ვერსიის მთავარი მინუსი არის ტექნიკის რესურსები, მაგრამ ეს არის ის, რისი გადახდაც თქვენ უნდა გადაიხადოთ განვითარების სიმარტივისთვის.

წყარო: www.habr.com