Bir projenin hikayesi ya da Yıldız işareti ve Php'ye dayalı bir PBX oluşturmak için 7 yılımı nasıl harcadığım

Elbette birçoğunuzun benim gibi benzersiz bir şey yapma fikri vardı. Bu yazıda PBX'i geliştirirken karşılaştığım teknik sorunları ve çözümlerini anlatacağım. Belki bu, birisinin kendi fikrine karar vermesine ve birisinin iyi bilinen yolu izlemesine yardımcı olabilir, çünkü ben de öncülerin deneyimlerinden faydalandım.

Fikir ve temel gereksinimler

Ve her şey basitçe sevgiyle başladı yıldız işareti (iletişim uygulamaları oluşturmak için çerçeve), telefon ve kurulumların otomasyonu ÜcretsizPBX (web arayüzü yıldız işareti). Şirketin ihtiyaçları spesifik değilse ve yetenekler dahilindeyse ÜcretsizPBX - her şey harika. Kurulumun tamamı XNUMX saat içinde gerçekleşti; şirket, yapılandırılmış bir PBX, kullanıcı dostu bir arayüz ve kısa bir eğitimin yanı sıra istenirse destek aldı.

Ancak en ilginç görevler standart değildi ve o kadar da muhteşem değildi. yıldız işareti çok şey yapılabilir, ancak web arayüzünü çalışır durumda tutmak için kat kat daha fazla zaman harcamak gerekiyordu. Yani küçük bir ayrıntı, PBX'in geri kalanını kurmaktan çok daha uzun sürebilir. Önemli olan bir web arayüzü yazmanın uzun zaman alması değil, mimari özelliklerde olmasıdır. ÜcretsizPBX. Mimarlık yaklaşımları ve yöntemleri ÜcretsizPBX php4 zamanında ortaya konmuştu ve o anda her şeyin daha basit ve daha kullanışlı hale getirilebileceği php5.6 zaten vardı.

Bardağı taşıran son damla, diyagram biçimindeki grafiksel arama planlarıydı. Bunun için böyle bir şey inşa etmeye çalıştığımda ÜcretsizPBX, onu önemli ölçüde yeniden yazmam gerektiğini ve yeni bir şey inşa etmenin daha kolay olacağını fark ettim.

Temel gereksinimler şunlardı:

• acemi bir yöneticinin bile sezgisel olarak erişebildiği basit kurulum. Böylece firmalar bizim tarafımızdan PBX bakımına ihtiyaç duymazlar,
• Görevlerin yeterli sürede çözülmesini sağlayacak şekilde kolay değişiklik yapılması,
• PBX ile entegrasyon kolaylığı. sen ÜcretsizPBX ayarları değiştirmek için bir API yoktu, yani Örneğin, üçüncü taraf bir uygulamadan gruplar veya sesli menüler oluşturamazsınız; yalnızca API'nin kendisinden yararlanabilirsiniz. yıldız işareti,
• açık kaynak - programcılar için bu, istemcideki değişiklikler açısından son derece önemlidir.

Daha hızlı geliştirme fikri, tüm işlevselliğin nesne biçimindeki modüllerden oluşmasını sağlamaktı. Tüm nesnelerin ortak bir ana sınıfa sahip olması gerekiyordu; bu, tüm ana işlevlerin adlarının zaten bilindiği ve dolayısıyla zaten varsayılan uygulamaların olduğu anlamına gelir. Nesneler, içinde bulabileceğiniz dize anahtarlarıyla ilişkisel diziler biçimindeki argümanların sayısını önemli ölçüde azaltmanıza olanak tanır. ÜcretsizPBX Fonksiyonun tamamının ve iç içe geçmiş fonksiyonların incelenmesiyle mümkün oldu. Nesneler söz konusu olduğunda, banal otomatik tamamlama tüm özellikleri gösterecek ve genel olarak hayatı birçok kez kolaylaştıracaktır. Ayrıca, kalıtım ve yeniden tanımlama, değişikliklerle ilgili birçok sorunu zaten çözmektedir.

Yeniden çalışma süresini yavaşlatan ve kaçınılması gereken bir sonraki şey kopyalamaydı. Bir çalışanı aramaktan sorumlu bir modül varsa, bir çalışana çağrı göndermesi gereken diğer tüm modüller onu kullanmalı ve kendi kopyalarını oluşturmamalıdır. Yani bir şeyi değiştirmeniz gerekiyorsa, yalnızca tek bir yerde değişiklik yapmanız gerekecek ve "nasıl çalışıyor" araştırması tek bir yerde yapılmalı ve tüm proje boyunca aranmamalıdır.

İlk versiyon ve ilk hatalar

İlk prototip bir yıl içinde hazırdı. PBX'in tamamı planlandığı gibi modülerdi ve modüller yalnızca çağrıları işlemek için yeni işlevler eklemekle kalmıyor, aynı zamanda web arayüzünün kendisini de değiştirebiliyordu.

Evet, böyle bir şema şeklinde bir arama planı oluşturma fikri bana ait değil ama çok uygun ve ben de aynısını yaptım. yıldız işareti.

Programcılar bir modül yazarak zaten şunları yapabilirler:

• Çağrı işleme için şemaya ve soldaki öğeler menüsüne yerleştirilebilecek kendi işlevselliğinizi yaratın,
• web arayüzü için kendi sayfalarınızı oluşturun ve şablonlarınızı mevcut sayfalara ekleyin (eğer sayfa geliştiricisi bunu sağladıysa),
• ayarlarınızı ana ayarlar sekmesine ekleyin veya kendi ayarlar sekmenizi oluşturun,
• programcı mevcut bir modülden miras alabilir, işlevselliğin bir kısmını değiştirebilir ve onu yeni bir adla kaydedebilir veya orijinal modülü değiştirebilir.

Örneğin kendi ses menünüzü şu şekilde oluşturabilirsiniz:

......
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__); //Подменить существующий модуль

İlk karmaşık uygulamalar ilk gururları ve ilk hayal kırıklıklarını beraberinde getirdi. İşe yaradığına ve ana özellikleri zaten yeniden üretebildiğime sevindim. ÜcretsizPBX. İnsanların plan fikrini beğendiğine sevindim. Geliştirmeyi basitleştirmek için hala birçok seçenek vardı, ancak o zamanlar bile bazı görevler zaten kolaylaştırılıyordu.

PBX yapılandırmasını değiştirme API'si bir hayal kırıklığıydı - sonuç hiç de istediğimiz gibi olmadı. Ben de aynı prensibi aldım ÜcretsizPBXUygula düğmesine tıklandığında tüm konfigürasyon yeniden oluşturulur ve modüller yeniden başlatılır.

Şuna benziyor:

*Arama planı, bir çağrının işlendiği bir kuraldır (algoritma).

Ancak bu seçenekle PBX ayarlarını değiştirmek için normal bir API yazmak imkansızdır. İlk olarak, değişiklikleri uygulama işlemi yıldız işareti çok uzun ve kaynak yoğun.
İkincisi, iki işlevi aynı anda çağıramazsınız çünkü her ikisi de yapılandırmayı oluşturacaktır.
Üçüncüsü, yönetici tarafından yapılanlar da dahil olmak üzere tüm ayarları uygular.

Bu versiyonda olduğu gibi Askozia, yalnızca değiştirilen modüllerin konfigürasyonunu oluşturmak ve yalnızca gerekli modülleri yeniden başlatmak mümkündü, ancak bunların hepsi yarım tedbirler. Yaklaşımı değiştirmek gerekiyordu.

İkinci versiyon. Burun dışarı çekilmiş kuyruk sıkışmış

Sorunu çözme fikri, yapılandırmayı ve arama planını yeniden oluşturmak değildi. yıldız işaretiancak bilgileri veritabanına kaydedin ve çağrıyı işlerken doğrudan veritabanından okuyun. yıldız işareti Veritabanından konfigürasyonları nasıl okuyacağımı zaten biliyordum, sadece veritabanındaki değeri değiştirin ve bir sonraki çağrı, değişiklikler dikkate alınarak işlenecek ve fonksiyon, arama planı parametrelerini okumak için mükemmeldi. REALTIME_HASH.

Sonunda yeniden başlatmaya bile gerek kalmadı yıldız işareti ayarları değiştirirken tüm ayarlar hemen uygulanmaya başlandı yıldız işareti.

Arama planındaki tek değişiklik dahili numaraların eklenmesi ve ipuçları. Ancak bunlar küçük nokta değişiklikleriydi

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

Arama planında kolayca bir satır ekleyebilir veya değiştirebilirsiniz. Ben miyim (kontrol arayüzü yıldız işareti) ve tüm arama planının yeniden başlatılması gerekmez.

Bu, yapılandırma API'sindeki sorunu çözdü. Hatta doğrudan veritabanına gidebilir ve yeni bir grup ekleyebilir veya örneğin grubun "çevirme süresi" alanındaki çevirmeli bağlantı süresini değiştirebilirsiniz ve bir sonraki arama zaten belirtilen süre kadar sürecektir (Bu, bazı API işlemleri gerektirdiğinden eylem Ben miyim çağrılar).

İlk zorlu uygulamalar yine ilk gururu ve hayal kırıklığını beraberinde getirdi. İşe yaradığına sevindim. Veritabanı kritik bir bağlantı haline geldi, diske bağımlılık arttı, riskler arttı ama her şey istikrarlı ve sorunsuz çalıştı. Ve en önemlisi artık web arayüzü üzerinden yapılabilecek her şey API üzerinden de yapılabiliyordu ve aynı yöntemler kullanılıyordu. Ek olarak web arayüzü, yöneticilerin sıklıkla unuttuğu "ayarları PBX'e uygula" düğmesinden de kurtuldu.

Hayal kırıklığı, gelişimin daha karmaşık hale gelmesiydi. İlk sürümden bu yana, PHP dili dilde bir arama planı oluşturmuştur. yıldız işareti ve tamamen okunamaz görünüyor, ayrıca dilin kendisi de yıldız işareti Bir arama planı yazmak son derece ilkeldir.

Neye benziyordu:

$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'))

İkinci versiyonda arama planı evrensel hale geldi, parametrelere bağlı olarak olası tüm işleme seçeneklerini içeriyordu ve boyutu önemli ölçüde arttı. Bütün bunlar geliştirme süresini büyük ölçüde yavaşlattı ve kadran planına bir kez daha müdahale edilmesi gerektiği düşüncesi beni üzdü.

Üçüncü versiyon

Sorunu çözme fikri üretmek değildi yıldız işareti php'den arama planı ve kullanımı FastAGI ve tüm işlem kurallarını PHP'nin kendisine yazın. FastAGI verir yıldız işareti, çağrıyı işlemek için sokete bağlanın. Oradan komutları alın ve sonuçları gönderin. Dolayısıyla arama planının mantığı zaten sınırların dışındadır yıldız işareti ve herhangi bir dilde yazılabilir, benim durumumda PHP'de.

Çok fazla deneme yanılma vardı. Asıl sorun, zaten çok sayıda sınıfım/dosyamın olmasıydı. Nesnelerin oluşturulması, başlatılması ve birbirlerine kaydedilmesi yaklaşık 1,5 saniye sürdü ve çağrı başına bu gecikme göz ardı edilebilecek bir şey değil.

Başlatma yalnızca bir kez gerçekleşmeliydi ve bu nedenle çözüm arayışı, php kullanarak bir hizmet yazmakla başladı. Pthreadler. Bir haftalık denemenin ardından, bu uzantının çalışma şeklinin karmaşıklığı nedeniyle bu seçenek rafa kaldırıldı. Bir aylık testten sonra, PHP'de eşzamansız programlamayı da bırakmak zorunda kaldım; basit, PHP'ye yeni başlayan herkesin aşina olacağı bir şeye ihtiyacım vardı ve PHP'nin birçok uzantısı eşzamanlıdır.

Çözüm, C dilinde derlenen kendi çok iş parçacıklı hizmetimizdi. PHPLIB. Tüm ATS php dosyalarını yükler, tüm modüllerin başlatılmasını bekler, birbirlerine bir geri arama ekler ve her şey hazır olduğunda onu önbelleğe alır. Tarafından sorulduğunda FastAGI bir akış oluşturulur, tüm sınıfların ve verilerin önbelleğinden bir kopya bu akışta çoğaltılır ve istek php işlevine iletilir.

Bu çözüm ile servisimize çağrı gönderilmesinden ilk komuta kadar geçen süre yıldız işareti 1,5 saniyeden 0,05 saniyeye düştü ve bu süre biraz projenin büyüklüğüne bağlı.

Sonuç olarak, arama planı geliştirme süresi önemli ölçüde azaldı ve PHP'deki tüm modüllerin arama planının tamamını yeniden yazmak zorunda kaldığım için bunu takdir edebiliyorum. Birincisi, veritabanından bir nesne elde etmek için yöntemlerin zaten php'de yazılması gerekiyordu; web arayüzünde görüntülemek için bunlara ihtiyaç vardı ve ikincisi ve asıl mesele de bu, sonunda sayılar ve diziler içeren dizelerle rahatça çalışmak mümkün. veritabanı artı birçok PHP uzantısı ile.

Arama planını modül sınıfında işlemek için işlevi uygulamanız gerekir. arama planıDinamik Çağrı ve tartışma pbxCallRequest etkileşim kuracak bir nesne içerecektir yıldız işareti.

Ayrıca arama planında hata ayıklamak mümkün hale geldi (php'de xdebug var ve hizmetimiz için çalışıyor), değişkenlerin değerlerini görüntüleyerek adım adım hareket edebilirsiniz.

Arama verileri

Her türlü analiz ve rapor, verilerin doğru şekilde toplanmasını gerektirir ve bu PBX bloğu da ilk versiyondan üçüncü versiyona kadar pek çok deneme yanılma sürecinden geçmiştir. Çoğu zaman çağrı verileri bir işarettir. Bir çağrı = bir kayıt: Kim aradı, kim cevap verdi, ne kadar süre konuştular. Daha ilginç seçeneklerde, çağrı sırasında hangi PBX çalışanının arandığını gösteren ek bir işaret bulunmaktadır. Ancak tüm bunlar ihtiyaçların yalnızca bir kısmını kapsıyor.

İlk gereksinimler şunlardı:

• Sadece PBX'in kimi aradığını değil, kimin cevap verdiğini de kaydedin, çünkü dinlemeler var ve çağrıları analiz ederken bunun dikkate alınması gerekecek,
• Bir çalışanla bağlantı kurmadan önce geçen süre. İçinde ÜcretsizPBX ve diğer bazı PBX'lerde, PBX telefonu açar açmaz çağrı yanıtlanmış sayılır. Ancak ses menüsü için zaten telefonu açmanız gerekiyor, böylece tüm çağrılar yanıtlanıyor ve yanıt için bekleme süresi 0-1 saniye oluyor. Bu nedenle, yalnızca yanıt öncesindeki sürenin değil, aynı zamanda temel modüllere bağlanmadan önceki sürenin de kaydedilmesine karar verildi (bu bayrağı modülün kendisi belirler. Şu anda "Çalışan", "Harici hat"),
• Daha karmaşık bir arama planı için, bir çağrı farklı gruplar arasında seyahat ederken her bir öğeyi ayrı ayrı inceleyebilmek gerekiyordu.

En iyi seçeneğin, PBX modüllerinin aramalarda kendileri hakkında bilgi göndermesi ve sonuçta bilgiyi bir ağaç biçiminde kaydetmesi olduğu ortaya çıktı.

Şöyle görünüyor:

İlk olarak, aramayla ilgili genel bilgiler (herkes gibi - özel bir şey değil).

1. Dış hattan bir çağrı aldım "Hamuru için"05:55:52'de 89295671458 numarasından 89999999999 numarasına, sonunda bir çalışan tarafından cevaplandı"Sekreter2» 104 numara ile. Müşteri 60 saniye bekledi ve 36 saniye konuştu.
2. Çalışan "Sekreter2"112'yi arıyor ve bir çalışan cevap veriyor"Yönetici1» 8 saniye sonra. 14 saniye konuşuyorlar.
3. Müşteri Çalışana devredilir "yönetici1" 13 saniye daha konuşmaya devam ettikleri yer

Ancak bu buzdağının görünen kısmı; her kayıt için PBX aracılığıyla ayrıntılı bir arama geçmişi alabilirsiniz.

Tüm bilgiler çağrıların iç içe geçmesiyle sunulur:

1. Dış hattan bir çağrı aldım "Hamuru için» 05:55:52'de 89295671458 numarasından 89999999999 numarasına.
2. 05:55:53'te dış hat Gelen devreye bir çağrı gönderiyor "test»
3. Bir çağrıyı şemaya göre işlerken, modül “yönetici çağrısı", burada arama 16 saniyedir. Bu istemci için geliştirilmiş bir modüldür.
4. Modül "yönetici çağrısı"Numaradan sorumlu çalışana (müşteri) çağrı gönderir"Yönetici1”ve yanıt için 5 saniye bekler. Yönetici cevap vermedi.
5. Modül "yönetici çağrısı"gruba bir çağrı gönderir"ŞİRKET yöneticileri" Bunlar aynı yöndeki (aynı odada oturan) ve yanıt için 11 saniye bekleyen diğer yöneticilerdir.
6. grup "ŞİRKET yöneticileri"Çalışanları çağırıyor"Yönetici1, Yönetici2, Yönetici3"aynı anda 11 saniye boyunca. Cevapsız.
7. Yöneticinin görüşmesi sona erer. Ve devre modüle bir çağrı gönderiyor "1c'den rota seçme" Ayrıca istemci için yazılmış bir modül. Burada çağrı 0 saniye süreyle işlendi.
8. Devre ses menüsüne bir çağrı gönderir "Ek arama ile temel" Müşteri orada 31 saniye bekledi, ek arama yapılmadı.
9. Şema Gruba bir çağrı gönderiyor "Sekreterler", burada müşteri 12 saniye bekledi.
10. Bir grupta 2 çalışan aynı anda çağrılıyor "Sekreter1"Ve"Sekreter2" ve 12 saniye sonra çalışan cevap veriyor "Sekreter2" Çağrının yanıtı ebeveyn çağrılarına kopyalanır. Grupta şu cevabı verdiği ortaya çıktı:Sekreter2", çağrıldığında devre cevaplandı"Sekreter2" ve dış hattaki çağrıyı şu şekilde yanıtladı: "Sekreter2'.

Basitçe rapor oluşturmayı mümkün kılacak olan şey, her bir operasyonla ilgili bilgilerin kaydedilmesi ve bunların iç içe yerleştirilmesidir. Ses menüsündeki bir rapor, bunun ne kadar yardımcı veya engel olduğunu öğrenmenize yardımcı olacaktır. Çağrının kesildiğini ve bu nedenle cevapsız sayılmadığını ve bunun bir grup çağrısı olduğunu ve başka birinin daha önce yanıtladığını, yani çağrının da kaçırılmadığını dikkate alarak, çalışanlar tarafından kaçırılan çağrılara ilişkin bir rapor oluşturun.

Bu tür bir bilgi depolama, her grubu ayrı ayrı almanıza ve ne kadar etkili çalıştığını belirlemenize ve saate göre yanıtlanan ve kaçırılan grupların bir grafiğini oluşturmanıza olanak tanır. Yöneticiye bağlandıktan sonra transferleri analiz ederek sorumlu yöneticiyle bağlantının ne kadar doğru olduğunu da kontrol edebilirsiniz.

Ayrıca, veritabanında bulunmayan numaraların ne sıklıkta doğru dahili numarayı çevirdiği veya giden aramaların yüzde kaçının cep telefonuna yönlendirildiği gibi oldukça alışılmadık çalışmalar da yapabilirsiniz.

Sonuç?

PBX'in bakımını yapmak için bir uzmana gerek yoktur; bunu en sıradan yönetici bile yapabilir; pratikte test edilmiştir.

Değişiklikler için ciddi niteliklere sahip uzmanlara ihtiyaç yoktur; PHP bilgisi yeterlidir, çünkü SIP protokolü, kuyruk, bir çalışanı ve diğerlerini aramak için modüller zaten yazılmıştır. Bunun için bir sarmalayıcı sınıfı var yıldız işareti. Bir modül geliştirmek için programcı hazır modülleri arayabilir (ve iyi bir şekilde çağırmalıdır). Ve bilgi yıldız işareti müşteri yeni bir rapor içeren bir sayfa eklemek isterse tamamen gereksizdir. Ancak uygulama, üçüncü taraf programcıların başa çıkabilmesine rağmen, belgeleme ve yorumların normal şekilde ele alınması olmadan kendilerini güvensiz hissettiklerini, dolayısıyla hala iyileştirme için yer olduğunu gösteriyor.

Modüller şunları yapabilir:

• yeni çağrı işleme yetenekleri yaratın,
• web arayüzüne yeni bloklar ekleyin,
• mevcut modüllerin herhangi birinden miras alabilir, işlevleri yeniden tanımlayabilir ve değiştirebilir veya yalnızca biraz değiştirilmiş bir kopya haline gelebilir,
• ayarlarınızı diğer modüllerin ayarlar şablonuna ekleyin ve çok daha fazlasını yapın.

API aracılığıyla PBX ayarları. Yukarıda açıklandığı gibi, tüm ayarlar veritabanında saklanır ve çağrı sırasında okunur, böylece tüm PBX ayarlarını API aracılığıyla değiştirebilirsiniz. API çağrılırken konfigürasyon yeniden oluşturulmaz ve modüller yeniden başlatılmaz, bu nedenle kaç ayarınızın ve çalışanınızın olduğu önemli değildir. API istekleri hızlı bir şekilde yürütülür ve birbirlerini engellemez.

PBX, çağrılarla birlikte tüm önemli işlemleri, süreleri (bekleme/konuşma), iç içe geçme ve PBX terimleriyle (çalışan, grup, dış hat, kanal değil, numara) saklar. Bu, belirli müşteriler için çeşitli raporlar oluşturmanıza olanak tanır ve işin çoğu, kullanıcı dostu bir arayüz oluşturmaktır.

Bundan sonra ne olacağını zaman gösterecek. Hala yeniden yapılması gereken birçok nüans var, hala birçok plan var ama 3. versiyonun oluşturulmasının üzerinden bir yıl geçti ve şimdiden fikrin işe yaradığını söyleyebiliriz. Sürüm 3'ün ana dezavantajı donanım kaynaklarıdır, ancak geliştirme kolaylığı için genellikle ödemeniz gereken şey budur.

Kaynak: habr.com