Η ιστορία ενός έργου ή πώς πέρασα 7 χρόνια δημιουργώντας ένα PBX βασισμένο σε Asterisk και Php

Σίγουρα πολλοί από εσάς, όπως εγώ, είχατε την ιδέα να κάνετε κάτι μοναδικό. Σε αυτό το άρθρο θα περιγράψω τα τεχνικά προβλήματα και τις λύσεις που έπρεπε να αντιμετωπίσω κατά την ανάπτυξη του PBX. Ίσως αυτό να βοηθήσει κάποιον να αποφασίσει για τη δική του ιδέα και κάποιον να ακολουθήσει τον καλοπατημένο δρόμο, γιατί ωφελήθηκα και εγώ από την εμπειρία των πρωτοπόρων.

Ιδέα και βασικές απαιτήσεις

Και όλα ξεκίνησαν απλά με αγάπη για Αστερίσκος (πλαίσιο κτιρίου εφαρμογών επικοινωνίας), αυτοματοποίηση τηλεφωνίας και εγκαταστάσεων freepbx (διασύνδεση ιστού για Αστερίσκος). Εάν οι ανάγκες της εταιρείας ήταν χωρίς ιδιαιτερότητες και εμπίπτουν στις δυνατότητες freepbx - όλα είναι υπέροχα. Η όλη εγκατάσταση πραγματοποιήθηκε εντός XNUMX ωρών, η εταιρεία έλαβε ένα διαμορφωμένο PBX, μια φιλική προς το χρήστη διεπαφή και σύντομη εκπαίδευση και υποστήριξη εάν το επιθυμείτε.

Αλλά οι πιο ενδιαφέρουσες εργασίες ήταν μη τυποποιημένες και τότε δεν ήταν τόσο φανταστικές. Αστερίσκος μπορεί να κάνει πολλά, αλλά για να διατηρηθεί η διεπαφή ιστού σε κατάσταση λειτουργίας, ήταν απαραίτητο να αφιερώσετε πολλές φορές περισσότερο χρόνο. Έτσι, μια μικρή λεπτομέρεια θα μπορούσε να διαρκέσει πολύ περισσότερο από την εγκατάσταση του υπόλοιπου PBX. Και το θέμα δεν είναι ότι χρειάζεται πολύς χρόνος για να γραφτεί μια διεπαφή ιστού, αλλά μάλλον στα αρχιτεκτονικά χαρακτηριστικά freepbx. Αρχιτεκτονικές προσεγγίσεις και μέθοδοι freepbx είχε σχεδιαστεί την εποχή του php4 και εκείνη τη στιγμή υπήρχε ήδη το php5.6 στο οποίο όλα μπορούσαν να γίνουν πιο απλά και πιο βολικά.

Η σταγόνα που ξεχείλισε το ποτήρι ήταν τα γραφικά σχέδια με τη μορφή διαγράμματος. Όταν προσπάθησα να φτιάξω κάτι τέτοιο για freepbx, συνειδητοποίησα ότι θα έπρεπε να το ξαναγράψω σημαντικά και θα ήταν πιο εύκολο να φτιάξω κάτι νέο.

Οι βασικές απαιτήσεις ήταν:

• απλή εγκατάσταση, διαισθητικά προσβάσιμη ακόμη και σε έναν αρχάριο διαχειριστή. Έτσι, οι εταιρείες δεν απαιτούν συντήρηση PBX από την πλευρά μας,
• εύκολη τροποποίηση έτσι ώστε οι εργασίες να επιλύονται σε επαρκή χρόνο,
• ευκολία ενσωμάτωσης με το PBX. U freepbx δεν υπήρχε API για αλλαγή ρυθμίσεων, π.χ. Δεν μπορείτε, για παράδειγμα, να δημιουργήσετε ομάδες ή φωνητικά μενού από μια εφαρμογή τρίτου κατασκευαστή, μόνο από το ίδιο το API Αστερίσκος,
• opensource - για προγραμματιστές αυτό είναι εξαιρετικά σημαντικό για τροποποιήσεις για τον πελάτη.

Η ιδέα της ταχύτερης ανάπτυξης ήταν όλη η λειτουργικότητα να αποτελείται από ενότητες με τη μορφή αντικειμένων. Όλα τα αντικείμενα έπρεπε να έχουν μια κοινή γονική κλάση, που σημαίνει ότι τα ονόματα όλων των κύριων συναρτήσεων είναι ήδη γνωστά και επομένως υπάρχουν ήδη προεπιλεγμένες υλοποιήσεις. Τα αντικείμενα θα σας επιτρέψουν να μειώσετε δραματικά τον αριθμό των ορισμάτων με τη μορφή συσχετιστικών πινάκων με πλήκτρα συμβολοσειρών, τα οποία μπορείτε να βρείτε στο freepbx Ήταν δυνατό με την εξέταση ολόκληρης της συνάρτησης και των ένθετων συναρτήσεων. Στην περίπτωση των αντικειμένων, η απλή αυτόματη συμπλήρωση θα εμφανίσει όλες τις ιδιότητες και γενικά θα απλοποιήσει τη ζωή πολλές φορές. Επιπλέον, η κληρονομικότητα και ο επαναπροσδιορισμός λύνουν ήδη πολλά προβλήματα με τροποποιήσεις.

Το επόμενο πράγμα που επιβράδυνε τον χρόνο επανάληψης και άξιζε να αποφευχθεί ήταν η επανάληψη. Εάν υπάρχει μια ενότητα που είναι υπεύθυνη για την κλήση ενός υπαλλήλου, τότε όλες οι άλλες μονάδες που πρέπει να στείλουν μια κλήση σε έναν υπάλληλο θα πρέπει να το χρησιμοποιήσουν και όχι να δημιουργήσουν τα δικά τους αντίγραφα. Έτσι, εάν πρέπει να αλλάξετε κάτι, τότε θα πρέπει να αλλάξετε μόνο σε ένα μέρος και η αναζήτηση για το "πώς λειτουργεί" θα πρέπει να πραγματοποιείται σε ένα μέρος και όχι σε όλο το έργο.

Πρώτη έκδοση και πρώτα λάθη

Το πρώτο πρωτότυπο ήταν έτοιμο μέσα σε ένα χρόνο. Ολόκληρο το 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__); //Подменить существующий модуль

Οι πρώτες πολύπλοκες υλοποιήσεις έφεραν το πρώτο καμάρι και τις πρώτες απογοητεύσεις. Χάρηκα που λειτούργησε, που ήμουν ήδη σε θέση να αναπαράγω τα κύρια χαρακτηριστικά freepbx. Χάρηκα που άρεσε στον κόσμο η ιδέα του σχεδίου. Υπήρχαν ακόμη πολλές επιλογές για την απλούστευση της ανάπτυξης, αλλά ακόμη και εκείνη την εποχή κάποιες από τις εργασίες είχαν ήδη γίνει ευκολότερες.

Το API για την αλλαγή της διαμόρφωσης του PBX ήταν μια απογοήτευση - το αποτέλεσμα δεν ήταν καθόλου αυτό που θέλαμε. Ακολούθησα την ίδια αρχή όπως στο freepbx, κάνοντας κλικ στο κουμπί Εφαρμογή, δημιουργείται εκ νέου ολόκληρη η διαμόρφωση και επανεκκινούνται οι μονάδες.

Μοιάζει με αυτό:

*Το Dialplan είναι ένας κανόνας (αλγόριθμος) με τον οποίο επεξεργάζεται μια κλήση.

Αλλά με αυτήν την επιλογή, είναι αδύνατο να γράψετε ένα κανονικό API για την αλλαγή των ρυθμίσεων του PBX. Πρώτον, η λειτουργία της εφαρμογής αλλαγών σε Αστερίσκος υπερβολικά μεγάλου μήκους και έντασης πόρων.
Δεύτερον, δεν μπορείτε να καλέσετε δύο συναρτήσεις ταυτόχρονα, γιατί και τα δύο θα δημιουργήσουν τη διαμόρφωση.
Τρίτον, εφαρμόζει όλες τις ρυθμίσεις, συμπεριλαμβανομένων εκείνων που έγιναν από τον διαχειριστή.

Σε αυτή την έκδοση, όπως και στο Ασκόζια, ήταν δυνατή η δημιουργία της διαμόρφωσης μόνο των αλλαγμένων λειτουργικών μονάδων και η επανεκκίνηση μόνο των απαραίτητων λειτουργικών μονάδων, αλλά όλα αυτά είναι ημίμετρα. Ήταν απαραίτητο να αλλάξει η προσέγγιση.

Δεύτερη έκδοση. Μύτη βγαλμένη ουρά κολλημένη

Η ιδέα για την επίλυση του προβλήματος δεν ήταν να αναδημιουργηθεί η διαμόρφωση και το σχέδιο κλήσης για Αστερίσκος, αλλά αποθηκεύστε πληροφορίες στη βάση δεδομένων και διαβάστε απευθείας από τη βάση δεδομένων κατά την επεξεργασία της κλήσης. Αστερίσκος Ήξερα ήδη πώς να διαβάζω διαμορφώσεις από τη βάση δεδομένων, απλώς αλλάξτε την τιμή στη βάση δεδομένων και η επόμενη κλήση θα διεκπεραιωθεί λαμβάνοντας υπόψη τις αλλαγές και η λειτουργία ήταν τέλεια για την ανάγνωση παραμέτρων σχεδίου κλήσης 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 διαμόρφωσης. Θα μπορούσατε ακόμη και να μεταβείτε απευθείας στη βάση δεδομένων και να προσθέσετε μια νέα ομάδα ή να αλλάξετε, για παράδειγμα, τον χρόνο κλήσης στο πεδίο "ώρα κλήσης" για την ομάδα και η επόμενη κλήση θα διαρκούσε ήδη τον καθορισμένο χρόνο (Αυτό δεν αποτελεί σύσταση για ενέργεια, δεδομένου ότι ορισμένες λειτουργίες 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 έγινε καθολικό, περιλάμβανε όλες τις πιθανές επιλογές επεξεργασίας ανάλογα με τις παραμέτρους και το μέγεθός του αυξήθηκε σημαντικά. Όλα αυτά επιβράδυναν πολύ τον χρόνο ανάπτυξης και η ίδια η σκέψη ότι για άλλη μια φορά ήταν απαραίτητο να παρέμβω στο σχέδιο κλήσης με λυπήθηκε.

Τρίτη έκδοση

Η ιδέα να λυθεί το πρόβλημα δεν ήταν να δημιουργήσει Αστερίσκος dialplan από php και χρήση FastAGI και γράψτε όλους τους κανόνες επεξεργασίας στην ίδια την PHP. FastAGI позволяет Αστερίσκος, για να επεξεργαστείτε την κλήση, συνδεθείτε στην πρίζα. Λάβετε εντολές από εκεί και στείλτε αποτελέσματα. Έτσι, η λογική του σχεδίου κλήσης βρίσκεται ήδη έξω από τα όρια Αστερίσκος και μπορεί να γραφτεί σε οποιαδήποτε γλώσσα, στην περίπτωσή μου σε PHP.

Υπήρχαν πολλές δοκιμές και λάθη. Το κύριο πρόβλημα ήταν ότι είχα ήδη πολλές τάξεις/αρχεία. Χρειάστηκε περίπου 1,5 δευτερόλεπτο για να δημιουργηθούν αντικείμενα, να αρχικοποιηθούν και να καταχωρηθούν μεταξύ τους και αυτή η καθυστέρηση ανά κλήση δεν είναι κάτι που μπορεί να αγνοηθεί.

Η αρχικοποίηση θα έπρεπε να είχε γίνει μόνο μία φορά και επομένως η αναζήτηση λύσης ξεκίνησε με τη σύνταξη μιας υπηρεσίας σε php χρησιμοποιώντας Κλωστές. Μετά από μια εβδομάδα πειραματισμού, αυτή η επιλογή τέθηκε στο ράφι λόγω των περιπλοκών του τρόπου λειτουργίας αυτής της επέκτασης. Μετά από ένα μήνα δοκιμών, έπρεπε επίσης να εγκαταλείψω τον ασύγχρονο προγραμματισμό στην PHP· χρειαζόμουν κάτι απλό, οικείο σε κάθε αρχάριο PHP και πολλές επεκτάσεις για την PHP είναι σύγχρονες.

Η λύση ήταν η δική μας υπηρεσία πολλαπλών νημάτων στο C, με την οποία έγινε μεταγλώττιση PHPLIB. Φορτώνει όλα τα αρχεία php ATS, περιμένει να αρχικοποιηθούν όλα τα modules, προσθέτει μια επανάκληση μεταξύ τους και όταν όλα είναι έτοιμα, τα αποθηκεύει προσωρινά. Όταν ρωτάτε από FastAGI δημιουργείται μια ροή, ένα αντίγραφο από την κρυφή μνήμη όλων των κλάσεων και τα δεδομένα αναπαράγονται σε αυτήν και το αίτημα περνά στη συνάρτηση php.

Με αυτή τη λύση, ο χρόνος από την αποστολή κλήσης στην υπηρεσία μας μέχρι την πρώτη εντολή Αστερίσκος μειώθηκε από 1,5s σε 0,05s και αυτός ο χρόνος εξαρτάται ελαφρώς από το μέγεθος του έργου.

Ως αποτέλεσμα, ο χρόνος για την ανάπτυξη του σχεδίου κλήσης μειώθηκε σημαντικά και μπορώ να το εκτιμήσω αυτό, καθώς έπρεπε να ξαναγράψω ολόκληρο το σχέδιο κλήσης όλων των μονάδων στην PHP. Πρώτον, οι μέθοδοι θα πρέπει να είναι ήδη γραμμένες σε php για τη λήψη ενός αντικειμένου από τη βάση δεδομένων· χρειάζονταν για εμφάνιση στη διεπαφή ιστού και, δεύτερον, και αυτό είναι το κύριο πράγμα, είναι επιτέλους δυνατή η εύκολη εργασία με συμβολοσειρές με αριθμούς και πίνακες με βάση δεδομένων συν πολλές επεκτάσεις PHP.

Για να επεξεργαστείτε το σχέδιο κλήσης στην κλάση ενότητας, πρέπει να εφαρμόσετε τη συνάρτηση dialplanDynamicCall και επιχείρημα pbxCallRequest θα περιέχει ένα αντικείμενο για αλληλεπίδραση Αστερίσκος.

Επιπλέον, κατέστη δυνατός ο εντοπισμός σφαλμάτων του σχεδίου κλήσης (το php έχει xdebug και λειτουργεί για την υπηρεσία μας), μπορείτε να μετακινηθείτε βήμα προς βήμα προβάλλοντας τις τιμές των μεταβλητών.

Δεδομένα κλήσεων

Οποιεσδήποτε αναλύσεις και αναφορές απαιτούν δεδομένα που συλλέγονται σωστά και αυτό το μπλοκ PBX πέρασε επίσης από πολλές δοκιμές και σφάλματα από την πρώτη έως την τρίτη έκδοση. Συχνά, τα δεδομένα κλήσεων είναι σημάδι. Μία κλήση = μία ηχογράφηση: ποιος τηλεφώνησε, ποιος απάντησε, πόση ώρα μίλησαν. Σε πιο ενδιαφέρουσες επιλογές, υπάρχει μια πρόσθετη πινακίδα που υποδεικνύει ποιος υπάλληλος PBX κλήθηκε κατά τη διάρκεια της κλήσης. Όλα αυτά όμως καλύπτουν μέρος μόνο των αναγκών.

Οι αρχικές απαιτήσεις ήταν:

• εκτός από ποιον κάλεσε το PBX, αλλά και ποιος απάντησε, γιατί υπάρχουν υποκλοπές και αυτό θα πρέπει να λαμβάνεται υπόψη κατά την ανάλυση κλήσεων,
• χρόνο πριν συνδεθείτε με έναν υπάλληλο. Σε freepbx και κάποια άλλα 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