הסיפור של פרויקט אחד או איך ביליתי 7 שנים ביצירת מרכזיה המבוססת על כוכבית ו- Php

אין ספק לרבים מכם, כמוני, היה רעיון לעשות משהו ייחודי. במאמר זה אתאר את הבעיות והפתרונות הטכניים שהייתי צריך להתמודד איתם בעת פיתוח המרכזיה. אולי זה יעזור למישהו להחליט על רעיון משלו, ולמישהו ללכת בדרך המכות, כי גם אני הרווחתי מניסיונם של חלוצים.

רעיון ודרישות מפתח

והכל התחיל פשוט מאהבה ל כוכבית (מסגרת לבניית אפליקציות תקשורת), אוטומציה של טלפוניה והתקנות FreePBX (ממשק אינטרנט עבור כוכבית). אם צרכי החברה היו חסרי פרטים ונפלו במסגרת היכולות FreePBX - הכל מצויין. כל ההתקנה התבצעה תוך XNUMX שעות, החברה קיבלה מרכזיה מוגדרת, ממשק ידידותי והדרכה קצרה בתוספת תמיכה אם תרצה.

אבל המשימות המעניינות ביותר היו לא סטנדרטיות ואז זה לא היה כל כך מדהים. כוכבית יכול לעשות הרבה, אבל כדי לשמור על תקינות ממשק האינטרנט, היה צורך להשקיע הרבה פעמים יותר זמן. אז פרט קטן יכול לקחת הרבה יותר זמן מהתקנת שאר המרכזייה. והנקודה היא לא שלוקח הרבה זמן לכתוב ממשק אינטרנט, אלא הנקודה היא בתכונות הארכיטקטוניות FreePBX. גישות ושיטות אדריכלות FreePBX היה מונח בזמן php4, ובאותו רגע כבר היה php5.6 שעליו אפשר היה לעשות הכל פשוט ונוח יותר.

הקש האחרון היה תוכניות חיוג גרפיות בצורה של דיאגרמה. כשניסיתי לבנות משהו כזה בשביל FreePBX, הבנתי שאצטרך לשכתב אותו באופן משמעותי ויהיה קל יותר לבנות משהו חדש.

הדרישות העיקריות היו:

• הגדרה פשוטה, נגישה באופן אינטואיטיבי אפילו למנהל מערכת מתחיל. לפיכך, חברות אינן דורשות תחזוקה של מרכזיות מהצד שלנו,
• שינוי קל כדי שהמשימות ייפתרו בזמן הולם,
• קלות אינטגרציה עם מרכזיה. U FreePBX לא היה API לשינוי הגדרות, כלומר. אתה לא יכול, למשל, ליצור קבוצות או תפריטים קוליים מאפליקציה של צד שלישי, רק ה-API עצמו כוכבית,
• opensource - עבור מתכנתים זה חשוב ביותר עבור שינויים עבור הלקוח.

הרעיון של פיתוח מהיר יותר היה שכל הפונקציונליות תהיה מורכבת ממודולים בצורת אובייקטים. לכל האובייקטים היה צריך להיות מחלקת אב משותפת, כלומר השמות של כל הפונקציות העיקריות כבר ידועות ולכן יש כבר יישומי ברירת מחדל. אובייקטים יאפשרו לך להפחית באופן דרמטי את מספר הארגומנטים בצורה של מערכים אסוציאטיביים עם מקשי מחרוזת, אותם תוכל לגלות ב FreePBX זה היה אפשרי על ידי בחינת הפונקציה כולה ופונקציות מקוננות. במקרה של אובייקטים, השלמה אוטומטית בנאלית תציג את כל המאפיינים, ובאופן כללי תפשט את החיים פי כמה. בנוסף, ירושה והגדרה מחדש כבר פותרים בעיות רבות עם שינויים.

הדבר הבא שהאט את זמן העבודה מחדש ושווה להימנע ממנו היה כפילות. אם יש מודול שאחראי לחיוג לעובד, אז כל המודולים האחרים שצריכים לשלוח שיחה לעובד צריכים להשתמש בו, ולא ליצור עותקים משלהם. לכן, אם אתה צריך לשנות משהו, אז תצטרך לשנות רק במקום אחד ואת החיפוש אחר "איך זה עובד" צריך להתבצע במקום אחד, ולא לחפש לאורך כל הפרויקט.

גרסה ראשונה ושגיאות ראשונות

אב הטיפוס הראשון היה מוכן תוך שנה. המרכזיה כולה, כמתוכנן, הייתה מודולרית, והמודולים יכלו לא רק להוסיף פונקציונליות חדשה לעיבוד שיחות, אלא גם לשנות את ממשק האינטרנט עצמו.

כן, הרעיון של בניית תכנית חיוג בצורה של תכנית כזו הוא לא שלי, אבל הוא מאוד נוח ועשיתי אותו דבר עבור כוכבית.

על ידי כתיבת מודול, מתכנתים כבר יכלו:

• צור פונקציונליות משלך לעיבוד שיחות, שניתן למקם בתרשים, כמו גם בתפריט האלמנטים משמאל,
• צור דפים משלך עבור ממשק האינטרנט והוסף את התבניות שלך לדפים קיימים (אם מפתח הדפים סיפק זאת),
• הוסף את ההגדרות שלך ללשונית ההגדרות הראשית או צור כרטיסיית הגדרות משלך,
• המתכנת יכול לרשת ממודול קיים, לשנות חלק מהפונקציונליות ולרשום אותו בשם חדש או להחליף את המודול המקורי.

לדוגמה, כך תוכל ליצור תפריט קולי משלך:

......
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 רגיל לשינוי הגדרות המרכזיה. ראשית, פעולת החלת שינויים ב כוכבית ארוך מדי ועתיר משאבים.
שנית, אתה לא יכול לקרוא לשתי פונקציות בו-זמנית, כי שניהם ייצרו את התצורה.
שלישית, הוא מחיל את כל ההגדרות, כולל אלה שנעשו על ידי המנהל.

בגרסה זו, כמו ב אסקוזיה, ניתן היה ליצור את התצורה של מודולים שהשתנו בלבד ולהפעיל מחדש רק את המודולים הדרושים, אבל כל אלה הם חצי אמצעים. היה צורך לשנות את הגישה.

גרסה שניה. האף שנשלף תקוע

הרעיון לפתור את הבעיה היה לא ליצור מחדש את התצורה ותוכנית החיוג עבור כוכבית, אך שמור מידע במסד הנתונים וקראה ממסד הנתונים ישירות תוך כדי עיבוד השיחה. כוכבית כבר ידעתי לקרוא תצורות מהמסד, פשוט שנה את הערך במסד הנתונים והקריאה הבאה תעובד תוך התחשבות בשינויים, והפונקציה הייתה מושלמת לקריאת פרמטרי 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 של התצורה. אתה יכול אפילו להיכנס ישירות למסד הנתונים ולהוסיף קבוצה חדשה או לשנות, למשל, את זמן החיוג בשדה "זמן חיוג" לקבוצה והשיחה הבאה כבר תימשך את הזמן שצוין (זו לא המלצה עבור פעולה, מכיוון שחלק מפעולות API דורשות עמי שיחות).

המימושים הקשים הראשונים הביאו שוב את הגאווה והאכזבה הראשונה. שמחתי שזה עבד. בסיס הנתונים הפך לקישור קריטי, התלות בדיסק גדלה, היו יותר סיכונים, אבל הכל עבד ביציבות וללא בעיות. והכי חשוב, עכשיו כל מה שאפשר לעשות דרך ממשק האינטרנט יכול להיעשות דרך ה-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 היא מאפשרת כוכבית, כדי לעבד את השיחה, התחבר לשקע. קבל פקודות משם ושלח תוצאות. לפיכך, ההיגיון של ה-dialplan כבר מחוץ לגבולות כוכבית וניתן לכתוב בכל שפה, במקרה שלי ב-PHP.

היו הרבה ניסוי וטעייה. הבעיה העיקרית הייתה שכבר היו לי הרבה שיעורים/קבצים. לקח בערך 1,5 שניות ליצור אובייקטים, לאתחל אותם ולרשום אחד את השני, וההשהיה הזו לכל שיחה היא לא משהו שאפשר להתעלם ממנו.

אתחול היה צריך לקרות רק פעם אחת ולכן החיפוש אחר פתרון התחיל בכתיבת שירות ב-php באמצעות Pthreads. לאחר שבוע של ניסויים, אפשרות זו נגנזה בשל המורכבויות של אופן פעולת ההרחבה הזו. לאחר חודש של בדיקות, נאלצתי גם לנטוש את התכנות האסינכרוני ב-PHP; הייתי צריך משהו פשוט, מוכר לכל מתחיל ב-PHP, והרחבות רבות עבור PHP הן סינכרוניות.

הפתרון היה שירות מרובה הליכי משלנו ב-C, שהורכב איתו PHPLIB. הוא טוען את כל קבצי ה-PHP של ATS, ממתין לאתחול כל המודולים, מוסיף התקשרות חוזרת זה לזה, וכשהכל מוכן, מאחסן אותו במטמון. כאשר מבררים על ידי FastAGI נוצר זרם, עותק מהמטמון של כל המחלקות והנתונים משוכפל בו, והבקשה מועברת לפונקציית php.

עם הפתרון הזה, הזמן משליחת השיחה לשירות שלנו ועד לפקודה הראשונה כוכבית ירד מ-1,5 שניות ל-0,05 שניות והזמן הזה תלוי מעט בגודל הפרויקט.

כתוצאה מכך, הזמן לפיתוח dialplan צומצם באופן משמעותי, ואני יכול להעריך זאת מכיוון שהייתי צריך לשכתב את כל ה-dialplan של כל המודולים ב-PHP. ראשית, שיטות כבר אמורות להיכתב ב-php כדי להשיג אובייקט ממסד הנתונים, הן היו נחוצות לתצוגה בממשק האינטרנט, ושנית, וזה העיקר, סוף סוף אפשר לעבוד בצורה נוחה עם מחרוזות עם מספרים ומערכים עם מסד נתונים ועוד הרחבות PHP רבות.

כדי לעבד את תוכנית החיוג במחלקת המודול, עליך ליישם את הפונקציה dialplanDynamicCall וטיעון pbxCallRequest יכיל אובייקט לאינטראקציה איתו כוכבית.

בנוסף, ניתן היה לבצע ניפוי באגים ב-dialplan (ל-php יש xdebug וזה עובד עבור השירות שלנו), אתה יכול לעבור צעד אחר צעד על ידי צפייה בערכים של משתנים.

נתוני שיחות

כל ניתוח ודוחות דורשים נתונים שנאספו בצורה נכונה, וגם בלוק מרכזיה זה עבר הרבה ניסוי וטעייה מהגרסה הראשונה עד השלישית. לעתים קרובות, נתוני שיחות הם סימן. שיחה אחת = הקלטה אחת: מי התקשר, מי ענה, כמה זמן דיברו. באפשרויות מעניינות יותר, ישנו שלט נוסף המציין לאיזה עובד מרכזיה התקשר במהלך השיחה. אבל כל זה מכסה רק חלק מהצרכים.

הדרישות הראשוניות היו:

• הצילו לא רק את מי שהתקשרה המרכזית, אלא גם את מי ענה, כי יש יירוטים ויש לקחת זאת בחשבון בעת ​​ניתוח שיחות,
• זמן לפני החיבור לעובד. ב FreePBX וכמה מרכזיות אחרות, השיחה נחשבת למענה ברגע שהמרכזייה מרימה את הטלפון. אבל בשביל התפריט הקולי כבר צריך להרים טלפון, אז כל השיחות נענות וזמן ההמתנה לתשובה הופך ל-0-1 שנייה. לכן, הוחלט לחסוך לא רק את הזמן שלפני תגובה, אלא את הזמן שלפני ההתחברות עם מודולים מרכזיים (המודול עצמו קובע את הדגל הזה. כרגע זה "עובד", "קו חיצוני").
• עבור תוכנית חיוג מורכבת יותר, כאשר שיחה עוברת בין קבוצות שונות, היה צורך להיות מסוגל לבחון כל אלמנט בנפרד.

האפשרות הטובה ביותר התבררה כאשר מודולי המרכזיה שולחים מידע על עצמם בשיחות ובסופו של דבר שומרים את המידע בצורה של עץ.

זה נראה כמו זה:

ראשית, מידע כללי על השיחה (כמו כולם - שום דבר מיוחד).

1. קיבל שיחה בקו חוץ"לבצק"בשעה 05:55:52 מהמספר 89295671458 למספר 89999999999, בסופו של דבר זה נענה על ידי עובד"מזכירה 2» עם מספר 104. הלקוח חיכה 60 שניות ודיבר 36 שניות.
2. עובד"מזכירה 2"מתקשר ל-112 ועובד עונה"מנהל 1» לאחר 8 שניות. הם מדברים 14 שניות.
3. הלקוח מועבר לעובד"מנהל 1"שם הם ממשיכים לדבר עוד 13 שניות

אבל זה קצה הקרחון; עבור כל רשומה אתה יכול לקבל היסטוריית שיחות מפורטת דרך המרכזיה.

כל המידע מוצג כקינון של שיחות:

1. קיבל שיחה בקו חוץ"לבצק» בשעה 05:55:52 מהמספר 89295671458 למספר 89999999999.
2. בשעה 05:55:53 הקו החיצוני שולח קריאה למעגל הנכנס "מבחן»
3. בעת עיבוד שיחה על פי הסכימה, המודול "שיחת מנהל", שבה השיחה היא 16 שניות. זהו מודול שפותח עבור הלקוח.
4. מודול"שיחת מנהל"שולח שיחה לעובד האחראי על המספר (לקוח)"מנהל 1" ומחכה 5 שניות לתגובה. המנהל לא ענה.
5. מודול"שיחת מנהל"שולח שיחה לקבוצה"מנהלי קורפ" אלו מנהלים אחרים מאותו כיוון (יושבים באותו חדר) ומחכים 11 שניות לתגובה.
6. קבוצה "מנהלי קורפ"קורא לעובדים"מנהל 1, מנהל 2, מנהל 3"במקביל למשך 11 שניות. אין תשובה.
7. שיחת המנהל מסתיימת. והמעגל שולח קריאה למודול "בחירת מסלול מ-1c" כמו כן מודול שנכתב עבור הלקוח. כאן השיחה עובדה במשך 0 שניות.
8. המעגל שולח קריאה לתפריט הקולי "בסיסי עם חיוג נוסף" הלקוח חיכה שם 31 שניות, לא היה חיוג נוסף.
9. התוכנית שולחת קריאה לקבוצה "מזכירות", שם הלקוח המתין 12 שניות.
10. בקבוצה, 2 עובדים נקראים בו זמנית"מזכירה 1"ו"מזכירה 2"ואחרי 12 שניות העובד עונה"מזכירה 2" התשובה לשיחה משוכפלת לשיחות הורים. מסתבר שבקבוצה הוא ענה "מזכירה 2", כאשר התקשר המעגל ענה"מזכירה 2" וענה לשיחה בקו החיצוני עם "מזכירה 2".

שמירת המידע על כל פעולה והקינון שלה היא שתאפשר לבצע פשוט דיווחים. דיווח על התפריט הקולי יעזור לך לגלות עד כמה הוא עוזר או מפריע. בניית דו"ח על שיחות שלא נענו על ידי עובדים תוך התחשבות בכך שהשיחה יורטה ולכן אינה נחשבת לא נענתה, ולקחת בחשבון שמדובר בשיחה קבוצתית, ומישהו אחר ענה קודם לכן, כלומר גם השיחה לא הוחמצה.

אחסון מידע כזה יאפשר לכם לקחת כל קבוצה בנפרד ולקבוע באיזו יעילות היא פועלת, ולבנות גרף של קבוצות שנעננו והוחמצו לפי שעה. כמו כן, ניתן לבדוק עד כמה מדויק החיבור למנהל האחראי על ידי ניתוח ההעברות לאחר החיבור למנהל.

אפשר גם לערוך מחקרים די לא טיפוסיים, למשל באיזו תדירות מספרים שלא נמצאים במאגר מחייגים לשלוחה הנכונה או איזה אחוז מהשיחות היוצאות מועברות לטלפון נייד.

התוצאה?

מומחה אינו נדרש לתחזק את המרכזיה; המנהל הרגיל ביותר יכול לעשות זאת - נבדק בפועל.

עבור שינויים, אין צורך במומחים בעלי כישורים רציניים; ידע ב-PHP מספיק, כי כבר נכתבו מודולים עבור פרוטוקול SIP, ועבור התור, ולהתקשרות לעובד ואחרים. יש שיעור עטיפה עבור כוכבית. כדי לפתח מודול, מתכנת יכול (ובצורה טובה צריך) לקרוא מודולים מוכנים. וידע כוכבית מיותרים לחלוטין אם הלקוח מבקש להוסיף דף עם דוח חדש כלשהו. אבל התרגול מראה שלמרות שמתכנתים של צד שלישי יכולים להתמודד, הם מרגישים חוסר ביטחון ללא תיעוד וסיקור נורמלי של הערות, כך שעדיין יש מקום לשיפור.

מודולים יכולים:

• ליצור יכולות חדשות לעיבוד שיחות,
• הוסף בלוקים חדשים לממשק האינטרנט,
• לרשת מכל אחד מהמודולים הקיימים, להגדיר מחדש פונקציות ולהחליף אותן, או פשוט להיות עותק מעט שונה,
• הוסף את ההגדרות שלך לתבנית ההגדרות של מודולים אחרים ועוד הרבה יותר.

הגדרות מרכזיה באמצעות API. כפי שתואר לעיל, כל ההגדרות מאוחסנות במסד הנתונים ונקראות בזמן השיחה, כך שניתן לשנות את כל הגדרות המרכזיה דרך ה-API. בעת קריאה ל-API, התצורה לא נוצרת מחדש והמודולים אינם מופעלים מחדש, לכן, אין זה משנה כמה הגדרות ועובדים יש לך. בקשות API מבוצעות במהירות ואינן חוסמות זו את זו.

המרכזייה מאחסנת את כל פעולות המפתח עם שיחות עם משך זמן (המתנה/שיחה), קינון ובמונחי מרכזיה (עובד, קבוצה, קו חיצוני, לא ערוץ, מספר). זה מאפשר לבנות דוחות שונים עבור לקוחות ספציפיים ועיקר העבודה היא ליצור ממשק ידידותי למשתמש.

הזמן יגיד מה יקרה בהמשך. יש עדיין הרבה ניואנסים שצריך לעשות מחדש, יש עדיין הרבה תוכניות, אבל שנה חלפה מאז יצירת הגרסה השלישית וכבר אפשר לומר שהרעיון עובד. החיסרון העיקרי של גרסה 3 הוא משאבי החומרה, אבל זה בדרך כלל מה שאתה צריך לשלם עבור קלות הפיתוח.

מקור: www.habr.com